Пока не заработало у людей, ничего не было

иллюстрация

Вечером 31 января 2017 года инженер GitLab, одного из крупнейших в мире сервисов для хранения кода, разбирался с неполадкой в базе данных. У базы было два сервера, основной и запасной, и запасной отстал от основного и перестал копировать с него данные. Чтобы запустить копирование заново, запасной сервер нужно было очистить. Шла поздняя ночь по времени инженера, он устал, несколько часов подряд воевал с этой проблемой, и в какой-то момент выполнил команду удаления данных в окне, которое было подключено не к тому серверу. Через секунду-другую он заметил ошибку и остановил команду. За эту секунду с основного сервера исчезли около трёхсот гигабайт рабочих данных.

У компании было несколько способов резервного копирования, и каждый был настроен. Когда команда начала их проверять, оказалось, что ни один не работает так, как все считали. Ежедневные копии на облачное хранилище не создавались, потому что программа копирования была рассчитана на старую версию базы, и об ошибках она сообщала письмами, которые никто не получал из-за другой настройки. Другие механизмы либо не были включены для этого сервера, либо давали копии, из которых нельзя было быстро восстановиться. Спасла ситуацию случайность: за шесть часов до аварии один из инженеров сделал снимок базы для своих тестовых нужд. Из него всё и восстановили, а изменения за эти шесть часов — проекты, комментарии, около семисот новых учётных записей — пропали. Восстанавливались в прямом эфире на YouTube, и тысячи людей несколько часов смотрели, как копируются данные.

До аварии всё выглядело образцово. Резервное копирование было настроено, задачи стояли в расписании, в документации было написано, что копии делаются. На любом совещании на вопрос «у нас есть резервные копии?» ответ был бы «да», и этот ответ был бы искренним. Копий при этом не было, потому что никто ни разу не пробовал из них восстановиться. Резервная копия, из которой ни разу не восстанавливались, существует примерно в том же смысле, в каком существует программообразный предмет из второй главы.

Со мной похожее случилось в куда более скромном масштабе, и этим он, по-моему, показательнее. Двадцать восьмого марта 2026 года я выкатывал новую версию одного из своих проектов, initerent. Сценарий выкатки должен был сделать четыре вещи по очереди: перевести базу на новую схему, заполнить её начальными данными, перенести старые документы и только после этого остановить приложение и поднять его заново. Сценарий споткнулся на первой же строчке из-за мелкой ошибки в синтаксисе командной оболочки, а дальше, из-за неправильно выставленных настроек и пустой переменной с именем учётной записи в хранилище образов, начали одна за другой падать миграция, заполнение и перенос документов. А потом, несмотря на то что ни одна подготовительная операция не выполнилась, сценарий дошёл до последнего шага и честно остановил приложение, чтобы пересоздать его на новой версии.