یک مهندس پایگاه داده تولیدی گیت‌لب را حذف کرد. 300 گیگابایت.
31 ژانویه 2017، 23:27 UTC: یک مهندس گیت‌لب، در پایان یک شب طولانی در حال مبارزه با یک رپلیکای خراب، به جای db2، دایرکتوری داده PostgreSQL را در db1 حذف می‌کند.
31 ژانویه 2017، 23:27 UTC: یک مهندس گیت‌لب، در پایان یک شب طولانی در حال مبارزه با یک رپلیکای خراب، به جای db2، دایرکتوری داده PostgreSQL را در db1 حذف می‌کند. db1 اولیه است. حدود 300 گیگابایت از پایگاه داده GitLab.com در یک یا دو ثانیه از بین می‌رود و از پنج مکانیسم پشتیبان‌گیری و تکرار، هیچ یک کار نمی‌کند. گزارش پس از حادثه: جدول زمانی از افزایش ناگهانی اسپم تا نام هاست اشتباه، اینکه چرا pg_basebackup گیر کرده به نظر می‌رسید، چرا pg_dump بی‌صدا از کار می‌افتاد (باینری‌های 9.2 روی پایگاه داده 9.6، ایمیل‌های شکست توسط DMARC برگشت داده می‌شد)، بازیابی 18 ساعته از یک اسنپ‌شات موقت 6 ساعته که به صورت زنده در YouTube پخش شد، و اینکه تقصیر واقعاً گردن کیست. حکم در مورد پاسخ: SHIP IT.
نسخه نوشتاری را بخوانید (انگلیسی) ↗
این ویدیو چه مواردی را پوشش می‌دهد
- 31 ژانویه 2017: rm -Rvf روی دایرکتوری داده اصلی؛ ~300 گیگابایت حذف شد، 4.5 گیگابایت باقی ماند
- 5 از 5 نسخه پشتیبان ناموفق: سطل S3 خالی (عدم تطابق نسخه pg_dump)، عدم وجود اسنپ‌شات‌های Azure روی DB، رپلیکای پاک شده، کپی روزانه LVM بدون وب‌هوک
- 1 فوریه، 18:00 UTC: GitLab.com از یک اسنپ‌شات دستی 6 ساعته بازگشت؛ سند زنده، پخش زنده، گزارش پس از حادثه بدون سرزنش با فهرست اصلاحات
رونوشت ترجمه شده
ترجمه شده از روایت اصلی انگلیسی. صوت و زیرنویس‌های موجود توسط YouTube کنترل می‌شوند.
0:00 یک مهندس در گیت‌لب دستور rm -rf را روی سرور پایگاه داده اشتباه اجرا می‌کند، و سیصد گیگابایت از GitLab.com در یک یا دو ثانیه ناپدید می‌شود، تقریباً به اندازه زمانی که برای خواندن یک نام هاست لازم است. 31 ژانویه 2017، ساعت 11:27 شب. UTC. گیت‌لب توییت می‌کند که به اشتباه داده‌های تولید را حذف کرده است، یادداشت‌های حادثه خود را برای اینترنت باز می‌کند، و بازیابی را در YouTube پخش می‌کند، دومین پخش زنده در پلتفرم. روز بعد، به صورت کتبی: از پنج روش پشتیبان‌گیری،
0:25 هیچ یک به طور قابل اعتماد کار نمی‌کنند. چگونه اتفاق می‌افتد، چرا ممکن است، و تقصیر واقعاً گردن کیست. این The Daily Diff، گزارش پس از حادثه است. 5:20 بعد از ظهر: یک مهندس از تولید اسنپ‌شات می‌گیرد برای آزمایش یک متعادل‌کننده بار در محیط staging. 7 شب: اسپم به پایگاه داده حمله می‌کند، به علاوه یک کار که یک کارمند گیت‌لب را به طور سخت‌افزاری حذف می‌کند، زیرا یک ترول او را به دلیل سوءاستفاده گزارش کرده است. 11 شب: رپلیکا آنقدر عقب می‌ماند که primary قبلاً
0:48 لاگ مورد نیاز را دور انداخته است؛ تنها راه حل این است که رپلیکا را پاک کرده و primary را دوباره کپی کند. pg_basebackup بدون خروجی گیر می‌کند. در واقع، بی‌صدا منتظر primary است؛ هیچ کس این را نمی‌داند، و دفترچه راهنما نمی‌گوید. مهندس، که قصد داشت ساعت یازده مرخصی بگیرد، تصمیم می‌گیرد که دایرکتوری داده خالی مشکل است و آن را حذف می‌کند. روی db1. primary. یک یا دو ثانیه بعد متوجه می‌شود؛ از تقریباً سیصد گیگابایت،
1:11 4.5 باقی مانده است. نسخه‌های پشتیبان. یک: pg_dump به S3، روزانه. سطل خالی است. کرون جاب روی یک سرور برنامه بدون پایگاه داده اجرا می‌شود، بنابراین بسته باینری‌های PostgreSQL 9.2 را برای یک پایگاه داده 9.6 انتخاب می‌کند، شکست می‌خورد، و ایمیل شکست را ارسال می‌کند، که به دلیل DMARC ناموجود برگشت داده می‌شود. دو: اسنپ‌شات‌های دیسک Azure، برای سرورهای فایل فعال شده‌اند، نه پایگاه‌های داده.
1:32 سه: رپلیکا، یک ساعت پیش عمداً پاک شده است. چهار: اسنپ‌شات روزانه، 24 ساعت قدیمی، هر وب‌هوک توسط همگام‌سازی staging حذف شده است. پنج: اسنپ‌شات دستی از 5:20، برای یک آزمایش بی‌ربط. آن یکی برنده می‌شود. بازیابی به معنای کپی کردن دیسک staging به تولید از طریق فضای ذخیره‌سازی ارزان Azure با سرعت شصت مگابیت در ثانیه: هجده ساعت. GitLab.com در 1 فوریه ساعت شش بعد از ظهر UTC، شش ساعت داده قدیمی‌تر است.
1:58 git blame: دو نام هاست با یک کاراکتر تفاوت، و پنج سیستم پشتیبان که هیچ کس هرگز از آنها بازیابی نکرده است. نه مهندس. گزارش پس از حادثه، امضا شده توسط مدیر عامل، او را ناشناس نگه می‌دارد، اعلان تولید را قرمز می‌کند، و دوام داده‌ها را به یک صاحب اختصاص می‌دهد، زیرا تا کنون هیچ مالکی نداشت. شعاع انفجار: هجده ساعت از کار افتادن، شش ساعت از دست رفتن داده‌ها، تقریباً پنج هزار پروژه، پنج هزار کامنت،
2:18 هفتصد کاربر جدید، و پنج هزار نفر در حال تماشای نوار پیشرفت. Hacker News به سند زنده 1,162 امتیاز می‌دهد و یک خط را به آنها نقل می‌کند: از پنج نسخه پشتیبان، هیچ کدام. حکم، گزارش پس از حادثه: SHIP IT، در مورد پاسخ. آنها حادثه را علنی اجرا می‌کنند، فرآیند را سرزنش می‌کنند، و فهرست اصلاحات را با شماره‌های issue منتشر می‌کنند. اقدام دوشنبه: یک نسخه پشتیبان را بازیابی کنید. اگر هرگز آن را بازیابی نکرده‌اید، یکی ندارید.
2:42 حادثه‌ای را که هنوز اجازه صحبت درباره آن را ندارید، برای من ارسال کنید، در نظرات، یا در thedailydiff.dev. و این The Daily Diff برای امروز است. من نیکو از Axrisi هستم. با مسئولیت‌پذیری ادغام کنید.
منابع
- GitLab, "Postmortem of database outage of January 31" (Feb 10, 2017)about.gitlab.com
- GitLab, "GitLab.com database incident" (Feb 1, 2017)about.gitlab.com
- @gitlabstatus, "We accidentally deleted production data…"twitter.com
- @gitlabstatus, emergency maintenance noticetwitter.com
- Hacker News, "GitLab Database Incident – Live Report" (1,162 points, 598 comments)news.ycombinator.com
- Hacker News, the postmortem thread (377 points)news.ycombinator.com
