1.5 डेटा स्रोत और इंस्ट्रूमेंटेशन

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

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

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

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

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

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

सिफ़ारिशें

भरोसा करने से पहले हर मेट्रिक को उसके वास्तविक स्रोत सिस्टम से मैप करें

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

रिपोर्ट पर नहीं, घटना पर इंस्ट्रूमेंट करें

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

सर्वेक्षणों को केवल उसके लिए आरक्षित रखें जो केवल एक व्यक्ति ही आपको बता सकता है

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

पाइपलाइन में ही डेटा-गुणवत्ता जाँच बनाएँ

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

परिभाषा के साथ-साथ संग्रह विधि को दस्तावेज़ीकृत करें

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

समझौते: लाभ और हानि

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

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

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

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

क्षेत्र दृष्टिकोण

स्टार्टअप। एक छोटे स्टैक के साथ, आपके अधिकांश मेट्रिक्स सीधे आपके CI/CD प्रदाता, वर्ज़न कंट्रोल होस्ट, और एक हल्के सर्वेक्षण उपकरण से आ सकते हैं, बिना कस्टम पाइपलाइन बनाए। जोखिम बुनियादी स्वास्थ्य जाँच को भी छोड़ देना है क्योंकि टीम तेज़ी से आगे बढ़ रही है; एक पाँच-मिनट की स्वचालित जाँच कि एक डेटा स्रोत अभी भी घटनाएँ भेज रहा है, चुपचाप अंधे उड़ने के विरुद्ध सस्ता बीमा है।

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

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

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

उदाहरण

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

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

व्यावसायिक तर्क: प्रेरणाएँ, ROI, और TCO

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

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

विरोधी-पैटर्न और नुक़सान

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

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

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

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

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

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

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

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

Observability Engineering, Charity Majors, Liz Fong-Jones, और George Miranda द्वारा (इंस्ट्रूमेंटेशन और टेलीमेट्री डिज़ाइन सिद्धांत)।
Accelerate: The Science of Lean Software and DevOps, Nicole Forsgren, Jez Humble, और Gene Kim द्वारा (DORA मेट्रिक्स के पीछे का इंस्ट्रूमेंटेशन दृष्टिकोण)।
Data Quality: The Accuracy Dimension, Jack E. Olson द्वारा (मेट्रिक्स पाइपलाइनों पर लागू डेटा-गुणवत्ता अवधारणाएँ)।
How to Measure Anything, Douglas W. Hubbard द्वारा (उन मात्राओं के लिए मापन विधियाँ जो सीधे देखने में कठिन लगती हैं)।