# NFR и SLA

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

## Цель

Формулировать **нефункциональные требования (NFR)** и понимать **SLA**, **SLO**, **SLI** — язык договорённостей о качестве облачного сервиса.

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

- [Сбор требований](sbor-trebovanij.md)

## Время

**3–4 часа**

---

## Почему NFR важны для архитектуры

**FR:** «Пользователь создаёт список».  
**NFR:** «Создание списка при 1000 RPS не деградирует сильнее чем на 10%».

Без NFR нельзя обосновать Redis, три реплики API или multi-AZ базу — только «модно».

---

## Категории NFR

| Категория | Примеры метрик |
|-----------|----------------|
| **Производительность** | Latency p50/p95/p99, throughput RPS |
| **Масштабируемость** | Линейный рост до N пользователей |
| **Доступность** | Uptime 99.9% |
| **Надёжность** | RPO, RTO при disaster |
| **Безопасность** | Шифрование, аудит, OWASP |
| **Сопровождаемость** | Время деплоя < 15 мин |
| **Совместимость** | API v1 поддерживается 12 мес |
| **Стоимость** | Cost per active user < $0.10/мес |

---

## SLI, SLO, SLA — цепочка

| Термин | Определение |
|--------|-------------|
| **SLI** (Indicator) | Измеряемая величина: «доля успешных запросов» |
| **SLO** (Objective) | Внутренняя цель: «99.95% успешных за 30 дней» |
| **SLA** (Agreement) | Договор с клиентом: нарушение → компенсация |

```mermaid
flowchart LR
  SLI[SLI метрика] --> SLO[SLO цель]
  SLO --> SLA[SLA договор]
  Monitor[Мониторинг] --> SLI
```

Пример SLI: `(2xx + 3xx) / total` для API `POST /items`.

---

## Доступность: «девятки»

| SLA | Простой в год (ориентир) |
|-----|--------------------------|
| 99% | ~3.65 дня |
| 99.9% | ~8.76 часа |
| 99.95% | ~4.38 часа |
| 99.99% | ~52.6 минуты |

**99.9%** для MVP часто достаточно; **99.99%** требует redundancy, multi-AZ, зрелый on-call.

---

## Latency

| Термин | Смысл |
|--------|-------|
| p50 | Половина запросов быстрее |
| p95 | 95% быстрее — типичная цель UX |
| p99 | Хвост, важен для платежей |

NFR пример: «p95 GET /lists < 200 ms при 500 RPS в одном регионе».

---

## RPO и RTO (disaster recovery)

| Метрика | Вопрос |
|---------|--------|
| **RPO** (Recovery Point Objective) | Сколько данных можно **потерять** по времени? |
| **RTO** (Recovery Time Objective) | За сколько **поднять** сервис после катастрофы? |

| Уровень | RPO | RTO | Архитектура |
|---------|-----|-----|-------------|
| Учебный MVP | 24 ч | 4 ч | Ежедневный бэкап |
| Продукт | 1 ч | 30 мин | PITR + реплика |
| Критичный | ~0 | минуты | Multi-region active-active |

---

## Пример набора NFR для «Умного списка»

| ID | NFR |
|----|-----|
| NFR-P1 | p95 API read < 250 ms, write < 400 ms |
| NFR-A1 | Доступность 99.5% / месяц |
| NFR-S1 | Данные в транзите: TLS 1.2+ |
| NFR-S2 | Пароли: bcrypt cost ≥ 12 |
| NFR-D1 | RPO 1 ч, RTO 2 ч |
| NFR-C1 | Инфраструктура ≤ $200/мес до 10k MAU |

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

---

## Бюджет ошибок (error budget)

Если SLO = 99.9%, «бюджет» простоя ≈ 43 мин/мес. Пока в бюджете — можно рисковать релизами; исчерпан — freeze фич, стабилизация.

Связь Dev и Ops в SRE-культуре ([раздел 07](../07-nadezhnost/README.md)).

---

## NFR и выбор компонентов

| NFR | Архитектурный ответ |
|-----|---------------------|
| 10k RPS read | Кэш + read replicas |
| Глобальные пользователи | CDN + региональный API |
| Строгий аудит | Append-only log, WORM storage |
| Быстрый MVP | PaaS, managed DB |

---

## Документирование NFR

Таблица в `docs/nfr.md` + ссылка из ADR. При изменении SLO — **версия** и дата, иначе споры «мы обещали 99.99 или нет».

---

## Практика

1. Посчитайте допустимый простой для 99.5% в месяц (30 дней).  
2. Задайте SLO для учебного API (availability + latency).  
3. Свяжите NFR-A1 с минимальной инфраструктурой (single AZ vs multi).

---

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

1. Чем SLO отличается от SLA?  
2. Что такое p95 одним предложением?  
3. RPO = 1 час — что значит при пожаре в DC?

---

## Дальше

→ [C4-модель](c4-model.md)