घातक 43 सेकंड, जो सेवा की दैनिक गिरावट का कारण बना

पिछले हफ्ते GitHub पर एक घटना घटी जिसने 24 घंटे और 11 मिनट तक सेवा को बाधित किया। इस घटना ने पूरे प्लेटफॉर्म को प्रभावित नहीं किया, लेकिन केवल कुछ आंतरिक सिस्टम, जिसके कारण पुरानी और असंगत जानकारी प्रदर्शित हुई। अंततः, उपयोगकर्ता डेटा खो नहीं गया था, लेकिन डेटाबेस में लिखने के कई सेकंड का मैनुअल सामंजस्य अभी भी जारी है। अधिकांश दुर्घटना के लिए, GitHub भी Webhooks को संभालने, GitHub पेज बनाने और प्रकाशित करने में असमर्थ था।

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

प्रागितिहास

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

21 अक्टूबर को 10:52 बजे यूटीसी पर, दोषपूर्ण 100 जी ऑप्टिकल उपकरणों को बदलने के लिए शेड्यूल किए गए मरम्मत कार्य के परिणामस्वरूप ईस्ट कोस्ट (यूएस ईस्ट कोस्ट) पर नेटवर्क नोड और ईस्ट कोस्ट के मुख्य डेटा सेंटर के बीच संचार का नुकसान हुआ। 43 सेकंड के बाद उनके बीच संबंध बहाल हो गया था, लेकिन इस छोटे से वियोग ने कई घटनाओं को जन्म दिया, जिसके कारण 24 घंटे और 11 मिनट तक सेवा में गिरावट आई।


GitHub के उच्च-स्तरीय नेटवर्क आर्किटेक्चर, जिसमें दो भौतिक डेटा केंद्र, 3 POP और कई क्षेत्रों में क्लाउड स्टोरेज शामिल हैं, जो फ़ेयरिंग से जुड़े हैं

अतीत में, हमने चर्चा की कि हम कैसे GTCHub मेटाडेटा को स्टोर करने के लिए MySQL का उपयोग करते हैं, साथ ही MySQL के लिए उच्च उपलब्धता प्रदान करने के लिए हमारा दृष्टिकोण भी। GitHub सैकड़ों गीगाबाइट से लेकर लगभग पाँच टेराबाइट तक के आकार में कई MySQL समूहों का प्रबंधन करता है। प्रत्येक क्लस्टर में Git के अलावा मेटाडेटा को संग्रहीत करने के लिए दर्जनों रीड प्रतिकृतियां होती हैं, इसलिए हमारे एप्लिकेशन पूल अनुरोध, मुद्दे, प्रमाणीकरण, पृष्ठभूमि प्रसंस्करण और Git ऑब्जेक्ट रिपॉजिटरी के बाहर अतिरिक्त सुविधाएं प्रदान करते हैं। एप्लिकेशन के विभिन्न हिस्सों में अलग-अलग डेटा कार्यात्मक विभाजन का उपयोग करके विभिन्न समूहों में संग्रहीत किया जाता है।

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


एक सामान्य टोपोलॉजी में, सभी अनुप्रयोग स्थानीय रूप से कम विलंबता के साथ पढ़ते हैं।

घटना का क्रॉनिकल

10.21.2018, 22:52 यूटीसी

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

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

10.21.2018, 22:54 यूटीसी

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

10.21.2018, 23:07 यूटीसी

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

10.21.2018, 23:13 यूटीसी

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

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


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

10.21.2018, 23:19 यूटीसी

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

10/22/2018, 00:05 यूटीसी

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


पुनर्प्राप्ति योजना में आगे बढ़ना, बैकअप से बहाल करना, सिंक्रनाइज़ करना, वापस रोल करना और हरी स्थिति में लौटने से पहले देरी से काम करना शामिल है

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

10/22/2018, 00:41 यूटीसी

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

10/22/2018, 06:51 यूटीसी

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

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

10/22/2018, 07:46 यूटीसी

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

10/22/2018, 11:12 यूटीसी

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

वास्तव में, लैगिंग प्रतिकृति के कैच-अप समय को तेजी से कम किया जाता है, रैखिक रूप से नहीं। जब अमेरिका और यूरोप में उपयोगकर्ता जाग गए, डेटाबेस क्लस्टर्स में रिकॉर्ड पर लोड बढ़ने के कारण, पुनर्प्राप्ति प्रक्रिया को प्रत्याशित से अधिक समय लगा।

10/22/2018, 13:15 यूटीसी

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

10/22/2018, 16:24 UTC

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

10/22/2018, 16:45 UTC

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

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

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

10/22/2018, 11:03 बजे यूटीसी

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

आगे की कार्रवाई

डेटा मिसमैच को हल करना

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

संचार

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

तकनीकी उपाय

इस विश्लेषण के दौरान, कई तकनीकी उपायों की पहचान की गई थी। विश्लेषण जारी है, सूची को पूरक किया जा सकता है।

• प्राथमिक डेटाबेस को क्षेत्र से बाहर जाने से रोकने के लिए ऑर्केस्ट्रेटर के कॉन्फ़िगरेशन को समायोजित करें। ऑर्केस्ट्रेटर ने सेटिंग्स के अनुसार काम किया, हालांकि अनुप्रयोग परत ने इस तरह के टोपोलॉजी परिवर्तन का समर्थन नहीं किया। एक क्षेत्र के भीतर एक नेता चुनना आमतौर पर सुरक्षित होता है, लेकिन पूरे महाद्वीप में यातायात के प्रवाह में देरी के कारण अचानक उपस्थिति इस घटना का मुख्य कारण बन गया है। यह प्रणाली का एक उभरता हुआ, नया व्यवहार है, क्योंकि इससे पहले कि हम इस परिमाण के नेटवर्क के आंतरिक खंड का सामना नहीं करते थे।
• हमने नई स्थिति रिपोर्टिंग प्रणाली में प्रवासन को तेज कर दिया है, जो अधिक सटीक और स्पष्ट योगों के साथ सक्रिय घटनाओं पर चर्चा करने के लिए अधिक उपयुक्त मंच प्रदान करेगा। हालाँकि पूरे घटनाक्रम में GitHub के कई हिस्से उपलब्ध थे, लेकिन हम पूरी साइट के लिए केवल हरे, पीले और लाल रंग की स्थितियों का चयन कर सकते थे। हम स्वीकार करते हैं कि यह एक सटीक तस्वीर नहीं देता है: क्या काम करता है और क्या नहीं। नई प्रणाली प्लेटफ़ॉर्म के विभिन्न घटकों को प्रदर्शित करेगी ताकि आप प्रत्येक सेवा की स्थिति जान सकें।
• इस घटना से कुछ हफ्ते पहले, हमने सक्रिय / सक्रिय / सक्रिय वास्तुकला का उपयोग करके कई डेटा केंद्रों से GitHub ट्रैफ़िक की सेवा के लिए कॉर्पोरेट-वाइड इंजीनियरिंग पहल शुरू की थी। इस परियोजना का लक्ष्य डेटा केंद्र स्तर पर N + 1 अतिरेक का समर्थन करना है ताकि बाहरी हस्तक्षेप के बिना एक डेटा केंद्र की विफलता का सामना कर सके। यह बहुत काम है और इसमें कुछ समय लगेगा, लेकिन हमारा मानना ​​है कि विभिन्न क्षेत्रों में कई अच्छी तरह से जुड़े डेटा केंद्र एक अच्छा समझौता प्रदान करेंगे। ताजा घटना ने इस पहल को और भी आगे बढ़ा दिया।
• हम अपनी मान्यताओं की जाँच में अधिक सक्रिय रुख अपनाएँगे। GitHub तेजी से बढ़ रहा है और पिछले एक दशक में जटिलता की काफी मात्रा जमा हुई है। समझौता करने और किए गए फैसलों के ऐतिहासिक संदर्भ कर्मचारियों की नई पीढ़ी को पकड़ने और पारित करने के लिए यह मुश्किल होता जा रहा है।

संगठनात्मक उपाय

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

निष्कर्ष

हम जानते हैं कि आप अपनी परियोजनाओं और व्यवसाय में गिटहब पर कैसे भरोसा करते हैं। हम अपनी सेवा की उपलब्धता और आपके डेटा की सुरक्षा के बारे में किसी से अधिक ध्यान रखते हैं। इस घटना के विश्लेषण से आपको बेहतर सेवा करने और अपने विश्वास को सही ठहराने का अवसर मिलता रहेगा।