Есть ещё человеческие SPOF

Например:

единственный инженер
        ↓
знает пароль
        ↓
знает процедуру recovery
        ↓
понимает архитектуру

Если этот человек недоступен, организация может технически иметь резервные серверы, но не иметь возможности ими воспользоваться.

То же относится к:

• — единственному administrator account;
• — единственному аппаратному токену;
• — одному месту хранения ключа;
• — undocumented procedure;
• — единственному человеку с доступом к провайдеру.

Это уже не аппаратный SPOF.

Но для эксплуатации результат тот же.

15. Как практически искать SPOF

Я бы начинал не со списка оборудования, а с сервиса.

Например:

пользователи должны открыть приложение и выполнить операцию.

Строим путь:

user
↓
DNS
↓
network
↓
firewall
↓
load balancer
↓
application
↓
database
↓
storage
↓
external services

И для каждого блока задаём вопросы.

Вопрос №1

Что произойдёт при полном отказе этого компонента?

Если:

service stops

идём дальше.

Вопрос №2

Есть ли альтернативный компонент?

Например:

app02

Если нет — SPOF найден.

Если есть — этого пока недостаточно.

Вопрос №3

Независим ли резервный компонент от той же причины отказа?

Проверяем:

power
network
storage
hypervisor
rack
site
DNS
management

Если оба экземпляра зависят от одного ресурса — независимости нет.

Вопрос №4

Как происходит переключение?

Например:

автоматически

или:

вручную по инструкции

или:

«мы знаем, что вроде можно»

Последний вариант техническим механизмом отказоустойчивости не является.

Вопрос №5

Проверялось ли переключение?

Это самый неприятный, но полезный вопрос.

Архитектура может выглядеть идеально:

primary
+
standby
+
replication
+
VIP

Но если никто никогда не выполнял:

primary FAIL
        ↓
standby becomes active
        ↓
client reconnects
        ↓
service continues

у нас есть проектное предположение, а не подтверждённое поведение.

16. Простая матрица SPOF

Для каждого критичного компонента можно составить таблицу:

Компонент:
Database

Отказ:
db01 полностью недоступна

Влияние:
приложение не работает

Резерв:
db02

Общая зависимость:
одна СХД

Переключение:
ручное

Проверялось:
нет

И сразу становится видно: резервная база есть, но архитектура всё ещё содержит риски.

17. Не каждый SPOF обязательно нужно устранять

Это тоже важно.

Абсолютно отказоустойчивую систему построить невозможно.

Можно зарезервировать:

server
storage
network
power
site

а затем обнаружить:

region outage

Можно добавить вторую площадку.

А потом:

общий облачный provider

И так практически бесконечно.

Поэтому вопрос должен быть не:

«Есть ли вообще SPOF?»

а:

«Какие отказы мы обязаны переживать согласно требованиям к сервису?»

18. SPOF нужно связывать с RTO и RPO

Например, бизнес говорит:

допустимый простой:
4 часа

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

Для другого сервиса:

допустимый простой:
30 секунд

тот же подход уже не подходит.

RTO — максимально допустимое время восстановления сервиса.

RPO — максимально допустимая потеря данных по времени.

Поэтому архитектура отказоустойчивости должна вытекать из требований:

бизнес-требования
        ↓
RTO / RPO
        ↓
допустимые сценарии отказа
        ↓
архитектура

А не наоборот.

19. Как выглядит хороший анализ

Не так:

2 servers → OK
2 switches → OK
2 databases → OK

А так:

Сценарий:
отказ hypervisor01

Результат:
сервис продолжает работать

Сценарий:
отказ switch01

Результат:
сервис продолжает работать

Сценарий:
отказ storage01

Результат:
сервис останавливается

Вот в последнем сценарии и появляется реальный архитектурный вывод.