מה אדריכלות יכולה ללמד אותנו על מערכות ריפוי עצמי

הועלה מחדש על ידי אפלטון

עוקב: 0

צוותי DevOps ומהנדסי אמינות אתרים (SREs) עוסקים בקוד מדי יום. פעולה זו מלמדת אותם לבחון את עולמם, לבצע תצפיות נבונות וליצור קשרים בלתי צפויים. אחרי הכל, למרות שהוא מאוד הגיוני ומתמטי באופיו, פיתוח תוכנה הוא, לפחות בחלקו, צורת אמנות.

לא משוכנע מהאמירה הזו? שקול את ההקבלות בין ההישגים האדריכליים המדהימים ביותר של ההיסטוריה לבין הנדסת תוכנה מודרנית. זוהי השוואה ראויה: בדיוק כמו הנדסת תוכנה, ארכיטקטורה משתמשת בחישובים מתמטיים מורכבים כדי ליצור משהו יפה. ובשני הדיסציפלינות, טעות בחישוב קלה יכולה להוביל לתוצאות משמעותיות. באופן מרתק, טעויות אדריכליות מפורסמות רבות דומות לבעיות שאנו מוצאים בקוד.

זכור, ההשראה נמצאת בכל מקום - כל עוד אתה יודע היכן לחפש. הנה כמה שיעורים שמהנדסי תוכנה יכולים ללמוד מהתגלות אדריכליות לאורך מאות שנים, במיוחד בנוגע לעתיד של מערכות ריפוי עצמי.

שיעור 1: מקרי Edge תמיד ינצלו פגיעויות של המערכת

מגדל סיטיקורפ - שנקרא כיום 601 לקסינגטון - סיים את בנייתו בעיר ניו יורק בשנת 1977, אז זה היה הבניין השביעי בגובהו בעולם. העיצוב החדיש של גורד השחקים כלל שלושה כלונסאות בגובה 100 פלוס רגל. זה היה פלא בהשלמה. עם זאת, סטודנט לתואר ראשון גילה במהרה משהו צורם: רוחות חזקות עלול לסכן את שלמות הבניין. ספציפית, אם רוחות רבעוניות חזקות פגעו בפינות של מגדל סיטיקורפ, המבנה היה נתון לקריסה - תרתי משמע. מקרה קצה.

למגדל היה סיכוי של אחד ל-16 לקרוס מדי שנה. הסיכויים האלה עשויים לפתות מישהו שיושב ליד שולחן הימורים, אבל התחזית הייתה עגומה עבור האדריכלים ומהנדסי המבנה מאחורי מגדל סיטיקורפ. למרבה המזל, טכנאים הצליחו לחזק את המפרקים המוברגים של הבניין. אסון נמנע.

מהנדסי מבנים ידעו ש-Citicorp Tower יתמודד בסופו של דבר מול רוח חזקה מספיק כדי לסכן את המיסבים שלו. באופן דומה, מהנדסי תוכנה ותיקים יודעים שניטור ביצועי יישומים חזקים (APM) וניהול אירועים אינם מספיקים כדי להגן על מערכת ממקרי הקצה הבלתי נמנעים. זה בגלל מערכות סטטיות בלי למידת מכונה (ML) היכולות אינן יכולות להתמודד עם מצבים חדשים בלתי צפויים ולא מתוכננים, כגון רוחות רבעונים. כאשר מסתמכים רק על כלי ניטור, מנהל אנושי חייב לפענח שגיאות ולהסלים את תהליך ניהול האירועים.

כדי לצמצם את הזמן הממוצע להתאוששות (MTTR)/זמן ממוצע לזיהוי (MTTD), צוותי DevOps חייבים לקבל את ההסתברות הגבוהה של מקרי קצה ולפעול לפריסת פתרונות למידה עצמית באופן מנע. שיעור זה מרחיק לכת, שכן ראיית הנולד היא קריטית בהנדסה.

שיעור 2: "בניית המטוס בזמן שהוא טס" יוצר מחזור בלתי נגמר

אירועים טרגיים סיפקו כמה מהם השיעורים החשובים ביותר בתולדות התעופה. כאשר מטוס סבל משחרור עצום באמצע הטיסה והתרסק ב-1954, מהנדסים הוכחו שחלונות נוסעים מרובעים הם נקודת לחץ מיותרת. מֵעַתָה וְאֵילָך, המטוסים היו מצוידים בחלונות מעוגלים. שריפות על הסיפון הובילו לסידורי ישיבה חדשים המתעדפים את קלות הפינוי. שינויים אלו הצילו אינספור חיים.

בתעשיות רבות - כולל תעופה - אין דרך לבצע בדיקת לחץ ממצה מוצר. כפי שהוזכר קודם לכן, מקרי קצה הם בלתי נמנעים. הפתרון הגדול ביותר כאן הוא שמהנדסי תוכנה חייבים לשים לב לפגיעויות של המערכת שלהם כשהם מציגים את עצמם. משם, עליהם להתייחס אליהם בצורה יעילה. לעשות זאת מצריך שני דברים: (1) זיהוי ומעקב אחר מדדי הביצועים העיקריים (KPIs) ו-(2) השקעת זמן ומשאבים בשיפור מערכות על סמך מדדים רלוונטיים.

צוות ההנדסה הממוצע משקיע ב-16 עד 40 כלי ניטור, אך לעתים קרובות הם מפספסים את הסימן שבו מדדים מדגימים הצלחה. פחות מ-15% מהצוותים עוקבים אחר MTTD, כך שהם מחמיצים 66% ממחזור החיים של האירוע. ורבע מהצוותים מדווחים חסרים את הסכמי רמת השירות שלהם (SLAs) למרות השקעה משמעותית במעקב אחר זמינות. זה אומר לנו שאיסוף נתונים מצריך ניתוח יסודי ושיטתי כדי לחתוך אותו - פתרונות נקודתיים אינם מספיקים עוד.

מהנדסי תוכנה, צוותי DevOps ו-SREs חייבים לתעדף תהליכים וכלים המוציאים ערך מכמויות עצומות של מידע על זמינות. במקום פשוט לראות שגיאה קריטית, הם חייבים לקחת דף מהספר של מהנדס תעופה ולקבל החלטות קריטיות, במהירות. הסוד לעשות זאת טמון ב-AI.

שיעור 3: בינה מלאכותית היא אבן בניין בסיסית למערכות ריפוי עצמי

מערכת אוטונומית לחלוטין, מתפקדת בצורה מושלמת, מערכת ריפוי עצמית היא אידיאלית עבור כל מהנדס תוכנה. מערכות שמתקנות את עצמן טובות לשביעות רצון הלקוחות, מכיוון שהן מבטלות זמן השבתה יקר מול הצרכן. יתר על כן, הם מועילים להפליא עבור פונקציות ניהול שירותי IT (ITSM), מכיוון שהם מפחיתים באופן משמעותי את הצורך בניהול כרטיסים מייגע. בניית מערכת כזו דורשת מספר מרכיבים, שרבים מהם אינם בהישג יד. אבל אנחנו קרובים יותר למציאות של ריפוי עצמי ממה שחלקם עשויים להבין.

היעדר אימוץ AI נרחב נותר המכשול הגדול ביותר שעומדות בפני מערכות ריפוי עצמי כיום. למרות שעסקים רבים אימצו כלים מבוססי AI או ML ראשוניים, תקינות הכלים הללו מוטלת בספק. כלומר, מהנדסים רבים עוסקים בינה מלאכותית עבור פעולות IT טכנולוגיות (AIOps) העוקבות אחר לוגיקה אוטומציה מבוססת כללים במקום אלגוריתמי AI אוטונומיים. ההבחנה אולי נראית קטנה, אבל בפועל, זה ההבדל בין שעות של אובדן תפוקה לבין מיליונים בהפסדים אפשריים.

העניין הוא שכלי AIOps מבוססי כללים מנתחים את האינטראקציות בין פתרונות נקודתיים שונים וכנראה יכולים לזהות שגיאות נתונים נפוצות. אבל מערכות מבוססות אוטומציה אינן יכולות לעבד את ההתפתחות של שגיאות חדשות לחלוטין לאורך זמן, וגם לא יכולות לחזות תקלות חדשות בנתונים. הסיבה לכך היא שהמנהלים האנושיים המקודדים את הפונקציות הללו מבקשים מהמערכת לעקוב אחר א אם זה, אז זה דפוס היגיון. כלי AIOps יעילים באמת מפחיתים שגיאות המתעוררות בכל ארבע נקודות הטלמטריה הקלאסיות - מזיהוי ועד רזולוציה - על ידי סיווג דפוסים חדשים ובעייתיים לפני שהטכנאים האנושיים בכלל מודעים לקיומם.

בזמן שאנחנו ממתינים ל הגל השלישי הממשמש ובא של AI, גרסה זו של AIOps היא הקרובה ביותר שיש לנו למערכות ריפוי עצמי. יהיה מעניין לעקוב אחר האופן שבו יישומי AIOps נוכחיים מדממים לעתיד של AI, שיכלול אוטומציה ממומשת במלואה ואפשרויות חשיבה עצמאיות. אולי אז גם מהנדסי מבנים יקצורו את הפירות של מערכת מבוססת בינה מלאכותית וריפוי עצמי.