Сервис для хранения кода GitLab лег из-за действий администратора, случайно удалившего 300 ГБ из базы данных компании. Сервис стал недоступен ночью с 31 на 1 февраля и не функционировал до примерно 16-00 по Москве. Находящийся в Амстердаме администратор по ошибке стер базу, в которой содержались запросы на изменение документации и кода проектов пользователей, при этом их репозитории остались нетронутыми.
В GitLab отметили, что в этом случае не помогла ни одна из пяти существующих в компании систем для хранения бэкапов: например, в одном из случаев процедура сохранения данных срабатывала с ошибкой, из-за чего бэкап не создавался. Последний актуальный бэкап был создан за 6 часов до инцидента и компания с его помощью пытается восстановить удаленную базу. Согласно сообщению в официальном Twitter компании, ей уже удалось восстановить около 75% данных.
https://twitter.com/gitlabstatus/status/826783947195633664
Администрация ресурса разместила полный отчет об инциденте и попытках восстановить данные. Информация за 6 часов работы была утеряна безвозвратно. GitLab создана в 2014 году украинским предпринимателем Дмитрием Запорожцем, штаб-квартира компании расположена в Сан-Франциско. По данным CrunchBase, за всё время существования она привлекла около $25,6 млн.
Добавить 7 комментариев
Отличная антиреклама.
Кому? Гитлабу, для которого это по сути лишь тестовая площадка для Gitlab EE, или тем, кто посчитал эту очевидную тестовую площадку местом, в котором стоит хранить свой код?
Ну и кстати, со всеми бывает: https://github.com/blog/744-today-s-outage
https://docs.google.com/document/d/1GCK53YDcBWQveod9kfzW-VCxIABGiryG7_z_6jHdVik/pub
>At this point frustration begins to kick in. Earlier this night YP explicitly mentioned he was going to sign off as it was getting late (23:00 or so local time), but didn’t due to the replication problems popping up all of a sudden.
> YP thinks that perhaps pg_basebackup is being super pedantic about there being an empty data directory, decides to remove the directory. After a second or two he notices he ran it on db1.cluster.gitlab.com, instead of db2.cluster.gitlab.com
2017/01/31 23:27 YP — terminates the removal, but it’s too late. Of around 310 GB only about 4.5 GB is left — Slack
Девопс заработался и перепутал базы. Надо было элементарно кинуть комманду в чат чтобы коллеги проверили перед выполнением.
шутка про дятла, разрушившего цивилизацию уже перестает быть шуткой
У них весьма забавная онлайн-трансляция на ютубе была с восстановление базы в рилтайме: https://www.youtube.com/watch?v=nc0hPGerSd4
Текстовая онлайн-сводка тоже присутствовала: https://docs.google.com/document/d/1GCK53YDcBWQveod9kfzW-VCxIABGiryG7_z_6jHdVik/pub
Понравилась такая открытость и подход к реакции на инцидент.
А бэкапы без периодической проверки их работоспособности — не бэкапы, иначе толку от них, если они не работают.
> Девопс заработался и перепутал базы. Надо было элементарно кинуть комманду в чат чтобы коллеги проверили перед выполнением.
Серьезно? какую команду? ту самую, т.е. соломку подстелить нужно было? Или Вы полагаете, что каждую команду админа нужно слать на ревью?
На самом деле, если уж идет возня руками в продакшн, что уже нездорово, вместо удаления файлов/каталогов следует переименовывать/перемещать их, напр. mv pg_basebackup pg_basebackup.off