Smoke testing infra: מה נשבר מיד לאחר הפריסה
הפריסה מסתיימת עם קוד אפס, ובעוד עשר דקות חלק מהשירותים אינם מגיבים — תרחיש מוכר. תשתית כקוד מתארת את המצב הרצוי, אך אינה מאשרת שהוא הושג: המודול יצר מאזן עומסים, אך כלל הניתוב לא הגיע, כי המשתנה התברר כריק.
מאחורי זה עומדות שלוש סיבות חוזרות. סביבה חלקית — חלק מהסודות, התעודות ופרמטרי החיבור נותרו מהסביבה הקודמת או לא הוגדרו מחדש. קשרים מקוטעים — השירות עלה, אך אינו רואה את מסד הנתונים, הברוקר או המטמון, כי קבוצת האבטחה או רשומת ה-DNS לא עודכנו. הרשאות שלא הוענקו — התפקיד נוצר, אך מדיניות הגישה לאחסון או לרישום התמונות אינה מקושרת אליו.
קטגוריה נפרדת — בדיקת התצורה, שאינה מופעלת בשום מקום כשלב עצמאי. המודולים מיושמים בהצלחה, אך איש אינו משווה את התוצאה לזו הצפויה: האם הפורטים הנדרשים פתוחים, האם נקודת הקצה של המוכנות מגיבה, האם המיגרציות הוחלו, האם שירותי התלות נגישים ברשת. השגיאה צפה כבר אצל המשתמש, והזמן עד לאבחון נמדד לא בדקות אלא בשעות של תכתובת בין הצוותים.
Smoke testing infra סוגר בדיוק את הפער הזה. מערך קצר של בדיקות לאחר הפריסה מפריד בתוך דקות בין "העלינו" ל"עובד": זמינות הצמתים, קישוריות בין השירותים, הרשאות לפעולות, שלמות התצורה.
הבדיקה רצה מול הסביבה שהועלתה בפועל, ולא מול התיאור במאגר, ולכן תופסת את הפער בין המצב המתוכנן למצב בפועל.
בהמשך נבחן כיצד בדיקה כזו משתלבת בתהליך השחרור, מה בדיוק לכלול בה וכיצד להגדיר נסיגה אוטומטית כשהיא נכשלת.
Smoke testing של הסביבה: מה נותנת האוטומציה של הבדיקות
בדיקות עשן של הסביבה — מערך קצר של בדיקות מיד לאחר ה-provisioning: זמינות הצמתים, פתרון שמות, תגובת מאזן העומסים, כתיבה לאחסון, מעבר תעבורה מכתובת חיצונית עד לאפליקציה. המערך רץ דקות ותופס את התקלה לפני שהמשתמש הראשון נכנס לסביבה.
האוטומציה של הבדיקות מקצרת את זמן השחרור לא באמצעות "האצה" כשלעצמה, אלא באמצעות הסרת הקבלה הידנית. המהנדס אינו עובר יותר על השירותים לפי רשימה — הבדיקות רצות במקביל, והתוצאה עם פסק הדין נכתבת ליומן הבנייה. השחרור מפסיק להמתין לאדם ולהידחות ליום המחרת.
רוב הנסיגות החירום — לא בגלל קוד גרוע, אלא בגלל סביבה לא מוכנה: מיגרציית סכמה שלא הוחלה, סוד חסר, כלל רשת שלא נסגר. מערך העשן בודק בדיוק את האינווריאנטים האלה ומעביר את הנסיגה מ"שמו לב בסביבת העבודה" ל"נפל בבדיקה". שיעור הנסיגות החירום יורד כי חלק מהשינויים אינם מגיעים לשחרור.
השבתת השירות מורכבת מזמן הגילוי ומזמן השחזור, והאוטומציה מכווצת את הראשון עד לרגע ה-provisioning. כשהתשתית מתוארת באופן דקלרטיבי ב-Terraform, הסביבה משוחזרת באמצעות יישום חוזר של התיאור, ולא בהרכבה ידנית מהזיכרון — משך השבתת השירות מפסיק להיות תלוי במי שנמצא בתורנות.
נעלם גם סוג שלם של כשלים הקשור לפערים בין הסביבות: בדיקות בסביבת הביניים ובסביבת היעד מראות את ההבדל בהגדרות לפני השחרור, ולא שבוע לאחריו.
אפשרויות הבדיקה: צ'קליסט ידני, סקריפטים, בקרה רציפה
הבדיקה לאחר הפריסה עונה על שאלה אחת: האם הסביבה עובדת בצורה שבה היא נמסרה. האפשרויות נבדלות לא בעומק, אלא במי שמפעיל את הבדיקה, מתי היא מופעלת וכמה מאמץ נדרש לתחזוקתה. אנחנו משווים אותן בלי לכפות גישה אחת.
| אפשרות | מתי מתאימה | מגבלות | מורכבות |
|---|---|---|---|
| צ'קליסט ידני | סוגי סביבות חדשים ובדיקות שבהן נדרש שיקול דעת: הרשאות גישה, התנהגות מערכות חיצוניות | מדלגים על שלבים בחופזה, התוצאה אינה משוחזרת, ההיסטוריה אינה נשמרת | נמוכה בהתחלה, גדלה עם מספר הסביבות |
| סקריפטים לבדיקות | פריסות סדירות של עמדות אחידות, ליבת בדיקות חוזרת | נשברים עם שינוי בסביבה, מכסים רק תרחישים שתוארו מראש | בינונית, נדרש בעלים |
| בקרה רציפה | סביבות ארוכות-טווח שבהן חשוב לשים לב להידרדרות בין מהדורות | מאשרת את המצב, אך לא את תקינותה של המהדורה החדשה; נדרשים ספים וערוץ התראות | גדלה עם מספר המדדים |
בפועל האפשרויות אינן מתחרות זו בזו אלא משלימות זו את זו: הסקריפטים מכסים את הליבה החוזרת, הצ'קליסט נשאר לדברים הדורשים שיקול דעת, והבקרה הרציפה שומרת בין המהדורות.
המגבלה העיקרית היא התיישנות: בדיקות הקשורות לטופולוגיה מסוימת מפסיקות להיות נכונות אחרי השינוי הראשון בסביבה, ולכן הסקירה שלהן נכללת בתקנון. הבחירה נקבעת לפי תדירות הפריסות ומספר הסביבות: ככל שהן רבות יותר, כך מוקדם יותר הצ'קליסט הידני מפסיק להתרחב.
שלבי היישום: מביקורת הסביבה ועד למסירת התקנונים
הסביבה לאחר ה-provisioning מוכנה פורמלית, אך עד לפריסה הראשונה איש אינו בודק אם השירותים מגיבים, אם המיגרציות מוחלות ואם העמדה שורדת הפעלה מחדש של צומת. את העבודה מסדרים כך שהבדיקות יופיעו לפני המהדורה הראשונה, ושהתראות השווא ייתפסו על עותק ולא בסביבת הייצור.
- ביקורת הסביבה — מיפוי מלאי של השירותים, הקשרים ביניהם, הפורטים והאינטגרציות החיצוניות. בפלט: מפה של מה שיש היגיון לבדוק, ורשימה של כשלים שכבר אירעו.
- תרשים הבדיקות — מחלקים את התרחישים למהירים ולעמוקים: קישוריות, זמינות שירותים, קריאה וכתיבה לאחסון, מיגרציות, שחזור לאחר הפעלה מחדש של צומת. עבור כל אחד קובעים קריטריון "עבר".
- הגדרת הבדיקות — מעבירים את התרשים לאוטומציה הקיימת ומקשרים אותו לאירועי ה-provisioning. הבדיקות אינן מחליפות ניטור: הן עונות על השאלה אם אפשר להעביר את הסביבה הלאה.
- הרצה על עמדה כפולה — פורסים עותק של טופולוגיית הייצור, מודדים את זמן ההרצה המלא ואת ההתנהגות בנפילת צומת. כאן גם קובעים את זמן ההמתנה המקסימלי לתגובה ואת מספר החזרות.
- טיפול בהתראות שווא — מפרידים בין הידרדרות לרעש: שירותים שעדיין לא התייצבו, מרוצי תנאים בעת העלייה, אי-זמינות זמנית של תלות חיצונית. נקודת ייחוס — אפס הרצות אדומות בסביבה בריאה.
- מסירת התקנונים — מתארים את הפעולות בעת נפילת בדיקה, את הבעלים של כל תרחיש ואת סדר ההרחבה של המערך עם הוספת שירותים חדשים.
מערכי בדיקות, תרשימי סביבות ותקנוני שחרור
הבדיקות נשמרות לא בתכתובת אלא במאגר לצד תיאור התשתית. המערכים מופעלים מיד לאחר ה-provisioning: ידנית בעת ניתוח תקלה ובאופן אוטומטי בצינור השחרור — כשער חובה לפני העברת העמדה לצוותי הפיתוח.
כל פריט באספקה מתואר בתיעוד הבדיקות: מה בדיוק נבדק, איזה מצב נחשב לתקין, מה לעשות בעת פער ולמי לפנות לקבלת הרשאות. המערכים מנוהלים בגרסאות יחד עם תרשימי הסביבות — כאשר הרכב הצמתים משתנה, רואים אילו בדיקות התיישנו, ונסיגת כללים אינה שוברת עמדות שכבר עובדות.
- מערכי בדיקות ברמת הבסיס: זמינות הצמתים, פתרון שמות, תגובת מאזן העומסים, מוכנות האחסון.
- בדיקות שכבת היישום: תגובת השירותים, תורי ההודעות, הרשאות חשבונות השירות, גישה לסודות.
- תרשימי סביבות: הרכב הצמתים, רשתות ותת-רשתות, איזון עומסים, קשרים בין שירותים למערכות חיצוניות.
- תקנון השחרור: שלבים מה-provisioning ועד למסירה לתפעול, נקודות עצירה וקריטריונים למוכנות העמדה.
- כללי גישה: הפרדת תפקידים בין מהנדסים לחשבונות שירות, סדר הענקה ושלילת הרשאות, ביקורת פעולות.
- תיעוד הבדיקות: ייעוד המערך, תוצאות צפויות, ניתוח פערים אופייניים, סדר הפעולות בעת תקלה.
- ניהול גרסאות של הבדיקות: היסטוריית שינויים, קישור לגרסת תרשים הסביבה, סימון מערכים מיושנים.
מקרה בוחן: צמצמנו את שיעור השחרורים החירום לאחר הפריסה
נקודת המוצא
פריסה לאשכול Kubernetes הסתיימה בסטטוס ירוק של הצינור, אך לא означаה שהשירות באמת עובד: 18% מהשחרורים נסוגו בשעות הראשונות. הסיבות חזרו על עצמן — מיגרציית סכמה שלא הוחלה, תלות לא זמינה, סוד שגוי בתצורה.
האבחון ארך בין 40 ל-60 דקות: המהנדס השווה ידנית אירועי אשכול, לוגים ומשתני סביבה, ובשחרורים ליליים הבדיקות נעשו לפי רשימה מצומצמת.
מה שינינו ומה קיבלנו
הבדיקות הפכו לשלב חובה לאחר ה-provisioning ולפני העברת התעבורה: זמינות נקודות הקצה, מוכנות הפודים, תגובות שירותי התלות, החלת מיגרציות, הרשאות חשבונות השירות. ההרצה אורכת 90–120 שניות, ובנפילה התעבורה נשארת במהדורה הקודמת — הנסיגה הפסיקה להיות פעולה ידנית. התראות שווא נחסמות על ידי המתנה למוכנות הפוד למשך זמן מוגדר, ולא על ידי נפילה בבקשה הראשונה.
שיעור הנסיגות ירד מ-18% ל-3%, וזמן השחזור — מ-50 דקות ל-7. השחרורים החירום מחוץ לחלון התקנוני פחתו כמעט פי שלושה: סיבת התקלה נראית בדוח ההרצה, ולא משוחזרת מהלוגים בדיעבד. מערך הבדיקות מנוהל בגרסאות יחד עם קוד התשתית, ולכן שירות חדש מקבל אותן כבר עם הוספתו, ולא אחרי האירוע הראשון.
במה נבדלות בדיקות העשן מרגרסיה מלאה של הסביבה?
בדיקת עשן עונה על שאלה אחת: אפשר להעביר תעבורה לסביבה הזו ממש עכשיו. הכיסוי — 15-25 בדיקות שעוברות בתוך דקות: האם מאזן העומסים עלה, האם האפליקציה מגיבה, האם מסד הנתונים, התורים, ה-DNS והתעודות זמינים, האם הכניסה ויצירת ישות בדיקה עוברות מקצה לקצה. כל השאר עבורה הוא רעש — היא אינה מחפשת שגיאות בלוגיקה העסקית, היא מאשרת חיוניות.
רגרסיה מלאה בודקת התנהגות: מאות תרחישים בכל הענפים המשמעותיים, כולל שילובים נדירים של תפקידים, הרשאות ומצבי נתונים. היא רצה שעות, דורשת מערך נתונים מוכן וסביבה יציבה, ותוצאתה — פסק דין "הפונקציונליות לא נשברה", ולא "הסביבה נושמת".
הגבול עובר לפי אובייקט הבדיקה: העשן מסתכל על התשתית ועל הקישוריות בין הרכיבים, הרגרסיה — על הלוגיקה היישומית. הראשון נותן תשובה בינארית בדקות, השני — דוח מפורט בשעות. אם העשן מתחיל לענות על "האם הכול עובד נכון", הוא מפסיק להיות מהיר והופך לרגרסיה מצומצמת.
לערבב ביניהם מסוכן לשני הכיוונים. עשן מנופח רץ עשרות דקות, תרחישים לא יציבים חודרים אליו, והצוות מתרגל לפרסם מעל תוצאה אדומה. החלפת הרגרסיה בעשן נותנת אפקט הפוך: הפרסום עובר בירוק, והפגמים צפים אצל המשתמשים, כי נבדקה קישוריות ולא התנהגות.
ההפרדה המעשית פשוטה: עשן — מחסום חובה בצינור הפרסום, שחוסם את מעבר התעבורה לגרסה החדשה; רגרסיה — לפי לוח זמנים או לפני שינוי גדול. גם קריטריוני המוכנות שלהם שונים, ובדיוק משום כך מחזיקים אותם כמערכים נפרדים.
בירור ספקות: כיסוי הבדיקות והתראות לא יציבות
כיסוי הבדיקות נקבע לא לפי מספרן אלא לפי רשימת נתיבי הכשל. לאחר ה-provisioning אנו בודקים לא רק "הצומת עלה", אלא גם קישוריות בין הסגמנטים, תגובת מאזן העומסים, הרשאות חשבון השירות, זמינות האחסון ותקינות רשומות ה-DNS. כך פגם תצורה צף לפני הפריסה הראשונה של האפליקציה, ולא ברגע שבו כבר עושים בה שימוש.
התראות לא יציבות מתקנים לפי הסיבה ולא לפי התעלמות: המתנה למוכנות באמצעות סקר מצב במקום השהיות קבועות, חזרות נפרדות עבור "התשתית עוד עולה" ועבור שגיאה אמיתית, בידוד הבדיקות זו מזו. בדיקה שנופלת לפעמים בלי סיבה גרועה מהיעדרה — הצוות מפסיק להאמין לה ומפספס נפילה אמיתית.
האם הכיסוי יספיק אם חלק מהסביבות נפרס ידנית?
עבור קטעים כאלה אנחנו קובעים נקודות ביקורת מבחוץ: זמינות הכתובות, תגובת השירותים, מצב התורים והתזמונים. שלבים ידניים מכניסים לתקנון, כך שבעת המסירה רואים היכן לצפות לפערים.
כיצד להבחין בין התראת שווא לתקלה אמיתית?
כל בדיקה כותבת למה בדיוק המתינה ומה לא הגיע: קוד התגובה, צומת היעד, משך ההמתנה. לפי העקבות האלה רואים אם מדובר בהידרדרות או שהבדיקה נגעה ברכיב שעוד לא מוכן. בדיקות מוכנות ב-Kubernetes בונים על סטטוסים של אובייקטים, ולא על השהיות.
מה קורה עם התמיכה במערך הבדיקות לאחר המסירה?
מוסרים אותו יחד עם התקנון: אילו בדיקות הן חובה לפני הפרסום, כיצד לחבר סביבה חדשה, היכן לראות את היסטוריית ההרצות. בתקופה הראשונה מלווים בעצמנו — מתקנים ספים ומוסיפים תרחישים בהתאם לשינויים בתשתית, ובהמשך את המערך מוביל צוות הלקוח.
נדון במשימה שלכם ונחזור עם תוכנית בדיקות
כדי לחזור עם הערכה ותוכנית בדיקות, ולא עם מילים כלליות, נדרשים מאיתנו שלושה דברים מכם: תיאור הסביבה (ענן, שרתים עצמאיים או סכמה משולבת), שיטת ה-provisioning הנוכחית ורשימת האירועים שכבר תפסתם ידנית. אם יש לוגים של הפרסום והתצורה — צרפו אותם, זה מספיק כדי לראות את נקודות הכשל בלי תשאול ממושך.
בהמשך עובדים בשני סבבים: תחילה מנתחים את הסביבה ומרכיבים את רשימת הבדיקות, ואחר כך מתאמים את ההיקף. חוזרים עם חבילה:
- מפת תשתית עם המקומות שבהם כשל עובר מבלי ששמים לב עד לפרודקשן;
- הרכב הבדיקות לאחר ה-provisioning: זמינות השירותים, מצב התלויות, תקינות ההרשאות ומשתני הסביבה, ההתנהגות בעת הפעלה מחדש של צומת;
- תרשים השתלבות בצינור האספקה: אילו בדיקות חוסמות את הפרסום ואילו רק מאותתות לתורן;
- דרישות לגישות ולסביבות בדיקה שבהן מריצים את הבדיקות;
- הערכת העבודה לפי שלבים עם חלוקה: מה אנחנו מכסים ומה נשאר בצד שלכם;
- לוחות זמנים ליישום — מתיאום ההרכב ועד להרצות הראשונות בסביבת הייצור ומסירת התיעוד.
תארו את המשימה בצורה חופשית: איזו סביבה, במה היא נפרסת, מה כבר נשבר. נחזור עם הערכה, תוכנית בדיקות ולוחות זמנים ליישום.