9.6 कैओस इंजीनियरिंग और रेज़िलिएंस टेस्टिंग

अवलोकन और प्रेरणा

कैओस इंजीनियरिंग किसी सिस्टम पर प्रयोग चलाने का एक अनुशासित अभ्यास है, जिसका उद्देश्य प्रोडक्शन में उथल-पुथल भरी परिस्थितियों को झेलने की उसकी क्षमता पर विश्वास बनाना है। इसका नाम लापरवाह लग सकता है, और यही वह पहली बात है जिसे भूलना ज़रूरी है। कैओस इंजीनियरिंग यादृच्छिक रूप से चीज़ों को तोड़कर यह उम्मीद करना नहीं है कि आप कुछ सीख जाएंगे। यह इसके ठीक विपरीत है: यथार्थवादी विफलताओं को नियंत्रित और परिकल्पना-आधारित तरीके से डालने की एक पद्धति, ताकि आप कमज़ोरियों को अपने उपयोगकर्ताओं से पहले खोज सकें। आप पहले से जानते हैं कि आपका सिस्टम विफलताओं का सामना करेगा, क्योंकि हर वास्तविक सिस्टम ऐसा करता है। सवाल केवल यह है कि क्या आप इन विफलताओं का सामना मंगलवार दोपहर, रोलबैक तैयार रखते हुए करते हैं, या रात 3 बजे अपने सबसे व्यस्त समय में, यह जाने बिना कि क्या हो रहा है।

बड़ी टीमों के लिए यह महत्वपूर्ण है क्योंकि जटिलता अब इतनी बढ़ चुकी है कि कोई भी व्यक्ति केवल निरीक्षण करके उसके बारे में तर्क नहीं कर सकता। एक आधुनिक सेवा दर्जनों या सैकड़ों घटकों का एक जाल होती है, जिनमें से हर एक के अपने टाइमआउट, रिट्राई, कैश और विफलता के तरीके होते हैं, और इनके बीच की अंतःक्रियाएँ ऐसा उभरता हुआ व्यवहार उत्पन्न करती हैं जिसकी भविष्यवाणी कोई आर्किटेक्चर डायग्राम नहीं कर सकता। आप कोड की समीक्षा कर सकते हैं, बॉक्स बना सकते हैं, फिर भी आप तब चौंक सकते हैं जब कोई धीमी डिपेंडेंसी एक रिट्राई स्टॉर्म को ट्रिगर कर दे जो तीन हॉप दूर स्थित किसी सेवा को गिरा दे। कैओस इंजीनियरिंग वह तरीका है जिससे आप इन अंतःक्रियाओं की अनुभवजन्य रूप से जांच करते हैं, ताकि आपकी रेज़िलिएंस कोई मान ली गई बात नहीं, बल्कि सत्यापित की गई बात बने।

एंटरप्राइज़ और सरकारी संदर्भों में दांव और भी ऊंचे हो जाते हैं, और, तेज़ी से, यह एक अनिवार्यता बनती जा रही है। वित्तीय नियामक अब फर्मों से यह अपेक्षा करते हैं कि वे गंभीर-लेकिन-संभावित परिदृश्यों के विरुद्ध परिचालन रेज़िलिएंस का परीक्षण करें और यह साबित करें कि वे व्यवधान के दौरान भी महत्वपूर्ण सेवाओं को चालू रख सकती हैं। सरकारी निकाय निरंतरता-अभ्यास चलाते हैं ताकि आवश्यक सार्वजनिक सेवाएँ आउटेज, आपदाओं और साइबर हमलों से बच सकें। दोनों ही दुनिया में, किसी ऑडिटर या नागरिक के लिए “हमें लगता है कि यह टिक जाएगा” कोई स्वीकार्य उत्तर नहीं है। कैओस इंजीनियरिंग आपको प्रमाण देती है। यह अध्याय साइट रिलायबिलिटी इंजीनियरिंग (अध्याय 9.1) और अध्याय 3.5 में दिए गए रेज़िलिएंस पैटर्न पर आधारित है, और यह घटना प्रबंधन (अध्याय 9.3) तथा आपदा पुनर्प्राप्ति (अध्याय 9.5) से गहराई से जुड़ा हुआ है।

प्रमुख सिद्धांत

• विश्वास बनाएं, अव्यवस्था न फैलाएं। लक्ष्य सत्यापित रेज़िलिएंस है, तमाशा नहीं। हर प्रयोग इस बारे में एक विशिष्ट प्रश्न का उत्तर देता है कि दबाव में सिस्टम कैसा व्यवहार करता है।
• पहले स्थिर स्थिति (steady state) को परिभाषित करें। बिना यह स्पष्ट और मापने योग्य परिभाषा दिए कि “स्वस्थ” स्थिति कैसी दिखती है, आप किसी समस्या का पता नहीं लगा सकते।
• एक परिकल्पना बनाएं। कोई फ़ॉल्ट डालने से पहले यह बताएं कि आप क्या होने की उम्मीद करते हैं। कोई आश्चर्य भी एक निष्कर्ष है; उसका न होना भी एक निष्कर्ष है।
• ब्लास्ट रेडियस को न्यूनतम और सीमित रखें। छोटे स्तर से शुरू करें, वास्तविक उपयोगकर्ताओं की सुरक्षा करें, और दायरा तभी बढ़ाएं जब विश्वास बढ़े।
• सावधानी के साथ प्रोडक्शन को प्राथमिकता दें। वास्तविक ट्रैफ़िक, वास्तविक डेटा और वास्तविक स्केल के तहत विफलताएँ अलग व्यवहार करती हैं। वहां परीक्षण करने का अधिकार अर्जित करें।
• सतत सत्यापन की दिशा में स्वचालन करें। जिस कमज़ोरी को आपने एक बार ठीक किया है, वह फिर से लौट सकती है। जो रेज़िलिएंस निरंतर परखी जाती है, वही सही बनी रहती है।
• विफलता एक शिक्षक है, कोई फैसला नहीं। निष्कर्ष सिस्टम को बेहतर बनाते हैं; वे कभी भी प्रयोग चलाने वाले व्यक्ति को दोष देने का कारण नहीं होते।

सिफारिशें

एक भी फ़ॉल्ट डालने से पहले पूर्वापेक्षाएँ स्थापित करें

कैओस इंजीनियरिंग एक परिपक्व सिस्टम के लिए एक फोर्स मल्टीप्लायर है और एक अपरिपक्व सिस्टम के लिए एक दायित्व। शुरू करने से पहले, आपके पास तीन चीज़ें होनी चाहिए। पहली, ऑब्ज़र्वेबिलिटी, यानी वे मेट्रिक्स, लॉग और ट्रेस जो आपको बाहर से यह देखने देते हैं कि आपका सिस्टम क्या कर रहा है, क्योंकि जिस प्रयोग को आप देख नहीं सकते, वह आपको कुछ नहीं सिखाता। दूसरी, सर्विस लेवल ऑब्जेक्टिव या स्थिर-स्थिति स्वास्थ्य की कोई समकक्ष परिभाषा (अध्याय 9.1), ताकि आप वास्तविक समय में एक सफल प्रयोग को हानिकारक प्रयोग से अलग कर सकें। तीसरी, एक तेज़ और भरोसेमंद रोलबैक या एबॉर्ट पथ, ताकि जिस क्षण कोई प्रयोग वास्तविक उपयोगकर्ताओं के लिए खतरा बने, आप उसे रोककर सेकंडों में सामान्य सेवा बहाल कर सकें। यदि आप अपने सिस्टम को माप नहीं सकते, उसकी स्वस्थ स्थिति को परिभाषित नहीं कर सकते, और उसे कगार से वापस नहीं खींच सकते, तो अभी कैओस प्रयोग न चलाएं। पहले ये क्षमताएँ बनाएं। ये किसी भी स्थिति में अपनी लागत वसूल लेती हैं।

स्थिर स्थिति को परिभाषित करें और एक वास्तविक परिकल्पना बनाएं

हर प्रयोग यह लिखने से शुरू होता है कि सामान्य स्थिति मापने योग्य शब्दों में कैसी दिखती है: 99.9 प्रतिशत से ऊपर रिक्वेस्ट सफलता दर, 95वें पर्सेंटाइल पर 400 मिलीसेकंड से कम चेकआउट लेटेंसी, किसी सीमा से कम क्यू डेप्थ। यही आपकी स्थिर-स्थिति परिभाषा है, और इसे आंतरिक तंत्र के बजाय उपयोगकर्ता को दिखने वाले स्वास्थ्य को दर्शाना चाहिए। इसके बाद सरल भाषा में एक परिकल्पना बताएं: “यदि हम recommendations सेवा में 300 मिलीसेकंड की लेटेंसी जोड़ते हैं, तो प्रोडक्ट पेज फिर भी अपने लेटेंसी बजट के भीतर रेंडर होगा, क्योंकि पेज recommendations को वैकल्पिक मानता है और 200 मिलीसेकंड के बाद टाइमआउट हो जाता है।” अब आपके पास एक ऐसा दावा है जिसे गलत साबित किया जा सकता है। जब आप प्रयोग चलाते हैं, तो दो अच्छी चीज़ों में से एक होती है। या तो सिस्टम अनुमान के अनुसार व्यवहार करता है और आपका विश्वास अर्जित होता है, या फिर ऐसा नहीं होता और आपको इंजीनियरों की निगरानी में, अपनी शर्तों पर, सस्ते में एक वास्तविक कमज़ोरी मिल जाती है।

यथार्थवादी फ़ॉल्ट डालें, मनमाने नहीं

आपके द्वारा डाले गए फ़ॉल्ट आपके सिस्टम में वास्तव में होने वाली विफलताओं को प्रतिबिंबित करने चाहिए। फ़ॉल्ट इंजेक्शन, यानी सिस्टम की प्रतिक्रिया परखने के लिए जानबूझकर त्रुटियाँ डालना, आपको वास्तविक प्रोडक्शन घटनाओं से लिया गया एक मेन्यू देता है। किसी धीमी डिपेंडेंसी या संतृप्त नेटवर्क लिंक का अनुकरण करने के लिए लेटेंसी डालें। किसी विफल हो रही डाउनस्ट्रीम सेवा का अनुकरण करने के लिए त्रुटियाँ डालें, जैसे HTTP 500 लौटाना या कनेक्शन अस्वीकार करना। दबाव में सिस्टम किस तरह ख़राब होता है यह देखने के लिए CPU, मेमोरी, डिस्क, या फ़ाइल डिस्क्रिप्टर की खपत करके रिसोर्स एग्ज़ॉशन डालें। किसी संपूर्ण डेटाबेस, कैश, क्यू, या थर्ड-पार्टी API को अनुपलब्ध बनाकर डिपेंडेंसी विफलता डालें। किसी डिस्ट्रिब्यूटेड सिस्टम में, जहां घटक अलग-अलग मशीनों पर चलते हैं और एक अविश्वसनीय नेटवर्क पर संवाद करते हैं, यही वे विफलताएँ हैं जो वास्तविक आउटेज में हावी रहती हैं। व्यवहार में चीज़ों को तोड़ने वाली चीज़ें साफ़-सुथरी क्रैश नहीं, बल्कि लेटेंसी और आंशिक विफलता होती हैं, इसलिए अपने प्रयोगों का भार इस उलझे हुए मध्य भाग की ओर रखें।

सत्यापित करें कि आपके रेज़िलिएंस तंत्र वास्तव में काम करते हैं

यहीं पर कैओस इंजीनियरिंग अपनी उपयोगिता साबित करती है। आपका सिस्टम ऐसे तंत्रों से भरा है जिनसे आपकी सुरक्षा की उम्मीद की जाती है: टाइमआउट जो किसी कॉलर को हमेशा के लिए इंतज़ार करने से रोकते हैं, रिट्राई जो क्षणिक गड़बड़ियों को छिपा देते हैं, सर्किट ब्रेकर जो किसी विफल डिपेंडेंसी पर लगातार प्रहार करना बंद कर देते हैं, और फेलओवर जो प्राइमरी के विफल होने पर स्टैंडबाय पर स्विच कर देता है। ये पैटर्न, जिन्हें अध्याय 3.5 में शामिल किया गया है, एक नियंत्रित समस्या और एक बढ़ते हुए आउटेज के बीच का अंतर हैं। परेशानी यह है कि इनका परीक्षण शायद ही कभी उन्हीं परिस्थितियों में किया जाता है जिनके लिए ये बनाए गए हैं। 30 सेकंड पर सेट किया गया टाइमआउट कुछ नहीं करता जब कॉलर की अपनी डेडलाइन 2 सेकंड हो। बिना बैकऑफ़ के रिट्राई एक संघर्षरत सेवा को थंडरिंग हर्ड में बदल देती है। एक सर्किट ब्रेकर जिसे कभी परखा नहीं गया, वह गलत तरीके से कॉन्फ़िगर हो सकता है और कभी ट्रिप न हो, या लगातार ट्रिप होता रहे। कैओस प्रयोग यही पुष्टि करने का तरीका हैं कि जब वह फ़ॉल्ट वास्तव में आता है जिससे बचाव के लिए ये तंत्र बने हैं, तो हर एक डिज़ाइन के अनुसार व्यवहार करता है। जब तक कोई प्रयोग इसके विपरीत साबित न कर दे, हर अनपरखे सुरक्षा तंत्र को टूटा हुआ मानें।

स्वचालित करने से पहले गेम डे से शुरुआत करें

ऐसे स्वचालित प्लेटफ़ॉर्म से शुरुआत न करें जो लगातार फ़ॉल्ट डालता रहे। एक गेम डे से शुरुआत करें: एक निर्धारित, प्रत्यक्ष अभ्यास जिसमें एक टीम इकट्ठा होती है, एक परिदृश्य चुनती है, एक नियंत्रित वातावरण में फ़ॉल्ट डालती है, और साथ मिलकर देखती है। उससे भी पहले, एक टेबलटॉप एक्सरसाइज़, जिसमें आप सिस्टम को छुए बिना व्हाइटबोर्ड पर किसी परिदृश्य पर चर्चा करते हैं, लगभग बिना किसी जोखिम के रनबुक, अलर्टिंग, और स्वामित्व में मौजूद अंतरालों को सामने लाती है। गेम डे आपका ऑन-रैंप हैं। ये परिकल्पना बनाने, ब्लास्ट रेडियस को नियंत्रित रखने, और दबाव में सिस्टम को पढ़ने की क्षमता बनाते हैं, और नेतृत्व तथा पड़ोसी टीमों के साथ वह विश्वास बनाते हैं जिसकी आपको प्रोडक्शन में प्रयोग चलाने की अनुमति मिलने से पहले आवश्यकता होगी। ये सीधे घटना प्रतिक्रिया को भी मज़बूत करते हैं, क्योंकि ये वही कौशल हैं जिनका उपयोग आपके ऑन-कॉल इंजीनियर किसी वास्तविक घटना (अध्याय 9.3) के दौरान करते हैं। अपने पहले गेम डे स्टेजिंग में चलाएं, फिर छोटे ब्लास्ट रेडियस के साथ शांत समय में प्रोडक्शन में, फिर दायरा बढ़ाएं।

जानबूझकर ब्लास्ट रेडियस को सीमित रखें

सबसे महत्वपूर्ण सुरक्षा अभ्यास हर प्रयोग की संभावित हानि को सीमित करना है। सबसे छोटे दायरे से शुरुआत करें जो आपको कुछ सिखा सके: एक इंस्टेंस, ट्रैफ़िक का एक प्रतिशत, एक गैर-महत्वपूर्ण डिपेंडेंसी, एक एवेलेबिलिटी ज़ोन। शुरू करने से पहले एबॉर्ट कंडीशन तय करें, उन्हें अपने स्थिर-स्थिति मेट्रिक्स से जोड़ें, और प्रयोग को रोकना ऐसी एक क्रिया बनाएं जिसे कोई भी देख रहा व्यक्ति ट्रिगर कर सके। बिज़नेस ऑवर्स में चलाना प्राथमिकता दें, जब टीम सतर्क और उपलब्ध हो, न कि रात भर में जब कोई आश्चर्य ऐसी घटना बन जाए जिसे कोई देख नहीं रहा। ब्लास्ट रेडियस तभी बढ़ाएं जब छोटे प्रयोग साफ़-सुथरे ढंग से चल चुके हों और आपका विश्वास वास्तव में बढ़ गया हो। नियंत्रण का यही अनुशासन कैओस इंजीनियरिंग को आपके स्वयं के कारण हुए आउटेज से अलग करता है।

सतत, स्वचालित रेज़िलिएंस सत्यापन की ओर बढ़ें

कभी-कभार होने वाले गेम डे कमज़ोरियाँ खोज लेते हैं, लेकिन सिस्टम हर दिन बदलते हैं, और पिछली तिमाही में किया गया कोई सुधार चुपचाप वापस बिगड़ सकता है। परिपक्व अंतिम स्थिति सतत सत्यापन है: रेज़िलिएंस प्रयोगों का एक चुना हुआ सेट जो किसी पाइपलाइन में या किसी शेड्यूल पर स्वचालित रूप से चलता है, ताकि टाइमआउट, रिट्राई पॉलिसी, या फेलओवर पथ में कोई गिरावट अगली वास्तविक आउटेज के दौरान नहीं, बल्कि कुछ ही दिनों में पकड़ में आ जाए। यहीं पर Netflix के Chaos Monkey जैसे टूल ने अपनी प्रतिष्ठा अर्जित की, जो प्रोडक्शन में बेतरतीब ढंग से इंस्टेंस बंद कर देता है ताकि इंजीनियर ऐसी सेवाएँ बनाने के लिए बाध्य हों जो इंस्टेंस के नुकसान को सहन कर सकें। केवल उन्हीं प्रयोगों को स्वचालित करें जिन्हें आप पहले से समझते हैं और मैनुअल रन से जिन पर आपको भरोसा है। एक अपरिपक्व सिस्टम पर सतत कैओस विश्वास नहीं, बल्कि घटनाएँ उत्पन्न करने का एक तरीका है।

प्रयोगों को आपदा पुनर्प्राप्ति और घटना से सीख के साथ जोड़ें

कैओस इंजीनियरिंग अकेली नहीं रहती। बड़े, दुर्लभ परिदृश्य (जैसे पूरे क्षेत्र (region) का नुकसान होना, किसी डेटाबेस का फेलओवर करना, बैकअप से पुनर्स्थापित करना) आपदा-पुनर्प्राप्ति परीक्षण (अध्याय 9.5) के दायरे में आते हैं, और एक गेम डे अक्सर उन योजनाओं को बिना परखे दस्तावेज़ों की तरह सड़ने देने के बजाय उनका अभ्यास कराने का सबसे अच्छा माध्यम होता है। दूसरी ओर, कमज़ोरी सामने लाने वाले हर प्रयोग को उसी सीखने के लूप में जाना चाहिए जिसमें एक वास्तविक घटना (अध्याय 9.3) जाती है: एक दोषरहित लेख, एक ट्रैक किया गया सुधार, और यह पुष्टि करने के लिए एक फॉलो-अप प्रयोग कि सुधार टिका रहता है। जब कैओस निष्कर्ष, आपदा-पुनर्प्राप्ति अभ्यास, और घटना रेट्रोस्पेक्टिव सभी रेज़िलिएंस कार्य के एक ही बैकलॉग में प्रवाहित होते हैं, तो आपको बिखरे हुए एकल अभ्यासों के बजाय संचयी प्रतिफल मिलता है।

ट्रेड-ऑफ़: लाभ और हानि

निर्णय	लाभ	हानि
प्रोडक्शन में परीक्षण	वास्तविक ट्रैफ़िक, डेटा, और स्केल; निष्कर्ष सटीक होते हैं	नियंत्रण विफल होने पर उपयोगकर्ताओं को जोखिम; परिपक्वता आवश्यक
केवल स्टेजिंग में परीक्षण	सुरक्षित, कम जोखिम, शुरू करना आसान	वास्तविक-दुनिया के व्यवहार को छोड़ देता है; झूठा विश्वास
मैनुअल गेम डे	कौशल और विश्वास बनाते हैं; कम टूलिंग लागत	दुर्लभ; निष्कर्ष बिना ध्यान दिए वापस बिगड़ सकते हैं
सतत स्वचालित कैओस	गिरावट को तेज़ी से पकड़ता है; स्केल करता है	पहले परिपक्व टूलिंग और ऑब्ज़र्वेबिलिटी आवश्यक
व्यापक ब्लास्ट रेडियस	बड़ी प्रणालीगत कमज़ोरियाँ उजागर करता है	उच्च जोखिम; एक गलती एक घटना बन जाती है
संकीर्ण ब्लास्ट रेडियस	सुरक्षित और नियंत्रणीय	उभरती हुई क्रॉस-सर्विस विफलताओं को चूक सकता है

केंद्रीय तनाव यथार्थवाद और सुरक्षा के बीच है। जो निष्कर्ष आप सबसे ज़्यादा चाहते हैं, वे प्रोडक्शन से आते हैं, क्योंकि यही एकमात्र स्थान है जहां आपका सिस्टम वास्तविक ट्रैफ़िक, वास्तविक डेटा, और वास्तविक स्केल का सामना करता है, फिर भी प्रोडक्शन ही वह जगह है जहां कोई बिगड़ा हुआ प्रयोग उपयोगकर्ताओं को नुकसान पहुंचाता है। इसका समाधान एक पक्ष चुनना नहीं है। इसका समाधान है धीरे-धीरे प्रोडक्शन की ओर अपना रास्ता अर्जित करना: अपनी पूर्वापेक्षाएँ साबित करें, स्टेजिंग में अभ्यास करें, फिर लाइव मेट्रिक्स से जुड़ी एबॉर्ट कंडीशन के साथ प्रोडक्शन में छोटे, अच्छी तरह नियंत्रित प्रयोग चलाएं, और प्रमाण जमा होने पर ही दायरा बढ़ाएं। दूसरा आवर्ती तनाव, मैनुअल बनाम स्वचालित, समय के साथ उसी तरह हल होता है। समझ और विश्वास बनाने के लिए मैनुअल से शुरुआत करें, फिर उन प्रयोगों को स्वचालित करें जिन पर आप भरोसा करने लगे हैं, ताकि जिस रेज़िलिएंस को आपने एक बार सत्यापित किया है, वह सत्यापित बनी रहे।

अपनी टीम के साथ चर्चा करने के लिए प्रश्न

1. क्या हम वास्तव में कैओस प्रयोग चलाने के लिए तैयार हैं, और हमें यह कैसे पता चलेगा? फ़ॉल्ट डालना शुरू करना लुभावना लग सकता है क्योंकि यह परिष्कृत लगता है, लेकिन ऐसे सिस्टम पर कैओस इंजीनियरिंग जिसे देखा नहीं जा सकता, जिसकी स्वास्थ्य की कोई स्पष्ट परिभाषा नहीं है, और जिसमें तेज़ रोलबैक नहीं है, महज़ स्वयं थोपा गया डाउनटाइम है। इस चर्चा में ईमानदार प्रमाण लाएं: क्या आप वास्तविक समय में रिक्वेस्ट सफलता दर और लेटेंसी देख सकते हैं, क्या आपके पास स्थिर स्थिति की सहमत परिभाषा है, और क्या आप किसी प्रयोग को रोककर सेकंडों में रिकवर कर सकते हैं? एक बड़ी टीम के लिए, उत्तर अक्सर सेवा के अनुसार अलग होता है, इसलिए उपयोगी परिणाम एक तत्परता मानदंड (readiness bar) है जिसे किसी सेवा को प्रयोगों के लिए पात्र बनने से पहले पार करना होगा। नियमित (regulated) परिवेशों में यह तत्परता मानदंड एक ऐसा नियंत्रण भी बन जाता है जिसे आप किसी ऑडिटर को दिखा सकते हैं। यदि ईमानदार उत्तर यह है कि आप तैयार नहीं हैं, तो इस तिमाही में आप जो सबसे मूल्यवान कैओस कार्य कर सकते हैं, वह है वे ऑब्ज़र्वेबिलिटी और रोलबैक क्षमताएँ बनाना जो आपको तैयार बनाती हैं।

2. हमारी ब्लास्ट-रेडियस नीति क्या है, और किसी प्रयोग को रोकने का अधिकार किसके पास है? हर कैओस प्रयोग वास्तविक उपयोगकर्ताओं के लिए कुछ जोखिम रखता है, और एक मूल्यवान निष्कर्ष और आपके द्वारा पैदा की गई एक घटना के बीच का अंतर यह है कि आपने उसे कितनी कसकर नियंत्रित रखा। ठोस सीमाओं पर बात करें: ट्रैफ़िक का कितना हिस्सा, कितने इंस्टेंस, कौन से वातावरण, दिन का कौन-सा समय, और कौन-सी मेट्रिक सीमाएँ रन को स्वतः रोक देंगी। पहले से तय करें कि हर प्रयोग को कौन देख रहा है और सिंगल-एक्शन किल स्विच किसके पास है, क्योंकि जिस प्रयोग को कोई भी जल्दी नहीं रोक सकता, वह नियंत्रित नहीं है। एक बड़े संगठन के लिए यही नीति कई टीमों को यह प्रयोग करने देती है कि उनमें से कोई भी गलती से किसी साझा डिपेंडेंसी को न गिरा दे। उत्तर लिखित रूप में होना चाहिए, उन टीमों के साथ सहमत होना चाहिए जिनकी सेवाओं को आप प्रभावित कर सकते हैं, और प्रोडक्शन में कुछ भी चलाने के लिए एक पूर्वशर्त माना जाना चाहिए।

3. हम किन रेज़िलिएंस तंत्रों को मानते हैं कि वे हमारी रक्षा करते हैं, और क्या हमने उन्हें वास्तव में कभी परखा है? ज़्यादातर सिस्टम ऐसे टाइमआउट, रिट्राई, सर्किट ब्रेकर, कैश, और फेलओवर पथों से भरे होते हैं जिन्हें एक बार कॉन्फ़िगर किया गया और फिर उस विफलता के तहत कभी नहीं परखा गया जिसके लिए वे बनाए गए थे। उन तंत्रों की एक सूची बनाएं जिन पर आप भरोसा कर रहे हैं, फिर हर एक के लिए पूछें कि उसे किसी वास्तविक डाले गए फ़ॉल्ट के तहत काम करता हुआ आखिरी बार कब सत्यापित किया गया था। प्रतिस्पर्धी विचार समय है: हर तंत्र को सत्यापित करने में इंजीनियरिंग प्रयास लगता है, और हमेशा कोई फ़ीचर डेडलाइन होती है। इस आपत्ति के विरुद्ध प्रति-प्रमाण लाएं, यानी किसी पिछली आउटेज की लागत जिसे एक काम करता हुआ सर्किट ब्रेकर या एक सही टाइमआउट रोक सकता था। उत्तर को मान ली गई सुरक्षाओं की एक सुकून देने वाली सूची को प्रयोगों के एक प्राथमिकता-क्रमित बैकलॉग में बदल देना चाहिए, उन तंत्रों से शुरू करते हुए जिनकी विफलता सबसे ज़्यादा नुकसान पहुंचाएगी।

4. स्टेजिंग के बजाय प्रोडक्शन में प्रयोग चलाने से पहले क्या सच होना चाहिए, और आज कौन-सी सेवाओं ने यह अधिकार अर्जित किया है? जो निष्कर्ष आप सबसे ज़्यादा चाहते हैं, वे प्रोडक्शन से आते हैं, क्योंकि यही एकमात्र स्थान है जहां आपका सिस्टम वास्तविक ट्रैफ़िक, वास्तविक डेटा, और वास्तविक स्केल का सामना करता है, फिर भी प्रोडक्शन ही वह एकमात्र स्थान भी है जहां कोई बिगड़ा हुआ प्रयोग वास्तविक उपयोगकर्ताओं को नुकसान पहुंचाता है। एक बड़ी टीम के लिए ईमानदार सच्चाई यह है कि अलग-अलग सेवाएँ तत्परता के अलग-अलग स्तरों पर होती हैं, इसलिए एक सामान्य “प्रोडक्शन में कोई कैओस नहीं” नियम आपकी सबसे अच्छी सीख को बर्बाद कर देता है, जबकि एक सामान्य “हां” स्वयं थोपी गई आउटेज को आमंत्रित करता है। प्रति सेवा प्रमाण लाएं: उसकी ऑब्ज़र्वेबिलिटी की गुणवत्ता, क्या स्थिर स्थिति परिभाषित और अलर्ट योग्य है, रोलबैक कितना तेज़ है, और साफ़-सुथरे स्टेजिंग प्रयोगों का ट्रैक रिकॉर्ड जो उसे आगे बढ़ाने को उचित ठहराए। एंटरप्राइज़ और सरकारी परिवेशों में, प्रोडक्शन गेट को एक दस्तावेज़ीकृत नियंत्रण से जोड़ें जो यह बताए कि प्रमोशन को कौन अनुमोदित करता है और कौन-सी एबॉर्ट कंडीशन लाइव मेट्रिक्स से जुड़ी हैं, ताकि ऑडिटर को वास्तविक उपयोगकर्ताओं के साथ तात्कालिक प्रयोग करती हुई टीम के बजाय एक जानबूझकर लिया गया, प्रमाण-आधारित निर्णय दिखाई दे।

5. जब कोई कैओस प्रयोग कोई कमज़ोरी सामने लाता है, तो वह निष्कर्ष कहां जाता है, और हम उसे बिना छुए सड़ने से कैसे रोकते हैं? ऐसा कार्यक्रम जो कमज़ोरियाँ खोजता है लेकिन उन्हें कभी ठीक नहीं करता, कार्यक्रम न होने से भी बदतर है, क्योंकि यह प्रयास को जला देता है, विश्वास को कमज़ोर करता है, और लोगों को यह सिखाता है कि प्रयोग महज़ तमाशा हैं। प्रतिस्पर्धी दबाव हमेशा फ़ीचर रोडमैप का होता है: एक रेज़िलिएंस सुधार शायद ही कभी अगली रिलीज़ जितना तत्काल महसूस होता है, जब तक कि वह आउटेज वास्तव में न आ जाए जिसे वह रोक सकता था। चर्चा में अपने रेज़िलिएंस बैकलॉग की वर्तमान स्थिति लाएं: कितने कैओस निष्कर्ष खुले हैं, सबसे पुराना कितना पुराना है, और क्या प्रयोगों, आपदा-पुनर्प्राप्ति अभ्यासों, और घटना रेट्रोस्पेक्टिव के निष्कर्ष एक साझा कतार में प्रवाहित होते हैं या टीमों में बिखरे रहते हैं। इस पर सहमत हों कि हर सुधार का स्वामी कौन है और यह पुष्टि करने वाला फॉलो-अप प्रयोग कौन चलाता है कि सुधार टिका रहता है। एक बड़े या नियमित संगठन के लिए, उस फोरम का नाम बताएं जो एक निश्चित अवधि पर बैकलॉग की समीक्षा करता है और किसी फ़ीचर पर रेज़िलिएंस सुधार को प्राथमिकता देने का अधिकार रखता है, क्योंकि जिस निष्कर्ष को बंद करने के लिए कोई जवाबदेह नहीं है, वह एक ऐसा जोखिम है जिसे आपने केवल दस्तावेज़ीकृत किया है, हटाया नहीं।

6. क्या हम अपने किसी प्रयोग को सतत सत्यापन में स्वचालित करने के लिए तैयार हैं, और विशेष रूप से किसे? कभी-कभार होने वाले गेम डे कमज़ोरियाँ खोज लेते हैं, लेकिन सिस्टम रोज़ बदलते हैं और पिछली तिमाही का सुधार चुपचाप वापस बिगड़ सकता है, इसलिए परिपक्व अंतिम स्थिति प्रयोगों का एक चुना हुआ सेट है जो स्वचालित रूप से चलता है और कुछ ही दिनों में गिरावट पकड़ लेता है। खतरा यह है कि बहुत जल्दी स्वचालित कर दिया जाए: कमज़ोर ऑब्ज़र्वेबिलिटी वाले अपरिपक्व सिस्टम पर सतत कैओस अंतर्दृष्टि से ज़्यादा तेज़ी से घटनाएँ पैदा करता है। उन प्रयोगों की सूची लाएं जिन्हें आपने पूरी तरह भरोसा करने लायक बार-बार मैनुअल रूप से चलाया है, वे ब्लास्ट-रेडियस नियंत्रण और एबॉर्ट कंडीशन जो उन्हें बिना निगरानी के नियंत्रित करेंगी, और वह मॉनिटरिंग जो रात 3 बजे, जब कोई देख नहीं रहा, किसी स्वचालित रन को गलत होते हुए पकड़ लेगी। एक बड़े एंटरप्राइज़ या सार्वजनिक एजेंसी के लिए, उस अतिरिक्त जांच को तौलें जिसे बिना निगरानी वाला फ़ॉल्ट इंजेक्शन आमंत्रित करता है: चेंज-मैनेजमेंट साइन-ऑफ़, वह ऑडिट ट्रेल जो हर स्वचालित रन को छोड़ना चाहिए, और किसी शेड्यूल किए गए प्रयोग के लिए स्पष्ट जवाबदेही जो किसी वास्तविक घटना के साथ मेल खा जाता है। केवल उन्हीं प्रयोगों को स्वचालित करें जिन्हें आप पहले से समझते हैं, और बाकी को तब तक मैनुअल रखें जब तक वे वही विश्वास अर्जित न कर लें।

क्षेत्रीय परिप्रेक्ष्य

स्टार्टअप। गति और अस्तित्व सबसे ऊपर होते हैं, इसलिए किसी कैओस प्लेटफ़ॉर्म पर कुछ भी खर्च न करें। स्टेजिंग में उस एक डिपेंडेंसी के विरुद्ध एक नब्बे-मिनट का गेम डे चलाएं जिसकी विफलता वास्तव में आपको खत्म कर सकती है, आमतौर पर भुगतान (payments), प्रमाणीकरण (auth), या आपका प्राथमिक डेटास्टोर। किसी साधारण प्रॉक्सी या मार दी गई प्रक्रिया (killed process) से विफलता डालें, देखें कि क्या टूटता है, गायब टाइमआउट या फॉलबैक को ठीक करें, और आगे बढ़ें। पूरा उद्देश्य यह है कि किसी स्पष्ट, स्वयं थोपी गई आउटेज को किसी ग्राहक के पकड़ने से पहले सस्ते में पकड़ लिया जाए, न कि ऐसा अनुशासन बनाना जिसके लिए आपके पास स्टाफ़ ही न हो।

लघु व्यवसाय। बिना किसी रिलायबिलिटी विशेषज्ञ और सीमित बजट के, रेज़िलिएंस टेस्टिंग को एक ऐसे कार्यक्रम के बजाय जिसके लिए स्टाफ़ रखा जाए, एक आवधिक, जानबूझकर किया गया अभ्यास मानें। समर्पित प्लेटफ़ॉर्म खरीदने के बजाय अपने क्लाउड प्रदाता या मैनेज्ड टूलिंग में पहले से शामिल फ़ॉल्ट-इंजेक्शन सुविधाओं पर निर्भर रहें, और प्रयोगों को उन गिनी-चुनी डिपेंडेंसीज़ पर केंद्रित करें जिन्हें कोई ग्राहक नोटिस करेगा। इसे बीमा के रूप में देखें: यह पुष्टि करने में बिताई गई एक दोपहर कि आपके बैकअप पुनर्स्थापित होते हैं और आपका चेकआउट सहजता से ख़राब होता है, उस आउटेज से कहीं सस्ता है जो साबित करे कि ऐसा नहीं होता।

एंटरप्राइज़। समस्या स्केल पर साझा डिपेंडेंसीज़ के विरुद्ध कई टीमों का समन्वय करने की है, इसलिए तत्परता मानदंड, ब्लास्ट-रेडियस नीति, और एबॉर्ट-कंडीशन वायरिंग को मानकीकृत करें जिसे हर टीम को प्रोडक्शन में चलाने से पहले पार करना होगा। कैओस निष्कर्षों, आपदा-पुनर्प्राप्ति अभ्यासों, और घटना रेट्रोस्पेक्टिव को स्पष्ट स्वामित्व के साथ एक रेज़िलिएंस बैकलॉग में भेजें, और परिचालन-रेज़िलिएंस अपेक्षाओं को प्रमाण के साथ पूरा करने के लिए त्रैमासिक गेम डे के साथ-साथ स्वचालित प्रयोगों के एक चुने हुए सेट का उपयोग करें। यह नियंत्रित करें कि किसी साझा सेवा को कौन प्रभावित कर सकता है, ताकि किसी एक टीम का प्रयोग उस इन्फ्रास्ट्रक्चर को न गिरा दे जिस पर दूसरे निर्भर हैं।

सरकार। खरीद नियम, पारदर्शिता, और सार्वजनिक जवाबदेही इस कार्य को आकार देते हैं। निरंतरता-अभ्यास की अनिवार्यताओं के लिए वैसे भी अक्सर नियमित अभ्यासों की आवश्यकता होती है, इसलिए इन्हें ऐसे लाइव गेम डे के रूप में चलाएं जो वास्तविक निष्कर्ष उत्पन्न करें, न कि कोई ऐसा बाइंडर जिसे कोई नहीं खोलता, और हर प्रयोग, उसके ब्लास्ट रेडियस, और उसके परिणाम का ऑडिट ट्रेल रखें। जहां फ़ॉल्ट-इंजेक्शन टूलिंग खरीदी जाती है, वहां मांग करें कि यह सुरक्षा और डेटा-हैंडलिंग नियमों के भीतर फ़िट बैठे, और नागरिक-केंद्रित सेवाओं पर प्रोडक्शन प्रयोगों को कड़ाई से नियंत्रित, स्वीकृत समय-खिड़कियों के लिए सुरक्षित रखें। एक कैओस कार्यक्रम जो प्रमाण उत्पन्न करता है, वही ठीक वह है जिसे कोई निगरानी निकाय या ऑडिटर देखने की अपेक्षा करता है।

उदाहरण

स्टार्टअप। पंद्रह लोगों का एक स्टार्टअप गिनी-चुनी सेवाओं पर एक वेब ऐप चलाता है और एक थर्ड-पार्टी भुगतान API पर निर्भर करता है। किसी के पास कैओस प्लेटफ़ॉर्म के लिए समय नहीं है, इसलिए टीम स्टेजिंग में एक नब्बे-मिनट का गेम डे चलाती है। वे एक परिकल्पना बनाते हैं: यदि भुगतान API त्रुटियाँ लौटाना शुरू कर दे, तो चेकआउट को क्रैश होने के बजाय एक स्पष्ट रिट्राई संदेश दिखाना चाहिए और ऑर्डर को कतार में डालना चाहिए। वे एक साधारण प्रॉक्सी से 500 प्रतिक्रियाएँ डालते हैं, और पाते हैं कि फ्रंटएंड अनिश्चित काल तक अटका रहता है क्योंकि क्लाइंट कॉल में कोई टाइमआउट नहीं है। वे एक टाइमआउट और एक मैत्रीपूर्ण फॉलबैक जोड़ते हैं, सुधार की पुष्टि के लिए प्रयोग को फिर से चलाते हैं, और एक साझा दस्तावेज़ में दो-पैराग्राफ़ का नोट लिखते हैं। कुल लागत: एक दोपहर, और एक बहुत ही वास्तविक बग जो किसी ग्राहक के पकड़ने से पहले पकड़ लिया गया।

एंटरप्राइज़। एक वैश्विक बैंक को नियामकों के सामने गंभीर-लेकिन-संभावित परिदृश्यों के विरुद्ध परिचालन रेज़िलिएंस प्रदर्शित करनी होती है। इसकी रिलायबिलिटी टीम त्रैमासिक गेम डे के साथ-साथ प्रोडक्शन में स्वचालित प्रयोगों का एक कार्यक्रम चलाती है। एक परिदृश्य में कम-ट्रैफ़िक की खिड़की के दौरान प्राइमरी ट्रांज़ैक्शन डेटाबेस को इसके स्टैंडबाय पर फेल ओवर किया जाता है, जिसमें कड़ाई से नियंत्रित ब्लास्ट रेडियस और ट्रांज़ैक्शन सफलता दर से जुड़ी एबॉर्ट कंडीशन होती हैं। पहला रन यह उजागर करता है कि एक डाउनस्ट्रीम रीकॉन्सिलिएशन सेवा की रिट्राई पॉलिसी में कोई बैकऑफ़ नहीं है, जिससे एक लोड स्पाइक उत्पन्न होता है जो आपदा-पुनर्प्राप्ति योजना (अध्याय 9.5) में दिए गए रिकवरी-टाइम ऑब्जेक्टिव से कहीं आगे तक रिकवरी में देरी कर देता है। यह निष्कर्ष घटना रेट्रोस्पेक्टिव के समान ही बैकलॉग में जाता है, रिट्राई पॉलिसी को एक्सपोनेंशियल बैकऑफ़ से ठीक किया जाता है, और एक फॉलो-अप प्रयोग पुष्टि करता है कि फेलओवर अब लक्ष्य के भीतर पूरा हो जाता है। पूरा अभ्यास नियामक के लिए प्रमाण बन जाता है।

सरकार। नागरिक-केंद्रित लाभ पोर्टल संचालित करने वाली एक राष्ट्रीय एजेंसी को व्यवधानों के दौरान परिचालन की निरंतरता बनाए रखना आवश्यक है। अपनी निरंतरता योजना को ऐसे बाइंडर के रूप में मानने के बजाय जिसे कोई नहीं खोलता, एजेंसी एक वार्षिक निरंतरता अभ्यास को एक लाइव गेम डे के रूप में चलाती है। टीम एक प्राइमरी डेटा सेंटर के नुकसान का अनुकरण करती है और सेकेंडरी साइट पर फेलओवर से गुज़रती है, जबकि अलग से एक पहचान-सत्यापन (identity-verification) डिपेंडेंसी में लेटेंसी डालकर देखती है कि क्या पोर्टल सहजता से ख़राब होता है। वे यह जानते हैं कि एक अनपरखे मॉनिटरिंग गैप ने ऑन-कॉल टीम को पहचान सेवा के धीमे होने से अनजान रखा, जिससे अलर्ट देर से बजे। एजेंसी ऑब्ज़र्वेबिलिटी गैप को बंद करती है, अपने रनबुक अपडेट करती है, और अगले साल के लिए वही अभ्यास शेड्यूल करती है, जिससे एक अनुपालन आवश्यकता एक महत्वपूर्ण सार्वजनिक सेवा के लिए वास्तविक, परखी हुई रेज़िलिएंस में बदल जाती है।

बिज़नेस केस: प्रेरणाएँ, ROI, और TCO

कैओस इंजीनियरिंग पर प्रतिफल उन आउटेज से आता है जो कभी होती ही नहीं। किसी बड़ी सेवा के लिए एक भी बड़ी आउटेज की लागत खोए हुए राजस्व, नियामक जुर्माने, सुधार श्रम, और प्रतिष्ठा को होने वाले नुकसान में दसियों हज़ार से लेकर लाखों तक हो सकती है, जो सेवा बहाल होने के बहुत बाद तक बनी रहती है। कैओस प्रयोग उन अप्रत्याशित, महंगे आश्चर्यों को सस्ते, निर्धारित निष्कर्षों में बदल देते हैं जिन्हें आप इंजीनियरों की निगरानी और रोलबैक तैयार रखते हुए अपने समय पर ठीक करते हैं। किसी नियंत्रित गेम डे के दौरान एक टूटा हुआ टाइमआउट खोजने में एक दोपहर लगती है। किसी वास्तविक घटना के दौरान उसे खोजने में एक आउटेज, एक ऑल-हैंड्स भागदौड़, और आपके उपयोगकर्ताओं का विश्वास लगता है। यह गणित बड़े अंतर से गेम डे के पक्ष में जाता है।

एक बार पूर्वापेक्षाएँ मौजूद होने पर कुल स्वामित्व लागत (TCO) मामूली होती है, क्योंकि कैओस इंजीनियरिंग उन्हीं ऑब्ज़र्वेबिलिटी, अलर्टिंग, और रोलबैक निवेशों का पुन: उपयोग करती है जिनकी आपको वैसे भी ज़रूरत है। ईमानदार लागतें हैं: प्रयोग चलाने का इंजीनियरिंग समय, फ़ॉल्ट डालने और ब्लास्ट रेडियस को नियंत्रित रखने के लिए कुछ टूलिंग, और नेतृत्व को जानबूझकर विफलता उत्पन्न करने के साथ सहज बनाने का सांस्कृतिक कार्य। आखिरी वाली ही असली बाधा है, और इससे पार पाने का तरीका है स्टेजिंग में शुरुआत करना, ऐसे निष्कर्ष दिखाना जो धन या जोखिम से जुड़ते हों, और कुछ नियंत्रित प्रोडक्शन प्रयोगों को विश्वास बनाने देना। नेतृत्व के सामने पक्ष रखने के लिए, कैओस इंजीनियरिंग को ऐसे बीमा के रूप में प्रस्तुत करें जिसे आप माप सकते हैं: हाल की घटनाओं की लागत प्रस्तुत करें, दिखाएं कि उनमें से किसे एक रेज़िलिएंस प्रयोग पकड़ सकता था, और एक ऐसा कार्यक्रम प्रस्तावित करें जो छोटे स्तर से शुरू हो और तभी बढ़े जब वह खुद को साबित करे। नियमित और सार्वजनिक-क्षेत्र के परिवेशों में, अनुपालन का पहलू भी जोड़ें, क्योंकि परिचालन-रेज़िलिएंस परीक्षण और निरंतरता अभ्यास तेज़ी से अपेक्षित होते जा रहे हैं, और एक कैओस कार्यक्रम ही वह तरीका है जिससे आप कागज़ी कार्रवाई के बजाय प्रमाण के साथ इस अपेक्षा को पूरा करते हैं।

एंटी-पैटर्न और सामान्य गलतियाँ

• बिना ऑब्ज़र्वेबिलिटी के कैओस। ऐसे सिस्टम में फ़ॉल्ट डालना जिसे आप देख नहीं सकते, अतिरिक्त कदमों के साथ अंदाज़ा लगाना है; आप नुकसान पहुंचाएंगे और कुछ नहीं सीखेंगे।
• कोई स्थिर-स्थिति परिभाषा नहीं। स्वास्थ्य के किसी सहमत माप के बिना, आप यह नहीं बता सकते कि किसी प्रयोग ने कोई समस्या उजागर की या पैदा की।
• कोई परिकल्पना नहीं। यादृच्छिक रूप से चीज़ों को तोड़ना कैओस इंजीनियरिंग नहीं है; यह एक फैंसी नाम वाला और बिना किसी निष्कर्ष वाला तोड़फोड़ है।
• अनियंत्रित ब्लास्ट रेडियस। छोटे, सुरक्षित प्रयोगों को छोड़कर सीधे प्रोडक्शन-व्यापी विफलता पर जाना एक परीक्षण को स्वयं थोपी गई आउटेज में बदल देता है।
• कोई एबॉर्ट पथ नहीं। जिस प्रयोग को आप तुरंत रोक नहीं सकते, वह प्रयोग नहीं है; वह एक ट्रिगर की प्रतीक्षा में बैठी हुई घटना है।
• बहुत जल्दी स्वचालित करना। एक अपरिपक्व सिस्टम पर सतत कैओस अंतर्दृष्टि से ज़्यादा तेज़ी से घटनाएँ पैदा करता है।
• कहीं न पहुंचने वाले निष्कर्ष। किसी कमज़ोरी को खोजकर कभी ठीक न करना अभ्यास को व्यर्थ कर देता है और पूरे कार्यक्रम में विश्वास को कमज़ोर करता है।
• किसी बुरे प्रयोग के बाद दोषारोपण। जिस इंजीनियर ने ऐसा प्रयोग चलाया जिसने एक वास्तविक खामी उजागर की, उसे दंडित करना यह सुनिश्चित करता है कि अगला प्रयोग कोई नहीं चलाएगा।

परिपक्वता मॉडल

• स्तर 1, प्रारंभ (Initiate): रेज़िलिएंस मान ली जाती है, परखी नहीं जाती। विफलताएँ वास्तविक घटनाओं के दौरान प्रोडक्शन में खोजी जाती हैं। कोई गेम डे नहीं, कोई फ़ॉल्ट इंजेक्शन नहीं, और अक्सर यह कोई स्पष्ट परिभाषा नहीं कि स्वस्थ स्थिति कैसी दिखती है। टीम अपनी कमज़ोरियों के बारे में कठिन तरीके से सीखती है, एक बार में एक आउटेज।
• स्तर 2, विकास (Develop): टीम कभी-कभार गेम डे चलाती है, आमतौर पर स्टेजिंग में, एक परिभाषित परिदृश्य और परिकल्पना के साथ। कुछ प्रमुख सेवाओं के लिए स्थिर स्थिति परिभाषित है और बुनियादी ऑब्ज़र्वेबिलिटी मौजूद है। निष्कर्ष दर्ज किए जाते हैं और कुछ को ठीक किया जाता है, लेकिन यह अभ्यास टीमों में असंगत है और एक स्थापित पद्धति के बजाय व्यक्तिगत समर्थकों पर निर्भर करता है।
• स्तर 3, मानकीकरण (Standardize): कैओस प्रयोग एक दस्तावेज़ीकृत, संगठन-व्यापी अभ्यास हैं, जिसमें लागू ब्लास्ट-रेडियस नीतियां, एबॉर्ट कंडीशन, और तत्परता मानदंड हैं, जिन्हें किसी सेवा को प्रोडक्शन में प्रयोग करने से पहले पार करना होगा। प्रयोग नियंत्रित परिस्थितियों में प्रोडक्शन में चलते हैं, निष्कर्ष घटना रेट्रोस्पेक्टिव और आपदा-पुनर्प्राप्ति अभ्यासों के साथ-साथ एक साझा रेज़िलिएंस बैकलॉग में प्रवाहित होते हैं, और रेज़िलिएंस तंत्रों को मान लेने के बजाय सत्यापित किया जाता है। हर टीम एक ही प्लेबुक का पालन करती है।
• स्तर 4, प्रबंधन (Manage): कार्यक्रम को आधार रेखाओं (baselines) के विरुद्ध डेटा के साथ मापा और नियंत्रित किया जाता है। आप रेज़िलिएंस कवरेज को ट्रैक करते हैं (कौन-सी महत्वपूर्ण सेवाएँ और कौन-से तंत्र, जैसे टाइमआउट, रिट्राई, सर्किट ब्रेकर, और फेलओवर, किसी वास्तविक डाले गए फ़ॉल्ट के तहत सत्यापित किए गए हैं और कितने हाल में), वह दर जिस पर प्रयोग निष्कर्ष सामने लाते हैं, किसी रेज़िलिएंस निष्कर्ष को बंद करने का औसत समय, और यह कितनी बार होता है कि पहले सत्यापित किया गया तंत्र वापस बिगड़ जाता है। इन मेट्रिक्स की समीक्षा एक निश्चित अवधि पर की जाती है, प्रोडक्शन प्रमोशन राय के बजाय प्रमाण पर आधारित होता है, और प्रयोगों को अभी भी असत्यापित तंत्रों के मापे गए जोखिम के अनुसार प्राथमिकता दी जाती है।
• स्तर 5, ऑर्केस्ट्रेशन (Orchestrate): प्रयोगों का एक चुना हुआ सेट निरंतर और स्वचालित रूप से चलता है, दिनों के भीतर गिरावट पकड़ लेता है, और सिस्टम तथा उसकी जोखिम तस्वीर बदलने पर कार्यक्रम भी अनुकूलित होता है। कैओस इंजीनियरिंग पूरे संगठन में डिलीवरी पाइपलाइन, घटना से सीख, और आपदा-पुनर्प्राप्ति परीक्षण के साथ एकीकृत है, ताकि नई सेवाओं को डिफ़ॉल्ट रूप से रेज़िलिएंस सत्यापन विरासत में मिले। रेज़िलिएंस सिस्टम की एक सतत सत्यापित विशेषता है, और नेतृत्व कार्यक्रम को किसी विशेष पहल के बजाय मानक जोखिम प्रबंधन के रूप में मानता है जिसे प्रमाण के आधार पर निखारा जाता है।

चर्चा के लिए विचार

1. आप कैसे तय करते हैं कि आपके संगठन में कौन-सी सेवा सबसे पहले प्रोडक्शन में कैओस प्रयोग चलाने का अधिकार अर्जित करती है, और उससे पहले क्या सच होना चाहिए?
2. जब कोई कैओस प्रयोग कोई गंभीर कमज़ोरी सामने लाता है, तो सुधार का स्वामी कौन होता है, और आप उस निष्कर्ष को बैकलॉग में बिना छुए पड़े रहने से कैसे रोकते हैं?
3. आपके संदर्भ में एक कैओस प्रयोग, एक आपदा-पुनर्प्राप्ति अभ्यास, और एक गेम डे के बीच रेखा कहां है, और क्या यह अंतर इस बात के लिए भी मायने रखता है कि आप उनकी योजना कैसे बनाते हैं?
4. आप किसी संशयवादी कार्यकारी को कैसे समझाएंगे कि प्रोडक्शन में जानबूझकर विफलता डालना वास्तविक आउटेज की प्रतीक्षा करने की यथास्थिति से ज़्यादा सुरक्षित है?
5. अगले महीने आपकी टीम जो सबसे छोटा, सबसे मूल्यवान पहला प्रयोग चला सकती है, वह क्या है, और उसे चलाने से आपको क्या रोकेगा?
6. एक निरंतरता-अनिवार्यता वाली नागरिक-केंद्रित सार्वजनिक सेवा और एक छोटे उपयोगकर्ता आधार वाले आंतरिक एंटरप्राइज़ टूल के बीच रेज़िलिएंस टेस्टिंग किस तरह अलग होनी चाहिए?

मुख्य निष्कर्ष

• कैओस इंजीनियरिंग रेज़िलिएंस पर विश्वास बनाने के लिए अनुशासित, परिकल्पना-आधारित प्रयोग है, यादृच्छिक तोड़फोड़ नहीं।
• एक भी फ़ॉल्ट डालने से पहले ऑब्ज़र्वेबिलिटी, एक स्थिर-स्थिति परिभाषा, और एक तेज़ रोलबैक स्थापित करें।
• यथार्थवादी फ़ॉल्ट डालें (लेटेंसी, त्रुटियाँ, रिसोर्स एग्ज़ॉशन, डिपेंडेंसी विफलता) और यह सत्यापित करने के लिए उनका उपयोग करें कि टाइमआउट, रिट्राई, सर्किट ब्रेकर, और फेलओवर वास्तव में काम करते हैं।
• टेबलटॉप एक्सरसाइज़ और गेम डे से शुरुआत करें, जानबूझकर ब्लास्ट रेडियस को नियंत्रित रखें, और प्रोडक्शन तथा स्वचालन की ओर अपना रास्ता अर्जित करें।
• प्रयोगों को आपदा-पुनर्प्राप्ति परीक्षण (अध्याय 9.5) और घटना से सीख (अध्याय 9.3) के साथ जोड़ें ताकि निष्कर्ष एक ही रेज़िलिएंस बैकलॉग में संचित हों।
• निष्कर्षों को दोषरहित तरीके से देखें और उन्हें ठीक करें; जिस प्रयोग का सबक अनसुलझा रह जाता है, वह किसी प्रयोग के न होने से भी बदतर है।

संदर्भ और आगे पढ़ने के लिए

• Casey Rosenthal, Nora Jones, Chaos Engineering: System Resiliency in Practice
• Russ Miles, Learning Chaos Engineering: Discovering and Overcoming System Weaknesses Through Experimentation
• Mikolaj Pawlikowski, Chaos Engineering: Crash Test Your Applications
• Ali Basiri et al., Chaos Engineering (IEEE Software, 2016)
• Betsy Beyer, Chris Jones, Jennifer Petoff, Niall Richard Murphy, Site Reliability Engineering: How Google Runs Production Systems
• Michael T. Nygard, Release It! Design and Deploy Production-Ready Software
• Principles of Chaos Engineering, principlesofchaos.org