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

यह श्रृंखला का अंतिम भाग है जिसमें बताया गया है कि हम सिटीमोबिल में हमारी सेवा उपलब्धता कैसे बढ़ा रहे हैं (आप पिछले भाग को यहाँ पढ़ सकते हैं)। अब मैं एक और प्रकार के आउटेज के बारे में बात करने जा रहा हूं और हमने उनके बारे में जो निष्कर्ष निकाले हैं, हमने विकास प्रक्रिया को कैसे संशोधित किया है, जो स्वचालन ने पेश किया है।

1. खराब रिलीज: बग

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

अन्य सभी प्रकार के आउटेज "खराब रिलीज: 500 आंतरिक सर्वर त्रुटियों" के समान हैं। केवल एक चीज यह है कि वे एक रिलीज से ट्रिगर नहीं होते हैं, बल्कि एक कार्यभार, मैनुअल ऑपरेशन या एक बाहरी सेवा समस्या है।

इस तरह के आउटेज से निपटने की विधि का वर्णन करने के लिए, हमें एक पुराना मजाक याद करना चाहिए:

एक गणितज्ञ और एक भौतिक विज्ञानी को एक ही कार्य प्रदान किया जाता है: पानी को उबालने के लिए। उन्हें कुछ सहायक उपकरण दिए गए हैं: एक स्टोव, एक केतली, पानी के साथ एक नल, मेल खाता है। वे दोनों केतली को पानी से भरने में बदल जाते हैं, गैस को चालू करते हैं और केतली को गर्म करना शुरू करते हैं। फिर कार्य सरल किया जाता है: उन्हें केतली दिया जाता है, पानी से भरा होता है और एक स्टोव जो पहले से ही है। कार्य समान है - पानी उबालें। भौतिक विज्ञानी केतली को स्टोव पर रखता है। गणितज्ञ केतली को खाली करता है, गैस को बंद करता है और कहता है: "समस्या उस तक कम हो जाती है जो पहले से ही हल हो गई है।" © anekdotov.net

इस तरह के आउटेज को "खराब रिलीज: 500 आंतरिक सर्वर त्रुटियों" को हर कीमत पर कम किया जाना चाहिए। आदर्श रूप से, बग को 500 त्रुटियों के समान लॉग किया जाना चाहिए। हालाँकि, निश्चित रूप से, आप बग की घटना को लॉग नहीं कर सकते क्योंकि यदि आप पहली बार में बग नहीं बना सकते थे।

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

1.1। बग की वजह से होने वाले नुकसान का उदाहरण

अचानक हमें अपने उपयोगकर्ताओं से भारी मात्रा में शिकायतें मिल रही थीं: Apple वेतन के माध्यम से भुगतान किए जाने वाले ऑर्डर बंद नहीं किए जा सकते थे। हमने अपनी जांच शुरू की; समस्या का परीक्षण वातावरण में पुन: पेश किया गया था। मूल कारण पाया गया: हमने क्रेडिट कार्ड के लिए समाप्ति तिथि के प्रारूप को अपडेट किया क्योंकि यह एक भुगतान प्रसंस्करण सेवा द्वारा बदल दिया गया था, लेकिन हमने इसे ऐप्पल पे के माध्यम से भुगतान के लिए सही ढंग से नहीं किया; इसलिए, एप्पल के सभी भुगतानों को अस्वीकार कर दिया गया था। जैसे ही हमें इस मुद्दे के बारे में पता चला, इसे तैनात किया और समस्या दूर हो गई। हालाँकि, यह समस्या 45 मिनट तक लाइव थी।

इस समस्या के मद्देनजर, हमने कई असफल Apple वेतन भुगतानों की निगरानी की और कुछ नॉनज़रो थ्रेशोल्ड के साथ एसएमएस और आईवीआर अलर्ट बनाए (क्योंकि कुछ असफल भुगतान सेवा द्वारा सामान्य माने जाते हैं; उदाहरण के लिए, यदि क्लाइंट के खाते में कोई पैसा नहीं है; या उसका क्रेडिट कार्ड अवरुद्ध है)। उस पल के बाद से, हम तुरंत दहलीज पार करने के बारे में पता लगा लेंगे। यदि कोई नई रिलीज़ Apple वेतन प्रसंस्करण में कोई समस्या लाती है, तो हम तुरंत 3 मिनट के भीतर रिलीज़ को वापस मॉनिटर करने और रोल करने के कारण पाएंगे (मैन्युअल रोलबैक की प्रक्रिया पिछले लेखों में से एक में वर्णित है)। इसलिए यह आंशिक डाउनटाइम के 45 मिनट हुआ करता था, और अब यह 3 मिनट है। लाभ!

1.2। अन्य उदाहरण

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

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

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

जैसा कि आप बता सकते हैं, हम इस तरह की सभी घटनाओं से निपटने के लिए एक ही दृष्टिकोण का उपयोग कर रहे हैं:

1. हम एक समस्या के बारे में पता लगाते हैं।
2. हम इसका निवारण करते हैं और कोड में एक बग ढूंढते हैं।
3. हम इसे ठीक करते हैं।
4. हम डेटाबेस में निशान का पता लगाते हैं (वेब-सर्वर लॉग या किबाना में भी निशान पाया जा सकता है) जो समस्या के संकेतों को इंगित कर सकता है।
5. हम इन निशानों का ग्राफ बनाते हैं।
6. हम समय में वापस जाते हैं और ग्राफ में उतार-चढ़ाव को देखते हैं।
7. हम अलर्ट के लिए एक अच्छी सीमा का चयन करते हैं।
8. जब समस्या फिर से उत्पन्न होती है, तो हम तुरंत एसएमएस अलर्ट के माध्यम से इसके बारे में पता लगाते हैं।

इस पद्धति के बारे में क्या अच्छा है: एक ग्राफ़ और एक चेतावनी पूरे बड़े समूह को हल करती है (समस्या समूहों के उदाहरण: आदेश बंद नहीं किए जा सकते हैं, अतिरिक्त बोनस, Apple वेतन भुगतान आदि नहीं होते हैं)

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

2. कोटान

हमारी प्रक्रिया स्वचालन स्तर बढ़ रहा था, और हमने फैसला किया कि यह एक वेब इंटरफ़ेस बनाने का समय था जो वर्तमान विकास प्रक्रिया की स्थिति को दिखाएगा। हमने इस वेब इंटरफ़ेस को "कोटान" (रूसी शब्द से "रोल", "रोल आउट करने के लिए" कहा है) :-)

"Kotan" की निम्नलिखित कार्यक्षमता है:

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

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

रिपोर्ट। ये सभी इतिहास की रिपोर्ट हैं। हर रिपोर्ट में इसके साथ जुड़ी सभी घटनाओं के लिंक होते हैं (कभी-कभी घटनाएं समूहों में आती हैं; मूल कारण समान है, और हम पूरे समूह के लिए एक रिपोर्ट बनाते हैं), यह रिपोर्ट लिखी गई थी, समस्या समाधान पुष्टि ध्वज और सबसे महत्वपूर्ण: मूल कारण, यह कैसे तय किया गया था, व्यापार पर प्रभाव, takeaways।

टेकअवे की सूची । प्रत्येक takeaway में एक नोट है कि क्या इसे लागू किया गया है, कार्यान्वयन अभी भी आ रहा है, या इसकी आवश्यकता नहीं है (स्पष्टीकरण के साथ क्यों नहीं)।

3. सॉफ्टवेयर विकास प्रक्रिया में क्या बदलाव आया है?

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

यह सुनिश्चित करने के लिए कि प्रत्येक घटना के टेकअवे हैं, हमने निम्नलिखित कार्य किए हैं:

• हर अलर्ट स्वचालित रूप से रिलीज को रोकता है।
• जब हमें एक समापन चेतावनी मिलती है (एक पाठ संदेश जो यह कहता है कि घटना समाप्त हो गई है), हम तुरंत रिलीज़ को अनब्लॉक नहीं करते हैं, लेकिन इसके बजाय हम दुर्घटना पर एक रिपोर्ट बनाने की पेशकश करते हैं।
• एक रिपोर्ट में निम्नलिखित जानकारी होनी चाहिए: एक दुर्घटना का मूल कारण, यह कैसे तय किया गया था, व्यापार प्रभाव, takeaways।
• टीम ने रिपोर्ट लिखी है जो दुर्घटना का निवारण करती है। जो दुर्घटना की पूरी जानकारी से लैस थे।
• जब तक इस तरह की रिपोर्ट बनाई और अनुमोदित नहीं की जाती है, तब तक स्वचालित रूप से ब्लॉक किए जाते हैं। जो टीम को किसी दुर्घटना के ठीक होने के तुरंत बाद ध्यान केंद्रित करने और रिपोर्ट बनाने के लिए प्रेरित करता है।
• रिपोर्ट को किसी ऐसे व्यक्ति द्वारा अनुमोदित किया जाना चाहिए जो टीम पर नहीं है, यह सुनिश्चित करने के लिए कि रिपोर्ट में वह सभी जानकारी है जो इसे समझने के लिए आवश्यक है।

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

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

एक उपसंहार के बदले, मुझे जल्दी से संक्षेप में बताएं कि हमने कई खोई हुई यात्राओं को कम करने के लिए सॉफ़्टवेयर विकास प्रक्रिया में क्या बदलाव किया है।


अंत तक पढ़ने के लिए धन्यवाद। आपके व्यवसाय के लिए शुभकामनाएँ! मैं आपको खोए हुए ऑर्डर, लेन-देन, खरीदारी, यात्राएं और जो भी आपके लिए महत्वपूर्ण है, कम चाहता हूं!