התיקון היה מוכן במרץ. החלון היה ביולי

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

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

הרשימה היא לא צוואר הבקבוק

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

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

חמש הנקודות שבהן זה נעצר

1. אף אחד לא יודע מי הבעלים

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

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

2. האישור נשאר בעל פה

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

3. החלון נקבע לפי היומן של צוות התשתיות

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

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

4. שתי מערכות מקושרות נופלות באותו לילה

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

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

5. אחרי שהחלון עבר, אין מה להראות

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

מה משנה את זה

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

1. מקור אחד לבעלות

   שורת שרת אחת שמיישבת את המצאי, המערכת והבעלים. כל השאר תלוי בזה.

2. קיבוץ לפי תיקון, לא לפי חולשה

   תיקון אחד סוגר לרוב עשרות CVE על עשרות שרתים. התיקון הוא היחידה שאפשר לתזמן; החולשה היא לא.

3. אישור שמייצר ראיה

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

4. בדיקת התנגשות לפני שקובעים

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

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

שורה אחת שכדאי לקחת

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