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