מהנדס מחק את מסד הנתונים של GitLab בפרודקשן. 300 גיגה-בייט.

מה מכסה הסרטון הזה

• 31 בינואר 2017: rm -Rvf על ספריית הנתונים של הראשי; ~300 ג'יגה-בייט הוסרו, 4.5 ג'יגה-בייט נותרו
• 5 מתוך 5 גיבויים נכשלים: דלי S3 ריק (אי התאמת גרסאות pg_dump), אין תצלומי מצב של Azure על מסד הנתונים, רפליקה נמחקה, העתקת LVM יומית ללא Webhooks
• 1 בפברואר, 18:00 UTC: GitLab.com חזר מצילום מצב ידני בן 6 שעות; מסמך חי, שידור חי, פוסטמורטם ללא אשמה עם רשימת תיקונים

תמליל מתורגם

תורגם מהקריינות המקורית באנגלית. זמינות אודיו וכתוביות נשלטת על ידי YouTube.

0:00 מהנדס ב-GitLab מריץ rm -rf על שרת מסד נתונים שגוי, ושלוש מאות גיגה-בייט מ-GitLab.com נעלמים תוך שנייה או שתיים, בקירוב זמן הקריאה של שם מארח. 31 בינואר 2017, 23:27 שעון UTC. GitLab מצייץ שמחק בטעות נתוני פרודקשן, פותח את הערות האירוע שלו לאינטרנט, ומשדר את השחזור ביוטיוב, השידור החי מספר שתיים בפלטפורמה. למחרת, בכתב: מתוך חמש טכניקות גיבוי,

0:25 אף אחת לא עובדת באופן אמין. איך זה קורה, למה זה אפשרי, ומי באמת אשם. זהו The Daily Diff, פוסטמורטם. 17:20: מהנדס מצלם תמונת מצב של פרודקשן כדי לבדוק מאזן עומסים בסביבת הבדיקות. 19:00: ספאם חובט במסד הנתונים, בתוספת משימה מוחקת לחלוטין עובד GitLab ש- טרול דיווח עליו על שימוש לרעה. 23:00: הרפליקה מפגרת כל כך עד שהראשי כבר מחק

0:48 את הלוג שהוא צריך; התיקון היחיד הוא למחוק את הרפליקה ולהעתיק את הראשי שוב. pg_basebackup נתקע ללא פלט. הוא למעשה ממתין, בשקט, לראשי; אף אחד לא יודע זאת, וה-runbook אינו מציין זאת. המהנדס, שהתכוון לסיים בשעה אחת עשרה, מחליט שספריית הנתונים הריקה היא הבעיה ומסיר אותה. ב-db1. הראשי. הוא שם לב שנייה או שתיים מאוחר יותר; מתוך כ-שלוש מאות גיגה-בייט,

1:11 4.5 נותרו. הגיבויים. אחד: pg_dump ל-S3, יומי. הדלי ריק. משימת ה-cron רצה על שרת יישומים ללא מסד נתונים, כך שהחבילה בוחרת קבצי הפעלה של PostgreSQL 9.2 עבור מסד נתונים 9.6, נכשלת, ושולחת אימיילים על הכשל, שקופצים חזרה בגלל חוסר ב-DMARC. שניים: תצלומי מצב של דיסק Azure, מופעלים עבור שרתי הקבצים, לא עבור מסדי הנתונים.

1:32 שלוש: הרפליקה, שנמחקה בכוונה לפני שעה. ארבע: צילום המצב היומי, בן 24 שעות, כאשר כל ה-webhookים הוסרו על ידי ה- סנכרון לסביבת הבדיקות. חמש: צילום המצב הידני מ-17:20, לבדיקה לא קשורה. זה מנצח. שחזור פירושו העתקת דיסק הבדיקות בחזרה לפרודקשן דרך אחסון Azure הזול בשישים מגה-ביט לשנייה: שמונה עשרה שעות. GitLab.com חזר ב-1 בפברואר בשעה שש בערב UTC, שישה שעות נתונים ישנים יותר.

1:58 git blame: שני שמות מארחים במרחק תו אחד, וחמש מערכות גיבוי שאף אחד מעולם לא שחזר מהן. לא המהנדס. הפוסטמורטם, חתום על ידי המנכ"ל, שומר עליו אנונימי, צובע את הפקודה בפרודקשן באדום, ומעניק עמידות נתונים לבעלים, כי עד עכשיו לא היה לו כזה. רדיוס פיצוץ: שמונה עשרה שעות השבתה, שש שעות של נתונים אבודים, כחמשת אלפים פרויקטים, חמשת אלפים תגובות,

2:18 שבע מאות משתמשים חדשים, וחמשת אלפים אנשים צופים בסרגל התקדמות. Hacker News מעניק למסמך החי 1,162 נקודות ומצטט שורה אחת בחזרה אליהם: מתוך חמישה גיבויים, אף אחד. פסק דין, פוסטמורטם: SHIP IT, על התגובה. הם מנהלים את האירוע בציבור, מאשימים את התהליך, ומפרסמים את רשימת התיקונים עם מספרי בעיות. פעולת יום שני: שחזר גיבוי. אם מעולם לא שחזרת אותו, אין לך כזה.

2:42 שלח לי את האירוע שעדיין אסור לך לדבר עליו, בתגובות, או ב-thedailydiff.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