הגירת פתרון AI: היכן זה נשבר ומה העסק מפסיד
העברת פתרון AI — זה לא העברת מכולות: יחד עם השירות עוברים אינדקס וקטורי, משקולות המודל, כללי עיבוד מקדים ותור בקשות. כל שכבה מתעדכנת בקצב שלה, והפער ביניהן מתגלה לא מיד — תחילה בכשלים נדירים, אחר כך בירידה יציבה באיכות התשובות.
הפער הטיפוסי הראשון — חוסר סנכרון בין נתונים למודל. בזמן שהאינדקס מדביק את זרם הרשומות החדשות, השירות עונה לפי הקשר מיושן: פורמלית הכל חי, אבל הרלוונטיות והדיוק יורדים.
זה לא מתוקן על ידי האצת ההעברה, אלא על ידי סכמת כתיבה כפולה וקישור מפורש של גרסת המודל לגרסת האינדקס — אז החזרה לאחור לא קורעת את הקישוריות.
מקום הכשל השני — ירידה באיכות לאחר המעבר: סביבה אחרת משנה את סדר החישובים, את התנהגות המאיץ והרכב המטמון, לכן התפלגות התשובות משתנה. בלי מערך בקשות ייחוס והרצות צל בשני קווי מתאר, התשובה נראית דומה, אבל למעשה היא סוטה במשמעות.
השלישי — ניתוק אינטגרציות וצמיחת התור. מערכות חיצוניות מחזיקות כתובות ישנות ותקוות קצה, חזרות מכפילות פעולות, מטמון לא מחומם מגדיל את זמן התגובה. במעבר חלק מהבקשות עוברות לתור, והוא גדל מהר יותר ממה שמתפנה: מכאן השבתת השירות ובקשות אבודות.
אנחנו מפרקים איך זה נסגר: העברת עומס מדורגת, חימום ובקרת מדדי איכות בכל שלב.
האפקט של המיגרציה: השבתה, כשלים, מהירות התאוששות
ההעברה הראשונה כמעט תמיד חושפת את אותו הדבר: השירות חי באזור אחד אצל ספק אחד, והמודל, האינדקס הווקטורי והתור מוקמים ידנית לפי הוראות. כל עוד הכל עובד, זה לא מורגש.
ברגע של כשל ספק, השחזור נמתח לשעות: צריך לא רק להחזיר משאבי מחשוב, אלא גם לשחזר את המצב — משקולות, מטמון אמבדינגים, כללי ניתוב.
לאחר המיגרציה אותה מערכת מתוארת באופן הצהרתי: תשתית, הרשאות וניתוב חיים כקוד, ו-Kubernetes נותן דרך זהה להפעלה בשני העננים. המעבר מצטמצם להעברת משקולות תעבורה, ולא לפריסה מאפס.
חלון ההשבתה במעבר מתוכנן נמדד בדקות: קו המתאר מוקם עם חימום המודל, לכן הבקשה הראשונה לא ממתינה לטעינת משקולות ואינדקס.
הוסר סוג שלם של כשלים — כשל ספק או אזור זמינות. פעם זה означало עצירת השירות, עכשיו — הסרת משקולות מנקודה לא זמינה והעברת הזרימה לקו מתאר שני. את עמידות השירות בודקים בתרחיש: מכבים קו מתאר אחד תחת עומס עבודה ובודקים עד כמה עיבוד הבקשות יורד.
העומס על האינפרנס מתחלק בין קווי המתאר: זרימה יציבה הולכת לראשי, פיקים — לגיבוי, לכן הירידה באיכות מורגשת לא למשתמש, אלא רק לגרף. זמן ההתאוששות לאחר תקלה מתקצר לדקות: החזרה לעבודה לא דורשת צעדים ידניים ולא תלויה במי מהמהנדסים שנמצא בקשר.
דרכי מעבר: העברה קרה, חיה ומדורגת
מצב ההעברה נבחר לפי פרופיל העומס ולפי כמה מצב השירות מחזיק בין בקשות. אם המודל עונה לקריאות בודדות ולא צובר דבר, המעבר מצטמצם להעתקת ארטיפקטים והעברת תעבורה.
אם בקו המתאר יש תורים, מטמונים, משימות ארוכות וסשנים זורמים, ניתוק החיבור נראה למשתמש מיד — ומחיר הטעות בבחירת המצב עולה בחדות.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| העברה קרה | שירותים פנימיים, עיבוד אצווה, קווי מתאר לבדיקה | נדרש חלון תחזוקה; בזמן ההעברה השירות אינו זמין כולו |
| מעבר מדורג | מוצר מודולרי: תחילה מוציאים את המודל, אחר כך תורים ואחסון | תקופה ארוכה שבה פועלים שני אתרים; קשה יותר לאתר את סיבת התקלה |
| קו מתאר משוכפל | פרודקשן עם סשנים זורמים ודרישת רציפות | צריכה כפולה של משאבים, סנכרון מצב ונקודת ניתוב אחודה |
איך לבחור מצב
הסתכלו על שלושה גדלים: חלון תחזוקה מותר, שיעור הבקשות שאסור לאבד, ונפח המצב שצריך להעביר. העברה קרה נכנסת לחלון של יחידות שעות ונותנת השבתה של עשרות דקות. מעבר מדורג מפחית את ההשבתה לשניות בכל שלב, אך דורש לשמור על תאימות בין שני קווי המתאר.
קו מתאר משוכפל מסיר את ההשבתה לחלוטין — בזכות כך שהעומס נישא זמנית על ידי תשתית כפולה, וחזרה לאחור אפשרית על ידי החלפת מסלול בדקות.
שלבי העבודה: מביקורת תלויות ועד מסירה
מיגרציה של פתרון AI אינה מצטמצמת להעברת מכולה: המצב מפוזר בין משקולות המודל, אחסון וקטורי, תורי פלט ומטמון אמבדינגים. כל עוד לא נבנתה סכמת תלויות, העברת תעבורה היא לוטו. לכן השלבים הולכים בקפדנות ברצף, עם ארטיפקט בסוף כל שלב.
- ביקורת תשתית. עורכים מלאי של שירותים, מודלים ואינטגרציות חיצוניות, מתעדים גרסאות אימג'ים, מדיניות רשת, מגבלות והרשאות גישה.
- סכמת תלויות. בונים גרף: מי קורא וכותב מצב, היכן כרכים ותורים משותפים, אילו קריאות מחויבות להיות סינכרוניות, ואילו מאפשרות אספקה מושהית.
- הכנת קו מתאר יעד. פורסים סביבה עם אותם ממשקים, מגדירים סודות, רשת, ניטור וסקיילינג אוטומטי — לפני העברת הנתונים.
- העברת נתונים ומצב. אינדקסים וקטוריים, מטמונים ותורים מועברים באופן אינקרמנטלי, עם כתיבה כפולה בשלב המעבר: המקור נשאר פעיל.
- בדיקות קבלה. מריצים בקשות ייחוס, משווים איכות תשובות, השהיות וצריכת משאבים עם קו המתאר המקורי, מנתחים פערים.
- תוכנית מעבר ותקנון חזרה לאחור. מעבירים תעבורה במנות, בהתאם למדדי שגיאות והשהיות; חזרה לקו המתאר הקודם — בלי אובדן רשומות.
- מסירה. מוסרים תיעוד, סכמות, לוחות ניטור והוראות הפעלה — צוות הלקוח מנהל את הפתרון בעצמו.
כל שלב מסתיים בארטיפקט: סכמה, תוכנית או פרוטוקול בדיקות. לפיהם רואים אם קו המתאר מוכן לשלב הבא, — וזה מה שמאפשר לעבור מיגרציה עם השבתות בדקות, ולא בשעות.
סכמות, מדיניות גישה ותקנוני מעבר
מערך הארטיפקטים מועבר לא כ'ארכיון לזיכרון', אלא למאגר העבודה של הלקוח: תצורות קו המתאר נשמרות כקוד, שינויים עוברים סקירה ונפרסים באותה דרך כמו בסביבת הפרודקשן.
לפני הקבלה אנחנו מפרקים כל סעיף על מערכת חיה יחד עם משמרת התורנות שלכם, כדי שהמעבר והחזרה לאחור יבוצעו לפי מסמך, ולא לפי הזיכרון של הקבלן.
- טופולוגיית קו מתאר — סכמת רשתות, אזורי זמינות, נקודות יציאת תעבורה ומיקום צמתי פלט המודלים עם הסבר אילו קישורים קריטיים בעת תקלה.
- מדיניות גישה — כללי בידוד רשת, הגבלות על תעבורה יוצאת וסדר גישה לשירותים חיצוניים שעיבוד הבקשות תלוי בהם.
- תפקידים והרשאות — מטריצת גישה: מי פורס, מי קורא יומנים, מי מפעיל מעבר, למי יש זכות לחזרה לאחור; עקרון הרשאות מינימליות עם הפרדת תפקידים.
- תקנון מעבר — סדר שלב-אחר-שלב להעברת תעבורה לקו מתאר חדש: בדיקות מוכנות, נקודות בקרה, תנאים שבהם הצעד מוחזר לאחור.
- תקנון חזרה לאחור — זמן התאוששות יעד, סדר החזרת תעבורה לקו המתאר הקודם, קריטריונים להפעלה ואחראים להחלטה.
- הוראות למשמרת תורנות — תרחישים קצרים לתקלות אופייניות: אי-זמינות צומת, עלייה בהשהיות, כשל תלות חיצונית, עם ציון מה לבדוק קודם כל.
- תיעוד תחזוקה — תיאור תצורה, סכמת גיבוי מודלים ונתונים, סדר עדכון ויומן שינויים של קו המתאר.
לאחר המסירה עורכים מעבר וחזרה לאחור באימון בצד שלכם — כך התקנונים נבדקים לתפקוד, ולא נשארים פורמליות.
מקרה בוחן: העברת עומס עבודה בלי לעצור את השירות
הלקוח — שירות שנותן תשובות מודל על תעבורה חיה: שעות שיא, זרימת פניות וציפיות קשיחות להשהיה. המעבר לענן אחר נתקל בדבר אחד: עצירה משמעה זרם שגיאות אצל לקוחות וטיפול ידני בתורים. לכן ההעברה התנהלה כפרויקט עם שני קווי מתאר פעילים — האתר הישן והחדש חיו במקביל, התעבורה הועברה במנות.
| מדד | לפני ההעברה | אחרי ההעברה |
|---|---|---|
| חלון השבתה | עצירות מתוכננות של 40–60 דקות | 0 — מעבר על תעבורה חיה |
| שיעור תשובות שגויות | 2.1% בשעות שיא | 0.3% ומטה |
| זמן חזרה לעבודה | 25 דקות של פעולות ידניות של התורן | 4 דקות לפי תקנון אוטומטי |
| נפח הנתונים המועברים | רק משקולות המודל, ידנית | כל קו המתאר: משקולות, תורים, מטמון מאפיינים |
העברנו לא רק משקולות של מודלים, אלא גם תורים, מטמון מאפיינים, תצורת סביבה — את המצב שבגללו הרציפות בדרך כלל נשברת. כל שלב סגרנו באימות לפי סכומי ביקורת: פער עצר את המעבר עד לתיקון. את קו המתאר החדש הקמנו על Kubernetes עם רפליקות בשני אזורי זמינות.
את הנתיב חזרה השארנו פתוח: האתר הישן נשאר בגיבוי חם, ובחריגה מהסף לפי שיעור שגיאות התעבורה חזרה אליו אוטומטית, בלי מעורבות התורן. כעבור שבועיים של מדדים יציבים הוצאנו את הגיבוי — השבתה ועלייה בשגיאות במהלך ההעברה לא נרשמו אף פעם.
במה שונה העברה מדורגת ממעבר מלא?
העברה מדורגת — זה מצב שבו שני קווי המתאר עובדים בו-זמנית, והחלק היחסי של התעבורה ביניהם משתנה באופן נשלט. תחילה לקו המתאר החדש עוברת זרימת שירות: בדיקות חיים, משימות רקע, קריאות פנימיות. אחר כך — מ-5 עד 10 אחוזים מבקשות המשתמשים, והלאה בצעדים עד למאה.
תנאי חובה — תאימות קווי המתאר לפי פורמט נתוני הקלט, סכמת תשובת המודל וגרסת האינדקס, אחרת השוואת איכות על מדגם הופכת לרעש.
מעבר מלא מעביר הכל בבת אחת: קו המתאר הקודם מכובה, כל התעבורה הולכת לחדש. נקודת החזרה לאחור כאן היא אחת והיא קיימת רק עד לרגע המעבר — לאחר מכן חזרה פירושה להקים את קו המתאר הישן, לחמם אותו ולהעביר שוב את הזרימה, וזה זמן אי-זמינות של השירות.
בגרסה המדורגת יש נקודות חזרה לאחור כמספר הצעדים. התפלגות התעבורה מתבצעת במאזן עומסים ככלל נפרד, לכן הסרת משקל מקו המתאר החדש מחזירה בקשות בשניות וללא פריסה מחדש.
אותו כלל מאפשר לפצל את הזרימה לפי קבוצות — דיירים או סוגי משימות, ולא 'עשרה אחוזים אקראיים', והאיכות על המדגם נשארת ניתנת לשחזור.
הבחירה מוכתבת על ידי מחיר הטעות. מעבר מלא מוצדק כאשר קווי המתאר אינם תואמים לפי פורמט הנתונים או שההשבתה מסוכמת עם הלקוח. העברה מדורגת נדרשת במקום שבו ליד חיים משתמשים והחזרה לאחור צריכה לארוך דקות, ולא חלון תחזוקה.
אנחנו מנהלים מעבר כזה דרך אורקסטרטור — ב-Kubernetes משקולות משתנים על ידי עריכת מניפסט אחד, בלי פעולות ידניות על השרתים.
ספקות טכניים: אחסון, הרשאות, נתיב חזרה
לפני תחילת המעבר, הצוות הטכני שואל אותן שאלות: היכן הנתונים מאוחסנים, מי רואה סודות, מה קורה עם מודלים מאומנים והאם נשאר נתיב חזרה.
בידוד סביבות — תנאי בסיס: קווי המתאר לפני ואחרי עובדים במקביל ואינם חופפים ברשת ובחשבונות, לכן אפשר להשוות תשובות על אותן בקשות, ולכבות את קו המתאר הישן רק לאחר קבלת כל העומס.
היכן הנתונים מאוחסנים בזמן המעבר?
הנתונים אינם נשלפים לצמתי ביניים: שכפול מתבצע ישירות בין אחסונים ובאופן אינקרמנטלי, לכן בסיס היעד מפגר בדקות. מערכי נתונים רגישים אינם יוצאים מגבולות קו המתאר המוסכם.
איך מועברים סודות ומפתחות גישה?
סודות אינם נשלחים בהתכתבות ואינם מונחים במאגר: הם מועברים דרך אחסון מאובטח, והשירות מקבל אותם בזמן עבודה לפי התפקיד שלו. מפתחות מחולקים לפי סביבות, לכן החלפת סוד אינה דורשת בנייה מחדש.
מה קורה עם מודלים מאומנים?
משקולות, נקודות ביקורת והגדרות מתן תשובות מועברים כארטיפקטים: גרסה אחר גרסה, עם אימות סכומים והרצה על מערך בקשות ייחוס. בפער באיכות, המודל אינו מוחלף — הפער מנותח לפני העברת תעבורה.
האם אפשר לחזור לקו המתאר הקודם?
המעבר חזרה מתוכנן מראש, ולא לפי עובדת תקלה. קו המתאר הישן נשאר פעיל עד סוף תקופת התצפית, עם סנכרון נתונים הפוך; החזרה — זה החלפת מסלול לשעות, ולא פריסה מחדש.
נדון במשימה: נבנה תוכנית העברה והערכה
כדי שתוכנית ההעברה תישען על תמונה אמיתית, ולא על הנחות, מתחילים בנתוני המקור. מסתכלים עליהם בסדר כזה: תחילה קשרים בין שירותים, אחר כך פרופיל עומס, אז דרישות לאחסון נתונים. כך הערכת לוחות הזמנים מתקבלת לפי עובדות, ולא 'בערך'.
מה כדאי לשלוח לפני הדיון במשימה:
- סכמה של קו המתאר הנוכחי: שירותים, מודלים, אחסונים וכיצד הם מקושרים ביניהם;
- פרופיל עומס: כמה בקשות בשיא, איזה חלק מהתשובות ארוך, איזו תגובה נחשבת לנורמה;
- חלונות שבהם השבתה אינה מותרת, ומשך ההפסקה המותר בשאר הזמן;
- רשימת מערכות חיצוניות שפונות לפתרון, והבעלים שלהן בצד הלקוח;
- דרישות האתר היעד: אזור מיקום, כללי אחסון נתונים, מגבלות על הוצאה החוצה;
- הרשאות ותפקידים בשני קווי המתאר, וכן את האחראי שמקבל החלטות לגבי המעבר;
- מה כבר ניסו להעביר ואילו מקומות התבררו כשבירים.
בהמשך נבנה תוכנית העברה: רצף שלבים, נקודות חזרה לאחור, מי עושה מה ובאיזה רגע. נחזור עם הערכת לוחות זמנים ואפשרויות — מהעברה מדורגת עם העברת תעבורה הדרגתית ועד מעבר מהיר עם חלון קצר. תארו את המשימה בצורה נוחה — נתקשר ונגדיר את הצעד הבא.