← [Главная](../README.md)

# 07 — Надёжность

## Цель

Понять, как проектировать **надёжные облачные приложения**: что такое отказоустойчивость, резервирование, аварийное восстановление (DR), и как паттерны retry и circuit breaker защищают систему от каскадных сбоев.

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

- Пройдены разделы **00–06** курса (архитектура, API, данные, безопасность).
- Базовое понимание: сервер, база данных, сеть, HTTP.
- Учебный проект или мысленный пример «интернет-магазин».

## Время

**6–10 часов** (теория + мини-упражнения на бумаге)

---

## Зачем этот раздел

Облачное приложение редко «падает целиком» из-за одной ошибки в коде. Чаще пользователь страдает из-за:

- недоступности одного микросервиса;
- перегрузки базы данных;
- сетевого таймаута между зонами;
- отсутствия плана восстановления после аварии.

**Надёжность** — это способность системы продолжать работу (или быстро восстанавливаться) при сбоях. Это не «магия DevOps», а **архитектурные решения**, которые закладывают на этапе проектирования.

---

## Ключевые понятия

| Термин | Простыми словами |
|--------|------------------|
| **Availability (доступность)** | Доля времени, когда сервис отвечает пользователю |
| **Fault tolerance** | Система переживает отказ компонента без полной остановки |
| **Resilience** | Умение «гнуться» под нагрузкой и сбоями, не ломаясь |
| **RTO** | За сколько часов восстановить сервис после катастрофы |
| **RPO** | Сколько данных можно потерять (окно бэкапа) |
| **SLA / SLO** | Обещание и внутренняя цель по доступности (раздел 08) |

---

## Оглавление раздела

| Страница | Содержание |
|----------|------------|
| [otkazoustojchivost.md](otkazoustojchivost.md) | Уровни отказоустойчивости, SPOF, зоны доступности |
| [rezervirovanie-i-dr.md](rezervirovanie-i-dr.md) | Реплики, бэкапы, DR-планы, active-passive vs active-active |
| [circuit-breaker-i-retry.md](circuit-breaker-i-retry.md) | Повторы запросов, предохранитель, идемпотентность |

---

## Ментальная модель

```text
Пользователь → Балансировщик → [Экземпляр A] [Экземпляр B]
                                    ↓              ↓
                              Реплика БД ←→ Реплика БД (standby)
```

Если **Экземпляр A** упал, балансировщик направляет трафик на **B**. Если упала **вся зона** — нужен DR в другом регионе (см. rezervirovanie-i-dr.md).

---

## Типичные ошибки новичков

| Ошибка | Почему плохо | Что делать |
|--------|--------------|------------|
| Один сервер «на всё» | Single Point of Failure | Минимум 2 экземпляра за LB |
| Retry без лимита | Усугубляет перегрузку | Exponential backoff + jitter |
| «Бэкап есть» без проверки | Восстановление не работает | Регулярные restore-тесты |
| DR только на бумаге | В кризисе никто не знает шаги | Runbook + учения раз в квартал |

---

## Практика на 15 минут

Возьмите учебный сервис «каталог товаров». Нарисуйте на листе:

1. Все компоненты (API, БД, кэш, очередь).
2. Отметьте **SPOF** (single point of failure) красным.
3. Для каждого SPOF запишите одно улучшение.

---

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

1. Чем отличается fault tolerance от resilience?
2. Что такое SPOF и приведите пример из веб-приложения.
3. Зачем нужны RTO и RPO при планировании DR?
4. Почему «просто добавить ещё один сервер» не всегда решает проблему?

---

## Дальше

→ [Отказоустойчивость](otkazoustojchivost.md)  
← [Главная](../README.md)