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