APRENDER. PRATICAR. EVOLUIR.Começar pelo impacto e pela decisão necessária
Às 05:00, um batch falha e o fecho financeiro é às 06:00. Reúne factos sobre o trabalho afetado, consumidores, prazo e alternativa disponível. Número de alertas ou senioridade de quem telefona não substituem critérios acordados de impacto e urgência. O exercício fornece uma matriz local: pagamentos bloqueados a menos de 30 minutos do cut-off são P1; relatórios com workaround até ao dia seguinte são P2. Essa regra serve o caso fictício, não é uma tabela universal do ITIL. A primeira decisão deve reduzir impacto no âmbito autorizado.
Um processo ativo ainda precisa de aceitação
Define o que conta como recuperação antes de confundir o indicador técnico com o serviço. Para este batch, os critérios são ficheiro completo, ausência de duplicados e confirmação de consumo. Um restart pode ser uma etapa útil sem satisfazer os três critérios. Mantém visível o estado de cada verificação. Se parte dos movimentos já foi aplicada, um replay pode criar efeitos duplicados. A equipa precisa de reconciliar o resultado e escolher uma recuperação suportada; não basta repetir até desaparecer o erro do scheduler.
Restaurar e investigar podem avançar em paralelo
Um workaround válido pode reduzir impacto enquanto a gestão de problemas continua a investigar causas reais ou potenciais. Relaciona incidentes repetidos e conserva as condições em que a alternativa foi ensaiada. Versão, configuração, efeitos externos e autorização podem limitar a reutilização. Não declares eliminação da causa só porque uma execução terminou. Também não retenhas uma recuperação viável apenas para esperar por uma explicação completa. O registo deve permitir ao turno seguinte perceber o que funciona, o que continua incerto e o risco residual.
A pré-autorização tem fronteiras
O título renovação de certificado não determina sozinho o tratamento da mudança. Neste exercício, o modelo standard cobre versão A e o mesmo algoritmo. Uma proposta que usa B e altera o algoritmo ultrapassa as condições fornecidas. Avalia risco, teste, recuperação e autoridade apropriada. A frequência mensal não amplia automaticamente o modelo. Se a expiração próxima tornar a intervenção urgente, o procedimento local permite contacto com uma autoridade de emergência; isso acelera a decisão sem transformar urgência em aprovação implícita.
Comunicar sem inventar uma previsão
Uma atualização útil distingue impacto, factos confirmados, hipótese e próxima decisão. Às 05:20, podes informar que o processamento retomou e a reconciliação continua por validar, com atualização às 05:30. Esse compromisso de comunicação não é uma promessa de recuperação às 05:30. Se a equipa não tem estimativa fiável, diz o que falta para a produzir. O service desk mantém contacto e compreensão da necessidade enquanto especialistas analisam o mecanismo. Evita obrigar o cliente a reconstruir o incidente a partir de tickets de vários fornecedores.
A passagem de turno transfere capacidade de agir
Um handover deve permitir que o colega tome a próxima decisão. Inclui âmbito, cronologia, efeitos já produzidos, acessos necessários, autoridade disponível e critérios de recuperação. Testa a cobertura fora de horas: receber um alerta não ajuda se o único fornecedor capaz de recuperar a base de dados só responde em horário diurno. A lacuna envolve pessoas, informação, parceiro e fluxo. Um documento pode estar completo e a capacidade operacional continuar ausente. Identifica o responsável e resolve essa diferença antes de aceitar operação 24/7.
Prática guiada: três registos, três finalidades
No fixture, o incidente acompanha recuperação funcional, o problema acompanha repetição e causa, e a mudança regista a decisão sobre a intervenção. São finalidades distintas, não três equipas obrigatórias ou uma sequência rígida. Identifica o que pode fechar segundo os critérios locais e o que continua aberto. Resposta orientadora: running e ticket externo fechado não satisfazem a recuperação; a causa também continua pendente. Completa a matriz com responsável e evidência necessária. O exercício não executa um workflow de ITSM nem conhece procedimentos internos de qualquer banco.
Synthetic service fixture, not an ITSM workflow
05:00 incident: batch stopped; cut-off 06:00
05:20 process=running; reconciliation=pending
consumer: some transactions already applied
problem: cause unresolved; recurrence observed
change: restart authorized; replay not yet assessed
next communication: 05:30, not a recovery promiseO job retomou às 05:20, mas a reconciliação está pendente e houve aplicação parcial. O responsável comunica o estado e coordena validação antes de aprovar replay ou recuperação total.
Armadilhas comuns
Fechar por running; repetir efeitos incertos; aplicar workaround fora de versão; confundir emergência com autorização; entregar um runbook sem acesso ou cobertura.
Tópicos relacionados: Gestão de incidentes · Níveis de serviço e melhoria
Recuperação, causa e mudança precisam de critérios próprios e informação suficiente para a próxima decisão.
Referência: Incident Management practice overview · ITIL 4 Foundation; syllabus v4.2.0 (March 2025)