← вся теориятеория к собесу · Docker и Kubernetes

Observability и CI/CD

Наблюдаемость и CI/CD

Сервис без наблюдаемости - чёрный ящик, а без CI-ворот баги ловят пользователи. Собес проверяет базу эксплуатации: три столпа observability, разницу liveness и readiness и роль CI как ворот качества до прода.

Типовые формулировки: «зачем logging вместо print?», «чем liveness отличается от readiness?», «что делает CI на каждый пуш».

Логи и три столпа наблюдаемости

logging вместо print - не вкусовщина: модуль logging даёт уровни (debug/info/error), формат (JSON для машинного сбора), хендлеры и централизованную конфигурацию. Можно приглушить шум и поднять детализацию БЕЗ правки кода, а логи маршрутизировать в сборщик. print в проде это ни уровней, ни формата, ни маршрутизации, потом не разобрать.

Три столпа observability дополняют друг друга. Логи - события, ЧТО случилось. Метрики - числовые агрегаты, СКОЛЬКО и как (rps, латентность, ошибки). Трейсы - путь запроса через сервисы, ГДЕ тормозит. Один столп не заменяет другой: по логам не увидишь тренд, по метрикам - конкретную ошибку.

// Структурированные (JSON) логи - потому что их собирает и ищет система; человекочитаемая строка хороша локально, но не в проде под нагрузкой.

logging: структурированные логи с уровнями и маршрутизацией
три столпа: логи, метрики, трейсы

Liveness/readiness и ворота CI/CD

Health-check (/health) нужен оркестратору, чтобы судить о состоянии инстанса, и делится на два разных вопроса. Liveness - ЖИВ ли процесс: если нет, оркестратор перезапускает. Readiness - ГОТОВ ли принимать трафик (прогрел кэш, поднял соединения): если нет, трафик не шлют, но и не перезапускают. Путать их опасно: перезапускать инстанс, который просто ещё прогревается, уронить его в цикле рестартов.

CI на каждый пуш и PR гоняет линт, типы и тесты, собирает образ - красное НЕ едет в прод. Это автоматические ворота качества ДО пользователей: ломающее ловится в пайплайне, а не в проде. CD затем выкатывает уже проверенный артефакт. Деплой без CI-ворот означает, что баги находят пользователи.

// Health-check держат лёгким: он должен отвечать быстро, а не выполнять тяжёлую операцию, иначе сам станет источником нагрузки и ложных срабатываний.

liveness/readiness: жив ли инстанс / готов ли принимать трафик
CI/CD: автопроверки перед деплоем / выкатка артефакта

Как отвечать: «Чем liveness отличается от readiness?»

Они отвечают на разные вопросы, и реакция оркестратора на них разная. Liveness - жив ли процесс вообще: если проба не проходит, значит инстанс завис или сломался, и его надо перезапустить. Readiness - готов ли инстанс ПРИНИМАТЬ трафик прямо сейчас: он может быть жив, но ещё прогревает кэш или поднимает соединения к БД, и пока не готов, оркестратор просто не шлёт на него запросы, но НЕ перезапускает. Путаница тут дорого стоит: если на медленный прогрев повесить liveness, оркестратор будет убивать инстанс, который вот-вот был бы готов, и получится цикл рестартов. Поэтому прогрев это readiness, а не liveness. И обе пробы держу лёгкими, чтобы они не создавали нагрузку сами.

Разведены оба вопроса с конкретной реакцией (перезапуск против отвода трафика), назван реальный провал при путанице (цикл рестартов) и добавлено про лёгкость проб - эксплуатационная зрелость.

На чём валят

−Логировать через print в проде: нет уровней, формата и маршрутизации - потом не разобрать.
−Путать liveness и readiness: перезапускать инстанс, который лишь прогревается - цикл рестартов.
−Деплоить без CI-ворот: ломающие изменения ловятся уже на пользователях, а не в пайплайне.
−Делать health-check тяжёлым: сам станет нагрузкой и источником ложных срабатываний.

Проверьте себя

Пять вопросов из банка по этой подтеме. Всего их 12, остальные разбираются в тренажёре.

#observability_cicd1 / 5
Какие три «столпа» наблюдаемости (observability) обычно называют?
A)Бэкапы, репликация и алёрты — базовые гарантии надёжности сервиса
B)Логи, метрики и трейсы — они отвечают на разные вопросы
C)Юнит-, интеграционные и e2e-тесты как способ наблюдать за системой
D)CPU, память и диск — три метрики, которых достаточно сервису
показать ответ и разбор
+B)Логи, метрики и трейсы — они отвечают на разные вопросы
// разбор: Три столпа: логи (дискретные события — что и когда произошло), метрики (числовые агрегаты во времени — сколько запросов, какая задержка, ошибки) и трейсы (путь одного запроса через сервисы — где именно тормозит). Вместе они дают разные срезы: логи для деталей, метрики для трендов и алёртов, трейсы для распределённой диагностики.
#observability_cicd2 / 5
Зачем сервису эндпоинт health-check (например /health)?
A)Чтобы пользователи видели красивую страницу статуса сервиса
B)Чтобы отдавать версию приложения браузеру при каждом заходе на сайт
C)Оркестратор проверяет живость и готовность инстанса по нему
D)Чтобы измерять точное время ответа всех остальных эндпоинтов сразу
показать ответ и разбор
+C)Оркестратор проверяет живость и готовность инстанса по нему
// разбор: Health-check — точка, по которой оркестратор (Kubernetes) и балансировщик судят о состоянии инстанса: liveness (жив ли — иначе перезапустить) и readiness (готов ли принимать трафик — иначе не слать запросы, пока прогревается или отвалилась БД). Обычно это лёгкая проверка ключевых зависимостей, а не тяжёлая операция.
#observability_cicd3 / 5
Что обычно делает CI-пайплайн до деплоя?
A)Гоняет линт и тесты, собирает артефакт — красный не едет в прод
B)Общается с пользователями, собирая обратную связь о новой версии
C)Форматирует код разработчика прямо в его рабочей ветке за него
D)Просто копирует код на сервер без каких-либо проверок в процессе
показать ответ и разбор
+A)Гоняет линт и тесты, собирает артефакт — красный не едет в прод
// разбор: CI на каждый пуш/PR прогоняет линтеры, типы (mypy) и тесты, собирает образ — и не пускает изменения дальше, если что-то красное. Это автоматические ворота качества: до прода доезжает только проверенный код. CD затем выкатывает собранный артефакт. Так ломающие изменения ловятся до пользователей, а не после.
#observability_cicd4 / 5
Почему в проде логируют через модуль logging, а не через print?
A)logging даёт уровни, формат и маршрутизацию — можно управлять без правки кода
B)print запрещён синтаксисом Python при запуске приложения в контейнере или на сервере
C)print в проде вообще не выводит ничего, его сообщения теряются на пути к консоли
D)logging работает быстрее print, поэтому его и выбирают для нагруженного прода
показать ответ и разбор
+A)logging даёт уровни, формат и маршрутизацию — можно управлять без правки кода
// разбор: logging даёт то, чего нет у print: уровни (debug/info/warning/error), настраиваемый формат (в т.ч. JSON для сбора), хендлеры и маршрутизацию, централизованную конфигурацию. Можно приглушить шум и поднять детализацию без правки кода, добавить контекст (id запроса). print — просто вывод строки без структуры и управления; в проде он не даёт разобрать инцидент. Отсюда правило: logging, не print.
#observability_cicd5 / 5
Три столпа observability — что это и зачем разные?
A)Три обязательных внешних сервиса, без покупки всех сразу observability не работает
B)Три уровня доступа к системе мониторинга для разработчиков, админов и менеджеров
C)Это три разных названия одного и того же: по сути все они являются просто логами
D)Логи (что случилось), метрики (сколько/как), трейсы (где тормозит) — разные вопросы
показать ответ и разбор
+D)Логи (что случилось), метрики (сколько/как), трейсы (где тормозит) — разные вопросы
// разбор: Логи, метрики и трейсы — три взаимодополняющих сигнала. Логи — дискретные события (что именно случилось, с контекстом). Метрики — числовые агрегаты во времени (сколько запросов, задержка, ошибки — для дашбордов и алертов). Трейсы — путь одного запроса через сервисы (где именно он проводит время, где узкое место). Вместе они отвечают на разные вопросы при диагностике; полагаться лишь на один недостаточно.

дальше

Теорию прочитали. Навык ставится повторением

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

Открыть тренажёр Вся тема: Docker и Kubernetes