उत्पादन बग पर प्रतीक्षा की लागत

टीमें अक्सर उत्पादन बग के बारे में इस तरह बात करती हैं जैसे कि लागत दोष के अंदर निहित हो। एक ख़राब सशर्त भेज दिया गया. एक माइग्रेशन से एक किनारे का मामला छूट गया। कतार में खड़े एक उपभोक्ता ने बहुत आक्रामक ढंग से पुनः प्रयास किया। कोड ठीक करें और लागत समाप्त हो जाएगी।

वह दृश्य बहुत छोटा है.

उत्पादन बग की लागत केवल कोड की वह पंक्ति नहीं है जिसके कारण यह हुआ। यह वह समय है जो संगठन इसके आसपास रहकर व्यतीत करता है।

इंतज़ार घटना का रूप बदल देता है

एक बग जिसे पांच मिनट में ठीक कर दिया जाता है वह आमतौर पर एक कोड समस्या होती है। एक बग जो एक घंटे तक प्रतीक्षा करता है वह समन्वय समस्या बन जाता है। एक बग जो एक दिन तक प्रतीक्षा करता है वह विश्वास की समस्या बन जाता है।

एक ही अंतर्निहित दोष कितने समय तक जीवित रहता है इसके आधार पर बहुत भिन्न क्षति पैदा कर सकता है:

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

इनमें से कोई भी लागत विदेशी नहीं है। वे सामान्य उत्पादन ड्रैग हैं।

एमटीटीआर कुछ महंगे मिनटों से चूक गया

पुनर्प्राप्ति के लिए औसत समय उपयोगी है, लेकिन यह उन क्षणों को छिपा सकता है जो सबसे अधिक बर्बादी पैदा करते हैं।

घड़ी आमतौर पर तब शुरू होती है जब किसी समस्या का पता चलता है और जब सेवा पुनर्प्राप्त मानी जाती है तो बंद हो जाती है। यह विश्वसनीयता के बारे में कुछ महत्वपूर्ण बात कहता है। यह आपको यह नहीं बताता कि घटना का कितना समय विफलता को समझने, मालिक को ढूंढने, सबूत इकट्ठा करने, या समीक्षा योग्य परिवर्तन की प्रतीक्षा करने में व्यतीत हुआ।

सुधार कार्यप्रवाह के लिए, महंगा अंतर अक्सर इस तरह दिखता है:

alert -> evidence -> code path -> owner -> patch -> review -> deploy

यदि टीम पहले चार चरणों को संपीड़ित कर सकती है, तो कोड समीक्षा पहले शुरू हो जाती है और अंतिम निर्धारण का मूल्यांकन करना आसान हो जाता है।

संदर्भ क्षय वास्तविक लागत है

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

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

त्वरित निवारण केवल गति के बारे में नहीं है। यह संदर्भ को संरक्षित करने के बारे में है जबकि टीम के पास यह अभी भी है।

लागत हमेशा इंजीनियरिंग डैशबोर्ड में दिखाई नहीं देती है

कुछ उत्पादन मुद्दे टेलीमेट्री में मामूली दिखते हैं और फिर भी व्यवसाय को नुकसान पहुंचाते हैं।

अनुमति बग कम संख्या में उच्च-मूल्य वाले खातों को प्रभावित कर सकता है। मैन्युअल वित्त कार्य बनाते समय बिलिंग-स्टेट बग कम-वॉल्यूम एज केस के रूप में दिखाई दे सकता है। चेकआउट समस्या एक क्षेत्र में केवल एक भुगतान विधि को प्रभावित कर सकती है, लेकिन समर्थन प्रभाव तत्काल हो सकता है।

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

जिससे प्रतीक्षा लागत कम हो जाती है

जब टीमें जांच और समीक्षा एक ही लूप में करती हैं तो प्रतीक्षा लागत कम हो जाती है।

इसका मतलब है:

• अलर्ट प्रासंगिक निशानों और लॉग से जुड़ा हुआ है
• विफलता विंडो की तुलना परिनियोजन से की जाती है
• संदिग्ध कोड पथ का नाम दिया गया है
• स्वामित्व का समाधान स्वचालित रूप से हो जाता है
• प्रस्तावित पैच समीक्षा के लिए काफी छोटा है
• आत्मविश्वासपूर्ण शब्दों के पीछे अनिश्चितता छिपी होने के बजाय दिखाई देती है

यहीं पर एआई-सहायता प्राप्त उपचार उपयोगी है। इसे गुप्त उत्पादन परिवर्तन नहीं करना चाहिए. इसे साक्ष्य तैयार करना चाहिए, सबसे छोटे विश्वसनीय सुधार का मसौदा तैयार करना चाहिए, और मालिक को एक पुल अनुरोध सौंपना चाहिए जिसे स्वीकार, संपादित या अस्वीकार किया जा सकता है।

वास्तविक माप अच्छे निर्णय का समय है

एक टीम इसलिए नहीं जीतती क्योंकि एक बॉट जल्दी से अंतर पैदा कर देता है। यह तब जीतता है जब सही समीक्षक जल्दी ही कोई अच्छा निर्णय ले लेता है।

कभी-कभी वह निर्णय "मर्ज फिक्स" होता है। कभी-कभी यह "रोल बैक" होता है। कभी-कभी ऐसा होता है "यह एक अपस्ट्रीम घटना है।" कभी-कभी ऐसा होता है कि "हमें मानवीय जांच की ज़रूरत है, पैच की नहीं।"

प्रतीक्षा करना महंगा है क्योंकि इससे उन सभी निर्णयों में देरी होती है। लक्ष्य उन्मत्त स्वचालन नहीं है. लक्ष्य उत्पादन संकेत से साक्ष्य-समर्थित कार्रवाई तक का एक छोटा रास्ता है।