Google PCA: DevOps, инженерия поставки и инфраструктура как код — Руководство по подготовке

By Laurynas Brazys · 5 September 2026 · #google #PCA #certification #exam-prep #study-guide

Часть Google Professional Cloud Architect — Руководство по подготовке. Практикуйтесь с проверенными ответами в центре экзаменов Google, или пройдите тесты на время на ExamRoll.io.

Обзор

DevOps, инженерия доставки (Delivery Engineering) и инфраструктура как код (IaC) в Google Cloud направлены на непрерывную поставку надежных изменений с четкой прослеживаемостью, автоматизацией и безопасностью. Архитектуры должны быть оптимизированы для коротких циклов обратной связи, повторяемых развертываний, неизменяемой инфраструктуры и защитных механизмов (guardrails), которые масштабируются вместе с организацией. В Google Cloud это обычно сочетает в себе лучшие практики контроля версий; CI с помощью Cloud Build; управление артефактами с помощью Artifact Registry; CD с помощью Cloud Deploy; Kubernetes на GKE с использованием манифестов, Helm или Kustomize; GitOps для контроля дрейфа конфигурации; и IaC с помощью Terraform или шаблонов развертывания Google Cloud. Операционное совершенство требует прогрессивной доставки (blue-green, canary, разделение трафика и feature flags), контроля цепочки поставок ПО (сканирование, отслеживание происхождения, подписание), шлюзов тестирования и развертывания, а также управления, которое балансирует скорость, безопасность, аудируемость и владение.

CI/CD, контроль версий и оркестрация релизов

• Принципы CI/CD

  • Поддерживайте master/main в готовом к релизу состоянии; практикуйте разработку на основе κορμού (trunk-based development) с короткоживущими ветками для новой функциональности.
  • Автоматизируйте сборку, тестирование, сканирование и упаковку при каждом изменении; требуйте рецензирования кода (code review) с обязательными подтверждениями и проверками статуса.
  • Обеспечивайте полную прослеживаемость от коммита → сборки → дайджеста артефакта → релиза в окружение; встраивайте SHA коммитов и метаданные сборки в образы и аннотации развертывания.
  • Типичные сбои: долгоживущие ветки, передача задач вручную, нестабильные тесты (flaky tests), невоспроизводимые сборки и отсутствие неизменяемости артефактов приводят к неожиданным проблемам на поздних этапах и откатам.

• Контроль версий, ветвление, pull-реквесты, рецензирование кода и прослеживаемость

  • Используйте защищенные ветки, обязательные рецензии и подписание коммитов. Ставьте теги на релизы и ведите журнал изменений (changelog), генерируемый из коммитов слияния.
  • Применяйте CODEOWNERS и метаданные о владении сервисом для закрепления ответственности за домен.
  • Связывайте коммиты с задачами и развертываниями; экспортируйте логи и метаданные CI/CD в Cloud Logging и BigQuery для аудита и сбора метрик DORA.

• Cloud Build

  • Триггеры: срабатывают по событиям Git (ветка, тег, PR), ручному запуску или через Pub/Sub. Параметризуйте с помощью подстановок (substitutions) для версии, окружения и feature flags, чтобы конвейеры соответствовали принципу DRY.
  • Шаги сборки: запускайте официальные сборщики или определенные вами контейнеры; используйте параллельные шаги, если они независимы, для уменьшения задержки; используйте кеши для зависимостей языков программирования, чтобы ускорить сборку.
  • Артефакты: отправляйте образы в Artifact Registry с неизменяемыми тегами и дайджестами; храните SBOM и логи сборки; публикуйте отчеты о тестировании как артефакты сборки.
  • Безопасные удостоверения для сборки: запускайте Cloud Build со специальным сервисным аккаунтом с минимальными привилегиями и, где возможно, с Workload Identity Federation для каждого репозитория. Для частных сетей или чтобы избежать исходящего трафика, используйте Private Pools. Ограничивайте использование ключей сервисных аккаунтов; предпочитайте короткоживущие токены.
  • Пример (сокращенный):
    • cloudbuild.yaml:
      • steps:
        • name: gcr.io/cloud-builders/docker args: [build, -t, $REGION-docker.pkg.dev/$PROJECT/app/web:$COMMIT_SHA, .]
        • name: gcr.io/cloud-builders/docker args: [push, $REGION-docker.pkg.dev/$PROJECT/app/web:$COMMIT_SHA]
      • substitutions:
        • _ENV=staging

• Cloud Deploy

  • Релизы и целевые окружения (targets): смоделируйте конвейер доставки с продвижением по целевым окружениям (например, dev → staging → prod). Релиз содержит ссылку на неизменяемый артефакт и конфигурацию развертывания.
  • Подтверждения и продвижение: требуйте ручных или автоматических подтверждений с ролевым контролем доступа. Продвижение должно быть быстрой операцией с низким риском, поскольку артефакт и манифесты не изменяются.
  • Канареечное развертывание (canary rollout) и откат: определите стратегии для постепенного вывода, проверок работоспособности и автоматического отката при ошибках SLO. Записывайте каждое продвижение, подтверждающего и результат проверки для аудита.
  • Типичные сбои: изменяемые артефакты между окружениями, ручное использование kubectl в production или пропуск проверок перед развертыванием вызывают дрейф конфигурации и неотслеживаемые сбои.

Инфраструктура как код и управление конфигурацией

• Terraform
  • Модули: инкапсулируют повторяемые шаблоны (например, VPC, кластеры GKE, сервисные аккаунты, привязки IAM). Версионируйте и закрепляйте (pin) релизы модулей; публикуйте внутренние реестры модулей.
  • Удаленное состояние (remote state): храните в Cloud Storage с версионированием, политикой хранения и CMEK; включите блокировки; ограничьте доступ с помощью IAM и единого доступа на уровне бакета; создавайте резервные копии состояния.
  • Планы и проверки политик: запускайте

undefined

в CI; требуйте ручной проверки плана; применяйте политики как код (policy as code) (OPA/Conftest, Sentinel или Policy Controller) для блокировки нарушений (например, публичные бакеты, широкие привязки IAM).

• Продвижение по средам: используйте отдельные рабочие пространства (workspaces) или отдельные файлы состояния/бэкенды для каждой среды; продвигайте изменения через те же версии модулей и переменные; никогда не редактируйте облачные ресурсы вручную. Конфиденциальные данные должны поступать из Secret Manager или систем автоматизации, а не быть захардкоженными.

• Сценарии сбоев: утечка секретов в файл состояния, одновременные изменения без блокировок, дрейф конфигурации из-за изменений в обход IaC и неявные зависимости, которые нарушают операции destroy/replace.

• Шаблоны развертывания Google Cloud и декларативная конфигурация

  • Используйте декларативные инструменты (Terraform, Google Cloud Deployment Manager или Kubernetes Configuration as Code) для определения желаемого состояния, а не скрипты с императивными шагами.
  • Предпочитайте неизменяемую (immutable) инфраструктуру: заменяйте шаблоны инстансов и обновляйте MIG; выкатывайте новые GKE Deployments вместо того, чтобы исправлять поды на месте. Неизменяемые шаблоны упрощают откат и аудит.
  • Deployment Manager поддерживает шаблоны Jinja/Python для ресурсов Google Cloud, но ограничен только Google Cloud; Terraform предлагает более широкую экосистему и инструменты для работы с политиками. Выбирайте на основе стандартов организации и навыков команды.

• Манифесты Kubernetes, Helm, Kustomize и GitOps

  • Манифесты: храните базовые шаблоны с наложениями (overlays) для каждой среды; параметризуйте только то, что должно отличаться в разных средах (например, количество реплик, лимиты, эндпоинты).
  • Helm: упаковывайте, шаблонизируйте и версионируйте сервисы с помощью чартов (charts); фиксируйте зависимости; закрепляйте (pin) дайджесты образов. Сценарий сбоя: избыточная шаблонизация скрывает намерения и усложняет проверку.
  • Kustomize: управляйте наложениями (база + патчи для среды); проще, чем Helm, когда достаточно чистого Kubernetes.
  • GitOps: контроллер (например, Config Sync, Argo CD, Flux) непрерывно сверяет состояние кластеров с желаемым состоянием в Git; каждое изменение — это PR с ревью и аудиторским следом. Автоматически обнаруживайте и исправляйте дрейф конфигурации.

Постепенная доставка, цепочка поставок, тестирование и верификация

• Feature flags и управление трафиком

  • Feature flags (функциональные флаги) отделяют развертывание от релиза; используйте для постепенного открытия функционала, A/B-тестов и аварийного отключения. Убедитесь, что состояния флагов версионируются и поддаются аудиту; удаляйте устаревшие флаги.
  • Разделение трафика: в Cloud Run используйте маршрутизацию на основе процентов между ревизиями; в GKE используйте service mesh или ingress-контроллеры, поддерживающие взвешенную маршрутизацию. Для API под одним хостнеймом/TLS держите отдельные бэкенд-сервисы для каждого пути за HTTP(S) Load Balancer; маршрутизация по путям чисто изолирует старую и новую версии, сохраняя единый URL и сертификат.
  • Blue-green: запустите два готовых к продакшену стека; атомарно переключайте трафик с помощью балансировщика нагрузки, селекторов сервисов или трафика ревизий Cloud Run. Обеспечивает мгновенный откат, но удваивает постоянные затраты.
  • Канареечное и постепенное развертывание: постепенно увеличивайте трафик, начиная с небольшой доли, измеряя «золотые сигналы» и бизнес-KPI; автоматизируйте откат при регрессии.

• Контроль цепочки поставок ПО

  • Сканирование образов: включите сканирование уязвимостей с помощью Artifact Analysis; прерывайте сборки при обнаружении критических уязвимостей или заведомо плохих базовых образов; соблюдайте регулярный график установки патчей.
  • Происхождение и подпись: генерируйте данные о происхождении сборки (provenance), совместимые с SLSA, в Cloud Build; подписывайте артефакты с помощью Cosign; применяйте политики Binary Authorization, требующие аттестаций перед развертыванием.
  • Управление зависимостями: закрепляйте (pin) версии и дайджесты, ведите SBOM, вендорируйте критические зависимости и проверяйте контрольные суммы. Сценарии сбоев включают дрейф транзитивных зависимостей и скомпрометированные реестры.

• Пирамида тестирования, шлюзы развертывания и верификация после развертывания

  • Пирамида: делайте упор на быстрые юнит-тесты; добавляйте интеграционные и контрактные тесты; запускайте целевые end-to-end тесты. Используйте реалистичные и обезличенные тестовые данные (используйте Cloud DLP для удаления PII).
  • Шлюзы развертывания: применяйте пороговые значения для процента успешных тестов, статуса уязвимостей, соответствия политикам и код-ревью перед продвижением; требуйте ручного подтверждения для продакшена при повышенном риске.
  • Верификация после развертывания: запускайте дымовые тесты (smoke tests), синтетические проверки и канареечный анализ с помощью Cloud Monitoring, Error Reporting и Trace. Если KPI ухудшаются, инициируйте автоматический откат и создайте инцидент с собранным контекстом.
  • Операционная диагностика: развертывайте Cloud Logging agent там, где это необходимо, и инструментируйте сервисы для Trace и Debugger. Храните раунбуки (runbooks) для безопасного устранения проблем (например, изменение размера постоянного диска онлайн и запуск

undefined

с минимальным простоем).

Управление, безопасность, аудируемость и владение

• Скорость без ущерба для безопасности

  • Разработка на основе основной ветки (trunk-based development) с короткоживущими PR и обязательным ревью поддерживает непрерывный поток работы без ущерба для качества.
  • Конвейеры самообслуживания с шаблонами для распространенных стеков (GKE + Helm, Cloud Run, Dataflow) ускоряют команды и снижают риски, связанные с уникальными решениями.

• Доступ, идентификация и утверждения

  • Используйте выделенные сервисные аккаунты для каждого этапа конвейера с минимальными привилегиями и Workload Identity Federation; избегайте статических ключей.
  • Разделяйте обязанности: разработчики создают сборки; менеджеры по релизам утверждают развертывание в производственную среду; операторы среды выполнения отвечают за конфигурацию и бюджеты во время выполнения.

• Аудируемость и соответствие требованиям

  • Экспортируйте Cloud Build, Cloud Deploy и Cloud Audit Logs в BigQuery. Используйте представления наборов данных и IAM для предоставления аудиторам данных аудита с ограниченным доступом. Храните метрики в течение длительного времени, экспортируя их в Cloud Storage или BigQuery в соответствии с политикой.
  • Записывайте хеш-суммы (digests) артефактов в метаданные развертывания. Поддерживайте сквозные SBOM и данные о происхождении (provenance) для каждого релиза.

• Владение и SLO

  • У каждого сервиса есть владелец, график дежурств (on-call), SLO и бюджеты ошибок, которые контролируют релизы. Свяжите политики развертывания с соблюдением SLO, чтобы избежать внесения изменений, когда бюджет исчерпан.

• Распространенные компромиссы и подводные камни

  • Стоимость сине-зеленого развертывания в сравнении со скоростью отката; уверенность при канареечном развертывании в сравнении со временем до полного релиза.
  • Согласованность GitOps в сравнении с операционной гибкостью; разрешите контролируемый экстренный доступ (break-glass) с логированием и последующими PR для исправления.
  • Чрезмерное использование шаблонов снижает читаемость; сохраняйте конфигурацию явной и минимальной.
  • Централизованная политика предотвращает неверную конфигурацию, но должна внедряться итеративно, чтобы избежать необоснованной блокировки команд.

Практический сценарий

Компания: Borealis Fintech

Задача: Borealis запускает новый платежный API на GKE, сохраняя при этом v1 и v2 под одним и тем же именем хоста и TLS. Им необходимы сквозная прослеживаемость, прогрессивная доставка с использованием канареечных релизов и флагов функциональности, строгий контроль цепочки поставок и аудируемое продвижение по средам dev, staging и prod. Они также хотят использовать GitOps для конфигурации кластера и Terraform для ресурсов платформы.

Подход:

1. Настроить систему контроля версий и ветвление

   • Создать монорепозиторий с каталогами сервисов и отдельный репозиторий для инфраструктуры. Обеспечить защиту ветки main, обязательные ревью PR, использование CODEOWNERS и подписанные коммиты. Обоснование: процесс разработки на основе основной ветки (trunk-based) с четким владением и готовой к аудиту историей.

2. Сборка артефактов с помощью Cloud Build и Artifact Registry

   • Определить cloudbuild.yaml для сборки и отправки образов с тегом $COMMIT_SHA и аннотациями с SBOM и данными о происхождении (provenance). Использовать выделенный сервисный аккаунт Cloud Build с минимальными привилегиями и частный пул (Private Pool). Обоснование: воспроизводимые, изолированные сборки с отслеживаемыми хеш-суммами.

   • Пример:

undefined

3. Внедрить контроль цепочки поставок ПО

   • Включить сканирование на уязвимости в Artifact Registry. Генерировать данные о происхождении и подписывать образы с помощью Cosign на шагах после сборки в Cloud Build. Настроить Binary Authorization так, чтобы требовать подписи и успешное прохождение сканирования перед развертыванием в GKE. Обоснование: блокировать ненадёжные или уязвимые артефакты на этапе применения политик.

4. Моделировать доставку с помощью Cloud Deploy

   • Определить конвейер доставки с целевыми средами dev, staging, prod и канареечной стратегией для prod. Требовать ручное утверждение для prod с участием утверждающих на основе ролей. Обоснование: неизменяемое продвижение по средам и аудируемые утверждения.

   • clouddeploy.yaml (фрагмент):

undefined

5. Маршрутизировать API v1 и v2 под одним именем хоста
   • Настроить внешний HTTP(S) Load Balancer с отдельными бэкенд-сервисами для путей /v1 и /v2, каждый из которых указывает на соответствующий NEG в GKE. Обоснование: чистая изоляция на основе путей, общий сертификат и DNS, независимое развертывание.

   • Пример (фрагмент):

undefined

6. Управлять инфраструктурой с помощью Terraform
   • Создать модули для VPC, GKE, Artifact Registry, сервисных аккаунтов и IAM. Хранить удаленное состояние в бакете Cloud Storage, защищенном с помощью CMEK, с версионированием и политикой хранения. Применять политики OPA в CI для предотвращения рискованных изменений. Обоснование: повторно используемое, проверяемое и управляемое предоставление платформы.

undefined

7. Настроить Kubernetes с помощью Helm/Kustomize и GitOps

   • Поддерживать базовые манифесты для API и оверлеи для каждой среды с помощью Kustomize. Использовать Config Sync или Argo CD для приведения состояния кластеров в соответствие с состоянием в Git. Обоснование: декларативные, аудируемые и устойчивые к дрейфу конфигурации операции.

8. Прогрессивная доставка с помощью канареечных релизов и флагов функциональности

   • Использовать канареечное развертывание Cloud Deploy для prod и SDK для флагов функциональности (OpenFeature) для контроля доступа к новой логике. Начать с 5% трафика, автоматически продвигать релиз при соблюдении SLO; автоматически откатывать при ухудшении показателей и использовать флаг как аварийный выключатель (kill switch). Обоснование: уменьшить радиус поражения и отделить развертывание от релиза.

9. Контроль качества и верификация

   • Этапы конвейера: модульные тесты → интеграционные тесты в эфемерной среде → сканирование контейнера → проверки политик → сквозные тесты в среде staging → канареечный релиз в prod с автоматизированной верификацией на основе SLO (Cloud Monitoring, Error Reporting, Trace). Обоснование: быстрая обратная связь на ранних этапах, надежная защита перед развертыванием в prod и объективные проверки работоспособности после развертывания.

10. Эксплуатация, логирование и аудит

    • Установить агенты Cloud Logging/Monitoring для вспомогательных ВМ и включить сбор логов/метрик рабочих нагрузок GKE. Экспортировать логи CI/CD и Audit Logs в BigQuery с представлениями с ограниченным доступом для аудиторов. Поддерживать ранбуки (включая процедуры безопасного отката и экстренного переключения DNS или LB). Обоснование: наблюдаемость для быстрого устранения проблем и доказательства соответствия требованиям.

Такая архитектура обеспечивает скорость за счет процесса разработки на основе основной ветки и автоматизированных конвейеров; безопасность — за счет канареечных релизов, флагов функциональности и Binary Authorization; аудируемость — за счет неизменяемых артефактов, утверждений и централизованных логов; и четкое владение — через CODEOWNERS и управляемые с помощью GitOps среды.

← Эксплуатация · Все домены · Стоимость →

Отработать эти вопросы → · Тесты на время на ExamRoll.io →

Просмотреть Google →