Как организован деплой: CI/CD, управление контейнерами и наличие даунтайма?

Что проверяют

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

Как отвечать

Расскажите о своём проекте по шагам, со своими инструментами и цифрами: сколько идёт пайплайн, как часто релизы. Каркас для Python-сервиса:

• CI: на каждый пуш ruff, mypy и pytest с тестовой базой в контейнере, в GitHub Actions, GitLab CI или Jenkins;
• сборка: многоэтапный Dockerfile на slim-образе, зависимости из lock-файла (uv, poetry), тег образа равен SHA коммита, а не latest. Тогда откат это просто деплой прошлого тега;
• выкладка: в Kubernetes rolling update с maxUnavailable: 0 и readinessProbe, новый под получает трафик только после готовности. Для рискованных изменений canary или blue-green;
• graceful shutdown: Gunicorn и Uvicorn по SIGTERM дорабатывают текущие запросы, terminationGracePeriodSeconds даёт на это время, короткий preStop ждёт, пока под уберут из балансировки. Воркеры Celery по тому же сигналу дожидаются текущих задач;
• миграции: Alembic или Django migrations отдельным шагом до выкладки и по схеме expand/contract. Сначала добавить новую колонку и писать в обе, потом переключить чтение, а старое удалить отдельным релизом.

Если деплой вёл DevOps, так и скажите, но покажите понимание шагов и назовите, что делали сами: писали миграции, чинили упавший пайплайн, разбирали неудачный релиз. Этот же вопрос полезно задать работодателю: ответ «выкатываем руками по ночам, с простоем» многое говорит о команде.

Где спотыкаются

Отвечают общими словами: «у нас CI/CD и Kubernetes». Без деталей это звучит так, будто вы видели пайплайн только в виде зелёной галочки.

Утверждают, что даунтайма нет, а в том же релизе переименовывают колонку. Во время rolling update старые поды ещё работают и падают на исчезнувшей колонке.

Не знают про обработку SIGTERM и readiness. Тогда при каждом деплое часть запросов обрывается с 502, хотя формально сервис не останавливался.