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