בקצרה
דפוס Circuit Breaker עוצר זמנית קריאות למערכת שתלויים בה (dependency) כאשר מתקיים תנאי כשל שהוגדר מראש. בסוכן AI אוכפים אותו בשכבת ביצוע הכלים, כדי שניסיונות נוספים של המודל לא יעקפו את ההגבלה. מגדירים מה המשתמש רואה בזמן התקלה ובודקים התאוששות הדרגתית לפני שמאפשרים חזרה לתעבורה רגילה.
Circuit breaker vs retry: מתי מפסיקים לנסות
המדריך של Microsoft מבחין בין ניסיון חוזר (retry) לבצע פעולה לבין חסימת קריאות שצפויות להיכשל. הדוגמה שלו כוללת שלושה מצבים: סגור (closed), פתוח (open) וחצי פתוח (half-open). בהתאמה, קריאות עוברות כרגיל, נחסמות או עוברות בכמות מוגבלת לבדיקת התאוששות. המנגנון מסייע לצמצם את השפעת התקלה, אך אינו מתקן את המערכת עצמה. שני המקורות של Microsoft שמופיעים בהמשך נבדקו ב-11 בנובמבר 2026.
בסוכן עסקי ההמלצה שלנו היא לקבל את ההחלטה באמצעות מדיניות שנאכפת בקוד החיבור. הנחיה למודל לא לנסות שוב יותר מדי אינה מגבלת תעבורה אמינה. המודל יכול להציע קריאה נוספת לכלי, אבל שירות הביצוע חייב לאכוף עליה את אותה הגבלה.
מתחילים במערכת אחת שהאטה בה משפיעה גם על עובדים וגם על תהליכי AI. מגדירים אילו כשלים נספרים ואילו מצביעים על בעיה בבקשה מסוימת. מזהה לקוח שגוי לא צריך לסגור אוטומטית את הגישה לכל המשתמשים. קובעים ספים לפי התנהגות שנמדדה ובדיקות מבוקרות, ולא לפי מספרים שאמורים להתאים לכל מערכת.
דוגמה: בירור מלאי במערכת ותיקה
המחשה בלבד, לא סיפור לקוח: סוכן מכירות פונה ל-API של מלאי במערכת לגאסי (Legacy), בזמן שעובדים משתמשים באותה מערכת. במהלך האטה, כמה שיחות מבקשות שוב ושוב מידע על מלאי. גם בקשות לקריאה בלבד יכולות להתחרות עם העובדים על חיבורים ועל משאבי עיבוד מוגבלים.
ממקמים את מנגנון ההגנה בגבול כלי המלאי ומחזירים תוצאה מובנית של חוסר זמינות כאשר קריאה נחסמת. הסוכן צריך להסביר שלא ניתן היה לבדוק זמינות עדכנית. אסור לו לפרש תשובת ברירת מחדל ריקה כאילו אין מלאי, או לטעון ששמירת מלאי הושלמה.
כמות שנשמרה במטמון יכולה לשמש לתשובה לצורכי מידע עם תאריך ברור, אם העסק מאפשר זאת. היא אינה אמורה לאשר בשקט התחייבות למלאי. אם דוחים את העבודה, מתעדים מי אחראי לה ובאילו תנאים היא פגה. לא מבטיחים עדכון אוטומטי אם אין בפועל משימה שנשמרה באופן עמיד ודרך למסור את התוצאה.
אוכפים מדיניות אחת בכל נתיבי הגישה הרלוונטיים
הנחיות Microsoft לטיפול בכשלים זמניים ממליצות לבדוק ניסיונות חוזרים מובנים ולהימנע משכבות כפולות שלהם. בוחנים יחד את ספריית הלקוח, שכבת ה-HTTP, מנוע תהליכי העבודה (workflow) ולולאת הסוכן. אחרת, מספר קטן של ניסיונות בכל שכבה עלול להצטבר להרבה יותר קריאות מהמתוכנן. ראו את המקור לטיפול בכשלים זמניים בהמשך.
ההמלצה שלנו היא לזהות כל נתיב שמגיע למערכת המוגנת. שינוי שם הכלי או מעבר למתאם נוסף אינם צריכים לעקוף את מדיניות התקלה. כשהשירות רץ בכמה תהליכים (workers), מבררים אם מנגנוני ההגנה מקומיים או מתואמים ומודדים את התעבורה המצטברת. מגבלה בתהליך אחד אינה מגבלה של כלל המערכת.
מפרידים לפי גבול הכשל האמיתי. אם שתי פעולות משתמשות במערכות עצמאיות, כשל באחת לא בהכרח צריך להשבית את שתיהן. אם הן חולקות אותה מערכת מוגבלת, מונים נפרדים עלולים להסתיר עומס מצטבר. מגבילים גם מקביליות (concurrency): המנגנון מגיב לכשלים ואינו מחליף תכנון של התעבורה לפני שהכשלים מופיעים.
בודקים את החזרה לעבודה ואת הצעד הבא של המשתמש
בסביבה מבודדת מדמים תגובות איטיות, כשל ממושך והתאוששות חלקית. מודדים את מספר הקריאות בפועל למערכת בזמן שהמנגנון פתוח. לאחר מכן מאפשרים תעבורת התאוששות מוגבלת ובודקים שעבודה שהצטברה אינה מגיעה בבת אחת ללא בקרה. כוללים בעומס הבדיקה גם שיחות מקבילות של סוכנים וגם תעבורה רגילה של היישום.
מגדירים הצלחה לפני הבדיקה: קריאות שנחסמו נשארות חסומות, פעולות בלתי תלויות ממשיכות לעבוד, המשתמשים מקבלים הסבר מדויק וההתאוששות נשארת בגבולות העומס שסוכמו. עוקבים אחר קריאות שנדחו, זמן בכל מצב, גיל המשימות בתור אם יש כזה ותוצאות עסקיות מוצלחות. חזרה למצב סגור לבדה אינה מוכיחה שהמשתמש קיבל את התוצאה.
משאירים אחראי תפעולי שיוכל להסביר מדוע ההגנה הופעלה ומה עדיין לא נפתר. צוות קטן ומנוסה יכול להיעזר בכלי פיתוח AI כדי לבנות את החיבור במהירות, תוך שמירה על האחריות להחלטות האלה. UVISION מספקת מפתחים ייעודיים ופרויקטים מנוהלים עם לפחות מפתח אחד במשרה מלאה בכל פרויקט, ומשלבת תחזוקה מתמשכת של מערכות לגאסי קריטיות עם הטמעת AI מעשית.
שאלות נפוצות
מה זה Circuit Breaker Pattern?
זהו דפוס שעוצר זמנית קריאות למערכת שתלויים בה כאשר מתקיימים תנאי כשל מוגדרים, ובהמשך מאפשר תעבורה מוגבלת לבדיקת התאוששות. בתהליך AI אוכפים את ההתנהגות בשכבת הביצוע. הסוכן חייב לטפל בכנות בתוצאה של חוסר זמינות, ולא לפרש קריאה שנחסמה כפעולה מוצלחת או כתוצאה עסקית ריקה שממנה אפשר להסיק מסקנות.
למה משתמשים ב-Circuit Breaker?
משתמשים בו כאשר קריאות חוזרות למערכת שנמצאת בתקלה עלולות לצרוך משאבים או לפגוע בעבודה אחרת. סוכן AI עשוי לבקש שוב את אותו כלי, ולכן הנחיות למודל לבדן אינן בקרת תעבורה מספקת. הדפוס יכול לצמצם את הלחץ הזה, אך אינו מתקן את המערכת, מוכיח קיבולת או מחליף הגבלת מקביליות.
איך מיישמים Circuit Breaker?
מזהים את המערכת שתלויים בה ואת מי שפונה אליה, מסווגים כשלים רלוונטיים ומגדירים מדיניות בגבול הביצוע. בודקים ניסיונות חוזרים קיימים ומביאים בחשבון ריצה בכמה תהליכים במקביל. מגדירים תשובות לחוסר זמינות וחזרה מבוקרת, ואז בודקים האטה והתאוששות חלקית בסביבה מבודדת. מודדים תעבורה בפועל ותוצאות עסקיות, ולא מסתמכים רק על מצב מנגנון ההגנה.
לקריאה נוספת
רוצים לבחון איך זה מתאים למערכות שלכם?
לשירות הרלוונטי