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