Software Architect · Модуль 15
Надёжная система не обещает, что ничего не сломается. Она ограничивает ущерб, быстро восстанавливается и честно показывает состояние.
SLO · error budget · graceful degradation · recovery
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 задержалась, пользовательская операция не должна зависнуть.
Надёжность проверяется не презентацией, а инцидентом или учением.
Пример: 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 у критичных данных? - Что продолжит работать при отказе зависимости? - Когда последний раз проверяли восстановление?