😸 🐎 👩🏻 जीनस फीनिक्स से डोडो पक्षी की कहानी। डोडो आईएस का महान पतन 🌮 ☢️ 👨🏿‍🌾

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

महान पतन का इतिहास

दिन 1. दुर्घटना जिसमें हमें लाखों रूबल खर्च हुए

21 अप्रैल, 2018 शनिवार को, डोडो आईएस प्रणाली गिर गई। बहुत बुरी तरह से फेल। कई घंटों के लिए, हमारे ग्राहक साइट के माध्यम से या मोबाइल एप्लिकेशन के माध्यम से ऑर्डर नहीं दे सकते हैं। कॉल सेंटर में कॉल की लाइन ऐसी अवस्था में आ गई है कि उत्तर देने वाली मशीन की स्वचालित आवाज़ कहती है: "हम 4 घंटों में वापस कॉल करेंगे।"

उस दिन हमने डोडो आईएस के सबसे गंभीर गिरनों में से एक का अनुभव किया। सबसे बुरी बात यह थी कि जिस दिन हमने 100 मिलियन रूबल के बजट के साथ पहला संघीय टीवी विज्ञापन अभियान शुरू किया था। यह डोडो पिज्जा के लिए एक शानदार कार्यक्रम था। अभियान के लिए आईटी टीम भी अच्छी तरह से तैयार थी। हमने तैनाती को स्वचालित और सरल बनाया - अब टीमसिटी में एक बटन की मदद से हम 12 देशों में एक मोनोलिथ को तैनात कर सकते हैं। हमने हर संभव कोशिश नहीं की और इसलिए पंगा लिया।

विज्ञापन अभियान अद्भुत था। हमें प्रति मिनट 100-150 ऑर्डर मिले। यह अच्छी खबर थी। बुरी खबर: डोडो आईएस इस तरह के भार का सामना नहीं कर सका और मर गया। हम वर्टिकल स्केलिंग की सीमा तक पहुँच गए और अब आदेशों की प्रक्रिया नहीं कर सकते थे। समय-समय पर पुनर्प्राप्त करने के लिए सिस्टम लगभग तीन घंटे तक अस्थिर था, लेकिन तुरंत फिर से गिर गया। डाउनटाइम के प्रत्येक मिनट ने हमें हजारों रूबल की लागत दी, न कि नाराज ग्राहकों से सम्मान की हानि की गिनती की। विकास दल ने सभी को नीचे जाने दिया: ग्राहक, साझेदार, पिज़्ज़ेरिया और एक कॉल सेंटर।

हमारे पास अपनी स्लीव्स को रोल करने और स्थिति को सही करने के लिए बैठने के अलावा कोई विकल्प नहीं था। रविवार (22 अप्रैल) के बाद से, हमने कड़ी मेहनत की है, हमें गलती करने का अधिकार नहीं है।

निम्नलिखित अनुभव का हमारा सारांश है कि इस तरह की स्थिति में खुद को कैसे पाया जाए और बाद में इससे कैसे निकला जाए। दोस्तों, हमारी गलतियाँ मत करो।

दो असफलताएँ जो डोमिनोज़ प्रभाव को लॉन्च करती हैं

यह इस बात से शुरू होने लायक है कि यह सब कैसे शुरू हुआ और हमने कहां-कहां शिकंजा कसा।

शनिवार 04/21/2018 को लगभग 5:00 बजे, हमने देखा कि डेटाबेस में तालों की संख्या बढ़ने लगी थी - समस्याओं का एक अग्रदूत। हमारे पास हल करने के लिए एक रनबुक तैयार थी, जैसा कि हमने समझा कि ये ताले कहाँ से आ रहे थे।

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

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

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

दिन 2. दुर्घटना उन्मूलन

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

आदेश का एक नया स्वागत रविवार, 22 अप्रैल को मुख्य लक्ष्य था। हम समझ गए कि शनिवार को आदेशों का चरम तुलनात्मक होगा। हमारे पास सबसे गंभीर समय सीमा थी - 17 बजे आदेशों की एक नई बाढ़ आ जाएगी।

इस दिन, हमने योजना के अनुसार कार्य किया "यह सुनिश्चित करने के लिए कि यह नहीं गिरता है", जिसे हमने 21 वें दिन की देर शाम को काम किया था, जब हमने पहले से ही सिस्टम को उठाया था और समझा था कि क्या हुआ था। योजना को सशर्त रूप से 2 भागों में विभाजित किया गया था:

मोबाइल एप्लिकेशन में एक नए आदेश के साथ योजना का कार्यान्वयन।
आदेश निर्माण प्रक्रिया का अनुकूलन।

इन बातों को लागू करने से, हम यह सुनिश्चित कर सकते हैं कि डोडो आईएस नहीं गिरेगा।

हम काम और काम के मोर्चे को निर्धारित करते हैं

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

हालांकि वास्तव में एक नई ऑर्डरिंग योजना की शुरुआत, हमने 04.21 के पतन से पहले शुरू की थी, लेकिन सौदा खत्म नहीं किया। अभी भी सक्रिय कीड़े थे और कार्य अर्ध-सक्रिय अवस्था में लटका हुआ था।

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

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

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

लगभग 15:00 बजे अपडेट को आधे नेटवर्क पर ले जाया गया (यह लगभग 200 पिज़्ज़ेरिया है)। 15:30 पर हमने सुनिश्चित किया कि सब कुछ ठीक काम कर रहा था और पूरे नेटवर्क को चालू कर दिया। टॉगल, त्वरित तैनाती, पुर्जों को टूटने और फिक्स्ड एपीआई की सुविधाओं ने यह सब करने में मदद की।

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

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

प्रक्रिया को व्यवस्थित करें

सुबह में, हमारे पास दिन का एकमात्र सिंक था, टीमों में टूट गया और काम करना छोड़ दिया।

सबसे पहले, हमने परिवर्तनों और कार्यों के पूरे लॉग को सीधे स्लैक में रखा, क्योंकि पहले तो इतने सारे कार्य नहीं थे। लेकिन उनकी संख्या बढ़ रही थी, इसलिए हम जल्दी से ट्रेलो चले गए। स्लैक और ट्रेलो के बीच कॉन्फ़िगर किए गए एकीकरण ने पहेली में किसी भी स्थिति में परिवर्तन की सूचना दी।

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

बुलेट ने बुलेट की गति से उत्पादन के लिए उड़ान भरी। कुल मिलाकर, हमने उस दिन 15 बार सिस्टम को अपडेट किया। लोगों को प्रति टीम, एक टेस्ट स्टैंड पर तैनात किया गया था। विकास, त्वरित जांच, उत्पादन पर तैनाती।

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

उस दिन के बाद, इस भावना के साथ बाहर जाना जरूरी था कि हमने वह सब कुछ किया जो हम कर सकते थे। और भी अधिक। और हमने यह किया! 15:30 पर एक आदेश प्राप्त करने की एक नई योजना पूरे नेटवर्क में एक मोबाइल एप्लिकेशन के लिए शुरू की गई थी। हैकाथॉन मोड, प्रति दिन प्रति उत्पादन 20 तैनाती के तहत!

22 अप्रैल की शाम शांत और स्पष्ट थी। न तो गिरता है और न ही एक संकेत है कि सिस्टम खराब हो सकता है।

लगभग 10 बजे हम फिर से एकत्र हुए और एक साप्ताहिक कार्य योजना की रूपरेखा तैयार की। सीमा, प्रदर्शन परीक्षण, अतुल्यकालिक आदेश और बहुत कुछ। यह एक लंबा दिन था, और आगे लंबे हफ्ते थे।

पुनर्जन्म

23 अप्रैल का सप्ताह नारकीय था। इसके बाद, हमने अपने आप से कहा कि हमने अपना सर्वश्रेष्ठ 200% किया है और हमने जो कुछ भी किया है वह सब किया है।

हमें डोडो आईएस को बचाना था और कुछ चिकित्सा सादृश्य लागू करने का फैसला किया। सामान्य तौर पर, यह एक रूपक (मूल XP में) का उपयोग करने का पहला वास्तविक मामला है, जो वास्तव में समझने में मदद करता है कि क्या किया गया था:

पुनर्जीवन - जब आपको एक रोगी को बचाने की आवश्यकता होती है जो मर रहा है।
उपचार - जब लक्षण होते हैं, लेकिन रोगी अभी भी जीवित है।

पुनर्जीवन

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

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

इलाज

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

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

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

नरक सप्ताह: प्रक्रिया संगठन

40 लोगों की एक टीम ने एक बड़े लक्ष्य पर काम किया - प्रणाली का स्थिरीकरण। सभी टीमों ने एक साथ काम किया। पता नहीं क्या करना है? अन्य टीमों की मदद करें। विशिष्ट लक्ष्यों पर ध्यान केंद्रित करने और छिड़काव करने में मदद न करने के लिए और उस बकवास में संलग्न न होने में मदद की जो हमारे लिए अनावश्यक थी।

दिन में तीन बार सिंक्रनाइज़ेशन, एक सामान्य स्टैंड-अप, जैसा कि एक क्लासिक घोटाले में था। 40 लोगों के लिए। केवल तीन सप्ताह में (लगभग 90 syncs के लिए) हम 30 मिनट तक नहीं मिले। सबसे लंबा सिंक 57 मिनट तक चला। हालांकि आमतौर पर उन्हें 20-30 मिनट लगते थे।

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

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

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

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

गिरने के बाद दूसरा और तीसरा सप्ताह पहले से ही एक शांत मोड में था, देर शाम तक नारकीय गति बनी रही, लेकिन मार्शल लॉ की सामान्य प्रक्रिया बनी रही।

अगला दिन एक्स: शक्ति परीक्षण

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

उस दिन हमें रूस में 91500 आदेश मिले (उस समय डोडो के इतिहास में दूसरा परिणाम)। किसी समस्या का मामूली संकेत भी नहीं था। 9 मई ने पुष्टि की कि हम सही रास्ते पर हैं! स्थिरता, प्रदर्शन, गुणवत्ता पर ध्यान दें। प्रक्रिया के पुनर्गठन ने हमें और इंतजार किया, लेकिन यह पूरी तरह से अलग कहानी है।

रेट्रो ग्रेट फॉल और 6 प्रैक्टिस

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

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

नतीजतन, 6 महत्वपूर्ण प्रथाएं थीं जिनके बारे में मैं अधिक विस्तार से बात करना चाहूंगा।

Top N . , . Product Owners , , , . . , . , , , . , . N – Lead Time .
. . -, , . , , , . .
. , « » . , . , , . , - . Dodo IS. .
Pull Request. , Pull Request, - . . , , , , - . , . , . 15 .
Performance- — . performance- . , . Performance- . baseline , PR . , .
Performance . — . , , -, , , . . , .

21.04.2018 – Dodo IS. ?

(Site Reliability Engineering): . , .

(Site Reliability Engineering, Product Owner Dodo IS): . , , .

auth’, . . , .

, () :

. , .

. , . . -. , , . - , , . , -, , .

. redis, . . - , . .

Dodo IS . . , . , , , , . , — .

. « ». « , » .

- ?

:

– . . . , . . .

:

. , . ( ), - . .

. :

?

:

, , , .

:

, , . , .

? ?

: , – .

— . - - .

, . 2018 , PerformanceLab, .
, . Less-.
. 2018 -, . , . - 2018 .
async . , 21.04.2018 . , . async.
. , SaveOrder async-await. , . : , LF, 20 . , . , . !

, , , .

, , . — -. .
. , (, ). , . «» . nginx , - , .

: innodb_lock_wait_timeout = 5; innodb_rollback_on_timeout = ON. . , , , , .

, ?

, , , . , .
, .
, , , . – .

.
. , , -. .
. , - , .

, ?

:

«» , «». , , . .

:

, . , , . .

2. , (Dodo IS Architect)

— , . , — .

, , . , (, , ) .

IT-. Dodo IS, . …

X , . . Dodo IS , , , . , , , . . 146%, . , Dodo IS ?

, . , , . , . , !

, . « »: 11- , , 2 . «» . 3-4 , . , . .

, , . . Dodo IS , « ». ! ( ).

, Dodo IS , . Dodo IS . « », , . ( ), loadtest, , .

जीनस फीनिक्स से डोडो पक्षी की कहानी। डोडो आईएस का महान पतन