AI Blue-Green Deployment: מעבר בטוח בין תשתיות AI שלמות

מאת צוות מדיה דיל · 07.08.2026 · Enterprise AI · 7 דק׳

כשהשינוי גדול מכדי לחלק בהדרגה - מעבר ספק מודל, שדרוג תשתית Retrieval - Blue-Green הוא הדרך לבדוק סביבה שלמה חדשה לפני שהיא נוגעת במשתמש אמיתי.

יש רגעים בחיי מערכת AI ארגונית שבהם אי אפשר לעשות שינוי הדרגתי - מעבר לספק מודל אחר לגמרי, שדרוג גרסת ה-SDK שמנהל את כל שכבת ה-tool-calling, או שינוי מבני עמוק בארכיטקטורת ה-Retrieval. שינויים כאלה קשה מאוד להריץ באופן חלקי דרך Canary, כי הם נוגעים בתשתית שלמה ולא ברכיב בודד שניתן להפעיל או לכבות בעדינות. עבור המקרים האלה קיים דפוס משלים: Blue-Green Deployment - בניית סביבת production שנייה, מלאה וזהה במבנה לסביבה הקיימת, הרצת הגרסה החדשה עליה במלואה, ובדיקתה עד כדי ביטחון מלא, ורק אז החלפת התעבורה כולה בבת אחת מהסביבה הישנה (Blue) לחדשה (Green) - עם יכולת לחזור לאחור באותה מהירות בדיוק אם משהו משתבש.

ההבדל המהותי בין Canary ל-Blue-Green

שני הדפוסים נועדו למזער סיכון, אך הם פותרים בעיות שונות. Canary, כפי שנדון במאמר על AI Canary Releases, מתאים כששני העולמות - הישן והחדש - יכולים לרוץ זה לצד זה חלקית, תוך שיתוף תשתית בסיסית. Blue-Green מתאים כשהשינוי כל כך עמוק שאי אפשר להפעיל אותו רק על חלק מהתעבורה בלי לשכפל את כל סביבת ההרצה - למשל מעבר ל-vector database אחר לגמרי, שבו אי אפשר "לחלק" משתמשים בין שני מסדי נתונים שונים בלי לסכן עקביות. הבחירה בין השניים היא בעצם שאלה של יכולת בידוד: אם אפשר לבודד את השינוי לרכיב יחיד, Canary עדיף כי הוא חושף פחות תעבורה לסיכון; אם השינוי נוגע בכל הערימה, Blue-Green הוא הדרך הבטוחה יותר.

אנטומיה של סביבת Green

סביבת Green חייבת להיות שכפול מלא ועצמאי של Blue - כולל כל שכבות ה-Agent: המודל, הפרומפטים, ה-Tools, ה-Retrieval pipeline, וכל תלות חיצונית. חשוב במיוחד שהיא תהיה מבודדת מבחינת state: אם ה-Agent שומר זיכרון שיחה, cache, או אינדקס וקטורי, לכל אחד מהם צריך עותק עצמאי משלו בסביבת Green, ולא שיתוף עם Blue - שיתוף state בין הסביבות הורס את כל הרעיון של בידוד, כי שינוי בסביבה אחת יכול לזלוג ולהשפיע על השנייה בדרכים לא צפויות. בניית הסביבה השנייה במלואה יקרה יותר מ-Canary פשוט, אבל היא נותנת ביטחון גבוה בהרבה שהמעבר יעבוד כמצופה, כי הוא נבדק במלואו לפני שהוא נוגע במשתמש אמיתי.

{
  "deployment": "vector-db-migration",
  "blue": { "env": "prod-a", "status": "live", "traffic_pct": 100 },
  "green": { "env": "prod-b", "status": "validating", "traffic_pct": 0 },
  "validation_checklist": {
    "shadow_traffic_replay": "passed",
    "eval_suite_score": 0.96,
    "load_test": "passed"
  },
  "cutover_planned": "2026-08-10T02:00:00Z"
}

Shadow Traffic: הבדיקה החשובה ביותר לפני Cutover

לפני שמעבירים תעבורה אמיתית לסביבת Green, השיטה היעילה ביותר לבדוק אותה היא Shadow Traffic - שכפול בקשות אמיתיות מ-production ושליחתן גם לסביבת Green, במקביל להרצתן הרגילה ב-Blue, בלי שהתשובה מ-Green בכלל מוחזרת למשתמש. כך אפשר להשוות תשובות אמיתיות בין שתי הסביבות על אותם קלטים בדיוק, ולזהות פערים לפני שאף משתמש אמיתי נחשף לסביבה החדשה כלל. שיטה זו חושפת בעיות רבות שבדיקות מלאכותיות מפספסות, כי היא משתמשת בהתפלגות האמיתית של בקשות המשתמשים - כולל מקרי קצה נדירים שקשה לחשוב עליהם מראש בבדיקה ידנית.

רגע ה-Cutover: החלפה אטומית

ה-Cutover עצמו - החלפת התעבורה כולה מ-Blue ל-Green - צריך להיות פעולה אטומית ומהירה ככל האפשר, לרוב על ידי שינוי הגדרת load balancer או DNS, ולא על ידי כיבוי הדרגתי של Blue. הסיבה היא שרוצים שהמעבר יהיה הפיך באותה מהירות בדיוק שבה הוא בוצע - אם מתגלה בעיה מיד אחרי ה-cutover, צריך להיות אפשר לחזור ל-Blue תוך שניות, לא דקות. בזמן שה-Green מקבל את כל התעבורה, Blue נשאר חי וזמין (לא נכבה) למשך תקופת חסד - לרוב כמה שעות עד יום - בדיוק בשביל תרחיש ה-rollback הזה.

כדאי גם לתזמן את ה-cutover בשעות שפל תעבורה מכוונת, לא כי הסיכון קטן יותר אז, אלא כי אם כן נדרש rollback, מספר המשתמשים שנפגעו קטן יותר, וזמן התגובה של הצוות התורן פנוי יותר לטפל בבעיה בלי לחץ נוסף. בארגונים גלובליים עם משתמשים בכמה אזורי זמן, אין באמת "שעת שפל" מוחלטת, ולכן שם דווקא Canary מבוזר לפי אזור עשוי להתאים יותר, כשה-cutover המלא של Blue-Green מבוצע בשלבים לפי אזור גאוגרפי במקום בבת אחת גלובלית.

עלות כפולה כתופעת לוואי מקובלת

יש לקבל את זה מראש: Blue-Green דורש להריץ שתי סביבות מלאות במקביל, גם אם רק אחת מהן משרתת תעבורה אמיתית - וזה אומר כפל עלות תשתית, לפחות לתקופה הקצרה של המעבר. עבור מערכות AI, זה אומר גם כפל quota אצל ספק המודל, ולעיתים כפל עלות אינדוקס מחדש של מסד וקטורי שלם. תכנון תקציבי מראש למעבר, כולל הבנה שהעלות הכפולה זמנית ומוצדקת בהחלט לעומת עלות של תקרית production כושלת, הוא חלק בלתי נפרד מהחלטת Blue-Green - ולא הפתעה שמתגלה רק כשהחשבונית מגיעה.

מתי Blue-Green עדיף על שדרוג הדרגתי

הכלל הפרקטי הוא: אם השינוי ניתן לבידוד ברמת בקשה בודדת (פרומפט, גרסת מודל בודדת), Canary עדיף כי הוא זול וגמיש יותר. אם השינוי נוגע בתשתית משותפת שאי אפשר לפצל בין שני מצבים בו-זמנית - כמו מעבר לפורמט אינדוקס חדש לגמרי, או שדרוג ספריית core שמשפיעה על כל הקריאות - Blue-Green הוא הדרך הבטוחה היחידה. ארגונים בוגרים לא בוחרים אחד לנצח; הם משתמשים בכל דפוס לפי סוג השינוי הספציפי שעומד על הפרק, ולעיתים אף משלבים - Blue-Green להקמת התשתית החדשה, ו-Canary לשליטה על קצב המעבר בתוכה.

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

טעויות נפוצות בפרודקשן

הטעות הראשונה היא לשתף משאבי state בין Blue ל-Green "כדי לחסוך עלות", מה שהורס את הבידוד ויוצר תלות מסוכנת בין הסביבות. השנייה היא לכבות את Blue מיד אחרי ה-cutover במקום להשאיר אותו חי לתקופת חסד - כך מאבדים את יכולת ה-rollback המיידי בדיוק ברגע שהיא הכי נחוצה. השלישית היא לדלג על שלב ה-Shadow Traffic מתוך לחץ זמנים, ולגלות פערים בין הסביבות רק אחרי שכל התעבורה כבר עברה לסביבה החדשה.

ניטור מיוחד בזמן חפיפה בין הסביבות

בזמן שגם Blue וגם Green חיים במקביל, כלי הניטור צריכים להבחין ביניהם בבירור בכל דשבורד ובכל alert, אחרת קשה מאוד לדעת אם התראה מסוימת מגיעה מהסביבה הישנה היציבה או מהסביבה החדשה שעדיין בבדיקה. תיוג מפורש של כל metric, log ו-trace עם שם הסביבה (blue או green) הוא דרישת מינימום, וכדאי גם להגדיר מראש dashboards נפרדים לכל סביבה כדי שצוות ה-oncall לא יצטרך לסנן ידנית באמצע תקרית לחוצה. חוסר הבחנה כזה הוא מקור נפוץ לבלבול בדיוק ברגע שהכי צריך בהירות.

מומלץ גם להגדיר מראש קריטריון ברור ליציאה משלב ה-validation לשלב ה-cutover, במקום להשאיר את זה כהחלטה אינטואיטיבית של מי שנמצא במשמרת. קריטריון כתוב - למשל "כל בדיקות ה-Shadow Traffic עברו במשך 48 שעות רצופות, וציון ה-Evaluation לא ירד מתחת לבייסליין" - מונע החלטות שרירותיות תחת לחץ, ומאפשר לכל אחד בצוות, לא רק למי שהוביל את הפרויקט, להחליט בביטחון מתי הסביבה החדשה מוכנה.

תיעוד ולמידה אחרי כל Blue-Green

כל מעבר Blue-Green הוא הזדמנות ללמידה ארגונית - הוא מתרחש לרוב פעם בכמה חודשים, ולכן קל לשכוח פרטים חשובים עד הפעם הבאה. תיעוד קפדני של כל שלב, כולל בעיות שהתגלו בשלב ה-Shadow Traffic ואיך טופלו, בונה ספר הפעלה (runbook) שהופך כל מעבר עוקב לפשוט יותר מקודמו. ארגונים שמזניחים את התיעוד הזה נוטים "לגלות מחדש" את אותן בעיות בכל מעבר גדול, כי הידע חי רק בזיכרון של האנשים הספציפיים שהיו מעורבים בפעם הקודמת - ואם הם עזבו את הצוות, הידע פשוט נעלם.

קשר לניהול גרסאות מודל

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

תרגול Rollback לפני שהוא נדרש באמת

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

סיכום

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

תגיות: Blue-Green Deployment · AI Deployment · Shadow Traffic · MLOps · Enterprise AI · Canary Release · Rollback

← חזרה לבלוג · צור קשר