आपकी आधी सर्विस एक साथ टाइम आउट होने लगती हैं और डिप्लॉय कुछ हुआ ही नहीं। आप वह इंसिडेंट कैसे चलाएंगे?

इंसिडेंट घोषित करें, एक incident commander तय करें, और जांच को संवाद से अलग रखें। फिर साझा डिपेंडेंसी खोजें: authentication, DNS, कोई डेटाबेस, कोई सर्टिफिकेट, service mesh का control plane, या कोई क्लाउड zone। देखें कि डिप्लॉय के बाहर क्या बदला, यानी config push, feature flag, DNS रिकॉर्ड, एक्सपायर होते सर्टिफिकेट, और प्रोवाइडर का status। निदान से पहले राहत दें, यानी लोड गिराएं, failover करें, या शक वाला flag बंद करें, फिर यूजर को दिखने वाले SLI से जांचें।

बिना डिप्लॉय के चौड़ी और एक साथ आई खराबी लगभग कभी दस अलग अलग बग नहीं होती, वह उन सबके नीचे बैठी एक ही चीज होती है। तो मैं फौरन इंसिडेंट का ढांचा खड़ा करता हूं, एक commander और एक संवाद संभालने वाला, फिर साझा परतों की लिस्ट पर लगता हूं: auth सर्विस, DNS, मुख्य डेटाबेस, mesh का control plane, सर्टिफिकेट, और क्लाउड प्रोवाइडर की सेहत। साथ ही मैं पूछता हूं कि कोड के अलावा क्या बदला, क्योंकि config push और feature flag ऐसे बदलाव हैं जिन्हें लोग गिनना भूल जाते हैं। हमारे साथ ठीक यही पैटर्न एक बार आया था और निकला कि एक अंदरूनी certificate authority का नवीनीकरण ऐसा था कि एक intermediate चुपचाप एक्सपायर हो गया, तो हर mutual TLS handshake एक ही मिनट में फेल होने लगा। पहचान यह थी कि नाकामियां एप्लिकेशन स्तर की नहीं, कनेक्शन स्तर की थीं। वह जांच चलते हुए मैं राहत का एक लीवर तैयार रखना चाहता हूं, आम तौर पर गैरजरूरी ट्रैफिक गिराना या दूसरे region पर failover, क्योंकि सोचते वक्त पूरी तरह टूटे रहने से मुझे खराब हालत में पर स्थिर रहना बेहतर लगता है। फिर सिर्फ हरे pod नहीं, असली यूजर मेट्रिक्स से जांच करता हूं।