מערכת AI לניתוח הגורמים לנפילות בניות

ניתוח כשלי builds: היכן הבנייה נשברת

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

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

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

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

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

מה משתנה לאחר ההטמעה: לוחות זמנים ומחלקות כשל

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

קיצור זמן השחזור של הבנייה נובע לא מחיפוש בלוגים, אלא מלוקליזציה: השלב שנכשל, הקובץ שהשתנה, ה-commit החשוד ומקרים דומים מהעבר שכבר ניתנה להם הכרעה. המהנדס לא קורא את הפלט כולו אלא רואה מיד את נקודת הכשל — הזמן מהכשל עד להרצה ירוקה יורד מ-30–60 דקות ל-10–15.

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

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

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

השוואה בין גישות לניתוח כשלי בנייה

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

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

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

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

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

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

חפצי ההטמעה: מפות, ניתוב, נהלים

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

מה בדיוק אנחנו מוסרים:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

התלבטויות בנוגע לאינטגרציות, הרשאות ומגבלות

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

כיצד המערכת מבדילה בין תקלה בגלל הקוד לתקלה בסביבה?

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

כמה היסטוריית בניות נדרשת ואילו הרשאות על קוד המקור?

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

נדבר על המשימה: מה יידרש מצדכם

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

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

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