Проектируем надежные системы — стоит ли игра свеч

Автор сразу разводит два термина. Availability — процент времени, когда система доступна пользователям; reliability — вероятность того, что система соответствует требуемому уровню производительности. Тут же оговорка: в отрасли эти слова используют вольно и часто как синонимы. Дальше идут три причины забывчивости: invisibility — надёжность, как и безопасность, по большей части невидима, пока всё идёт хорошо; assessment — добиваться идеальной надёжности непрактично, поэтому нужен риск-менеджмент и оценка стоимости негативных событий; evolution — система неизбежно усложняется по мере роста функциональности и масштаба.

Уровень риска предлагается выбирать не для компании целиком, а по классу приложения. Из white paper «Deployment Archetypes for Cloud Applications» берётся деление на business critical с прямым влиянием на бизнес и жёсткими требованиями к доступности и задержкам, line of business — поддерживающие процессы вроде ETL/ELT и пайплайнов CI/CD, где важна скорость выполнения, и internal applications вроде HR и офисной автоматизации. Автор оговаривается, что компании обычно дробят эту классификацию мельче под собственную стратегию SLA.

Определения взяты из книги Google по SRE. SLI — количественная мера аспекта предоставляемого сервиса: задержка, доля ошибок, пропускная способность, доступность. SLO — целевое значение или диапазон для SLI: либо «SLI не выше цели», либо коридор между нижней и верхней границей. SLA — контракт с пользователями, включающий последствия при невыполнении SLO. Признак различия простой: если у нарушения нет явных последствий, перед вами SLO, а не SLA.

Мониторинг делится на white-box, показывающий внутреннее состояние системы, и black-box, отражающий восприятие пользователем. В качестве готовых наборов метрик автор называет Four Golden Signals от Google и RED Method Тома Уилки. Обе схемы работают на ту же цель, ради которой заводились SLO: заметить нарушение обещания раньше, чем о нём сообщит пользователь.

Ключевых концепций надёжности четыре: fault domains — наборы компонентов, отказывающих как единая точка, отсюда репликация между зонами и регионами, балансировка и минимизация времени старта и остановки; шардирование приложений и данных между fault domains; инкрементальные откатываемые выкладки в production; управление зависимостями с учётом их доступности и моделей отказа. Отдельно разбираются данные: durability, доступность через асинхронную репликацию с eventual consistency или синхронную со strong и резервные копии. Цели RPO и RTO задают модель развёртывания, а доступность, добавленная задним числом, означает переделку архитектуры вплоть до полного переписывания.

Каталог паттернов дан со ссылкой на доклад Александра Кривощёкова из Yandex Go: retries только для идемпотентных запросов, с экспоненциальной задержкой и вероятностным выбором интервала; deadlines — таймауты на стороне клиента, согласованные по всей цепочке вызовов; rate limiting через token bucket, leaky bucket или sliding window counter; circuit breaker, отключающий запросы к сломанному провайдеру по порогу ошибок; rich client с оговоркой, что массовое его применение переусложняет систему; dummy как упрощённый аварийный режим. Замыкает раздел таблица архетипов: движение по ней вправо повышает и надёжность, и стоимость.