Проектируем надежные системы

Отправная точка — разделение availability, процента времени, когда система доступна пользователям, и reliability, вероятности соответствовать требуемому уровню производительности; автор признаёт, что на практике термины путают. Про надёжность забывают из-за невидимости (пока всё работает, её как будто нет), из-за оценки — совершенная надёжность непрактична, поэтому нужен риск-менеджмент и понимание стоимости негативных событий, — и из-за эволюции: усложнение системы превращает мелкие изменения в крупные сбои.

Дальше риск переводят в измеримое. Приложения делят на business critical, line of business (ETL/ELT, пайплайны CI/CD) и internal вроде HR-систем, а обещание фиксируют через SLI как количественную меру аспекта сервиса, SLO как целевое значение или диапазон и SLA как контракт с последствиями. Если последствий нет, это по-прежнему SLO. Наблюдают за этим white-box и black-box мониторингом с готовыми наборами метрик — Four Golden Signals и RED Method.

Проектная часть держится на четырёх концепциях: fault domains и репликация между зонами и регионами, шардирование приложений и данных, инкрементальные откатываемые выкладки и управление зависимостями. К этому добавляются durability, доступность данных через синхронную или асинхронную репликацию и резервные копии, а цели RPO и RTO прямо определяют модель развёртывания. Отдельно подчёркнуто, что доступность, добавленная как функция задним числом, может потребовать переделки архитектуры или полного переписывания.

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

Эксплуатационная часть опирается на книгу «Accelerate» и четыре метрики DORA: время поставки и частоту выкладок для темпа, среднее время восстановления и долю неудачных изменений для стабильности. Их поддерживает внутренняя платформа разработки — в Tinkoff это Spirit: пайплайны с тест-менеджментом на Allure, quality gate, нагрузочным Cosmos и фитнес-функциями на Danger, слой XaaS с управляемыми Kubernetes, Postgres, Kafka, Cassandra и S3, а также Sage (наблюдаемость, доступная и внешним пользователям), SLAser для отслеживания SLA и OMG для управления инцидентами. Ролей тут так много, что автор пишет «Dev…Sec…Data…WTF…Ops» и вспоминает pipeline-driven organisation Роя Ошерова.

Культурный блок начинается с исследования Google Project Aristotle: 180 команд, из них 115 инженерных и 65 из продаж, размером от 3 до 50 человек, 250 утверждений из опроса вовлечённости и сотни двойных слепых интервью. Пять факторов успеха по убыванию — психологическая безопасность, надёжность, структура и ясность, смысл работы и её влияние; размер команды значимым не оказался, хотя другие исследования говорят о преимуществе команд меньше десяти человек. Дальше идёт типология Рона Веструма 2004 года: патологическая культура ищет виноватого, бюрократическая — справедливости, генеративная — системную проблему, причём сам Веструм оговаривается, что это корреляция, а не причинность. Замыкает всё культура постмортемов из практики Google SRE.