Что является критикал, а что нет

Критикал vs. Нон-критикал в DevOps: философия и практика

Разделение на критикал (critical) и нон-критикал (non-critical) — это не просто классификация задач или систем, это основа для построения устойчивых и эффективных процессов в DevOps. Это разделение определяет приоритеты реагирования, архитектурные решения, процессы разработки и уровень инвестиций.

Что является критикал (Critical)

Критикальные компоненты — это те, отказ которых напрямую и немедленно влияет на ключевые бизнес-процессы, доходы, безопасность или обязательное соблюдение регуляторных требований. Их неработоспособность приводит к существенным финансовым потерям или репутационному ущербу.

• Основные пользовательские сервисы (Core Services): Например, платежный шлюз для e-commerce, система авторизации, сервис обработки заказов.
• Критикальные данные и базы данных: Базы, хранящие финансовые транзакции, персональные данные пользователей (PII), конфигурацию продуктов.
• Инфраструктурные зависимости: Системы DNS, основные маршрутизаторы в сети, центральные брокеры сообщений (например, Kafka), если все микросервисы зависят от него.
• Системы безопасности: Системы управления доступом (IAM), мониторинг безопасности (SIEM) в режиме реального времени.
• Сервисы, обеспечивающие SLA (Service Level Agreement): Те, для которых есть жесткие договорные обязательства по доступности (например, 99.99%).

Для критикальных систем применяются максимальные стандарты:

# Пример декларации требований для критикального сервиса в Helm chart или конфиге
deployment:
  replicas: 3  # Минимум три реплики для отказоустойчивости
  strategy:
    type: RollingUpdate
    maxUnavailable: 0  # Не допускаем недоступности во время обновления
  resources:
    requests:
      cpu: "100m"
      memory: "128Mi"
    limits:
      cpu: "200m"
      memory: "256Mi"
  podDisruptionBudget:
    minAvailable: 2  # Гарантируем доступность хотя бы двух Pods

• Высокая отказоустойчивость: Multi-region/zone deployment, автоматическое восстановление (self-healing).
• Строгий мониторинг и алертование: Мониторинг не только метрик (CPU, память), но и бизнес-метрик (количество успешных транзакций). Алерты настроены на немедленное реагирование.
• Жесткий контроль изменений: Обязательные этапы проверки (peer review), автоматическое тестирование в CI/CD, поэтапное развертывание (canary releases, blue-green).
• Глубокое планирование восстановления: Детальные планы Disaster Recovery (DR), регулярные тесты восстановления, гарантированные RTO (Recovery Time Objective) и RPO (Recovery Point Objective).

Что является нон-критикал (Non-Critical)

Нон-критикальные компоненты — это сервисы, временная неработоспособность которых не вызывает значительного ущерба. Их функция может быть вспомогательной, периодической или их отказ может быть компенсирован.

• Вспомогательные сервисы: Системы внутренней аналитики, бэкенд для статических страниц (например, "About Us"), сервисы генерации отчетов по расписанию.
• Функции с graceful degradation: Если основная функция работает, но некоторые "улучшения" недоступны (например, система рекомендаций на сайте).
• Инфраструктура разработки: Внутренние инструменты для разработчиков, не влияющие на прод (например, временные тестовые среды).
• Кэширующие слои: Кэш второго уровня (L2 cache), отказ которого приводит лишь к временному увеличению нагрузки на основную базу данных.

Для нон-критикальных систем подход более гибкий и экономичный:

# Пример простой стратегии деплоя для нон-критикального сервиса
kubectl apply -f deployment.yaml
# Можно допустить более агрессивный update
# strategy:
#   type: RollingUpdate
#   maxUnavailable: 1  # Можно временно потерять одну реплику

• Умеренная отказоустойчивость: Достаточно реплик в одной зоне, возможно ручное восстановление.
• Уведомления вместо алертов: События могут фиксироваться в логах или отправляться в тикет-систему для разбора в рабочее время.
• Более быстрые циклы изменений: Меньше бюрократии в CI/CD, возможны прямые деплои в определенные среды.
• Базовые планы восстановления: Процессы восстановления могут быть описаны в общих чертах, RTO может быть несколько часов или дней.

Ключевой принцип: Контекст определяет критичность

Критикальность — динамическая характеристика. Сервис внутренней аналитики может стать критикальным, если его данные используются для регулируемых финансовых отчетов. Поэтому процесс классификации должен быть регулярным и учитывать:

• Бизнес-зависимости: Кто и как использует этот сервис?
• Архитектурные зависимости: Сколько других систем от него зависят?
• Регуляторные требования: Насколько его данные защищены законами?

Итог: Четкое разделение на критикал и нон-критикал позволяет оптимально распределить ресурсы, сфокусировать усилия команды на самых важных областях и строить инфраструктуру, которая одновременно является экономичной и надежной. Это фундамент для баланса между скоростью разработки (Velocity) и стабильностью операций (Stability).