Chaos Engineering - Chaos Monkey, Game Days
ב-2010, Netflix עברה לAWS. ב-2011, אחד מה-engineers שאל שאלה מפריעה: "האם אנחנו באמת בטוחים שה-system שלנו עמיד לכשלים? או שאנחנו רק מניחים שהוא עמיד?"
הדרך הישנה לבדוק: לחכות שמשהו ייכשל בפרודקשן. הדרך שNetflix המציאה: לגרום לדברים להיכשל בכוונה - בזמן ובמצב שנוחים לטיפול - ולראות מה קורה.
הם כתבו כלי שנקרא Chaos Monkey, שבכל יום עסקי מוריד instances אקראיים בפרודקשן. לא ב-staging. ב-production. אם ה-system לא מסוגל לשרוד זה - עדיף לגלות כשהengineers ערים ומוכנים, לא ב-3 בלילה.
התוצאה המוכחת של הגישה הזו הגיעה ב-21 באפריל 2011, כשAWS us-east-1 עבר outage גדול שהשפיע על עשרות אלפי חברות. Netflix, שתרגלה failover מאות פעמים דרך Chaos Monkey, נשארה פעילה. Reddit, Foursquare, Quora - לא. ה-difference? Netflix ידעה מה לעשות כי היא עשתה את זה כל יום. השאר גילו שה-failover procedures שלהן "עובדות על הנייר" אבל לא בפועל.
זה לא רק engineering story. זה business story. Netflix לא איבדה streaming revenue ביום הזה בגלל AWS outage. המתחרים שלה - כן. כשמחשבים את ה-ROI של Chaos Engineering, לא מדברים על engineering metrics - מדברים על revenue resilience.
ב-2018, Gremlin - חברת Chaos Engineering כservice - ערכה סקר ב-200 חברות: חברות שמריצות chaos experiments מדווחות על MTTD שנמוך ב-30% בממוצע, ו-MTTR שנמוך ב-40% בממוצע, לעומת חברות שלא מריצות chaos. הסיבה: engineers שמריצים chaos regularly מכירים את ה-system failure modes - ב-3 בלילה כשמשהו קורה, הם כבר ראו את זה.