Я разделяю срочность и критичность до того, как обсуждать надёжность системы

Я стараюсь не путать срочное с критичным, когда мы обсуждаем надёжность системы. Срочное громко требует внимания прямо сейчас. Критичное может молчать неделями, но в неудачный день остановит работу компании. Если смотреть только на шум, команда всегда будет занята и всё равно останется без защиты.

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

Почему очередь инцидентов не заменяет карту рисков

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

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

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

Критичность начинается с последствий

Полезный вопрос звучит не так: «насколько это технически сложно?» А так: «что перестанет делать бизнес, если это случится?».

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

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

Необязательно переводить всё в сложную шкалу. Достаточно, чтобы руководитель и команда одинаково понимали: вот это можно исправить завтра, а вот это нужно проверить до того, как оно сломается.

У срочных задач тоже есть ловушка

Срочность легко превращается в привычку. Если одна и та же ошибка каждую неделю вызывает аврал, она уже не срочная задача. Это повторяющийся риск, который нужно вынести из режима «потушили и забыли».

Здесь помогает наблюдаемость. Не просто лог, куда никто не смотрит, а ответ на три вопроса: что именно перестало работать, кого это затронуло, когда началось. В статье о моменте, когда система перестаёт быть видимой я разбирал именно эту грань. Чем раньше команда видит отклонение, тем меньше срочности придумывает себе потом.

Я ищу не идеальную защиту, а следующий разумный шаг

Иногда разговор о надёжности стопорится на словах «нужно всё резервировать» или «сначала переделаем архитектуру». Это похоже на ремонт квартиры, который не начинают, потому что нельзя сразу заменить всё.

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

Такой шаг маленький, но проверяемый. Он полезнее общего обещания «повысить надёжность». А затем можно переходить к следующему риску. Архитектура обычно становится устойчивее не одним героическим проектом, а серией решений, которые уменьшают цену плохого дня.

Кому принадлежит решение

Техническая команда может описать варианты, но не должна в одиночку решать, сколько простоя допустимо для бизнеса. Это разговор владельца процесса и тех, кто отвечает за систему. Один говорит о последствиях, другой — о реалистичных способах защиты.

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

Не путайте риск с прогнозом

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

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

Как разговаривать о деньгах без страшилок

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

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

Решения должны оставлять след

После обсуждения критичного риска важно зафиксировать не только задачу, но и причину решения. Что защищаем, какой сценарий считаем приемлемым, кто проверит результат и когда вернёмся к вопросу. Через несколько месяцев система и бизнес меняются, и без этой записи новая команда может принять старую защиту за случайное ограничение.

Это не бюрократия ради документа. Это способ не начинать один и тот же спор с нуля. Приоритеты меняются, но решения остаются объяснимыми.

Простая таблица на одну встречу

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

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

Вывод

Срочное требует реакции. Критичное требует подготовки. Надёжная система — не та, где никогда не бывает проблем, а та, где команда заранее понимает цену главных рисков, знает первый шаг и не ищет владельца решения в момент сбоя.

Когда эти две очереди разделены, текущие обращения перестают съедать всё внимание. И у бизнеса появляется время защитить то, что действительно нельзя потерять.