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

Я использую переиспользуемые pipeline templates с независимыми builds сервисов и собираю каждый commit только один раз.

• Pull requests запускают затронутые lint, unit и policy checks меньше чем за пять минут с dependency-aware caching.
• Merge создаёт immutable image, сканирует его через Trivy, подписывает Cosign и продвигает один digest по окружениям.
• Production использует automated canaries с SLO gates, а runner concurrency и deployment queues рассчитаны на измеренный пик 600 deploy.

Я собираю только затронутый dependency graph и делаю cache keys воспроизводимыми из inputs.

• Bazel, Nx или Pants связывает changed files с сервисами и включает reverse dependencies, которые нужно повторно тестировать.
• Remote caches хранят compiled layers и test outputs по hash source, lockfile, toolchain и build configuration.
• Nightly full build ловит ошибки graph, а p95 pull request должен упасть ниже десяти минут без сокращения required tests.

Я provision примерно 150 concurrent ephemeral runners сверх среднего требования 100 runners для этой нагрузки.

• Autoscaling держит около 20% warm capacity, чтобы queue p95 оставался меньше двух минут во время bursts.
• Недоверенные pull requests работают без cloud credentials на отдельных node pools или accounts от signed release jobs.
• Каждый job получает чистую VM или Pod, максимум 30 минут жизни, restricted egress и отсутствие shared Docker socket.

Я запускаю green на полной production capacity до переключения traffic, принимая временную стоимость compute 2x.

• Green получает smoke и synthetic tests, затем 5% shadow или live traffic со сравнением latency, errors и saturation с blue.
• Load balancer перемещает traffic контролируемыми шагами и держит connection draining внутри десятиминутного rollback window.
• Blue остаётся deployable и подключённым к backward-compatible data layer, пока green не удержит SLO минимум 30 минут.

Я прохожу 5%, 25%, 50% и 100% traffic, только пока canary signals остаются рядом с baseline.

• Каждый этап длится минимум десять минут и сравнивает error rate, p95 latency, saturation и business metric вроде checkout success.
• Automatic rollback срабатывает выше 0,5% errors, при regression latency 20% или двух fast burn-rate windows.
• Минимум три canary replicas не дают судить по одному noisy instance, а rollout pause-ится при малом sample volume.

Я использую expand-and-contract sequence из минимум трёх независимо deployable changes.

• Сначала добавляю nullable column или совместимый default без долгой table rewrite, затем deploy кода с записью в оба представления.
• Backfill идёт ограниченными batches при monitoring lock time, replica lag и CPU базы ниже согласованных limits.
• Только после перехода всех readers новый pipeline проверяет completeness, добавляет constraint и удаляет старый path.

Я создаю один signed image digest после merge и продвигаю metadata со ссылкой на этот digest.

• Tests, SBOM, provenance и vulnerability results привязываются к immutable digest в registry.
• Environment-specific configuration остаётся вне image в Helm values, Kustomize overlays или runtime configuration.
• Admission отклоняет mutable tags в production, поэтому все восемь окружений запускают прошедший ранние gates artifact.

Я делаю rollback заранее вычисленным deployment action, а не rebuild или ручным изменением manifest.

• Registry хранит недавние signed digests, а GitOps history фиксирует точные image и configuration revision каждого release.
• Database changes остаются backward-compatible минимум одно release window, иначе application rollback небезопасен.
• Quarterly exercise откатывает representative services и измеряет traffic recovery меньше пяти минут вместе с readiness и connection draining.

Сначала я сокращаю 18-минутный test path, потому что он доминирует в critical path.

• Tests делятся по historical duration между parallel workers, а flaky tests quarantined с owners вместо blind retry.
• BuildKit layer caching и prebuilt toolchain images сокращают шестиминутную build без потери reproducibility.
• Deploy начинается после required gates, а p95 duration по stage доказывает общий результат ниже 12 минут две недели.

Я использую native builders для каждой architecture и объединяю manifests в один multi-architecture digest.

• BuildKit выполняет architecture-independent stages один раз, где возможно, и делит remote cache layers между runner pools.
• Native arm64 runners избегают большого и нестабильного emulation cost QEMU для compile-heavy services.
• CI запускает smoke tests на обоих images и принимает дизайн только при p95 build time меньше 18 минут.

Средняя потребность около 54 concurrent runners, поэтому я начну примерно с 80 для bursts и maintenance.

• Расчёт: 400 умножить на восемь и разделить на 60, затем headroom проверяется по arrival peaks, а не плоскому часовому average.
• Autoscaling использует queue depth и oldest-job age с целью p95 queue две минуты.
• Per-repository concurrency и cancellation superseded commits не дают одной busy branch занять все 80 runners.

Я использую risk-based automated gates и сохраняю human approval для high-impact changes.

• Signed artifacts с passing tests, policy checks и canary evidence могут auto-promote для low-risk services.
• IAM, database, public-network или tier-0 changes требуют двух named approvers и expiring deployment window.
• Platform записывает approver, digest, policy result и rollback link с целью median wait меньше десяти минут без ослабления tier-0 control.

Я публикую небольшие versioned modules и собираю из них поддерживаемые account и environment stacks.

• VPC module владеет networking primitives и отдаёт stable contract, но не создаёт одновременно EKS, databases и application IAM.
• Opinionated wrapper modules дают approved defaults common path, открывая только реально меняющиеся teams inputs.
• CI тестирует examples, upgrade paths, policy compliance и plans минимум для двух реальных account classes до release.

Я делю state по lifecycle, blast radius, ownership и change frequency, а не произвольному числу ресурсов.

• Network, shared identity, clusters, data services и application stacks получают отдельные states с явными remote outputs.
• Я избегаю длинных chains terraform_remote_state, публикуя stable values через parameter store или platform API там, где уместно.
• Migration использует moved blocks или state moves в reviewed batches с целевыми lock time и plan p95 ниже пяти минут.

Я использую remote encrypted backend с locking, versioning, audit logs и узкими identities.

• S3 native lockfiles с versioning или Terraform Cloud предотвращают concurrent writes и хранят recoverable state versions.
• Каждый state имеет dedicated apply identity; plan jobs получают read access и short-lived OIDC credentials.
• CI сериализует applies на state, снимает stale locks через audited procedure и quarterly тестирует restoration.

Я использую отдельные root configurations и state backends для account и production boundaries, а не 90 CLI workspaces.

• Directory или generated-stack structure делает account, region и environment видимыми в review и access policy.
• Production получает отдельные apply identity и approval path, поэтому выбор неверного workspace не может попасть в него.
• Workspaces остаются для short-lived identical preview environments с действительно одинаковыми isolation и configuration.

Я запускаю scheduled read-only plans для каждого state и направляю actionable drift owning team.

• High-risk states планируются hourly, обычные daily, а cloud audit events запускают targeted plans после console changes.
• Report отделяет provider normalization от реальных create, update и delete actions, удерживая false positives ниже 5%.
• Emergency changes получают owner и expiry, затем импортируются в code или reverted в течение 24 часов.

Я публикую новую major version и поддерживаю старый contract в течение измеренного migration window.

• Upgrade tests запускают representative consumer plans и документируют state moves, renamed inputs и provider-version requirements.
• Renovate или похожий bot открывает pinned-version pull requests группами по пять consumers, начиная с non-production.
• Старый major удаляется только после migration всех 60 states и одной проверки rollback instructions.

Я создаю plan из reviewed commit и применяю именно этот approved plan через short-lived production identity.

• CI хранит binary plan, human-readable summary, provider lockfile и commit SHA как один immutable review artifact.
• Apply отклоняет changed branch head, stale plan, policy failure или expired approval вместо silent replan.
• Production plans истекают через короткое окно, например четыре часа, потому что external state может измениться.

Я мигрирую по service boundary и risk tier, а не делаю один bulk import.

• Inventory и cloud tags определяют owner, dependencies и решение import, replace или retire для каждого ресурса.
• Generated import blocks ускоряют capture, но каждый imported state должен получить zero-change plan до обычных applies.
• Cohorts начинают с non-production и идут примерно по 100 ресурсов в неделю с monitoring unintended replacement и access changes.