Google PCD: Тестирование, инженерия качества и безопасное управление релизами — Руководство по подготовке

By Laurynas Brazys · 4 September 2026 · #google #PCD #certification #exam-prep #study-guide

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

Обзор

Высокопроизводительные команды в Google Cloud сочетают тщательное тестирование с прогрессивной доставкой, чтобы снизить риски и ускорить внесение изменений. Надежная стратегия охватывает все: от модульных до сквозных тестов, симуляцию реалистичных данных и зависимостей, автоматизированные проверки качества и контролируемые модели выпуска, такие как канареечные и сине-зеленые развертывания. Наблюдаемость, ответственность и дисциплинированная проверка после релиза замыкают цикл. В этом разделе подробно описывается, как проектировать системы с учетом надежности, изолировать риски и безопасно продвигать сборки по средам с помощью сервисов Google Cloud.

Стратегия тестирования и управление данными

Пирамида тестирования и типы тестов

Модульные тесты: быстрая, изолированная проверка функций, классов и небольших модулей. Они должны составлять основную часть набора тестов. Запускайте их при каждом коммите и pull request.
Интеграционные тесты: проверяют взаимодействие между компонентами, такими как приложение и его хранилище данных или очередь. Используйте эмуляторы Google Cloud, где это возможно.
Контрактные тесты: контракты, управляемые потребителем (consumer-driven contracts) для микросервисов, предотвращают несовместимые изменения API. Проверяйте поведение поставщика на соответствие ожидаемой схеме и семантике потребителя перед интеграцией. Используйте Pact или аналогичные инструменты; версионируйте API и публикуйте схемы.
Сквозные тесты: проверяют полный путь системы, используя конфигурацию, идентификационные данные и сетевые политики, близкие к производственным. Ограничьте их количество, распараллеливайте и запускайте в предпроизводственных средах.
Дымовые тесты: минимальные проверки, подтверждающие, что критически важные зависимости, маршруты и проверки работоспособности ведут себя корректно после каждого развертывания. Это ваша первая проверка после развертывания.

Управление тестовыми данными, изоляция, воспроизводимость и паритет сред

Наполнение данными (seeding): генерируйте небольшие, детерминированные наборы данных для модульных тестов и более крупные, репрезентативные наборы для интеграционных/производительных тестов. Наполняйте данными из фикстур, зафиксированных в системе контроля версий.
Изоляция: убедитесь, что тесты не используют общее состояние. Используйте эфемерные базы данных, изолированные пространства имен GKE и уникальные префиксы для объектов Cloud Storage. Для SQL создавайте схемы для каждого теста; для Pub/Sub генерируйте временные топики/подписки.
Воспроизводимость: закрепляйте версии зависимостей, делайте сборки герметичными и фиксируйте случайные начальные значения (random seeds). Храните тестовые контейнеры с дайджестами в Artifact Registry.
Паритет сред: стандартизируйте образы контейнеров и инфраструктуру как код (infrastructure-as-code) для сред разработки, QA, стейджинга и продакшена. Храните конфигурацию вне образов и используйте метаданные и секреты для конкретной среды. Для Compute Engine храните значения для каждого развертывания в метаданных шаблона экземпляра; для паритета между проектами настройте ключ метаданных среды и считывайте его при запуске для выбора конфигурации, специфичной для данной среды.

Моки, эмуляторы, фейки и песочницы

Моки/стабы: заменяйте взаимодействующие компоненты на уровне модульных тестов, чтобы изолировать логику и избежать сетевых вызовов. Избегайте избыточного мокирования; проверяйте поведение, а не детали реализации.
Эмуляторы: предпочитайте официальные эмуляторы для интеграционных тестов. Примеры: эмуляторы Firestore/Datastore, Pub/Sub, Spanner и Bigtable. Они обеспечивают точность API без затрат на облачные ресурсы и ускоряют CI.
Фейки: когда эмулятор отсутствует, запускайте легковесные локальные фейки (например, фейковое хранилище объектов) или общие сервисы-песочницы с сильной изоляцией и квотами.
Симуляция внешних зависимостей: для сторонних API запускайте фейки на основе контрактов за service mesh или API gateway; настраивайте тайм-ауты, повторные попытки и внедрение хаоса (chaos injection) для тестирования обработки сбоев.

Распространенные режимы сбоев и компромиссы

Чрезмерная зависимость от сквозных тестов замедляет итерации; вкладывайтесь в модульные и контрактные тесты, чтобы выявлять проблемы раньше.
Общие, долгоживущие тестовые среды накапливают расхождения в конфигурации (drift) и загрязнение данных. Предпочитайте эфемерные среды и идемпотентную настройку/очистку.
Эмуляторы могут не идеально повторять производственную среду. Используйте сквозные тесты на стейджинге с реальными сервисами перед продвижением в продакшен.

Краткий пример Cloud Build для разделения этапов со сбоями

steps:
- name: gcr.io/cloud-builders/gcloud
  entrypoint: bash
  args: ['-c', 'make compile && make unit']
- name: gcr.io/cloud-builders/gcloud
  entrypoint: bash
  args: ['-c', 'docker build -t $IMAGE .']
- name: gcr.io/cloud-builders/gcloud
  entrypoint: bash
  args: ['-c', 'make integration']  # run against emulators or ephemeral env
images: ['$IMAGE']

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

Нефункциональное тестирование и качество кода

Тестирование производительности

Типы: нагрузочное (постоянная нагрузка), стресс-тестирование (за пределами пиковой нагрузки), тестирование на выносливость (длительное) и тестирование емкости.
Инструменты: используйте Cloud Monitoring для SLO и оповещений, Cloud Trace для анализа задержек и Cloud Profiler для выявления узких мест. Для GKE масштабируйтесь с помощью Cluster Autoscaler и HPA; для обработчиков Pub/Sub HPA по внешним метрикам справляется с масштабированием при резких скачках нагрузки.
Тестирование в производственной среде: используйте темные запуски (dark launches) и зеркалирование запросов для безопасной оценки новых бэкендов с производственным трафиком. External HTTP(S) Load Balancing поддерживает зеркалирование запросов; Anthos Service Mesh поддерживает теневой трафик (traffic shadowing).

Тестирование безопасности

SAST/сканирование секретов: запускайте статические анализаторы в CI и отклоняйте жестко закодированные учетные данные. Храните секреты в Secret Manager с доступом по принципу наименьших привилегий.
Сканирование зависимостей и образов: включите Container Analysis в Artifact Registry. Применяйте политики с помощью Binary Authorization, требуя аттестации об отсутствии критических уязвимостей перед развертыванием.
DAST: сканируйте стейджинг-среды с помощью аутентифицированных сканеров и блокируйте релизы при обнаружении критических уязвимостей.

Доступность и регрессионное тестирование

Доступность: интегрируйте автоматические проверки доступности (a11y), например, Lighthouse CI, в неблокирующие проверки перед слиянием; исправляйте проблемы до релиза.
Регрессионные наборы: поддерживайте отобранные, стабильные наборы регрессионных тестов для критически важных пользовательских путей. Запускайте дымовые тесты при каждом развертывании и полный регресс на кандидатах в релиз.

Статический анализ, проверки качества и рецензирование кода

Статический анализ: настройте соответствующие языку линтеры и форматеры как проверки перед отправкой кода (pre-submit checks). Используйте Bazel или аналогичные инструменты для распараллеливания.
Проверки качества (Quality gates): прерывайте сборку при нарушении пороговых значений (покрытие тестами, сложность, ошибки линтера). Публикуйте результаты в логах Cloud Build.
Рецензирование кода: требуйте рецензирования двумя людьми для рискованных изменений, используйте CODEOWNERS для критически важных путей и запускайте presubmit CI для тегов, используемых в релизах.
Цепочка поставок: генерируйте SBOM, подписывайте артефакты и храните данные о происхождении (provenance). Применяйте проверки аттестации в Binary Authorization.

Прогрессивная доставка и безопасные релизы

Стратегии развертывания

Rolling (поэтапное обновление): Постепенная замена подов или экземпляров. Низкий риск для сервисов без состояния (stateless); сочетайте с проверками готовности (readiness probes) и настройками всплеска/доступности (surge/availability).
Blue-green (сине-зеленое): Запуск полностью новой среды, выполнение проверки, затем переключение трафика. Обеспечивает мгновенный откат путем возврата конфигурации балансировщика нагрузки. Идеально, когда требуется немедленное возвращение к предыдущей версии.
Canary (канареечное): Постепенное перенаправление небольшого процента трафика на новую версию с одновременным отслеживанием ключевых метрик. Автоматизируйте продвижение версии, если она стабильна, и выполняйте откат при регрессиях.
Traffic splitting (разделение трафика): Маршрутизация по процентному соотношению или атрибутам (заголовки, cookie, user-agent) с помощью GKE и Anthos Service Mesh, или использование встроенного разделения в Cloud Run и App Engine.

Функциональные флаги и эксперименты

Функциональные флаги: Отделите развертывание от релиза. Используйте флаги для постепенного выката, аварийных выключателей (kill switches) и переключателей экспериментов. Храните их централизованно (например, в управляемом сервисе флагов или в хранилище конфигураций, защищенном IAM). Сохраняйте жизненный цикл флагов коротким и удаляйте лишнее.
Темные запуски (Dark launches): Развертывание отключенных функций; проверка с помощью внутренних пользователей или синтетического трафика.
Теневой трафик (Shadow traffic): Дублирование производственных запросов на новые сервисы без влияния на пользователей; сравнение ответов для выявления регрессий.
Контролируемые эксперименты: Реализация A/B или многовариантной маршрутизации с помощью правил service mesh. Для экспериментов на основе user-agent используйте маршрутизацию по совпадению заголовка.

Шлюзы, утверждения, откат и наблюдаемость

Шлюзы развертывания: Добавьте интеграционные тесты перед развертыванием (predeploy) и дымовые/проверки работоспособности после развертывания (postdeploy). Для продвижения между средами используйте триггеры на основе тегов, чтобы отделить сборку от релиза.
Ручные утверждения: Требуйте подтверждения от человека на ключевых этапах, например, при переходе от staging к production. Cloud Deploy поддерживает шаги ручного утверждения для каждой цели (target).
Автоматический откат: Определите SLO и политики оповещений; когда канареечная версия нарушает пороговые значения частоты ошибок или задержки, автоматически выполняйте откат, вызывая deploy API. Поддерживайте быстрые и хорошо отработанные процедуры отката.
Наблюдаемость релизов: Инструментируйте релизы, добавляя метки версий в метрики и логи. Экспортируйте метрики Prometheus в Cloud Monitoring и создавайте метрики на основе логов для анализа шаблонов ошибок, чтобы эффективно коррелировать телеметрию с затратами.

Краткий пример маршрутизации в ASM для канареечного релиза на основе заголовков

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
spec:
  http:
  - match:
    - headers:
        user-agent:
          regex: ".*Android.*"
    route:
    - destination: { host: svc, subset: v2 }  # canary
  - route:
    - destination: { host: svc, subset: v1 }  # stable

Надёжность тестов, циклы обратной связи и дисциплина после релиза

Управление нестабильными (flaky) тестами и надёжность

Обнаружение и изоляция: Отслеживайте нестабильность тестов со временем; изолируйте известные нестабильные тесты и не блокируйте ими релизы, при этом приоритизируя их исправление.
Тайм-ауты и повторные попытки: Добавьте разумные тайм-ауты; разрешите одну повторную попытку для предполагаемых сбоев инфраструктуры, а не для логических ошибок.
Герметичные сборки: Избегайте сетевых вызовов в юнит-тестах; закрепляйте версии артефактов и используйте эмуляторы для уменьшения недетерминизма.
Распараллеливание: Разделяйте тесты в Cloud Build на несколько шагов или воркеров, чтобы минимизировать задержку обратной связи.

Циклы обратной связи

Триггеры CI: Запускайте юнит- и интеграционные тесты при каждом коммите в main и в pull-запросах. Используйте отдельные шаги в Cloud Build, чтобы история сборок показывала этап, на котором произошёл сбой. Создавайте триггеры релиза на Git-тегах, а не на каждом коммите, чтобы контролировать развёртывания.
Прогрессивная верификация: Автоматически продвигайте сборку из dev в test после успешного развёртывания, подписавшись на уведомления Cloud Deploy Pub/Sub и вызывая продвижение при событиях SUCCEEDED.
Продвижение на основе метрик: Для канареечных развёртываний управляйте увеличением трафика на основе метрик Cloud Monitoring и SLO.

Документация к релизу, владение и верификация после релиза

Документация: Ведите заметки о релизе, инструкции (runbooks) и процедуры отката рядом с кодом. Отслеживайте заявки на изменения со ссылками на коммиты, образы и версии окружений.
Владение: Определите ротацию дежурных и владельцев компонентов; используйте CODEOWNERS для критически важных областей. Убедитесь в наличии чётких утверждающих для продвижения в продакшен.
Верификация после релиза: Выполняйте дымовые тесты (smoke suites), следите за состоянием бюджетов ошибок и проверяйте дашборды по тегу версии. Убедитесь, что отчёты о безопасности и уязвимостях остаются в рамках политики. При возникновении проблем сначала выполняйте откат, а затем ищите первопричину.

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

Платформенная команда Acme Retail стандартизирует тестирование и релизы для приложения на базе микросервисов в GKE, которое также включает stateless веб-фронтенд в Cloud Run. Они должны обеспечить быструю обратную связь, блокировать рискованные сборки и безопасно развёртывать новые функции, используя реальный трафик для оценки производительности.

Подход

Разделение этапов сборки и тестирования в Cloud Build

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

steps:
- name: gcr.io/cloud-builders/docker
  args: ['build', '-t', '$IMAGE', '.']
- name: gcr.io/cloud-builders/gcloud
  args: ['bash','-lc','make unit']
- name: gcr.io/cloud-builders/gcloud
  args: ['bash','-lc','make integration']  # against emulators
images: ['$IMAGE']

Запуск интеграционных тестов с использованием эмуляторов и эфемерных пространств имён

Обоснование: Для воркеров Pub/Sub и сервисов, использующих Firestore, применяйте эмуляторы Pub/Sub и Firestore. Для сервисов, требующих политик кластера, создавайте эфемерное пространство имён GKE для каждой сборки с временными топиками и сервисными аккаунтами через Workload Identity. Это обеспечивает изоляцию, скорость и низкую стоимость при сохранении точности тестов.

Применение шлюзов качества безопасности с помощью Artifact Registry и Binary Authorization

Обоснование: Включите сканирование уязвимостей при отправке образа, прерывайте пайплайн при обнаружении критических CVE и требуйте аттестации в Binary Authorization перед развёртыванием в GKE. Это предотвращает развёртывание образов с известными критическими уязвимостями.

Использование триггеров релиза на основе Git-тегов

Обоснование: Триггеры Cloud Build, срабатывающие на теги (например, vX.Y.Z), позволяют автоматизировать релизы только для явно помеченных коммитов, избегая случайных развёртываний в продакшен из каждого коммита в main.

Прогрессивная доставка с помощью Cloud Deploy и Anthos Service Mesh

Обоснование: Определите пайплайн Cloud Deploy с целевыми окружениями dev, test и prod. Используйте ручное утверждение для контроля продвижения в prod. Для prod используйте канареечную стратегию с ASM для переключения трафика на 5%, 25%, 50%, 100%, отслеживая при этом SLO. Cloud Deploy подписывается на хуки верификации; сбой автоматически останавливает или откатывает канареечное развёртывание через API.

Наблюдаемость и автоматизированные хуки для отката

Обоснование: Экспортируйте метрики Prometheus в Cloud Monitoring и создавайте метрики на основе логов для сигнатур ошибок. Настройте политики оповещений на метриках с метками версий. Cloud Function, подписанная на оповещения, вызывает API Cloud Deploy для приостановки или отката развёртывания. Это связывает объективные сигналы о состоянии системы с управлением развёртыванием.

Теневой трафик и A/B-валидация для фронтенда в Cloud Run

Обоснование: Используйте зеркалирование запросов на внешнем балансировщике нагрузки HTTP(S), чтобы направлять продакшен-запросы на новую ревизию Cloud Run, не затрагивая пользователей. Затем используйте разделение трафика в Cloud Run для переключения небольших процентов и сравнения метрик задержки/ошибок перед полным переключением.

Резервный откат по схеме «синий-зелёный» для критически важных бэкенд-сервисов

Обоснование: Для сервисов, требующих мгновенного отката, поддерживайте «синее» и «зелёное» развёртывания за одним бэкенд-сервисом. Проверяйте «зелёное» развёртывание с помощью дымовых и контрактных тестов, затем переключайте трафик. Мгновенно возвращайтесь на предыдущую версию при появлении аномалий.

Верификация и документирование после релиза

Обоснование: После продвижения сборки запустите автоматические дымовые тесты, проверьте дашборды по версии релиза и обновите заметки о релизе, добавив дайджесты артефактов и историю развёртывания. Владельцы и дежурные принимают ответственность; если бюджеты ошибок начинают исчерпываться, сначала выполняется откат, а затем проводится анализ без поиска виновных.

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

← Производительность · Все домены · Стоимость →

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