בדיקות עשן אוטומטיות לאחר פריסה: הגדרה ומימוש ב-CI/CD

בדיקות עשן אחרי דיפלוי: איפה נשבר הריליס

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

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

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

בדיקות עשן (smoke tests) אחרי דיפלוי הן בדיקה אוטומטית אחרי הריליס: מערך קצר של פניות לנתיבים קריטיים, שרץ מיד אחרי הדיפלוי ולפני פתיחת התעבורה. בהמשך נפרט איך סוגרים את זה — מבחירת הבדיקות ועד rollback אוטומטי של הריליס.

מה נותנת בדיקה אוטומטית אחרי הריליס

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

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

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

צפיות השחרור מפסיקה להיות תלויה במי שמריץ את הריליס: מערך בדיקות אחד, דוח אחד, רף זהה לסביבת הבדיקות ולסביבת העבודה. ההחלטה על rollback מתקבלת על סמך עובדות, לא על סמך תחושה.

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

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

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

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

סדר ההטמעה של הבדיקות בצינור האספקה

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

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

מה נשאר בריפו ובתיעוד

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

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

מקרה בוחן: איך קיצרנו את זמן זיהוי התקלה

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

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

מה שינינו

הרכבנו מערך עשן של 14 תרחישים שעונים על שאלה אחת — האם המוצר חי: זמינות ה-API, הזמנה מקצה לקצה, תשלום בסביבת הבדיקות, מסירת אירועים לתור, התנהגות השירות כש"השכן" לא זמין. הריצה אורכת 2-3 דקות.

את ההפעלה קשרנו לשתי נקודות: מיד אחרי הדיפלוי לסביבת הבדיקות ואחרי שחרור קנרית על 10% מהתעבורה. נפילה של כל שלב עוצרת את הדיפלוי ומפעילה rollback, והתוצאות נשלחות ל-Prometheus — רואים איזה תרחיש התחיל ליפול אחרי שינוי מסוים.

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

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

מה לעשות אם הדיפלוי רץ אבל אין בדיקות?

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

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

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

ספקות טכניים בנוגע לבדיקות עשן

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

באיזו סביבה להריץ את הבדיקות אחרי הדיפלוי?

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

מה לעשות עם נתוני הבדיקה כדי לא לפגוע בנתונים האמיתיים?

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

מי מתחזק את מערך הבדיקות אחרי ההעברה?

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

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

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

מצד הלקוח נדרשים לרוב:

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

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

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