פלייבוק לתיאום חלונות תחזוקה

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

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

המצב שממנו מתחילים

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

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

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

שלב 1 · מקור אחד לבעלוּת

כל השאר תלוי בזה, ולכן זה ראשון.

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

מה עושים כשהמקורות לא מסכימים

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

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

שלב 2 · מטריצת יעדי זמן

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

	נכס קריטי	נכס משני	נכס לא קריטי
חומרה קריטית	ימים	ימים	ימים
חומרה גבוהה	ימים	ימים	ימים
חומרה בינונית	במחזור	במחזור	במחזור

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

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

שלב 3 · לוח חלונות קבוע, שנקבע מראש

זה השלב שמשנה הכי הרבה ביחס למאמץ שהוא דורש.

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

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

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

מה נכנס ללוח

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

שלב 4 · אישור שמייצר ראיה מעצמו

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

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

שלב 5 · בדיקת התנגשות לפני שקובעים

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

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

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

שלב 6 · צ׳קליסט ביצוע שנסגר בזמן אמת

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

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

1. גיבוי נלקח ואומת

   לא «נלקח» — אומת. גיבוי שלא נבדק הוא הנחה.

2. נבדק בסביבה נפרדת

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

3. השירות הופסק והוחזר

   עם שעות. שתי שורות שמייצרות את משך ההשבתה בפועל.

4. נבדק אחרי

   מי בדק ומה בדק. «עלה» זה לא בדיקה.

5. תוצאה, כולל כישלון

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

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

שלב 7 · שלושה מדדים, לא לוח מחוונים

מדדו שלושה דברים. יותר מזה אף אחד לא יסתכל.

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

תבנית: מדיניות חלון תחזוקה בעמוד אחד

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

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

ארבעה דברים שלא כדאי לעשות

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

מה לוקח כמה זמן

לפי מה שראיתי, בארגון של כמה מאות שרתים: שלב 1 הוא רבעון של עבודה אמיתית ברוב המקומות, שלבים 2 ו‑3 הם שבועיים של החלטות, ושלבים 4 עד 7 תלויים בכלים. אין כאן קיצור דרך בשלב הראשון — וזה גם השלב שאם עושים רק אותו, השאר מתחיל לזוז מעצמו.