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

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

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

Обзор

Операции, наблюдаемость и автоматизация платформы в Google Cloud гарантируют, что сервисы можно диагностировать, обслуживать и постоянно улучшать, контролируя при этом безопасность и затраты. Целостный дизайн охватывает логирование, метрики, трассировку, аудит, инструкции по эксплуатации (runbooks), реагирование на инциденты, управление квотами и мощностями, а также автоматизацию. Цель — получать полезные сигналы с низким уровнем шума, привязанные к целям уровня обслуживания, в сочетании с детерминированной автоматизацией, которая сокращает рутинную работу (toil) и дрейф конфигурации.

Логирование и аудит

Cloud Logging централизует логи из сервисов Google Cloud, GKE и виртуальных машин. Предпочитайте структурированные логи (JSON) с единообразными ключами, такими как request_id, user_id, service, version, latency_ms и severity; структурированные данные позволяют выполнять точные запросы, создавать метрики на основе логов и оценивать политики. На виртуальных машинах и узлах GKE установите Ops Agent (предпочтительно) или устаревший агент логирования для сбора системных и прикладных логов; убедитесь, что парсеры генерируют JSON для ваших фреймворков.

Контейнеры логов и хранение: Используйте региональные контейнеры логов для обеспечения резидентности данных и CMEK. Контейнеры по умолчанию включают _Default и _Required; последний хранит логи аудита Admin Activity, System Event и Policy Denied с фиксированным длительным сроком хранения. Создавайте выделенные контейнеры для каждого класса данных (например, app, security, analytics) с настроенным сроком хранения и CMEK. Более длительное хранение улучшает возможности для расследований (forensics), но увеличивает затраты; экспортируйте данные для долгосрочного архивирования, когда хранение в Logging не требуется.
Приемники логов и экспорт: Маршрутизируйте логи с помощью Log Router, используя приемники (sinks) в BigQuery (аналитика), Pub/Sub (SIEM или конвейеры) и Cloud Storage (архивирование). Используйте партиционированные таблицы BigQuery для управления объемом и затратами. Всегда предоставляйте сервисному аккаунту приемника минимально необходимые права на запись в место назначения, чтобы избежать скрытых сбоев. Избегайте циклов маршрутизации, не загружая экспортированные логи обратно в Logging.
Запросы и метрики на основе логов: Используйте Logs Explorer с фильтрами по полям logName, resource.type, severity, labels и jsonPayload. Создавайте метрики на основе логов (счетчик или распределение) для SLI частоты ошибок и гистограмм задержек, что помогает в настройке оповещений. Контролируйте кардинальность, нормализуя поля с высокой вариативностью.
Логи аудита Cloud Audit Logs: Логи Admin Activity (записи в плоскости управления), Data Access (чтение/запись пользовательских данных), System Event и Policy Denied обеспечивают наблюдаемость на административном уровне. Логи Data Access имеют большой объем и по умолчанию отключены для многих сервисов; включайте их только там, где это необходимо, и направляйте в контейнер с соответствующим сроком хранения и CMEK. Логи Policy Denied помогают на ранней стадии выявлять нарушения прав доступа и политик организации. Обеспечьте разделение обязанностей: команды безопасности обычно владеют логами аудита и имеют к ним доступ, в то время как у других команд доступ ограничен.
Режимы отказа и компромиссы:
- Слишком широкие фильтры приемников приводят к взрывному росту затрат в BigQuery; фильтруйте точно и устанавливайте срок действия для партиций.
- Поля JSON с высокой кардинальностью (например, полные URL) ухудшают производительность запросов; очищайте данные и извлекайте нормализованные метки.
- Недостаточный срок хранения затрудняет расследования; экспорт в GCS или BigQuery решает эту проблему.
- Отсутствие агента или неверные настройки парсера вызывают тихую потерю логов; настройте оповещения на основе heartbeat агента и ошибок приема данных.

Пример: создание регионального контейнера логов с настраиваемым сроком хранения и экспорт отфильтрованных логов аудита через приемник.

gcloud logging buckets create app-logs –location=us-central1 –retention-days=30
gcloud logging sinks create bq-audit-sink bigquery.googleapis.com/projects/PROJECT/datasets/audit –log-filter=“logName:cloudaudit.googleapis.com AND protoPayload.serviceName:*” –use-partitioned-tables

Мониторинг, трассировка и диагностика приложений

Cloud Monitoring собирает системные и прикладные метрики, поддерживает дашборды, оповещения, проверки доступности (uptime checks), каналы уведомлений и цели уровня обслуживания (SLO).

Метрики и дашборды: Используйте встроенные метрики для сервисов Google и создавайте пользовательские метрики через Cloud Monitoring API или OpenTelemetry. Делайте акцент на четырех золотых сигналах: задержка, трафик, ошибки, насыщенность. Применяйте метки разумно; избегайте значений меток с неограниченной кардинальностью. Используйте Metrics Scope для агрегации представлений из нескольких проектов. Используйте MQL для более выразительных запросов, когда это необходимо.
Оповещения и каналы уведомлений: Внедряйте оповещения для SLO на основе нескольких окон и скоростей сгорания бюджета (multi-window, multi-burn-rate), чтобы сбалансировать быстрое обнаружение и снижение шума. Определите каналы уведомлений (email, SMS, Pub/Sub, веб-хуки, сторонние инструменты для инцидентов) и включайте ссылки на инструкции (runbooks) и контекст в документацию к оповещениям. Используйте ограничения частоты уведомлений и автозакрытие инцидентов для предотвращения шторма оповещений.
Проверки доступности: Проверяйте критически важные эндпоинты из нескольких регионов с верификацией TLS, DNS и проверкой содержимого. Свяжите проверки доступности с оповещениями и SLO сервиса. Помните, что проверки доступности не валидируют внутренние зависимости; дополняйте их синтетическими транзакциями и внутренними проверками работоспособности.
SLO и SLI: Определите SLI для доступности, задержки и корректности. Настройте SLO в Cloud Monitoring Service Monitoring и отслеживайте бюджеты ошибок. Настройте оповещения на сгорание бюджета, а не на сырые ошибки, чтобы соответствовать влиянию на клиента. Используйте шлюзы выпуска (release gates) или прогрессивную доставку, чтобы не выходить за рамки оставшегося бюджета ошибок.
Cloud Trace, Error Reporting, Profiler: Используйте распределенную трассировку между сервисами с помощью OpenTelemetry для аннотирования спанов метаданными запроса и зависимостей. Динамически настраивайте выборку (sampling) для каждого сервиса и пути, чтобы обеспечить покрытие критических потоков, контролируя при этом затраты. Error Reporting автоматически агрегирует исключения из логов, дедуплицирует их по стектрейсу и инициирует уведомления. Profiler обеспечивает непрерывное профилирование CPU, кучи (heap) и wall-time в производственной среде с низкими накладными расходами; используйте его для устранения «горячих» участков кода и снижения затрат.
Режимы отказа и компромиссы:
- Избыточная кардинальность метрик увеличивает затраты и замедляет запросы; агрегируйте данные перед отправкой.
- Низкая частота выборки трассировки скрывает проблемы с хвостовой задержкой (tail latency); используйте более высокую частоту выборки для медленных путей.
- Неправильно подобранные SLO (например, слишком строгие) вызывают усталость от оповещений; итерируйте на основе реальных данных трафика.
- Проверки доступности могут проходить успешно, в то время как внутренние зависимости не работают; используйте SLO, учитывающие зависимости.

Эксплуатация платформы, ранбуки и управление инцидентами

Операционная дисциплина сокращает среднее время обнаружения, устранения и анализа инцидентов.

Ранбуки и эскалация: Каждое оповещение (alert) должно содержать ссылку на детерминированный ранбук, описывающий предварительные условия, шаги по диагностике, процедуру отката и шаблоны для коммуникации. Определите чёткие графики дежурств и политики эскалации. Храните ранбуки в системе контроля версий и тестируйте их.
Управление инцидентами и постмортемы: Используйте стандартизированные уровни критичности (severities), роли (командир инцидента, ответственный за коммуникации, инженер по эксплуатации, профильный эксперт/SME) и каналы связи. Для массового оповещения отдавайте предпочтение ChatOps и страницам статуса (status pages). Проводите разборы инцидентов без поиска виновных (blameless postmortems), фиксируя хронологию, сопутствующие факторы, пробелы в обнаружении, влияние на клиентов и конкретные последующие шаги с назначенными ответственными и сроками.
Управление квотами и сигналы о ёмкости: Отслеживайте метрики Service Usage и квот времени выполнения сервисов (serviceruntime quota), настроив оповещения на коэффициент использования. Запрашивайте увеличение квот проактивно и согласовывайте лимиты автомасштабирования с квотами. Используйте сигналы о ёмкости, такие как загрузка CPU, использование памяти, файловые дескрипторы, пулы соединений и глубина очереди. Для GKE настраивайте HPA/VPA и cluster autoscaler; для GCE MIGs устанавливайте периоды стабилизации (cool-downs) и, где это уместно, предиктивное автомасштабирование.
Состояние сервиса и диагностика неисправностей: Комбинируйте просмотр логов в реальном времени в Logs Explorer (live tail), метрики на основе логов, дашборды и Trace для сокращения среднего времени до обнаружения (MTTD). Включите VPC Flow Logs и Firewall Rules Logging для диагностики сети; используйте серийную консоль VM при сбоях загрузки. Держите захват пакетов и трассировку ядра в качестве процедур аварийного доступа (break-glass) в ранбуках.
Сценарии сбоев:
- Исчерпание квот выглядит как полный отказ сервиса; настройте оповещения при достижении 80% использования и ограничивайте частоту запросов (rate-limit) от вышестоящих систем.
- Автомасштабирование без предварительного прогрева вызывает холодные старты; используйте минимальное количество реплик для критически важных путей.
- Отсутствие синтетических проверок маскирует сбои, видимые клиентам; внедряйте канареечные транзакции.

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

Автоматизируйте повторяемые задачи, следуя принципу наименьших привилегий и обеспечивая идемпотентность.

Инструменты: Используйте Cloud Shell для безопасного, эфемерного административного доступа с постоянным каталогом $HOME; размещайте вспомогательные исполняемые файлы в ~/bin для их постоянного присутствия в PATH. Автоматизируйте задачи с помощью gcloud, REST API и клиентских библиотек. Используйте сервисные аккаунты и workload identity, чтобы избавиться от долгоживущих ключей.
Планировщики и оркестраторы: Используйте Cloud Scheduler для запуска заданий HTTP и Pub/Sub по расписанию cron. Используйте Workflows для оркестрации автоматизации с участием нескольких сервисов, реализуя повторные попытки, экспоненциальную задержку, компенсацию и тайм-ауты. Обеспечивайте идемпотентность и добавляйте в журналы идентификаторы корреляции.
Примеры рутинной автоматизации:
- Ежедневный экспорт ресурсов в GCS и BigQuery для инвентаризации и создания отчетов об отклонениях.
- Автоматический расчет скорости исчерпания бюджета ошибок SLO с публикацией на панель мониторинга.
- Периодическая оценка соответствия политикам организации и выявление аномалий в IAM.
Инвентаризация ресурсов и оценка политик: Cloud Asset Inventory предоставляет данные о состоянии ресурсов, привязок IAM и политик организации на определенный момент времени, а также потоки изменений в реальном времени. Экспортируйте данные в BigQuery для исторического анализа и обнаружения отклонений; подпишитесь на Pub/Sub для анализа нарушений политик почти в реальном времени. Используйте Policy Analyzer и Recommender для обнаружения избыточно широких прав IAM и неиспользуемых разрешений. Применяйте ограничения с помощью Organization Policy и проверяйте конфигурации перед развертыванием с помощью подхода «политики как код» (policy-as-code).
Отклонение конфигурации: Предотвращайте отклонения с помощью декларативного подхода IaC (инфраструктура как код) и непрерывной проверки. При обнаружении отклонения либо автоматически приводите конфигурацию в соответствие, либо помещайте ресурсы в карантин. Помечайте ресурсы тегами с указанием происхождения (например, deployment_id), чтобы отличать управляемые ресурсы от созданных вручную.
Архитектура наблюдаемости для безопасности, надежности и затрат:
- Безопасность: Направляйте журналы аудита в защищенные с помощью CMEK сегменты с ограниченным доступом; экспортируйте их в выделенный проект безопасности. Интегрируйте SIEM через Pub/Sub.
- Надежность: Создавайте панели мониторинга и оповещения на основе SLI и трассировок; репетируйте автоматизацию реагирования на инциденты с помощью Workflows.
- Затраты: Контролируйте кардинальность метрик, настраивайте хранение журналов для каждого сегмента, секционируйте экспорты в BigQuery и используйте Profiler для оптимизации нагруженных участков кода.

Пример: запланировать ежедневный экспорт ресурсов и запустить рабочий процесс.

undefined

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

Компания Contoso Commerce запускает мультирегиональную платформу оформления заказов на базе GKE. Требования: аудируемое администрирование, оповещения на основе SLO с минимальным шумом, сквозная трассировка запросов, автоматизированная еженощная инвентаризация для проверки соответствия требованиям и строгий контроль затрат.

Подход:

Создание основы для журналирования и аудита

Создайте региональные сегменты журналов с CMEK для журналов приложений, безопасности и аналитики; установите срок хранения 30 дней для приложений и 400+ дней для безопасности в соответствии с требованиями. Направьте журналы Admin Activity, System Event и Policy Denied в сегмент безопасности; включите журналы Data Access только для платежных сервисов.
Обоснование: Разделение по уровню чувствительности данных уменьшает радиус поражения и затраты; CMEK обеспечивает соответствие требованиям; ограничение сбора журналов Data Access позволяет избежать всплесков их объема.

Внедрение структурированного журналирования и сбора логов приложений

Разверните Ops Agent на узлах GKE и коллекторы в виде sidecar-контейнеров или DaemonSet для отправки журналов приложений в формате структурированного JSON с идентификаторами корреляции (trace_id, span_id) и метками пользователя/сессии, очищенными от персональных данных (PII).
Обоснование: Структурированные журналы позволяют выполнять точные запросы, создавать метрики на основе журналов и связывать их с трассировками; идентификаторы корреляции поддерживают распределенную диагностику.

Развертывание распределенной трассировки, агрегации ошибок и профилирования

Инструментируйте микросервисы с помощью SDK OpenTelemetry для экспорта данных в Cloud Trace; установите более высокую частоту выборки для путей оформления заказа и оплаты. Включите Error Reporting для всех сред выполнения и Profiler для сервисов, критичных к ресурсам CPU/памяти.
Обоснование: Трассировки позволяют локализовать задержки на каждом этапе между сервисами; Error Reporting группирует стектрейсы для ускорения первичной диагностики; Profiler снижает затраты на вычисления и хвостовую задержку.

Определение SLI/SLO и настройка оповещений и панелей мониторинга

Определите SLI: p90 и p99 задержки при оформлении заказа, доступность API оформления заказа и процент успешных платежей. Установите SLO (например, доступность 99,9%, задержка p99 менее 800 мс). Настройте оповещения о скорости исчерпания бюджета ошибок (2% за 1 час и 1% за 6 часов) со ссылками на инструкции (runbooks) и канал PagerDuty; создайте панели мониторинга, отображающие «золотые сигналы» и тренды бюджета ошибок.
Обоснование: Оповещения на основе бюджета ошибок связаны с влиянием на клиентов и уменьшают шум; панели мониторинга обеспечивают операционную ситуационную осведомленность.

Добавление внешних и внутренних проверок работоспособности

Настройте мультирегиональные проверки доступности (uptime checks) для эндпоинтов оформления заказа с проверкой содержимого; добавьте синтетические проверки транзакций для всего процесса от корзины до оплаты. Интегрируйте проверки готовности GCLB и GKE.
Обоснование: Проверки доступности подтверждают доступность сервиса для клиентов; синтетические тесты обнаруживают нарушения в работе зависимостей.

Автоматизация инвентаризации, мониторинга политик и обнаружения отклонений

Создайте проект безопасности для получения экспортов Cloud Asset Inventory в GCS и BigQuery; включите потоки Pub/Sub в реальном времени для отслеживания изменений в IAM и политиках организации. Ежедневно запускайте Workflows для сравнения манифестов желаемого состояния с текущими ресурсами; создавайте заявки или автоматически устраняйте отклонения с низким риском.
Обоснование: Централизованная инвентаризация упрощает аудит; непрерывная оценка политик предотвращает разрастание привилегий; автоматизация сдерживает отклонения.

Управление квотами и емкостью

Отслеживайте квоты на вычислительные ресурсы, балансировщики нагрузки и API с оповещениями при достижении 70% и 85% использования. Заранее запрашивайте увеличение квот под целевую нагрузку; согласуйте лимиты GKE cluster autoscaler и HPA с квотами. Включите предиктивное автомасштабирование для сервисов на базе MIG с медленным запуском.
Обоснование: Достижение лимитов квот может выглядеть как сбои в работе; проактивные корректировки и согласованное автомасштабирование предотвращают троттлинг в пиковые моменты.

Оптимизация затрат на наблюдаемость

Ограничьте срок хранения журналов для каждого сегмента, исключите подробные отладочные журналы в производственной среде с помощью фильтров Log Router и экспортируйте в BigQuery только необходимые поля с истечением срока действия секций. Ограничьте кардинальность меток метрик; используйте результаты Profiler для уменьшения ресурсов, выделенных для нагруженных сервисов.
Обоснование: Наблюдаемость должна быть экономически эффективной; целенаправленное хранение и экспорт предотвращают неконтролируемый рост расходов.

Подготовка инструкций (runbooks) и отработка действий при инцидентах

Создайте версионируемые инструкции (runbooks) для каждой политики оповещений, включая диагностические запросы, фильтры трассировок, команды отката и процедуры коммуникации. Проводите учения («game days») для проверки эскалации и автоматизации.
Обоснование: Детерминированные, отработанные на практике ответные действия сокращают среднее время восстановления (MTTR) и повышают надежность.

Проверка и итеративное улучшение

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

← Миграция · Все домены · DevOps →

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