Deploy הוא אירוע מסוכן

אחרי שמבינים ש-Latency נולדת מהחלטות, וש-Metrics יכולים להרגיע גם כשצריך להילחץ - מגיע הרגע שבו מנסים “לתקן”.

ואז עושים Deploy.

האשליה: “זה שינוי קטן”

Deploy נתפס כפעולה טכנית:

• העלינו גרסה
• הוספנו שדה
• תיקנו באג נקודתי

השינוי נראה מינורי. הסיכון - זניח.

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

למה Deploy מסוכן מעצם טבעו

Deploy אינו רק שינוי קוד. הוא שינוי של מצב המערכת.

ב-Deploy משתנים בו-זמנית:

• קוד שרץ
• תזמון
• אינטראקציות בין רכיבים
• והנחות נסתרות שנבנו לאורך זמן

גם אם הקוד “נכון” - ההקשר שבו הוא רץ השתנה.

למה Deploys שוברים יותר ממה שנדמה

רוב השבירות אינן נובעות מ-bug ישיר.

הן נובעות מ:

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

Deploy קטן יכול:

• להזיז Bottleneck
• להפעיל קוד שלא רץ קודם
• או לחשוף תלות שלא הייתה מורגשת

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

Rollback הוא אשליה מנחמת

“אם תהיה בעיה - נעשה rollback”.

זה נשמע אחראי. זה מרגיש בטוח.

אבל בפרודקשן:

• המערכת כבר ראתה את השינוי
• נתונים כבר נכתבו
• תורים כבר התמלאו
• ולקוחות כבר הגיבו

Rollback מחזיר קוד - לא מחזיר מצב.

הוא מקל, אבל כמעט אף פעם לא מוחק את ההשפעה.

שינוי כשרשרת תגובות

Deploy אינו אירוע נקודתי. הוא התחלה של שרשרת.

שינוי קטן:

• מזיז Latency
• משנה דפוסי שימוש
• מפעיל Retries
• ויוצר עומס משני

התגובה לשינוי יכולה להיות גדולה מהשינוי עצמו.

זו הסיבה ש-Deploys מסוכנים: לא בגלל מה שתכננת - אלא בגלל מה שלא צפית.

המשל

אפשר לחשוב על שינוי קטן בנהר.

הזזת אבן אחת:

• משנה זרימה
• מזיזה סחף
• ופותחת נתיב חדש

האבן קטנה. ההשפעה - לא.

השורה התחתונה

Deploy אינו רגע טכני. הוא אירוע מערכתי.

מערכות יציבות אינן שואלות: “האם הקוד נכון?”

הן שואלות:

• מה עוד זה משנה
• איפה זה עלול להגביר עומס
• ואיך נזהה בעיה מוקדם

שינוי קטן בפרודקשן אינו דבר קטן.

מבט קדימה

מתוך הפחד מ-Deploy חד, נולד פתרון שנשמע בטוח יותר:

לעשות הכול בהדרגה.

אבל “בהדרגה” אינו תמיד עדין - ולעיתים הוא מסוכן יותר משינוי חד.

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