Citymobil - विकास के बीच स्थिरता बढ़ाने के लिए स्टार्टअप के लिए एक गाइड। भाग 1

इस लेख के साथ, मैंने दो लेखों का एक छोटा चक्र खोला है जिसमें मैं विस्तार से वर्णन करूंगा कि हमने कई महीनों में कई बार सिटीमोबिल सेवाओं की स्थिरता को कैसे बढ़ाया। लेख हमारे व्यापार के बारे में, कार्य के बारे में, बढ़ती स्थिरता की समस्या के कारण के बारे में और सीमाओं के बारे में एक कहानी से शुरू होता है। सिटीमोबिल तेजी से बढ़ने वाला टैक्सी एग्रीगेटर है। 2018 में, यह सफल यात्राओं की संख्या में 15 गुना से अधिक की वृद्धि हुई। पिछले महीनों की तुलना में कुछ महीनों में विकास 50% से अधिक हो गया।

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

1. समस्या का कथन: हम वास्तव में क्या सुधार करना चाहते हैं

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

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

यहां से हमें स्थिरता को मापने के लिए एक समझने योग्य मानदंड मिला: खोई गई यात्राओं की संख्या ऐसी यात्राएं हैं जिन्हें हमने तकनीकी समस्याओं के कारण स्पष्ट रूप से खो दिया है। एक तकनीकी समस्या का अर्थ है, उदाहरण के लिए, कोड में एक बग, 500 वीं त्रुटि, बुनियादी ढांचे पर एक दुर्घटना, एक साथी सेवा के साथ टूट एकीकरण (उदाहरण के लिए, Google मानचित्र)।

2. खोई हुई यात्राओं को कैसे गिनें?

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

निम्नलिखित ग्राफ में, काली रेखा एक निश्चित दिन पर यात्राएं दिखाती है और हरी रेखा एक सप्ताह पहले यात्राएं दिखाती है। एक्स अक्ष समय है। Y अक्ष पर, बिंदु X के चारों ओर एक निश्चित समय अंतराल में ट्रिप की संख्या। एक स्पष्ट शिखर को तीव्र-कोण वाले त्रिकोण के रूप में नीचे देखा जाता है। इस त्रिकोण का क्षेत्र खोई हुई यात्राओं की संख्या है। बेशक, यह एक अनुमानित राशि है, क्योंकि ग्राफ में उतार-चढ़ाव हो रहा है, लेकिन हम समझते हैं कि 10-20% सटीकता भी हमारे लिए एक व्यवसाय के लिए दुर्घटना के पैमाने का अनुमान लगाने के लिए पर्याप्त है।



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

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



आमतौर पर ट्रेंड लाइन बनाना मुश्किल होता है, क्योंकि sawtooth ग्राफ। इस मामले में, सप्ताह-दर-सप्ताह तुलना हमें मदद करती है। यदि आप एक ही चार्ट पर दो लाइनें खींचते हैं - अंतिम सप्ताह और वर्तमान एक - तो यह पता चलता है कि प्लस या माइनस वक्र दोनों आकार में समान हैं, लेकिन इसमें केवल एक ही दूसरे से ऊपर है (सामान्य चालू सप्ताह पिछले एक की तुलना में अधिक है, हालांकि वहाँ हैं अपवाद)। सप्ताह-दर-सप्ताह तुलना महत्वपूर्ण है, क्योंकि सप्ताह के प्रत्येक दिन, अलग-अलग परिस्थितियों के कारण, एक अलग शेड्यूल रूप होता है। सप्ताह-दर-सप्ताह चार्ट को देखकर, आप समझ सकते हैं कि आज की यात्राओं की प्रवृत्ति रेखा कहाँ हो सकती है।

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

यही है, तकनीकी समस्याओं के कारण एक खो यात्रा, वास्तव में, कुछ खो यात्राएं।

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

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

इस धारणा के तहत कि के गुणांक समय के साथ बहुत अधिक नहीं बदलता है, यात्रा के नुकसान की प्रवृत्ति को समझने के लिए, यह प्राथमिक खोई हुई यात्राओं पर विचार करने और उनकी संख्या को कम करने की कोशिश करने के लिए पर्याप्त है, क्योंकि प्राथमिक खोई गई यात्राओं की अवधि-से-अवधि का अनुपात माध्यमिक खोई गई यात्राओं की अवधि के अनुपात के समान होगा। अवधि। उदाहरण: यदि हमने पिछले महीने 1000 प्राथमिक यात्राएं खो दी हैं, तो माध्यमिक यात्राएं हमने 1000 * K खो दी हैं, और कुल मिलाकर हमने 1000 * (1+ K ) खो दिए हैं। यदि, आगे, चालू महीने में हमने 500 प्राथमिक यात्राएं खो दी हैं, तो माध्यमिक यात्राएं हमने 500 * K खो दी हैं, और कुल मिलाकर हमने 500 * (1+ K ) खो दिए हैं। इस मामले में, गुणांक K के मूल्य की परवाह किए बिना , हमने यात्राएं 1000 * (1+ K ) / (500 * (1+ K )) = 2 गुना कम करना शुरू कर दिया।

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

कुल: हम प्राथमिक खो जाने वाली यात्राओं में लगातार कमी के लिए लड़ रहे हैं।

3. ठीक है, हम खोई हुई यात्राओं पर विचार करते हैं। आगे क्या है?

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

4. प्रक्रिया कैसे काम करती है

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

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

उपरोक्त संक्षेप करने के लिए, समस्याएं मैनुअल हस्तक्षेप के कारण हैं। एक बार बचपन में, १०-१२ साल की उम्र में, जंगल की अपनी एक यात्रा में, मैंने अपने पिता से एक वाक्यांश सुना, जिसे मैंने अपने पूरे जीवन के लिए याद रखा: “ताकि आग बाहर न निकले, आपको बस इसे छूना नहीं है। मुझे लगता है कि हम में से कई ऐसे क्षणों को याद करते हैं जब हमने जलाऊ लकड़ी को पहले से ही जल रही आग में फेंक दिया था और यह किसी अज्ञात कारण से बाहर चला गया था।

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

प्रक्रिया पूरी तरह से तेजी से विकास पर केंद्रित थी और निम्नानुसार आयोजित की गई थी:

• प्रति दिन 20-30 रिलीज;
• डेवलपर्स खुद को रोल आउट करते हैं;
• डेवलपर द्वारा परीक्षण वातावरण में तेजी से परीक्षण;
• न्यूनतम स्वचालित / यूनिट परीक्षण, न्यूनतम समीक्षा।

सबसे कठिन परिस्थितियों में डेवलपर्स, वास्तव में, क्यूए के चेहरे में पीछे के क्षेत्रों को कवर किए बिना, उत्पादक कार्यों और व्यापार के लिए महत्वपूर्ण प्रयोगों की एक बड़ी धारा के साथ, जितना संभव हो उतना ध्यान केंद्रित और समन्वित रूप से काम किया, जटिल समस्याओं को सरल तरीकों से हल किया, कोड को "बढ़ने" की अनुमति नहीं दी, अच्छी तरह से समझा व्यापार के मुद्दे। , परिवर्तन के लिए बहुत जिम्मेदारी से, जल्दी से वापस लुढ़का। सिटीमोबिल यहां अद्वितीय नहीं है। Mail.ru मेल में 8 साल पहले, जब मैं वहां काम करने आया था, तब भी ऐसी ही स्थिति थी। और हमने कर्टसी के बिना Mail.ru Cloud को जल्दी और सरलता से शुरू किया। और पहले से ही बाद में प्रक्रियाओं को बदल दिया ताकि अधिक स्थिरता प्राप्त हो सके।

निश्चित रूप से, आपने इसे अपने दम पर देखा: जब कोई भी आपकी पीठ को कवर नहीं करता है, जब केवल आप उत्पादन के साथ अकेले होते हैं, जब जिम्मेदारी का एक बड़ा बोझ कुचल जाता है - आप चमत्कार करते हैं। मुझे खुद ऐसा अनुभव था (और भी कट्टर)। एक बार, पिछली शताब्दी में (अनुमान, इंटरनेट पिछली शताब्दी में पहले से ही था, मुझे याद है जब मुझे याद है), मैंने newmail.ru मेल सेवा के एकमात्र डेवलपर के रूप में काम किया, इसे स्वयं तैनात किया, और खुद भी उत्पादन का परीक्षण किया। if (!strcmp(username, “danikin”)) { … some new code… } :-) के माध्यम से अपने आप को, तो यह स्थिति मेरे करीब है।

मुझे आश्चर्य नहीं था अगर मुझे पता था कि "घुटने पर" इस ​​तरह के एक सरल दृष्टिकोण के साथ, कई स्टार्ट-अप शुरू हुए, दोनों सफल और असफल, लेकिन एक ही जुनून से प्रेरित - तेजी से व्यापार विकास और बाजार पर कब्जा करने पर ध्यान दें।

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

5. एक अच्छी प्रक्रिया ने स्थिरता को खतरा क्यों दिया?

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

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

6. ठीक है, कार्य स्पष्ट है, प्रक्रिया स्पष्ट है। आगे क्या है?

Mail.ru मेल और Mail.ru क्लाउड में अनुभव होने के बाद, जहां कुछ बिंदु से स्थिरता सबसे आगे रखी गई थी, जहां सप्ताह में एक बार रोलआउट किया जाता है, विस्तार कार्यक्षमता और परीक्षण मामलों में वर्णित है, सब कुछ ऑटो और यूनिट परीक्षणों के साथ कवर किया जाता है, कम से कम एक बार कोड की समीक्षा की जाती है, और कभी-कभी तीन बार, मैं पूरी तरह से नई स्थिति में आया हूं।

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

7. जब आप नहीं जानते कि क्या करना है, तो गलतियों से सीखें

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

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

हमने सभी दुर्घटनाओं को एक सामान्य Google तालिका में लॉग करना शुरू किया। प्रत्येक दुर्घटना के लिए, निम्नलिखित संक्षिप्त जानकारी प्रदान की गई थी:

• दिनांक, समय, अवधि;
• मूल कारण
• समस्या के समाधान के लिए उन्होंने क्या किया;
• व्यवसाय पर प्रभाव (खोई हुई यात्राओं की संख्या, अन्य प्रभाव);
• निष्कर्ष।

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

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

8. एक गलती का उदाहरण, जिस पर उन्होंने सीखा

मूल कारण भविष्य में इसी तरह की दुर्घटनाओं को रोकने के लिए उन्मूलन है। और निष्कर्ष यह है कि मूल कारण को कैसे खत्म किया जाए (या इसके होने की संभावना को कम किया जाए)।

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

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

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

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

9. आप इस गलती से और क्या सीख सकते हैं, और क्या करें और क्या न करें

इसलिए, हम इस दुर्घटना का विश्लेषण करना जारी रखते हैं। कंपनी तेजी से बढ़ रही है, नए कर्मचारी आते हैं। वे इस गलती से कैसे सीखेंगे? हर नए कर्मचारी को बताएं? जाहिर है, अधिक से अधिक गलतियां होंगी - हर कोई उनसे कैसे सीखें? उत्तर लगभग स्पष्ट है: एक do & don'ts फ़ाइल प्राप्त करें ("doos और donts" के रूप में पढ़ें)! रूसी में एक मुफ्त अनुवाद में, मुहावरे का & डॉन का अर्थ है "क्या अच्छा है और क्या बुरा है।" इस फ़ाइल में हम विकास के विषय पर सभी निष्कर्ष लिखते हैं। हम सभी नए कर्मचारियों को फ़ाइल दिखाते हैं, और यह भी डेवलपर्स के सामान्य चैट में दिखाते हैं कि हर बार फ़ाइल अपडेट होने के बाद, और हम कृपया सभी से इसे फिर से पढ़ने के लिए कहें (ताकि पुराने ज्ञान और नए दोनों को ताज़ा करें)।

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

ऊपर वर्णित दुर्घटना से निष्कर्ष: एक do & don'ts फ़ाइल बनाएं, जो आपने इसमें सीखा है उसे लिखें, पूरी टीम को फ़ाइल दिखाएं और सभी नवागंतुकों से इसका अध्ययन करने के लिए कहें।

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

10. एक उपसंहार के बजाय

दूसरे भाग में, मैं आपको सिटीमोबिल के अनुभव के अनुसार दुर्घटनाओं के प्रकारों के बारे में बताऊंगा और प्रत्येक प्रकार के दुर्घटना के विवरण में गोता लगाऊंगा, और आपको यह भी बताऊंगा कि हमने दुर्घटनाओं से क्या निष्कर्ष निकाला, हमने कैसे प्रक्रिया को बदल दिया, जिसने स्वचालन को शुरू किया। दूसरे भाग में सबसे दिलचस्प! देखते रहो!