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

Что освещается в этом видео

• 31 января 2017 г.: rm -Rvf в каталоге данных первичного сервера; удалено ~300 ГБ, осталось 4,5 ГБ
• 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