Коротко: самые дорогие аварии в проде — не «гениальный баг», а отсутствие бэкапов, миграции без отката, доступ без ограничений и деплой в пятницу.

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

Ошибка 1. Бэкап, который никто не проверял

Классика: бэкапы вроде бы делаются, а в момент аварии выясняется, что они битые, неполные или последний валидный — двухнедельной давности. Бэкап, который ни разу не восстанавливали, — это не бэкап, а надежда.

Чему научило: раз в период делать тестовое восстановление на отдельный стенд. Если восстановление не отрепетировано — считайте, что бэкапа нет.

Ошибка 2. Миграция БД без плана отката

Выкатили релиз, миграция переименовала колонку / удалила данные, что-то пошло не так — а отката нет. Особенно больно с разрушающими изменениями (DROP COLUMN, UPDATE без бэкапа).

-- опасно: данные теряются безвозвратно
ALTER TABLE orders DROP COLUMN legacy_status;

-- безопаснее: сначала перестать использовать в коде,
-- выкатить, убедиться, что всё ок, и только потом удалять колонку
-- (expand / contract — двухфазная миграция)

Чему научило: разрушающие миграции — двухфазно (expand/contract), сначала перестаём писать/читать колонку, и только отдельным релизом удаляем. И всегда снимок БД перед выкаткой.

Ошибка 3. Доступ к проду «у всех и всё»

Когда у половины команды есть рут на проде и прямой доступ к боевой БД, рано или поздно кто-то выполнит DELETE/UPDATE без WHERE на боевой базе вместо тестовой. Это вопрос времени, а не вероятности.

Чему научило: принцип наименьших привилегий, отдельные учётки, прод-доступ — по необходимости и с аудитом. Любая ручная операция на проде — через ревью или хотя бы «второй парой глаз».

Ошибка 4. Деплой в пятницу вечером

Выкатили большой релиз в конце дня в пятницу, что-то отвалилось — и команда либо чинит на выходных, либо прод лежит до понедельника. Дорого и по деньгам, и по выгоранию.

Чему научило: крупные релизы — в начале дня и недели, когда есть кому реагировать. Не «нельзя деплоить в пятницу из суеверия», а «не выкатывай то, что некому будет чинить».

Ошибка 5. Нет мониторинга — узнаём от пользователей

Если о падении вы узнаёте из гневного письма клиента, а не от алерта, — вы управляете системой вслепую. Тихие деградации (выросли тайминги, копится очередь, заканчивается место на диске) самые коварные.

Чему научило: базовый мониторинг и алерты — это не «когда-нибудь потом», а часть выхода в прод. Хотя бы аптайм, ошибки, latency и свободное место.

Ошибка 6. Секреты в коде и репозитории

Пароль от боевой БД или ключ платёжного шлюза, закоммиченный в репозиторий, — это утечка, которая уже произошла, даже если коммит потом удалили (он остаётся в истории).

Чему научило: секреты — только в переменных окружения / секрет-хранилище, и ротация ключей, если что-то всё-таки утекло.

Что общего у всех этих историй

Ни одна из дорогих аварий не была про сложный алгоритм. Все они — про отсутствие простой дисциплины: проверенные бэкапы, обратимые миграции, ограниченный доступ, разумное окно релизов, мониторинг и гигиена секретов. Это дёшево внедрить заранее и очень дорого осознать постфактум.

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