Самая дорогая ошибка, которую я наблюдал в роли технического директора

Однажды, мне пришлось разбираться с последствиями одной ошибки, которая стоила очень дорого бизнесу, а на разбор последствий ушло около года. Сегодня поделюсь выводами, которые я извлек из этой ситуации которая произошла более 10 лет назад.

Закон Мёрфи: «Если что-нибудь может пойти не так, оно пойдёт не так»

Вы когда-нибудь сталкивались с тем, что в жизни начинают происходить несвязанные друг с другом события, которые сами по себе не имеют критических последствий при этом вероятность их относительно низкая, но они почему-то начинают происходить в один момент, как по сговору, что в итоге превращается в лавину неприятностей?

Вот именно такая лавина “случайностей” в моей практике однажды привела к тому, что в одной компании, у которой насчитывалось уже несколько десятков тысяч пользователей, в один прекрасный солнечный день была утеряна база данных за последние 3 месяца. Все новые пользователи, все данные пользователей, все платежи и прочие данные были безвозвратно утеряны.

Что случилось

Всех деталей я, по понятным причинам, раскрыть не могу, но если в общих чертах, то: у сервера, на котором работал сервис, пропало питание, после включения питания у сервера перестала запускаться база данных установленная на нем, после безуспешных попыток восстановить работу базы данных было принято решение восстановить ее из свежей резервной копии. Базу восстановили, сервис снова заработал и… оказалось что в “актуальной” резервной копии нет данных за последние 3 месяца.

Как так получилось

На тот момент система резервного копирования была настроена таким образом: основная база данных зеркалируется на резервную базу данных в реальном времени, а с резервной базы данных ежедневно снимается резервная копия. И ровно за 3 месяца за инцидента, механизм зеркалирования данных на резервную базу данных дал сбой. При этом резервная база данных в системе мониторинга говорила “у меня всё ок, механизм синхронизации работает”, но по факту новые данные в неё перестали приходить и она “зависла” в одном состоянии. Соответственно все резервные копии снимаемые с нее ежедневно уже не содержали актуальных данных.

Последствия

Естественно, для бизнеса это были большие репутационные потери: очень много пользователей лишились всех своих данных за этот период. Очень много сил и времени ушло на переписки с пользователями и попытки восстановить хоть какие-то данные. Около года потребовалось, чтобы хоть как-то разгрести последствия этого инцидента — восстановить доверие пользователей, стабилизировать продукт и вернуть бизнес в рабочее состояние.

Работа над ошибками

Когда я подключился к задаче, то моей основной целью было исключить повторение подобной ситуации. Система резервного копирования была полностью переработана: начиная от проверки того, что резервные копии 100% снимаются с актуальных данных, до того, что резервные копии 100% при восстановлении содержат актуальные данные. Естественно были предусмотрены сценарии, когда дата-центр, в котором хранятся резервные копии, может быть полностью уничтожен (вот вам примеры того, что и такое случается https://habr.com/ru/news/546264/ и https://habr.com/ru/articles/954512/).

Выводы

Важность резервных копий сложно переоценить, не даром даже есть поговорка: люди делятся на три категории: те кто ещё не делает резервные копии, те, кто уже делает, и те, кто проверяет сделанные.

Но эта ошибка на самом деле не была технической, она была управленческой. Проблема была не в том, что не было резервного копирования, а в том, что никто не задался вопросом: а что будет, если один из элементов этой системы перестанет работать незаметно? Если бы хотя бы одно из событий в этой цепочке было предусмотрено, то последствия могли бы быть минимальными или их удалось бы избежать вовсе.