שני חלונות תקינים, לילה אחד, ומערכת שנפלה

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

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

למה זה קשה לתפוס

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

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

איפה הידע על התלויות באמת יושב

בשלושה מקומות בו‑זמנית, וזאת בדיוק הבעיה:

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

אף אחד משלושת המקומות האלה לא מגיע לרגע שבו בוחרים תאריך ביומן.

הידע הזמין הכי טוב: מי מדבר עם מי

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

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

שלוש הערות מהיישום

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

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

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

מתי הבדיקה שווה משהו

ברגע שבוחרים תאריך. לא אחרי, לא בדוח שבועי.

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

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

למה האזהרה לא צריכה לחסום

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

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

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

מה לעשות אם אין כלי ניטור תלויות

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

השאלה שמייצרת את הרשימה מהר: «אילו שתי מערכות אסור להשבית באותו לילה?». אנשים יודעים לענות עליה מיד, גם כשהם לא יודעים לצייר את הארכיטקטורה.

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

מה שווה למדוד

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

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