गैर-आईटी प्रबंधकों को दोष-सहिष्णु आईटी अवसंरचना के निर्माण के सिद्धांतों की व्याख्या कैसे करें

लगभग एक साल पहले, मेरे सामने एक गंभीर कार्य निर्धारित किया गया था: प्रबंधकों के लिए 2-घंटे के व्याख्यान में लगाने के लिए एजिल और देवओप्स दोनों की कहानी।

इस प्रकार आईटी के लिए एजाइल प्रशिक्षण के सोफ्त्स्किल विमान से मेरी वापसी शुरू हुई। और आयोजकों के अनुसार, 1000 से अधिक उत्पाद प्रबंधक इस व्याख्यान से गुजरे, जिनमें से लगभग 48/50 लोगों ने मेरी कक्षा में पहली बार "लोड बैलेंसर" शब्द सुना।

यहां तक ​​कि मुझे एक कॉमिक देवता मिला "एक महान बैलेन्सर, डाउनटाइम के बिना अपडेट के मास्टर, प्रोग्रामिंग के बिना ए / बी परीक्षणों को लागू करने के लिए सस्ते, और आम तौर पर एक प्रबंधक की अच्छी रात की नींद।"

बेशक, आईटी के सहकर्मी इस सरलीकरण पर हंस सकते हैं, और यहां तक ​​कि इस बात से भी नाराज हो सकते हैं कि दुनिया "बैलेंसर" शब्द पर सहमत नहीं थी और इस पर कितना ध्यान दिया जा सकता है।

लेकिन जब मेरे जिम में 50 में से 48 लोगों ने लोड बैलेंसिंग की घटना के बारे में नहीं सुना, तो यह थोड़ा दुखद है। हां, और कुछ मोबाइल एप्लिकेशन के बैकेंड के डेवलपर्स, यहां तक ​​कि बड़े बैंक भी ऐसी योजनाओं के अभाव में पाप कर सकते हैं।

मेरा पसंदीदा पीला बैंक, उदाहरण के लिए, मोबाइल एप्लिकेशन के बैकेंड सर्वर को सुबह 5 बजे मॉस्को समय में सप्ताह में लगभग 2 बार अपडेट करता है। मुझे वह क्यों पता है? क्योंकि नोवोसिबिर्स्क में, जहां मैं 2016 में एक साल के लिए रहने के लिए लौट रहा था, यह उस समय पहले से ही 9 बजे था, और 000 त्रुटि मेरे लिए पॉप अप हुई। यह कल्पना करना भयानक है कि यह सुदूर पूर्व के लिए पहले से ही दोपहर का भोजन है।

शायद हमारे पास इस दुनिया को थोड़ा बेहतर बनाने का मौका है अगर प्रबंधक बजट क्षमताओं के समय गलती को बर्दाश्त करने के बारे में सोचेंगे, और हर चीज के लिए 1 सर्वर नहीं होगा, लेकिन वास्तव में जोखिम और सिस्टम लोड कॉन्फ़िगरेशन की एक बहुत ही बढ़िया डिग्री है।

क्यों?

बहुत पहला सवाल जो किसी भी कार्य को निर्धारित करते समय उठता है, निश्चित रूप से: क्यों?

ऐसी एक रूपरेखा है:

हमें इसकी आवश्यकता क्यों है? | उन्हें इसकी आवश्यकता क्यों है?

हमें इसकी आवश्यकता क्यों है?

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

अपने लिए, मैंने पहले सवाल का काफी सरलता से जवाब दिया: प्रबंधकों की तकनीकी साक्षरता में सुधार से अपर्याप्त कार्यों की संभावना कम हो जाती है और डेवलपर्स की खुशी बढ़ जाती है।

उन्हें इसकी आवश्यकता क्यों है?

आईटी से वास्तव में दूर रहने वाले प्रबंधकों को इस बारे में क्यों पता है?

हम सभी लोग हैं, और हम सभी शांति से सोना चाहते हैं। प्रबंधक अक्सर किसी ऐसी चीज़ की जिम्मेदारी लेते हैं, जो वास्तव में प्रभावित करने में सक्षम नहीं होती है। इस मामले में तनाव का स्तर एयरोफोबिया वाले विमान के यात्रियों के साथ तुलनीय है।

और यह संभवतः एकमात्र तर्क है जो स्नोबेरी जैसा नहीं होगा "आप इस तरह की स्पष्ट चीजों को कैसे नहीं जान सकते हैं" या "किसी भी व्यक्ति को रात में आंखों पर पट्टी बांधकर अनिश्चित काल के लिए अंधाधुंध होना चाहिए"। मेरे अनुभव में, यदि कोई व्यक्ति "कंसोल में कोहनी के लिए" है, तो भी अनजाने में, लेकिन वह अक्सर ऐसे टिकटों के साथ काम कर सकता है।

मैं जटिल सरल चित्रों को कैसे समझा सकता हूं

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

वयस्क शिक्षा में, और नई जानकारी को आत्मसात करना सीखने का हिस्सा है, यह समझना महत्वपूर्ण है कि किसी भी जानकारी को कम से कम तीन बार दोहराया जाना चाहिए ताकि संभावना प्राप्त हो सके कि यह वास्तव में अधिग्रहित है।

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



लेकिन पहली बार दिखाई गई यह योजना, "बैलेंसर" शब्द के एक व्यक्ति को सर्वर पर लोड को संतुलित करने की घटना के साथ बना सकती है। इस प्रक्रिया की सही समझ की कोई गारंटी नहीं है, लेकिन इस विश्वास के साथ कि यह मौजूद है और इसकी आवश्यकता क्यों है।



आइए इस जगह में चंचलता के कुछ बिंदुओं को बिगाड़ें और कहें कि "जो दाईं ओर है उसका मूल्य कम किए बिना, हम बाईं ओर के मूल्य पर अधिक मूल्य रखते हैं।"

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

आगे क्या है?

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

खैर, यह मेरे लिए नहीं है कि आपको बता दें कि क्षमता के 1/10 पर छोटे संपादन किए गए हैं (भले ही यह 3 में से 1 सर्वर है, लेकिन केवल 10% ट्रैफ़िक इसे दिया गया है), यह उन्नयन के दौरान जुनून में एक मजबूत कमी है। भले ही सर्वर हर 10 वें अनुरोध को पूरी तरह से संसाधित करना बंद कर दें।

आरपीएस 600 पर हमें 20% की गिरावट आई थी, और इसे जल्दी से समाप्त कर दिया गया था, यह लोगों की भागीदारी के बिना भी लगता है। यह तब था कि मैं, एक तकनीकी पीएम के रूप में, जो दिशा के सभी बैकेंड के लिए जिम्मेदार था, व्यावहारिक रूप से अन्य प्रबंधकों को "बैलेंसर" शब्द दोहराने की आकांक्षा करने लगा।

जैसा कि मेरे अनुभव से पता चलता है, यह ज्ञान अत्यंत उपयोगी है ताकि प्रबंधक समझ सकें कि जोखिमों को रिलीज से कैसे कम किया जा सकता है और सीआई / सीडी और विभिन्न तकनीकी प्रयोगों में रुचि हो सकती है।

लगभग 4 साल पहले, मेरे व्यवहार में लगभग यही कहानी डेवलपर्स को GitFlow जैसी "ब्रंचिंग" प्रणालियों के बारे में बताने के लिए थी, जो रिलीज शाखा में कमानों पर रिलीज और स्थिरीकरण को स्थिर करने के लिए, हुक स्तर पर समर्थित है, लेकिन हाल ही में यह कम और कम हो गया है और कम आवश्यकता है।

मेरी राय में, गैर-तकनीकी प्रबंधकों की तकनीकी साक्षरता को बढ़ाना वास्तव में महत्वपूर्ण है। बिल्कुल इस तरह से जरूरी नहीं है, बिल्कुल।