AI Root Cause Analysis — איתור שורש הבעיה באופן אוטומטי

מאת צוות מדיה דיל · 09.08.2026 · Technology · 8 דק׳

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

שירות ההתראות ללקוחות מתחיל לשלוח הודעות באיחור. הצוות בודק את השירות עצמו - הכל תקין, אין שגיאות, השרתים לא עמוסים. הם מרחיבים את הבדיקה לשירות שממנו הוא שואב נתונים - גם שם הכל נראה בסדר. רק אחרי שעה של חיפוש מגלים שהבעיה בכלל בתור ההודעות (Message Queue) שמשותף לשלושה שירותים, שאחד מהם החל לצרוך הודעות לאט יותר בגלל שינוי קונפיגורציה לא קשור, וגרם לעומס שהשפיע על כל השאר. זו הדוגמה הקלאסית לפער בין תסמין לשורש: מה שרואים ראשון כמעט אף פעם לא המקום שבו הבעיה התחילה. AI Root Cause Analysis נועד לצמצם את הפער הזה - לא רק לזהות שמשהו לא בסדר, אלא לעקוב אחורה בשרשרת הסיבתיות עד שמגיעים לגורם האמיתי.

למה שורש הבעיה כל כך קשה לאיתור במערכות מבוזרות

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

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

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

גרף תלויות: הבסיס לניתוח שיטתי

הכלי המרכזי ב-Root Cause Analysis אוטומטי הוא גרף תלויות - מיפוי של כל השירותים במערכת והקשרים ביניהם, כולל תלויות ישירות (קריאות API) ותלויות עקיפות (משאבים משותפים כמו מסדי נתונים, תורים, Cache). הגרף הזה יכול להיבנות משילוב של כמה מקורות: ניתוח סטטי של הקוד (מי קורא למי), ניתוח דינמי מתוך Traces בזמן ריצה, ותצורת התשתית (איזה שירות משתמש באיזה מסד נתונים).

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

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

בדיקת השערות: מ"מה קרה" ל"למה זה קרה"

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

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

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

קורלציה בזמן: הכלי החזק והמסוכן ביותר

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

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

מ-Root Cause Analysis ל-Prevention

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

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

שכבת ביניים: כשהגורם השורשי הוא אנושי או תהליכי

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

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

טעויות נפוצות

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

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

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

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

שאלות נפוצות

האם ניתוח שורש הבעיה יכול לעבוד בלי גרף תלויות מלא ומעודכן?

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

מה ההבדל בין זה לבין ניתוח לוגים רגיל?

ניתוח לוגים מתמקד במציאת מידע רלוונטי בתוך נתוני לוג; Root Cause Analysis הוא שכבה שמעליו - הוא משתמש בלוגים, מדדים והיסטוריית שינויים יחד, כדי לענות על שאלת "למה", לא רק "מה קרה".

כמה זמן לוקח לבנות גרף תלויות מדויק לארגון קיים?

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

האם ייתכן שהניתוח יזהה כמה גורמים שורשיים בו-זמנית?

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

איך מוודאים שהניתוח לא "ממציא" קשרים שלא קיימים?

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

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

תגיות: AI Root Cause Analysis · ניתוח שורש בעיה · RCA אוטומטי · אבחון תקלות · Distributed Systems Debugging · AIOps

← חזרה לבלוג · צור קשר