Na revisão de agosto de 2026 do guia do exame Cloud Digital Leader, o domínio 6, "Escalonamento com as operações do Google Cloud", caiu para cerca de 10%, mas ganhou muitos itens novos e detalhados. Ele pergunta como medir o desempenho e a confiabilidade de um sistema por latência, tráfego, saturação e erros; como projetar para a resiliência com redundância, replicação, infraestrutura escalonável e backups; o Google Cloud Observability, do Cloud Monitoring ao Cloud Profiler; e, do lado dos custos, as políticas de cota, as regras de limite de orçamento, os relatórios do Cloud Billing, o Dynamic Workload Scheduler e o papel das pessoas, dos processos e da tecnologia.
Este artigo começa pelos termos básicos de operações e depois percorre os quatro sinais dourados, SLI, SLO e SLA com orçamentos de erro, o projeto para a resiliência, as ferramentas de observabilidade e os controles e práticas de FinOps que mantêm os custos sob controle. As definições básicas de SLI, SLO e SLA, DevOps, e orçamentos e descontos por compromisso de uso são tratados primeiro em Gestão de custos e excelência operacional.
---
Termos básicos de operações: excelência operacional, confiabilidade e alta disponibilidade
O guia do exame pede que você reconheça os termos fundamentais das operações em nuvem. Os três parecem iguais, mas focam em coisas diferentes.
| Termo | Significado | Exemplo | |------|------|------| | Excelência operacional | A capacidade de operar os sistemas com eficiência e continuar melhorando-os | Automação de implantações, monitoramento, melhorias depois de incidentes | | Confiabilidade | O quanto um sistema se comporta como esperado de forma constante | Os usuários recebem o resultado correto toda vez que fazem uma solicitação | | Alta disponibilidade | A capacidade de continuar atendendo mesmo quando ocorrem falhas, geralmente expressa como percentual de tempo no ar | O serviço continua em outras zonas quando uma zona cai |
Cada 9 a mais em um número de disponibilidade reduz a um décimo o tempo de inatividade permitido.
| Disponibilidade | Inatividade permitida por mês (aprox.) | |------|------| | 99% | 7 horas e 18 minutos | | 99,9% | 43 minutos e 50 segundos | | 99,99% | 4 minutos e 23 segundos | | 99,999% | 26 segundos |
Dica para o exame: Quanto mais alta a meta de disponibilidade, maiores o custo e a complexidade. Nem todo serviço precisa de 99,999%; definir uma meta que se encaixe no negócio faz parte da excelência operacional.
---
Os quatro sinais dourados: o que medir
Não dá para colocar centenas de mostradores no painel de um carro. O motorista olha o essencial: velocidade, combustível e temperatura do motor. A prática de SRE do Google diz que, se você só puder medir quatro métricas de um serviço voltado ao usuário, deve focar em latência, tráfego, erros e saturação. O guia do exame também cita esses quatro como a forma de medir o desempenho e a confiabilidade de um sistema.
!Os quatro sinais dourados, latência, tráfego, erros e saturação, medidos como SLIs e comparados com os SLOs
| Sinal | O que observa | Exemplo | |------|------|------| | Latência | O tempo para atender uma solicitação | 95% das solicitações de pagamento respondidas em até 300 milissegundos | | Tráfego | Quanta demanda chega ao sistema | Solicitações por segundo, usuários simultâneos | | Erros | O percentual de solicitações que falham | Percentual de respostas de erro do servidor (5xx), resultados incorretos | | Saturação | O quanto o sistema está cheio | Uso de CPU, memória, disco e filas |
A saturação é especial porque avisa antes de os problemas começarem. Os outros três pioram só quando os usuários já foram afetados, mas, quando a saturação se aproxima do limite, dá para aumentar a capacidade antes que aconteça uma queda.
Dica para o exame: "A velocidade de resposta que os usuários sentem" é a latência, "o volume de solicitações que o serviço recebe" é o tráfego e "se os recursos estão perto do limite" é a saturação.
---
SLI, SLO, SLA e orçamentos de erro
SLI, SLO e SLA são as ferramentas que transformam os sinais dourados em números gerenciáveis. A ordem é medir, definir uma meta e fazer uma promessa aos clientes.
| Termo | Papel | Exemplo | |------|------|------| | SLI (indicador de nível de serviço) | O valor realmente medido | 99,95% das solicitações tiveram sucesso neste mês | | SLO (objetivo de nível de serviço) | A meta interna definida pela equipe | Pelo menos 99,9% das solicitações com sucesso ao longo de um mês | | SLA (acordo de nível de serviço) | A promessa contratual aos clientes, com compensação se for descumprida | Abaixo de 99,5%, parte da taxa é devolvida como créditos |
O SLO é definido de forma mais rígida que o SLA. Isso deixa uma folga para ainda cumprir a promessa aos clientes mesmo que a meta interna seja descumprida por pouco.
Orçamento de erros: quanto de falha é permitido
O orçamento de erros é 100% menos o SLO. Se o SLO é 99,9%, o orçamento de erros é 0,1%, o que significa que cerca de 43 minutos de inatividade por mês, ou 1.000 falhas a cada milhão de solicitações, são permitidos.
Se ainda há orçamento: seguir com mudanças arriscadas, como lançar novos recursos e fazer experimentos Se o orçamento acabou: parar os lançamentos e focar em melhorar a estabilidade
Assim, uma equipe de desenvolvimento que quer "lançar rápido" e uma equipe de operações que diz "estabilidade primeiro" conseguem chegar a um acordo com base em dados, e não em intuição. O SRE combina isso com os post-mortems sem culpa, que focam nas causas e nas correções em vez de culpar pessoas pelos incidentes, e com o princípio de automatizar o trabalho manual repetitivo.
Dica para o exame: Se "o orçamento de erros acabou", a resposta certa é parar de lançar novos recursos e focar em melhorar a confiabilidade. Se perguntarem "qual é o orçamento de erros com um SLO de 99,9%?", a resposta é 0,1%.
---
Projetando infraestrutura e processos resilientes
Um avião tem dois ou mais motores para continuar voando se um parar. O guia do exame cita redundância, replicação, infraestrutura escalonável e backups como formas de projetar para a resiliência.
| Técnica | Significado | Exemplos no Google Cloud | |------|------|------| | Redundância | Vários componentes cumprem o mesmo papel para que o sistema continue funcionando se um parar | Grupos de instâncias gerenciadas com VMs distribuídas entre zonas, balanceamento de carga | | Replicação | Manter cópias dos dados sincronizadas continuamente em outros locais | Configuração de alta disponibilidade do Cloud SQL (uma instância em espera em outra zona), Spanner multirregional, Cloud Storage multirregional | | Infraestrutura escalonável | Adicionar e remover recursos automaticamente conforme a carga | Escalonamento automático, Cloud Run, Cloud Load Balancing | | Backups | Guardar à parte uma cópia de um momento específico para recuperar depois de erros ou ransomware | Backups automáticos do Cloud SQL, snapshots de disco, Backup and DR Service |
Replicação e backups são diferentes. Como a replicação mantém as cópias sincronizadas em tempo real, se alguém exclui dados por engano, a exclusão também é replicada. Um backup é uma cópia de um momento passado, então permite desfazer esse tipo de erro.
Ao planejar a recuperação de desastres, primeiro se definem duas metas.
| Meta | Pergunta | Exemplo | |------|------|------| | RTO (objetivo de tempo de recuperação) | Em quanto tempo depois de uma falha o serviço precisa voltar? | Recuperar em até 4 horas | | RPO (objetivo de ponto de recuperação) | Quantos dados se pode perder no máximo? | Recuperar os dados até os últimos 15 minutos |
Dica para o exame: "Voltar ao estado de ontem os dados excluídos por engano" é um backup. "O banco de dados continua funcionando mesmo se uma zona parar" é a replicação com uma instância em espera em outra zona (uma configuração de alta disponibilidade).
---
Google Cloud Observability: cinco ferramentas para enxergar dentro dos sistemas
O guia do exame pergunta como modernizar as operações com o Google Cloud Observability (antigos Stackdriver e operations suite) e cita cinco ferramentas.
| Ferramenta | O que faz | Pergunta que responde | |------|------|------| | Cloud Monitoring | Coleta métricas, painéis, alertas e verificações de tempo de atividade | O sistema está saudável agora? | | Cloud Logging | Coleta, armazena, pesquisa e analisa logs | O que aconteceu? | | Cloud Trace | Acompanha a latência de cada trecho enquanto uma solicitação passa por vários serviços | Onde ficou lento? | | Cloud Profiler | Analisa continuamente, com baixa sobrecarga, qual código usa mais CPU e memória nos aplicativos em execução | Qual código consome mais recursos? | | Error Reporting | Coleta os erros dos aplicativos, agrupa por tipo e avisa sobre os novos | Quais erros são novos? |
O Cloud Debugger, que você pode ver em material antigo, foi desativado em 31 de maio de 2023, então não está mais na lista.
Dica para o exame: "Descobrir qual trecho dos microsserviços deixa a resposta lenta" é o Cloud Trace, e "descobrir quais funções usam mais CPU para reduzir custos" é o Cloud Profiler.
---
O outro lado das operações: controles que mantêm os custos sob controle
Escalonar as operações significa controlar os custos, e não só a confiabilidade. O guia do exame cita as políticas de cota, as regras de limite de orçamento, os relatórios do Cloud Billing, o Dynamic Workload Scheduler e as Spot VMs como formas de controlar o consumo da nuvem.
| Controle | O que faz | Interrompe o uso de fato? | |------|------|------| | Orçamentos e regras de limite | Avisam quando os custos reais ou previstos passam de um percentual definido; podem acionar ações automáticas pelo Pub/Sub | Orçamentos somente de alertas não (alguns serviços suportam orçamentos com teto de gastos em um projeto) | | Cotas | Limitam quanto de um recurso ou quantas chamadas de API um projeto pode usar | Sim; as solicita