Цель и целевые метрики

SLA 99.99% означает очень низкий допустимый простой — нужно понимать RTO/RPO для сервисов и строить архитектуру исходя из них.

Небольшая точность по времени простоя (шаги вычислений — аккуратно):

• В году 365 дней → 365 × 24 × 60 = 525600 минут.
  Допустимая доля простоя = 1 − 0.9999 = 0.0001.
  525600 × 0.0001 = 525600 / 10000 = 52.56 минут в год.

• В среднем в месяце (год / 12): 525600 / 12 = 43800 минут → 43800 × 0.0001 = 4.38 минуты в месяц.

• В неделе (7 дней): 7 × 24 × 60 = 10080 минут → 10080 × 0.0001 = 1.008 минуты в неделю.

Эти цифры показывают, насколько мало времени вы можете терять — архитектура и оперирование должны быть нацелены на автоматические и быстро срабатывающие механизмы.

Архитектурные принципы

• Устранение Single Point of Failure на каждом уровне: сеть, compute, storage, DNS, авторизация.

• Разделение доменов отказа: минимум несколько Availability Zones; при высоких требованиях — multi-region.

• Избыточность и автоматический failover: все критичные компоненты — в active-passive или актив-актив конфигурации с автоматической детекцией здоровья и переключением.

• Стейт-менеджмент: приложениями — stateless; всё состояние — в распределённых управляемых сервисах (реплицируемые БД, объектное хранилище, кэш).

• Идемпотентность и retry-logic: операции должны быть идемпотентны, с экспоненциальным бэкоффом и circuit breaker’ами.

• Минимизация blast radius: микро-сегментация, отдельные сети/VPC per tier, лимиты запросов и rate limiting.

Конкретные компоненты и паттерны (что и как развернуть)

• Compute:

  • Горизонтальное масштабирование (autoscaling groups / managed instance groups / k8s HPA) распределённое по AZ; минимум 2 AZ, предпочтительно ≥3 для меньшего влияния потери одной AZ.

  • Rolling/blue-green/ canary deployments + connection draining.

• Load balancing & DNS:

  • Региональный L4/L7 балансировщик с health-checks по AZ.

  • Для глобальной устойчивости — глобальный LB / GSLB + health checks + low TTL для failover.

• Базы данных и хранение:

  • Для критичных данных — multi-AZ синхронная репликация или кворумные распределённые СУБД (в зависимости от требований к задержке/консистентности).

  • Сделать read-replicas для нагрузки чтения и гео-реплики для DR.

  • Регулярные бэкапы + point-in-time recovery; хранение бэкапов в другом регионе/аккаунте.

• Кэш и очереди: распределённые кэши с репликацией (failover), очереди с гарантией доставки и видимостью задач (чтобы перераспределить при падении воркера).

• Сеть: NAT/egress per AZ (чтобы не было единой точки), Transit gateway / hub-and-spoke, приватные endpoints к облачным сервисам.

• Config & Secrets: централизованный secret manager с KMS и контролем доступа, шифрование at-rest/in-transit.

• Observability: метрики, трассировка, логи, synthetic checks, alerting + dashboards; метрики health и SLO-ориентированные алерты (burn rate).

• Automation: IaC (модули), автоматические playbook’и для failover, runbooks и сценарии восстановления в коде.

Операционные практики

• SLO / Error budget: назначьте SLO для каждого сервиса и управляйте релизами в рамках бюджета ошибок.

• Health checks и failover time-target: health probe interval/minimum healthy threshold выставлять так, чтобы failover происходил в требуемые секунды/минуты; настроить grace/warmup для новых инстансов.

• Тестирование отказов: регулярные «game days» и chaos engineering (имитация падения AZ/регионов, отключение баз данных) — тренируйте процедуры и проверяйте runbooks.

• CI/CD: канареечные и phased deploys с автоматическим мониторингом метрик и быстрым rollback.

• Runbooks и RACI: документированные шаги восстановления, назначенные владельцы и контакты.

• Capacity planning: резерв мощности, стресс-тесты под пиковую нагрузку, мониторинг latencies и saturation.

• Monitoring & Alerting: оповещения по SLO-нарушениям + автоматический ремедиэйт для известных кейсов (скрипты, автоматические рестарты).

• Change management: small, reviewed changes; maintenance windows и уведомления; feature flags для выключения фич.

Баланс стоимости и надёжности

• Достижение 99.99% требует значительных резервирований и автоматизации — multi-AZ обычно достаточно для многих сервисов; multi-region добавляет стоимость и сложность, но снижает риск регионального outage.

• Комбинация: reserved capacity для базовой нагрузки + spot/preemptible для пиков (с контролем failover).

Метрики и контроль

• Отслеживайте: availability per endpoint, latency p95/p99, error rate, replication lag, queue depth, instance startup time.

• Установите target recovery times (RTO) для каждого класса сервиса и проверяйте реальные времена при тестах.

Что делать прямо сейчас (практический чек-лист)

• Определите SLO/SLA и error budgets для ключевых сервисов.

• Перенастройте критичные слои на multi-AZ с автоматическими health checks и авто-скейлингом.

• Внедрите автоматические failover для БД или managed multi-AZ DB.

• Добавьте synthetic checks и настройте alert → pager + runbook.

• Проведите первый «game day» (падение одной AZ) и зафиксируйте время восстановления и пробелы в процессах.