10 вопросов о наблюдаемости Kubernetes, которые задают на каждом собеседовании в DevOps.

Вопросы о наблюдаемости Kubernetes, от которых зависит ваш успех или провал на следующем собеседовании по DevOps.

Я провёл собеседования с более чем 150 кандидатами на должность DevOps за последний год. И тема, на которой я больше всего сосредотачиваюсь, — наблюдаемость.

Когда я спрашиваю: «Расскажите мне о вашей архитектуре логирования», я обычно получаю в ответ либо пустые взгляды, либо расплывчатые ответы вроде «использую Prometheus и Grafana». Но этого уже недостаточно.

Компании ищут не просто людей, знающих названия инструментов. Им нужны инженеры, которые понимают, как на самом деле работают производственные системы. Как происходит обмен логами. Как собираются метрики. Как оповещения доходят до нужных людей в 3 часа ночи.

Поэтому я делюсь теми самыми вопросами, которые задаю, вместе с ответами, которые отличают младших специалистов от старших.

Расскажите, пожалуйста, о вашей текущей архитектуре логирования. Как вы собираете и храните логи в своей среде Kubernetes?

Вот как должен звучать хороший ответ:

Мы используем паттерн сайдкара. Основной контейнер пишет логи в общий том. Sidecar Fluentd считывает эти логи и отправляет их в CloudWatch. Оттуда логи проходят через Kinesis Firehose в OpenSearch для быстрых запросов. Мы храним 7 дней в OpenSearch, 30 дней в CloudWatch и архивируем все в S3 для соответствия требованиям.

Почему этот ответ работает: он показывает, что вы понимаете весь поток данных, а не только отдельные инструменты. Вы знаете, зачем нужен каждый компонент и как долго следует хранить данные на каждом этапе.

Что делает этот ответ неработоспособным: утверждение «мы используем Fluentd» без объяснения архитектуры. Или, что еще хуже, незнание того, куда на самом деле попадают ваши логи.

Я вижу, вы используете OpenSearch. Почему бы просто не хранить все данные в CloudWatch? Разве это не проще?

Этот вопрос проверяет ваше понимание компромиссов, а не только используемых инструментов.

CloudWatch становится дорогим и медленным при обработке петабайтов данных. OpenSearch создан для высокоскоростных запросов к огромным массивам данных. Для небольшого стартапа CloudWatch вполне подойдет. Но в больших масштабах OpenSearch необходим для анализа в реальном времени, и он обходится дешевле при частых запросах.

Почему это важно: боевые системы генерируют тонны логов. Вам нужно быстро запрашивать их, когда что-то ломается. CloudWatch для этого не предназначен. А вот OpenSearch — предназначен.

Тревожный ответ: «Потому что все используют OpenSearch» или «В моей предыдущей компании его использовали». Это говорит о том, что вы не принимаете архитектурные решения, а просто копируете то, что делают другие.

Вопрос 3: Можете объяснить разницу между логами и метриками? Когда следует использовать каждый из них?

Большинство людей считают, что это одно и то же. Это не так.

Правильный ответ:

Логи событий похожи на дневник. В них записывается всё, что произошло. Пользователь вошёл в систему из Индии. API выдал ошибку 500. Платеж не удался при оформлении заказа.

Метрики — как монитор состояния. Они измеряют, как всё работает. CPU на уровне 80 %. Время ответа — 250 мс. Приложение работает 99,5 % времени.

Подумайте об этом так:

Логи = что произошло, Метрики = насколько хорошо работает

Вот почему вам нужны оба в продакшене:

Ваш API внезапно стал работать медленно. Метрики показывают, что проблема существует. Латентность выросла со 100 мс до 5 секунд. Что-то не так.

Но метрики не говорят вам, ПОЧЕМУ это происходит медленно. Вот тут-то и пригодятся логи. Вы проверяете логи и обнаруживаете, что один конкретный запрос к базе данных выдал ошибку тайм-аута.

Метрики говорят вам, что есть пожар. Логи говорят вам, где он начался и что горит.

Невозможно устранить проблемы, используя только один из методов. Вам нужны оба.

Я вижу Prometheus и Grafana в вашем наборе инструментов. В чём разница? Зачем вам оба?

Это сбивает с толку многих людей, потому что, видя, как эти инструменты используются вместе, они предполагают, что делают одно и то же.

Prometheus собирает и временно хранит метрики, обычно 10–15 дней. Он сканирует конечные точки вашего приложения каждые 15–30 секунд. Grafana просто визуализирует данные. Она делает некрасивые цифры красивыми. Представьте Prometheus как сборщик данных, а Grafana — как слой их визуализации.

Вот в чём большинство людей ошибаются: Prometheus НЕ хранит долговременные данные. Если вам нужны исторические метрики за период более нескольких недель, вам потребуется что-то другое. Именно поэтому в боевых системах часто добавляют Thanos или Cortex для долговременного хранения данных.

В вашем соглашении об уровне обслуживания (SLA) клиентам гарантируется 99,5% времени бесперебойной работы. Что это на самом деле означает с точки зрения допустимого времени простоя?

Я задаю этот вопрос, чтобы проверить, понимают ли кандидаты влияние своей работы на бизнес, а не только техническую сторону вопроса.

В 30-дневном месяце у вас есть 2 592 000 секунд. 99,5% времени безотказной работы означает, что допустимый простой составляет 0,5%. Это 12 960 секунд, или максимум около 3,6 часов в месяц. Мы отслеживаем это в режиме реального времени, и клиенты могут видеть фактическое время безотказной работы на панелях мониторинга.

Почему это важно: DevOps — это не просто поддержание работоспособности систем. Это выполнение обязательств перед бизнесом. Если вы не можете перевести технические показатели в бизнес-результаты, вы упускаете половину картины.

Как вы аутентифицируете Grafana для получения данных из CloudWatch? Расскажите подробнее о вашем подходе к обеспечению безопасности.

Именно здесь я выявляю людей, которые просто следуют инструкциям, не понимая принципов безопасности.

Никогда не используем ключи доступа. Мы создаём роль IAM с правами чтения CloudWatch, а затем сопоставляем её с сервисной учётной записью пода Grafana с помощью OIDC. Тот же паттерн, что и у AWS Load Balancer Controller. Под автоматически получает эту роль. Никакие учётные данные не хранятся в коде.

Тревожный сигнал: если кто-то упоминает о жестком кодировании учетных данных AWS или их хранении в ConfigMaps, собеседование практически закончено. Это потенциальный инцидент, связанный с безопасностью боевой среды.

Какой интервал скрапинга вы используете для Prometheus и почему выбрали именно его?

Это проверяет соответствие практических знаний теоретическим.

Наш стандарт — 15–30 секунд. Меньшее значение нежелательно, так как это приведет к перегрузке системы запросами. Мы настраиваем путь endpoint’а, обычно /metrics, частоту сбора данных и время хранения в манифесте ServiceMonitor.

В продолжение я всегда спрашиваю: «Что произойдет, если установить время на 5 секунд?» Хорошие кандидаты знают, что это создает ненужную нагрузку. Отличные кандидаты действительно ломали систему таким образом и извлекали из этого урок.

Мы рассматриваем Datadog. Вы использовали и Datadog, и Prometheus плюс Grafana. Что вы думаете о том, когда стоит использовать каждый из них?

Этот вопрос покажет, понимаете ли вы компромисс между стоимостью и сложностью.

Datadog — это универсальное решение. Мониторинг, логи, метрики, панели мониторинга — всё встроено. Не требует настройки. Но оно очень дорогое. Prometheus плюс Grafana — это решение с открытым исходным кодом, более дешевое, но требует специальных знаний для правильной настройки. Ключевой момент: есть ли у вас команда и время? Используйте Prometheus. Хотите быстро продвинуться вперед и у вас есть бюджет? Используйте Datadog.

По сути, я спрашиваю: можно ли принимать архитектурные решения, исходя из размера команды, бюджета и технических требований? Или вы просто выбираете то, что популярно в LinkedIn?

Я заметил, что вы упомянули sidecar контейнеры для логирования. Можете объяснить, как работает этот паттерн?

Этот тест проверяет, понимаете ли вы Kubernetes-паттерны, а не просто отдельные контейнеры.

Оба контейнера работают в одном поде и используют общий смонтированный том. Ваше приложение записывает логи в этот том. Sidecar, например Fluentd, читает из того же тома и отправляет логи в CloudWatch или OpenSearch. Это позволяет отделить ведение логов от вашего приложения. Вы можете менять инфраструктуру логирования без изменения кода приложения.

Почему этот паттерн важен: в продакшене вам нужно менять backend логирования, добавлять новые назначения или менять вендоров. Если логирование встроено в код приложения, любое изменение требует нового деплоя. Sidecar решает это.

Если бы завтра вы настраивали мониторинг для нового микросервисного приложения, какие метрики вы бы отслеживали с первого дня?

Это мой любимый вопрос, потому что он показывает, как кандидаты оценивают готовность к работе в боевых средах.

Задержка. Время ответа в миллисекундах. Частота ошибок. 500-е, 400-е по эндпоинтам. Пропускная способность. Количество запросов в секунду. Процент времени безотказной работы. Использование CPU и памяти по сервисам. Типы запросов. Шаблоны GET, POST, DELETE. Географические данные. Откуда поступает трафик. Это помогает соблюдать SLA и выявлять проблемы до того, как их заметят клиенты.

Кандидаты, которые произвели на меня впечатление, добавляют: «И я бы настроил оповещения по этим показателям до запуска системы, а не после возникновения инцидента».

Вот что важно на собеседованиях по DevOps.

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

Освоив этот принцип, вы сможете объяснить работу любой системы мониторинга. Будь то Prometheus и Grafana, Datadog, New Relic или любой новый инструмент, который появится в следующем году.

Я видел кандидатов с двухлетним опытом, которые отлично понимают этот процесс, и они с легкостью проходят собеседования. А также видел ветеранов с пятилетним стажем, которые запомнили команды инструментов, но не могут объяснить архитектуру, и терпят сокрушительное поражение.

Чего на самом деле хотят компании?

Когда я нанимаю DevOps-инженеров, я ищу человека, который может объяснить, почему он выбрал тот или иной инструмент, а не просто как им пользоваться.

Можете ли отследить поток данных через несколько систем?

Понимаете ли вы влияние простоев на бизнес? Можете ли вы принимать компромиссные решения, учитывая стоимость, сложность и размер команды?

Если вы умеете это делать, конкретные инструменты не имеют значения. Вы освоите тот набор технологий, который использует компания.

Как на самом деле подготовиться к этим вопросам

Прекратите смотреть 10-часовые курсы по каждому инструменту мониторинга. Вместо этого постройте один полный стек мониторинга с нуля.

• Возьмите Prometheus и Grafana.
• Настройте его для реального применения.
• Сломайте. Почините.
• Поймите, зачем существует каждый элемент.
• Затем проделайте то же самое с логами.
• Настройте Fluentd или Fluent Bit.
• Отправьте логи в CloudWatch или Loki.
• Делайте запросы. Ломайте пайплайн. Чините его.

За две недели практических занятий вы узнаете больше, чем за шесть месяцев просмотра обучающих видеороликов.