डेटा सेंटरच्या धुराच्या चाचणीला आग लागल्यास सर्व्हर विझवावेत का?

उन्हाळ्याच्या एका चांगल्या दिवशी तुमच्या उपकरणांसह डेटा सेंटर असे दिसल्यास तुम्हाला कसे वाटेल?

सर्वांना नमस्कार! माझे नाव दिमित्री सॅमसोनोव्ह आहे, मी येथे प्रमुख सिस्टम प्रशासक म्हणून काम करतो.वर्गमित्र" फोटो चार डेटा केंद्रांपैकी एक दर्शवितो जेथे आमच्या प्रकल्पाची सेवा देणारी उपकरणे स्थापित केली आहेत. या भिंतींच्या मागे सुमारे 4 हजार उपकरणे आहेत: सर्व्हर, डेटा स्टोरेज सिस्टम, नेटवर्क उपकरणे इ. - आमच्या सर्व उपकरणांपैकी जवळजवळ ⅓.
बहुतेक सर्व्हर लिनक्स आहेत. विंडोज (एमएस एसक्यूएल) वर अनेक डझन सर्व्हर देखील आहेत - आमचा वारसा, ज्याला आम्ही अनेक वर्षांपासून पद्धतशीरपणे सोडून देत आहोत.
त्यामुळे, 5 जून 2019 रोजी 14:35 वाजता, आमच्या एका डेटा सेंटरमधील अभियंत्यांनी फायर अलार्मची तक्रार नोंदवली.

नकारात्मक

१४:४५. डेटा सेंटर्समध्ये धुराच्या किरकोळ घटना तुम्हाला वाटते त्यापेक्षा जास्त सामान्य आहेत. हॉलमधील निर्देशक सामान्य होते, म्हणून आमची पहिली प्रतिक्रिया तुलनेने शांत होती: त्यांनी उत्पादनासह कामावर बंदी आणली, म्हणजे, कॉन्फिगरेशनमधील कोणत्याही बदलांवर, नवीन आवृत्त्या रोल आउट करण्यावर, इ. काही निश्चित करण्याशी संबंधित काम वगळता.

राग

छताला आग नेमकी कुठे लागली हे अग्निशामक दलाकडून जाणून घेण्याचा किंवा परिस्थितीचे आकलन करण्यासाठी तुम्ही स्वतः जळत्या छतावर जाण्याचा प्रयत्न केला आहे का? पाच लोकांच्या माध्यमातून मिळालेल्या माहितीवर विश्वास ठेवण्याचे प्रमाण किती असेल?

14: 50 आग कुलिंग सिस्टीमजवळ येत असल्याची माहिती मिळाली आहे. पण येईल का? कर्तव्यावरील सिस्टम प्रशासक या डेटा सेंटरच्या समोरील बाह्य रहदारी काढून टाकतो.

याक्षणी, आमच्या सर्व सेवांचे फ्रंट तीन डेटा सेंटरमध्ये डुप्लिकेट केले गेले आहेत, DNS स्तरावर संतुलन वापरले जाते, जे आम्हाला DNS वरून एका डेटा सेंटरचे पत्ते काढून टाकण्याची परवानगी देते, ज्यामुळे वापरकर्त्यांना सेवांमध्ये प्रवेश करण्याच्या संभाव्य समस्यांपासून संरक्षण मिळते. . डेटा सेंटरमध्ये आधीच समस्या आल्या असल्यास, ते आपोआप रोटेशन सोडते. आपण येथे अधिक वाचू शकता: ओड्नोक्लास्निकीमध्ये लोड बॅलन्सिंग आणि फॉल्ट टॉलरन्स.

आगीचा आमच्यावर अद्याप कोणत्याही प्रकारे परिणाम झालेला नाही - वापरकर्ते किंवा उपकरणांचे नुकसान झाले नाही. हा अपघात आहे का? दस्तऐवजाचा पहिला विभाग "अपघात कृती योजना" "अपघात" ची संकल्पना परिभाषित करतो आणि विभाग याप्रमाणे समाप्त होतो:
«अपघात झाला की नाही अशी शंका आली तर तो अपघातच!»

14:53. आपत्कालीन समन्वयक नियुक्त केले जातात.

समन्वयक ही अशी व्यक्ती आहे जी सर्व सहभागींमधील संवाद नियंत्रित करते, अपघाताच्या प्रमाणात मूल्यांकन करते, आपत्कालीन कृती योजना वापरते, आवश्यक कर्मचारी आकर्षित करते, दुरुस्ती पूर्ण होण्यावर लक्ष ठेवते आणि सर्वात महत्त्वाचे म्हणजे कोणतीही कामे सोपवते. दुसऱ्या शब्दांत, ही अशी व्यक्ती आहे जी संपूर्ण आपत्कालीन प्रतिसाद प्रक्रिया व्यवस्थापित करते.

सौदा

१५:०१. आम्ही उत्पादनाशी संबंधित नसलेले सर्व्हर अक्षम करण्यास सुरवात करतो.
१५:०३. आम्ही सर्व आरक्षित सेवा योग्यरित्या बंद करतो.
यामध्ये केवळ आघाडी (ज्यापर्यंत वापरकर्ते यापुढे प्रवेश करू शकत नाहीत) आणि त्यांच्या सहायक सेवा (व्यवसाय तर्कशास्त्र, कॅशे इ.) समाविष्ट करत नाहीत, तर प्रतिकृती घटक 2 किंवा अधिक असलेले विविध डेटाबेस (शरिरासाठी चांगलं असतं,, बायनरी डेटा स्टोरेज, शीतगृह, NewSQL इ.).
15: 06 डेटा सेंटरच्या एका हॉलला आग लागण्याचा धोका असल्याची माहिती मिळाली आहे. आमच्याकडे या खोलीत उपकरणे नाहीत, परंतु आग छतापासून हॉलमध्ये पसरू शकते या वस्तुस्थितीमुळे काय घडत आहे याचे चित्र मोठ्या प्रमाणात बदलते.
(नंतर असे दिसून आले की हॉलला कोणताही शारीरिक धोका नाही, कारण ते छतावरून हर्मेटिकली सील केलेले होते. धोका फक्त या हॉलच्या कूलिंग सिस्टमला होता.)
१५:०७. आम्ही सर्व्हरवर अतिरिक्त तपासण्यांशिवाय प्रवेगक मोडमध्ये कमांडच्या अंमलबजावणीला परवानगी देतो (आमच्या आवडत्या कॅल्क्युलेटरशिवाय).
१५:०८. हॉलमधील तापमान सामान्य मर्यादेत आहे.
15: 12 हॉलमध्ये तापमानात वाढ नोंदवली गेली.
१५:१३. डेटा सेंटरमधील अर्ध्याहून अधिक सर्व्हर बंद आहेत. चला सुरू ठेवूया.
१५:१६. सर्व उपकरणे बंद करण्याचा निर्णय घेण्यात आला.
१५:२१. आम्ही अॅप्लिकेशन आणि ऑपरेटिंग सिस्टम योग्यरित्या बंद न करता स्टेटलेस सर्व्हरची वीज बंद करण्यास सुरुवात करतो.
१५:२३. एमएस एसक्यूएलसाठी जबाबदार असलेल्या लोकांच्या गटाचे वाटप केले गेले आहे (त्यापैकी काही आहेत, त्यांच्यावरील सेवांचे अवलंबित्व मोठे नाही, परंतु कार्यक्षमता पुनर्संचयित करण्याची प्रक्रिया जास्त वेळ घेते आणि उदाहरणार्थ, कॅसॅंड्रापेक्षा अधिक क्लिष्ट आहे).

औदासिन्य

15: 25 16 पैकी चार हॉलमध्ये (क्र. 6, 7, 8, 9) वीज बंद असल्याची माहिती मिळाली. आमची उपकरणे हॉल 7 आणि 8 मध्ये आहेत. आमच्या दोन हॉलची (क्र. १ आणि २) माहिती नाही.
सहसा, आगीच्या वेळी, वीजपुरवठा ताबडतोब बंद केला जातो, परंतु या प्रकरणात, अग्निशामक आणि डेटा सेंटरच्या तांत्रिक कर्मचार्‍यांच्या समन्वित कार्याबद्दल धन्यवाद, ते सर्वत्र बंद केले गेले नाही आणि त्वरित नाही, परंतु आवश्यकतेनुसार.
(नंतर असे आढळून आले की हॉल 8 आणि 9 मध्ये वीज बंद केलेली नव्हती.)
१५:२८. आम्ही इतर डेटा केंद्रांमध्ये बॅकअपमधून MS SQL डेटाबेस तैनात करण्यास सुरुवात करत आहोत.
किती वेळ लागेल याला? संपूर्ण मार्गासाठी पुरेशी नेटवर्क क्षमता आहे का?
15: 37 नेटवर्कच्या काही भागांचे शटडाउन रेकॉर्ड केले गेले.
व्यवस्थापन आणि उत्पादन नेटवर्क एकमेकांपासून शारीरिकदृष्ट्या वेगळे आहेत. उत्पादन नेटवर्क उपलब्ध असल्यास, आपण सर्व्हरवर जाऊ शकता, अनुप्रयोग थांबवू शकता आणि OS बंद करू शकता. ते उपलब्ध नसल्यास, तुम्ही IPMI द्वारे लॉग इन करू शकता, अनुप्रयोग थांबवू शकता आणि OS बंद करू शकता. जर तेथे कोणतेही नेटवर्क नसेल तर आपण काहीही करू शकत नाही. "धन्यवाद, कॅप!", तुम्ही विचार कराल.
"आणि सर्वसाधारणपणे, खूप गडबड आहे," तुम्ही देखील विचार करू शकता.
गोष्ट अशी आहे की सर्व्हर, आग नसतानाही, प्रचंड प्रमाणात उष्णता निर्माण करतात. अधिक तंतोतंत, जेव्हा थंड होते तेव्हा ते उष्णता निर्माण करतात आणि जेव्हा थंड होत नाही तेव्हा ते एक नरकमय नरक तयार करतात, ज्यामुळे उपकरणाचा एक भाग वितळतो आणि दुसरा भाग बंद होतो आणि सर्वात वाईट म्हणजे... हॉलच्या आत आग, जी जवळजवळ सर्व काही नष्ट करण्याची हमी आहे.

१५:३९. आम्ही conf डेटाबेसमधील समस्यांचे निराकरण करतो.

conf डेटाबेस समान नावाच्या सेवेसाठी बॅकएंड आहे, जो सर्व उत्पादन अनुप्रयोगांद्वारे सेटिंग्ज द्रुतपणे बदलण्यासाठी वापरला जातो. या बेसशिवाय, आम्ही पोर्टलच्या ऑपरेशनवर नियंत्रण ठेवू शकत नाही, परंतु पोर्टल स्वतः कार्य करू शकते.

१५:४१. कोअर नेटवर्क उपकरणावरील तापमान सेन्सर जास्तीत जास्त परवानगीयोग्य रीडिंग रेकॉर्ड करतात. हा एक बॉक्स आहे जो संपूर्ण रॅक व्यापतो आणि डेटा सेंटरमधील सर्व नेटवर्कचे ऑपरेशन सुनिश्चित करतो.

१५:४२. इश्यू ट्रॅकर आणि विकी अनुपलब्ध आहेत, स्टँडबायवर स्विच करा.
हे उत्पादन नाही, परंतु अपघात झाल्यास, कोणत्याही ज्ञानाची उपलब्धता गंभीर असू शकते.
१५:५०. एक देखरेख यंत्रणा बंद झाली आहे.
त्यापैकी अनेक आहेत आणि ते सेवांच्या विविध पैलूंसाठी जबाबदार आहेत. त्यापैकी काही प्रत्येक डेटा सेंटरमध्ये स्वायत्तपणे ऑपरेट करण्यासाठी कॉन्फिगर केले आहेत (म्हणजे, ते फक्त त्यांच्या स्वतःच्या डेटा सेंटरचे निरीक्षण करतात), इतरांमध्ये वितरित घटक असतात जे पारदर्शकपणे कोणत्याही डेटा सेंटरच्या नुकसानापासून वाचतात.
या प्रकरणात ते काम करणे थांबवले व्यवसाय तर्कशास्त्र संकेतक विसंगती शोध प्रणाली, जे मास्टर-स्टँडबाय मोडमध्ये कार्य करते. स्टँडबायवर स्विच केले.

दत्तक घेणे

१५:५१. MS SQL वगळता सर्व सर्व्हर योग्यरित्या बंद न करता IPMI द्वारे बंद केले गेले.
आवश्यक असल्यास तुम्ही IPMI द्वारे मोठ्या प्रमाणात सर्व्हर व्यवस्थापनासाठी तयार आहात का?

या टप्प्यावर डेटा सेंटरमधील उपकरणांचे बचाव पूर्ण झाल्यावर अगदी क्षण. जे काही करता येईल ते पूर्ण झाले आहे. काही सहकारी विश्रांती घेऊ शकतात.
16: 13 माहिती प्राप्त झाली आहे की एअर कंडिशनर्सचे फ्रीॉन पाईप्स छतावर फुटतात - यामुळे आग विझल्यानंतर डेटा सेंटर सुरू होण्यास विलंब होईल.
१६:१९. डेटा सेंटरच्या तांत्रिक कर्मचार्‍यांकडून मिळालेल्या माहितीनुसार, हॉलमधील तापमानात वाढ थांबली आहे.
१७:१०. conf डेटाबेस पुनर्संचयित केला गेला आहे. आता आपण ऍप्लिकेशन सेटिंग्ज बदलू शकतो.
सर्वकाही दोष-सहिष्णु असेल आणि एका डेटा सेंटरशिवाय देखील कार्य करत असेल तर हे इतके महत्त्वाचे का आहे?
प्रथम, सर्व काही दोष-सहिष्णु नसते. अशा विविध दुय्यम सेवा आहेत ज्या अद्याप डेटा सेंटरच्या अपयशातून पुरेशा प्रमाणात टिकल्या नाहीत आणि मास्टर-स्टँडबाय मोडमध्ये डेटाबेस आहेत. सेटिंग्ज व्यवस्थापित करण्याची क्षमता आपल्याला कठीण परिस्थितीतही वापरकर्त्यांवर अपघाताच्या परिणामांचा प्रभाव कमी करण्यासाठी आवश्यक ते सर्व करण्याची परवानगी देते.
दुसरे म्हणजे, हे स्पष्ट झाले की डेटा सेंटरचे ऑपरेशन येत्या काही तासांमध्ये पूर्णपणे पुनर्संचयित केले जाणार नाही, म्हणून प्रतिकृतींच्या दीर्घकालीन अनुपलब्धतेमुळे संपूर्ण डिस्क्स सारख्या अतिरिक्त समस्या उद्भवणार नाहीत याची खात्री करण्यासाठी उपाययोजना करणे आवश्यक होते. उर्वरित डेटा केंद्रे.
१७:२९. पिझ्झाची वेळ! आम्ही लोकांना काम देतो, रोबोट नाही.

पुनर्वसन

18:02. हॉल क्रमांक 8 (आमचे), 9, 10 आणि 11 मध्ये तापमान स्थिर झाले आहे. ऑफलाइन राहिलेल्यांपैकी एक (क्रमांक 7) आमच्या उपकरणे ठेवते आणि तिथले तापमान सतत वाढत असते.
१८:३१. त्यांनी हॉल क्रमांक 18 आणि 31 मध्ये उपकरणे सुरू करण्यास परवानगी दिली - या हॉलवर आगीचा परिणाम झाला नाही.

सध्‍या, हॉल क्रमांक 1, 3, 8 मध्‍ये सर्व्हर लाँच केले जात आहेत, ज्याची सुरुवात अत्यंत गंभीर आहे. सर्व चालू सेवांचे योग्य ऑपरेशन तपासले जाते. सभागृह क्रमांक 7 मध्ये अजूनही अडचणी आहेत.

१८:४४. डेटा सेंटरच्या तांत्रिक कर्मचार्‍यांनी शोधून काढले की खोली क्रमांक 18 मध्ये (जेथे फक्त आमची उपकरणे आहेत) बरेच सर्व्हर बंद नाहीत. आमच्या माहितीनुसार, तेथे 44 सर्व्हर ऑनलाइन राहतात. दुसऱ्या तपासणीनंतर, आम्हाला 7 सर्व्हर सापडतात.
20:18. डेटा सेंटर तंत्रज्ञ हॉलवेजमधून चालणाऱ्या मोबाईल डक्टमधून वातानुकूलित खोलीतून हवा फुंकतात.
२३:०८. पहिल्या अॅडमिनला घरी पाठवले. उद्या काम सुरू ठेवण्यासाठी कोणीतरी रात्री झोपणे आवश्यक आहे. पुढे, आम्ही आणखी काही प्रशासक आणि विकासक रिलीझ करू.
02:56. आम्ही लॉन्च केले जाऊ शकते ते सर्व लॉन्च केले. आम्ही स्वयंचलित चाचण्या वापरून सर्व सेवांची भरपूर तपासणी करतो.

03:02. शेवटच्या, 7 व्या हॉलमधील वातानुकूलन पूर्ववत करण्यात आले आहे.
03:36. आम्ही डेटा सेंटरमधील मोर्चे DNS मध्ये रोटेशनमध्ये आणले. या क्षणापासून वापरकर्ता रहदारी येण्यास सुरुवात होते.
आम्ही बहुतेक प्रशासकीय टीम घरी पाठवत आहोत. पण आपण काही लोकांना मागे सोडतो.

लहान FAQ:
प्रश्न: 18:31 ते 02:56 पर्यंत काय झाले?
A: “डिझास्टर ऍक्शन प्लॅन” चे अनुसरण करून, आम्ही सर्वात महत्वाच्या सेवांपासून सुरुवात करून सर्व सेवा सुरू करतो. या प्रकरणात, चॅटमधील समन्वयक विनामूल्य प्रशासकाला सेवा जारी करतो, जो OS आणि अनुप्रयोग सुरू झाला आहे की नाही, काही त्रुटी आहेत की नाही आणि निर्देशक सामान्य आहेत की नाही हे तपासतो. प्रक्षेपण पूर्ण झाल्यानंतर, तो चॅटवर अहवाल देतो की तो विनामूल्य आहे आणि त्याला समन्वयकाकडून एक नवीन सेवा मिळते.
अयशस्वी हार्डवेअरमुळे प्रक्रिया आणखी मंदावली आहे. जरी OS थांबवणे आणि सर्व्हर बंद करणे योग्यरित्या झाले असले तरीही, डिस्क, मेमरी आणि चेसिस अचानक बिघाड झाल्यामुळे काही सर्व्हर परत येत नाहीत. जेव्हा शक्ती गमावली जाते तेव्हा अपयशाचे प्रमाण वाढते.
प्रश्न: तुम्ही एकाच वेळी सर्वकाही का चालवू शकत नाही आणि नंतर निरीक्षणात काय येते ते ठीक करू शकत नाही?
उ: सर्व काही हळूहळू केले पाहिजे, कारण सेवांमध्ये अवलंबित्व आहेत. आणि मॉनिटरिंगची वाट न पाहता सर्व काही लगेच तपासले पाहिजे - कारण समस्या अधिक बिघडण्याची वाट न पाहता त्वरित त्यांना सामोरे जाणे चांगले आहे.

७:४०. शेवटचा प्रशासक (संयोजक) झोपायला गेला. पहिल्या दिवसाचे काम पूर्ण झाले आहे.
८:०९. प्रथम विकासक, डेटा सेंटर अभियंते आणि प्रशासकांनी (नवीन समन्वयकांसह) पुनर्संचयित करण्याचे काम सुरू केले.
09:37. आम्ही हॉल क्रमांक 7 (शेवटचा) वाढवायला सुरुवात केली.
त्याच वेळी, आम्ही इतर खोल्यांमध्ये जे निश्चित केले नव्हते ते पुनर्संचयित करणे सुरू ठेवतो: डिस्क/मेमरी/सर्व्हर्स बदलणे, मॉनिटरिंगमध्ये "बर्न" होणारी प्रत्येक गोष्ट निश्चित करणे, मास्टर-स्टँडबाय योजनांमध्ये भूमिका परत बदलणे आणि इतर छोट्या गोष्टी, ज्यामध्ये आहेत. तरीही खूप.
१७:०८. आम्ही उत्पादनासह सर्व नियमित कामांना परवानगी देतो.
२१:४५. दुसऱ्या दिवसाचे काम पूर्ण झाले आहे.
09:45. आज शुक्रवार आहे. निरीक्षणामध्ये अजूनही काही लहान समस्या आहेत. वीकेंड पुढे आहे, प्रत्येकाला आराम करायचा आहे. आम्ही शक्य तितक्या मोठ्या प्रमाणात दुरुस्ती करणे सुरू ठेवतो. नियमित प्रशासकीय कामे पुढे ढकलली जाऊ शकतात. संयोजक नवीन आहे.
१५:४०. दुसर्‍या डेटा सेंटरमधील कोर नेटवर्क उपकरणाचा अर्धा भाग अचानक पुन्हा सुरू झाला. जोखीम कमी करण्यासाठी मोर्चे रोटेशनमधून बाहेर काढले गेले. वापरकर्त्यांसाठी कोणताही प्रभाव नाही. नंतर हे निष्पन्न झाले की ते सदोष चेसिस होते. एकाच वेळी दोन अपघात दुरुस्त करण्याचे काम समन्वयक करत आहेत.
१७:१७. दुसर्या डेटा सेंटरमध्ये नेटवर्क ऑपरेशन पुनर्संचयित केले गेले आहे, सर्वकाही तपासले गेले आहे. डेटा सेंटर रोटेशन मध्ये ठेवले आहे.
१८:२९. तिसऱ्या दिवसाचे काम आणि सर्वसाधारणपणे, अपघातानंतर जीर्णोद्धार पूर्ण झाले आहे.

नंतरचा शब्द

04.04.2013 404 त्रुटीच्या दिवशी, "वर्गमित्र" सर्वात मोठ्या अपघातातून बचावले —तीन दिवसांसाठी पोर्टल पूर्णपणे किंवा अंशतः अनुपलब्ध होते. या संपूर्ण कालावधीत, विविध शहरांतील १०० हून अधिक लोकांनी, विविध कंपन्यांकडून (पुन्हा धन्यवाद!), दूरस्थपणे आणि थेट डेटा सेंटरमध्ये, मॅन्युअली आणि स्वयंचलितपणे, हजारो सर्व्हर दुरुस्त केले.
आम्ही निष्कर्ष काढले आहेत. हे पुन्हा घडू नये म्हणून आम्ही आजपर्यंत व्यापक काम केले आहे आणि करत आहोत.

वर्तमान अपघात आणि 404 मधील मुख्य फरक काय आहेत?

• आमच्याकडे "अपघात कृती योजना" आहे. एक चतुर्थांश एकदा, आम्ही व्यायाम आयोजित करतो - आम्ही आपत्कालीन परिस्थितीची भूमिका बजावतो, जी प्रशासकांच्या गटाने (सर्व बदलून) "आपत्कालीन कृती योजना" वापरून दूर करणे आवश्यक आहे. अग्रगण्य प्रणाली प्रशासक समन्वयकाची भूमिका बजावतात.
• त्रैमासिक, चाचणी मोडमध्ये, आम्ही LAN आणि WAN नेटवर्कद्वारे डेटा केंद्रे (सर्व बदलून) वेगळे करतो, ज्यामुळे आम्हाला अडथळे त्वरित ओळखता येतात.
• कमी तुटलेल्या डिस्क्स, कारण आम्ही मानके कडक केली आहेत: कमी ऑपरेटिंग तास, SMART साठी कठोर थ्रेशोल्ड,
• आम्ही बर्कलेडीबी पूर्णपणे सोडून दिले, एक जुना आणि अस्थिर डेटाबेस ज्याला सर्व्हर रीस्टार्ट झाल्यानंतर पुनर्प्राप्त करण्यासाठी बराच वेळ लागतो.
• आम्ही MS SQL सह सर्व्हरची संख्या कमी केली आणि उर्वरित लोकांवरील अवलंबित्व कमी केले.
• आमचे स्वतःचे आहे ढग - एक ढग, जिथे आम्ही दोन वर्षांपासून सक्रियपणे सर्व सेवा स्थलांतरित करत आहोत. क्लाउड अनुप्रयोगासह कार्य करण्याचे संपूर्ण चक्र मोठ्या प्रमाणात सुलभ करते आणि अपघात झाल्यास ते अशी अद्वितीय साधने प्रदान करते:
  • एका क्लिकवर सर्व अनुप्रयोगांचा योग्य थांबा;
  • अयशस्वी सर्व्हरवरून अनुप्रयोगांचे सहज स्थलांतर;
  • स्वयंचलित रँक (सेवांच्या प्राधान्यक्रमानुसार) संपूर्ण डेटा सेंटर लाँच.

या लेखात वर्णन केलेला अपघात 404 व्या दिवसानंतरचा सर्वात मोठा होता. अर्थात, सर्व काही सुरळीत झाले नाही. उदाहरणार्थ, दुसर्‍या डेटा सेंटरमध्ये आगीमुळे नुकसान झालेल्या डेटा सेंटरच्या अनुपलब्धतेदरम्यान, एका सर्व्हरवरील डिस्क अयशस्वी झाली, म्हणजेच कॅसॅंड्रा क्लस्टरमधील तीन प्रतिकृतींपैकी फक्त एक प्रवेशयोग्य राहिली, म्हणूनच 4,2% मोबाइल अनुप्रयोग वापरकर्ते लॉग इन करू शकले नाहीत. त्याच वेळी, आधीच कनेक्ट केलेले वापरकर्ते कार्य करत राहिले. एकूणच, अपघाताच्या परिणामी, 30 हून अधिक समस्या ओळखल्या गेल्या - बॅनल बग्सपासून ते सर्व्हिस आर्किटेक्चरमधील कमतरतांपर्यंत.

परंतु सध्याचा अपघात आणि 404 वी यातील सर्वात महत्त्वाचा फरक हा आहे की आम्ही आगीचे परिणाम दूर करत असताना, वापरकर्ते अजूनही मजकूर पाठवत होते आणि व्हिडिओ कॉल करत होते टमटम, गेम खेळले, संगीत ऐकले, एकमेकांना भेटवस्तू दिल्या, व्हिडिओ पाहिले, टीव्ही मालिका आणि टीव्ही चॅनेल ओके, आणि मध्ये प्रवाहित देखील ओके लाइव्ह.

तुमचे अपघात कसे होतात?

स्त्रोत: www.habr.com