Google PCA: Миграция, модернизация и стратегия гибридного облака — Руководство по подготовке

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

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

Обзор

Успешная стратегия миграции, модернизации и гибридного облака согласовывает выбор платформы с бизнес-результатами, управляя при этом рисками для доступности, целостности данных, задержек, безопасности и затрат. Этот путь сочетает быстрый rehost для снижения рисков, связанных с дата-центром, и целевой рефакторинг для получения преимуществ облака. Операционная модель должна развиваться вместе с технологией для поддержания улучшений. В этом разделе представлен прагматичный план для оценки и планирования волн миграции, принципы принятия решений, механика миграции, гибридная интеграция, паттерны модернизации, соображения по политикам и мультиоблачным средам, а также оптимизация после миграции с акцентом на режимы отказа и компромиссы.

Оценка, готовность и планирование волн миграции

• Обнаружение и анализ зависимостей

  • Проведите инвентаризацию рабочих нагрузок, версий, ядер ОС, хранилищ, IAM и классификаций данных. Составьте карту зависимостей для потоков web→API→DB, общих служб (LDAP/AD, DNS, NTP), пакетных конвейеров и внешних API.
  • Используйте профилирование приложений и распределенную трассировку в средах перед миграцией, чтобы выявить скрытые зависимости и задержки в «длинном хвосте». Включите VPC Flow Logs и инструментацию на уровне приложений (Cloud Logging, Cloud Monitoring, Cloud Trace).
  • Определите границы состояния и «гравитацию» данных: размер, паттерны доступа (соотношение R/W), требования к согласованности и топологию репликации.

• Готовность и навыки

  • Оцените навыки в области основ облака, IaC, CI/CD, SRE, безопасности, сетей и баз данных. Определите дорожную карту обучения и сертификации для разных ролей и заложите в бюджет время на повышение квалификации и теневые дежурства (shadow on-calls).
  • Создайте целевую зону (landing zone) — проекты, папки, Shared VPC, политики организации, приемники аудита (audit sinks), стратегию CMEK — до начала первой волны миграции.

• Планирование волн миграции

  • Сгруппируйте приложения в волны по сходству и радиусу поражения (blast radius): общие данные, синхронные зависимости и окна для изменений. Переносите зависимости с высоким риском в ту же волну или заменяйте их заглушками (stub) с четко определенными контрактами API.
  • Определите для каждой волны SLO, RTO/RPO, критерии отката и контрольные точки валидации (validation gates): проверки схем, синтетические пользовательские сценарии, пороговые значения производительности.
  • Подготовьте ранбуки (runbooks) и управление изменениями: шаги переключения, контрольные точки, откат и сбор подтверждений для утверждения.

• Совместимость, лицензирование и базовые показатели производительности

  • Проверьте поддержку ОС и промежуточного ПО (middleware) в Compute Engine и управляемых сервисах. Проверьте условия коммерческого лицензирования, ограничения BYOL, требования к модулям ядра и привязки к оборудованию (hardware affinities).
  • Соберите базовые показатели CPU, памяти, IOPS, пропускной способности и задержек с пиковыми значениями и 95-м перцентилем для определения размеров целевых ресурсов и подтверждения преимуществ.

• Управление данными

  • Классифицируйте данные PII/PCI. Спланируйте деидентификацию или токенизацию на этапе приема данных с помощью Cloud DLP. Определите политики аудита, хранения и экспорта до сохранения первого производственного лога.

Распространенные режимы отказа: неизвестные синхронные зависимости, вызывающие каскадные тайм-ауты после переключения; пересекающиеся диапазоны IP-адресов, блокирующие сетевое соединение; пробелы в соблюдении лицензионных соглашений; отсутствие паритета при откате, когда изменения данных невозможно отменить.

Стратегии миграции, перемещение данных и переход

• Система принятия решений (6R)

  • Rehost (перенос): перенос «как есть» в Compute Engine. Самый быстрый способ миграции в облако, минимальные изменения. Риск: сохранение технического долга и неэффективное выделение ресурсов.
  • Replatform (оптимизация платформы): небольшие изменения для внедрения управляемых сервисов (например, Cloud SQL, Cloud Load Balancing). Быстрое получение преимуществ в эксплуатации при минимальных изменениях кода.
  • Refactor (рефакторинг): декомпозиция или контейнеризация для GKE/Cloud Run; внедрение событийно-ориентированных архитектур. Наибольшая долгосрочная выгода с риском для сроков реализации.
  • Retire (вывод из эксплуатации): удаление неиспользуемых систем после подтверждения отсутствия их использования и зависимостей.
  • Retain (сохранение): сохранение в локальной среде по нормативным причинам или из-за требований к задержке; интеграция через гибридную модель.
  • Relocate (перемещение): перенос рабочих нагрузок vSphere в Google Cloud VMware Engine; сохраняет инструментарий и минимизирует изменения.

• Инструменты для миграции вычислительных ресурсов и баз данных

  • Migrate to Virtual Machines ускоряет перенос (rehost) в Compute Engine, сохраняя диски и конфигурацию сети. Проверьте поддержку гостевой ОС и драйверов ядра.
  • Database Migration Service обеспечивает однородную онлайн-репликацию (например, MySQL, PostgreSQL) в Cloud SQL с минимальным временем простоя. Убедитесь, что настройки binlog/репликации корректны, а задержка позволяет наверстывать отставание почти в реальном времени.
  • Выбирайте базы данных в соответствии с рабочей нагрузкой:
    • Cloud SQL для управляемых реляционных СУБД; включите автоматическое увеличение хранилища и отслеживайте загрузку ЦП на уровне около 75% на ядро; следите за задержкой репликации и выполняйте шардирование или вертикальное масштабирование при приближении к пороговым значениям.
    • Bigtable для сбора временных рядов (например, данных с датчиков) с низкой задержкой и высокой пропускной способностью.
    • Spanner для глобального масштабирования и строгой согласованности; понимайте компромисс между привязкой к платформе (lock-in) и переносимостью.
  • Перемещение данных
    • Storage Transfer Service для постоянных или запланированных передач; поддерживает распараллеливание и повторные попытки.
    • Transfer Appliance для однократной массовой загрузки (десятки-сотни ТБ) для сокращения времени и рисков сетевой передачи.
    • gsutil и параллельные составные загрузки (parallel composite uploads) для наборов данных малого и среднего размера.

• Онлайн- и офлайн-миграция

  • Онлайн: непрерывная репликация с коротким периодом перехода. Плюсы: минимальное время простоя; Минусы: требует стабильной задержки и пропускной способности; необходимо избегать проблем с двойной записью.
  • Офлайн: создание снимка и массовый импорт. Плюсы: простота и предсказуемость; Минусы: время простоя равно времени копирования.

• Планирование перехода, откат и контроль времени простоя

  • За несколько дней до перехода уменьшите DNS TTL, заморозьте несущественные изменения и запланируйте окно для технического обслуживания.
  • Выполните этапы валидации: проверка соответствия схем, контрольные суммы или количество строк, дымовое тестирование приложения, канареечный трафик и проверка производительности.
  • Откат: убедитесь в наличии обратно совместимых изменений схемы, флагов функций (feature flags) и сохранении исходных данных (source-of-truth). Избегайте необратимых записей до подтверждения стабильности.
  • Пример расширения диска ВМ с минимальным временем простоя:
    • Измените размер диска в консоли или CLI: gcloud compute disks resize my-disk –size=500GB –zone=us-central1-a
    • В Linux с ext4: sudo resize2fs /dev/sdb
  • Поэтапное обновление приложения в GKE с минимальным влиянием:
    • kubectl set image deployment/echo-deployment echo-container=gcr.io/project/echo:v2

Типичные сценарии сбоев: потеря пакетов через Cloud VPN, нарушающая репликацию баз данных (используйте Dedicated Interconnect или Partner Interconnect), расхождение данных при двойной записи во время перехода, отсутствие проверок работоспособности, останавливающее поэтапные обновления.

Гибридная идентификация, подключение и интеграция с локальной средой

• Идентификация

  • Сохраняйте Active Directory как источник истины. Используйте Google Cloud Directory Sync для синхронизации учетных записей и групп и настройте SAML SSO для доступа пользователей к Google Cloud.
  • Предоставляйте минимально необходимые права доступа IAM через роли, используйте сервисные аккаунты для рабочих нагрузок и предпочитайте Workload Identity Federation долгоживущим ключам.

• Гибридное подключение и маршрутизация

  • Используйте Cloud VPN для начальных потребностей с низкой пропускной способностью и для тестирования; переходите на Dedicated Interconnect для стабильной пропускной способности, меньшей задержки и предсказуемой производительности репликации. Развертывайте резервные подключения VLAN (VLAN attachments) и HA VPN или двойные Interconnect для отказоустойчивости.
  • Убедитесь, что диапазоны IP-адресов Google Cloud не пересекаются с CIDR-блоками локальной сети, чтобы сохранить сквозную доступность.
  • Обеспечьте многоуровневый доступ с помощью правил брандмауэра и тегов. Пример, разрешающий доступ только с web на API:
    • gcloud compute firewall-rules create allow-web-to-api –network=prod-vpc –direction=INGRESS –action=ALLOW –rules=tcp:8443 –source-tags=web –target-tags=api
  • Используйте Private Service Connect и частный доступ к Google (private Google access) для взаимодействия между сервисами без выхода в публичный интернет; сегментируйте с помощью VPC Service Controls, где это необходимо.
  • Гибридный DNS: используйте Cloud DNS с перенаправлением и политиками для входящего/исходящего трафика для разрешения имен как в локальной сети, так и в облаке.

• Интеграция с локальной средой и задержка

  • Держите состояние близко к вычислительным ресурсам или наоборот; если локальная БД должна оставаться основной, рассмотрите использование App Engine flexible или Compute Engine с Cloud VPN/Interconnect для частного доступа.
  • Внедряйте кэши и очереди, чтобы развязать синхронные пути и сглаживать колебания задержки; измеряйте задержку p95/p99, а не только средние значения.

Типичные сценарии сбоев: пересекающиеся CIDR-блоки, блокирующие маршруты, недостаточная избыточность сессий BGP, утечки через публичный DNS или исходящий трафик (egress), раскрывающие частные сервисы, а также непредвиденно «разговорчивые» протоколы, страдающие от соединений с высокой задержкой.

Модернизация, операционная модель и оптимизация

• Паттерны модернизации унаследованных систем

  • Удушающий инжир (Strangler fig): размещение API-фасада перед монолитом и постепенное перенаправление доменов на новые сервисы.
  • Контейнеризация: стандартизация базовых образов (предпочтительно использовать компактные образы, например Alpine, если они совместимы), упорядочивание слоев Dockerfile для кэширования установки зависимостей до копирования исходного кода для сокращения времени сборки и внедрение конвейера CI/CD с автоматизированным тестированием в промежуточной среде (staging).
  • Управляемые сервисы данных: перенос операционных хранилищ в управляемые базы данных; выбор в зависимости от домена: Cloud SQL для транзакционных нагрузок, Bigtable для временных рядов, Spanner для глобально согласованных рабочих нагрузок.

• Проверка совместимости, согласованности и производительности приложений

  • Подтвердите поддержку ОС и промежуточного ПО (middleware), лимиты потоков и соединений, а также семантику файловой системы. Проверьте переносимость лицензий и учет использования.
  • Определите требования к согласованности данных (чтение собственных записей, монотонное чтение, итоговая или строгая согласованность). Соотнесите их с целевыми базами данных и шаблонами доступа.
  • Проверьте производительность с помощью нагрузочных тестов и синтетических пользовательских сценариев; убедитесь, что бюджеты SLO достижимы после миграции.

• Наблюдаемость и соответствие требованиям

  • Инструментируйте приложения с помощью Cloud Logging, Monitoring и Trace для локализации задержек в микросервисах.
  • Экспортируйте журналы аудита и изменения политик IAM в BigQuery и предоставляйте к ним доступ аудиторам через представления и IAM на наборах данных. Экспортируйте долгосрочные метрики в Cloud Storage для выполнения требований по многолетнему хранению.

• Операционная модель и владение

  • Внедрите практики SRE: SLO, бюджеты ошибок, реагирование на инциденты и ретроспективы без поиска виновных. Определите владельцев сервисов, ранбуки и ротацию дежурств.
  • Используйте IaC (например, Terraform) для согласованного развертывания инфраструктуры. Помните, что Deployment Manager является специфичным для Google инструментом, что может ограничить автоматизацию ресурсов в мультиоблачной среде и быть незнакомым многим инженерам.
  • Автоматизируйте согласованность политик с помощью Organization Policy, IAM Conditions, Config Sync и Policy Controller (OPA Gatekeeper) в разных проектах и средах.

• Мультиоблачная стратегия и компромиссы, связанные с привязкой к поставщику

  • Повышайте переносимость с помощью Kubernetes, практик 12-факторных приложений, контрактов, определенных через OpenAPI, и абстракций для вывода данных. Сбалансируйте переносимость с операционной нагрузкой и производительностью; управляемые сервисы снижают ручной труд, но могут увеличить стоимость перехода к другому поставщику.

• Оптимизация затрат и производительности; вывод из эксплуатации

  • Масштабируйте stateless-сервисы на Compute Engine с помощью управляемых групп экземпляров и автомасштабирования; выбирайте бессерверные решения (Cloud Functions или Cloud Run) для пиковых или MVP-нагрузок, которым выгодно масштабирование до нуля.
  • Подбирайте оптимальный размер ВМ, включайте автомасштабирование в GKE, применяйте скидки за зарезервированное использование и выводите из эксплуатации неиспользуемые артефакты. Отслеживайте реализацию преимуществ через KPI (доступность, задержка, стоимость обслуживания).
  • Выводите из эксплуатации локальные системы после периода охлаждения и подтверждения зависимостей. Архивируйте или удаляйте данные в соответствии с политикой хранения и обновите CMDB.

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

Acme Weather Networks должна перенести свою платформу сенсоров реального времени и унаследованный UI администратора на J2EE из локального дата-центра в Google Cloud. Система получает данные от 50 000 сенсоров, отправляющих по 10 показаний в секунду, и хранит исторические данные за пять лет (75 ТБ). Необходимо сохранить частный доступ к локальным ERP и Active Directory во время перехода, минимизировать время простоя для локальной базы данных MySQL и устранить периодические сбои репликации, наблюдаемые через VPN.

1. Создать безопасную целевую зону

   • Создайте организацию, папки и проекты для prod/non-prod сред. Настройте Shared VPC с непересекающимися IP-диапазонами, чтобы обеспечить доступность локальных ресурсов через гибридное подключение. Примените политики организации и централизованный экспорт журналов аудита в BigQuery с доступом по принципу наименьших привилегий.
   • Обоснование: Предотвращение конфликтов маршрутизации и обеспечение базового управления до развертывания рабочих нагрузок.

2. Внедрить гибридную идентификацию

   • Настройте Google Cloud Directory Sync для зеркалирования удостоверений и групп из AD и настройте SAML SSO. Используйте сервисные аккаунты и кастомные роли IAM для платформы и рабочих нагрузок.
   • Обоснование: Сохранение корпоративной системы идентификации в качестве источника истины и обеспечение контроля доступа по принципу наименьших привилегий.

3. Обеспечить подключение и спланировать производительность

   • Начните с HA Cloud VPN для сред разработки и тестирования. Для репликации производственной базы данных и стабильного приема данных с сенсоров разверните Dedicated Interconnect с двумя подключениями VLAN и сессиями BGP.
   • Обоснование: Interconnect обеспечивает меньшую задержку и меньше потерь пакетов по сравнению с VPN, что стабилизирует репликацию MySQL и потоковый прием данных.

4. Эффективно перенести исторические данные

   • Закажите Transfer Appliances, загрузите набор данных объемом 75 ТБ локально, отправьте и восстановите в Cloud Storage. Используйте Storage Transfer Service для последующих инкрементальных обновлений, если это необходимо. Запустите Cloud DLP на журналах поддержки для деидентификации PII перед сохранением в Bigtable или BigQuery.
   • Обоснование: Офлайн-перенос больших объемов данных снижает риски в окне переключения и позволяет избежать перегрузки каналов связи.

5. Перенести (rehost) UI администратора на J2EE

   • Используйте Migrate to Virtual Machines для переноса (lift-and-shift) ВМ с J2EE на Compute Engine. Разместите экземпляры в управляемой группе экземпляров за балансировщиком нагрузки HTTP(S). Примените правила брандмауэра по тегам, чтобы разрешить только потоки web→API→DB. Пример:

undefined

• Обоснование: Быстрое снижение рисков с использованием знакомой среды выполнения при одновременном обеспечении сетевых путей с наименьшими привилегиями.

6. Мигрировать MySQL в Cloud SQL с минимальным простоем

   • Оцените базовую производительность и включите бинарное логирование на источнике. Используйте Database Migration Service для настройки непрерывной репликации в Cloud SQL. Включите автоматическое увеличение хранилища и создайте оповещения о загрузке ЦП около 75% и задержке репликации менее 60 секунд.
   • Обоснование: Онлайн-миграция обеспечивает минимальное время простоя; управляемый SQL снижает ручной труд и обеспечивает соблюдение операционных SLO.

7. Выполнить контролируемое переключение

   • За 48 часов до переключения уменьшите TTL для DNS, заморозьте изменения схемы и запланируйте окно обслуживания. Остановите запись в локальную БД, убедитесь, что задержка DMS равна нулю, выполните проверку контрольных сумм и дымовые тесты приложения, а затем перенаправьте клиентов на Cloud SQL. Подготовьте план отката, по которому запись может быть перенаправлена обратно в локальную систему в случае сбоя проверки.
   • Обоснование: Детерминированные шаги ограничивают RTO и поддерживают согласованность данных.

8. Построить систему сбора телеметрии в реальном времени

   • Принимайте данные через Pub/Sub, обрабатывайте с помощью Dataflow и храните временные ряды в Bigtable для записи и чтения с низкой задержкой. Сохраняйте интеграцию с ERP приватной через Interconnect.
   • Обоснование: Bigtable соответствует профилю высокопроизводительных временных рядов, а Pub/Sub разделяет пиковые нагрузки от производителей и потребителей.

9. Контейнеризировать сервисы и внедрить CI/CD

   • Контейнеризируйте stateless-сервисы для GKE. Оптимизируйте Dockerfile, используя компактные базовые образы и упорядочивая слои так, чтобы установка зависимостей предшествовала копированию исходного кода. Внедрите конвейер CI/CD с автоматизированными тестами в промежуточной среде и canary-развертываниями. Обновляйте с минимальным простоем:

undefined

• Обоснование: Улучшает скорость, надежность и масштабируемость развертывания без кардинальной переработки.

10. Улучшить наблюдаемость и аудит

    • Инструментируйте Cloud Logging, Monitoring и Trace для точного определения задержек в микросервисах. Экспортируйте журналы аудита в BigQuery и предоставляйте аудиторам представления с ограниченным доступом. Экспортируйте долгосрочные метрики в Cloud Storage для выполнения требований по пятилетнему хранению.
    • Обоснование: Полноценная телеметрия поддерживает SLO и соответствие требованиям.

11. Оптимизировать и вывести из эксплуатации

    • Включите автомасштабирование на MIG и в GKE, подберите оптимальный размер экземпляров, примените скидки за зарезервированное использование и запланируйте запуск некруглосуточных нагрузок на бессерверных платформах (например, Cloud Functions для вспомогательных задач) для масштабирования до нуля. После периода стабильности и охлаждения выведите из эксплуатации локальные системы, обновите CMDB и опубликуйте отчет о полученных выгодах.
    • Обоснование: Достижение экономии затрат и операционной эффективности при одновременном устранении расходов на параллельную работу двух систем.

12. Ввести в эксплуатацию и обучить персонал

    • Финализируйте ранбуки, матрицу RACI, ротацию дежурств и бюджеты SLO/ошибок. Проведите целевое обучение и разработайте планы сертификации для устранения пробелов в навыках. Предпочитайте Terraform для IaC; учтите, что Deployment Manager является специфичным для Google инструментом и может не подходить для управления ресурсами вне Google.
    • Обоснование: Зрелая операционная модель поддерживает надежность и скорость разработки после завершения миграции.

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

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

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