Citymobil - विकास के बीच स्थिरता बढ़ाने के लिए स्टार्टअप के लिए एक गाइड। भाग 2. दुर्घटनाओं के प्रकार क्या हैं?

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

0. प्रस्तावना

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

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

यह हिमशैल के सभी टिप है। कार्यक्षमता बहुत अधिक है। उपयोगकर्ता के अनुकूल इंटरफेस हिमशैल के एक विशाल पानी के नीचे भाग को छुपाता है।

और अब वापस दुर्घटनाओं के लिए। दुर्घटनाओं के इतिहास के छह महीनों में, हमने निम्नलिखित वर्गीकरण को संकलित किया है:

• खराब रिलीज, 500 वीं त्रुटियां;
• खराब रिलीज, सबॉप्टिमल कोड, आधार पर लोड;
• सिस्टम में असफल मैनुअल हस्तक्षेप;
• ईस्टर अंडे;
• बाहरी कारण;
• खराब रिलीज, टूटी हुई कार्यक्षमता।

नीचे मैं लिखूंगा कि सबसे सामान्य प्रकार के दुर्घटनाओं पर हमने कौन से निष्कर्ष निकाले।

1. खराब रिलीज, 500 वीं त्रुटियां

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

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

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

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

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

यहां खराब रिलीज से निपटने के लिए एक प्रक्रिया है, हमें सुधार करना था।

1.1। निष्क्रिय अवस्था में कमी

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

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

1. प्रोग्रामर कोड को दर्शाता है।
2. रिलीज एक दुर्घटना (बड़े पैमाने पर 500s) की ओर जाता है।
3. एसएमएस आता है।
4. प्रोग्रामर और एडमिनिस्ट्रेटर समझने लगते हैं (कभी-कभी तुरंत नहीं, लेकिन 2-3 मिनट के बाद: एसएमएस में देरी हो सकती है, फोन पर ध्वनि बंद हो सकती है, और एक दिन में एसएमएस के बाद तत्काल कार्रवाई की संस्कृति दिखाई नहीं दे सकती)।
5. दुर्घटना का सक्रिय चरण शुरू होता है, जो पहले की तरह ही 10 मिनट तक रहता है।

इस प्रकार, निष्क्रिय चरण को 15 मिनट से घटाकर 3 कर दिया गया था।

1.2। निष्क्रिय चरण की और कमी

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

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

हमने आँकड़ों के आधार पर तीन मिनट चुने: कभी-कभी 1-2 मिनट की देरी से चार्ट पर समस्याएं दिखाई देती थीं, लेकिन कभी भी तीन मिनट से अधिक नहीं होते थे।

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

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

1.3। सक्रिय चरण में और कमी

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

इस सरल नियम ने दुर्घटनाओं के दौरान पहले से ही रिलीज की संख्या में तेजी से कमी की और सक्रिय चरण को कम कर दिया - 5 मिनट से 3 तक।

1.4। सक्रिय चरण में और भी अधिक कमी

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

इस प्रकार, यह प्रक्रिया इस तरह बन गई: डेवलपर रोल आउट करता है, तीन मिनट के लिए चार्ट की निगरानी करता है, और उसके बाद दो और मिनटों के लिए कोई भी कुछ भी रोल आउट नहीं कर सकता है। यदि कोई समस्या है, तो डेवलपर रिलीज़ को वापस ले लेता है। इस नियम ने मौलिक रूप से निदान को सरल बनाया, और सक्रिय और निष्क्रिय चरणों की कुल अवधि 3 + 1 = 4 मिनट से घटकर 1 + 1 = 2 मिनट हो गई।

लेकिन दुर्घटना के दो मिनट बहुत है। इसलिए, हमने प्रक्रिया का अनुकूलन जारी रखा।

1.5। स्वचालित क्रैश डिटेक्शन और रोलबैक

हम लंबे समय से सोच रहे हैं कि खराब रिलीज के कारण दुर्घटना की अवधि को कैसे कम किया जाए। उन्होंने खुद को tail -f error_log | grep 500 में देखने के लिए मजबूर करने की भी कोशिश tail -f error_log | grep 500 tail -f error_log | grep 500 । लेकिन अंत में, वे सभी एक कार्डिनल स्वचालित समाधान पर बस गए।

संक्षेप में, यह एक ऑटो-रोलबैक है। हमने एक अलग वेब सर्वर स्थापित किया है, जिस पर हमने अन्य वेब सर्वरों की तुलना में बैलेंसर से 10 गुना कम भार लोड किया है। प्रत्येक रिलीज़ स्वचालित रूप से इस अलग सर्वर पर सीआई / सीडी-सिस्टम द्वारा तैनात किया गया था (हमने इसे प्रीप्रोड कहा, हालांकि, नाम के बावजूद, वास्तविक उपयोगकर्ताओं से वास्तविक लोड वहां गया)। और फिर स्वचालन ने tail -f error_log | grep 500 tail -f error_log | grep 500 । यदि एक मिनट के भीतर कोई 500 वीं त्रुटि नहीं हुई, तो CI / CD ने उत्पादन में नया कोड तैनात किया। यदि त्रुटियां दिखाई दीं, तो सिस्टम ने तुरंत सब कुछ वापस कर दिया। इसी समय, बैलेंसर स्तर पर, प्रॉप्रोड पर 500 त्रुटियों के साथ पूरा किए गए सभी अनुरोधों को उत्पादन सर्वरों में से एक में दोहराया गया था।

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

2. खराब रिलीज, सबॉप्टिमल कोड, बेस लोड

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

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

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

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

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

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

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

3. सिस्टम में असफल मैनुअल हस्तक्षेप

ऐसे हादसों के उदाहरण: एक असफल ALTER (जिसने डेटाबेस को ओवरलोड किया था या एक प्रतिकृति लैग उकसाया था) या असफल DROP (MySQL के बग में भाग गया था, डेटाबेस को ब्लॉक कर दिया जब एक ताज़ा टेबल गिरा दिया गया था); हाथ से गलती से मास्टर के लिए भारी अनुरोध; हमने लोड के तहत सर्वर पर काम किया, हालांकि हमें लगा कि यह काम से बाहर है।

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

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

अदृश्य लेकिन कठोर लोहे के हुक के साथ निगरानी और सतर्कता अनिश्चितता की चट्टान में कट जाती है और हमें कभी भी हमारे द्वारा निर्धारित स्थिरता के स्तर से नीचे नहीं गिरने देती है, जिसे हम लगातार केवल ऊपर उठाते हैं।

4. ईस्टर अंडा

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

उदाहरण के लिए: अतिप्रवाह 32 बिट auto_increment ; कोड / कॉन्फ़िगरेशन में गैर-समानता, लोड के कारण "शॉट"; एक लैगिंग प्रतिकृति (आमतौर पर या तो एक प्रतिकृति के लिए एक उप-अपनाने के अनुरोध के कारण होता है जिसे एक नए उपयोग पैटर्न, या एक उच्च लोड द्वारा ट्रिगर किया गया था, या एक नए लोड पैटर्न द्वारा ट्रिगर किए गए मास्टर पर एक प्रतिकृति और लोड किए गए प्रतिकृति के कारण)।

ईस्टर अंडे का एक अन्य लोकप्रिय प्रकार गैर-इष्टतम कोड है, और अधिक विशेष रूप से, गैर-इष्टतम SQL क्वेरी। पहले, तालिका छोटी थी और लोड कम था - क्वेरी अच्छी तरह से काम करती थी। और तालिका में वृद्धि के साथ, समय में रैखिक और भार में वृद्धि, समय में रैखिक, DBMS संसाधन की खपत में वृद्धि हुई है। आमतौर पर यह एक तेज नकारात्मक प्रभाव की ओर जाता है: सब कुछ "ठीक" था, और धमाकेदार।

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

हालाँकि, हमारे पास ईस्टर अंडे भी थे, जो भार से संबंधित नहीं थे। उदाहरण के लिए, 32-बिट auto increment : तालिका में दो और कुछ अरब रिकॉर्ड के बाद, आवेषण को निष्पादित किया जाना है। तो आधुनिक दुनिया में auto increment के क्षेत्र को 64-बिट किया जाना चाहिए। हमने इस पाठ को अच्छी तरह से सीखा।

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

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

5. बाहरी कारण

ये ऐसे कारण हैं जो हमें लगता है कि हमारे द्वारा खराब नियंत्रित हैं। उदाहरण के लिए:

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

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

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

6. खराब रिलीज, टूटी हुई कार्यक्षमता

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

अन्य सभी प्रकार की दुर्घटनाएं "खराब रिलीज, 500 वीं त्रुटियों" के समान हैं। यह सिर्फ इतना है कि ट्रिगर एक रिलीज नहीं है, बल्कि एक लोड, एक मैनुअल ऑपरेशन या बाहरी सेवा के पक्ष में एक समस्या है।

इस प्रकार की दुर्घटना से निपटने की विधि का वर्णन करने के लिए, दाढ़ी वाले किस्से को याद करना पर्याप्त है:

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

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

6.1। उदाहरण

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

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

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

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

यात्राओं के लिए उपयोगकर्ताओं को कैशबैक देने के तर्क को बदल दिया। जिसमें उपयोगकर्ताओं के गलत समूह को वितरित करना शामिल है। हमने समस्या को ठीक किया, कैशबैक का एक शेड्यूल बनाया, वहां एक तेज वृद्धि देखी, यह भी देखा कि इस तरह की वृद्धि कभी नहीं हुई, एक एसएमएस अलर्ट बना।

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

जैसा कि आप देख सकते हैं, इस प्रकार की दुर्घटना का दृष्टिकोण हमेशा समान होता है:

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

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

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

7. कोटान

, , -, . - ( , ) «». «». :-)

«» :

. — , . , ( ), ( ) , . ( , ).

. , . , : — , — . , « 500- 1 %» — . « 500- 1 %, - , - , - » — . , . ( ). , : , «», , , , . — . ( , ). .

रिपोर्ट। . , ( , , ), , : , , , .

. , , ( , ).

8. ?

— . . : , . , , . , , , .. — , — ! , . , , ? , , .. , , .

. . ( , ), , : , , , . , , . . . -, , . , , , — : .

9.

, .

?	?
.	.
( ) post-mortem.	.
do's & dont's.	, , .
, 5 .	.
, .	.
.	.
	.
.	.
.	.
SMS/IVR- .	.
( ) .	.
.	- .
( — slow.log).	- « ».
.	.
.	.
.	, , .
«» — .	, .
.	.

, ! , , , , !