Я обсуждаю надёжность системы только после вопроса: сколько простоя бизнес действительно выдержит

Я обсуждаю надёжность системы только после одного неудобного вопроса: сколько простоя бизнес действительно выдержит? Не сервер, не база данных и не техническая команда — именно бизнес. Потому что «система должна работать всегда» звучит хорошо, но не помогает выбрать ни архитектуру, ни бюджет, ни порядок действий при сбое.

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

Надёжность начинается не с оборудования

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

Я предлагаю начинать с обычного рабочего дня. Берём одно действие и спрашиваем: что будет, если оно недоступно час? Кто это заметит? Можно ли временно продолжить работу иначе? Какие данные потом придётся сверять? Ответы обычно полезнее длинного списка технологий.

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

Три границы, о которых стоит договориться

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

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

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

Ручной режим — не признание поражения

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

Ручной режим надо проверить так же, как основной. Где лежит шаблон? Кто решает, что пора им пользоваться? Как избежать двойного ввода после восстановления? Кто сверяет данные? Пока на эти вопросы нет ответа, фраза «переживём» остаётся надеждой.

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

Не все ошибки требуют одинакового ответа

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

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

Как это влияет на архитектуру

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

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

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

Проверка до следующего сбоя

Вопросы стоит задавать в спокойный день, а не в момент аварии. Выберите один критичный сценарий и проведите короткую проверку: отключите безопасный тестовый компонент, пройдите ручной маршрут, восстановите данные на отдельном контуре, посмотрите, кто и как получает сообщение. Цель не в драме, а в том, чтобы найти пробелы, пока они дёшевы.

О восстановлении важно помнить отдельно: оно начинается с заранее понятного плана, а не с поиска действий во время сбоя. Практические шаги собраны в статье «Как составить план восстановления бизнес-системы после сбоя». А для начала полезно составить карту систем и их связей — это помогает увидеть, где один сбой останавливает несколько процессов; подробнее об этом — в материале «Зачем бизнесу карта IT-систем?».

Надёжность не обещает, что проблем не будет. Она делает последствия понятными, а действия — подготовленными. Мне гораздо ближе такая честная устойчивость, чем громкое обещание «работать без остановок».