Например:
server ├── eth0 → switch01 └── eth1 → switch01
Интерфейса два. Switch всё ещё один. Или:
eth0 → switch01 eth1 → switch02
но bonding настроен неправильно и после отказа первого канала трафик реально не переключается. Поэтому:
дублирование
≠
работоспособный failover
6. Load balancer
Допустим:
┌── app01
users → LB ───┤
└── app02
Application layer зарезервирован.
LB — один.
Получаем явный SPOF.
Добавляем:
LB01 LB02
Но теперь спрашиваем: как клиент переключится с LB01 на LB02? Например, используется virtual IP:
VIP ↓ LB01 / LB02
Тогда проверяем уже механизм владения VIP. То есть высокая доступность — это не:
два load balancer
а:
один путь отказал
↓
рабочий путь реально принял нагрузку
7. DNS
DNS часто вообще забывают включить в схему отказоустойчивости. Сервис может иметь:
2 reverse proxy 3 application server 2 database node
но клиенты приходят по:
service.example.ru
Если единственный DNS resolver или authoritative DNS становится недоступен:
service physically works
↓
пользователь не может его найти
Поэтому DNS тоже часть пути предоставления сервиса.
8. База данных
Очень частая ситуация:
db01 → primary db02 → replica
На схеме уже написано: HA database. Но наличие replica ещё не отвечает на несколько вопросов:
- — насколько она отстаёт?
- — может ли она принять роль primary?
- — кто выполнит переключение?
- — приложение узнает новый адрес?
- — что произойдёт с незавершёнными транзакциями?
- — как исключается split-brain?
- — проверялся ли сценарий аварийного переключения?
Поэтому:
replica exists
≠
database failover works
Резервный компонент полезен только тогда, когда существует рабочий способ начать его использовать.
9. Кворум тоже может иметь зависимость
Для кластеров из нескольких узлов кажется логичным:
node01 node02 node03
Но нужно смотреть не только на сами узлы. Например, все три зависят от:
единой сети cluster communication
или:
одной системы хранения
или внешнего quorum/witness-компонента, который сам не зарезервирован. Количество узлов ещё не показывает реальную устойчивость архитектуры.
10. Authentication и IAM
Приложение может быть полностью работоспособно:
frontend → OK backend → OK database → OK
но логин выполняется через:
Keycloak
или:
FreeIPA / AD
Если identity provider недоступен:
новые пользователи
↓
не могут войти
Для бизнеса сервис фактически недоступен. IAM — такая же зависимость, как database или network.
11. Внешние сервисы
Особенно легко пропустить зависимости, которыми мы вообще не управляем. Например:
application ├── payment API ├── SMS provider ├── SMTP ├── external SSO └── public DNS
Внутренний кластер может быть идеально зарезервирован. Но если критичный бизнес-процесс зависит от одного внешнего API:
external API unavailable
↓
business operation unavailable
он является частью анализа отказоустойчивости.
12. Питание
На схеме инфраструктуры питание часто вообще отсутствует. Но:
server01 ─┐
├── PDU01
server02 ─┘
снова создаёт общий домен отказа. У серверов могут быть даже два блока питания:
PSU1 ─┐
├── PDU01
PSU2 ─┘
Формально PSU два. Практически один PDU выключает оба. Правильнее:
PSU1 → PDU01 → UPS01 PSU2 → PDU02 → UPS02
если такой уровень отказоустойчивости действительно требуется.
13. Backup не устраняет SPOF работающей системы
Это отдельная важная граница. Допустим, database единственная:
db01
но у неё есть хороший backup. Это не делает database высокодоступной. Backup отвечает на другой вопрос: можем ли мы восстановить данные после отказа? HA отвечает: сможет ли сервис продолжить работу при отказе? То есть:
backup
≠
redundancy
Но backup уменьшает последствия отказа, поэтому он является частью общей стратегии надёжности.