🔥 Что на самом деле хотят услышать на DevOps собесе
На собеседованиях по DevOps очень любят спрашивать: "Как у вас устроен мониторинг в проекте?"
И многие отвечают слишком коротко:
Prometheus, Grafana, CloudWatch.
Ответ вроде правильный.
Но для сильного собеседования этого мало.
Интервьюеру обычно важно понять не просто названия инструментов, а всю цепочку:
- как собираются логи
- куда они попадают дальше
- как долго хранятся
- как собираются метрики
- как считается SLA
- и почему архитектура сделана именно так
Именно это показывает разницу между человеком, который просто пользовался готовым стеком, и тем, кто реально поднимал мониторинг в production.
Например, в enterprise-проекте на EKS мониторинг может выглядеть так:
Есть два типа нагрузок:
- микросервисы на Fargate
- stateful-приложение в StatefulSet
И подход к ним разный.
Для Fargate удобно использовать OpenTelemetry add-on.
Он автоматически собирает логи со всех Fargate-подов и отправляет их в CloudWatch. Это простой и удобный вариант, когда не хочется отдельно городить сбор логов внутри каждого сервиса.
Для StatefulSet чаще нужен более гибкий контроль.
Тут можно использовать Fluent Bit как sidecar-контейнер:
он читает логи из общего тома, фильтрует их, форматирует и отправляет в CloudWatch.
Это особенно важно в банках и других регулируемых системах, где есть требования к структуре логов, аудиту и хранению данных.
Дальше пайплайн может быть таким:
CloudWatch → Lambda для форматирования → Kinesis Firehose → OpenSearch
Зачем это нужно:
- Lambda может нормализовать и обогащать логи
- Firehose умеет батчить и стабильно доставлять данные
- OpenSearch удобен для поиска и анализа
- S3 подходит для долгого и дешёвого хранения
Пример хранения:
- 7 дней в OpenSearch
- 30 дней в CloudWatch
- полный архив в S3
С метриками история другая.
Обычно используют Prometheus, который ходит в /metrics каждого приложения, например каждые 30 секунд.
Чтобы Prometheus понимал, что именно скрейпить в Kubernetes, для сервисов настраивают ServiceMonitor.
Дальше Grafana показывает всё в дашбордах.
Хорошая практика - свести в Grafana сразу несколько источников:
- Prometheus для технических метрик
- CloudWatch для инфраструктуры и логов
- OpenSearch для поиска по событиям и ошибкам
Тогда в одном месте можно увидеть:
- CPU и memory
- latency и error rate
- логи по времени инцидента
- состояние сервиса по SLA
И вот тут начинается взрослая часть мониторинга.
SLA - это не абстрактная цифра на слайде.
Это конкретный лимит простоя.
Например, 99.1% uptime в месяц означает, что сервис может быть недоступен примерно 6.4 часа за месяц.
Если это вынесено в Grafana, то и команда, и бизнес видят состояние системы в реальном времени, а не узнают о проблеме постфактум.
Поэтому на собеседовании лучше рассказывать не просто набор инструментов, а целую историю:
не "у нас Prometheus и Grafana",
а "вот как у нас собираются логи, вот куда они идут, вот почему выбран именно такой маршрут, вот как мы храним данные, вот как считаем SLA и что видит бизнес".
Именно такой ответ звучит как опыт production-уровня.
