🔥 Что на самом деле хотят услышать на 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-уровня.

https://uproger.com/samyj-populyarnyj-vopros-na-sobesedovaniyah-devops-kak-u-vas-ustroen-monitoring-v-proekte/