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

By Laurynas Brazys · 31 August 2026 · #google #ACE #certification #exam-prep #study-guide

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

Обзор

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

Основы мониторинга и оповещений

Cloud Monitoring собирает временные ряды из сервисов Google Cloud, агентов и пользовательских метрик для предоставления дашбордов, проверок доступности, SLO и оповещений.

• Метрики и кардинальность

  • Типы отслеживаемых ресурсов (например, gce_instance, aws_ec2_instance, global) определяют область видимости таких измерений, как проект, регион и ID экземпляра.
  • Минимизируйте использование меток с неограниченным количеством значений (например, user_id), чтобы предотвратить взрывной рост кардинальности, который замедляет запросы и увеличивает стоимость.
  • Для задержек (p50/p90/p99) предпочитайте метрики распределения и используйте окна выравнивания для согласованной агрегации.

• Дашборды

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

• Политики оповещений

  • Разрабатывайте оповещения на основе симптомов, связанных с пользовательским опытом: исчерпание бюджета SLO по доступности, перцентили задержки, частота ошибок. Используйте оповещения с несколькими окнами и несколькими порогами исчерпания, чтобы отлавливать как быстрое, так и медленное исчерпание (например, 2% за 1 час и 5% за 5 минут).
  • Установите разумные ограничения на частоту уведомлений и правила автоматического закрытия. Используйте аннотации для автоматического устранения инцидентов, чтобы документировать сценарии реагирования (ранбуки).
  • Используйте оповещения об отсутствии метрик для критически важных пакетных заданий и конвейеров данных со строгим расписанием.
  • Метрики на основе логов поддерживают оповещения о событиях приложений или безопасности (например, повторяющиеся permissionDenied).

• Каналы уведомлений

  • Настройте каналы в соответствии с серьезностью: пейджинг для SEV1 (дежурный инженер, SMS, телефон), чат для SEV2/3, электронная почта или веб-хуки для низкоприоритетных событий. Используйте Pub/Sub для интеграции с системами тикетов или автоматизации.
  • Периодически тестируйте каналы; устаревшие каналы — это скрытый источник сбоев.

• Проверки доступности и синтетический мониторинг

  • Проверки HTTP(S) и TCP с глобальных точек наблюдения подтверждают внешнюю доступность. Сочетайте проверки с проверкой содержимого для обнаружения частичных сбоев.
  • Используйте внутренние проверки доступности (private uptime checks) через гибридное подключение или Private Service Connect для внутренних сервисов.
  • Сценарии сбоев: проверки могут завершаться неудачно из-за задержки DNS TTL, проблем с ротацией TLS-сертификатов или сбоев в пределах региона; подтвердите проблему по метрикам, прежде чем отправлять оповещение.

• Мониторинг нескольких проектов

  • Используйте единое рабочее пространство Monitoring и свяжите с ним все проекты для создания консолидированных дашбордов и оповещений. Это упрощает управление SLO для всего парка ресурсов и сокращает дублирование.

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

Cloud Logging — это маршрутизатор, хранилище и система запросов для логов платформы и приложений. Дополнительные APM-инструменты (Error Reporting, Trace, Profiler) ускоряют поиск первопричин.

• Маршрутизация логов, бакеты, приемники и хранение

  • Направляйте логи с помощью приемников (sinks) в бакеты логов (по умолчанию или кастомные), BigQuery (для аналитики), Pub/Sub (для потоковой обработки) или Cloud Storage (для архивации).
  • Используйте бакеты логов с региональной привязкой для обеспечения резидентности данных и производительности. Применяйте CMEK, если это требуется для соответствия нормативным требованиям.
  • Установите срок хранения для каждого бакета (например, 30–90 дней для операционных нужд, несколько лет для аудита). Более длительное хранение увеличивает стоимость; используйте агрессивную фильтрацию для контроля расходов.
  • Исключения уменьшают объем принимаемых подробных логов (например, от проверок работоспособности). Проверяйте фильтры, чтобы случайно не отбросить критически важные логи.

  Пример: создание приемника в BigQuery для логов аудита

undefined

Пример: создание исключения

undefined

• Запросы и Log Explorer

  • Используйте расширенные фильтры по resource.type, severity, меткам и JSON-полям. Сохраняйте запросы для распространенных сценариев анализа (сбои при запуске, permissionDenied, quotaExceeded).
  • Создавайте метрики на основе логов типа “распределение” и “счетчик” для оповещений и дашбордов.

• Cloud Audit Logs

  • Журналы Admin Activity: всегда включены, плата за сбор не взимается; записывают административные операции записи (например, createInstance).
  • Журналы Data Access: записывают операции чтения и записи на уровне данных (например, storage.objects.get). По умолчанию отключены для многих сервисов; включайте выборочно, так как объем и стоимость могут быть высокими.
  • Журналы System Event: системные действия Google (например, действия автомасштабирования, live migration в рамках обслуживания).
  • Журналы Policy Denied: явные записи об отказах в доступе со стороны IAM и политик организации. Критически важны для устранения проблем с доступом и проверок безопасности.
  • Направляйте логи аудита в BigQuery для хранения и расследования; индексируйте метки, такие как authenticationInfo.principalEmail, для атрибуции.

• Error Reporting, Trace и Profiler

  • Error Reporting автоматически группирует трассировки стека по сервису и версии; интегрируйте его с каналами уведомлений для оповещения о новых группах ошибок и внезапных всплесках.
  • Cloud Trace собирает распределения задержек запросов и спаны; настройте частоту выборки, чтобы сбалансировать накладные расходы и точность (например, 1 из 1000 для сервисов с высоким QPS, с использованием выборки на основе хвоста распределения (tail-based sampling), если применяются коллекторы OpenTelemetry).
  • Profiler обеспечивает непрерывное профилирование CPU/кучи в производственной среде с низкими накладными расходами. Ограничьте его применение горячими участками кода или репрезентативными рабочими нагрузками, чтобы контролировать объем данных и накладные расходы. Используйте сопоставление с исходным кодом для читаемых графов вызовов.
  • Компромиссы: более высокая частота выборки улучшает диагностику, но увеличивает стоимость и потенциальное раскрытие персональных данных (PII); очищайте конфиденциальные поля и используйте токенизацию.

Устранение неполадок в сервисах, ресурсах и сети

Эффективное устранение неполадок начинается с анализа симптомов, затем переходит к границам системы, ресурсам и их зависимостям.

• Состояние управляемых сервисов, статус служб, квоты, региональные инциденты

  • Проверьте, не вызвана ли проблема вышестоящим сервисом: изучите состояние сервиса и последние региональные уведомления. Ищите всплески ошибок, повышенную задержку или ошибки, связанные с квотами.
  • Квоты устанавливаются на уровне проекта и часто на уровне региона; сообщения quotaExceeded и rateLimitExceeded в логах указывают на троттлинг. Запрашивайте увеличение квот заблаговременно перед пиковыми нагрузками.
  • Типичный сбой: частичные сбои в регионе могут проявляться как периодические ошибки; по возможности настраивайте многорегиональное аварийное переключение (failover).

• Состояние ресурсов и диагностика ВМ

  • Используйте операции с инстансами, события технического обслуживания и проверки состояния. Для MIG анализируйте перезапуски из-за автовосстановления и сбои проверок состояния, чтобы выявить проблемные образы или конфигурации.

  • Серийная консоль ВМ для просмотра сообщений загрузки и ядра:

undefined

- Распространенные причины: паника ядра (kernel panics), некорректные записи в `fstab`, блокирующие загрузку, неправильные сетевые конфигурации, неверная настройка OS Login, приводящая к сбоям SSH.

• Используйте OS Login с SSH-ключами для каждого пользователя и ролями IAM (compute.osLogin или compute.osAdminLogin) для отслеживаемого доступа.

• Logs Explorer для анализа сбоев

  • Начните с логов, описывающих симптомы (5xx, deadlineExceeded), затем отфильтруйте по меткам ресурсов и сопоставьте с изменениями в развертывании и логами квот. Используйте гистограммы для определения моментов изменений.

• Наблюдаемость сети

  • VPC Flow Logs: сэмплирование трафика (5-tuple) для каждого VNIC; включается на уровне подсетей. Настраивайте частоту сэмплирования (например, 0.5) и параметры метаданных для баланса между производительностью и детализацией.

undefined

• Логирование правил брандмауэра: фиксируйте срабатывания правил allow/deny для критически важных правил, чтобы диагностировать неожиданные блокировки или перекрытие правил (shadowing).

undefined

• Connectivity Tests: моделируйте и проверяйте доступность между VPC, пирингами, Cloud VPN, Cloud Interconnect и через правила брандмауэра. Полезно для проверки перед внесением изменений и для анализа инцидентов.

undefined

• Дополнительные сигналы: логи Cloud NAT и балансировщиков нагрузки для проблем с исходящим (egress) и пограничным трафиком. Типичные сбои включают асимметричную маршрутизацию, отсутствующие маршруты, неправильный порядок правил брандмауэра и ограничения политик.

Надежность, SLO и реагирование на инциденты

Операционная дисциплина связывает телеметрию с целями, влияющими на пользователей, и обеспечивает последовательное реагирование на инциденты.

• SLO, бюджеты ошибок и базовые показатели

  • Определите SLO на основе ориентированных на пользователя SLI (доступность, задержка, корректность). Пример: 99,9% запросов на чтение выполняются менее чем за 200 мс в течение 30 дней.
  • Отслеживайте бюджеты ошибок и создавайте сводные дашборды по сервисам и версиям релизов. Контролируйте развертывания на основе потребления бюджета.
  • Устанавливайте базовые показатели производительности до роста трафика; регрессии обнаруживаются по отклонению, а не по абсолютным значениям.

• Снижение шума от оповещений

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

• Рабочий процесс реагирования на инциденты

  • Проведите триаж и определите серьезность; назначьте роли (командир инцидента, операционная группа, группа коммуникаций, секретарь).
  • Пути эскалации: дежурные смены, профильные эксперты и поддержка вендора (включайте в заявки в техподдержку ID проекта, ID запросов, временные метки и регионы).
  • Коммуникация: поддерживайте единый источник правды (канал в чате и документ по инциденту). Предоставляйте периодические обновления для заинтересованных сторон с информацией о влиянии, мерах по смягчению последствий и предполагаемом времени устранения (ETA).
  • Плейбуки по смягчению последствий: откат, переключение на резерв, отключение через feature flag или добавление мощностей. Отдавайте предпочтение обратимым изменениям с малым радиусом поражения.

• Разбор инцидента и анализ первопричин (RCA)

  • На основе доказательств: сопоставляйте метрики, логи, трассировки и события изменений. Укажите, какие сигналы обнаружения сработали (или почему не сработали), а также время до обнаружения/устранения.
  • Определяйте сопутствующие факторы, а не только непосредственную причину. Фиксируйте конкретные задачи с ответственными и сроками; соответствующим образом обновляйте раунбуки и оповещения.
  • Культура без поиска виновных (blameless culture) способствует полному раскрытию информации и системным исправлениям.

• Операционные раунбуки (runbooks)

  • Структура: триггер и обнаружение, дерево быстрой диагностики, безопасные меры по смягчению, шаги по откату/восстановлению, проверка и критерии выхода.
  • Держите команды и фильтры готовыми к копированию и вставке; проверяйте наличие минимально необходимых IAM-прав у ответственных за реагирование (например, storage.objectCreator для резервных копий с доступом только на запись; выделенные сервисные аккаунты для workload identity).
  • Версионируйте раунбуки с помощью управления изменениями; тестируйте их во время учений (game days).

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

Компания Northwind Outfitters управляет региональной e-commerce платформой на Google Cloud. После недавнего всплеска трафика пользователи периодически сообщают о таймаутах при оформлении заказа и медленном поиске товаров. Операционной команде необходимо быстро восстановить надежность, уменьшить шум от оповещений и усилить диагностику в нескольких проектах.

Подход:

1. Консолидировать мониторинг по всем проектам

• Действие: Создать единое рабочее пространство Monitoring и связать проекты prod, payments и search. Построить дашборд «Путь пользователя» (User Journey), отображающий доступность, задержку и частоту ошибок для оформления заказа и поиска.
• Обоснование: Централизованная видимость поддерживает триаж на уровне сервисов и позволяет сопоставлять межсервисные проблемы (например, каскадное влияние задержки поиска на таймауты при оформлении заказа).

2. Внедрить SLO и оповещения по скорости сжигания бюджета ошибок (burn-rate)

• Действие: Определить SLO: 99,9% операций оформления заказа менее 400 мс, 99,95% операций поиска менее 250 мс. Создать оповещения по скорости сжигания бюджета для нескольких окон (2% за 1 час и 5% за 5 минут) на основе SLI по задержке и частоте ошибок. Уведомлять дежурную смену через пейджинг, а заинтересованных лиц — через чат.
• Обоснование: Оповещения по скорости сжигания бюджета отлавливают быстрые регрессии и продолжительное медленное ухудшение, не вызывая оповещений при нормальных колебаниях.

3. Добавить синтетические проверки доступности с проверкой содержимого

• Действие: Настроить TCP и HTTPS проверки доступности для публичных точек входа и частную проверку доступности для внутреннего API платежей, проверяя, что тело ответа содержит «ok».
• Обоснование: Позволяет обнаруживать проблемы с доступностью и частичные сбои, такие как неверно маршрутизируемые бэкенды или деградировавшие вышестоящие сервисы.

4. Оптимизировать маршруты и хранение логов

• Действие: Создать выделенные бакеты для логов: ops (90 дней), security-audit (2 года, CMEK). Направить логи Admin Activity, Data Access, System Event и Policy Denied в BigQuery через приемники (sinks) для аналитики. Добавить исключения для «шумных» проверок работоспособности.
• Обоснование: Правильно подобранный срок хранения контролирует затраты; BigQuery обеспечивает быструю экспертизу. Исключения снижают шум, не приводя к потере критически важных данных.

5. Включить диагностику приложений

• Действие: Инструментировать сервисы с помощью OpenTelemetry для Trace; включить Error Reporting для бэкенда и фронтенда; развернуть Profiler на сервисе оформления заказов с профилированием CPU и кучи (heap) с консервативной частотой выборки.
• Обоснование: Трассировки выявляют узкие места по задержке; Error Reporting подсвечивает новые группы ошибок; Profiler с низкими накладными расходами обнаруживает конкуренцию за CPU и утечки памяти.

6. Усилить наблюдаемость сети

• Действие: Включить VPC Flow Logs на подсетях продакшена (частота выборки 0.5, включить все метаданные) и логирование правил брандмауэра (allow/deny) для входящего трафика к сервисам поиска и платежей. Создать Connectivity Tests от веб-уровня к поиску и от платежей к Cloud SQL.
• Обоснование: Логи потоков и брандмауэра выявляют отброшенные пакеты, повторные передачи и затененные правила; Connectivity Tests проверяют доступность и выявляют неверные конфигурации.

7. Диагностика на уровне ресурсов и безопасный доступ

• Действие: Для нестабильных VM проверять проблемы с загрузкой через последовательную консоль:

undefined

• Если требуется SSH, принудительно использовать OS Login и предоставить право compute.osAdminLogin группе «ops-admins». Каждый администратор использует свой собственный SSH-ключ.
• Обоснование: Логи последовательной консоли выявляют сбои ядра и системы инициализации. OS Login с ключами для каждого пользователя обеспечивает атрибутируемый доступ с минимальными привилегиями.

8. Проверка квот и работоспособности региона

• Действие: Просмотреть недавние события quotaExceeded в логах; повысить региональные квоты на API и IP-адреса для автомасштабирования поиска. Проверить уведомления о работоспособности сервисов для затронутого региона; временно перенаправить трафик с помощью весов балансировщика нагрузки.
• Обоснование: Троттлинг из-за квот и региональные инциденты являются частыми источниками периодических сбоев; проактивное масштабирование и управление трафиком смягчают их влияние.

9. Снижение шума и обновление раунбуков

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

10. Разбор инцидента и последующие действия

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

← Развертывание · Все домены · Безопасность →

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

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