APRENDER. PRATICAR. EVOLUIR.Começar pela pergunta operacional e pela unidade
Um painel deve ajudar a decidir uma ação concreta: investigar atraso, suspender uma expansão, confirmar recuperação ou acompanhar uma dependência. Antes de escolher cores, define a população, o período e a unidade. Na série de CPU do exercício, as três amostras são 10%, 10% e 90%. A média de cerca de 36,7% não contradiz o pico de 90%; resume outra propriedade. Consultar o máximo permite encontrar a amostra elevada, mas não prova que durou toda a janela nem que causou o incidente. Ao discutir com desenvolvimento e APS, pede a ligação entre sinal, hipótese e verificação seguinte. Conserva os dados necessários para contrariar a hipótese, em vez de escolher apenas a agregação mais favorável. Num serviço de reporting, o utilizador pode estar à espera de um ficheiro mesmo quando a infraestrutura tem médias aceitáveis. Por isso, combina saúde técnica com um fluxo funcional representativo, sem tratar um único indicador como prova completa de disponibilidade.
Distinguir ausência, zero e supressão de notificações
Uma medição de zero erros tem significado apenas dentro de uma população e de um caminho de recolha conhecidos. Se os contadores de pedidos e erros deixam de emitir, substituir ambos por zero não cria uma medição válida de sucesso. No primeiro caso desta aula, a sonda funcional continua a falhar enquanto o painel esconde a ausência. A decisão é manter a aceitação pendente e investigar tanto o serviço como a telemetria. Existe uma segunda armadilha no arranque: uma policy de ausência para um heartbeat novo precisa de observar uma medição inicial; o facto de nunca ter alertado não demonstra que o produtor funciona. Ensaiar emissão e interrupção é parte do handover. Finalmente, um snooze pode suprimir notificações durante manutenção. Esse silêncio é uma configuração, não uma recuperação. Regista o período e âmbito da supressão, mantém observação adequada à janela e confirma o comportamento antes de reportar que o serviço regressou ao normal.
Ler o log sem inventar uma duração ou uma causa
O excerto original do exercício tem timestamp às 09:10 e receiveTimestamp às 09:14, com o evento delivery_failed do job report-17. Assumindo o relógio de origem correto, o evento está marcado quatro minutos antes da receção pelo Logging. Escreve três frases: o que foi observado, o que continua desconhecido e o que verificarias a seguir. Uma resposta adequada distingue o tempo do evento da chegada à plataforma e pede evidência sobre recolha, buffers e transporte. Não pode concluir que o job executou durante quatro minutos, porque nenhum campo representa o seu início. Também não há dois erros apenas por existirem duas horas. Para investigar uma janela de release, conserva os dois eixos temporais e a identificação do trabalho. Evita acrescentar o request_id único como label de uma métrica: isso multiplica séries. Mantém dimensões limitadas nas métricas e detalhes correlacionáveis nos logs, com o acesso e retenção apropriados ao contexto.
Seguir a cadeia de execução e a idade do trabalho
Quando A chama B, dois spans exportados não garantem uma trace distribuída ligada. No cenário, B ignora o contexto recebido e cria sempre uma raiz nova. Corrige propagação e extração do contexto e confirma trace ID, span ID e parent span ID na cadeia; aumentar sampling não resolve esta falha estrutural. Num fluxo assíncrono, acrescenta outra pergunta: há quanto tempo espera o trabalho mais antigo? Uma subscrição pode ter apenas três mensagens por confirmar e uma delas envelhecer enquanto as novas são processadas. Volume baixo não demonstra cumprimento do prazo. Investiga mensagens persistentes, falhas de processamento, acknowledgements e capacidade antes de concluir que todos os consumidores precisam de mais CPU. O exercício exclui filtros e transformações para tornar a observação clara. No sistema real, documenta essas configurações porque podem alterar a interpretação do backlog. Não confirmes mensagens apenas para melhorar o gráfico: rejeição, quarentena e reprocessamento precisam de uma decisão explícita sobre o trabalho.
Comparar indicadores por pedido e por janela
O quadro guiado contém dez janelas elegíveis, sem medições em falta. Nas primeiras nove, há 100 sucessos em 100 pedidos por janela. Na última, há zero sucessos em dez pedidos. O critério de janela boa é pelo menos 99% de sucesso nessa janela. Classifica cada uma antes de calcular: nove são boas e uma é má, pelo que o SLI por janelas é 9/10, ou 90%. Agora soma pedidos: há 900 sucessos em 910 pedidos, cerca de 98,90%. Nenhuma conta corrige a outra; medem unidades diferentes. Explica ao sponsor qual corresponde ao objetivo acordado e evita escolher depois a mais favorável. Como extensão, altera a última janela para 99 sucessos em 100 pedidos: ela passa exatamente no limiar, sem necessidade de arredondamento favorável. Se removeres os dados de uma janela, já não podes usar a regra do exercício sem definir o tratamento de dados ausentes e a elegibilidade.
Inventariar o que cada mecanismo de recuperação protege
Uma recuperação completa depende de mais do que um estado de backup bem-sucedido. Backup for GKE protege manifests e volumes suportados dentro do âmbito configurado; uma referência a uma imagem não guarda as suas camadas, e uma ligação a Cloud SQL não inclui a base externa. No ensaio, pede a localização da imagem recuperável, a proteção da base e a sequência de validação das dependências. Em Cloud Storage, restaurar um objeto soft-deleted cria uma nova versão viva. Um consumidor preso à geração anterior precisa de reconciliação da referência e teste do conteúdo esperado. Em Cloud Run, manter instâncias mínimas não garante que o mesmo processo nunca reinicie; um checkpoint necessário à retoma não deve existir apenas em memória. Para cada dependência, escreve objeto protegido, ponto recuperável, identidade de acesso, ação de restauro e critério funcional. Isto torna a conversa de resiliência verificável e revela lacunas antes de um incidente real.
Medir a recuperação até ao resultado funcional acordado
No segundo caso, a nova instância funds-recovery existe às 14:12 e passa a validação de dados às 14:18. Às 14:25, o cliente continua configurado para funds-live e o teste funcional falha. O RTO definido no exercício termina quando o serviço funcional é restabelecido, pelo que o relógio não pode parar às 14:18. Esse instante é um marco útil, com nome preciso: base validada. O plano seguinte precisa de coordenar destinos de escrita, acesso, configuração de ligação, reconciliação e teste da aplicação. PITR não reescreve automaticamente os clientes; apagar a origem também não é um mecanismo de seleção da instância nova. Mantém opções de recuperação enquanto a transição não está validada e regista decisões autorizadas. No comité, apresenta o tempo de cada etapa e o que falta para fechar o objetivo. A distinção entre componente pronto e serviço recuperado permite melhorar o próximo ensaio com base no caminho realmente observado.
Entregar responsabilidade e evidência ao turno seguinte
Um incidente prolongado pode atravessar equipas, idiomas e fusos horários. Prepara um registo vivo com impacto conhecido, hipóteses ainda abertas, alterações realizadas, decisões e próximas ações. Na passagem de Lisboa para outra equipa, revê o estado com quem vai assumir, obtém aceitação explícita e comunica quem coordena a partir desse momento. Uma mensagem enviada sem confirmação não prova transferência de comando. Para treinar, pede a um colega que explique a última decisão e a condição para a alterar, usando apenas o registo de passagem. Se não conseguir distinguir a base validada do serviço recuperado, ou ausência de métricas de zero erros, melhora o documento e repete. O resumo desta aula é preservar significado: o que o sinal mede, o que o mecanismo protege e quem tem responsabilidade pela próxima decisão. Liga este trabalho aos tópicos de governação de mudanças, reconciliação de dados e aceitação de releases. Estes exemplos são exercícios originais; não constituem execução de recuperação em Google Cloud.
{"timestamp":"2026-10-06T09:10:00Z","receiveTimestamp":"2026-10-06T09:14:00Z","severity":"ERROR","jsonPayload":{"job":"report-17","event":"delivery_failed"}}A base recuperada passa a validação às 14:18, mas a aplicação ainda aponta para a origem e falha às 14:25. O serviço continua por recuperar.
Armadilhas comuns
Substituir ausência por zero, inferir duração a partir da receção do log, esconder picos na média, ignorar imagens e bases externas, e parar o RTO antes da aceitação funcional.
Tópicos relacionados: Aceitação de releases e observabilidade · Reconciliação e recuperação de dados · Governação e coordenação de incidentes
Define a unidade do indicador, confirma o âmbito da recuperação e entrega ao turno seguinte uma decisão que possa ser explicada e continuada.
Referência: Filtering and aggregation: manipulating time series · Current linked standard guide; edition date unconfirmed (2026-09-30 inspection)