कुबेरनेट्स के साथ अभिसरण

कुल मानकीकरण

मैंने सम्मेलन में अपने भाषण के लिए यह सामग्री तैयार की और हमारे तकनीकी निदेशक से पूछा कि हमारे संगठन के लिए कुबेरनेट्स की मुख्य विशेषता क्या थी। उसने उत्तर दिया:

डेवलपर्स खुद नहीं समझ पाते कि उन्होंने कितना अतिरिक्त काम किया।

जाहिरा तौर पर, वह हाल ही में पढ़ी गई पुस्तक "फैक्टफुलनेस" से प्रेरित थी - बेहतर के लिए मामूली और निरंतर परिवर्तनों को नोटिस करना मुश्किल है, और हम लगातार अपनी प्रगति से चूक जाते हैं।

लेकिन कुबेरनेट्स पर स्विच निश्चित रूप से महत्वहीन नहीं है।

हमारी लगभग 30 टीमें सभी या कुछ वर्कलोड को क्लस्टर पर चलाती हैं। हमारे HTTP ट्रैफ़िक का लगभग 70% Kubernetes समूहों पर अनुप्रयोगों द्वारा उत्पन्न होता है। यह संभवतः प्रौद्योगिकियों का सबसे बड़ा अभिसरण है क्योंकि मैंने 2010 में फॉरवर्ड खरीदी गई कंपनी के बाद कंपनी ज्वाइन की थी, जब हमने .NET और भौतिक सर्वर से AWS और एक अखंड प्रणाली से microservices में स्विच किया था।

और यह सब बहुत जल्दी हुआ। 2017 के अंत में, सभी टीमों ने अपने AWS बुनियादी ढांचे का उपयोग किया। उन्होंने लोड बैलेंसर्स, EC2 इंस्टेंस, ECS क्लस्टर अपडेट और इस तरह से सामान सेट किया। एक साल से थोड़ा अधिक समय बीत गया, और सब कुछ बदल गया।

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

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

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

यह इस बारे में है कि संगठन तीन-वर्षीय परियोजनाओं को कैसे मानते हैं: पहला वर्ष विकास और तैयारी का है, दूसरा वर्ष कार्यान्वयन का है, तीसरा वापसी है। एक व्याख्यान में, वह कहते हैं कि इस तरह की परियोजनाएं आमतौर पर लगातार की जाती हैं और शायद ही कभी दूसरे वर्ष के अंत तक मिलती हैं (अक्सर किसी अन्य कंपनी द्वारा अधिग्रहण और दिशा और रणनीति में बदलाव के कारण), इसलिए सामान्य वास्तुकला है

स्थिरता के कुछ समानता में परिवर्तन का स्तरीकरण।

और uSwitch एक बेहतरीन उदाहरण है।

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

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

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

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

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

नतीजतन, जैसा कि माइकल न्यगार्ड ने वर्णित किया, हमें परिवर्तनों की कई परतों की एक प्रणाली मिली - कुछ सिस्टम पपेट के साथ स्वचालित थे, कुछ टेराफॉर्म के साथ, कहीं हम ईसीएस का उपयोग करते थे, कहीं ईसी 2 का।

2012 में, हमें अपनी वास्तुकला पर गर्व था, जिसे आसानी से प्रयोग में लाया जा सकता था , सफल समाधान खोजे और उन्हें विकसित किया।

लेकिन 2017 में, हमने महसूस किया कि बहुत कुछ बदल गया है।

AWS अब 2010 की तुलना में बहुत अधिक जटिल है। यह विकल्पों और सुविधाओं के एक टन प्रदान करता है - लेकिन परिणामों के बिना नहीं। आज, EC2 के साथ काम करने वाली किसी भी टीम को VPC, नेटवर्क कॉन्फ़िगरेशन और बहुत कुछ चुनना होगा।

हमने अपने दम पर यह अनुभव किया - टीमों ने शिकायत करना शुरू किया कि वे बुनियादी ढांचे को बनाए रखने के लिए अधिक से अधिक समय बिता रहे थे, उदाहरण के लिए, एडब्ल्यूएस ईसीएस क्लस्टर्स , ईसी 2 मशीनों में उदाहरणों को अपडेट करना, ईएलबी बैलेन्सर से एएलबी पर स्विच करना, आदि।

2017 के मध्य में, एक कॉर्पोरेट इवेंट में, मैंने सभी से सिस्टम के समग्र गुणवत्ता में सुधार के लिए अपने काम को मानकीकृत करने का आग्रह किया। मैंने हैक किए गए आइसबर्ग रूपक का उपयोग यह दिखाने के लिए किया कि हम सॉफ्टवेयर कैसे बनाते हैं और कैसे बनाए रखते हैं:

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

उस समय, एप्लिकेशन डेवलपर्स की प्रत्येक टीम ने लगभग पूरे हिमखंड से निपटा और खुद से सभी निर्णय लिए - भाषा, विकास पर्यावरण, पुस्तकालय और मैट्रिक्स टूल, ऑपरेटिंग सिस्टम, उदाहरण प्रकार, भंडारण का चयन किया।

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

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

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

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

इसने हमारी कंपनी के विकास को सीमित कर दिया। टीमों ने स्वायत्तता की मांग की, लेकिन नए लोगों को कैसे नियुक्त किया जाए? हमें मजबूत एप्लिकेशन और उत्पाद डेवलपर्स और तेजी से परिष्कृत AWS प्रणाली के ज्ञान की आवश्यकता थी।

हम अपनी टीमों का विस्तार करना चाहते थे और साथ ही उन सिद्धांतों को संरक्षित करते थे जिनके साथ हम सफल थे: स्वायत्तता, न्यूनतम समन्वय और स्वयं-सेवा बुनियादी ढाँचा।

कुबेरनेट्स के साथ, हमने आवेदन-केंद्रित अमूर्त और न्यूनतम टीम समन्वय के साथ क्लस्टर को बनाए रखने और कॉन्फ़िगर करने की क्षमता के साथ इसे पूरा किया।

अनुप्रयोग-केंद्रित सार

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

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

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

2010 में, uSwitch के पास एक अखंड प्रणाली की सेवा के लिए पारंपरिक टीमें थीं, और हाल ही में हमारे पास एक IT विभाग था जो आंशिक रूप से हमारे AWS खाते को प्रबंधित करता था। मुझे ऐसा लगता है कि सामान्य अवधारणाओं की कमी ने इस टीम के काम में गंभीरता से बाधा डाली।

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

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

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

एक आम भाषा में संचार अधिक उत्पादक है, लेकिन फिर भी हमें टीमों के बीच बातचीत को यथासंभव सीमित करने की आवश्यकता है।

बातचीत की न्यूनतम आवश्यकता

Accelerate के लेखक एक ढीली युग्मित वास्तुकला की विशेषताओं को उजागर करते हैं जिसके साथ आईटी टीमें अधिक कुशलता से काम करती हैं:

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

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

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

मुझे यकीन नहीं है कि कुबेरनेट्स के साथ हमारे पास अधिक स्वायत्तता है, लेकिन यह निश्चित रूप से उच्च स्तर पर रहा, और साथ ही साथ हमें कुछ समस्याओं से छुटकारा मिला।

कुबेरनेट्स पर स्विच करना त्वरित था। आरेख हमारे कार्य समूहों में नाम स्थान (कमांड की संख्या के बराबर) की कुल संख्या दिखाता है। पहली फरवरी 2017 में दिखाई दी।

हमारे पास दौड़ने के कारण थे - हम बुनियादी ढांचे की चिंताओं से अपने उत्पाद पर केंद्रित छोटी टीमों को बचाना चाहते थे।

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

हाल ही में, टीमें बेहतर उपकरणों के लिए कुबेटनेट पर स्विच कर रही हैं। कुबेरनेट समूह हमारे हाशिकॉर्प वॉल्ट , Google क्लाउड ट्रेस और इसी तरह के औजारों के साथ एकीकरण को आसान बनाते हैं। हमारी सभी टीमों को और भी अधिक प्रभावी सुविधाएँ मिलती हैं।

मैंने पहले ही चार्ट दिखाया था कि हमारे कर्मचारियों ने 2014 से 2017 तक हर हफ्ते कितनी सेवाओं का उपयोग किया है। और यहाँ इस आरेख का सिलसिला आज भी जारी है।

हमने जटिल AWS ढांचे के प्रबंधन में प्रगति की है। मुझे खुशी है कि अब आधे कर्मचारी 2015 की शुरुआत में भी ऐसा ही कर रहे हैं। क्लाउड कंप्यूटिंग टीम में हमारे 4-6 कर्मचारी हैं, जो कुल संख्या का लगभग 10% है - यह आश्चर्य की बात नहीं है कि 90 वें प्रतिशत लगभग नहीं हिलता था। लेकिन मैं यहां भी प्रगति की आशा करता हूं।

अंत में, मैं इस बारे में बात करूंगा कि हमारा विकास चक्र कैसे बदल गया है, और फिर से हाल ही में पढ़ी गई एक्सिलरेट किताब को याद करें।

पुस्तक में दो दुबले विकास मैट्रिक्स का उल्लेख किया गया है: लीड समय और पैकेज का आकार। लीड समय को तैयार समाधान के वितरण के अनुरोध से माना जाता है। पैकेज का आकार काम की मात्रा है। पैकेज का आकार जितना छोटा होगा, कार्य उतना ही कुशल होगा:

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

पुस्तक में तैनाती आवृत्ति द्वारा पैकेट के आकार को मापने का सुझाव दिया गया है - जितनी अधिक बार तैनाती, छोटे पैकेट।

हमारे पास कुछ तैनाती के लिए डेटा है। डेटा पूरी तरह से सही नहीं है - कुछ टीमें सीधे रिपॉजिटरी की मुख्य शाखा को रिलीज भेजती हैं, कुछ अन्य तंत्र का उपयोग करती हैं। इसमें सभी एप्लिकेशन शामिल नहीं हैं, लेकिन 12 महीने के डेटा को सांकेतिक माना जा सकता है।

तीसवें सप्ताह में विफलता क्रिसमस है। बाकी के लिए, हम देखते हैं कि तैनाती की आवृत्ति बढ़ जाती है, जिसका अर्थ है कि पैकेट का आकार घटता है। मार्च से मई 2018 तक, रिलीज़ की आवृत्ति लगभग दोगुनी हो गई, और हाल ही में हम कभी-कभी प्रति दिन सौ से अधिक मुद्दों को बनाते हैं।

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

Accelerate, परिनियोजन आवृत्ति और कर्मचारियों की संख्या के बीच संबंध के बारे में भी बात करती है, और यदि कर्मचारी बढ़ा है तो कंपनी कितनी तेजी से काम कर सकती है। लेखक संबंधित वास्तुकला और टीमों की सीमाओं पर जोर देते हैं:

यह पारंपरिक रूप से माना जाता है कि एक टीम का विस्तार करने से समग्र उत्पादकता बढ़ जाती है, लेकिन व्यक्तिगत डेवलपर उत्पादकता घट जाती है।

यदि हम तैनाती की आवृत्ति पर समान डेटा लेते हैं और उपयोगकर्ताओं की संख्या पर निर्भरता का आरेख बनाते हैं, तो हम देख सकते हैं कि हम रिलीज़ की आवृत्ति बढ़ा सकते हैं, भले ही हमारे पास अधिक लोग हों।

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

यह हमारे लिए अच्छा हुआ करता था। हमारे पास microservices, AWS, उत्पादों के लिए अच्छी तरह से स्थापित टीमें, उत्पादन में उनकी सेवाओं के लिए जिम्मेदार डेवलपर्स, शिथिल युग्मित टीमें और वास्तुकला हैं। मैंने 2012 में एक सम्मेलन में "हमारी आयु प्रबुद्धता" ("हमारी आयु प्रबुद्धता") की रिपोर्ट में इस बारे में बात की थी। लेकिन पूर्णता की कोई सीमा नहीं है।

अंत में, मैं एक और किताब - स्केल देना चाहता हूं। मैंने इसे हाल ही में शुरू किया था, और जटिल प्रणालियों में ऊर्जा की खपत के बारे में एक दिलचस्प टुकड़ा है:

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

मुझे लगता है कि आप यहां आईटी सिस्टम जोड़ सकते हैं। मुझे उम्मीद है कि हमारे आखिरी प्रयास थोड़ी देर के लिए भी उलझे रहेंगे।