مهندس حذف قاعدة بيانات GitLab الإنتاجية. 300 جيجابايت.

ما يغطيه هذا الفيديو

• 31 يناير 2017: rm -Rvf على دليل بيانات الأساسي؛ تم حذف ~300 جيجابايت، وبقي 4.5 جيجابايت
• فشل 5 من أصل 5 نسخ احتياطية: سلة S3 فارغة (عدم تطابق إصدار pg_dump)، لا توجد لقطات Azure على قاعدة البيانات، نسخة طبق الأصل ممسوحة، نسخة LVM يومية بدون webhooks
• 1 فبراير، 18:00 بالتوقيت العالمي المنسق: GitLab.com يعود من لقطة يدوية عمرها 6 ساعات؛ وثيقة حية، بث مباشر، تقرير ما بعد الوفاة بدون لوم مع قائمة إصلاحات

النص المترجم

مترجم من السرد الإنجليزي الأصلي. يتم التحكم في الصوت والتعليقات التوضيحية المتاحة بواسطة YouTube.

0:00 يقوم مهندس في GitLab بتشغيل rm -rf على خادم قاعدة البيانات الخاطئ، وثلاثمائة جيجابايت من GitLab dot com تختفي في ثانية أو اثنتين، تقريبًا الوقت الذي يستغرقه قراءة اسم المضيف. 31 يناير 2017، الساعة 11:27 مساءً. بالتوقيت العالمي المنسق. تغرد GitLab بأنها حذفت بيانات الإنتاج عن طريق الخطأ، تفتح ملاحظات الحادث للإنترنت، وتبث الاستعادة على YouTube، البث المباشر الثاني على المنصة. في اليوم التالي، كتابيًا: من بين خمس تقنيات للنسخ الاحتياطي،

0:25 لا يعمل أي منها بشكل موثوق. كيف يحدث ذلك، ولماذا هو ممكن، ومن يتحمل اللوم بالفعل. هذا هو The Daily Diff، تقرير ما بعد الوفاة. الساعة 5:20 مساءً: يقوم مهندس بالتقاط لقطة للإنتاج لاختبار موازن التحميل في المرحلة التجريبية. الساعة 7 مساءً: يضرب البريد العشوائي قاعدة البيانات بقوة، بالإضافة إلى مهمة حذف صعبة لموظف في GitLab قام بتبليغ عن تروُّل بسبب إساءة استخدام. الساعة 11 مساءً: تتخلف النسخة المتماثلة إلى درجة أن الأساسي قد تجاهل بالفعل

0:48 السجل الذي تحتاجه؛ الحل الوحيد هو مسح النسخة المتماثلة ونسخ الأساسي مرة أخرى. pg_basebackup يتوقف بدون إخراج. إنه في الواقع ينتظر، بصمت، الأساسي؛ لا أحد يعرف ذلك، ودليل التشغيل لا يذكر ذلك. المهندس، الذي كان ينوي المغادرة في الحادية عشرة، يقرر أن دليل البيانات الفارغ هو المشكلة ويزيله. على db1. الأساسي. يلاحظ بعد ثانية أو اثنتين؛ من حوالي ثلاثمائة جيجابايت،

1:11 تبقى 4.5. النسخ الاحتياطية. الأول: pg_dump إلى S3، يوميًا. السلة فارغة. وظيفة cron تعمل على خادم تطبيق بدون قاعدة بيانات، لذا يختار البرنامج ثنائيات PostgreSQL 9.2 لقاعدة بيانات 9.6، يفشل، ويرسل بريدًا إلكترونيًا بالفشل، والذي يرتد بسبب عدم وجود DMARC. الثاني: لقطات قرص Azure، مفعلة لخوادم الملفات، وليس لقواعد البيانات.

1:32 الثالث: النسخة المتماثلة، تم مسحها عمدًا قبل ساعة. الرابع: اللقطة اليومية، عمرها 24 ساعة، وكل webhook تم تجريده بواسطة مزامنة المرحلة التجريبية. الخامس: اللقطة اليدوية من الساعة 5:20، لاختبار غير ذي صلة. هذا هو الفائز. الاستعادة تعني نسخ قرص المرحلة التجريبية مرة أخرى إلى الإنتاج عبر تخزين Azure الرخيص بسرعة ستين ميجابت في الثانية: ثمانية عشر ساعة. GitLab dot com يعود في 1 فبراير في السادسة مساءً بالتوقيت العالمي المنسق، بيانات أقدم بست ساعات.

1:58 git blame: اسما مضيفين بفرق حرف واحد، وخمسة أنظمة نسخ احتياطي لم يقم أحد بالاستعادة منها قط. ليس المهندس. تقرير ما بعد الوفاة، موقع من قبل الرئيس التنفيذي، يبقيه مجهولاً، يلون موجه الإنتاج باللون الأحمر، ويعطي متانة البيانات مالكًا، لأنه حتى الآن لم يكن لديها مالك. نطاق التأثير: ثمانية عشر ساعة توقف، ست ساعات من البيانات المفقودة، ما يقرب من خمسة آلاف مشروع، خمسة آلاف تعليق،

2:18 سبعمائة مستخدم جديد، وخمسة آلاف شخص يشاهدون شريط تقدم. Hacker News يمنح الوثيقة الحية 1,162 نقطة ويقتبس منها سطرًا واحدًا: من أصل خمس نسخ احتياطية، لا شيء. الحكم، ما بعد الوفاة: SHIP IT، على الاستجابة. يديرون الحادث علنًا، يلومون العملية، وينشرون قائمة الإصلاحات مع أرقام المشاكل. إجراء الاثنين: استعادة نسخة احتياطية. إذا لم تقم باستعادته قط، فليس لديك واحد.

2:42 أرسل لي الحادث الذي ما زلت غير مسموح لك بالتحدث عنه، في التعليقات، أو على the daily diff dot dev. وهذا هو الفرق لليوم. أنا نيكو من 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