Google PCA: Надежность, аварийное восстановление и непрерывность бизнеса — Руководство по подготовке

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

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

Обзор

Надежность, аварийное восстановление (DR) и непрерывность бизнеса обеспечивают соответствие сервисов согласованным целям несмотря на сбои компонентов, зон или регионов. В Google Cloud надежность проектируется через понимание доменов сбоя (зональных, региональных и глобальных), определение целевых показателей восстановления (RTO/RPO), выбор отказоустойчивых архитектур сервисов (например, active-active) и тщательное тестирование планов восстановления. Ваш проект должен соотносить критичность сервисов с четкими целями доступности, гарантиями долговечности данных и проверенными путями восстановления, балансируя между доступностью, согласованностью данных, стоимостью и операционной сложностью. Ключевые аспекты включают изоляцию единых точек отказа, использование управляемой репликации, где это возможно, автоматизацию решений по переключению на резерв и постоянную проверку того, что допущения верны в условиях, приближенных к производственным.

Домены сбоя, местоположения и мультирегиональные сервисы

Зоны доступности и регионы:
- Зоны — это независимые домены сбоя в пределах одного региона. Зональные сбои — наиболее распространенные крупномасштабные события, от которых вы проектируете защиту.
- Регионы — это совокупности зон с низкозатратными сетевыми соединениями. Региональные сбои случаются реже, но их необходимо учитывать для высококритичных систем.
- Шаблоны проектирования:
  - Внутрирегиональный: размещайте stateless-вычисления как минимум в двух зонах с помощью региональных управляемых групп инстансов (MIG).
  - Межрегиональный: реплицируйте состояние и переключайте трафик для критически важных сервисов, которые не могут пережить потерю региона.
Мультирегиональные и глобальные сервисы:
- Глобальные уровни управления: сети VPC, Cloud DNS, глобальная внешняя балансировка нагрузки HTTP(S) и Cloud IAM — это сервисы глобального уровня, используемые для уменьшения связанности между регионами.
- Размещение уровня данных имеет значение:
  - Cloud Storage: выбирайте региональные, двухрегиональные или мультирегиональные бакеты в соответствии с шаблонами доступа и потребностями в DR.
  - BigQuery: наборы данных размещаются в регионе или мультирегионе; мультирегиональное размещение повышает доступность аналитической платформы, но учитывайте требования к местоположению данных и исходящий трафик для внешних соединений.
  - Spanner: конфигурация инстанса (региональная или мультирегиональная) определяет топологию реплик и поведение согласованности данных.
Анализ доменов сбоя:
- Определите радиус поражения (blast radius) для каждого компонента. Примеры:
  - Зональный: отдельная ВМ, зональный пул узлов GKE, зональный SSD PD.
  - Региональный: основной и резервный инстансы Cloud SQL HA являются региональными; некоторые работы по обслуживанию могут затронуть весь регион.
  - Глобальный: неверная конфигурация IAM или Cloud DNS влияет на все регионы.
- Выявляйте коррелирующие сбои, такие как общие зависимости (например, один NAT-шлюз, один инстанс Memorystore) или риски, вызванные человеческим фактором (общий сервисный аккаунт, единое состояние Terraform).
- Рассматривайте квоты как домены сбоя; автомасштабировщик, достигший лимита региональной квоты, функционально не работает.

Компромиссы:

Межзональная репликация сокращает время простоя, но увеличивает межзональный трафик и затраты.
Межрегиональные архитектуры сокращают RTO, но увеличивают задержку, сложность и расходы.
Глобальная anycast-балансировка нагрузки упрощает переключение на резерв, но скрывает неработоспособные бэкенды только при точных проверках работоспособности.

Цели, картирование зависимостей и проверка DR

RTO и RPO:
- Целевое время восстановления (RTO): целевое время для восстановления сервиса. Определяет глубину автоматизации, конфигурацию резервных систем и детализацию инструкций (runbooks).
- Целевая точка восстановления (RPO): допустимый период потери данных. Определяет выбор способа репликации и частоту резервного копирования.
Критичность сервисов и их классификация:
- Определите уровни (например, Tier 0: безопасность/финансовые последствия; Tier 1: выручка; Tier 2: внутренние инструменты) с целевыми SLO, RTO/RPO и частотой тестирования.
- Привяжите расходы и сложность к уровню; не каждому сервису требуется межрегиональная архитектура.
Картирование зависимостей:
- Проведите инвентаризацию вышестоящих и нижестоящих зависимостей: идентификация (Cloud IAM, SAML IdP), секреты (Secret Manager, KMS), сеть (DNS, Cloud Interconnect/VPN), хранилища и БД, наблюдаемость, CI/CD и сторонние API.
- Задокументируйте регион, зону и SLA для каждой зависимости; определите компенсирующие меры для слабых звеньев.
Планы восстановления:
- Создайте инструкции (runbooks) и автоматизацию для переключения на резерв и обратно (failover/failback), восстановления данных и применения конфигураций (DNS, бэкенды балансировщика нагрузки, файрвол).
- Заранее подготовьте разрешения и сервисные аккаунты; разместите определения инфраструктуры для устранения ручных согласований.
- Поддерживайте экстренный доступ (break-glass access) с аудируемым повышением привилегий.
Тестирование восстановления:
- Планируйте регулярные переключения на резерв для stateful-систем (например, Cloud SQL HA) для проверки повышения роли инстанса и переустановки соединений.
- Проводите учения (game days), имитирующие зональный или региональный сбой; включайте в сценарий сбои вышестоящих провайдеров и отказы IAM/KMS.
- Используйте внедрение сбоев (fault injection) для проверки автоматических выключателей (circuit breakers), тайм-аутов и повторных попыток; убедитесь, что автомасштабирование и противодавление (backpressure) работают как задумано.
- Постоянно измеряйте RTO/RPO во время тестов; корректируйте архитектуру, если целевые показатели не достигаются.

Отказоустойчивые шаблоны для вычислительных ресурсов, баз данных и хранилищ

Самовосстанавливающиеся вычислительные ресурсы с использованием региональных MIG и балансировки нагрузки:
- Используйте региональные MIG для распределения экземпляров по зонам с автомасштабированием и автовосстановлением.
- Используйте глобальный внешний балансировщик нагрузки HTTP(S) в качестве фронтенда и проверку работоспособности бэкенд-сервиса, настроенную на реальную готовность (например, /healthz проверяет зависимости).
- Разрешите проверки работоспособности в правилах межсетевого экрана, чтобы избежать постоянного перезапуска VM:

    gcloud compute firewall-rules create allow-lb-health-checks \
      --network=prod-vpc --action=ALLOW --direction=INGRESS \
      --rules=tcp:80,tcp:443 \
      --source-ranges=130.211.0.0/22,35.191.0.0/16 \
      --target-tags=web-backend
    ```

  - Избегайте хранения состояния локально; выносите сессии в Memorystore или базы данных; используйте исчерпание подключений (connection draining) на бэкендах, чтобы сохранить выполняемые запросы во время сжатия (scale-in).
  - Распространенные сценарии сбоев: неправильно настроенные проверки работоспособности (проверяющие слишком много или слишком мало), отсутствующие правила межсетевого экрана и начальная загрузка, зависящая от неработоспособных нижестоящих сервисов.
- Отказоустойчивость Cloud SQL:
  - Высокая доступность: основной и резервный экземпляры в разных зонах с синхронной репликацией дисков и автоматическим переключением при сбое; выберите окно обслуживания и тестируйте переключение при сбое.
  - Реплики для чтения: добавьте реплики для чтения в том же или в другом регионе, чтобы разгрузить основной экземпляр от запросов на чтение и сократить RTO при региональных сбоях; повышайте реплики до основного экземпляра во время аварийного восстановления (DR).
  - Резервные копии и PITR:
    - Включите автоматическое ежедневное резервное копирование и восстановление на определенный момент времени (PITR) через бинарные/транзакционные журналы с достаточным сроком хранения для соответствия требованиям и RPO.
    - Проверяйте восстановление в непроизводственной среде, отрабатывайте процедуры повышения реплик и обновления строк подключения приложений.
  - Сеть: для производственной среды предпочитайте использовать частный IP-адрес; убедитесь, что тесты переключения при сбое проверяют поведение DNS и пулов соединений.
  - Практический совет: периодически выполняйте контролируемое переключение при сбое, чтобы убедиться, что пулы соединений приложений переподключаются корректно.

gcloud sql instances failover prod-sql
```

Конфигурация и отказоустойчивость Spanner:
- Региональные экземпляры обеспечивают операции чтения/записи с низкой задержкой и строгой согласованностью в пределах одного региона, используя Paxos между зонами.
- Мультирегиональные экземпляры реплицируются между регионами с синхронной кворумной записью (строгая глобальная согласованность) и опциональными репликами только для чтения; выбирайте ведущий регион (leader region) близко к источникам записи.
- Компромиссы: мультирегиональная конфигурация улучшает RTO/RPO и доступность на чтение, но увеличивает задержку записи и стоимость. Используйте ее для глобально распределенных, интенсивных по записи нагрузок, требующих строгой согласованности; в противном случае рассмотрите региональный Spanner или Cloud SQL с репликами.
Долговечность и шаблоны восстановления Cloud Storage:
- Стратегия расположения: региональное (regional) для близости к вычислительным ресурсам, двухрегиональное (dual-region) для active-active в двух регионах, мультирегиональное (multi-region) для широкой доступности глобальным пользователям.
- Управление версиями: включите управление версиями объектов для восстановления после удаления или повреждения; совмещайте с правилами жизненного цикла для управления затратами.
- Хранение: применяйте политики хранения на уровне бакета и, при необходимости, блокировки хранения (retention locks) для соответствия требованиям; используйте временные удержания (event-based holds) для управления записями.
- Шаблоны резервного копирования: бакеты в другом проекте с отдельным администрированием снижают риск случайного удаления и повышения привилегий. Для баз данных экспортируйте логические резервные копии в Cloud Storage в отдельном проекте.
- Пример правила жизненного цикла для удаления версий старше 90 дней:

    {
      "rule": [
        {
          "action": { "type": "Delete" },
          "condition": { "age": 90, "isLive": false }
        }
      ]
    }
    ```

    Применить с помощью:

gsutil lifecycle set lifecycle.json gs://prod-backups
```

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

Управление трафиком, мультисайтовые стратегии и непрерывная отказоустойчивость

Мультисайтовые стратегии:
- Активный-активный (Active-active): обслуживание трафика из нескольких регионов одновременно; требует симметричной репликации данных и бесконфликтной записи. Лучшие показатели RTO/RPO; самая высокая стоимость и сложность.
- Активный-пассивный (Active-passive): основной сайт в горячем режиме и готовый резервный; данные реплицируются непрерывно, трафик переключается при сбое. Хороший баланс между стоимостью и RTO.
- Теплый резерв (Warm standby): уменьшенная копия резервного сайта с предварительно синхронизированными данными; требует масштабирования при переключении; умеренные RTO и стоимость.
- Пилотный свет (Pilot light): минимальная репликация критически важных данных и определения инфраструктуры; большинство компонентов разворачивается при переключении; длительное RTO, низкая постоянная стоимость.
- Холодный резерв (Cold standby): только периодические резервные копии; восстановление из копий при сбое; самое длительное RTO, самая низкая стоимость.
Отказоустойчивость на уровне DNS и управления трафиком:
- Предпочитайте маршрутизацию на основе проверок работоспособности на Уровне 7 с помощью глобального внешнего балансировщика нагрузки HTTP(S). Он выполняет проверки работоспособности для каждого бэкенда и перенаправляет трафик от неработоспособных зон или регионов без изменения DNS.
- Используйте DNS-записи с низким TTL только для грубого управления переключением или для переключения между несвязанными VIP-адресами балансировщиков; помните, что из-за кеширования DNS переключение не происходит мгновенно.
- Для частных сервисов используйте внутренний балансировщик нагрузки HTTP(S) с региональными паттернами отказоустойчивости, а также частный DNS, который можно обновлять программно при необходимости.
Паттерны плавной деградации:
- Внедряйте флаги функций (feature flags) для отключения некритичного функционала при высокой нагрузке.
- Используйте прерыватели цепи (circuit breakers), тайм-ауты, повторные попытки с джиттером и переборки (bulkheads) для локализации сбоев.
- Предусмотрите режим «только для чтения», когда пути записи нарушены; ставьте операции записи в очередь для последующей обработки.
- Ограничивайте частоту запросов клиентов и применяйте противодавление (backpressure) для предотвращения каскадных сбоев.
Хаос-инжиниринг и непрерывное улучшение:
- Внедрение сбоев на сетевом (задержка, потеря пакетов) и прикладном уровнях подтверждает, что механизмы отказоустойчивости срабатывают, как задумано.
- Учения (Game days) отрабатывают восстановление с участием разных команд; включают оповещения, выполнение сценариев восстановления (runbooks) и анализ инцидентов (postmortems) с конкретными корректирующими действиями.
- Отслеживайте бюджеты ошибок и SLO; корректируйте емкость, стратегии повторных попыток и конфигурации репликации на основе полученных данных.
Компромиссы между доступностью, согласованностью, стоимостью и сложностью:
- Доступность vs. согласованность: строгая глобальная согласованность (например, многорегиональный Spanner) может увеличить задержку записи; согласованность в конечном счете (например, асинхронные реплики) может уменьшить задержку, но несет риск чтения устаревших данных.
- Стоимость vs. RTO/RPO: хранилища в двух регионах и многорегиональные базы данных увеличивают расходы, но минимизируют потерю данных и время простоя.
- Сложность vs. надежность: каждый механизм переключения, поток репликации и правило маршрутизации должны эксплуатироваться и тестироваться; сохраняйте архитектуру настолько простой, насколько это необходимо для достижения целей.

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

Acme Tickets, быстрорастущая компания по продаже билетов онлайн, должна обеспечить непрерывную работу во время региональных сбоев для своего API покупок и каталога мероприятий, соблюдая строгие требования RTO/RPO (RTO ≤ 5 минут, RPO ≤ 1 минута). Стек включает микросервисы без сохранения состояния, реляционную базу данных заказов, конвейер аналитики и статические медиаресурсы.

Определите уровни обслуживания, SLO и цели восстановления

Обоснование: Классифицировать API покупок и БД заказов как Уровень 0 (RTO 5 мин, RPO 1 мин), каталог — как Уровень 1 (RTO 15 мин, RPO 5 мин), а аналитику — как Уровень 2 (по мере возможности). Это позволяет соотнести затраты и сложность с влиянием на бизнес.

Выберите региональное размещение и мультисайтовую стратегию

Обоснование: Развернуть сервисы без состояния в режиме active-active в регионах us-central1 и us-east1 для минимизации RTO; использовать active-passive для базы данных заказов, чтобы сбалансировать задержку записи и стоимость.

Внедрите региональные MIG и глобальный балансировщик нагрузки HTTP(S)

Обоснование: Две региональные MIG (по одной на регион), распределенные как минимум по двум зонам каждая. Единый глобальный anycast VIP маршрутизирует трафик через сервисы бэкенда с проверками работоспособности, автоматически отключая неработоспособные регионы.

Вынесите состояние за пределы сервисов и настройте самовосстановление

Обоснование: Храните сессии в Memorystore с межрегиональными репликами чтения для каталога и поддерживайте сервисы без состояния, чтобы автовосстановление MIG и плавающие обновления были безопасны. Проверки работоспособности указывают на /healthz, который проверяет критически важные нижестоящие сервисы.

Подготовьте Cloud SQL для PostgreSQL с высокой доступностью (HA) и межрегиональной репликой чтения

Обоснование: Используйте HA в основном регионе для отказоустойчивости на уровне зон и включите PITR с достаточным сроком хранения. Создайте межрегиональную реплику чтения во вторичном регионе и протестированный сценарий восстановления (runbook) для ее повышения при региональном сбое, что обеспечит RPO ≤ 1 минуты с минимальной потерей записей.

Запланируйте регулярные тесты переключения базы данных

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

Разместите статические медиафайлы в сегменте Cloud Storage с двумя регионами, версионированием и хранением

Обоснование: Двойной регион обеспечивает доступность объектов в двух регионах; версионирование защищает от случайных перезаписей/удалений. Применяйте правила жизненного цикла для удаления старых версий и контроля затрат.

Защитите проверки работоспособности и исходящий трафик с помощью брандмауэра и квот

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

Внедрите DNS как грубый механизм управления с низким TTL

Обоснование: Хотя глобальный балансировщик нагрузки обрабатывает маршрутизацию на основе работоспособности, поддерживайте A-запись с низким TTL, указывающую на резервный VIP для экстренного ручного переключения, понимая ограничения кеширования DNS.

Автоматизируйте сценарии аварийного восстановления (DR runbooks) и проверяйте их с помощью учений (game days)

Обоснование: Используйте Cloud Scheduler для запуска синтетического трафика и SLO в Cloud Monitoring для подтверждения поведения во время ежеквартальных учений с внедренными сбоями (например, блокировка межрегионального трафика, завершение работы узлов). Собирайте метрики RTO/RPO и совершенствуйте процедуры.

Обеспечьте безопасность и разделение резервных копий

Обоснование: Экспортируйте ежедневные логические резервные копии БД заказов в сегмент Cloud Storage в отдельном проекте с блокировками хранения (retention locks); периодически восстанавливайте их на промежуточный экземпляр для проверки целостности и времени восстановления.

Внедрите плавную деградацию

Обоснование: Если БД заказов деградировала, переключите каталог в режим «только для чтения», ставьте операции записи в очередь для последующей обработки и отключайте некритичные функции. Это предотвращает каскадные сбои и поддерживает частичную работоспособность сервиса.

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

← Безопасность · Все домены · Миграция →

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