פיתוח מערכת בינה מלאכותית אוטונומית לזיהוי ותיקון תקלות

ניטור תקלות אוטונומי: היכן נשבר הטיפול הידני

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

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

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

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

מה נותן ניטור רציף וריפוי עצמי של תקלות

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

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

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

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

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

מצבי עבודה: סוכן על השרת, ניתוח יומנים, היברידי

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

במה נבדלים הקצוות

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

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

בידוד מעגלים ובחירה

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

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

שלבי ההטמעה: מהאודיט ועד למסירה לתפעול

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

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

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

ארטיפקטים: קונפיגורציות, סכמות, תקנוני משמרות

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

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

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

מקרה בוחן: זמן התגובה לתקלות הצטמצם פי שלושה

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

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

מה השתנה

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

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

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

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

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

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

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

ספקות טכניים לפני תחילת הפרויקט

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

לא נטבע בהתראות שווא?

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

איך מבדילים בין תקלה לעבודות מתוכננות?

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

אפשר להרחיב את הפתרון למעגלים אחרים?

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

מי אחראי לטעות של האוטומציה?

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

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

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

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

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

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