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

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

שלושה סוגי כשל, והמסוכן שבהם

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

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

מה נכנס לראנבוק

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

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

אילו התראות באמת נחוצות

שלוש, לרוב התהליכים:

1. התהליך נכשל - שגיאה שעצרה את הריצה.
2. התהליך לא רץ כשהיה אמור - היעדר ריצה בחלון הצפוי.
3. חריגה בנפח - רץ אבל טיפל בהרבה פחות או בהרבה יותר מהרגיל.

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

איך מגדירים סף שלא מייצר רעש

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

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

לאן ההתראה הולכת

לא למייל כללי. התראה שנשלחת ל-info@ היא התראה שאיש לא קורא, וזו אחת הסיבות הנפוצות לכשל שקט למרות שקיים ניטור.

מה שעובד: ערוץ שהאחראי באמת קורא, עם שמו ברור בהודעה, ועם מה שצריך לעשות בגוף ההתראה עצמה. התראה שאומרת "Scenario 14 failed" ולא אומרת מה זה ומה עושים תגיע אל מי שאינו יודע מה לעשות איתה, ותידחה למחר.

מי מטפל כשאין איש מערכות?

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

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

למה ניסיונות חוזרים אינם פתרון מלא

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

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

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

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

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

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

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

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

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

מקורות

• אוטומציה לעסקים קטנים בישראל
• Make - טיפול בשגיאות בתרחישים