Chaos Engineering: איך שוברים את המערכת שלכם בכוונה כדי שהיא לא תישבר לבד

מאת צוות מדיה דיל · 02.08.2026 · DevOps · 7 דק׳

מדריך מלא ל-Chaos Engineering בפרודקשן: עקרונות, כלים (Chaos Monkey, Gremlin, Litmus), Game Days, ואיך בונים תוכנית ניסויים שלא הופכת לאסון אמיתי.

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

כל ארכיטקט טוען שהמערכת שלו "resilient" — יש retries, יש circuit breakers, יש multi-AZ. אבל עד שלא ניתקתם בכוונה instance באמצע שעת עומס, זו רק השערה. Chaos Engineering הוא המשמעת ההנדסית של בדיקת השערות אמינות בפרודקשן (או בסביבה קרובה מאוד לפרודקשן), במקום להניח שהן נכונות. הרעיון נולד ב-Netflix עם Chaos Monkey ב-2011, ומאז התפתח לדיסציפלינה מלאה עם כלים, מתודולוגיה, ואפילו standard מוסכם (Principles of Chaos Engineering).

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

המתודולוגיה: Steady State, Hypothesis, Blast Radius

כל ניסוי chaos בנוי מארבעה שלבים:

  • הגדרת Steady State — מטריקה מדידה שמייצגת "המערכת בריאה" (למשל p99 latency, error rate, throughput). בלי baseline ברור אי אפשר לדעת אם הניסוי "שבר" משהו.
  • גיבוש Hypothesis — "אם node אחד ב-DB cluster ייפול, ה-steady state לא ישתנה כי יש failover אוטומטי תוך 10 שניות".
  • הזרקת Fault מבוקרת — מנתקים instance, מוסיפים latency מלאכותי, גורמים ל-packet loss, או "הורגים" pod.
  • מדידת התוצאה והשוואה להשערה — אם ה-steady state נשמר, ההשערה אושרה. אם לא — מצאתם bug אמיתי לפני שהלקוחות מצאו אותו.

מושג קריטי נוסף הוא Blast Radius — כמה מהמערכת יכול הניסוי לפגוע בו אם ההשערה שגויה. ניסוי ראשון תמיד מתחיל ב-blast radius מינימלי (סביבת staging, או פרודקשן על 1% מהתעבורה עם kill switch מוכן), ורק אחרי שהוא עובר, מרחיבים בהדרגה.

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

  • Chaos Monkey / Chaos Kong (Netflix) — כיבוי אקראי של instances (Monkey) ואפילו regions שלמים (Kong). מקור ההשראה לכל הכלים שבאו אחריו.
  • Gremlin — SaaS מסחרי עם UI לניהול ניסויים, blast radius controls, ו-"halt button" מיידי — הכלי הפופולרי ביותר בארגונים גדולים בזכות ה-safety controls.
  • LitmusChaos — open source, native ל-Kubernetes, מריץ ChaosExperiments כ-CRDs — מתאים לצוותים שכבר חיים ב-K8s ורוצים chaos-as-code.
  • AWS Fault Injection Simulator (FIS) — שירות מנוהל של AWS להזרקת תקלות ברמת EC2/ECS/RDS, עם אינטגרציה טבעית ל-CloudWatch alarms כ-stop condition.
  • Toxiproxy — proxy קליל להזרקת latency/timeouts/connection resets ברמת רשת, שימושי בעיקר בבדיקות אינטגרציה ו-CI, לא רק בפרודקשן.

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

סוגי ניסויים נפוצים

ניסויי chaos מתחלקים בגדול לכמה קטגוריות: Resource (CPU/memory pressure מלאכותי), Network (latency, packet loss, DNS failure, partition בין services — chaos ברמת רשת חושף בעיקר בעיות timeout config שגויות), State (כיבוי node ב-DB, ניתוק replica), ו-Application (הרג process ספציפי, throw exception מכוון בקוד). הניסוי הכי בעל ערך ברוב הארגונים הוא דווקא Dependency Failure — מדמים שsservice חיצוני (payment gateway, third-party API) לא זמין, ובודקים אם יש fallback הגיוני או שהכול קורס.

Game Days: chaos כתרגיל ארגוני

מעבר לניסויים אוטומטיים ברקע, ארגונים בוגרים מריצים Game Days — אירוע מתוזמן שבו כל הצוות (כולל on-call, IC, אפילו נציגי מוצר) מתרגל תגובה לאינסידנט מבוים. ה-Game Day משלב chaos engineering עם incident management: מזריקים תקלה, הצוות מגלה, מכריז אינסידנט, פותר, וכותב פוסט-מורטם — הכול בסביבה מבוקרת עם "שופט" שיודע מה קרה באמת ומוודא שהצוות לא לוקח סיכון אמיתי.

Game Days חושפים לא רק bugs טכניים אלא גם פערים תהליכיים — runbook שלא עודכן, alert שלא הגיע לאדם הנכון, escalation policy עם מספר טלפון ישן. אלה הפערים ה"משעממים" שבפועל הורגים MTTR באינסידנט אמיתי.

Trade-offs: פרודקשן מול Staging

המתח המרכזי: chaos ב-staging בטוח יותר אבל פחות מייצג — staging לרוב לא רץ תחת עומס אמיתי, ולא כולל את כל האינטגרציות עם ספקים חיצוניים. chaos בפרודקשן מייצג אמת, אבל מסוכן. הגישה הבוגרת היא הדרגתית: מתחילים ב-staging לבניית ביטחון בכלים, עוברים לפרודקשן עם blast radius זעיר (canary traffic, שעות שפל, טרפיק פנימי בלבד), ורק אחרי חודשים של רקורד נקי מרחיבים ל-full production chaos בזמן עסקים רגיל.

trade-off שני הוא תזמון אוטומציה — chaos רץ באופן רציף וברקע (כמו Chaos Monkey המקורי) חושף רגרסיות מוקדם, אבל דורש בשלות ארגונית גבוהה. רוב הארגונים מתחילים עם ניסויים מתוזמנים ומבוקרים (Game Day חודשי), ועוברים ל-continuous chaos רק אחרי שהתרבות ההנדסית מוכנה לכך.

Chaos Engineering לא רק לתשתית: בדיקת Dependencies חיצוניים

אחד השימושים הכי בעלי ROI ב-chaos engineering, שלרוב מקבל פחות תשומת לב מ-"הריגת instances", הוא בדיקת ההתנהגות מול dependencies חיצוניים שאין לכם עליהם שליטה בכלל — payment gateway, SMS provider, שירות email טרנזקציוני, third-party auth. כלים כמו Toxiproxy מאפשרים להזריק latency או כשל מלאכותי ספציפית לתעבורה שיוצאת לספק החיצוני הזה, ולבדוק: האם יש timeout סביר? האם יש retry הגיוני? האם המשתמש מקבל הודעת שגיאה ברורה, או שהאפליקציה פשוט "נתקעת" לנצח מחכה לתשובה שלא תגיע?

הניסיון מלמד שרוב הבעיות האמיתיות שמתגלות ב-production incidents אינן מ"השרת שלנו נפל" — הן מ-dependency חיצוני שהתנהג בצורה בלתי צפויה (איטי, לא זמין חלקית, מחזיר תשובות שגויות) שהמערכת לא תוכננה להתמודד איתה. הרצת ניסויי chaos ממוקדים על כל dependency חיצוני קריטי, לפני שהוא נכשל בעצמו בפרודקשן, היא אחת ההשקעות המשתלמות ביותר בכל התחום.

טעויות נפוצות בפרודקשן

  • אין baseline מדוד — מריצים ניסוי בלי לדעת מה "נורמלי", ולכן לא ניתן לפרש את התוצאה.
  • אין kill switch מיידי — כשהניסוי משתולל, לוקח זמן יקר לעצור אותו ידנית.
  • מריצים בשעת שיא — ניסוי ראשון תמיד צריך להתבצע בשעת עומס נמוך, לא בפיק תעבורה.
  • לא מודיעים לצוות התמיכה — support נכנס לפאניקה על "אינסידנט" שהוא בעצם ניסוי מתוכנן.
  • עוצרים אחרי הניסוי הראשון המוצלח — chaos engineering הוא תהליך מתמשך, לא פרויקט חד-פעמי; המערכת משתנה כל הזמן וההשערות צריכות אימות חוזר.

תיעוד ניסויים: בניית ספרייה ארגונית של Failure Modes

ערך שנצבר לאורך זמן ולא תמיד מוערך מספיק: כל ניסוי chaos, בין אם הצליח (השערה אושרה) ובין אם נכשל (נמצא bug), צריך להיות מתועד במקום מרכזי — לא רק ב-Slack channel שנשכח אחרי שבוע. ספריית ניסויים ארגונית (לרוב wiki פשוט או repo ייעודי) עם: מה נבדק, ההשערה, התוצאה, ואם נמצא bug — מה תוקן, בונה עם הזמן מפה חיה של "מה אנחנו יודעים על ההתנהגות של המערכת שלנו תחת כשל". זה בעל ערך כפול: גם למניעת ניסוי כפול על אותו תרחיש, וגם ככלי onboarding למהנדסים חדשים שמתחילים להבין את המערכת דרך "מה כבר נבדק ומה לא".

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

מתי כן ומתי לא כדאי

chaos engineering מתאים למערכות עם דרישות זמינות גבוהות ומורכבות אמיתית — מיקרו-שירותים מרובים, תלויות רשת בין רכיבים, multi-region. במונוליט פשוט על שרת יחיד, הערך הראשוני נמוך יחסית לעלות — עדיף להתחיל שם בבדיקות עומס ו-DR drills פשוטים. גם ארגון שעדיין לא בנה monitoring ו-alerting בסיסי לא מוכן ל-chaos — אי אפשר למדוד אימפקט של ניסוי בלי מטריקות טובות מלכתחילה.

בשלות ארגונית: מודל השלבים לאימוץ Chaos Engineering

ארגונים לא קופצים ישר ל-continuous chaos בפרודקשן — יש מסלול הדרגתי שכדאי להכיר לפני שמתחילים. שלב 1: ניסויים ידניים ב-staging, עם מהנדס בודד שמריץ ומתעד תוצאות — המטרה כאן היא לבנות ביטחון בכלי ולזהות bugs "קלים" (timeout חסר, retry בלי backoff). שלב 2: Game Day מתוזמן ומודע, עם כל הצוות, פעם ברבעון — כאן נבדק גם התהליך התהליכי (runbooks, escalation) ולא רק הקוד. שלב 3: ניסויים אוטומטיים מתוזמנים בפרודקשן, בשעות שפל, עם blast radius מוגבל וkill switch — הצוות כבר בטוח מספיק בכלים כדי לתת להם לרוץ ללא השגחה צמודה. שלב 4: continuous chaos, בסגנון Chaos Monkey המקורי — רץ ברקע כל הזמן, ומהנדסים בונים קוד מתוך הנחה שכל instance עלול להיעלם בכל רגע. רוב הארגונים בישראל, גם הבשלים טכנולוגית, נמצאים בפועל בין שלב 1 ל-2, ואין שום בעיה בזה — המעבר לשלב 4 דורש תרבות הנדסית ספציפית שלא כל ארגון צריך.

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

סיכום

Chaos Engineering הופך את שאלת "האם המערכת שלנו resilient" משאלה רטורית לתשובה נמדדת. הערך האמיתי לא בכלי עצמו אלא במשמעת המדעית סביבו — hypothesis ברור, blast radius מבוקר, ו-stop condition שמונע מהניסוי להפוך לאסון. ארגון שמריץ Game Days באופן קבוע מגיע לאינסידנט אמיתי מוכן הרבה יותר טוב מארגון שרק קורא על זה.

תגיות: Chaos Engineering · Chaos Monkey · Gremlin · Resilience Testing · Game Day · Blast Radius · SRE

← חזרה לבלוג · צור קשר