ऑपरेशनल हैंडऑफ़ वह पल है जब ऑन-साइट बनाया गया सिस्टम, जिसे पहले ‘फ़ॉरवर्ड डिप्लॉयड इंजीनियर’ (FDE) अपनी समझ से चलाता था, अब कस्टमर की टीम उसे सोच-समझकर और योजना के साथ चला सकती है। ऑपरेशनल हैंडऑफ़ का मतलब है कि कस्टमर रोज़ाना सिस्टम को चला सकता है, खराबी आने पर उसे ठीक (डीबग) कर सकता है, और आपकी मौजूदगी के बिना उसमें सुरक्षित बदलाव कर सकता है।
इस स्थिति पर विचार करें। आपने HarborView Insurance के लिए AI-आधारित इंटरनल ‘क्लेम्स ट्राइएज सर्विस’ बनाई है, जो Kubernetes पर चलती है और इसमें PostgreSQL डेटाबेस, Redis कैश और इंटरनल गेटवे के पीछे मॉडल कॉल्स शामिल हैं। पायलट प्रोजेक्ट सफल रहा, लीडरशिप चाहती है कि आप इसे प्रोडक्शन में लाएँ, और तीन हफ़्ते बाद आपको साइट से जाना है।
इस आखिरी दौर में, असली सवाल यह नहीं है कि सिस्टम आज काम कर रहा है या नहीं। सवाल यह है कि क्या HarborView मंगलवार की रात को किसी घटना (इंसिडेंट) के दौरान इसे चालू रख सकता है, और क्या वे अगली तिमाही में बिना किसी सुरक्षा खामी या भरोसेमंदता (रिलायबिलिटी) की समस्या पैदा किए इसमें बदलाव कर सकते हैं।
हैंडऑफ़ अक्सर इसलिए फ़ेल हो जाता है क्योंकि हर कोई “काम पूरा होने” (done) शब्द का अलग-अलग मतलब निकालता है। आपके लिए इसका मतलब हो सकता है कि बैकलॉग साफ़ हो गया है और डैशबोर्ड हरे (सही स्थिति) दिख रहे हैं। कस्टमर के लिए इसका मतलब हो सकता है कि वे आपको बुलाए बिना डिप्लॉयमेंट कर सकते हैं, और उनकी सिक्योरिटी टीम ने एक्सेस और लॉगिंग को मंज़ूरी दे दी है।
“काम पूरा होने” (done) को रिलायबिलिटी, सिक्योरिटी और डिलीवरी ओनरशिप से जुड़े सफलता के पैमानों (सक्सेस क्राइटेरिया) के तौर पर परिभाषित करें। आप ज़ीरो इंसिडेंट (कोई भी घटना न होने) की गारंटी नहीं दे रहे हैं। आप यह पक्का करने की कोशिश कर रहे हैं कि जब कोई घटना हो, तो कस्टमर आपकी निजी जानकारी या संदर्भ (प्राइवेट कॉन्टेक्स्ट) के बिना उसे पहचान सके, उसकी वजह पता कर सके और सिस्टम को ठीक कर सके।
हैंडऑफ़ सच में पूरा हुआ है या नहीं, इसे मापने का एक आसान तरीका जानें।
आगे बढ़ने के लिए ज़रूरी सिद्धांत यह है कि हर सफलता के मानदंड (success criterion) के लिए एक मालिक (owner) और एक सबूत (proof point) की ज़रूरत होती है। सबूत का मतलब है कोई ऐसी चीज़ जिसे आप दिखा सकें, जैसे कि रनबुक का लिंक, पूरी हो चुकी एक्सेस रिक्वेस्ट, ऑन-कॉल रोटेशन एंट्री, या कस्टमर टीम द्वारा आपके देखते हुए किया गया सफल डिप्लॉयमेंट।
वादों से बेहतर सबूत अगर हैंडऑफ़ की किसी ज़रूरत को एक छोटे से रिव्यू में वेरिफ़ाई नहीं किया जा सकता, तो वह अभी कोई ज़रूरत नहीं है।
जब हैंडऑफ़ कमज़ोर होता है, तो पहली आउटेज (सेवा में रुकावट) एक दूसरी समस्या पैदा करती है। आउटेज तकनीकी होती है, और दूसरी समस्या होती है ज़िम्मेदारी को लेकर उलझन, जिससे आउटेज लंबी खिंच जाती है और एक-दूसरे पर दोष मढ़ने का सिलसिला शुरू हो जाता है।
कल्पना कीजिए कि HarborView को एक अलर्ट मिलता है कि p95 लेटेंसी दोगुनी हो गई है और रिक्वेस्ट टाइम-आउट हो रही हैं। ऑन-कॉल इंजीनियर डैशबोर्ड खोलता है और देखता है कि एक साथ दस अलर्ट आ रहे हैं। उन्हें पता नहीं होता कि कौन सा अलर्ट ज़रूरी है, उनके पास प्रोडक्शन में Kubernetes डिप्लॉयमेंट को रीस्टार्ट करने की परमिशन नहीं होती, और उन्हें ऐसी कोई रनबुक नहीं मिलती जिसमें बताया गया हो कि मॉडल गेटवे के लिए “सामान्य” स्थिति कैसी दिखती है।
वे आपको पेज (संपर्क) करते हैं, आप बिल्ड के दौरान सीखी गई तीन बातें बताते हैं, और सिस्टम वापस चालू हो जाता है। दो हफ़्ते बाद ऐसा फिर होता है, लेकिन इस बार आप फ़्लाइट में होते हैं, और आउटेज तीन घंटे ज़्यादा लंबी चलती है। इसकी मूल वजह शायद कैश स्टैम्पीड (cache stampede) या गलत साइज़ वाला डेटाबेस कनेक्शन पूल हो सकती है, लेकिन ज़्यादा समय तक चलने की वजह ऑपरेशनल बुनियादी बातों की कमी थी, न कि बग।
देखिए कि कैसे हैंडऑफ़ में छोटी-मोटी कमियां लंबी घटनाओं और ज़िम्मेदारी तय करने में उलझन का कारण बन जाती हैं।