Вопросы на собеседовании: DevOps-инженер

CI-пайплайн должен сначала давать самую быструю и дешёвую обратную связь, а затем постепенно повышать стоимость и риск проверок.

• Сначала запускаются линтеры и статические проверки, затем юнит-тесты, сборка контейнера и интеграционные тесты собранного образа.
• Сканирование безопасности выполняется после дешёвых проверок, а публикация и деплой начинаются только после прохождения всех проверок качества.
• Такой порядок не заставляет ждать десятиминутную сборку ради ошибки форматирования и не тратит ресурсы на уже сломанные коммиты.
• В pull request пайплайн останавливается до публикации, а после слияния в main публикует артефакт и запускает деплой.

Сборки в CI медленные, потому что у чистых раннеров нет постоянного кеша слоёв, доступного на машине разработчика.

• BuildKit нужно дать постоянный источник через реестровый кеш cache-from и cache-to либо подключить кеш-хранилище CI-платформы.
• Для каталогов пакетных менеджеров, например pip или npm, используются кеш-маунты BuildKit, чтобы загрузки переживали сборки, но не попадали в слои образа.
• Манифесты зависимостей копируются и устанавливаются до исходного кода, поэтому дорогие слои сохраняются при изменении только файлов приложения.
• Попадания в кеш нужно проверять в логах CI, поскольку удалённый кеш не спасёт Dockerfile, ранние слои которого меняются в каждом коммите.

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

• При OIDC-федерации CI-провайдер выдаёт токен на каждую задачу, облако проверяет его, а задача принимает только необходимую ей роль.
• Статического облачного секрета в этом случае нет, поэтому он не утечёт через логи или форки и не потребует ручной ротации.
• Долгоживущие ключи часто не ротируются и со временем получают лишние права, повышая вероятность и последствия компрометации.
• Если OIDC недоступен, нужны короткоживущие токены из менеджера секретов, маскированные переменные, минимальные права и плановая ротация.

Принцип «собрать один раз, развернуть много раз» означает продвижение одного протестированного и неизменяемого артефакта через все окружения.

• Один контейнерный образ собирается и тестируется, после чего тот же digest проходит через dev, staging и production.
• Конфигурация конкретного окружения передаётся во время запуска, а не запекается в отдельные образы.
• Пересборка для каждого окружения может изменить зависимости, входные данные или базовый образ, поэтому в production попадёт бинарник, не проверенный на staging.
• Неизменяемые теги привязываются к коммиту, а mutable-тег latest не используется для продвижения, что сохраняет происхождение и надёжный откат.

Повторяющиеся пайплайны GitHub Actions нужно заменить версионируемыми общими workflow и тонкими вызовами из сервисных репозиториев.

• В центральном репозитории размещаются workflow_call с типизированными входами и секретами, а каждый сервис передаёт только свои параметры.
• Для небольших общих последовательностей, например настройки облачных доступов или сборки образа, используются composite actions.
• Общие workflow подключаются по релизным тегам, а не по main, чтобы несовместимые изменения внедрялись управляемо и не затрагивали все репозитории сразу.
• Для сервисов с обоснованными исключениями нужен документированный путь отклонения без возврата всей организации к копированию workflow.

Оптимизация пайплайна начинается с измеренных узких мест, а не с предположений.

• Тайминги стадий и шагов за несколько сотен запусков покажут время на установку зависимостей, сборку образов и последовательные тесты.
• Сначала кешируются зависимости и слои сборки, затем независимые задачи запускаются параллельно, а тесты разбиваются на шарды.
• Медленные полные end-to-end тесты можно вынести из критического пути pull request в запуск после слияния или по ночам, если это позволяет их профиль риска.
• Бюджет длительности и уведомления о регрессиях закрепляют ответственность за скорость и не дают пайплайну снова растянуться до сорока минут.

Trunk-based разработка требует от CI/CD быстрой и надёжной проверки небольших изменений, которые часто сливаются в main.

• Пайплайн должен достаточно быстро и стабильно проверять каждое слияние, а незавершённая функциональность скрывается фичефлагами, а не ветками.
• Долгоживущие ветки откладывают интеграцию, накапливают конфликты и превращают staging в очередь крупных, частично проверенных слияний.
• Trunk-based разработка вместе с фичефлагами поддерживает непрерывный деплой, поскольку проблемы интеграции выявляются раньше, а размер изменений уменьшается.
• Ветвление в стиле GitFlow ведёт к релизным поездам и крупным пакетам; это может подходить регулируемому графику релизов, но снижает частоту деплоя.

Ручное одобрение уместно только там, где человек добавляет оценку, которую не могут дать автоматические проверки.

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

Надёжный откат повторно разворачивает предыдущий заведомо рабочий артефакт без новой сборки.

• В реестре хранятся неизменяемые версионированные образы, а инструмент деплоя умеет выбрать любую сохранённую версию проверенной командой.
• Процедуру отката нужно регулярно отрабатывать, поскольку непроверенный runbook с большой вероятностью подведёт во время инцидента.
• Один git revert заставляет ждать сборку и тесты, пока production не работает, и бесполезен, если сломан сам пайплайн.
• Обратно совместимые изменения схемы и миграции expand-contract нужны, чтобы данные новой версии не мешали вернуть старый артефакт.

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

• Фильтры путей запускают workflow сервиса при изменениях в его каталоге и в используемых им общих путях.
• Зависимости от общих библиотек моделируются через Nx, Bazel, Turborepo или поддерживаемый скрипт, который вычисляет затронутые сервисы по diff.
• Полная сборка запускается по ночам, поскольку логика путей и графа зависимостей может пропустить связь или содержать ошибку.
• Каждый сервис разворачивается независимо, чтобы изменение одной команды не выпустило незавершённую работу другой.

Self-hosted раннеры оправданы требованиями к сети, оборудованию, кешу или стоимости больших объёмов, которые hosted-раннеры закрывают плохо.

• Они подходят для доступа к приватной сети, GPU или большого объёма памяти, постоянного кеша и нагрузок, где поминутная оплата hosted-раннеров невыгодна.
• Команда при этом отвечает за обновления, ёмкость, масштабирование, мониторинг и регулярную замену парка раннеров.
• Раннеры должны быть эфемерными или часто пересоздаваться, чтобы одна сборка не оставляла состояние следующей.
• Код pull request из форка считается удалённым выполнением кода: его сеть и доступы изолируются, по умолчанию используются hosted-раннеры, а self-hosted запускаются только при необходимости в защищённой среде.

GitOps делает Git источником желаемого состояния кластера, а контроллер внутри кластера постоянно приводит фактическое состояние к нему.

• Манифесты или Helm values хранятся в Git, а деплой становится слитым pull request с новым тегом образа, который забирает Argo CD или Flux.
• CI больше не нужны доступы к кластеру, поскольку изменение получает и применяет контроллер внутри самого кластера.
• Реконсиляция обнаруживает ручной дрейф и может сообщить о нём или отменить его, поэтому желаемое состояние поддерживается постоянно.
• Откат выполняется через git revert в репозитории состояния, а история Git показывает, кто и что изменил.

Сборочный пайплайн должен обеспечивать прослеживаемость каждого входа и не допускать непроверенные артефакты до деплоя.

• Сторонние CI actions фиксируются по SHA коммита, базовые образы по digest, а зависимости через lock-файлы вместо изменяемых ссылок.
• Во время сборки создаётся SBOM, а зависимости и образы сканируются на известные уязвимости с блокировкой критических находок по политике.
• Собранные образы подписываются, чтобы среда деплоя могла проверить, что артефакт действительно выпущен CI.
• Секреты нельзя передавать через аргументы сборки или слои, поскольку их можно извлечь из истории образа.

Миграции базы при непрерывном деплое должны оставаться совместимыми со старыми и новыми экземплярами приложения во время раскатки.

• Миграции выполняются отдельной init-задачей или стадией пайплайна до деплоя кода приложения.
• Применяется expand-contract: добавить nullable-колонку, развернуть запись в оба формата, заполнить данные, переключить чтение и удалить старую колонку в более позднем релизе.
• Каждое промежуточное состояние схемы должно работать, пока старые и новые экземпляры используют его одновременно.
• Миграцию и код, который сразу от неё зависит, нельзя выпускать одним деплоем, чтобы сохранить безопасную раскатку и откат.

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

• Переменные окружения, подключённые конфигурационные файлы или значения конфигурационного сервиса передаются при деплое по принципам twelve-factor.
• Общая база дополняется небольшими Kustomize overlays или Helm values, чтобы различия окружений были видны на ревью.
• Секреты передаются отдельно через менеджер секретов или sealed secrets и никогда не хранятся в репозитории открытым текстом.
• Обязательная конфигурация проверяется при запуске, чтобы отсутствующее или неверное значение остановило деплой, а не случайный запрос в production.

При миграции с Jenkins на GitHub Actions сохраняются концепции доставки, но модель выполнения нужно спроектировать заново, а не переводить задачи строка в строку.

• Стадии Jenkins становятся jobs, shared libraries заменяются reusable workflows или composite actions, агенты становятся раннерами, а доступы переходят в секреты окружения или предпочтительно OIDC.
• Stateful-сервер Jenkins с многолетней конфигурацией плагинов заменяется декларативным YAML в репозиториях и эфемерными раннерами.
• Уникальные ручные настройки задач и лишние плагины нужно удалить, а не воспроизводить накопленное поведение на новой платформе.
• До переноса составляется список задач с постоянным workspace, плагинов без аналога в Actions и незадокументированного поведения на сервере Jenkins.

Инфраструктурный код до production должен пройти последовательные статические проверки, анализ плана, интеграционные тесты и staging.

• Сначала запускаются terraform fmt и validate, tflint и policy-as-code правила, запрещающие риски вроде публичных S3-бакетов или ingress 0.0.0.0/0.
• В каждом pull request выполняется terraform plan, а его diff проверяется как основной артефакт с оценкой масштаба изменений, а не только стиля HCL.
• Модули с нетривиальной логикой создаются во временном sandbox-аккаунте, их поведение проверяется, после чего ресурсы удаляются.
• Последним защитным слоем то же изменение применяется к staging-инфраструктуре и только затем продвигается в production.

Уведомления CI становятся полезными, когда каждое падение получает его владелец вместе с контекстом для немедленной диагностики.

• Падения pull request отправляются напрямую автору, а сбои main-ветки конкретного сервиса поступают в канал отвечающей за него команды.
• Уведомления не рассылаются людям, которые не могут на них повлиять, иначе общий канал быстро превращается в красную стену, отключённую всеми.
• Каждое сообщение содержит упавшую стадию, полезный фрагмент ошибки, ссылку на логи и отличие от последнего успешного запуска.
• Падения продуктовых тестов, нестабильность инфраструктуры и сбои окружений учитываются отдельно, чтобы обычный шум не приучал команду игнорировать красный статус.

Multi-stage Dockerfile отделяет сборку от выполнения, поэтому в production попадают только необходимые во время работы файлы.

• Первая стадия использует полный образ с инструментами, устанавливает зависимости и компилирует бинарник или собирает приложение.
• Финальная стадия начинается с минимальной базы distroless, Alpine или slim и копирует только готовый артефакт и runtime-зависимости.
• Компиляторы, заголовочные файлы, пакетные менеджеры и исходный код не попадают в production, что уменьшает образ и поверхность атаки.
• Стабильная установка зависимостей остаётся в ранних кешируемых слоях, а небольшая финальная стадия быстро пересобирается и доставляется.

Образ размером 1,8 ГБ нужно уменьшать, начиная с крупнейших структурных источников, а затем защитить результат от регрессии.

• Сначала проверяется базовый образ: замена полной ОС или крупного языкового образа на slim либо distroless обычно даёт максимальную экономию при малых усилиях.
• Через docker history или dive находятся инструменты сборки, кеши apt и pip, целиком скопированные исходники и пропуски в .dockerignore, например .git или node_modules.
• Multi-stage сборка исключает инструменты компиляции, а кеши пакетов удаляются в той же инструкции RUN, где создаются.
• После оптимизации в CI добавляется лимит размера образа, чтобы незаметное раздувание не вернулось.