פיתוח Runbook ו-Playbook לצוותי DevOps

פיתוח Runbook: מדוע נהלים נשברים באירוע

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

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

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

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

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

מה משתנה בעבודת משמרת התורנים לאחר ההטמעה

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

אחרי — הבדיקות הראשונות כתובות, והאבחון נעשה תוך 5-10 דקות: המהנדס לא מחפש, אלא מאשר או פוסל השערות לפי הסדר.

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

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

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

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

פורמטים של נהלים: מה מתאים לצוות שלכם

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

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

השוואה בין גישות לתיעוד

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

פיתוח Runbook: שלבי העבודה על הנוהל

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

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

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

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

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

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

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

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

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

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

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

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

לפני: אבחון מהזיכרון

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

אחרי: מערך תרחישים מקושר

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

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

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

במה נוהל תגובה נבדל מהוראה?

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

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

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

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

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

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

שאלות נפוצות על נהלים והתמיכה בהם

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

יש לנו טיוטות של נהלים — האם נצטרך לשכתב אותן?

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

איך הנוהל קשור לתורנויות ולהתראות?

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

נדון במשימה ונחזור עם הערכה ותוכנית

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

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

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

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

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