AIOps: התראות חזויות — הגדרה ואופטימיזציה

למה AIOps predictive alerting לא תופס תקלות

תמונה אופיינית: ההתראה מגיעה כבר אחרי הכשל — השירות הפסיק להגיב, התור גדל, לקוחות כותבים לתמיכה. זמן הזיהוי בתבנית כזו שווה לזמן עד שהבעיה תהפוך גלויה מבחוץ. הגדרת AIOps predictive alerting לא משנה זאת אוטומטית — נדרש מעבר מתגובה לחיזוי.

השכבה השנייה של הבעיה — רעש התראות. כללי סף מוגדרים בערך לפי ערכי שיא ואינם מתחשבים בפרופיל העומס היומי והשבועי, לכן אותו סף מופעל גם בעלייה של הערב וגם בירידה אמיתית. שיעור ההתראות השווא עולה, התורן מתרגל לסגור התראות בלי להסתכל — ומפספס את האמיתית.

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

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

מה משתנה לאחר המעבר להתראות חזויות

ההשפעה המדידה הראשונה — נפח תור ההתראות. מודל ספים במערך טיפוסי מפיק 200–400 הפעלות במשמרת, שמתוכן עשירית דורשת בירור: השאר — עליות עונתיות, משימות מתוכננות ומדדים שמתנדנדים באופן סינכרוני. מודל חזוי בונה קו בסיס לכל סדרה ומנמיך אותות קשורים, ומשאיר 20–40 התראות. שיעור השווא יורד מ-60–70% ל-10% ומטה.

ההשפעה השנייה — הזמן מהאות הראשון ועד לירידה. הסף מופעל כשהמדד כבר חצה את הגבול, כלומר ההאטה נראית למשתמש. חיזוי לפי מגמה וסטייה מהפרופיל העונתי נותן חלון של 15–40 דקות עד לחציית הסף: זה מספיק כדי להרחיב את המאגר, להפעיל מחדש מופע או לבטל מהדורה. התראה מוקדמת מעבירה את הכשל מפתרון לילי לעבודה מתוכננת.

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

העומס על התורן יורד ישירות: הקימות לילה הופכות למועטות פי 2–3, וניתוח מקרה בודד מהיר יותר, כי בהתראה כבר יש מגמה, שירותים מושפעים וסיבה סבירה. כללים וקווי בסיס חיים לצד הנתונים — במערך שלנו זה Prometheus עם רשומות נפרדות — לכן המודל מחושב מחדש על אותה היסטוריה כמו הגרפים.

אפשרויות לבניית התראה חזויה

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

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

כיצד אנו מטמיעים התראה חזויה

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

1. ביקורת ניטור. אוספים רשימה של מקורות מדדים, יומנים ועקבות, בודקים עומק אחסון, שלמות תיוג ואיך בנויות ההתראות כיום. כללים כפולים ורועשים מתעדים בנפרד, כדי לא להעביר את הבעיה למערכת חדשה.
2. תרשים תלויות שירותים. משחזרים מפה: מי קורא למי, היכן בסיסי נתונים ותורים משותפים, אילו כשלים מדורגים לאורך השרשרת. בלעדיה המודל רואה אנומליה אצל כל משתתף ושולח עשר התראות על תקלה אחת.
3. הגדרת כללי התראה. מגדירים ספים וחלונות הערכה, רמות קריטיות, מאחדים אותות קשורים לתקלה אחת, מפצלים התראות בין משמרות תורנים. סף למדד עם עונתיות יומית ולמונה שגיאות שונה — אין ערכים אוניברסליים.
4. בדיקה על תקלות היסטוריות. מריצים את המודל על כשלים קודמים: כמה מהם המערכת הייתה תופסת מראש וכמה מוקדם יותר, כמה התראות שווא הייתה נותנת. כללים עם יחס גרוע מתקנים לפני ההפעלה.
5. פיילוט במצב צפייה. התראות מגיעות לתורן, אבל לא מרימות משמרת, עד שדיוק מאומת על תעבורה חיה.
6. מסירה למשמרת תורנים. מוסרים נהלים: מה לעשות בעת הפעלה, כיצד לאשר או לדכא אות, כיצד לשנות ספים בלי מפתח, לאן להסתכל בהתראת שווא. מנתחים תרחישים יחד עם התורנים.

תיעוד, כללים ונהלים בתוצרים

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

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

מקרה בוחן: הפחתת רעש התראות בשירות בעל עומס גבוה

מה היה לפני ההטמעה

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

השבתה שנמנעה ותוצאות ההטמעה

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

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

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

AIOps או ספים סטטיים: מה לבחור להתראות

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

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

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

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

שאלות טכניות על התראות חזויות

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

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

באיזו מהירות אנו מגיעים לדיוק עבודה בהתראות?

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

האם זרם התראות השווא לא יגדל לאחר ההפעלה?

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

האם זה תואם לניטור הנוכחי וכיצד בנוי החזרה לאחור?

השכבה החזויה משתלבת באיסוף המדדים הקיים: בשילוב עם Prometheus היא קוראת סדרות שכבר נאספות ואינה דורשת סוכן נפרד במארחים. החזרה לאחור מסתכמת בכיבוי החיזוי — מערכת הניטור הבסיסית ממשיכה לפעול כבעבר.

נדון במשימה שלך ונחזור עם הערכה

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

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

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

תאר את משימת הניטור בצורה חופשית — נחזור עם הערכה, תוכנית עבודה ושאלות על התשתית שלך.