От бизнес-целей к техническим SLO и бюджетам: как задать «рамки реальности»
Любая катастрофоустойчивость начинается не с «репликации во все стороны», а с ясных бизнес-ограничений. Сформулируйте критичные сценарии (покупка, оплата, авторизация, сбор телеметрии, обработка заказов) и назначьте для каждого SLO — целевую доступность/латентность по 95–99.9-перцентилю. Далее переводим это в RTO (сколько сервис может быть недоступен) и RPO (какой объём данных допустимо потерять при аварии). Эти числа не вытаскивают из воздуха: они привязаны к реальным деньгам/штрафам/рискам и должны быть приняты владельцами продукта и финансов. После чего честно рисуем карту зависимостей: какие внутренние и внешние сервисы влияют на сценарий; какие «скрытые» зависимости есть у DNS, OAuth, платежных провайдеров, очередей, таймеров, сторонних SDK; какие лимиты облака/провайдера могут внезапно сработать (квоты, API throttling). Без этой карты разговоры про «пять девяток» — просто фольклор. На этом этапе вводим бюджет ошибок — измеряемую величину, которую нельзя «обмануть»: если бюджет сожран инцидентами/регрессиями, мы останавливаем масштабирование/релизы и вкладываемся в стабильность. Важно отделить SLA (юридическое обещание клиенту) от SLO (внутренняя инженерная цель): первое устанавливается консервативнее, чтобы PR-обещание не зависело от тонкой настройки. Подготовьте «паспорт сервиса» на один экран: владельцы, SLO, зависимые системы, RTO/RPO, окна регламентных работ, «красные линии» (что запрещено без созвона), контакты дежурных. И заведите единый словарь инцидентов: SEV-уровни, критерии эскалации, часовые пояса, каналы связи, шаблоны обновлений статуса. План без дисциплины — бумага; дисциплина без плана — героизм. Вам нужно и то и другое, причём записанное и повторяемое.
Архитектура устойчивости — это подбор конкретных паттернов под сценарии, а не «галочка». Для стейтлес-слоёв (API-шлюз, рендеринг, воркеры) разумны multi-AZ и горизонтальное масштабирование; для стейтфул-данных — другая математика: репликация (синхронная/асинхронная), кворум (Raft/Paxos-семейство), read replicas для разгрузки чтения, point-in-time бэкапы и журналы. Решение «active-active» по регионам красиво в презентациях, но даёт сложные компромиссы консистентности, стоимости и операционной сложности; во многих бизнесах active-passive с чётко отработанным фейловером даёт лучший итог по деньгам/риску. Отдельно проектируем состояния: очереди/шины (exactly-once редко реален, чаще — идемпотентность и дедупликация), кэши (горячие ключи и истечение TTL при фейловере), таймеры (reliable scheduler vs. «cron в поде»), файлы/объекты (версионирование, WORM-политики). Для DNS — двойной контур (провайдеры), низкие TTL для «фронтов», Route-health-check с гемлоками, отдельная стратегия на случай poisoning/compromise. Для секретов — независимый KMS/вторичный контур, планы по ротации при «похоронах» региона. Составьте «матрицу покрытий»: на каждый сценарий — от какого класса отказов вы защищены (AZ-фейл, сеть, сторедж, регрессия релиза, внешняя зависимость, лимиты облака), что будет при двойном отказе, какой «грациозный деградационный режим» у фронта (резервные страницы, отключаемые виджеты, упрощённые флоу). И не забудьте про backups: это не файлы на диске, а успешные восстановленные окружения. Еженедельно/ежемесячно проверяйте restore из «холодного» снапшота на изолированном стенде: метрики времени восстановления, целостность, побочные зависимости (ссылки, ключи, секреты). Пока вы не сделали реальный restore-drill, у вас нет бэкапов — у вас только надежда.
Эксплуатация — место, где хорошая архитектура выигрывает или проигрывает. Готовьте ранбуки на один экран для типовых бед: «падает регион», «застряла репликация», «сломался DNS», «регрессия релиза», «переполнены очереди», «квоты/лимиты», «компрометация ключей». В каждом — три блока: как распознать (симптомы/метрики/логи), что делать сразу (переключение/ограничение трафика/резервный контур), когда эскалировать и кому. Деплойте прогрессивно: канарейки 1–5% трафика, автоматические сторожа по SLO и бизнес-метрикам, быстрый откат, «килл-свитчи» для фич и зависимостей. Проводите game-days: отключение AZ, деградация базы, истечение сертификата, падение провайдера DNS — всё на тестовом/препроде с таймингом и постмортемом. Хаос-инжиниринг не о «хаосе», а о предсказуемости: вы тренируете мышцы команды и валидируете инструменты. Коммуникации — половина успеха: статус-страница, шаблоны обновлений, частота апдейтов, внутренний канал war-room, «спикер» для внешних клиентов. Постмортем — без поиска виноватых: хронология, корневая причина (техническая и организационная), что усилило ущерб, какие гвард-рейлы, алерты и тесты добавляем, кто владелец изменений и до какой даты. Параллельно держите проверку изменений инфраструктуры: «expand → migrate → contract» для схем, верхний предел одновременно изменяемых сервисов, запрет «тихих» правок в проде. И всегда считайте экономику: простой × средний чек × конверсия × сезонность; держите таблицу «стоимость минуты даунтайма» и сравнивайте её со стоимостью дублирования, дополнительного региона и 24×7 дежурств. Цель DR — не «бессмертие», а разумный баланс риска, стоимости и скорости восстановления. У кого этот баланс честнее и проверен практикой — тот выигрывает.