सिटीमोबिल - स्टार्टअप्स के लिए व्यावसायिक विकास के बीच उपलब्धता में सुधार के लिए एक मैनुअल। भाग २

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

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

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

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

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

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

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

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

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

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

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

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

2. उपलब्धता की धमकी क्यों आई?

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

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

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

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

आपको लगता है कि सब कुछ काफी सरल था: हम Citymobil पर Mail.Ru ईमेल / क्लाउड प्रक्रिया को दोहरा सकते थे ताकि सेवा की उपलब्धता बढ़ सके। हालांकि, जैसा कि वे कहते हैं - शैतान विवरण में है:

1. Mail.Ru ईमेल / क्लाउड में तैनाती सप्ताह में एक बार आयोजित की जाती है, दिन में 30 बार नहीं; सिटीमोबिल में हम रिलीज की मात्रा का त्याग नहीं करना चाहते थे;
   
2. मेल में। ईमेल / क्लाउड कोड को ऑटो / यूनिट टेस्ट द्वारा कवर किया गया है और सिटीमोबिल में हमारे पास न तो समय है और न ही संसाधन हैं; हमने अपने सभी बैकेंड विकास प्रयासों को परिकल्पना और उत्पाद सुधार परीक्षण में झोंक दिया।
   

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

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

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

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

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

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

प्रत्येक बड़े आउटेज के लिए, हम उस क्षण से लेकर समाप्त होने तक विस्तृत मिनट-दर-मिनट विवरण के साथ एक अलग बड़ी फ़ाइल बनाएंगे: जब तक कि यह समाप्त नहीं हो जाता है: हमने क्या किया, क्या निर्णय किए गए। इसे आमतौर पर पोस्टमार्टम कहा जाता है। हम इन पोस्ट-मॉर्टम के लिंक को सामान्य तालिका में जोड़ देंगे।

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

5. हमारे द्वारा सीखे गए आउटेज का उदाहरण

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

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

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

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

6. हम इस गलती से और क्या सीख सकते हैं या "क्या करें और क्या न करें"।

ठीक है, चलो इस आउटेज का विश्लेषण करते रहें। कंपनी तेजी से बढ़ रही है, नए इंजीनियर आ रहे हैं। वे इस गलती से कैसे सीख रहे हैं? क्या हमें हर नए इंजीनियर को इसके बारे में बताना चाहिए? जाहिर है, अधिक से अधिक गलतियाँ होंगी - हम सभी को उनसे कैसे सीखते हैं? उत्तर लगभग स्पष्ट है: do's और file बनाएँ। हम इस फाइल में सभी takeaways लिख रहे हैं। हम इस फाइल को अपने सभी नए इंजीनियरों को और हमारे सभी मौजूदा इंजीनियरों को एक कार्यसमूह में चैट करते हैं, जब भी हर बार do & don'ts अपडेट किया जाता है, दृढ़ता से सभी को इसे फिर से पढ़ने (पुरानी जानकारी पर ब्रश करने और देखने के लिए आग्रह करता हूं) नया एक)।

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

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

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

7. उपसंहार के बदले में

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