Повторяющиеся падения: как найти первопричину и прекратить простои
Повторяющиеся падения — это не “невезение” и не “ну бывает”. Это признак, что проблему лечат пластырем: перезапустили, подкрутили, “почистили”, и на пару дней стало легче. Потом всё повторилось. Для бизнеса это означает одно: система живет в режиме пожара, а вы теряете выручку, репутацию и управляемость.
Ниже — подход, который помогает выйти из бесконечного круга “упало → срочно подняли → забыли”.
1) Зафиксируйте, что вы называете “падением” и чем это измеряется
Чтобы перестать спорить, нужно договориться о терминах. Для владельца бизнеса “падение” — это когда:
- клиенты не могут оформить заказ/оставить заявку;
- менеджеры не видят новые обращения;
- оплаты не проходят или статусы не обновляются;
- сотрудники не могут работать в системе.
Сразу определите 2–3 показателя, которые важны именно вам: например, “сколько минут в день недоступно оформление заказа” или “сколько заявок застряло”. Без этого подрядчик может рапортовать “сервер жив”, а бизнес будет гореть.
2) Соберите факты, а не эмоции: простой журнал инцидентов
Вам не нужна техническая простыня. Нужна таблица (или список) по каждому случаю:
- дата и время начала/окончания;
- что именно перестало работать (с точки зрения пользователя);
- сколько клиентов/сделок затронуто (примерно);
- что сделали для восстановления (перезапуск, откат, отключили модуль);
- повторилось ли через 1–3–7 дней.
Через 2–3 недели у вас будет картина: падения происходят в пиковые часы, после релиза, при интеграции X, при выгрузке отчетов. Это уже почти половина решения.
3) Разделите “симптом” и “первопричину” — и требуйте второе
Симптом: “сайт не открывается”, “CRM не грузится”, “оплата не проходит”.
Первопричина: “заканчивается место/память”, “очередь интеграции забилась”, “после обновления выросла нагрузка”, “одна операция блокирует остальные”.
Бизнес‑правило простое: закрытым инцидент считается только тогда, когда устранена первопричина или хотя бы поставлена защита от повторения. Если в отчете написано “перезапустили, стало ок” — это не решение, это отсрочка.
4) Попросите у поддержки 3 ответа по каждому повтору
Для владельца достаточно трех пунктов:
- Что было причиной (человеческим языком)?
- Почему это не поймали заранее?
- Что сделали, чтобы не повторилось (конкретно)?
Если на третий пункт ответа нет, значит, вы продолжите платить за пожары.
5) Введите правило: “быстро поднять” + “устойчиво исправить”
В момент падения цель одна — минимизировать ущерб. Это “быстро поднять”. Но дальше должен быть второй этап — “устойчиво исправить”, уже без спешки, но с дедлайном.
Например:
- срочно: переключили на упрощенный режим, отключили тяжёлый отчет, временно ограничили функционал;
- затем: переработали узкое место, добавили контроль, сделали обновление безопасным.
Если второй этап не закреплен задачей, сроком и ответственным, он никогда не случится.
6) Самый частый источник повторов — изменения без контроля
Парадокс: многие падения начинаются после “невинной доработки”. Причина не в самой доработке, а в том, что изменения выкатывают без:
- понятного плана релиза,
- проверки на типовых сценариях,
- возможности быстро откатить,
- контроля “что ухудшилось”.
Поэтому повторяющиеся падения почти всегда лечатся не “одной правкой”, а налаживанием процесса.
7) Что вы можете сделать как бизнес‑заказчик уже завтра
- Назначить одного ответственного внутри (чтобы не было “каждый пишет в чат что видит”).
- Завести журнал инцидентов (простой, но обязательный).
- Ввести правило: “инцидент закрыт, когда есть предотвращение повтора”.
- Попросить у подрядчика план на 2–4 недели: быстрые стабилизации + работа с первопричинами.
- Установить контроль: еженедельный короткий отчет по стабильности.
Результат — вы переводите падения из хаоса в управляемую работу: меньше простоев, меньше срочных счетов и больше предсказуемости.