DevOps परिप्रेक्ष्य से तकनीकी ऋण कैसे बेचें?

अक्सर नाटकीय और दयनीय ढंग से यह तर्क दिया जाता है कि तकनीकी ऋण न बनाना ही बेहतर है। हां, बेशक इसके बिना यह बेहतर है। लेकिन इसके दुष्परिणामों को अभी भी ख़त्म किया जा सकता है।

मैं तकनीकी ऋण को सभी परिवर्तनों और सुधारों, ढांचागत संशोधनों और प्रक्रिया परिवर्तनों, अंतराल को खत्म करने के उद्देश्य से टीम संरचनाओं में बदलाव (उत्पादों को लॉन्च करने के ढांचे के भीतर सचेत रूप से या नहीं) के रूप में संदर्भित करता हूं, और ऐसी विशेषताएं जो समय के साथ बहुत हस्तक्षेप करती हैं।

और चूंकि ऐसी चीजें उत्पादन और संचालन विभागों की दृढ़ और भरोसेमंद टीमप्ले के बिना तय नहीं की जा सकती हैं, इसलिए यह कहानी सीधे DevOps के बारे में है।

तकनीकी ऋण - यह किसका है?

लेकिन सबसे पहले, समस्या की जड़ - मैं तकनीकी ऋण के बारे में बात क्यों कर रहा हूँ? क्योंकि मैं इस बात से बहुत आहत हूं कि व्यवसाय इसके लिए समय आवंटित नहीं करता है। यह लाल धागा डेवलपर्स और संचालन के बीच सभी रिपोर्ट, मीटअप और संचार के माध्यम से चलता है।

दुष्ट, बुरा, भयानक व्यवसाय तकनीकी ऋण के साथ काम करने के लिए समय आवंटित नहीं करता है। यहाँ तक कि एक उचित प्रश्न भी उठता है: "क्या उन्हें गुणवत्ता की बिल्कुल भी आवश्यकता नहीं है?" आगे देखते हुए, मैं कहूंगा: "किसी को भी गुणवत्ता की आवश्यकता नहीं है।" लेकिन मैं इस विचार को थोड़ी देर बाद प्रकट करूंगा।

इस स्थिति का विश्लेषण करने के लिए, आइए विचार करें कि व्यवसाय हमारे साथ ऐसा क्यों करता है। और उत्तर पाने के लिए हमें यह सोचना होगा कि तकनीकी ऋण किसका है। इसके लिए कौन जिम्मेदार है?

वर्षों की भागीदारी के बाद, मुझे एहसास हुआ कि हम फ्रोडो की तरह थे, जिन्होंने हर किसी को एक अंगूठी की पेशकश की। यह ऐसा है, "इस बोझ को उठाने में मेरी मदद करो!" हम तकनीकी ऋण से निपटने के लिए व्यवसायों की इच्छा (वास्तव में चाहते हैं) की प्रतीक्षा कर रहे हैं। लेकिन व्यापार के साथ हमारी आपसी ग़लतफ़हमी का मूल कारण यह है कि वह ऐसा कभी नहीं चाहेगा।

हमारे लिए, यह एक इंजीनियरिंग चुनौती है, उत्पाद उत्कृष्टता में सुधार करने का एक तरीका है, या यहां तक कि हमारे उत्पाद में गौरव बढ़ाने का एक तंत्र भी है। लेकिन व्यवसाय के लिए, यह हमेशा एक उपद्रव, एक आवश्यक बुराई (या आवश्यकता) है जिस पर आपको समय व्यतीत करना होगा।

कल्पना कीजिए कि आप एक कैब में बैठते हैं, और ड्राइवर पूछता है, "क्या मैं कार धोने के स्थान पर रुक सकता हूँ?"

इस स्थिति में व्यवसाय एक ग्राहक है, और डेवलपर्स कैब ड्राइवर हैं।

• व्यवसाय क्रोधित है: "कैसे?! मैं यात्रा के समय का भुगतान कर रहा हूं, और आप कार धोने जा रहे हैं!"

• जिस पर कैब ड्राइवर तर्कसंगत रूप से उत्तर देता है: "क्या आप एक साफ सुथरी कार में यात्रा नहीं करना चाहते हैं जिसमें अच्छी खुशबू आ रही हो?"

• व्यवसाय उत्तर देता है: "यार, बेशक मैं करता हूँ! लेकिन मैं डिफ़ॉल्ट रूप से इसकी अपेक्षा करता हूँ, और मैं अब इसके लिए कार धोने पर रुकने के लिए तैयार नहीं हूँ!"

इस प्रकार व्यवसाय तकनीकी ऋण का इलाज करते हैं। यह कार धोने के लिए रुकने के सुझाव की तरह है। साफ़-सुथरे या लक्ज़री सैलून के लिए कैब ऑर्डर करते समय मैं उपयुक्त श्रेणी का चयन करता हूँ। ऑर्डर देने के चरण में, मैं इसमें निवेश करने को तैयार हूं, लेकिन कार धोने के लिए रुकना संभव नहीं है।

क्योंकि, जैसा कि मैंने पहले कहा, कोई भी गुणवत्ता नहीं चाहता। लेकिन यह डिफ़ॉल्ट रूप से अपेक्षित है.

यह बहुत जरूरी है। व्यवसाय स्वयं कार धोने के लिए न जाने का त्याग नहीं कर सकते हैं, और व्यवसाय अपने समय की कीमत पर वहां नहीं जा सकते हैं। तो हम क्या करें? एक व्यवसाय एक लोकोमोटिव है. इसे सुविधाओं, बिक्री और ग्राहकों की आवश्यकता है। हमारे "मैं चाहता हूँ" और "मैं चाहता हूँ" के माध्यम से किसी व्यवसाय को तकनीकी ऋण बेचना असंभव है। लेकिन व्यवसाय को दूसरे तरीके से प्रेरित करना संभव है।

अपनी यात्रा के दौरान, मैंने तकनीकी ऋण "खरीदने" के लिए व्यावसायिक प्रेरणा की 3 श्रेणियां बनाई हैं:

• "मोटी" उदासीनता. जब कोई अमीर निवेशक होता है, तो सीईओ अजीब गीक्स की विकास टीम का खर्च उठा सकता है। यह ऐसा है, "ठीक है, उन्हें ऐसा करने दो! मुख्य बात उत्पाद को पूरा करना है, और टीम भावना वाह, सब कुछ अच्छा है, और हम दुनिया में सबसे अच्छे कार्यालय होंगे"।

  
  

  मेरे विचार में, यह एक शानदार फ्रीस्टाइल है जो अक्सर आपदा की ओर ले जाती है क्योंकि तकनीकी ऋण के लिए व्यावहारिकता की आवश्यकता होती है। जब हम इसे व्यावहारिक रूप से नहीं करते हैं, तो हम छद्म-शांत वास्तुकला का लेविथान बनाते हैं।

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

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

इसके बाद, मैं अपने अनुभव और मेरे और मेरी अद्भुत टीम के लिए क्या काम कर रहा है, इस पर चर्चा करूंगा।

तकनीकी ऋण के साथ खरगोश का छेद कितना गहरा है?

जब मैं 3 साल पहले नई कंपनी में शामिल हुआ, तो मुझे यह समझने की ज़रूरत थी कि यह तकनीकी ऋण कितना था। मुझे पता था कि यह अनुरोधों के आँकड़ों से मौजूद था, जिसमें व्यवसायों और भागीदारों के अनुरोध भी शामिल थे। मुझे यह पता लगाने की ज़रूरत थी कि मैं आम तौर पर किसके साथ काम कर रहा था।

तकनीकी ऋण के साथ काम करने में यह एक सामान्य और अनिवार्य पहला कदम है। आपको जो पहला काम मिले उसे करने में जल्दबाजी नहीं करनी चाहिए। आपको स्थिति का समग्र रूप से विश्लेषण करना चाहिए।

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

हमारे एप्लिकेशन में कम से कम 80 अलग-अलग घटक थे (वितरण, इंस्टॉलेशन नहीं)। स्थिति का पता लगाने के बाद उससे निपटना पड़ा.

चरण 1. आभासी टीमें

इतना चतुर होने के कारण, मेरे मन में यह विचार आया कि मैं दिखावा करूँगा कि सभी के पास समय है और प्रत्येक घटक के इर्द-गिर्द एक आभासी टीम बनाऊँगा। ऐसा लग रहा था, "दोस्तों, किस घटक को कौन लेगा? इसे कैसे सुधारें इस पर अपने सुझाव दें।" लेकिन ध्यान केंद्रित रहने के लिए, हम सभी ने मिलकर पहले चरण को अनुकूलित करने के लिए मानदंड तैयार किए:

• लूस कपलिंग
• लागत प्रभावी मापनीयता
• नए डेवलपर्स का आसान कनेक्शन (सरल और स्पष्ट सिद्धांत: इस घटक में वास्तव में क्या किया जा सकता है और क्या नहीं, साथ ही कोड का अलगाव जिसे हर कोई "छुआ" नहीं सकता है)
• जहां आवश्यक हो वहां बाहरी एपीआई का उपयोग करने की क्षमता
• प्रस्तावित प्रौद्योगिकी स्टैक की पहुंच
• वर्तमान समाधानों में क्विकविन अनुकूलन
• निगरानी और समस्या निवारण में आसानी
• ऑडिट + लाइसेंस शुद्धता सिद्धांत
• वर्जनिंग और अप्रचलन सिद्धांत

बेशक, यह कोई फोकस नहीं था बल्कि सॉफ्टवेयर विकास के लगभग सभी पहलुओं के लिए मानदंडों का एक सेट था। पूरी सूची को एक वाक्यांश से बदला जा सकता है: "सब कुछ ठीक करें।"

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

इसलिए, मैं चरण 2 पर चला गया।

चरण 2. तकनीकी ऋण मेरा है

चरण 1 में, मैं हमारी कंपनी के सीईओ से सहमत था कि हम एक बैकलॉग कोटा शुरू करेंगे। हम व्यावसायिक मुद्दों पर 70%, दोष उन्मूलन पर 15% और तकनीकी ऋण पर 15% खर्च करेंगे।

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

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

और इसलिए हम चल पड़े। तकनीकी नेता (प्रभारी) होते हैं और तकनीकी ऋण के लिए 15% कोटा होता है (समय है)। लेकिन आखिर में हकीकत क्या दिखी?

पहली चीज़ जिसका हमें सामना करना पड़ा वह यह थी कि हमारे पास फिनटेक, अनुपालन और कर्तव्यों का पृथक्करण है, यानी, मेरे और विकास के पास उत्पादन तक कोई पहुंच नहीं है और परिभाषा के अनुसार यह नहीं हो सकता है। और फिर भी, मैं कहता हूं, "दोस्तों, उत्पादन की स्थिति के लिए आप जिम्मेदार हैं!"

लोगों को लॉग दें!

जब आप लोगों को जिम्मेदारी देते हैं, तो कृपया उनके हाथों में एक उपकरण भी दें। और यह पहला काम है जो हमने ओपीएस विशेषज्ञों के साथ किया, तकनीशियनों को लॉग प्रदान किया ताकि वे अपने घटकों के लॉग देख सकें।

और हमारा वास्तव में सहयोगात्मक प्रयास था - DevOps की ओर हमारा पहला कदम, जहां संचालन और विकास एक साथ काम करते हैं। शोषण ने लॉग ट्रांसफर (किबाना, आदि) की स्थापना की, जबकि विकास को यह सुनिश्चित करना था कि लॉग में संवेदनशील जानकारी (व्यक्तिगत डेटा, आदि) न हो।

5% को भाग्यशाली माना जाता है...

वास्तविकता यह है कि 15% कोटा के बावजूद, प्रत्येक स्प्रिंट में कुछ व्यावसायिक संकट और तत्काल इंजेक्शन होते हैं क्योंकि "साझेदार को अभी इसकी आवश्यकता है, या वह छोड़ देगा!" बेशक, इस तकनीकी ऋण को सबसे पहले स्प्रिंट से बाहर धकेला जाता है - परिणामस्वरूप, हमारे पास 0% के साथ स्प्रिंट थे।

15% के साथ स्प्रिंट भी थे, लेकिन हमारे पास औसतन केवल 5-8% तकनीकी ऋण था। यह एक बड़ी समस्या है क्योंकि एक प्रोग्रामर यह नहीं जान सकता कि उसके पास कार्यान्वयन के लिए कितना समय होगा।

अपनी ओर से, मैंने सभी टीमों के ऊपर अथक रूप से पतंग उड़ाकर इस स्थिति में मदद करने की कोशिश की। हमने प्रत्येक स्प्रिंट के लिए विस्तृत मेट्रिक्स एकत्र करना सीखा, और मैंने अंत में स्प्रिंट को देखा।

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

लेकिन जब इसे व्यवस्थित रूप से दोहराया गया, तो मैंने उत्पादन विशेषज्ञों को इकट्ठा किया, तर्क दिया और समझाया कि यह कितना महत्वपूर्ण और अस्वीकार्य था क्योंकि कोटा पर सहमति हो गई थी। उस मॉडल में प्रक्रिया को आगे बढ़ाना मेरा दैनिक कार्य था।

और यह आगे बढ़ा, लेकिन अब मेरा मानना है कि इस दृष्टिकोण की अपनी महत्वपूर्ण कमियां हैं।

दृष्टिकोण की सीमाएँ

उत्पाद मालिक इस तथ्य के आदी हैं कि सारा बैकलॉग उनका है और सभी कार्यों का समन्वय उनके द्वारा किया जाता है: "कोटा अच्छा है, लेकिन केवल हम ही तय करते हैं कि तकनीकी ऋण के इस कोटा में टीम क्या करेगी!"

और जब डेवलपर्स रिफैक्टरिंग, बॉयलरप्लेट्स को खत्म करने आदि जैसे कार्यों (मजबूत कनेक्टिविटी के बारे में याद रखें) के साथ आए, तो उन्हें एक तार्किक प्रतिक्रिया मिली: "क्या?! कौन सा बॉयलरप्लेट? हम किस बारे में बात कर रहे हैं?"

परिणामस्वरूप, कार्यों को उन कार्यों से प्रतिस्थापित कर दिया गया जिन्हें तकनीकी ऋण के रूप में संदर्भित किया जा सकता था लेकिन वे विक्रेता के लिए सशर्त रूप से फायदेमंद थे। इसीलिए मुझे सख्त रुख अपनाना पड़ा और कहना पड़ा: "तकनीकी ऋण मेरा है! और मेरा दावा है कि इसे प्रत्येक स्प्रिंट के लिए तकनीकी ऋण के कोटा में प्रत्येक उत्पाद टीम के तकनीकी ऋण में शामिल किया जाएगा।"

हम ऐसे ही रहते थे। हालाँकि हम सामान्य रूप से रहते थे और काम करते थे, अविश्वास मजबूत होता गया। जब हम कुछ करते हैं और किसी को नहीं बताते कि यह क्या है, और समय व्यावसायिक कार्यों पर खर्च नहीं किया जाता है, तो यह हर किसी के लिए अस्पष्ट होता है कि हम क्या परिणाम लाते हैं।

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

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

क्योंकि वास्तव में उनके पास समय नहीं था, उन पर अतिरिक्त काम का बोझ डाल दिया गया था और उन्हें काम करने से रोका गया था।

लेकिन इस दृष्टिकोण के नकारात्मक पहलुओं के बावजूद, हमने काफी कुछ हासिल किया।

इस दृष्टिकोण से हमने क्या हासिल किया है?

सबसे पहले, हमने ऑटोटेस्ट से मांसपेशियों का निर्माण किया है। संपूर्ण सीआई प्रक्रिया को बड़े पैमाने पर नया स्वरूप देकर, हमने इसे एक सभ्य प्रक्रिया बना दिया है जिससे हमें कोई शर्म नहीं है।

दूसरे, हमने कई घटकों में स्पेगेटी कोड के खिलाफ लड़ाई को सफलतापूर्वक लागू किया।

हमने मॉड्यूलराइजेशन किया है और बॉयलरप्लेट्स को कम किया है। इन कार्यों को डर के माध्यम से भी व्यवसाय को नहीं बेचा जा सकता है। यदि आपके उत्पाद में तकनीकी कमियों में ये समस्याएं हैं और आपको उन्हें ठीक करने की आवश्यकता है (यदि वे हैं, तो उन्हें पहले करने की आवश्यकता है), तो आपको उन्हें बेचने की कोशिश करने की भी आवश्यकता नहीं है। यह केवल "तकनीकी ऋण - यह मेरा है" मॉडल के माध्यम से, केवल कोटा के माध्यम से किया जा सकता है।

मैंने कई प्रयास देखे हैं और पहले चरण में स्वयं इसे अलग तरीके से करने का प्रयास किया है। बात नहीं बनी.

दरअसल, इस मोड में काम लंबे समय तक नहीं चल सकता। यह एक सीमित कार्टे ब्लैंच है जो प्रबंधन आपको सीटीओ और टीम लीडर के रूप में आप पर भरोसा करते हुए देता है।

चरण 3. वैध परियोजना

फिर, हमने चरण 3 शुरू किया - तकनीकी ऋण पर काम करने के लिए एक "वैध" परियोजना। धारणा यह थी कि हम एक बंद कोटा से दूर जा रहे थे, एक सामान्य उत्पाद बैकलॉग के माध्यम से योजना बना रहे थे (यानी, उत्पाद मालिक स्वीकार करते हैं कि इन परियोजनाओं को पूरा करने की आवश्यकता है), और एक साफ बिक्री की ओर जा रहे थे। ऐसा करने के लिए, हमने 2 चीज़ें कीं:

• हमने इस परियोजना के ढांचे के भीतर जो काम करना शुरू किया था, मैंने उसके दायरे को यथासंभव सीमित कर दिया।

• मैंने इस बारे में ठोस उम्मीदें बनाईं कि हम उत्पादन में किसके लिए लड़ेंगे। यह आदर्शवाद की पूर्ण अस्वीकृति थी क्योंकि हमारे कार्य यथासंभव व्यावहारिक, समझने योग्य और व्यावसायिक दृष्टिकोण से सेवा के लिए उपयोगी होने चाहिए।

एक महत्वपूर्ण बात यह है कि हमें एक निश्चित भ्रम है कि हम तकनीकी ऋण के व्यावसायिक मूल्य की गणना करने की कोशिश कर रहे हैं, हालांकि यह शायद ही संभव है। और यदि इसकी अभी भी गणना की जा सकती है, तो हमारे पास एक दुःस्वप्न तकनीकी ऋण है!

व्यवसाय के लिए नकारात्मक मूल्य की तुलना में सकारात्मक मूल्य बेहतर काम करता है। यदि आप कहते हैं, "यह ग्राहक चला जाएगा। वह इतना पैसा लाता है," तो जब तक वह नहीं जाता, यह काम नहीं करेगा। यह कोई व्यावसायिक मूल्य नहीं है. इसके अलावा, जोखिमों के साथ काम करने की संस्कृति अभी भी बहुत अधिक नहीं है, इसलिए मोड यह है: "जब तक वे चले नहीं जाते तब तक कोई नुकसान नहीं होगा।"

बिजनेस वैल्यू दिखाना भी जरूरी नहीं है. जहां आप इसे दिखा सकते हैं, लेकिन आप तकनीकी मूल्य दिखा सकते हैं, केवल इसकी गणना की जानी चाहिए।

तकनीकी ऋण कैसे बेचें इस पर गाइड

तकनीकी ऋण बेचने के लिए इस चरण का संपूर्ण कार्यप्रवाह यहां दिया गया है।

फोकस का एक क्षेत्र चुनें (सिर्फ एक)

चूँकि यह डर के माध्यम से बेचा जा रहा है, इसलिए ऐसा क्षेत्र चुनें जो वास्तव में आपके व्यवसाय को प्रभावित करता हो। क्षेत्र भिन्न हो सकते हैं: उपलब्धता, पुनः कार्य की गति, ए/बी परीक्षणों और प्रयोगों की सुरक्षा, और पुनः कार्य की लागत। इसमें क्षेत्रों और विषयों की एक बड़ी संख्या है।

मेरे मामले में, मैंने एक्सेसिबिलिटी को चुना क्योंकि यह व्यवसाय के रडार पर था और इसका हमारी सेवा पर कुछ प्रभाव पड़ा। यह बहुत महत्वपूर्ण है कि अपने आप को फैलाकर न रखें और केवल एक ही विषय चुनें।

इंटीग्रल एनालिसिस करें

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

उपलब्धता का पहला नियम ऐसी प्रणाली बनाने का प्रयास करना नहीं है जो हमेशा उपलब्ध रहेगी, बल्कि कोई घटना घटित होने पर तैयार रहना है। यही हमें सुनिश्चित करना है.

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

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

घटक-दर-घटक विश्लेषण करें

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

हमने यह सब प्रस्तुत कर दिया है, लेकिन यह अभी तक विपणन योग्य नहीं है। अब बाहर जाकर इसे खुलकर दिखाने के लिए, हमने इस चरण की प्रत्येक परियोजना के लिए निम्नलिखित कार्य किए हैं।

सारभूत, मात्रात्मक संकेतक तैयार करें

हम मात्रात्मक संकेतकों से बहुत डरते हैं: हम मात्रात्मक संकेतकों में डेवलपर्स के काम की गुणवत्ता को कैसे माप सकते हैं? हमारे पास मात्रात्मक संकेतकों के खिलाफ बहुत सारे तर्क हैं, लेकिन हमें उन्हें सीधे तौर पर नहीं लेना चाहिए।

मूल्य को केवल व्यावसायिक मूल्य के रूप में नहीं लिया जाना चाहिए। उदाहरण के लिए, उन्हें "X झूठी सकारात्मकताओं से अधिक नहीं" के रूप में परिभाषित किया जा सकता है।

आप घटकों का एक विशिष्ट सेट सूचीबद्ध कर सकते हैं जिसके लिए कैनरी रिलीज़ या गारंटीकृत पैच रोलबैक सुनिश्चित करने की क्षमता प्रदान करना महत्वपूर्ण है। निस्संदेह, समग्र उपलब्धता एक मात्रात्मक संकेतक होनी चाहिए। यह बहुत जरूरी है।

परियोजनाओं का बचाव

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

यह सुना गया, हमने यह किया और यह काम कर गया। मुझे लगता है कि यह उल्लू का चित्र बनाने के वीडियो जैसा है: "एक अंडाकार और दो डैश बनाएं।" अंत में - जादू - आपको एक उल्लू मिलता है! लेकिन सारा जादू यह है कि आपको इस पूरे प्रोजेक्ट को पूरा करना होगा और इसे अंत तक पहुंचाना होगा।

इस दिशा में सिर्फ कुछ काम करने के लिए नहीं बल्कि उसे परिणाम तक पहुंचाने के लिए। यानी बताए गए मात्रात्मक संकेतकों तक पहुंचना और उन्हें दिखाना। 95% बार इस खाई से छलांग नहीं लगाई जा सकती। इसे पूरी तरह से कूदना चाहिए।

दृष्टिकोण के लाभ

तो, हमने (रसातल पर) कूदना शुरू कर दिया। हम इसे सफलतापूर्वक कर रहे हैं. अब, हम इस परियोजना के दूसरे दौर में हैं। अर्थात्, हमने परियोजनाओं के पहले पूल को खींच लिया है और परियोजनाओं के दूसरे पूल पर सहमति व्यक्त की है। क्या बदल गया?

विश्वास बढ़ रहा है

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

बड़े प्रोजेक्ट कर रहे हैं

चूँकि ये अब वैध परियोजनाएँ हैं, हम टीमों के बीच तालमेल बिठा सकते हैं और वास्तव में बड़ी परियोजनाएँ कर सकते हैं। कुछ परियोजनाएँ स्प्रिंट से स्प्रिंट तक क्रमिक रूप से की गईं। प्रौद्योगिकी टीम की संरचना द्वारा हमें उस परियोजना के भीतर नियमित रूप से (सप्ताह में एक बार) ट्रैक किया जाता है और हम समझते हैं कि कौन कहां है (किस चरण में)।

यह जानकारी यथासंभव खुली और पारदर्शी है. परियोजनाओं की प्रगति और वर्तमान स्थितियाँ प्रकाशित की जाती हैं और उत्पाद स्वामियों (और जो कोई भी इसे देखना चाहता है) के लिए उपलब्ध है।

परियोजना में OPS'ers

सबसे महत्वपूर्ण बात यह है कि हमें एहसास हुआ कि बुनियादी ढांचे और रोलआउट प्रक्रिया में हमें बहुत सी चीजों को नया स्वरूप देना है। इस परियोजना में OPS'ers को स्पष्ट रूप से शामिल किया गया था।

मेरे दिमाग में, यह कुबेरनेट्स और डॉकर की तुलना में अधिक DevOps है जब OPS'ers डेवलपर्स के साथ चर्चा करते हैं कि किसी घटक के आर्किटेक्चर को कैसे बदला जाए, और डेवलपर्स OPS'ers के साथ चर्चा करते हैं कि बुनियादी ढांचे को कैसे बदला जाए।

मैंने इसे तुरंत क्यों नहीं किया?

यहां हम उस पर वापस आते हैं जिसके बारे में मैं चरण 2 के अंत में बात कर रहा था: यह पहले काम नहीं करता। क्योंकि चरण 2 में हमने जो किया (स्पेगेटी कोड जिसे हमने फिर से डिजाइन किया, वह परीक्षणों की मांसपेशियों का निर्माण, और सीआई प्रक्रियाओं का नया स्वरूप) मापने योग्य मेट्रिक्स के संबंध में व्यवसाय को बेचना असंभव होता।

उस स्थिति को किसी विशेष डर से मैप नहीं किया गया था, और हमारा मानक तर्क, "स्पेगेटी कोड के कारण हमें कोड करने में लंबा समय लग रहा है" - व्यवसाय में कोई भी नहीं सुनता है। इसलिए, हम उस दृष्टिकोण को आगे बढ़ाने में सक्षम नहीं होंगे।

मेरे दृष्टिकोण से, यदि आपके पास एक प्रौद्योगिकी मंच है जिसके लिए इतने गहन बुनियादी ढांचे के पुनर्निर्माण की आवश्यकता है, तो आप चरण 2 से बच नहीं सकते हैं।

आपको इसके लिए जाना होगा, लेकिन आपको न केवल हर समय पतंग की तरह इधर-उधर उड़ने के लिए तैयार रहना होगा, बल्कि इस दुकान को इतनी जल्दी बंद करने के लिए भी तैयार रहना होगा कि आपके व्यवसाय का विश्वास न खो जाए।