უნდა ჩაქრეს თუ არა სერვერები, თუ მონაცემთა ცენტრის კვამლის ტესტს ცეცხლი გაუჩნდა?

როგორ იგრძნობთ თავს, თუ ზაფხულის ერთ მშვენიერ დღეს მონაცემთა ცენტრი თქვენი აღჭურვილობით ასე გამოიყურებოდა?

Სალამი ყველას! მე მქვია დიმიტრი სამსონოვი, ვმუშაობ სისტემის წამყვან ადმინისტრატორად "კლასელები" ფოტოზე ნაჩვენებია ოთხი მონაცემთა ცენტრიდან ერთ-ერთი, სადაც დამონტაჟებულია მოწყობილობა, რომელიც ემსახურება ჩვენს პროექტს. ამ კედლების უკან დაახლოებით 4 ათასი ცალი აღჭურვილობაა: სერვერები, მონაცემთა შენახვის სისტემები, ქსელური აღჭურვილობა და ა.შ. - ჩვენი აღჭურვილობის თითქმის ⅓.
სერვერების უმეტესობა არის Linux. ასევე არის რამდენიმე ათეული სერვერი Windows-ზე (MS SQL) - ჩვენი მემკვიდრეობა, რომელსაც მრავალი წელია სისტემატურად ვტოვებთ.
ასე რომ, 5 წლის 2019 ივნისს, 14:35 საათზე, ჩვენი ერთ-ერთი მონაცემთა ცენტრის ინჟინრებმა განაცხადეს ხანძრის განგაში.

უარი

14:45. კვამლის მცირე ინციდენტები მონაცემთა ცენტრებში უფრო ხშირია, ვიდრე ფიქრობთ. დარბაზების შიგნით ინდიკატორები ნორმალური იყო, ამიტომ ჩვენი პირველი რეაქცია შედარებით მშვიდი იყო: მათ შემოიღეს აკრძალვა წარმოებასთან მუშაობისთვის, ანუ ნებისმიერი კონფიგურაციის ცვლილებაზე, ახალი ვერსიების გამოშვებაზე და ა.შ.

Anger

ოდესმე გიცდიათ მეხანძრეებისგან გაერკვია ზუსტად სად გაჩნდა ხანძარი სახურავზე, ან თავად შეხვედით ცეცხლმოკიდებულ სახურავზე სიტუაციის შესაფასებლად? როგორი იქნება ხუთი ადამიანის მიერ მიღებული ინფორმაციისადმი ნდობის ხარისხი?

14: 50. მიღებულია ინფორმაცია, რომ ცეცხლი გაგრილების სისტემას უახლოვდება. მაგრამ მოვა? მორიგე სისტემის ადმინისტრატორი აშორებს გარე ტრაფიკს ამ მონაცემთა ცენტრის წინა მხარეს.

ამ დროისთვის, ჩვენი ყველა სერვისის ფრონტი დუბლირებულია სამ მონაცემთა ცენტრში, დაბალანსება გამოიყენება DNS დონეზე, რაც საშუალებას გვაძლევს ამოიღოთ ერთი მონაცემთა ცენტრის მისამართები DNS-დან, რითაც დავიცვათ მომხმარებლები სერვისებზე წვდომის პოტენციური პრობლემებისგან. . თუ პრობლემები უკვე მოხდა მონაცემთა ცენტრში, ის ავტომატურად ტოვებს ბრუნვას. მეტი შეგიძლიათ წაიკითხოთ აქ: დატვირთვის დაბალანსება და ხარვეზების ტოლერანტობა ოდნოკლასნიკში.

ხანძარი ჩვენთვის ჯერ არანაირად არ შეხებია - არც მომხმარებლები და არც ტექნიკა დაზიანებულა. ეს უბედური შემთხვევაა? დოკუმენტის პირველი ნაწილი „ავარიის სამოქმედო გეგმა“ განსაზღვრავს „ავარიის“ ცნებას და სექცია ასე მთავრდება:
«თუ არსებობს ეჭვი, არის თუ არა უბედური შემთხვევა, მაშინ ეს უბედური შემთხვევაა!»

14:53. ინიშნება საგანგებო სიტუაციების კოორდინატორი.

კოორდინატორი არის ადამიანი, რომელიც აკონტროლებს კომუნიკაციას ყველა მონაწილეს შორის, აფასებს ავარიის მასშტაბებს, იყენებს საგანგებო სამოქმედო გეგმას, იზიდავს საჭირო პერსონალს, აკონტროლებს რემონტის დასრულებას და რაც მთავარია, დელეგირებს ნებისმიერ დავალებას. სხვა სიტყვებით რომ ვთქვათ, ეს არის ადამიანი, რომელიც მართავს საგანგებო სიტუაციებზე რეაგირების მთელ პროცესს.

გარიგება

15:01. ჩვენ ვიწყებთ სერვერების გამორთვას, რომლებიც არ არის დაკავშირებული წარმოებასთან.
15:03. ჩვენ სწორად გამორთეთ ყველა დაჯავშნილი სერვისი.
ეს მოიცავს არა მხოლოდ ფრონტებს (რომელზეც ამ დროისთვის მომხმარებლები აღარ წვდებიან) და მათ დამხმარე სერვისებს (ბიზნესის ლოგიკა, ქეშები და ა.შ.), არამედ სხვადასხვა მონაცემთა ბაზებს რეპლიკაციის ფაქტორით 2 ან მეტი (Cassandra, ორობითი მონაცემთა შენახვა, ცივი საწყობი, NewSQL და ა.შ.).
15: 06. მიღებულია ინფორმაცია, რომ ხანძარი ემუქრება მონაცემთა ცენტრის ერთ-ერთ დარბაზს. ჩვენ არ გვაქვს ამ ოთახში აღჭურვილობა, მაგრამ ის ფაქტი, რომ ცეცხლი შეიძლება გადავიდეს სახურავიდან დარბაზებში, მნიშვნელოვნად ცვლის სურათს იმის შესახებ, რაც ხდება.
(მოგვიანებით გაირკვა, რომ დარბაზს ფიზიკური საფრთხე არ ემუქრებოდა, ვინაიდან იგი სახურავიდან ჰერმეტულად იყო დალუქული. საფრთხე მხოლოდ ამ დარბაზის გაგრილების სისტემას ეხებოდა.)
15:07. ჩვენ დავუშვებთ ბრძანების შესრულებას სერვერებზე დაჩქარებულ რეჟიმში დამატებითი შემოწმების გარეშე (ჩვენი საყვარელი კალკულატორის გარეშე).
15:08. დარბაზებში ტემპერატურა ნორმალურ ფარგლებშია.
15: 12. დარბაზებში ტემპერატურის მატება დაფიქსირდა.
15:13. მონაცემთა ცენტრში სერვერების ნახევარზე მეტი გამორთულია. Გავაგრძელოთ.
15:16. მიღებულ იქნა გადაწყვეტილება ყველა აღჭურვილობის გამორთვის შესახებ.
15:21. ჩვენ ვიწყებთ გამორთვას მოქალაქეობის არმქონე სერვერებზე აპლიკაციისა და ოპერაციული სისტემის სწორად გამორთვის გარეშე.
15:23. გამოყოფილია MS SQL-ზე პასუხისმგებელი ადამიანების ჯგუფი (მათგან ცოტაა, მათზე სერვისების დამოკიდებულება არ არის დიდი, მაგრამ ფუნქციონირების აღდგენის პროცედურა უფრო მეტხანს გრძელდება და უფრო რთულია, ვიდრე, მაგალითად, კასანდრა).

დეპრესია

15: 25. მიიღეს ინფორმაცია 16-დან ოთხ დარბაზში (No6, 7, 8, 9) გათიშვის შესახებ. ჩვენი აღჭურვილობა განთავსებულია მე-7 და მე-8 დარბაზებში. ჩვენი ორი დარბაზის (No1 და 3) შესახებ ინფორმაცია არ არის.
ჩვეულებრივ, ხანძრის დროს, ელექტრომომარაგება დაუყოვნებლივ ითიშება, მაგრამ ამ შემთხვევაში, მეხანძრე-მაშველების და მონაცემთა ცენტრის ტექნიკური პერსონალის კოორდინირებული მუშაობის წყალობით, ყველგან და არა დაუყოვნებლივ, არამედ საჭიროებისამებრ გამორთული იყო.
(მოგვიანებით გაირკვა, რომ მე-8 და მე-9 დარბაზებში დენი არ იყო გამორთული.)
15:28. ჩვენ ვიწყებთ MS SQL მონაცემთა ბაზების განთავსებას სარეზერვო ასლებიდან სხვა მონაცემთა ცენტრებში.
Რამდენი ხანი დასჭირდება? არის თუ არა საკმარისი ქსელის სიმძლავრე მთელი მარშრუტისთვის?
15: 37. დაფიქსირდა ქსელის ზოგიერთი ნაწილის გათიშვა.
მენეჯმენტი და საწარმოო ქსელი ფიზიკურად იზოლირებულია ერთმანეთისგან. თუ საწარმოო ქსელი ხელმისაწვდომია, მაშინ შეგიძლიათ გადახვიდეთ სერვერზე, შეაჩეროთ აპლიკაცია და გამორთოთ OS. თუ ის არ არის ხელმისაწვდომი, მაშინ შეგიძლიათ შეხვიდეთ IPMI-ით, შეაჩეროთ აპლიკაცია და გამორთოთ OS. თუ არცერთი ქსელი არ არის, მაშინ ვერაფერს გააკეთებთ. "გმადლობთ, კაპ!", თქვენ ფიქრობთ.
„და ზოგადად, ბევრი არეულობაა“, შეიძლება ასევე იფიქროთ.
საქმე იმაშია, რომ სერვერები ხანძრის გარეშეც კი წარმოქმნიან უზარმაზარ რაოდენობას სითბოს. უფრო ზუსტად, როცა გაგრილებაა, წარმოქმნიან სითბოს, ხოლო როცა არ არის გაგრილება, ქმნიან ჯოჯოხეთურ ჯოჯოხეთს, რომელიც საუკეთესო შემთხვევაში დნება დანადგარის ნაწილს და სხვა ნაწილს გამორთავს, უარეს შემთხვევაში კი... შიგ ცეცხლს გამოიწვევს. დარბაზი, რომელიც თითქმის გარანტირებულად ანადგურებს ყველაფერს.

15:39. ჩვენ ვასწორებთ პრობლემებს conf მონაცემთა ბაზასთან.

conf მონაცემთა ბაზა არის ამავე სახელწოდების სერვისის უკანა ნაწილი, რომელსაც ყველა საწარმოო აპლიკაცია იყენებს პარამეტრების სწრაფად შესაცვლელად. ამ ბაზის გარეშე ჩვენ ვერ ვაკონტროლებთ პორტალის მუშაობას, მაგრამ თავად პორტალს შეუძლია იმუშაოს.

15:41. ტემპერატურული სენსორები Core ქსელის მოწყობილობებზე აღრიცხავენ კითხვებს მაქსიმალურ დასაშვებთან ახლოს. ეს არის ყუთი, რომელიც იკავებს მთელ თაროს და უზრუნველყოფს მონაცემთა ცენტრის შიგნით ყველა ქსელის მუშაობას.

15:42. პრობლემების ტრეკერი და ვიკი მიუწვდომელია, გადადით ლოდინის რეჟიმში.
ეს არ არის წარმოება, მაგრამ ავარიის შემთხვევაში, ნებისმიერი ცოდნის ბაზის ხელმისაწვდომობა შეიძლება იყოს კრიტიკული.
15:50. მონიტორინგის ერთ-ერთი სისტემა გამორთულია.
რამდენიმე მათგანია და ისინი პასუხისმგებელნი არიან მომსახურების სხვადასხვა ასპექტზე. ზოგიერთი მათგანი კონფიგურირებულია დამოუკიდებლად მუშაობისთვის თითოეულ მონაცემთა ცენტრში (ანუ ისინი აკონტროლებენ მხოლოდ საკუთარ მონაცემთა ცენტრს), ზოგი შედგება განაწილებული კომპონენტებისგან, რომლებიც გამჭვირვალედ გადარჩებიან ნებისმიერი მონაცემთა ცენტრის დაკარგვას.
ამ შემთხვევაში მან შეწყვიტა მუშაობა ბიზნეს ლოგიკის ინდიკატორების ანომალიების გამოვლენის სისტემა, რომელიც მუშაობს სამაგისტრო ლოდინის რეჟიმში. გადართულია ლოდინის რეჟიმში.

მიღება

15:51. ყველა სერვერი, გარდა MS SQL-ისა, გამორთული იყო IPMI-ის მეშვეობით სწორად გამორთვის გარეშე.
მზად ხართ სერვერის მასიური მართვისთვის IPMI-ის საშუალებით საჭიროების შემთხვევაში?

სწორედ იმ მომენტში, როდესაც ამ ეტაპზე დასრულდა მონაცემთა ცენტრში აღჭურვილობის გადარჩენა. ყველაფერი, რისი გაკეთებაც შეიძლებოდა, გაკეთდა. ზოგიერთ კოლეგას შეუძლია დაისვენოს.
16: 13. მიღებულია ინფორმაცია, რომ კონდიციონერებიდან ფრეონის მილები იფეთქება სახურავზე - ეს შეაფერხებს მონაცემთა ცენტრის გაშვებას ხანძრის ლიკვიდაციის შემდეგ.
16:19. დატა ცენტრის ტექნიკური პერსონალიდან მიღებული მონაცემებით, დარბაზებში ტემპერატურის მატება შეჩერებულია.
17:10. conf მონაცემთა ბაზა აღდგენილია. ახლა ჩვენ შეგვიძლია შევცვალოთ აპლიკაციის პარამეტრები.
რატომ არის ეს ასე მნიშვნელოვანი, თუ ყველაფერი ხარვეზების ტოლერანტულია და მუშაობს თუნდაც ერთი მონაცემთა ცენტრის გარეშე?
ჯერ ერთი, ყველაფერი არ არის შეცდომის ტოლერანტული. არსებობს სხვადასხვა მეორადი სერვისები, რომლებსაც ჯერ არ გადაურჩა მონაცემთა ცენტრის უკმარისობა საკმარისად კარგად და არის მონაცემთა ბაზები სამაგისტრო ლოდინის რეჟიმში. პარამეტრების მართვის შესაძლებლობა საშუალებას გაძლევთ გააკეთოთ ყველაფერი, რათა მინიმუმამდე დაიყვანოთ უბედური შემთხვევის შედეგები მომხმარებლებზე, თუნდაც რთულ პირობებში.
მეორეც, გაირკვა, რომ მონაცემთა ცენტრის ფუნქციონირება სრულად არ აღდგება უახლოეს საათებში, ამიტომ საჭირო იყო ზომების მიღება იმის უზრუნველსაყოფად, რომ ასლების გრძელვადიანი მიუწვდომლობა არ გამოეწვია დამატებით პრობლემებს, როგორიცაა სრული დისკები. დარჩენილი მონაცემთა ცენტრები.
17:29. პიცის დრო! ჩვენ ვასაქმებთ ადამიანებს და არა რობოტებს.

რეაბილიტაცია

18:02. მე-8 (ჩვენი), 9, 10 და 11 დარბაზებში ტემპერატურა დასტაბილურდა. ერთ-ერთში, რომელიც რჩება ოფლაინში (No. 7) არის ჩვენი აღჭურვილობა და იქ ტემპერატურა აგრძელებს მატებას.
18:31. მათ 1-ლი და მე-3 დარბაზებში აღჭურვილობის ამოქმედების ნებართვა მისცეს - ეს დარბაზები ხანძრის შედეგად არ დაზარალდა.

ამჟამად სერვერების გაშვება მიმდინარეობს No1, 3, 8 დარბაზებში, დაწყებული ყველაზე კრიტიკულით. შემოწმებულია ყველა გაშვებული სერვისის სწორი მოქმედება. მე-7 დარბაზთან დაკავშირებით კვლავ პრობლემებია.

18:44. დატა ცენტრის ტექნიკურმა პერსონალმა აღმოაჩინა, რომ მე-7 ოთახში (სადაც მხოლოდ ჩვენი აღჭურვილობაა განთავსებული) ბევრი სერვერი არ არის გამორთული. ჩვენი მონაცემებით, იქ 26 სერვერი რჩება ონლაინ რეჟიმში. მეორე შემოწმების შემდეგ, ჩვენ ვპოულობთ 58 სერვერს.
20:18. მონაცემთა ცენტრის ტექნიკოსები ჰაერს უბერავენ უკონდიცირებულ ოთახში, დერეფნებში გამავალი მობილური არხებით.
23:08. პირველი ადმინი სახლში გაგზავნეს. ვიღაცამ უნდა დაიძინოს ღამით, რომ ხვალ განაგრძოს მუშაობა. შემდეგი, ჩვენ გავათავისუფლებთ კიდევ რამდენიმე ადმინს და დეველოპერს.
02:56. ჩვენ გავუშვით ყველაფერი, რისი გაშვებაც შეიძლებოდა. ჩვენ ვამოწმებთ ყველა სერვისს ავტომატური ტესტების გამოყენებით.

03:02. ბოლო, მე-7 დარბაზში კონდიციონერი აღდგენილია.
03:36. ჩვენ შევიტანეთ ფრონტები მონაცემთა ცენტრში როტაციაში DNS-ში. ამ მომენტიდან მომხმარებლის ტრაფიკი იწყება.
ჩვენ ვაგზავნით ადმინისტრაციული გუნდის უმეტესობას სახლში. მაგრამ ჩვენ დავტოვებთ რამდენიმე ადამიანს.

მცირე ხშირად დასმული კითხვები:
კითხვა: რა მოხდა 18:31-დან 02:56-მდე?
პასუხი: „სტიქიის დროს სამოქმედო გეგმის“ მიხედვით, ჩვენ ვიწყებთ ყველა სერვისს, დაწყებული ყველაზე მნიშვნელოვანით. ამ შემთხვევაში, ჩატში კოორდინატორი გასცემს სერვისს უფასო ადმინისტრატორს, რომელიც ამოწმებს დაიწყო თუ არა OS და აპლიკაცია, არის თუ არა შეცდომები და არის თუ არა ინდიკატორები ნორმალური. გაშვების დასრულების შემდეგ ის ჩატში ატყობინებს, რომ თავისუფალია და იღებს ახალ სერვისს კოორდინატორისგან.
პროცესი კიდევ უფრო ანელებს წარუმატებელი აპარატურის გამო. მაშინაც კი, თუ OS-ის შეჩერება და სერვერების გამორთვა მოხდა სწორად, ზოგიერთი სერვერი არ ბრუნდება დისკების, მეხსიერების და შასის უეცარი გაუმართაობის გამო. როდესაც ელექტროენერგია იკარგება, უკმარისობის მაჩვენებელი იზრდება.
კითხვა: რატომ არ შეგიძლიათ ერთდროულად აწარმოოთ ყველაფერი და შემდეგ გამოასწოროთ ის, რაც გამოდის მონიტორინგში?
_ ყველაფერი ეტაპობრივად უნდა მოხდეს, რადგან სამსახურებს შორის არის დამოკიდებულებები. და ყველაფერი უნდა შემოწმდეს დაუყოვნებლივ, მონიტორინგის მოლოდინის გარეშე - რადგან უმჯობესია პრობლემების მოგვარება დაუყოვნებლივ, მათი გაუარესების მოლოდინის გარეშე.

7:40. ბოლო ადმინი (კოორდინატორი) დასაძინებლად წავიდა. პირველი დღის სამუშაოები დასრულდა.
8:09. პირველმა დეველოპერებმა, მონაცემთა ცენტრის ინჟინრებმა და ადმინისტრატორებმა (ახალი კოორდინატორის ჩათვლით) დაიწყეს აღდგენითი სამუშაოები.
09:37. დავიწყეთ მე-7 დარბაზის ამაღლება (ბოლო).
ამავდროულად, ჩვენ ვაგრძელებთ აღდგენას, რაც არ იყო დაფიქსირებული სხვა ოთახებში: დისკების/მეხსიერების/სერვერების გამოცვლა, ყველაფრის დაფიქსირება, რაც „იწვის“ მონიტორინგში, როლების გადართვა სამაგისტრო ლოდინის სქემებში და სხვა წვრილმანები, რომელთაგან არის თუმცა საკმაოდ ბევრი.
17:08. ჩვენ ვუშვებთ ყველა რეგულარულ მუშაობას წარმოებასთან.
21:45. მეორე დღის სამუშაო დასრულებულია.
09:45. Დღეს პარასკევია. ჯერ კიდევ არის საკმაოდ მცირე პრობლემები მონიტორინგში. შაბათ-კვირა წინ არის, ყველას დასვენება უნდა. ჩვენ ვაგრძელებთ ყველაფრის მასიურ შეკეთებას, რაც შეგვიძლია. ადმინისტრატორის რეგულარული დავალებები, რომლებიც შეიძლებოდა გადაიდო, გადაიდო. კოორდინატორი ახალია.
15:40. უეცრად ძირითადი ქსელის აღჭურვილობის ნახევარი სხვა მონაცემთა ცენტრში გადაიტვირთა. რისკების შესამცირებლად ფრონტები ამოღებულ იქნა როტაციიდან. მომხმარებლებისთვის არანაირი ეფექტი არ არის. მოგვიანებით გაირკვა, რომ ეს იყო გაუმართავი შასი. კოორდინატორი მუშაობს ერთდროულად ორი ავარიის გამოსწორებაზე.
17:17. ქსელის მუშაობა სხვა მონაცემთა ცენტრში აღდგენილია, ყველაფერი შემოწმდა. მონაცემთა ცენტრი გადადის როტაციაში.
18:29. მესამე დღის სამუშაოები და ზოგადად, ავარიის შემდეგ რესტავრაცია დასრულდა.

Afterword

04.04.2013 წ 404 შეცდომის დღეს, "კლასელები" ყველაზე დიდ ავარიას გადაურჩა — სამი დღის განმავლობაში პორტალი მთლიანად ან ნაწილობრივ მიუწვდომელი იყო. მთელი ამ დროის განმავლობაში, 100-ზე მეტმა ადამიანმა სხვადასხვა ქალაქიდან, სხვადასხვა კომპანიისგან (დიდი მადლობა კიდევ ერთხელ!), დისტანციურად და პირდაპირ მონაცემთა ცენტრებში, ხელით და ავტომატურად, შეაკეთეს ათასობით სერვერი.
ჩვენ გამოვიტანეთ დასკვნები. რომ ეს აღარ განმეორდეს, ჩვენ ჩავატარეთ და ვაგრძელებთ ვრცელ სამუშაოებს დღემდე.

რა არის ძირითადი განსხვავებები მიმდინარე ავარიასა და 404-ს შორის?

• ჩვენ გვაქვს "ავარიის სამოქმედო გეგმა". კვარტალში ერთხელ ვატარებთ სავარჯიშოებს - როლურად ვთამაშობთ საგანგებო სიტუაციას, რომელიც ადმინისტრატორთა ჯგუფმა (ყველა თავის მხრივ) უნდა აღმოფხვრას "გადაუდებელი სამოქმედო გეგმის" გამოყენებით. სისტემის წამყვანი ადმინისტრატორები რიგრიგობით თამაშობენ კოორდინატორის როლს.
• ყოველკვარტალურად, სატესტო რეჟიმში, ჩვენ ვიზოლირებთ მონაცემთა ცენტრებს (ყველა თავის მხრივ) LAN და WAN ქსელების საშუალებით, რაც საშუალებას გვაძლევს დროულად გამოვავლინოთ შეფერხებები.
• ნაკლები გატეხილი დისკი, რადგან ჩვენ გავამკაცრეთ სტანდარტები: ნაკლები სამუშაო საათი, უფრო მკაცრი ბარიერი SMART-ისთვის,
• ჩვენ მთლიანად მივატოვეთ BerkeleyDB, ძველი და არასტაბილური მონაცემთა ბაზა, რომლის აღდგენასაც დიდი დრო დასჭირდა სერვერის გადატვირთვის შემდეგ.
• ჩვენ შევამცირეთ MS SQL სერვერების რაოდენობა და შევამცირეთ დამოკიდებულება დანარჩენებზე.
• ჩვენ გვაქვს საკუთარი ღრუბელი - ერთ ღრუბელი, სადაც უკვე ორი წელია აქტიურად ვახორციელებთ ყველა სერვისის მიგრაციას. ღრუბელი მნიშვნელოვნად ამარტივებს აპლიკაციასთან მუშაობის მთელ ციკლს და ავარიის შემთხვევაში ის უზრუნველყოფს ისეთ უნიკალურ ინსტრუმენტებს, როგორიცაა:
  • ყველა აპლიკაციის სწორი გაჩერება ერთი დაწკაპუნებით;
  • აპლიკაციების მარტივი მიგრაცია წარუმატებელი სერვერებიდან;
  • მთელი მონაცემთა ცენტრის ავტომატური რანჟირებული (მომსახურების პრიორიტეტის მიხედვით) გაშვება.

ამ სტატიაში აღწერილი უბედური შემთხვევა ყველაზე დიდი იყო 404-ე დღის შემდეგ. რა თქმა უნდა, ყველაფერი შეუფერხებლად არ წარიმართა. მაგალითად, სხვა მონაცემთა ცენტრში ხანძრის მსხვერპლის მონაცემთა ცენტრის მიუწვდომლობის დროს, ერთ-ერთ სერვერზე დისკი ვერ მოხერხდა, ანუ კასანდრას კლასტერში სამი ასლიდან მხოლოდ ერთი დარჩა ხელმისაწვდომი, რის გამოც მობილური აპლიკაციის 4,2%. მომხმარებელმა ვერ შეძლო შესვლა. ამავდროულად, უკვე დაკავშირებული მომხმარებლები განაგრძობდნენ მუშაობას. საერთო ჯამში, ავარიის შედეგად გამოვლინდა 30-ზე მეტი პრობლემა - ბანალური შეცდომებიდან დაწყებული სერვისის არქიტექტურის ხარვეზებამდე.

მაგრამ ყველაზე მნიშვნელოვანი განსხვავება ამჟამინდელ ავარიასა და 404-ს შორის არის ის, რომ სანამ ხანძრის შედეგების აღმოფხვრას ვაწარმოებდით, მომხმარებლები კვლავ აწერდნენ ტექსტს და აკეთებდნენ ვიდეო ზარებს. თამთამიითამაშეს, უსმენდნენ მუსიკას, აჩუქეს ერთმანეთს საჩუქრები, უყურეთ ვიდეოებს, სერიალებს და ტელეარხებს OK, და ასევე შემოვიდა კარგი.

როგორ მიდის თქვენი ავარიები?

წყარო: www.habr.com