APRENDER. PRATICAR. EVOLUIR.1. Começar pela pergunta e pela população
O PM de uma release fictícia recebe duas contagens: A teve dez falhas e B teve quatro. Antes de comunicar melhoria, pergunta quantos pedidos cada versão recebeu, em que janela e para que operação. No exercício, A tem mil pedidos e B cem, com registo completo e sem sampling. As taxas observadas são um e quatro por cento. O número absoluto menor não demonstra melhoria. Isto também não prova que a versão causou a diferença: carga, clientes e operações podem exigir análise adicional. Define a população que a decisão pretende representar e conserva numerador e denominador no relatório. Para um canary, mostra exposição e resultados por versão em vez de misturar tudo numa média global. Inclui a hora de recolha e os critérios usados para classificar falha. Outra pessoa deve conseguir reproduzir a comparação a partir dos dados identificados.
2. Contar linhas ou elementos representados
AppRequests inclui ItemCount, o número de elementos representados por uma linha amostrada. No exemplo controlado, a linha de falha representa dez pedidos e a de sucesso noventa. Contar uma falha entre duas linhas dá cinquenta por cento das linhas; usar os pesos dá dez por cento dos pedidos representados. Explica qual pergunta cada cálculo responde. Em KQL, agrupa pela versão pretendida e calcula somas e somas condicionais quando os pesos são aplicáveis. Confirma schema e tipos, porque as tabelas de workspace não usam necessariamente os mesmos nomes das experiências de consulta anteriores. Não inventes pesos para dados sem essa informação e não uses o cálculo para esconder perdas no exporter. O exercício pressupõe que os pesos representam corretamente a população; a realidade exige validar esse pressuposto. Uma população vazia deve aparecer como ausência de dados para avaliar, não como zero por cento de falhas.
3. Não agregar resumos como se fossem dados originais
Duas instâncias reportam p95 de cem e novecentos milissegundos. A média, quinhentos, não é automaticamente o p95 global. No laboratório, criamos duas populações com esses mesmos resumos individuais: numa, a instância rápida recebe quase todo o tráfego; na outra, a lenta recebe quase todo o tráfego. Os percentis globais são diferentes. O exemplo usa nearest-rank exato sobre pequenas listas locais; não reproduz o algoritmo aproximado de Kusto. Para uma análise real, conserva dados ou distribuições adequadas à agregação pretendida e interpreta as limitações do método usado. Mesmo uma média ponderada dos dois p95 não reconstrói em geral a distribuição perdida. Durante o reporting, identifica se o número representa uma instância, operação, região ou população combinada. Um dashboard pode apresentar números bem formatados que respondem a perguntas distintas. A revisão deve confirmar o significado antes de usar a cor do gráfico como critério de promoção.
4. Reconstruir o percurso sem inventar causalidade
No exemplo de tracing, A e B partilham TraceId e o ParentSpanId de B aponta para o SpanId de A. Isso permite identificar B como filho de A dentro do percurso observado. Não elimines B por parecer um duplicado só porque ambos partilham o trace. A propagação de contexto liga unidades de execução, mas não prova que o resultado de negócio foi aceite no destino. Ao investigar um timeout de pagamentos, relaciona o span com a confirmação funcional apropriada e distingue envio, receção e resultado. Se parte do contexto não for propagada, a proximidade temporal não basta para inventar uma relação pai-filho. Documenta a lacuna e verifica os pontos de passagem entre serviços. Usa identificadores de correlação próprios para diagnóstico, evitando dados pessoais ou segredos nos campos. O handover deve explicar que percurso foi observado e onde ainda falta evidência.
5. Distinguir o estado do alerta da repetição de mensagens
Uma regra stateful permanece Fired enquanto a condição não está resolvida e não dispara novamente em cada avaliação. A equipa deve acompanhar o alerta ativo e o seu responsável, em vez de esperar mensagens repetidas para confirmar que o problema persiste. Define uma política operacional de atualização e escalonamento que não dependa dessa suposição. Outra lacuna aparece num recurso novo com dynamic thresholds ainda sem histórico suficiente. A ausência de alerta durante aprendizagem não equivale a uma validação da primeira release. Consulta os requisitos atuais do tipo de regra e mantém critérios explícitos de observação e aceitação durante esse período. Evita escolher um número de dias de memória ou extrapolar suporte entre métricas. Para cada sinal, regista condição, população, janela, estado, ação prevista e responsável. Esta descrição permite identificar se falhou a deteção, a interpretação ou a resposta humana.
6. Ensaiar o caminho até quem responde
No caso fictício, o batch falhou às 22:55 durante manutenção. O alerta existe no portal, mas uma alert processing rule suprimiu os action groups. Às 23:10, o prazo aproxima-se e ninguém assumiu resposta. O fim da janela não garante execução retroativa das ações suprimidas. Aciona o percurso operacional autorizado e confirma o estado batch, enquanto se revê âmbito, filtros e calendário da regra. Uma segunda regra que adiciona action groups não prevalece sobre uma supressão também aplicável. Não reinicies trabalho de negócio apenas para produzir um novo alerta de teste. Separa o ensaio de notificação da recuperação da aplicação e confirma resultados parciais antes de qualquer repetição. No handover, identifica quem observa alertas durante manutenção, como se contacta o suporte e quem confirma a saída da supressão. Concluir a mudança inclui restabelecer essa capacidade de resposta.
7. Relacionar sondas com critérios funcionais
O endpoint /health deste exercício só confirma que o processo web responde. HTTP 200 não prova conclusão do batch que o endpoint nem consulta. Aumentar localizações ou frequência da mesma sonda melhora observação desse teste, mas não acrescenta o percurso funcional ausente. Define sinais adequados para o batch: início esperado, progresso, conclusão e resultado que o negócio precisa de confirmar. Os critérios concretos pertencem à aplicação e devem ser acordados com os responsáveis. Um teste sintético também precisa de refletir aquilo que afirma validar; nomear a sonda Payments não lhe dá cobertura automática dos pagamentos. Durante uma release, cruza sinais técnicos com resultados funcionais sem os tornar equivalentes. Se o PM só recebeu evidência web, comunica essa limitação e atribui a confirmação batch. Esta prática evita fechar uma mudança com uma parte importante do serviço ainda por observar.
8. Praticar cálculos e escrever uma decisão auditável
Executa o código local depois de prever as duas taxas e os percentis combinados. As catorze verificações usam dados fictícios e não executam KQL, consultam Azure ou medem a qualidade real da telemetria. O pequeno modelo de alertas é uma fotografia de condições fornecidas, não um scheduler nem um simulador de entrega de mensagens. Troca suppressed mantendo fired verdadeiro e observa que visibilidade e notificação são coisas diferentes. Troca depois owner e identifica quando continua a faltar resposta. Para concluir, escreve quatro linhas: população observada, resultado, limitação e próxima ação com responsável. No caso batch, indica explicitamente a ausência de garantia de replay e a necessidade de confirmar resultados antes de reiniciar. Liga esta aula à recuperação de releases e ao handover: uma decisão tecnicamente correta só produz efeito quando chega a quem pode atuar e fica registada com evidência suficiente.
# Original fictional datasets; local arithmetic only, not a KQL execution engine.
# Weighted rows are assumed representative. No claims about sampling correction
# beyond the supplied ItemCount values or production telemetry completeness.
from math import ceil
def weighted_failure(rows):
total = sum(r['ItemCount'] for r in rows)
return None if total == 0 else sum(r['ItemCount'] for r in rows if not r['Success']) / total
def nearest_rank(values, percentile):
return sorted(values)[ceil(len(values) * percentile / 100) - 1]
assert 10 / 1000 == 0.01
assert 4 / 100 == 0.04
assert 4 < 10 and 4 / 100 > 10 / 1000
sample = [{'Success': False, 'ItemCount': 10}, {'Success': True, 'ItemCount': 90}]
assert weighted_failure(sample) == 0.1
assert sum(not r['Success'] for r in sample) / len(sample) == 0.5
assert weighted_failure([]) is None
# Two datasets have identical per-instance p95 values but different global p95.
large_fast = [100] * 1000
small_slow = [900] * 10
small_fast = [100] * 10
large_slow = [900] * 1000
assert nearest_rank(large_fast, 95) == nearest_rank(small_fast, 95) == 100
assert nearest_rank(large_slow, 95) == nearest_rank(small_slow, 95) == 900
assert nearest_rank(large_fast + small_slow, 95) == 100
assert nearest_rank(small_fast + large_slow, 95) == 900
assert (100 + 900) / 2 == 500
def decision(fired, suppressed, owner):
# Snapshot model: no Azure scheduler, rule propagation or message delivery.
return {'visible': fired, 'notify': fired and not suppressed,
'needs_owner': fired and not owner}
assert decision(True, True, False) == {'visible': True, 'notify': False, 'needs_owner': True}
assert decision(True, False, True) == {'visible': True, 'notify': True, 'needs_owner': False}
assert decision(False, False, False) == {'visible': False, 'notify': False, 'needs_owner': False}
print('14 arithmetic and decision assertions passed; no KQL or Azure alert execution')
A versão canary tem menos falhas mas taxa superior; um alerta batch disparou durante supressão e ficou sem responsável. O aluno calcula populações e decide como acionar resposta sem reiniciar às cegas.
Armadilhas comuns
Comparar contagens sem exposição; ignorar ItemCount; fazer média de p95; confundir trace com sucesso; esperar mensagens repetidas de um alerta stateful; assumir replay após manutenção; usar uma sonda web como validação batch.
Tópicos relacionados: KQL e agregações · Tracing distribuído · Gestão de incidentes · Handover para RUN
Define a população e os limites de cada sinal. Confirma a deteção, o encaminhamento e a responsabilidade pela resposta antes de declarar a operação assegurada.
Referência: Use aggregation functions in Kusto Query Language · AZ-400 objectives 2026-07-27