# 15. Надёжность

Как думать про SLO, error budget, graceful degradation, incident response, recovery и устойчивость системы к отказам.

- **Author:** Фёдор Чищин
- **Level:** advanced
- **Reading time:** ~25 минут чтения
- **Published:** 2026-05-23
- **Source:** https://fedorthinks.com/ru/learn/software-architect-15-reliability

---

## 1. Главная идея

Reliability — это управляемое качество сервиса с понятными целями, а не надежда на хороший код.

### SLO переводит надёжность в язык продукта

> «Поезд должен ходить хорошо» невозможно проверить. «99% поездов приходят с задержкой меньше пяти минут» уже можно измерить.

SLA — обещание клиенту. SLO — внутренняя цель. SLI — измеряемый индикатор: availability, latency, error rate, freshness. Error budget показывает, сколько ошибок допустимо за период.

Архитектор использует SLO, чтобы выбирать trade-offs: если error budget горит, команда снижает риск релизов; если бюджет большой, можно быстрее экспериментировать.

### Отказ должен быть ожидаемым сценарием

> План эвакуации нужен не потому, что пожар желателен, а потому что он возможен.

Надёжность проектируется через timeouts, retries, bulkheads, rate limits, circuit breakers, backups, restore drills, health checks, runbooks и incident response. Важны не только prevention, но и detection, mitigation, recovery.

Система должна деградировать управляемо: если recommendation engine упал, checkout должен работать; если analytics задержалась, пользовательская операция не должна зависнуть.

## 2. Пример и антипример

Надёжность проверяется не презентацией, а инцидентом или учением.

### Пример: graceful degradation поиска

> Если электронное табло в аэропорту погасло, сотрудники всё равно должны иметь резервный список рейсов.

Search service недоступен. Product page продолжает открываться, каталог показывает fallback по популярным товарам, UI честно сообщает, что поиск временно ограничен. Alert уходит on-call, runbook описывает проверку индекса и rollback.

Пользователь видит ухудшение функции, а не полный отказ продукта.

### Антипример: backup без restore

> Запасной ключ бесполезен, если никто не знает, от какой он двери.

Команда говорит, что backup настроен. Но restore никогда не проверяли, RPO и RTO неизвестны, доступ к backup есть только у одного человека, а схема восстановления не документирована.

Backup — это только половина reliability. Настоящая гарантия появляется после успешного restore drill.

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

- Какие SLI действительно отражают пользовательский опыт?
- Какой RPO и RTO у критичных данных?
- Что продолжит работать при отказе зависимости?
- Когда последний раз проверяли восстановление?

Следующий модуль: [Безопасность](./software-architect-16-security).