После аварии мы восстановили сервер — и 6 дней не замечали, что часть системы молчит
Переезд в пожарном режиме — это всегда компромисс. Когда поднимаешь систему с нуля за считанные часы, часть функций осознанно выключаешь: не до конца понятно, актуальны ли старые настройки на новом месте, и включать всё подряд без проверки — риск разослать клиентам что-то неправильное. Так мы временно отключили несколько вещей: напоминания должникам о просроченной оплате, повторные касания с лидами, которые не дошли до сделки, пересчёт реферальных начислений, веб-пуш уведомления. Пометка в скрипте восстановления была простая — «выключено, ждём решения» — и в голове это звучало как временная мера на день-два.
Дальше встал вопрос, который на самом деле сложнее, чем кажется: как убедиться, что после аварии восстановлено ВСЁ, а не только то, что видно на первый взгляд? Проверка 7 ноября отвечала на вопрос «что из запущенного работает без ошибок» — заходили в каждый процесс, смотрели лог, если лог свежий и без исключений, ставили галочку. Логика разумная, но у неё есть слепая зона: выключенный вручную флаг не падает и не пишет ошибку. Он просто ничего не делает. С точки зрения мониторинга такой процесс выглядит так же тихо и благополучно, как процесс, который вовсе не должен был запускаться.
В эту дыру и попали напоминания должникам и повторные касания с лидами. Оба флага стояли в `false` ещё с момента аварийной сборки, потому что на тот момент их включение отложили «до решения» — а отдельной задачи с этим решением никто не завёл, оно осталось комментарием внутри скрипта. При каждой следующей проверке смотрели на список запущенных процессов, а не на список того, что было включено до аварии. Клиенты с просроченной оплатой не получали напоминаний шесть дней — не потому что сломалась отправка, а потому что система добросовестно выполняла команду «не отправлять», которую сама себе поставила в момент пожара и о которой все забыли.
13 ноября сделали сверку по-другому — механически, а не на глазах. Вместо того чтобы снова обходить процессы и смотреть, не упали ли они, выписали из собственных рабочих заметок все флаги, которые по смыслу должны стоять «включено» (простым поиском шаблона `*_ENABLED=true` по своим записям), и построчно сравнили этот список с реальными настройками на новом сервере. Несовпадение в любую сторону — сигнал: либо забыли включить то, что давно пора вернуть, либо это осознанная пауза, но тогда она обязана висеть отдельной открытой задачей с вопросом, а не молчать внутри скрипта.
Сверка сразу поймала обе пропавшие функции. Напоминания включили, прогнали сначала на трёх тестовых адресатах, затем вживую: за один прогон уведомления получили три человека — двое через бота, один через SMS, ошибок ноль. Та же проверка нашла и другую вещь, которая маскировалась под «работает»: сторож, следящий за активностью в соцсетях, делал запуск каждые пять минут, журнал показывал «процесс стартовал» — но все 34 последних запуска подряд падали на одной и той же ошибке отсутствующего модуля, просто ни одна из них не пробивалась в основной список инцидентов, потому что сам процесс технически стартовал.
Вывод получился не про конкретную аварию, а про то, как вообще проверять восстановление после любого форс-мажора. Мониторинг «ничего не падает» и факт «всё работает, как должно» — это два разных утверждения, и после аварии между ними легко потерять несколько дней, потому что молчащий выключенный флаг ничем не отличается от молчащего здорового процесса, пока не сравнишь его с тем, что было раньше. Если у вас есть система, которую когда-нибудь придётся поднимать в пожарном режиме, заранее стоит держать где-то один список «что должно быть включено в норме» — в явном виде, который можно механически сравнить с реальностью после того, как пожар потушен. И любое «выключаю пока, разберёмся позже» в такой момент стоит сразу превращать в отдельный открытый вопрос с конкретным сроком — иначе разбираться придётся не вам, а клиенту, который неделю не получал писем и даже не узнает почему.