אוטומציה שנכשלה: איך מתכננים ניסיונות חוזרים והתראות?

מבדילים בין כשל זמני לנתון שגוי

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

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

ניסיון חוזר דורש הגנה מכפילות

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

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

מתכננים השהיה ותקרת ניסיונות

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

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

התראה צריכה להגיע לאחראי עם פעולה ברורה

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

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

בודקים כשל מכוון בסביבת בדיקה

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

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

שאלות נפוצות