מערכות מפוזרות מודרניות נכשלות בדרכים שאינן יכולות להיות צפויות במלואן. מיקרו-שירות שהיה בריא לחלוטין בשעה 2:00 לפנות בוקר יכול להתמוטט לתוך הפסקת עבודה מלאה בשעה 2:03 לפנות בוקר, מה שמשאיר מהנדסי שיחות להתמוטטות דרך לוח התקנים וזרימי יומן בעוד המשתמשים הסופיים חווים שירות מתדרדרדר. המודל הישן של תגובה לתאונות ריאקטיביות, שבו בני אדם לזהות, לאבחן ולתקן בעיות, פשוט לא יכולים לעמוד בקצב עם היקף ומורכבות של התשתית של היום. Observability as the Foundation התבוננות כבסיס התאוששות עצמית מתחילה עם תצפית עמוקה. שלא כמו מעקב מסורתי, אשר מסתמך על קווים מוגדרים מראש וטקסטים סטטיים, תצפית אמיתית פירושה שאתה יכול לשאול שאלות אקראיות על המצב הפנימי של המערכת שלך באמצעות הנתונים שהיא משחררת. זה דורש שלושה עמודים שעובדים בקנה אחד: מטריקים, יומנים, וסימנים מפוזרים. מטריקים נותנים לך אותות סדרת זמן כגון שימוש ב-CPU, אחוזים של עיכוב בקשה ושיעורי שגיאה. יומנים מספקים את הסיפור מאחורי המספרים האלה. היישום המעשי כולל ציוד כל שירות עם OpenTelemetry, הסטנדרט המתעורר עבור איסוף טלמטיקה אגרסיבית. כאשר כל שירות משחרר אותות עקביים, עשירים בסימנטית, פלטפורמת התצפית שלך הופכת למקור יחיד של האמת על מה שקורה בפועל בייצור. כלים כגון Prometheus, Grafana, Jaeger, ו- OpenSearch מהווים את עמוד השדרה של צינור זה, לבלוע מיליארדי נקודות נתונים מדי יום ולהפוך אותם מחפשים כמעט בזמן אמיתי. קבלת היסוד הזה נכון הוא לא מסחרי. ללא נתונים טלמטיקה באיכות גבוהה, באיכות נמוכה, כל שכבה של אינטליגנציה שנבנתה עליו יפיק תוצאות לא אמין. Where AIOps Enters the Picture איפה AIOps נכנסת לתמונה פלטפורמות AIOps יושבות בחלק העליון של שכבת התצפית שלך וליישם למידה מכונה כדי לעשות את מה שהאנושות לא יכולה לעשות בקנה מידה: להתחבר אלפי אותות בו זמנית, לזהות דפוסים שקדמו לכישלונות, ולהבחין בין הפרעות אמיתיות לרעש של חלוקת המערכת הרגילה. זיהוי הפרעות בהקשר זה הוא לא רק אזהרה כאשר מטריקה חוצה סף סטטי. מערכות AIOps טובות להשתמש הלמידה ללא פיקוח כדי לבנות שורות בסיס דינמיות שמתאימות דפוסי התנועה שלך, עונות, קדנציה הפצה. שיא באיטיות שאלת מסד נתונים ב 11:55 בבוקר ביום שני עשוי להיות נורמלי לחלוטין עבור עומס העבודה שלך, בעוד אותו שיא ב 3:00 בבוקר ביום ראשון שווה להעיר מישהו. קשרי אירועים חשובים באותה מידה. אירוע תשתית יחיד לעתים קרובות מעורר מאות אזהרות בו זמנית במערכות מעקב שונות. ללא קשרי קשר, מהנדס ההתקשרות שלך מקבל 200 עמודים בתוך שלוש דקות, רובם הם סימפטומים ולא גורמים. פלטפורמות AIOps כמו Moogsoft, BigPanda ו-AIOps של PagerDuty משתמשות באלגוריתם מבוסס גרף ובניתוח זמן כדי להתמוטט סערות אזהרה לאירוע אחד אפשרי, תווית הסיבה האפשרית עבור המשיב. Automated Incident Remediation in Practice תיקון תאונות אוטומטיות בפועל זיהוי בעיה מהר יותר הוא בעל ערך. תיקון זה ללא התערבות אנושית הוא טרנספורמטיבי. תיקון אוטומטי כרוך בבניית ספריית פעולות Runbook שניתן להפעיל בתכנית כאשר תנאים ספציפיים נפגשים, וזה המקום שבו האדריכלות הופכת באמת מעניינת. נקודת התחלה מעשית היא לזהות את עשרת האירועים המובילים לפי תדירות בששת החודשים האחרונים. עבור קבוצות רבות, רשימה זו כוללת דברים כגון מחיצות שבורות מהזיכרון, מקטעי דיסק ממלאים, שורות של גיבוי עקב משתמשים איטיים, או תאריכים של תעודות. אלה הם מצבי כישלון מובן היטב עם צעדים תיקון חוזרים: הפעלה מחדש של פוד, ניקוי יומנים ישנים, גודל קבוצת צרכנים, סיבוב תעודה. כל אחד מהם ניתן לקודד כפעולה אוטומטית בפלטפורמה כמו Ansible, Runbook Automation, או מפעיל Kubernetes מותאם אישית. האדריכלות נראית בערך ככה: פלטפורמת AIOps שלך מזהה פגיעה ומקשר אותה לדפוס כישלון ידוע. לאחר מכן היא מפעילה הודעה Webhook או הודעת אוטובוס אירועים לאדריכל האוטומציה שלך, אשר מבצע את הפעולה המתאימה Runbook נגד API התשתית שלך. התוצאה, בין אם הצלחה או כישלון, נכתבת בחזרה לפלטפורמת התצפית שלך כאירוע מבוסס, סוגר את מעגל ההודעות. אם הפעולה האוטומטית נכשלת או אם הביטחון באבחון הוא מתחת לגבול מוגדר, המערכת מתדרדרת לתגובה אנושית עם כל הקשר הרלוונטי מראש עמוס בתעודת האירוע. מערכות אוטומטיות פועלות על תשתיות הייצור ללא הגנות מתאימות יכולות להחמיר את האירועים באופן משמעותי. לכל פעולה אוטומטית צריכה להיות רדיוס נפץ מוגדר, מצב ריצה יבש, מנגנון ריצה חוזרת, ומחבר מעגל שמפסיק פעולות אוטומטיות אם יותר מדי תיקונים מופעלים בתוך חלון קצר. Measuring What Matters למדוד את מה שחשוב המקרה העסקי של תשתית הריפוי העצמי נמדד באמצעות כמה מדדים אמינים מרכזיים. זמן ממוצע לזיהוי (MTTD) מציין כמה מהר נגיעות מופיעות על פני השטח. זמן ממוצע לתיקון (MTTR) ממד כמה זמן זה לוקח כדי לשחזר את השירות. כיסוי אוטומציה, אחוז האירועים שנפתרו לחלוטין ללא התערבות אנושית, אומר לך עד כמה מתבגר ספריית הריפוי שלך. ארגונים שביצעו השקעה רצינית בתחום זה מדווחים בדרך כלל על הפחתת MTTD של 50 אחוזים או יותר, הפחתת MTTR של 40 עד 70 אחוזים, ושיעורי כיסוי אוטומציה של 30 עד 60 אחוזים של נפח האירועים הכולל בתוך 18 חודשים מההשקעה הראשונית. The Road Ahead הדרך קדימה תשתית הריפוי העצמי אינה יעד שאתם מגיעים אליו ולאחר מכן מפסיקים. זוהי תרגול המתפתח ככל שהמערכות שלכם גדלים ומצבי הכישלון שלכם משתנים. הצוותים שעושים זאת טובים יותר מתייחסים לתיקוני האוטומציה שלהם כמו לקוד הייצור: גירסה, בדיקה, סקירה, ושיפור מתמיד בהתבסס על תוצאות האירועים האמיתיות. הם משלבים את נתוני ההתבוננות שלהם עם מערכות ניהול השינויים שלהם כך שמודלים של AIOps יכולים לקחת בחשבון את ההפצה האחרונה בעת אבחון הפרעות. המטרה הסופית היא תשתית שאינה רק נצפתה אוטומטית, אלא באמת עמידה: תשתית שמחכה לכישלון, מגיבה בצורה אינטליגנטית ומשפרת באופן מתמיד את עמדת האמינות שלה.
