APRENDER. PRATICAR. EVOLUIR.Definir população e denominador antes da percentagem
Uma percentagem só é interpretável com população, intervalo e regra de contagem. No exercício, A tem 9 falhas em 9000 pedidos e B tem 20 em 1000, na mesma janela e sem sobreposição. A taxa global é 29/10000=0,29%. A média simples de 0,1% e 2% seria 1,05%, porque daria o mesmo peso a grupos com volumes diferentes. Uma taxa global correta pode, contudo, esconder degradação numa população pequena. Por isso, mantém as dimensões necessárias à decisão, como revisão ou jornada de negócio, além do total. Antes de comparar dois painéis, verifica se contam pedidos, tentativas ou operações concluídas e se incluem as mesmas exclusões. Num handover APS, entrega estas definições com as queries e os responsáveis. Um número aparentemente preciso sem essas definições pode levar a decisões incompatíveis entre desenvolvimento, produção e negócio.
Reconhecer a precisão disponível nos histogramas
Uma distribuição agregada guarda contagens por intervalo; não conserva necessariamente cada latência original. No exemplo, 90 medições pertencem a [0,100) ms e 10 a [100,1000) ms. Se definirmos p95 observado como a medição de ordem 95 entre as 100 ordenadas, sabemos que está no segundo intervalo. Não sabemos se foi 120, 550 ou 900 ms. O valor 550 apresentado por uma estimativa não prova uma observação exata. Para praticar, constrói dois conjuntos com as mesmas contagens, mudando apenas os dez valores do segundo intervalo, e compara os percentis observados. Depois discute se a largura dos buckets permite tomar a decisão de latência pretendida. Não aumentes a precisão aparente do relatório com casas decimais que os dados não suportam. Distingue contagem, estimativa e medição individual quando explicares o resultado a quem aprova o serviço.
Interpretar a lógica de alerta e a identidade do recurso
Em alertas métricos, alinhamento e reteste têm funções diferentes. O primeiro regulariza os pontos observados; o segundo exige persistência da condição ao longo do tempo configurado. Se um valor já alinhado deixa de violar o limiar, a janela de reteste reinicia. Não somes dois períodos altos separados por um valor saudável como se fossem contínuos. Também importa a combinação de condições: AND pode reunir CPU alta numa VM e memória alta noutra. Para exigir ambas na mesma VM, avalia AND_WITH_MATCHING_RESOURCE e preserva labels de recurso compatíveis após agregação. No exercício, desenha duas linhas temporais, uma por VM, e marca qual condição se verifica em cada uma. Depois explica que decisão operacional o alerta deve permitir. O nome do painel não corrige uma query que perdeu a identidade necessária; a configuração deve conservar essa ligação.
Separar armazenamento, contagem e cobertura de traces
Uma métrica user-defined com âmbito de projeto pode contar eventos recebidos pela Logging API apesar de uma exclusão impedir o seu armazenamento em _Default. O exercício assume billing ativo, métrica existente e eventos que correspondem ao filtro. Não generalizes para uma métrica bucket-scoped: esta depende dos logs guardados nesse bucket. Um contador crescente também não permite reconstruir mensagens descartadas. Mantém no desenho a separação entre evidência agregada e conteúdo retido. No tracing, a ausência de spans de um pedido não invalida erros demonstrados por contadores ou logs. Sampling e propagação de contexto são mecanismos distintos; um trace ID não garante recolha completa. Durante um incidente, conserva os erros observados e trata a falta de traces como lacuna de diagnóstico. Verifica configuração de sampling, instrumentação e limites antes de concluir que o pedido não existiu ou que a chamada a jusante não ocorreu.
Escolher sinais de diagnóstico e probes adequadas
Perfis de uma aplicação Java com muito wall time e pouco CPU time sugerem espera, não uma causa única já demonstrada. Wall time inclui esperas por I/O, locks ou sincronização; CPU time mede execução no processador. Usa a diferença para escolher evidência adicional, como stacks e latência de dependências. Não aproves mais vCPU apenas porque uma função demora muito. Em GKE, um arranque legítimo de 90 segundos pode ser interrompido por liveness demasiado precoce. Readiness falsa não suspende liveness. Uma startup probe adia readiness e liveness até ter sucesso, com tolerância configurada para o arranque medido. Continua a existir possibilidade de reinício se a startup probe falhar além da tolerância. O exercício pede dois critérios separados: tempo aceitável para inicializar e condição que indica incapacidade de progresso após iniciar. Assim evitas transformar lentidão temporária em reinícios que impedem recuperação.
Reconciliar trabalho depois de um timeout
Um request timeout Cloud Run fecha a ligação e devolve 504, mas não termina o contentor que estava a servir o pedido. O código pode continuar; também não há garantia de que termine com sucesso. Logo, o erro de transporte não prova ausência de efeitos. No caso report-41, existe um registo durável que passa a completed e referencia o ficheiro publicado depois do timeout. Consulta esse estado e valida o objeto antes de decidir repetir. Criar report-42 muda a identidade do trabalho e pode produzir outra publicação. Se o resultado estiver incompleto, o procedimento de recuperação deve considerar os efeitos já ocorridos. O desenho da aplicação pode oferecer consulta por ID e repetição segura, mas essas propriedades precisam de implementação e evidência próprias. Não as atribuas automaticamente à plataforma. Regista no ticket o resultado visto pelo cliente e o resultado observado no serviço como factos distintos.
Decidir expansão e recuperação com o âmbito certo
No ensaio fictício, o canary tem 12 falhas em 100 pedidos e a versão estável 20 em 2000. O total de 32/2100 é cerca de 1,52%, mas a regra aprovada manda parar a expansão quando o canary excede 5% após pelo menos 100 pedidos. Os 12% do canary acionam essa decisão. Um alerta global de 2% serve outro âmbito e não substitui o critério de release. Depois de conter a expansão, avalia a recuperação prevista e conserva evidência da revisão afetada. Em Cloud Deploy, pedir rollback cria um novo rollout baseado numa release anterior. A criação do recurso ainda não prova sucesso do deployment nem recuperação funcional. Acompanha o resultado e valida o serviço. Repor uma versão de aplicação também não demonstra reversão de alterações de dados ou de efeitos externos; esses elementos devem estar cobertos pelo plano de recuperação.
Ligar orçamento de erro a ações verificáveis
Com SLO de 99,5%, a taxa de erro permitida é 0,5%. Uma janela com 2% de erros apresenta burn rate de 4: consome à taxa de quatro vezes a tolerância. Isto não significa que gastou 4% do orçamento completo. Para conhecer o restante, precisas do histórico, população e período do SLO. No exercício final, calcula primeiro taxas e depois escreve a ação que cada sinal justifica. Se um alerta chegou a um canal sem operador de prevenção, “melhorar alertas” é insuficiente como ação de postmortem. Define responsável, prazo e ensaio de entrega com reconhecimento pelo operador previsto, conservando o resultado. O fecho deve demonstrar a correção do percurso que falhou. Estes exercícios usam dados fictícios e documentação; não constituem medições de uma plataforma cloud nem procedimentos internos de um banco. A aprendizagem consiste em ligar cada decisão ao que a evidência permite concluir.
O canary falha 12% dos pedidos, mas o total do serviço mostra 1,52%; a decisão depende do critério aprovado para a revisão.
Armadilhas comuns
Calcular médias de percentagens sem considerar os denominadores, tratar trace ausente como pedido inexistente e considerar timeout ou criação de rollout como resultado final.
Tópicos relacionados: SLO e error budgets · Observabilidade e diagnóstico · Aceitação de releases
O sinal precisa de âmbito, cobertura e significado; a recuperação só está demonstrada quando o resultado necessário foi observado.
Referência: Alerting on SLOs · Current linked standard guide; edition date unconfirmed (2026-09-30 inspection)