ინჟინერმა GitLab-ის საწარმოო მონაცემთა ბაზა წაშალა. 300 გიგაბაიტი.

რას მოიცავს ეს ვიდეო

• 2017 წლის 31 იანვარი: rm -Rvf მთავარი სერვერის მონაცემთა დირექტორიაზე; ~300 GB წაიშალა, 4.5 GB დარჩა
• 5-დან 5 სარეზერვო ასლი მარცხდება: ცარიელი S3 bucket (pg_dump ვერსიის შეუსაბამობა), მონაცემთა ბაზაზე Azure-ის სნეპშოტები არ არის, წაშლილი რეპლიკა, ყოველდღიური LVM ასლი ვებჰუკების გარეშე
• 1 თებერვალი, 18:00 UTC: GitLab.com დაუბრუნდა 6-საათიან, ხელით გაკეთებულ სნეპშოტს; ცოცხალი დოკუმენტი, პირდაპირი ტრანსლაცია, უდანაშაულო შემდგომი ანალიზი გამოსწორების სიით

ნათარგმნი ტრანსკრიპტი

ნათარგმნია ორიგინალური ინგლისური ნარატივიდან. ხელმისაწვდომი აუდიო და სუბტიტრები კონტროლდება YouTube-ის მიერ.

0:00 GitLab-ის ინჟინერი არასწორ მონაცემთა ბაზის სერვერზე აწარმოებს rm -rf-ს, და სამასი გიგაბაიტი GitLab dot com ქრება წამში ან ორში, დაახლოებით ის დრო, რაც ჰოსტნეიმის წასაკითხად არის საჭირო. 2017 წლის 31 იანვარი, საღამოს 11:27. UTC. GitLab ტვიტავს, რომ შემთხვევით წაშალა საწარმოო მონაცემები, ინციდენტის ჩანაწერებს ინტერნეტს უხსნის და აღდგენას YouTube-ზე გადასცემს, პლატფორმაზე მეორე ყველაზე ყურებადი ლაივ სტრიმია. მეორე დღეს, წერილობით: ხუთი სარეზერვო ტექნიკიდან,

0:25 არცერთი საიმედოდ არ მუშაობს. როგორ ხდება, რატომ არის შესაძლებელი და ვის ეკისრება რეალურად ბრალი. ეს არის The Daily Diff, შემდგომი ანალიზი. საღამოს 5:20: ინჟინერი აკეთებს საწარმოო სნეპშოტს დატვირთვის ბალანსერის შესამოწმებლად განვითარების გარემოში. საღამოს 7:00: სპამი აწვება მონაცემთა ბაზას, პლუს სამუშაო, რომელიც უხეშად შლის GitLab-ის თანამშრომელს, რომელიც ტროლმა ძალადობისთვის დააფიქსირა. საღამოს 11:00: რეპლიკა ისე ჩამორჩა, რომ მთავარმა სერვერმა უკვე წაშალა

0:48 მისთვის საჭირო ჟურნალი; ერთადერთი გამოსავალია რეპლიკის წაშლა და მთავარი სერვერის ხელახლა კოპირება. pg_basebackup გაიჭედა გამოსავლის გარეშე. ის რეალურად ჩუმად ელოდება მთავარ სერვერს; არავინ იცის ეს, და runbook არ ამბობს. ინჟინერი, რომელსაც თერთმეტზე უნდა მოეწერა ხელი, გადაწყვეტს, რომ ცარიელი მონაცემთა დირექტორია პრობლემაა და შლის მას. db1-ზე. მთავარ სერვერზე. ის წამში ან ორში ამჩნევს; დაახლოებით სამასი გიგაბაიტიდან,

1:11 4.5 რჩება. სარეზერვო ასლები. ერთი: pg_dump S3-ზე, ყოველდღიურად. bucket ცარიელია. cron-ის დავალება მუშაობს აპლიკაციის სერვერზე მონაცემთა ბაზის გარეშე, ამიტომ პაკეტი ირჩევს PostgreSQL 9.2 ორობით ფაილებს 9.6 მონაცემთა ბაზისთვის, მარცხდება და აგზავნის ელ.ფოსტებს მარცხის შესახებ, რომელიც DMARC-ის ნაკლებობის გამო უკუაგდებს. ორი: Azure-ის დისკის სნეპშოტები, ჩართულია ფაილურ სერვერებისთვის, არა მონაცემთა ბაზებისთვის.

1:32 სამი: რეპლიკა, მიზანმიმართულად წაშლილი ერთი საათის წინ. ოთხი: ყოველდღიური სნეპშოტი, 24 საათის წინანდელი, ყოველი ვებჰუკი ამოღებულია განვითარების გარემოს სინქრონიზაციით. ხუთი: ხელით გაკეთებული სნეპშოტი 5:20-დან, დაუკავშირებელი ტესტისთვის. ეს იმარჯვებს. აღდგენა ნიშნავს განვითარების გარემოს დისკის უკან საწარმოო გარემოში კოპირებას Azure-ის იაფი საცავით სამოცი მეგაბიტი წამში: თვრამეტი საათი. GitLab dot com ბრუნდება 1 თებერვალს საღამოს ექვს საათზე UTC, ექვსი საათით ძველი მონაცემებით.

1:58 git blame: ორი ჰოსტნეიმი ერთ სიმბოლოში განსხვავდება, და ხუთი სარეზერვო სისტემა, რომელთაგან არავის არასოდეს აღუდგენია. არა ინჟინერი. შემდგომი ანალიზი, CEO-ს მიერ ხელმოწერილი, მას ანონიმურად ტოვებს, საწარმოო გარემოს მოთხოვნას წითლად აფერადებს და მონაცემთა გამძლეობას მფლობელს აძლევს, რადგან აქამდე მას არ ჰყავდა. დაზიანების რადიუსი: თვრამეტი საათი გათიშული, ექვსი საათის მონაცემები დაკარგული, დაახლოებით ხუთი ათასი პროექტი, ხუთი ათასი კომენტარი,

2:18 შვიდასი ახალი მომხმარებელი და ხუთი ათასი ადამიანი უყურებს პროგრესის ზოლს. Hacker News-მა ცოცხალ დოკუმენტს 1,162 ქულა მიანიჭა და ერთი სტრიქონი მოჰყავს უკან: ხუთი სარეზერვო ასლიდან, არცერთი. ვერდიქტი, შემდგომი ანალიზი: SHIP IT, რეაგირებაზე. ისინი ინციდენტს საჯაროდ ატარებენ, ბრალს პროცესს სდებენ და გამოსწორების სიას საკითხის ნომრებით აქვეყნებენ. ორშაბათის მოქმედება: სარეზერვო ასლის აღდგენა. თუ არასოდეს აღგიდგენიათ, არ გაქვთ.

2:42 გამომიგზავნეთ ინციდენტი, რომელზეც ჯერ კიდევ არ გაქვთ საუბრის უფლება, კომენტარებში, ან daily diff dot dev-ზე. და ეს არის დღევანდელი diff. მე ვარ ნიკო Axrisi-დან. პასუხისმგებლობით გააერთიანეთ.

წყაროები

1. GitLab, "Postmortem of database outage of January 31" (Feb 10, 2017)about.gitlab.com
2. GitLab, "GitLab.com database incident" (Feb 1, 2017)about.gitlab.com
3. @gitlabstatus, "We accidentally deleted production data…"twitter.com
4. @gitlabstatus, emergency maintenance noticetwitter.com
5. Hacker News, "GitLab Database Incident – Live Report" (1,162 points, 598 comments)news.ycombinator.com
6. Hacker News, the postmortem thread (377 points)news.ycombinator.com