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