החזרה אוטומטית לגרסה קודמת בעת פריסה כושלת ב-Kubernetes

רולבק אוטומטי: היכן נשבר הדיפלוי ב-Kubernetes

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

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

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

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

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

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

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

מה משתנה לאחר הטמעת החזרות לאחור מנוהלות

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

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

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

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

אסטרטגיות דיפלוי ורגע הפעלת הרולבק

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

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

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

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

הטמעת רולבק אוטומטי: שישה שלבים

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

1. מאינווטריזציה של דיפלויים. מאחדים את כל הנתיבים שבהם קוד מגיע לפרודקשן: קווי בנייה, תיקונים ידניים, משימות מתוזמנות. כל מה שלא משאיר עקבות לחזרה לאחור — או שסוגרים, או שמתכננים כסעיף נפרד.
2. הגדרת אותות תקלה. מסכימים מה נחשב לדיפלוי כושל: כישלון בדיקת מוכנות, עלייה בשיעור השגיאות, אי-עמידה בעומס המתוכנן. לכל אות יש סף וזמן השהיה — אחרת הרולבק מתעורר בתנודות שגרתיות.
3. אחסון גרסאות קודמות. קובעים עד כמה מהדורות אחורה זמינה החזרה לאחור, היכן נמצאים האימג'ים והמניפסטים הקודמים, ובכמה זמן הגרסה חוזרת לפעולה.
4. הגדרת החזרות לאחור. את הכללים רושמים בתוך הדיפלוי עצמו: איזה אות מפעיל את החזרה, מי מקבל התראה, מה קורה עם התעבורה ומיגרציות הנתונים. שינויים בלתי תואמים בסכימה מטפלים בנפרד — אין מרפאים אותם בהחזרה לאחור.
5. בדיקת מוכנות. מתרגלים החזרה לאחור בסביבת בדיקות: מפילים מהדורה באופן מלאכותי, מודדים את זמן החזרה, משווים את מצב השירות והנתונים לקודם. כך נבדקים גם הספים וגם היעדר הפעלות שווא.
6. הרצה בפרודקשן. מפעילים את האוטומציה תחילה על שירות אחד עם תחום השפעה צר, אחר כך מרחיבים ומנהלים יומן הפעלות.
7. מסירה לתפעול. למשמרת התורנית עובר נוהל: סדר הניתוח של כל החזרה לאחור, נקודות בקרה וכללי תיקון הספים.

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

מה נשאר באשכול ובמאגר לאחר העבודה

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

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

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

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

מה היה: החזרה לאחור לפי שיחה

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

מה שינו ומה נהיה

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

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

במה שונה החזרה לאחור לפי מדדים מהחזרה לאחור לפי אימג'?

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

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

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

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

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

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

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

ספקות טכניים נפוצים לפני הטמעה

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

האוטומציה לא תתחיל להחזיר מהדורה לאחור סתם כך?

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

מה לעשות אם החזרה לאחור בוצעה, אבל סיבת התקלה נשארה?

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

האם ניתן להחזיר לאחור לא את כל המהדורה, אלא קבוצה אחת?

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

איך זה קשור לגישות והרשאות?

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

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

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

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

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