Отказоустойчивость сайта — какие сбои он должен переживать без остановки

Фраза «сайт должен быть отказоустойчивым» звучит убедительно, пока не нужно принять решение. Должен ли каталог открываться, если упала CRM? Можно ли принять заказ без онлайн-оплаты? Сколько новых данных компания готова потерять при аварии? Кто переключит трафик, если перестал отвечать основной сервер? Без этих ответов отказоустойчивость превращается либо в дорогую архитектуру «на всякий случай», либо в надежду на бэкап.

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

У одного сайта критичен путь «найти товар — оформить — оплатить». У другого — доступ клиента к документам, приём заявки на сервис или передача лида в CRM. Для медиа важнее выдача материалов, для B2B-портала — расчёт спецификации и личный кабинет. Нельзя назначить одинаковую степень защиты всем страницам и сервисам.

Соберите короткую карту критичных сценариев:

Эта карта не обещает, что любое действие можно безопасно выполнить офлайн. Она заставляет различать «страница открылась» и «бизнес-операция завершилась». Внешний мониторинг главной страницы не заметит ситуацию, когда форма выглядит рабочей, но данные не дошли до менеджера. Поэтому сценарий проверяют до конечного результата: от действия посетителя до записи в системе, уведомления и возможности обработать исключение.

Надёжность ломается не только от падения одного сервера. Полезно проверить классы отказов, которые по-разному требуют реакции.

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

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

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

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

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

Два показателя помогают убрать из обсуждения слово «быстро».

Это цели, а не характеристики тарифа. «RTO 30 минут» означает, что за полчаса должна быть восстановлена оговорённая способность работать: например, принимать заказы и не дублировать их. «RPO 5 минут» означает, что компания сознательно не готова терять данные старше пяти минут. Одна ночная копия редко соответствует такому RPO, но и синхронная репликация может быть неоправданна для редко меняемой витрины.

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

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

Их часто смешивают в одной фразе «у нас всё продублировано». Но это разные механизмы.

Failover — это переключение на резервный компонент. Оно бывает автоматическим и ручным. Автоматизация сокращает время реакции, но может переключать систему при ложном сигнале или распространять проблему на резерв. Ручное переключение медленнее, зато иногда безопаснее для редкого, но критичного процесса. Выбор зависит от RTO, понятности сигнала и способности команды действовать круглосуточно.

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

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

Например:

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

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

Так формируется SLI — измеримый показатель уровня сервиса. SLO задаёт его целевое значение и период. Начинать нужно с того, что важно пользователю, а затем выбирать измерение, а не назначать цель по тому, что уже удобно собирать в дашборде. Метрика «сайт доступен» полезна только если известно, какие ответы и для кого она считает доступными.

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

Резервный контур, который не включали, — это предположение. Проверку проводят контролируемо и по одному сценарию: остановить неосновной экземпляр, запретить ответ внешнего API в тестовом окружении, восстановить копию в изолированной среде, выполнить тестовую заявку после переключения. Цель — не устроить эффектную аварию, а подтвердить конкретное свойство.

После теста ответьте на четыре вопроса:

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