Что является критичным, а что нет в контексте DevOps?

«Что является критичным, а что нет в контексте DevOps?» — вопрос из категории Софт-скиллы, который задают на 23% собеседований Devops Инженер. Ниже — развёрнутый пример ответа, который можно адаптировать под свой опыт.

Ответ

В моей работе DevOps-инженера классификация на критичное и некритичное основана на влиянии на бизнес-процессы и пользователей.

Критичные (Critical) компоненты:

  • Базовые сервисы инфраструктуры: DNS, шлюзы, балансировщики нагрузки (Nginx, HAProxy), кластеры баз данных (PostgreSQL, Redis в режиме primary). Их отказ приводит к недоступности всего приложения.
  • Ключевые бизнес-сервисы: Платежный шлюз, сервис аутентификации, основной API бэкенда.
  • Системы координации: Consul, etcd или мастер-ноды Kubernetes. Без них перестает работать оркестрация.

Некритичные (Non-Critical) компоненты:

  • Вспомогательные системы: Сервисы мониторинга (Grafana, Alertmanager), агрегаторы логов (Loki, Elasticsearch для логов), тестовые среды. Их временная деградация допустима.
  • Улучшающие компоненты: Кэширующие слои (Redis для кэша, CDN), фоновые воркеры для обработки не срочных задач (отправка email, генерация отчетов).
  • Реплики данных: Реплики БД для чтения, резервные инстансы приложений.

Пример из практики: В одном из проектов мы определяли приоритеты для алертов в Prometheus. Алерт на недоступность балансировщика имел наивысший приоритет (P0) и вел к немедленному пейджингу, в то время как алерт на высокую загрузку ЦП в сервисе аналитики был P3 и обрабатывался в рабочее время.