⚜️ 🍞 💌 एक आर्किटेक्ट के लिए चेकलिस्ट 🕣 🔘 🍑

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

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

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

बेशक, यह एक गलत परिभाषा है, और विपणक मुझसे बहस कर सकते हैं - और यहां तक कि बहस भी! लेकिन जो कुछ आप नीचे पढ़ते हैं, उसके लिए यह काफी पर्याप्त है।

कम नौकरशाही - आसान विकास

क्या बदला है: सबसे पहले, कंपनी प्रबंधन का मॉडल। यदि पहले केंद्रीकृत उद्यम वास्तुकला (उद्यम वास्तुकला) के लोग प्रत्येक परियोजना को सत्यापित करते थे, तो अब वे एक तकनीकी नीति (एक बड़ा और स्मार्ट दस्तावेज़) और ट्रेन आर्किटेक्ट प्रकाशित करते हैं। और इसे कैसे लागू किया जाए यह पहले से ही सौ से अधिक टीमों के प्रत्येक उत्पाद वास्तुकार का एक व्यक्तिगत मामला है।

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

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

कई और उदाहरण हैं जहां आईटी सिस्टम के डिजाइन और विकास में गुणवत्ता और निरंतरता की गारंटी होना उपयोगी है।

अंतर्मुखी विशेषज्ञ

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

— DevOps- support-;
, . , , ;
- , — . . -, ; -, ; -, ;
, ;
"लेखा परीक्षकों" की एक टीम में रोटेशन का संगठन ताकि जितना संभव हो सके टीम के प्रतिनिधियों को ज्ञान और अनुभव साझा करने का अवसर मिले।

प्रक्रिया शुरू करने के लिए, हमने उत्साही लोगों की एक टीम को इकट्ठा किया, प्रत्येक भूमिकाओं के लिए चर्चा के विषयों की एक सूची विकसित की, और हमारे प्रेरक लेखा परीक्षकों की टीम को प्रशिक्षित किया। वैसे, प्रशिक्षण सबसे कठिन चरण था, क्योंकि अक्सर हमारे क्षेत्र में बहुत अच्छे विशेषज्ञ भी बहुत अच्छे इंट्रोवर्ट्स होते हैं :-)

इसका परिणाम क्या है?

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

उदाहरण के लिए, आइए "आर्किटेक्चर" की दिशा में एक अध्ययन के परिणामों को देखें।

हमने क्या किया है:

20 टीमों के साथ संवाद किया;
प्रत्येक ने औसतन 31 दिन बिताए। इस तथ्य को देखते हुए कि हमने एक साथ कई टीमों के साथ बातचीत की, पूरी प्रक्रिया में छह महीने लगे;
वास्तुकला से जुड़े 180 जोखिमों का खुलासा किया।

हमारी टीमों के भीतर, जोखिमों को निम्नानुसार विभाजित किया गया था:

जोखिम 1: डिजाइन

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

यह समझने के लिए कि हम किन जोखिमों को समझते हैं, आइए उदाहरण के लिए TOP-3 देखें।

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

उदाहरण के लिए, हमने टेलीमेडिसिन के लिए एक डिजिटल उत्पाद बनाने का फैसला किया। इसके लिए क्या आवश्यक है?

हमें शायद रोगी और चिकित्सक के बीच वीडियो कॉल के लिए एक घटक की आवश्यकता है - हम कॉल के लिए एक घटक बनाते हैं;
कभी-कभी आपको एक नियमित चैट की आवश्यकता होती है - इसका मतलब है कि हम चैट के लिए एक घटक बनाते हैं;
हमें स्वचालित चिकित्सा प्रणालियों से चिकित्सा इतिहास लेने की आवश्यकता है - हम उचित घटक बनाते हैं;
हमें ड्यूटी पर डॉक्टरों की एक अनुसूची रखने की आवश्यकता है - हम इसके लिए एक घटक भी बनाते हैं।

आदि।

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

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

इसलिए, यह कई सरल नियमों को याद रखने योग्य है:

कम तकनीकी जटिलता, छोटी टीमों और अस्थिर आवश्यकताओं के साथ छोटी परियोजनाओं के लिए नीचे-अप डिज़ाइन विधि अच्छी है;
बड़ी परियोजनाओं और टीमों के लिए, डिजाइन विधि ऊपर-नीचे है, अर्थात, जब हम पहली बार तस्वीर को पूरी तरह से डिजाइन करते हैं, और फिर कोडिंग के लिए आगे बढ़ते हैं।

इसलिए, एक नई परियोजना में सुर्खियों में आने से पहले, अपने आप से सवाल पूछें: यह किस प्रकार का है?

जोखिम 2: सुरक्षा

ऐसा लगता है कि इन दिनों सुरक्षा पर बहुत गंभीरता से विचार किया जा रहा है। हर कोई आवश्यकता के रूप में इस तरह के भोज को याद करता है:

उपयोगकर्ताओं को प्रमाणित करें
उन्हें कार्रवाई करने के लिए अधिकृत करें;
कम से कम विशेषाधिकारों के सिद्धांत का अनुपालन;
डेटा गोपनीयता बनाए रखें;
उपयोगकर्ता क्रियाओं के ऑडिट का लॉग रखें।

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

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

आवेदन आपको ऐसे पासवर्ड दर्ज करने की अनुमति दे सकता है जो बहुत सरल हैं, जिन्हें तब चुनना आसान है;
हो सकता है कि एप्लिकेशन को स्वयं ही ब्रूट फोर्स पासवर्ड से संरक्षित न किया जाए (कोई कैप्चा या ऐसा कुछ भी नहीं है);
. , - ;
URL- HTTP- ;
-, . , MD5 ;
- ;
- , . , , -;
- : , ..;
- HTTP-:

- session tokens , ;
- session fixation- (. . session token );
- HttpOnly Secure browser cookies, session tokens;
- .

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

जोखिम 3: प्रदर्शन

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

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

सबसे पहले, हम देखते हैं कि क्या वितरित एप्लिकेशन में क्लाइंट कैश बनाना संभव है ताकि हर बार हम उस डेटा का अनुरोध / गणना न करें जो हमें चाहिए। यदि यह संभव है, तो हम नेटवर्क अनुरोधों, सर्वर संसाधनों को लोड करने और वहां होने वाली हर चीज को सहेजते हैं।
लेकिन यह बहुत दुर्लभ है, इसलिए हम यह देखना चाहते हैं कि क्या हम एक सर्वर कैश बना सकते हैं। इसके साथ, सिद्धांत क्लाइंट के साथ समान है, लेकिन प्रदर्शन लाभ थोड़ा कम है, क्योंकि नेटवर्क अनुरोध अभी भी जाएंगे;
, . , , , , (load balancer);
, . — My SQL Cluster Grid Edition Apache Ignite (Gridgain).

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

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

सारांश

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

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

मेरी रिपोर्ट यहां पाई जा सकती है।

लेख के लेखक: दिमित्री डेज़ुबा, आर एंड सेंटर के प्रमुख।

एक आर्किटेक्ट के लिए चेकलिस्ट

कम नौकरशाही - आसान विकास

अंतर्मुखी विशेषज्ञ

इसका परिणाम क्या है?

सारांश

More articles: