איך לבנות נוהל ניטור לאוטומציות שמזהה תקלות לפני שהלקוחות מזהים אותן

מתחילים מההבטחה העסקית, לא מרשימת שגיאות

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

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

1. נסחו את ההבטחה בפורמט: כאשר X קורה, Y חייב להופיע בתוך Z דקות.
2. הגדירו אילו שדות הופכים את התוצאה לשלמה ולא רק לקיימת.
3. קבעו מהו הנזק לאחר 15 דקות, שעה ויום של איחור.
4. בחרו תהליך יחיד לניסוי הראשון ורשמו במפורש מה מחוץ להיקף.

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

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

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

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

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

קובעים בעלות, חומרה וזמני תגובה לפני ההתראה הראשונה

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

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

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

מזהים גם מצב של אין אירועים

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

דוגמה היפותטית מלאה: מוקד מקבל בדרך כלל 8 עד 20 לידים בין 09:00 ל-12:00 בימי חול. בוחרים כלל פתיחה שמרני: אם עד 10:30 לא נקלט אף ליד, נשלחת התראת חומרה 2. לפני הסלמה בודקים במקור אם נוצרו לידים. אם במקור יש 6 וביעד אפס, התקלה במסלול. אם גם במקור אפס, בודקים את הטופס ואת הקמפיין ולא מבצעים replay. לאחר שלושה שבועות משווים התראות שווא ומעדכנים את הסף, בלי לשנות אותו על סמך יום חריג יחיד.

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

כלל: בימי א-ה בין 09:00 ל-17:00, אם current_time - last_received_at > 90 דקות, פתח אירוע חומרה 2.
אימות: השווה source_count ו-target_count באותו חלון.
חריג: חג או השבתה מתוכננת הרשומים בלוח התחזוקה.
פעולה: אל תבצע replay לפני שנמצא event_id במקור ולא נמצא ביעד.

מתכננים idempotency לפני שמאפשרים replay

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

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

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

מבצעים replay מבוקר עם רשימת מועמדים ואישור תוצאה

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

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

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

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

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

מגדירים בדיקות קבלה שמוכיחות תוצאה עסקית

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

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

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

מאבחנים התראה לפי הראיה האחרונה, לא לפי ניחוש

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

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

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

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

מתרגלים תקרית בלי לסכן לקוחות או נתוני ייצור

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

דוגמה היפותטית: בשעה 10:00 מוזן האירוע DRILL-204 עם סימון בדיקה, אך הוא אינו מופיע ברשימת התוצאות המדומה. בשעה 10:12 כלל הפער פותח התראה. האחראית התורנית מאשרת קבלה ב-10:16, מוצאת שהאירוע קיים במקור וחסר ביעד, ומכינה רשימת replay של מזהה אחד. לפני ההרצה היא בודקת שמפתח idempotency קיים ושהאירוע לא הושלם. ב-10:24 האירוע משוחזר, נוצרת רשומה יחידה וב-10:30 הבעלים העסקי מאשר סיום. לאחר התרגיל מתגלה שממלא המקום לא הצליח לקרוא את יומן האירוע, ולכן הרשאת הקריאה והוראת הגישה מתוקנות.

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

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

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

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

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

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

סוגרים אירוע רק אחרי התאמה, מסירה ולמידה

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

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

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

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

משיקים את הנוהל בשבעה צעדים ומוסרים בעלות

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

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

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

1. מלאו את תבנית ה-runbook עבור תהליך עסקי אחד.
2. הריצו את חמש בדיקות הקבלה ושמרו ראיות.
3. בצעו מסירה מעשית לבעלים ולממלא המקום.
4. הפעילו תקופת למידה של שבועיים ותעדו כל חריגה.
5. עדכנו ספים, אשרו זמני תגובה וקבעו תרגיל רבעוני.
6. עברו לתהליך נוסף רק לאחר שהראשון עבר תרגיל ושחזור בדיקה.