הגדרת הנדסת כאוס באמצעות Gremlin ב-Kubernetes

Chaos Engineering Gremlin: כשלים שלא קיימים בבדיקות

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

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

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

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

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

מה נותנת בדיקת עמידות מבוקרת

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

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

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

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

מצבי ניסוי: השוואת גישות ומגבלות

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

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

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

שלבי יישום: מהערכה ועד מסירת נהלים

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

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

חפצי יישום: מניפסטים, מדיניות, נהלים

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

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

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

מקרה בוחן: כיצד הסרנו סוג שלם של כשלי תורים

מה היה לפני הניסוי

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

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

מה שינו במסגרת מקרה היישום

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

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

מדדים לפני ואחרי

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

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

Gremlin ובדיקות עומס: מה ההבדל?

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

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

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

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

ספקות טכניים לפני תחילת הניסוי

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

איך הניסוי משפיע על מעגל העבודה?

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

האם חובה סביבה נפרדת?

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

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

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

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

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