APRENDER. PRATICAR. EVOLUIR.Definir o resultado e a interface
Num serviço fictício de fundos, todos os servidores estão disponíveis, mas os ficheiros reconciliados chegam depois do fecho do negócio. A revisão deve começar pelo resultado útil e pelo prazo, acompanhados de indicadores técnicos para diagnóstico. Uma equipa cumprir a sua tarefa não comprova a entrega completa. Define quem recebe ocorrências, quem coordena, quem consegue recuperar e quem corrige defeitos. Estas funções podem estar distribuídas, com condições e contactos confirmados. Se a equipa se reorganizar, atualiza a interface e testa o encaminhamento; uma caixa antiga sem resposta não passa a funcionar por o documento ter data recente. O gestor ajuda a resolver lacunas e compromissos, respeitando as autoridades técnicas e de mudança aplicáveis em cada contexto.
Demonstrar a passagem para suporte
O caso Passagem tem uma assinatura de aceitação, mas o alerta ainda chega ao grupo anterior e o runbook usa outra versão. A transição permanece condicionada à resolução dessas lacunas. Ensaia deteção, encaminhamento, reconhecimento, escalamento e recuperação no âmbito autorizado. Confirma que o procedimento corresponde ao ambiente e às dependências relevantes. Um apoio temporário da equipa anterior pode fazer sentido, desde que capacidade, responsabilidade e prazo sejam aceites. Depois da passagem, novos pedidos fora de âmbito exigem rever procura e capacidade, sem aceitar trabalho invisível ou devolver tudo automaticamente. Se L3 recupera com um workaround e o defeito depende de código de outra equipa, separa a responsabilidade de recuperação da responsabilidade pela correção. A disponibilidade restabelecida não prova que a causa desapareceu.
Examinar dependências e estados intermédios
O objetivo de recuperação é duas horas, mas uma dependência crítica só garante primeira resposta em quatro. Não anuncies prontidão só porque existe contrato: resposta e restauro são compromissos diferentes. Procura uma alternativa ensaiada ou renegocia o objetivo com quem pode decidir. Numa mudança de API, o fornecedor reduz timeout e o consumidor mantém retries sobre resultados desconhecidos. Acorda semântica de falha e repetição e ensaia a combinação. No caso Esquema, produtor N+1 e consumidor N são incompatíveis durante trinta minutos, embora o estado final N+1/N+1 passe os testes. O risco está na transição. Define uma sequência ou mecanismo de compatibilidade e condições para avançar ou reverter. Diagramas finais e testes unitários isolados não comprovam essa janela.
Manter indicadores e decisões rastreáveis
Com 100000 eventos elegíveis e objetivo de 99,9%, o orçamento aritmético é cem falhas. Se vinte já ocorreram, restam oitenta para a mesma população e janela fixas; isto não autoriza provocar falhas. Conta transações na unidade acordada, sem transformar três alertas da mesma transação em três falhas. Se a definição exclui tráfego sintético por etiqueta, aplica a regra ao numerador e denominador. Usa a política de serviço efetivamente acordada: uma pausa de funcionalidades pode admitir correções urgentes com análise e aprovação. A exceção não é automática. Na retirada de um serviço, sete dias sem tráfego não cobrem um processo mensal conhecido. Confirma o ciclo e o consumidor antes de encerrar dependências. Estes exemplos são fictícios; o laboratório verifica apenas aritmética e regras sintéticas, sem validar políticas ou operação reais.
Outcome: valid reconciliation before business close
Dependency: response time is not restoration time
Acceptance: routing + acknowledgment + recovery evidence
Transition: producer/consumer versions during coexistence
Retirement: cover known cycles and confirm consumersPrimeira resposta em quatro horas não sustenta, por si só, um objetivo de recuperar todo o serviço em duas horas.
Armadilhas comuns
Assinatura como prova de prontidão; componente verde como resultado completo; resposta como restauro; estado final como prova da transição.
Tópicos relacionados: Fiabilidade e aprendizagem · Decisões técnicas e qualidade
Responsabilidade de serviço exige interfaces que funcionem, condições observadas e decisões acompanhadas durante todo o ciclo de vida.
Referência: SRE Engagement Model · GitLab Handbook 2026; DORA current five-metric model; SRE and engineering guidance reviewed 2026-09-30