नमस्कार, हेब्र! और फिर से एलेक्सी प्रिस्टावको संपर्क में है।

मेरे पिछले लेखों के विपरीत, आज हम लोगों के बारे में बात करेंगे। दिन के नायक ऑपरेशन सेवा हैं, जिनके हितों का मैं प्रतिनिधित्व करता हूं, और विकास सेवा।

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

इस लेख में मैं निम्नलिखित सवालों के जवाब देने की कोशिश करूंगा:

विकास के तरीके और प्रक्रियाएं संचालन को कैसे प्रभावित करती हैं?
संघर्ष के प्रत्येक पक्ष को क्या कहते हैं?
असहमति का मूल कारण क्या है?

बिल्ली के लिए आपका स्वागत है!

सेवाओं के सामने क्या चुनौतियां हैं

हम विभागों को बेहतर तरीके से जानेंगे और संचालन सेवा से शुरू करेंगे (यह एक समर्थन सेवा भी है)। इस भयानक जानवर की आवश्यकता क्यों है, यह किस कार्य को करता है, और "किसके लिए" यह काम करता है?

ऑपरेटिंग सेवा का मुख्य कार्य सेवाओं के स्तर का प्रबंधन करना है, अर्थात्, एसएलए के ढांचे के भीतर आईटी प्रणाली के संचालन को बनाए रखना।
ऑपरेशन को सेवा के लिए निरंतर पहुंच प्रदान करनी चाहिए और ग्राहक के साथ एक समझौते के ढांचे के भीतर इसकी सही कार्यप्रणाली - आमतौर पर व्यवसाय के साथ।

यहाँ इस समस्या का हल है:

हादसा प्रबंधन: एक दुर्घटना के दौरान व्यावसायिक कार्य को बहाल करना;
समस्या प्रबंधन: दुर्घटनाओं और घटनाओं के संभावित कारणों को संबोधित करना;
कॉन्फ़िगरेशन प्रबंधन: जानकारी एकत्र करना और सॉफ्टवेयर और बुनियादी ढांचे के संचालन मापदंडों का विश्लेषण करना;
परिवर्तन प्रबंधन: परिवर्तन के दौरान समस्याओं और दुर्घटनाओं के जोखिम को कम करना।

विकास सेवा की भूमिका भी समझ में आती है - एक आईटी सेवा का प्रारंभिक निर्माण और ग्राहक के अनुरोध पर इसमें नई कार्यक्षमता का परिचय।

निश्चित रूप से, आपको पहले से ही डेवलपर्स और समर्थन के घर्षण बिंदुओं के बारे में संदेह है, क्योंकि जहां कार्यों के चौराहे हैं, वहां संघर्ष हैं। लेकिन निष्कर्ष पर जल्दी मत जाओ। डेवलपर्स और व्यवस्थापक के बीच शाश्वत बहस "लड़ाई" के उपरिकेंद्र से दूर है।

असहमति कहां बढ़ती है

प्रोग्रामर और एडिंस का "युद्ध" मानव हितों का टकराव नहीं है, यह सेवाओं का टकराव है।

समस्या इन बहुत सेवाओं की प्राथमिकताओं और प्रेरणा में निहित है। अपने सबसे सामान्य रूप में, इसे निम्नानुसार वर्णित किया जा सकता है:

विकास टीम पहले ताजगी (पेशेवर विकास, रुचि) की तकनीक का उपयोग करना चाहती है और काम को जितनी जल्दी हो सके (बाहरी प्रेरणा) करना चाहती है।

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

उसी समय, यह समझना महत्वपूर्ण है कि न केवल डेवलपर्स ने "नई कार्यक्षमता" को देखा और न केवल विशेष रूप से प्रशंसा गिर को बढ़ाते हैं।

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

प्रोग्रामर सक्रिय रूप से ऑपरेशन में शामिल होते हैं। वे सॉफ्टवेयर त्रुटियों को सही करते हैं, सिस्टम अनुकूलन और एसएलए प्रणाली का पालन करने के लिए तकनीकी सुधार करते हैं, अर्थात वे अंतिम आईटी सेवा की पहुंच की समस्या को हल करते हैं।

प्रोग्रामर और प्रशासकों के बीच संघर्ष अवधारणाओं के प्रतिस्थापन से बढ़ता है:

विकास → कोडिंग;
समर्थन → अनुप्रयोग सेवाओं का प्रशासन।

एक पेशेवर आधार पर (एक कार्यात्मक आधार पर) के रूप में अधीनता संरचना को तिरछा करने से हमेशा संघर्ष होता है। एक नियम के रूप में, प्रशासक और प्रोग्रामर पूरी तरह से अलग-अलग टीमों, और कभी-कभी विभागों में काम करते हैं, और क्रमशः संचालन और विकास के रूप में प्रेरित होते हैं।

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

प्रत्येक पक्ष इसे समस्या के संयुक्त समाधान के रूप में नहीं, बल्कि अपने स्वयं के कार्यों से एक व्याकुलता के रूप में मानता है, जो उस छोर के बिना भी दिखाई नहीं देते हैं।

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

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

आइए संघर्ष के सभी पक्षों पर एक नज़र डालें:

बेशक, यह कार्यात्मक और परिचालन आवश्यकताओं का केवल सबसे आम हिस्सा है।

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

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

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

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

विकास की प्रक्रियाएँ

अंत में, हम लगभग उस बिंदु पर पहुंच गए जिसके लिए सब कुछ ऊपर था। सेवा संचालन की कुंजी क्या है?

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

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

आइए क्लासिक्स से शुरू करें: वॉटरफॉल मॉडल।

झरना

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

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

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

यदि परिणाम अपेक्षित से दूर है, तो ग्राहक को एक नए चक्र के अंत तक, या यहां तक कि दो को सहना होगा। नियमित रूप से इसके स्थान पर ऑपरेशन सेवा है। और तकनीकी कार्यक्षमता सबसे अधिक बार पंक्ति में अंतिम होती है।

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

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

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

चुस्त

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

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

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

● अनुबंध की शर्तों पर समझौते की तुलना में ग्राहक के साथ सहयोग अधिक महत्वपूर्ण है।
और फिर, हाँ, अधिक महत्वपूर्ण है। लेकिन अनुबंध की शर्तों के बिना हम कैसे समझेंगे कि क्या और कैसे करना है? आपसी गलतफहमी को दूर करने के लिए और कैसे एक स्पष्ट रूप से परिभाषित दस्तावेज़ के माध्यम से संवाद और सहमति के अलावा? बेशक, अनुबंध भी एक रामबाण नहीं है, लेकिन यह नब्बे के दशक की विधि की तुलना में बहुत अधिक विश्वसनीय है:

- वस्या, क्या तुम मुझे समझती हो?
- ठीक है, हाँ की तरह, भाई।

● मूल योजना का पालन करने की तुलना में परिवर्तन के लिए तैयारी अधिक महत्वपूर्ण है।
लेकिन यह केवल एक मामले में सच है: यदि प्रारंभिक योजना एक पूर्ण लॉग थी, और जो वे बनाने की योजना बना रहे थे, तो यह किसी की जरूरत नहीं थी। आप प्रत्येक हाथ में एक उद्यम वास्तुकार देते हैं!

इस घोषणापत्र का आँख बंद करके पालन करने का नतीजा यह है कि व्यवसाय ग्राहक को खुद को एक उद्यम वास्तुकार में बदलना होगा (लेकिन अधिक बार नहीं, वह एक कद्दू में बदल जाता है)। इतना ही नहीं, यह उसके लिए "कार्यात्मक" नहीं है, यह आईटी को समझने के लिए भी आवश्यक है।

जमघट

एग्री मेनिफ़ेस्ट की विचारधारा के लिए वाटरप्रूफ़ को टेलर के पहले प्रयासों में से एक है।
घोटाले की मुख्य विशेषताएं:

छोटे स्प्रिंट में काम करते हैं। स्प्रिंट की शुरुआत के बाद की रचना संपादित नहीं होती है;
स्प्रिंट विश लॉग में व्यक्तिगत उपयोगकर्ता कहानियां डालकर योजना बनाना। परियोजना के मालिक पर - "प्रोजेक्ट लॉग" से एक विकल्प;
ग्राहक के हितों को परियोजना के मालिक (उत्पाद स्वामी) द्वारा दर्शाया जाता है;
विकास टीम में विभिन्न प्रोफाइल के विशेषज्ञ शामिल हैं: प्रोग्रामर, डेवलपर्स, आर्किटेक्ट, विश्लेषक। टीम पूरे परिणाम के लिए जिम्मेदार है;
हम पूरी टीम द्वारा परियोजना की दैनिक चर्चा के साथ प्रलेखन और पत्राचार की जगह लेते हैं।

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

किसी विशेषता को उसके समाप्त रूप में निरंतर पुन: प्राथमिकता देने के परिणामस्वरूप, यह बहुत जल्द उत्पादक में आ सकता है। इसके अलावा, UserStory लिखने के चरण में अंतिम प्रणाली पर नियोजित कार्यक्षमता के प्रभाव का मूल्यांकन करना बेहद मुश्किल है, क्योंकि इस कार्यक्षमता के प्रकट होने के समय इसकी स्थिति पहले से ज्ञात नहीं है।

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

सामान्य ऑपरेशन के लिए, ऑपरेशन होना चाहिए:

SCRUM बैठकों में भाग लें;
विकास की कामकाजी स्थितियों के बारे में लगातार जागरूक;
विकास योजनाओं को जानें और स्थितियां जारी करें।

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

Kanban

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

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

कानन आमतौर पर सीआई / सीडी प्रक्रियाओं के साथ हाथ से जाता है। यहां कोई स्प्रिंट नहीं हैं, कार्यों को लगातार तैयार किया जाता है क्योंकि वे तैयार हैं, ऐसे कार्यों के आकार पर सख्त प्रतिबंध हैं। इस वजह से, एक अभिन्न रूप में जटिल कार्यक्षमता लगभग कभी वितरित नहीं होती है, क्योंकि यह कार्य के आकार में फिट नहीं होती है।

ऐसी स्थितियों में, सिस्टम के लिए दस्तावेज़ीकरण वास्तव में अप्रचलित हो जाता है क्योंकि यह लिखा जाता है, और सभी अर्थों को खो देता है, क्योंकि यह उत्पादित (अर्थात् उत्पादित, लेकिन विकसित नहीं) प्रणाली के कुछ राज्य को ठीक करना असंभव है, जिसमें यह सच होगा।

ऑपरेशन के लिए, इसका अर्थ है कि SLA प्रदान करने में असमर्थता: कोई प्रलेखन नहीं है, और कोई नहीं जानता कि सिस्टम कैसे काम करता है और इसे कैसे काम करना चाहिए।

निरंतरता और निरंतर संचालन का आश्वासन SLA कार्यान्वयन की नींव है।

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

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

DevOps

बेशक, DevOps इस तरह के रूप में एक विकास पद्धति नहीं है, लेकिन मैं मदद नहीं कर सकता लेकिन अपने 5 kopecks डालें और ऑपरेशन और विकास के संघर्ष को हल करने के लिए सबसे आम प्रयास के बारे में बात नहीं करता।

सिद्धांत रूप में, DevOps सूचना प्रौद्योगिकी विशेषज्ञों के साथ विकास विशेषज्ञों की सक्रिय बातचीत और एक दूसरे में उनकी कार्य प्रक्रियाओं के पारस्परिक एकीकरण के उद्देश्य से प्रथाओं का एक समूह है।

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

नतीजतन, DevOps आवश्यक विकास लिंक को पूरा करके विकास टीम को ऑपरेशन सेवा से स्वतंत्र बनाने का एक साधन बन जाता है। जाहिर है, अपने आप में यह समाधान एकतरफा है और केवल एक पक्ष - विकास के लिए समस्या का हल करता है। अक्सर यह केवल संघर्ष को बढ़ा देता है, जिससे विकास सेवा संचालन को पूरी तरह से अनदेखा कर सकता है।

व्यवहार में, मैं अक्सर दो कार्यान्वयनों में आता हूं:

ऑपरेशन व्यवस्थापक की टीम को बनाए रखा गया है और उत्पादक में लगे हुए हैं।

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

एक ही बात है, लेकिन ऑपरेशन टीम को "कोई आदमी नहीं - कोई समस्या नहीं है" की भावना को समाप्त कर दिया गया है।

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

यहां तक कि अगर हम मूल विचार पर लौटते हैं कि DevOps परीक्षण के बारे में है, और इसे गारंटी गुणात्मक परिवर्तनों के त्वरित हस्तांतरण की गारंटी देनी चाहिए, तो यह फिर से पता चलता है कि प्रक्रिया से बाहर करना या ऑपरेशन को बदलना असंभव है। विचार का ध्यान स्वयं परिवर्तन प्रक्रिया की गुणवत्ता सुनिश्चित करने और इन परिवर्तनों की गुणवत्ता की गारंटी देने पर है। ध्यान दें कि SLA अनुपालन और अभिगम नियंत्रण कहीं भी उल्लिखित नहीं हैं। और परिवर्तनों की उच्च गुणवत्ता (घटक) सिस्टम के उच्च समग्र प्रदर्शन की गारंटी नहीं देता है।

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

आउटपुट के बजाय

तो क्या करें और कैसे रहें?

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

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

ऊपर वर्णित स्थितियों और प्रक्रियाओं में निश्चित रूप से आप सभी ने एक या दूसरे तरीके से भाग लिया। टिप्पणियों में अपना अनुभव साझा करें!

शोषण की नजर से विकास प्रक्रियाएं। बैरिकेड के दूसरी तरफ से एक नज़र