Google PCA: Operações, Observabilidade e Automação de Plataforma — Guia de estudos

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

Faz parte do Google Professional Cloud Architect — Guia de estudos. Pratique com respostas verificadas no centro de exames da Google, ou faça testes cronometrados no ExamRoll.io.

Visão Geral

Operações, Observabilidade e Automação de Plataforma no Google Cloud garantem que os serviços sejam diagnosticáveis, sustentáveis e continuamente aprimorados, ao mesmo tempo em que controlam a segurança e o custo. Um design coeso abrange logging, métricas, tracing, auditabilidade, runbooks, resposta a incidentes, governança de cotas e capacidade, e automação. O objetivo é ter sinais acionáveis e de baixo ruído vinculados a objetivos de nível de serviço (SLOs), juntamente com uma automação determinística que reduz o trabalho repetitivo (toil) e o desvio de configuração (configuration drift).

Logging e Auditabilidade

O Cloud Logging centraliza os logs dos serviços do Google Cloud, GKE e VMs. Prefira logs estruturados (JSON) com chaves consistentes para request_id, user_id, service, version, latency_ms e severity; dados estruturados permitem consultas precisas, métricas baseadas em logs e avaliação de políticas. Em VMs e nós do GKE, instale o Ops Agent (preferencial) ou o agente de logging legado para coletar logs de sistema e de aplicação; garanta que os parsers emitam JSON para seus frameworks.

• Buckets de log e retenção: Use buckets de log localizados regionalmente para residência de dados e CMEK. Os buckets padrão incluem _Default e _Required; este último armazena logs de auditoria de Admin Activity, System Event e Policy Denied com retenção fixa de longo prazo. Crie buckets dedicados por classe de dados (ex: app, segurança, analytics) com retenção e CMEK personalizados. Uma retenção mais longa melhora a análise forense, mas aumenta o custo; exporte para arquivamento de longo prazo quando a retenção no Logging não for necessária.

• Sinks de log e exportações: Roteie com o Log Router usando sinks para o BigQuery (analytics), Pub/Sub (SIEM ou pipelines) e Cloud Storage (arquivamento). Use tabelas particionadas no BigQuery para gerenciar volume e custo. Sempre conceda à conta de serviço do sink acesso de escrita com o menor privilégio (least-privilege) ao destino para evitar falhas silenciosas. Evite loops de roteamento não reingerindo logs exportados de volta para o Logging.

• Consultas e métricas baseadas em logs: Use o Logs Explorer com filtros em logName, resource.type, severity, labels e campos jsonPayload. Derive métricas baseadas em logs (contador ou distribuição) para SLIs de taxa de erro e histogramas de latência, dando suporte a alertas. Controle a cardinalidade normalizando campos de alta variância.

• Cloud Audit Logs: Os logs de Admin Activity (escritas no control-plane), Data Access (leituras/escritas de dados do usuário), System Event e Policy Denied fornecem observabilidade administrativa. Os logs de Data Access são de alto volume e desabilitados por padrão para muitos serviços; habilite apenas onde for necessário e roteie para um bucket com retenção e CMEK apropriados. Os logs de Policy Denied ajudam a detectar violações de permissão e de políticas da organização (org policy) precocemente. Garanta a segregação de custódia: as equipes de segurança normalmente possuem e acessam os logs de auditoria, com visualizações restritas para outras equipes.

• Modos de falha e trade-offs:

  • Sinks muito abrangentes explodem os custos no BigQuery; filtre com precisão e expire as partições.
  • Campos JSON de alta cardinalidade (ex: URLs completas) degradam as consultas; higienize e extraia rótulos normalizados.
  • Retenção insuficiente prejudica as investigações; exportações para o GCS ou BigQuery mitigam isso.
  • A ausência do agente ou configurações incorretas do parser causam perda silenciosa de logs; alerte sobre o heartbeat do agente e erros de ingestão.

Exemplo: criar um bucket de log regional com retenção personalizada e exportar um sink de auditoria filtrado.

• 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

Monitoramento, Tracing e Diagnóstico de Aplicações

O Cloud Monitoring coleta métricas de sistema e de aplicação, suporta dashboards, alertas, verificações de tempo de atividade (uptime checks), canais de notificação e objetivos de nível de serviço (SLOs).

• Métricas e dashboards: Use as métricas integradas para os serviços do Google e crie métricas personalizadas via Cloud Monitoring API ou OpenTelemetry. Enfatize os quatro sinais de ouro (four golden signals): latência, tráfego, erros, saturação. Aplique rótulos (labels) criteriosamente; evite valores de rótulo ilimitados. Use o Metrics Scope para agregar visualizações de múltiplos projetos. Use MQL para consultas expressivas quando necessário.

• Alertas e canais de notificação: Implemente alertas de múltiplas janelas e múltiplas taxas de queima (multi-burn-rate) para SLOs para equilibrar a detecção rápida e a redução de ruído. Defina canais de notificação (e-mail, SMS, Pub/Sub, webhooks, ferramentas de incidentes de terceiros) e inclua links para runbooks e contexto na documentação do alerta. Use limites de taxa de notificação e fechamento automático de incidentes (autoclose) para prevenir tempestades de alertas.

• Verificações de tempo de atividade (Uptime checks): Sonde endpoints críticos de múltiplas regiões com verificação de TLS, DNS e correspondência de conteúdo. Vincule as verificações de tempo de atividade a alertas e SLOs de serviço. Lembre-se de que as verificações de tempo de atividade não validam dependências internas; complemente com transações sintéticas e verificações de saúde internas.

• SLOs e SLIs: Defina SLIs para disponibilidade, latência e correção. Configure SLOs no Cloud Monitoring Service Monitoring e acompanhe os orçamentos de erro (error budgets). Alerte sobre a queima do orçamento, não sobre erros brutos, para se alinhar ao impacto no cliente. Use portões de liberação (release gates) ou entrega progressiva para respeitar o orçamento de erro restante.

• Cloud Trace, Error Reporting, Profiler: Use tracing distribuído entre serviços com OpenTelemetry para anotar spans com metadados de requisição e dependência. Ajuste a amostragem dinamicamente por serviço e por caminho para garantir a cobertura de fluxos críticos enquanto controla o custo. O Error Reporting agrega automaticamente exceções dos logs, desduplica por stack trace e dispara notificações. O Profiler fornece perfis contínuos de CPU, heap e tempo de execução (wall-time) em produção com baixo overhead; use-o para eliminar caminhos críticos (hot paths) e reduzir custos.

• Modos de falha e trade-offs:

  • Cardinalidade excessiva de métricas aumenta o custo e torna as consultas mais lentas; agregue antes de emitir.
  • Amostragem de trace baixa esconde problemas de latência de cauda (tail latency); faça a amostragem com uma taxa mais alta para caminhos lentos.
  • SLOs desalinhados (ex: muito rígidos) geram fadiga de alertas; itere com dados de tráfego reais.
  • As verificações de tempo de atividade podem passar enquanto dependências internas falham; use SLOs cientes das dependências.

Operações de Plataforma, Runbooks e Gerenciamento de Incidentes

O rigor operacional reduz o tempo médio de detecção, mitigação e aprendizado.

• Runbooks e escalonamento: Todo alerta deve estar vinculado a um runbook determinístico com pré-condições, etapas de diagnóstico, rollback e modelos de comunicação. Defina rotações de plantão (on-call) e políticas de escalonamento claras. Armazene os runbooks em controle de versão e teste-os.

• Gerenciamento de incidentes e postmortems: Use severidades, papéis (comandante do incidente, comunicações, ops, SME) e canais padronizados. Prefira chat ops e páginas de status para comunicação em massa (broadcast). Escreva postmortems sem atribuição de culpa (blameless) capturando a linha do tempo, fatores contribuintes, lacunas na detecção, impacto no cliente e ações de acompanhamento (follow-ups) concretas vinculadas a responsáveis e datas.

• Gerenciamento de cotas e sinais de capacidade: Monitore as métricas de Service Usage e de cota de serviceruntime com alertas sobre a proporção de uso. Solicite aumentos de cota proativamente e alinhe os limites do autoscaling com as cotas. Use sinais de capacidade como CPU, memória, descritores de arquivo, pools de conexão e profundidade da fila. Para o GKE, ajuste o HPA/VPA e o cluster autoscaler; para GCE MIGs, defina cool-downs e autoscaling preditivo quando apropriado.

• Saúde do serviço e solução de problemas (troubleshooting): Combine o live tail do Logs Explorer, métricas baseadas em logs, dashboards e o Trace para reduzir o MTTD. Habilite o VPC Flow Logs e o Firewall Rules Logging para triagem de rede; use o console serial da VM para falhas de inicialização (boot). Mantenha a captura de pacotes e o rastreamento de kernel (kernel tracing) como procedimentos de emergência (break-glass) nos runbooks.

• Modos de falha:

  • O esgotamento de cota se parece com interrupções (outages); alerte sobre 80% de uso e aplique rate-limit no upstream.
  • O autoscaling sem pré-aquecimento (prewarming) causa cold starts; use réplicas mínimas para caminhos críticos.
  • A falta de verificações sintéticas (synthetic checks) mascara falhas visíveis ao cliente; implemente transações canary.

Automação, Inventário de Recursos, Políticas e Desvio (Drift)

Automatize tarefas repetitivas com o princípio de privilégio mínimo e idempotência.

• Ferramentas: Use o Cloud Shell para administração segura e efêmera com $HOME persistente; coloque binários auxiliares em ~/bin para persistência do PATH. Automatize com gcloud, APIs REST e bibliotecas de cliente. Use contas de serviço e workload identity para eliminar chaves de longa duração.

• Agendadores e orquestradores: Use o Cloud Scheduler para acionar jobs HTTP e do Pub/Sub em agendamentos cron. Use o Workflows para orquestrar a automação de múltiplos serviços com novas tentativas (retries), backoff exponencial, compensação e timeouts. Garanta a idempotência e adicione IDs de correlação aos logs.

• Exemplos de automação de rotina:

  • Exportação diária de ativos para o GCS e BigQuery para inventário e relatórios de desvio (drift).
  • Cálculo automatizado da taxa de consumo (burn-rate) do SLO com publicação em um dashboard.
  • Avaliação periódica de políticas em relação às políticas da organização e anomalias do IAM.

• Inventário de recursos e avaliação de políticas: O Cloud Asset Inventory fornece feeds de alterações em tempo real e de um ponto no tempo (point-in-time) de recursos, associações (bindings) do IAM e políticas da organização. Exporte para o BigQuery para análise histórica e detecção de desvio (drift); inscreva-se no Pub/Sub para triagem quase em tempo real de violações de política. Use o Policy Analyzer e o Recommender para detectar permissões do IAM excessivamente amplas e não utilizadas. Imponha restrições com a Organization Policy e valide as configurações antes da implantação com política como código (policy-as-code).

• Desvio de configuração (drift): Previna o desvio (drift) com IaC declarativo e validação contínua. Ao detectar, reconcilie automaticamente ou coloque os recursos em quarentena. Etiquete (tag) os recursos com proveniência (ex: deployment_id) para distinguir entre recursos gerenciados e ad hoc.

• Arquitetura de observabilidade para segurança, confiabilidade e custo:

  • Segurança: Roteie os logs de auditoria para buckets protegidos por CMEK e com acesso restrito; exporte para um projeto de segurança dedicado. Integre com o SIEM via Pub/Sub.
  • Confiabilidade: Baseie dashboards e alertas em SLIs e traces; ensaie a automação de incidentes com workflows.
  • Custo: Controle a cardinalidade das métricas, ajuste a retenção de logs por bucket, particione as exportações para o BigQuery e use o Profiler para otimizar os caminhos críticos (hot paths).

Exemplo: agendar uma exportação diária de ativos e executar um workflow.

• gcloud asset export –content-type=resource –output-path=gs://ORG-SEC-BUCKET/daily/resources-$(date +%F).json
• gcloud scheduler jobs create http run-asset-scan –schedule=“0 3 * * *” –uri=“WORKFLOW_EXECUTIONS_API_ENDPOINT” –http-method=POST –oauth-service-account-email=scheduler-sa@PROJECT.iam.gserviceaccount.com

Cenário de Problema Prático

A Contoso Commerce está lançando uma plataforma de checkout baseada em GKE multirregional. Requisitos: administração auditável, alertas baseados em SLO com ruído mínimo, rastreamento de ponta a ponta das requisições, inventário de conformidade noturno automatizado e controles de custo rigorosos.

Abordagem:

1. Estabelecer as bases de logging e auditoria

• Criar buckets de log regionais com CMEK para logs de aplicação, segurança e análise; definir 30 dias para aplicação, 400+ dias para segurança, conforme necessário. Roteie os logs de Admin Activity, System Event e Policy Denied para o bucket de segurança; habilite os logs de Data Access apenas para os serviços de pagamento.
• Justificativa: A segregação por sensibilidade reduz o raio de impacto (blast radius) e o custo; a CMEK atende aos requisitos de conformidade; o escopo limitado do Data Access evita picos de volume.

2. Implementar logging de aplicação estruturado e coleta

• Implantar o Ops Agent nos nós do GKE e coletores sidecar/daemonset para enviar logs de aplicação como JSON estruturado com IDs de correlação (trace_id, span_id) e rótulos de usuário/sessão higienizados para remover PII.
• Justificativa: Logs estruturados permitem consultas precisas, métricas baseadas em logs e junção com traces; IDs de correlação dão suporte a diagnósticos distribuídos.

3. Implantar rastreamento distribuído, agregação de erros e profiling

• Instrumentar os microsserviços com SDKs do OpenTelemetry exportando para o Cloud Trace; definir amostragem mais alta para os caminhos de checkout e pagamento. Habilitar o Error Reporting para todos os runtimes e o Profiler para serviços críticos em CPU/memória.
• Justificativa: Traces localizam a latência por salto de serviço; o Error Reporting agrupa stack traces para acelerar a triagem; o Profiler reduz o custo de computação e a latência de cauda (tail latency).

4. Definir SLIs/SLOs e configurar alertas e dashboards

• Definir SLIs: latência p90 e p99 do checkout, disponibilidade da API de checkout e taxa de sucesso de pagamento. Definir SLOs (ex: 99,9% de disponibilidade, latência p99 abaixo de 800 ms). Configurar alertas de taxa de consumo (burn-rate) (2% em 1 hora e 1% em 6 horas) com links para runbooks e canal do PagerDuty; construir dashboards exibindo os sinais dourados (golden signals) e tendências do orçamento de erro (error budget).
• Justificativa: Alertas de orçamento de erro estão ligados ao impacto no cliente e reduzem o ruído; dashboards fornecem consciência situacional operacional.

5. Adicionar verificações de saúde externas e internas

• Configurar verificações de tempo de atividade (uptime checks) multirregionais para os endpoints de checkout com validação de conteúdo; adicionar verificações de transação sintética para o fluxo do carrinho ao pagamento. Integrar com as readiness probes do GCLB e GKE.
• Justificativa: As verificações de tempo de atividade (uptime checks) validam a disponibilidade para o cliente; fluxos sintéticos detectam quebras de dependência.

6. Automatizar inventário, monitoramento de políticas e detecção de desvio

• Criar um projeto de Segurança para receber exportações do Cloud Asset Inventory para o GCS e BigQuery; habilitar feeds do Pub/Sub em tempo real para alterações de IAM e políticas da organização. Executar Workflows noturnos para comparar manifestos de estado desejado com os ativos atuais; abrir tickets ou reconciliar automaticamente desvios de baixo risco.
• Justificativa: O inventário centralizado apoia auditorias; a avaliação contínua de políticas previne o aumento de privilégios (privilege creep); a automação controla o desvio (drift).

7. Gerenciar cotas e capacidade

• Monitorar cotas de computação, balanceador de carga e API com alertas em 70% e 85% de uso. Solicitar previamente cotas maiores para a carga alvo; alinhar os limites do autoscaler de cluster do GKE e do HPA com as cotas. Habilitar o autoscaling preditivo para serviços baseados em MIG onde a inicialização é lenta.
• Justificativa: Tetos de cota podem se passar por interrupções; ajustes proativos e autoscaling alinhado previnem o throttling sob picos de carga.

8. Otimizar custos em observabilidade

• Limitar a retenção de logs por bucket, excluir logs de depuração (debug) verbosos em produção através de filtros do Log Router e exportar apenas os campos necessários para o BigQuery com expiração de partição. Restringir a cardinalidade dos rótulos de métricas; usar os achados do Profiler para reduzir o tamanho (downsize) dos serviços mais ativos.
• Justificativa: A observabilidade deve ser custo-efetiva; retenção e exportações direcionadas evitam gastos descontrolados.

9. Preparar runbooks e prática de incidentes

• Criar runbooks versionados para cada política de alerta, incluindo consultas de diagnóstico, filtros de trace, comandos de rollback e comunicações. Realizar game days para validar a escalada e a automação.
• Justificativa: Respostas determinísticas e praticadas reduzem o MTTR e melhoram a confiabilidade.

10. Validar e iterar

• Revisar continuamente o ruído dos alertas, ajustar os limiares e refinar os SLOs com base no tráfego real. Acompanhar os itens de ação pós-mortem até a conclusão, com responsáveis e prazos.
• Justificativa: A observabilidade e as operações melhoram através de feedback medido, reduzindo o trabalho repetitivo (toil) e aumentando a qualidade do serviço ao longo do tempo.

← Migração · Todos os domínios · DevOps →

Pratique estas questões → · Prática cronometrada no ExamRoll.io →

Navegar Google →