הגדרת הנדסת כאוס באמצעות Chaos Mesh

Chaos Engineering: מדוע כשל מתגלה בפרודקשן

שירות עולה לפרודקשן לאחר שעבר בדיקות עומס ונראה בריא: הצמתים חיים, המדדים יציבים, ההתראות שותקות. אבל קשרים בין רכיבים כמעט никогда לא נבדקים לכשל — לקוח אל תור בלי הגבלת ניסיונות חוזרים, מאגר חיבורים משותף לכמה תלויות, קריאה סינכרונית באמצע תרחיש קריטי. כל קשר כזה נשאר תלות לא נבדקת, ועד הכשל הראשון מתנהג כאמין.

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

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

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

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

כשלים מבוקרים: מה משתנה בתפעול

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

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

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

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

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

Chaos Engineering: מצבי ניסוי ומגבלות

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

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

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

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

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

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

מה נשאר במאגר שלכם לאחר העבודות

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

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

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

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

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

מה שינינו

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

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

לפני היישום, בבידוד אזור, שיעור התגובות המוצלחות ירד ל-60%, המעבר ארך דקות, וההתאוששות דרשה התערבות ידנית.

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

מה לעשות אם האשכול כבר עובד תחת עומס

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

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

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

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

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

מגבלות השיטה וספקות טכניים

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

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

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

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

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

נדון במשימה: ממה מתחילה הבדיקה

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

אחר כך נחזור עם הערכה ותוכנית. הם כוללים:

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

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