Gradual rollout: למה "בהדרגה" לא תמיד בטוח
Gradual rollout: למה “בהדרגה” לא תמיד בטוח
אחרי שהבנו ש-Deploy הוא אירוע מסוכן, התגובה האינסטינקטיבית היא לנסות לרכך אותו.
לא לשחרר בבת אחת. לא לזעזע את המערכת. לעשות הכול בהדרגה.
וזו בדיוק הנקודה שבה נוצרת אשליה חדשה.
האשליה: “אם זה הדרגתי - זה בטוח”
Gradual rollout נשמע אחראי:
- אחוז קטן מהמשתמשים
- ניטור צמוד
- אפשרות לעצור בכל רגע
זה מרגיש כמו שליטה.
אבל בפועל, הדרגתי אינו בהכרח עדין - ולעיתים הוא מסוכן יותר משינוי חד.
הבעיה האמיתית: מצבי ביניים
ב-Gradual rollout, המערכת אינה במצב הישן ואינה במצב החדש.
היא נמצאת בין לבין.
ובמצב הזה:
- חלק מהרכיבים פועלים לפי לוגיקה אחת
- חלק לפי לוגיקה אחרת
- והנחות משני הצדדים כבר אינן נכונות
זהו מצב שמערכת כמעט אף פעם לא תוכננה אליו.
חוסר סימטריה הוא אויב שקט
במצב הדרגתי:
- משתמשים שונים חווים התנהגות שונה
- בקשות זהות מקבלות טיפול שונה
- תקלות מופיעות רק “לחלק”
וזה מקשה מאוד על:
- זיהוי בעיות
- שחזור תקלות
- והבנה מה באמת קורה
כשל שאינו אחיד קשה יותר מכשל כולל.
למה partial failure קשה יותר מ-total failure
כשל מלא הוא ברור:
- משהו לא עובד
- כולם נפגעים
- ויש טריגר לפעולה
כשל חלקי:
- נראה כמו רעש
- מתפזר
- ולעיתים נדחק הצידה כ”מקרה קצה”
אבל הוא מסוכן יותר, כי הוא יכול להימשך זמן רב - ולשחוק את המערכת בשקט.
הדרגתי כמכפיל מורכבות
Gradual rollout לא רק מפחית סיכון - הוא גם מגדיל מורכבות:
- צריך לתמוך בשני מצבים
- צריך לוגיקה כפולה
- צריך ניטור מורכב יותר
אם המערכת לא בנויה לכך מראש, ההדרגתיות הופכת למלכודת.
המשל
אפשר לחשוב על מעבר גשר.
סגירה מלאה: ברורה, חדה, לא נעימה - אבל כולם יודעים מה קורה.
פתיחה “חצי-חצי”: נתיב אחד פתוח, אחד סגור, שילוט לא ברור, ועומס לא צפוי.
הרבה תאונות קורות דווקא שם.
השאלה הנכונה
השאלה אינה: “האם לשחרר בהדרגה?”
אלא:
- האם המערכת יודעת לחיות במצב ביניים
- האם מצבי ביניים הם חלק מהתכנון
- ומה המחיר של חוסר סימטריה
Gradual rollout הוא כלי - לא ערובה לבטיחות.
השורה התחתונה
מצב הדרגתי אינו תמיד זהיר. לעיתים הוא פשוט פחות גלוי.
מערכות יציבות:
- בוחרות מתי מצב הדרגתי מתאים
- ומתי שינוי חד דווקא בטוח יותר
לא כי הוא עדין - אלא כי הוא ברור.
מבט קדימה
אחרי Deploy, ואחרי Rollout, נשארת שאלה עמוקה יותר:
מה קורה כשהמערכת כבר משתמשת בממשק שהבטחנו לא לשבור?
בפוסט הבא נצלול להתחייבות הארוכה ביותר בהנדסה: Backward compatibility - ולמה “רק נוסיף שדה” הוא לעיתים התחלה של בעיה גדולה.
📚 פוסטים נוספים בסדרה: כשהמערכת כבר רצה
- חלק 1 Production הוא נקודת האמת של המערכת
- חלק 2 Latency כבעיה ארגונית, לא טכנית
- חלק 3 כשמדדים משקרים
- חלק 4 Deploy הוא אירוע מסוכן
- חלק 6 Backward compatibility כהתחייבות ארוכת טווח
- חלק 7 כשמערכת משקפת מבנה ארגוני
- חלק 8 Incident response הוא תרבות, לא פרוצדורה
- חלק 9 Good Enough Engineering
- חלק 10 Over-engineering ו-Under-engineering: שני צדדים של אותה טעות
- חלק 11 מהנדסים בוגרים לא מחפשים שליטה