APRENDER. PRATICAR. EVOLUIR.1. Capacidade por tarefa
Num serviço fictício de fundos, saber consultar o estado do batch não demonstra capacidade para o recuperar. Constrói uma matriz com tarefas concretas: reconhecer impacto, interpretar evidência, executar uma ação autorizada, confirmar o resultado e pedir apoio. Para cada pessoa regista competência observada, acesso, ferramenta e disponibilidade. Se Rui restaura A e Eva restaura B, existem duas pessoas, mas nenhuma substituição demonstrada por serviço. A escala deve ser avaliada perante uma ausência, uma mudança de versão e uma falha fora do caminho de sucesso. Uma célula sem evidência deve ficar por confirmar; não a convertas em aprovação porque houve formação.
2. Passar responsabilidade com confirmação
Uma passagem tem informação e responsabilidade. O registo deve indicar impacto atual, observações com hora, ações executadas e respetivo resultado, hipóteses ainda abertas, restrições, próximo passo e responsável. A pessoa que recebe confirma que compreendeu o estado e aceita a função. Num incidente em curso, comunica essa alteração às equipas participantes. Uma confirmação de leitura não prova aceitação. Se a nova equipa só consegue diagnosticar entre as 22:00 e as 22:20, confirma apoio com capacidade de restauro durante esse intervalo. Não assumes disponibilidade de quem saiu da escala nem resolves o problema partilhando credenciais.
3. Ensaiar limites e exceções
Prepara um exercício sem produção real: fornece um registo sintético com um alerta, uma versão e uma condição de paragem. A pessoa identifica o procedimento aplicável, explica a ação permitida, reconhece quando a deve interromper e contacta o apoio acordado. Depois confirma o resultado funcional esperado. Regista onde precisou de ajuda e repete essa parte com o guia corrigido. Um ensaio deve corresponder à versão instalada: queueDepth pode existir no guia e faltar no sistema. A solução é validar o significado e a métrica substituta, não decorar um nome antigo. Autonomia pode incluir um escalamento adequado; não exige acesso ilimitado.
4. Coordenar intervenções e evidência
Se duas equipas alteram a mesma configuração ao mesmo tempo, uma melhoria ou regressão torna-se difícil de atribuir. A coordenação deve identificar quem executa, em que sequência, com que autorização e que observação confirma o efeito. Mantém distintas uma hipótese rejeitada, uma mitigação temporária e uma causa confirmada. No exemplo de reconciliação, a redução dos erros HTTP é uma observação técnica positiva; um ficheiro ainda não reconciliado mantém a recuperação funcional por confirmar. Comunica ambos os estados em vez de reduzir a situação a verde ou vermelho. A investigação pode continuar após a mitigação, com responsabilidades e próximos passos definidos.
5. Reservar tempo para validar
Define o prazo pelo resultado necessário. Neste exercício, restauro de 18 minutos seguido de validação de 12 deve terminar às 02:00 UTC. O último início matemático é 01:30. Às 01:25, dez minutos adicionais de diagnóstico levariam o início para 01:35 e o fim para 02:05. O cálculo pressupõe durações fixas, sequência sem espera e nenhuma margem; na operação real essas hipóteses exigem evidência e contingência. Não omitas validação para fazer o relatório caber no prazo. Se a janela já não é viável, comunica o impacto e obtém uma decisão da autoridade adequada, sem inventar uma aprovação.
6. Oficina e resumo
Em pares, uma pessoa entrega um registo com três hipóteses e outra assume o turno. A primeira hipótese já foi rejeitada; a segunda foi mitigada; a terceira ainda não foi testada. O novo turno deve explicar o que sabe, o que falta confirmar, quem executa o próximo passo e quando precisa de decidir. Troquem de papel introduzindo uma lacuna de acesso de 20 minutos. A resposta deve propor cobertura explicitamente aceite e uma mensagem curta para os participantes. Resumo: capacidade é específica da tarefa; responsabilidade precisa de aceitação; evidência tem estados diferentes; restauro e validação consomem tempo. Estes exercícios não substituem procedimentos internos nem demonstram prontidão de uma equipa real.
Prazo validado: 03:00 UTC
Restauro: 16 min
Validação: 9 min
Último início: 03:00 - 00:25 = 02:35 UTC
Diagnóstico até 02:40 => conclusão às 03:05 UTCÀs 02:30 UTC, restauro de 16 minutos mais validação de nove tem de terminar às 03:00. A decisão pode esperar no máximo cinco minutos, sem margem adicional.
Armadilhas comuns
Confundir nomes na escala com capacidade, leitura com aceitação, redução de alertas com recuperação e início com conclusão.
Tópicos relacionados: Gestão de incidentes · Capacidade e conhecimento
Uma passagem está pronta quando existe responsabilidade aceite e capacidade demonstrada para o âmbito acordado.
Referência: SRE Workbook: On-Call · ITIL 4 CDS; observed syllabus v1.0 mirror, 2025 update comparison pending