Инженер изтри производствената база данни на GitLab. 300 гигабайта.

Какво обхваща този видеоклип

• 31 януари 2017 г.: rm -Rvf върху директорията с данни на основната; ~300 GB премахнати, останали 4,5 GB
• 5 от 5 архива не работят: празен S3 кош (несъответствие във версията на pg_dump), без Azure моментни снимки на базата данни, изтрита реплика, ежедневно LVM копие без уебхукове
• 1 февруари, 18:00 UTC: GitLab.com се възстановява от 6-часова ръчна моментна снимка; документ на живо, предаване на живо, безпристрастен посмъртен анализ със списък с корекции

Преведен препис

Преведено от оригиналния английски разказ. Наличните аудио и субтитри се контролират от YouTube.

0:00 Инженер от GitLab изпълнява rm -rf на грешния сървър на базата данни, и триста гигабайта от GitLab.com изчезват за секунда или две, приблизително толкова време, колкото е необходимо за прочитане на име на хост. 31 януари 2017 г., 23:27 ч. UTC. GitLab туитва, че по погрешка е изтрил производствени данни, отваря своите бележки за инциденти за интернет и предава възстановяването на живо в YouTube, вторият най-гледан поток на живо в платформата. На следващия ден, писмено: от пет техники за архивиране,

0:25 нито една не работи надеждно. Как се случва, защо е възможно и кой всъщност е виновен. Това е The Daily Diff, посмъртен анализ. 17:20 ч.: инженер прави моментна снимка на производството за тестване на балансьор на натоварването в стейджинг. 19:00 ч.: спам атакува базата данни, плюс задача за твърдо изтриване на служител на GitLab, съобщен от трол за злоупотреба. 23:00 ч.: репликата изостава толкова много, че основната вече е изхвърлила

0:48 лога, от който се нуждае; единственото решение е да се изтрие репликата и да се копира основната отново. pg_basebackup виси без изход. Всъщност чака мълчаливо основната; никой не знае това, и наръчникът не го казва. Инженерът, който е трябвало да приключи в единадесет, решава, че празната директория с данни е проблемът и я премахва. На db1. Основната. Забелязва секунда или две по-късно; от приблизително триста гигабайта,

1:11 остават 4,5. Архивите. Едно: pg_dump към S3, ежедневно. Кошът е празен. Задачата cron се изпълнява на приложен сървър без база данни, така че пакетът избира PostgreSQL 9.2 бинарни файлове за база данни 9.6, не успява и изпраща имейли за неуспеха, които отскачат поради липсващ DMARC. Две: моментни снимки на Azure диск, активирани за файловите сървъри, не за базите данни.

1:32 Три: репликата, изтрита нарочно преди час. Четири: ежедневната моментна снимка, на 24 часа, всеки уебхук премахнат от синхронизацията на стейджинг. Пет: ръчната моментна снимка от 17:20, за несвързан тест. Тази печели. Възстановяването означава копиране на стейджинг диска обратно в производството през евтиното хранилище на Azure при шейсет мегабита в секунда: осемнадесет часа. GitLab.com се връща на 1 февруари в шест вечерта UTC, данни на шест часа.

1:58 git blame: две имена на хостове с един символ разлика и пет системи за архивиране, от които никой никога не е възстановявал. Не инженерът. Посмъртният анализ, подписан от изпълнителния директор, го запазва анонимен, оцветява червено производствения промпт и дава на устойчивостта на данните собственик, защото досега нямаше такъв. Радиус на взрива: осемнадесет часа прекъсване, шест часа данни изчезнали, приблизително пет хиляди проекта, пет хиляди коментара,

2:18 седемстотин нови потребители и пет хиляди души, гледащи лента за напредък. Hacker News дава на документа на живо 1162 точки и цитира един ред обратно към тях: от пет архива, нито един. Присъда, посмъртен анализ: SHIP IT, относно отговора. Те управляват инцидента публично, обвиняват процеса и публикуват списъка с корекции с номера на проблемите. Действие за понеделник: възстановяване на архив. Ако никога не сте го възстановявали, нямате такъв.

2:42 Изпратете ми инцидента, за който все още не ви е позволено да говорите, в коментарите или на 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