🦒 🖖🏼 🧙 कम कनेक्टिविटी, वास्तुकला और टीम संगठन 🐫 🤛🏻 🥥

लेख का अनुवाद विशेष रूप से पाठ्यक्रम के छात्रों के लिए तैयार किया गया था "DevOps प्रथाओं और उपकरण" ।

यह लेख सॉफ्टवेयर विकास में कोड संरचना और संगठन संरचना के बीच संबंधों पर चर्चा करता है। मैं चर्चा करता हूं कि सॉफ्टवेयर और टीमें आसानी से पैमाना क्यों नहीं बना सकतीं, हम प्रकृति और इंटरनेट में क्या सबक देख सकते हैं, और दिखा सकते हैं कि स्केलिंग की समस्याओं को दूर करने के लिए हम सॉफ्टवेयर और टीमों की कनेक्टिविटी को कैसे कम कर सकते हैं।

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

सॉफ्टवेयर और कमांड स्केल नहीं करते हैं

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

ऐसा क्यों हो रहा है? इसके दो कारण हैं: कोड और टीम से संबंधित। कोड और कमांड दोनों ही बड़े पैमाने पर नहीं हैं।

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

टीमें भी पैमाने नहीं बनातीं। जैसे-जैसे टीमें बढ़ती हैं, संचार अधिक जटिल होता जाता है। एक सरल सूत्र खेल में आता है:

c = n(n-1)/2

(जहां n लोगों की संख्या है, और c टीम के सदस्यों के बीच संभावित कनेक्शन की संख्या है)

टीम के सदस्यों की संख्या	संभावित कनेक्शन की संख्या
1	0
2	1
5	10
10	45
100	4950

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

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

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

प्रकृति स्केलिंग सबक

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

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

क्या ऐसे सॉफ्टवेयर सिस्टम हैं जो परिमाण के कई आदेशों को सफलतापूर्वक मापते हैं? जवाब स्पष्ट है - इंटरनेट, एक वैश्विक सॉफ्टवेयर प्रणाली जिसमें लाखों नोड्स हैं। सबनेट वास्तव में पूरे इंटरनेट के छोटे संस्करणों की तरह दिखते हैं और काम करते हैं।

शिथिल युग्मित सॉफ़्टवेयर के संकेत

एक बड़ी प्रणाली में अलग, शिथिल युग्मित घटकों को अलग करने की क्षमता सफल स्केलिंग की मुख्य विधि है। इंटरनेट, वास्तव में, शिथिल युग्मित वास्तुकला का एक उदाहरण है। इसका मतलब है कि नेटवर्क पर प्रत्येक नोड, सेवा या एप्लिकेशन में निम्नलिखित गुण हैं:

एक सामान्य संचार प्रोटोकॉल का उपयोग किया जाता है।
अन्य नोड्स के साथ एक स्पष्ट अनुबंध का उपयोग करके डेटा स्थानांतरित किया जाता है।
संचार को विशिष्ट कार्यान्वयन प्रौद्योगिकियों के ज्ञान की आवश्यकता नहीं होती है।
संस्करण और परिनियोजन स्वतंत्र हैं।

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

एक शिथिल युग्मित संगठन के संकेत

हम समान सिद्धांतों के बाद टीमों को स्केल कर सकते हैं:

प्रत्येक उप-टीम को एक छोटे सॉफ्टवेयर विकास संगठन की तरह दिखना चाहिए।
आंतरिक प्रक्रियाओं और टीम संचार को टीम से परे नहीं जाना चाहिए।
सॉफ्टवेयर को लागू करने के लिए उपयोग की जाने वाली तकनीकों और प्रक्रियाओं पर टीम के बाहर चर्चा नहीं की जानी चाहिए।
टीमों को केवल बाहरी मुद्दों पर एक दूसरे के साथ संवाद करना चाहिए: सामान्य प्रोटोकॉल, कार्यक्षमता, सेवा स्तर और संसाधन।

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

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

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

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

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

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

कॉनवे का उल्टा कानून: संगठन संरचना आदर्श लक्ष्य वास्तुकला चाहिए

कमजोर सॉफ्टवेयर सुसंगतता और कमजोर टीम जुटना एक साथ कैसे फिट होते हैं? कॉनवे के नियम कहते हैं:

"संगठन डिज़ाइनिंग सिस्टम एक डिज़ाइन तक सीमित हैं जो इस संगठन की संचार संरचना को कॉपी करता है।"

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

हमें एक ही घटक पर कई टीमों के काम से बचना चाहिए। यह एक विरोधी पैटर्न है। और, एक अर्थ में, एक बड़े कोड बेस के साथ एक बड़ी टीम के काम से भी बदतर, क्योंकि टीमों के बीच संचार बाधाएं स्वामित्व और नियंत्रण की कमी की एक और अधिक मजबूत भावना का कारण बनती हैं।

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

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

शिथिल युग्मित टीमें शिथिल युग्मित सॉफ़्टवेयर विकसित करती हैं

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

यदि आपने इस सामग्री को अंत तक पढ़ा है, तो हम अनुशंसा करते हैं कि आप "DevOps के जीवन में एक दिन" विषय पर एक खुले वेबिनार की रिकॉर्डिंग देखें ।