מערכת בינה מלאכותית לאבחון אוטומטי של אירועים (RCA)

ניתוח תקלות ידני לעומת RCA אוטומטי

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

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

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

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

מה נותן RCA אוטומטי: האפקט במדדים

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

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

ארבעה אפקטים מדידים:

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

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

מצבי אבחון: חוקים, למידה מההיסטוריה, היברידי

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

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

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

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

שלבי ההטמעה: מביקורת נתונים ועד מסירה לתפעול

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

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

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

תוצרי ההטמעה: מודל, חוקים, תיעוד, נהלים

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

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

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

מקרה בוחן: ניתוח תקלות בזרם אירועים בצפיפות גבוהה

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

נקודת המוצא

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

מה שינו ומה נהיה

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

חציון הניתוח — 6 דקות, תוצאה מוסברת אוטומטית במלואה ב-70-80% מהתקלות, והשאר מגיעות עם תחום חיפוש מצומצם ממילא. כשלים חוזרים מאותו סוג — 4-5 בחודש. הסוג היקר ביותר — מפלים בהדגרדציה של תלות משותפת — מזוהה אוטומטית ומגיע לניתוח ראשון.

במה שונה קורלציה של אירועים מחיפוש סיבת השורש?

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

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

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

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

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

ספקות טכניים: נתונים, דיוק, התראות שווא

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

הטלמטריה חלקית, חותמות הזמן לא מסונכרנות — זה גזר דין?

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

איך אתם מגבילים רמזי שווא?

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

עד כמה ההטמעה תהיה מדורגת ומי אחראי לאיכות?

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

נדון במשימה: נבנה סכמת אבחון לזרם שלכם

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

מה אנחנו מבקשים מצדכם:

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

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

תארו את המשימה בצורה חופשית — נחזור עם הערכה ותוכנית.