← [Раздел](README.md) · [Главная](../README.md)

# Отказоустойчивость

## Цель

Научиться находить **единые точки отказа (SPOF)**, понимать уровни избыточности в облаке (зона, регион, экземпляр) и выбирать архитектурные меры для повышения доступности без лишней сложности.

## Предварительно

- [README раздела 07](README.md)
- Понимание: виртуальная машина, контейнер, балансировщик нагрузки (обзорно)

## Время

~60 минут чтения + 30 минут на схему своего проекта

---

## Что такое отказоустойчивость

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

Пример из жизни: в самолёте два двигателя. Один заглох — второй довозит. В ПО то же: два экземпляра API за балансировщиком.

**Важно:** отказоустойчивость ≠ «никогда не падает». Это **контролируемая деградация**: часть функций может отключиться, но критичный путь пользователя сохраняется.

---

## Single Point of Failure (SPOF)

**SPOF** — компонент, отказ которого останавливает всю систему или критичную функцию.

| Компонент | SPOF? | Типичное решение |
|-----------|-------|------------------|
| Один pod API без реплик | Да | `replicas: 2+`, PodDisruptionBudget |
| Managed PostgreSQL с HA | Частично | Multi-AZ, автоматический failover |
| Redis без реплики | Да | Primary + replica, Sentinel/Cluster |
| DNS только у одного провайдера | Да | Secondary DNS, health checks |
| Разработчик с root-доступом | «Человеческий SPOF» | RBAC, break-glass процедуры |

Упражнение: пройдитесь по C4 Container diagram и спросите «что сломается, если этот блок исчезнет?».

---

## Уровни избыточности в облаке

```mermaid
flowchart TB
  subgraph region["Регион (например eu-central-1)"]
    subgraph azA["Зона A"]
      AppA[App pod]
      DBA[(DB primary)]
    end
    subgraph azB["Зона B"]
      AppB[App pod]
      DBB[(DB standby)]
    end
    LB[Load Balancer]
  end
  LB --> AppA
  LB --> AppB
  DBA -.->|репликация| DBB
```

| Уровень | Что защищает | Типичная цена |
|---------|--------------|---------------|
| **Несколько экземпляров в одной зоне** | Падение процесса / pod | Низкая |
| **Multi-AZ (несколько зон)** | Пожар в дата-центре, сбой зоны | Средняя |
| **Multi-region** | Региональный outage | Высокая (латентность, данные) |

Начинайте с **multi-instance + multi-AZ** для stateless-сервисов. Multi-region — когда бизнес явно требует (финтех, глобальный SLA).

---

## Stateless vs Stateful

| Тип | Поведение при сбое | Паттерн |
|-----|-------------------|---------|
| **Stateless** (API без сессии на диске) | Новый экземпляр подхватывает запрос | Горизонтальное масштабирование |
| **Stateful** (БД, очередь, файловое хранилище) | Нужна репликация и выбор лидера | Primary/replica, кворум |

Правило: **выносите состояние из приложения**. Сессии — в Redis; файлы — в object storage (S3-совместимое), не на локальный диск pod.

---

## Health checks и готовность

Балансировщик и оркестратор (Kubernetes) должны знать, «жив» ли экземпляр.

| Проверка | Вопрос | Пример |
|----------|--------|--------|
| **Liveness** | Процесс завис? | HTTP `/health/live` → restart pod |
| **Readiness** | Можно ли слать трафик? | БД недоступна → убрать из LB |
| **Startup** | Долгий старт? | Не убивать pod при миграциях |

Плохой health check: всегда `200 OK` без проверки зависимостей — трафик идёт на «мертвый» сервис.

---

## Graceful shutdown

При выкатке новой версии старый экземпляр должен:

1. Перестать принимать новые запросы (readiness = false).
2. Дождаться завершения текущих (drain, timeout 30–60 с).
3. Закрыть соединения к БД и выйти.

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

---

## Деградация функций

Не всё должно работать при аварии. Заранее определите **уровни деградации**:

| Уровень | Поведение |
|---------|-----------|
| Полный | Все функции |
| Деградация | Каталог работает, рекомендации отключены |
| Минимум | Только просмотр заказа, оплата недоступна |
| Maintenance | Статическая страница |

Feature flags и fallback-ответы («рекомендации временно недоступны») лучше, чем белый экран 500.

---

## Метрики доступности (введение)

**Доступность** часто выражают в «девятках»:

| SLA | Допустимый downtime в год |
|-----|---------------------------|
| 99% | ~3.65 дня |
| 99.9% | ~8.76 часов |
| 99.95% | ~4.38 часов |
| 99.99% | ~52.6 минут |

Подробнее про SLO — в [разделе 08](../08-observability/metriki-i-slo.md).

---

## Самопроверка

1. Назовите три примера SPOF в типичном веб-приложении.
2. Чем отличается liveness от readiness?
3. Зачем выносить сессии из памяти приложения?
4. Когда multi-region оправдан, а когда — избыточен?

---

## Дальше

→ [Резервирование и DR](rezervirovanie-i-dr.md)  
← [README раздела 07](README.md)