APRENDER. PRATICAR. EVOLUIR.Começar pelo resultado do serviço
Um processo ativo e um endpoint 200 não confirmam que o relatório do ciclo atual está disponível. Identifica a população de utilizadores, a operação, a atualização exigida e o resultado esperado. Se faltam amostras e também o heartbeat do coletor, regista uma lacuna de observabilidade em vez de concluir zero erros. Procura fontes alternativas e investiga a recolha. Numa release, separa versão e tipo de operação: a média global pode melhorar enquanto as escritas do grupo novo falham. O trabalho de APS é ligar esses sinais ao impacto e à decisão seguinte, preservando o âmbito e as limitações de cada observação.
Organizar factos, hipóteses e cronologia
Uma alteração imediatamente anterior ao incidente é uma pista, não uma causa automaticamente confirmada. Regista a observação e formula uma hipótese que possa ser distinguida de alternativas. Conserva os horários com offsets: 10:55+01:00 corresponde a 09:55 UTC, pelo que às 10:00 UTC o resultado tem cinco minutos. O laboratório calcula essa diferença com instantes conscientes do fuso; não valida sincronização dos relógios. Na escalada L3, inclui impacto, janela, população, alterações relevantes, ações já tentadas e resultados. Um reinício que reduz erros pode ser mitigação útil, mas não reconcilia automaticamente operações anteriores nem termina a investigação da causa.
Passar responsabilidade sobre o estado atual
O modelo de passagem guarda a equipa seguinte, a revisão aceite e a revisão atual. A equipa B aceitou a revisão 4; entretanto, a revisão 5 acrescentou operações desconhecidas e uma restrição de replay. A comparação marca a passagem incompleta. Este é um modelo simples para tornar visível uma lacuna, não uma aplicação real de aprovação. Na prática, explica a mudança material, confirma aceitação e comunica quem coordena. Inclui responsáveis por reconciliação, próximos passos e hora da atualização ao negócio. Se o recetor não está disponível, trata a continuidade de cobertura pelo processo local. O fim do turno ou o envio de um link não demonstram, por si só, transferência efetiva.
Demonstrar autonomia no papel previsto
Um fornecedor recuperou o serviço usando a sua conta. O operador RUN previsto não consegue aceder ao recurso necessário e ainda não aceitou o serviço. O modelo de prontidão mantém ready falso, mesmo com recoveryTested verdadeiro. A lição é avaliar capacidade no contexto de quem ficará responsável. Um runbook deve indicar pré-condições, âmbito, resultados esperados, verificações e limites de paragem ou escalada. Pede uma execução controlada pelo papel autorizado, sem depender do autor para interpretar cada passo. Se houver suporte transitório, define cobertura, duração, limites e aceitação pelos responsáveis. O laboratório não testou permissões reais nem realizou uma sessão humana de aceitação.
Prever recuperação dentro do cut-off
No modelo, há 1200 itens acumulados, entram 30 por minuto e a capacidade de serviço é 70 por minuto. A fila reduz-se a 40 por minuto, demorando 30 minutos a drenar. Faltam 25 para o cut-off e a validação final precisa de cinco; só existem vinte para processamento. A taxa necessária seria 90 por minuto: sessenta de redução líquida mais trinta de entradas. Isto é uma necessidade calculada, não capacidade demonstrada. Avalia com os responsáveis opções de admissão, prioridade, capacidade ou resultado parcial permitido. Acrescentar workers não garante esse ganho quando outra dependência limita o serviço. As taxas constantes são uma hipótese explícita do exercício.
Ligar suporte, projeto e melhoria
A divisão de 75% suporte e 25% projetos pertence ao papel descrito neste contexto; não é uma regra universal de APS ou SRE. Se incidentes consomem capacidade prevista para projeto, torna o desvio visível e revê compromissos. Não mantenhas datas com uma hipótese de capacidade que deixou de ser verdadeira nem reclassifiques horas para esconder o problema. Fecha a oficina com um resumo em inglês: impacto conhecido, incertezas, mitigação, decisões pendentes, responsável e próximo ponto de situação. Junta uma lacuna de operação ao plano de melhoria, com critério de conclusão verificável. O guião está preparado para prática de equipa, mas a sessão humana e a revisão especializada continuam por realizar.
backlog = 1200
arrivals_per_minute = 30
service_per_minute = 70
drain_minutes = backlog / (service_per_minute - arrivals_per_minute) # 30
cutoff_minutes = 25
validation_minutes = 5
required_service = arrivals_per_minute + backlog / (cutoff_minutes - validation_minutes) # 90/min
# Synthetic constant-rate model, not measured capacity or an approved action.A equipa seguinte aceitou a revisão 4 do incidente; a revisão 5 acrescenta operações desconhecidas e restrição de replay. A aceitação anterior não cobre esse novo estado.
Armadilhas comuns
Confundir ausência de métricas com zero erros, média global com todos os grupos saudáveis, envio de documento com aceitação ou demonstração do fornecedor com autonomia RUN.
Tópicos relacionados: Gestão de incidentes · Gestão de projetos técnicos · Monitorização e observabilidade
Uma equipa autónoma conhece o estado, consegue executar os procedimentos autorizados e assume explicitamente as lacunas e as próximas decisões.
Referência: Managing Incidents · DR APS professional curriculum 2026-09; vendor-neutral operational guidance reviewed 2026-09-30