עמידות לתקלות של סוכני AI: failover והחלפה אוטומטית

Failover של סוכני AI: היכן בדיוק נשבר הפרודקשן

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

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

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

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

מה משתנה לאחר ההטמעה: זמן, הפסדים, כשלים

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

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

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

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

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

מצבי גיבוי: פעיל, חם וקר

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

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

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

תבניות failover: סדר ההטמעה במערכת שלכם

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

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

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

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

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

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

6. נראות. מדדי מעברים, שיעור תשובות מדורדרות, זמן שחזור. התראות — על תדירות ההפעלה, אחרת רעש של כשלים חד-פעמיים יסתיר דעיכה אמיתית.

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

מה מוסרים לידיים: תרשימים, מדיניות, נהלים

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

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

התוצרים נשארים במאגר שלכם ומתעדכנים יחד עם המערכת: משנים לוגיקה — באותו שינוי מתקנים את התרשים והנוהל.

מקרה בוחן: החלפה אוטומטית הסירה מעברים ידניים בלילה

הלקוח — שירות מסביב לשעון, שבו העוזרים עונים לפניות לקוחות, והפסקה בעבודתם נראית מיד. לפני ההטמעה, כשל סוכן בלילה הצריך משמרת ידנית: התראה, אבחון, מעבר לסוכן גיבוי, בדיקת תשובות ורק אחר כך שינה. המחזור ארך בממוצע 18–22 דקות, בלילות פחות מוצלחים — עד 40, ומקרים כאלה הצטברו ל-3–4 בחודש.

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

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

מדדים לפני ואחרי

• זמן עד העברת תעבורה: 18–22 דקות → 40–60 שניות.
• מעברים ידניים בלילה: 3–4 בחודש → אפס בשמונה חודשי תצפית.
• זמן השבתה בחודש: 60–90 דקות → דקות בודדות.
• שיעור הכשלים שנסגרו אוטומטית: כ-95%, והשאר — מקרים שבהם נדרשת החלטה לפי הנתונים, ולא מעבר.

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

מה לעשות אם המערכת כבר פרוסה במופע אחד?

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

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

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

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

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

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

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

ספקות טכניים: שאלות נפוצות בנושא עמידות בפני כשלים

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

כיצד אתם מתמודדים עם הפעלות שגויות?

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

מה אם גם הגיבוי אינו זמין?

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

נדון במשימה: ננתח את המערכת שלכם ונחזור עם הערכה

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

מה תקבלו לאחר הדיון במשימה:

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

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