Отказоустойчивая система не стремится сделать отказ невозможным. Она стремится сделать его предсказуемым и ограниченным

Два сервера в одном rack. Две реплики в одной зоне. Основная и резервная БД с общей storage-зависимостью. Два канала, проходящие через один физический узел.

Формально резервирование есть.

Практически один отказ выключает всё.

AMPE строит redundancy вокруг независимых failure domains.

Автоматическое переключение выглядит надёжно на диаграмме.

Но важно понимать: как определяется отказ; кто принимает решение о переключении; нет ли split-brain; какое состояние потеряется; как система возвращается обратно.

Failover, который никогда не тестировался, остаётся предположением.

Когда недоступность системы напрямую влияет на бизнес.

Когда зависимые сервисы создают каскадные отказы.

Когда есть резерв, но нет уверенности, что он реально включится.

Когда один медленный downstream замедляет весь request path.

Когда техническая доступность высокая, но пользовательский результат нестабилен.

Когда нужно определить degraded mode.

Когда incident history показывает повторяющиеся failure patterns.

Без timeout ожидание может длиться дольше, чем имеет смысл для бизнеса.

Слишком короткий timeout создаёт ложные отказы.

Слишком длинный удерживает ресурсы и усиливает деградацию.

AMPE связывает timeout с latency budget всего запроса, а не выбирает случайную цифру на каждом сервисе.

Если зависимость уже нестабильна, продолжать слать в неё полный поток часто вредно.

Circuit breaker позволяет быстро прекратить бессмысленные попытки и дать downstream восстановиться.

Но у него должны быть понятные состояния, threshold и recovery logic.

Иначе защита сама становится источником нестабильности.

Недоступны рекомендации — каталог продолжает работать.

Не обновляется аналитика — транзакционный контур жив.

Нет внешнего enrichment — операция идёт с базовыми данными.

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

Процесс может отвечать /health 200 и не иметь связи с БД.

Или быть здоровым сам, но не готовым принимать трафик после старта.

Поэтому liveness, readiness и бизнес-готовность разделяются.

SLO определяет требуемую надёжность.

Failure model — возможные классы отказов. Architecture — containment boundaries. Timeouts, retries, breakers и bulkheads — поведение при частичных сбоях. Failover — восстановление критической функции. Observability — подтверждение фактического состояния.

Так надёжность проектируется заранее.

Один сбой реже распространяется на всю систему.

Резервирование соответствует реальным failure domains.

Failover становится проверяемым.

Degraded mode определяется до аварии.

Timeout и retry перестают усиливать проблему.

И главное — система получает предусмотренное поведение при отказе, а не надеется, что всё всегда будет доступно.