Google PCD: Наблюдаемость, отладка и операции по обеспечению надежности систем — Руководство по подготовке

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

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

Трассировка, ошибки и углубленная диагностика

Распределенная трассировка

• Контекст трассировки. Предпочитайте W3C trace-context (traceparent, tracestate). Для совместимости с Cloud Trace продолжайте поддерживать x-cloud-trace-context: x-cloud-trace-context: TRACE_ID/SPAN_ID;o=1
• Распространение (Propagation). Передавайте заголовки трассировки между сервисами, через очереди сообщений и асинхронные границы; создавайте новые дочерние спаны при выполнении RPC или SQL-вызовов. Потеря контекста нарушает карты сервисов и приводит к появлению узлов «unknown service».
• Сэмплирование. Сбалансируйте стоимость и точность; динамическое сэмплирование на входе (head-based) и сэмплирование на основе хвоста (tail-based) для редких медленных запросов могут повысить полезность данных.

Cloud Trace

• Предоставляет гистограммы задержек, каскадные диаграммы спанов (waterfalls) и карты сервисов. Используйте аннотации для критически важных подопераций (RPC, запросы к БД).
• Диагностируйте выбросы с помощью трассировок p95/p99; обращайте внимание на веерное разветвление (fan-out), N+1 запросы или конкуренцию за блокировки.
• Включите корреляцию трассировок и логов, чтобы по клику на трассировку можно было увидеть связанные с ней логи.

Error Reporting

• Автоматически агрегирует исключения по сигнатуре стека для каждого сервиса/версии. Настройте контекст сервиса, чтобы избежать смешивания ошибок из разных сервисов. Подавляйте известные «шумные» ошибки или направляйте их в уведомления с более низким приоритетом.
• Удаляйте персональные данные (PII) из сообщений об исключениях; вместо этого логируйте стабильные коды ошибок и идентификаторы корреляции.

Cloud Profiler

• Непрерывное профилирование CPU/heap с низкими накладными расходами для поддерживаемых сред выполнения. Сравнивайте профили между версиями и при разных уровнях трафика для выявления регрессий. Избегайте интерпретации артефактов сэмплирования как точных значений.

Cloud Debugger

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

Краткий пример: добавление W3C traceparent и корреляция лога

• Распространение через HTTP: traceparent: 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01
• Поле в логе для связи с Cloud Trace: “logging.googleapis.com/trace”: “projects/myproj/traces/4bf92f3577b34da6a3ce929d0e0e4736”

Инженерия надежности, оповещения и сигналы о работоспособности

SLI, SLO, SLA и бюджеты ошибок

• SLI (Service Level Indicators) измеряют удовлетворенность пользователей: доступность, задержка, корректность. Определяйте их для каждой критической конечной точки и пользовательского сценария.
• SLO (Service Level Objectives) устанавливают целевые показатели, например, 99,9% запросов выполняются менее чем за 300 мс в течение 30 дней.
• Бюджеты ошибок определяют допустимый уровень ненадежности. Расходуйте бюджеты на релизы, эксперименты или миграции; замораживайте изменения, если скорость исчерпания бюджета слишком высока.
• SLA (Service Level Agreements) — это внешние обязательства; поддерживайте SLO более строгим, чем SLA, чтобы иметь запас прочности.

Проектирование качественных оповещений

• По возможности предпочитайте оповещения на основе SLO и симптомов, а не на основе причин.
• Используйте оповещения с несколькими окнами и скоростями исчерпания (например, 14x за 5 минут и 2x за 1 час), чтобы отлавливать как быстрое, так и медленное исчерпание бюджета, уменьшая при этом количество ложных срабатываний.
• Добавьте проверку на отсутствие метрик для сторожевых таймеров (watchdogs) (например, «пульс» (heartbeat) длительно выполняющейся задачи).
• Маршрутизируйте по степени серьезности; ограничивайте частоту уведомлений; предоставляйте ссылки на ранбуки и дашборды.

Проверки работоспособности (health checks и probes)

• Проверки готовности (Readiness checks) блокируют трафик до тех пор, пока зависимости не будут готовы; проверки жизнеспособности (liveness checks) инициируют перезапуск зависших процессов; проверки запуска (startup probes) защищают медленно стартующие приложения от преждевременных перезапусков.
• Для ВМ за балансировщиком нагрузки разрешите диапазоны IP-адресов источника проверок работоспособности, иначе трафик не достигнет бэкендов: gcloud compute firewall-rules create allow-lb
  –network prod –allow tcp
  –source-ranges 130.211.0.0/22,35.191.0.0/16 –direction INGRESS
• Пример для Kubernetes: readinessProbe: httpGet: { path: /ready, port: 8080 } periodSeconds: 5 failureThreshold: 3 livenessProbe: httpGet: { path: /healthz, port: 8080 } initialDelaySeconds: 30 periodSeconds: 10
• Синтетическое тестирование. Используйте проверки доступности (uptime checks) и специализированные сквозные сценарии через Cloud Scheduler + Cloud Run/Functions для проверки входа в систему, платежей или других критических путей.
• Мониторинг зависимостей. Отслеживайте насыщение соединений с базой данных, долю ошибок RPC, отставание в очередях, ошибки исходящего трафика и SLI сторонних сервисов. Настройте повторные попытки с усеченной экспоненциальной задержкой (truncated exponential backoff) для временных ошибок 429/5xx, используя ключи идемпотентности для безопасности.

← Непрерывная доставка · Все домены · Производительность →

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

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