Quando muda a pessoa responsável por uma aplicação, não basta repassar uma lista de tarefas ou enviar links para um canal de chat. Quem assume o plantão precisa entender qual serviço foi afetado, quais decisões continuam em aberto, o que pode fazer e como confirmar se uma intervenção funcionou. Sem esse contexto, a equipe perde tempo reconstruindo os fatos e pode repetir ações ou deixar riscos sem tratamento.
Uma passagem de plantão técnico em aplicações PHP deve ser um resumo operacional, atualizado e orientado à próxima ação. Ela não substitui o sistema de incidentes, o gerenciador de tarefas nem os runbooks: conecta esses recursos e explica como interpretá-los durante o período de responsabilidade de quem assume o plantão.
Definir o que deve ficar sob responsabilidade de quem assume o plantão
Antes de definir um formato, determinem quais decisões a pessoa de plantão pode tomar e quais situações exigem escalonamento para outra função. O escopo pode incluir o monitoramento de alertas, o diagnóstico inicial, uma mitigação reversível e a coordenação de uma recuperação. Alterações destrutivas, migrações de dados ou decisões sobre comunicação externa podem exigir autorização explícita.
A passagem deve deixar visíveis, no mínimo, cinco elementos: o serviço envolvido, o estado atual, o impacto conhecido, a pessoa responsável pela próxima ação e o critério para revisar o resultado. Se algum deles faltar, quem assume pode saber que há um problema, mas não necessariamente como prosseguir.
Também convém definir quando o documento será atualizado, qual fuso horário a equipe usa e por qual canal uma emergência deve ser comunicada. O horário do último dado é relevante: uma métrica ou um estado de incidente sem marcação temporal pode levar alguém a agir com base em uma situação já resolvida.
Registrar incidentes e tarefas sem duplicar o acompanhamento
O registro da passagem não deve se transformar em outra fila de trabalho. Mantenham cada incidente no sistema que já o gerencia e anotem no resumo o identificador, o link, o estado e a próxima etapa. Assim, evita-se que duas cópias divirjam quando alguém atualiza uma e se esquece da outra.
Para um incidente em aberto, resumam os fatos necessários para dar continuidade:
- Serviço e ambiente: aplicação PHP, componente afetado e se o problema ocorre em produção, staging ou outro ambiente.
- Impacto observado: funcionalidade degradada, usuários afetados, se isso for conhecido, e abrangência ainda não confirmada.
- Estado e cronologia: início aproximado, alterações relevantes e última verificação, com fuso horário.
- Ações realizadas: o que foi alterado e qual resultado foi observado; separem fatos de hipóteses.
- Próxima ação e responsável: tarefa concreta, pessoa ou função responsável e momento da revisão.
- Escalonamento: condição que exige avisar outra pessoa ou equipe.
Para tarefas pendentes que não sejam incidentes, o ticket pode ser suficiente. Incluam-nas na passagem somente se afetarem quem assume o plantão: por exemplo, se tiverem um prazo durante o turno ou condicionarem uma intervenção operacional.
Vincular runbooks a condições e verificações
Um link para um runbook não explica quando usá-lo nem qual resultado esperar. Acrescentem uma frase que descreva o sinal que aciona o procedimento e os limites de sua aplicação. Por exemplo: “Usar se as verificações de integridade falharem em produção; não reiniciar o processo antes de confirmar se há uma migração em andamento”. O detalhe deve corresponder ao sistema real da equipe, e não a uma suposição.
O procedimento deve indicar as permissões necessárias, as etapas de diagnóstico, a ação segura, como validar a recuperação e como escalar se a verificação falhar. Em uma aplicação PHP, pode incluir referências a logs de erro, estado dos processos, métricas, filas ou dependências externas, desde que esses sinais existam e estejam acessíveis a quem está de plantão.
Se uma instrução depender de uma configuração específica, de uma versão ou de uma infraestrutura determinada, documentem esse limite. Não incluam credenciais nem segredos na passagem: indiquem os mecanismos autorizados para obter acesso. Um runbook desatualizado ou que exige permissões que ninguém tem é um risco, não uma ajuda.
Explicitar riscos, dependências e limites de recuperação
Registrem os riscos conhecidos que possam mudar a resposta: uma dependência degradada, uma tarefa agendada suspensa, uma solução temporária ou uma alteração recente ainda em observação. Para cada risco, indiquem qual sinal o confirmaria e qual ação é necessária. Se a causa não tiver sido comprovada, identifiquem-na como hipótese; não apresentem uma correlação como diagnóstico definitivo.
Os limites de recuperação também devem estar claros. Quais ações são reversíveis? Qual operação pode afetar dados? Há um backup cuja restauração tenha sido testada ou existe apenas uma política de backups? Quem autoriza uma restauração ou uma alteração de configuração? Distinguir entre capacidade documentada e capacidade verificada evita criar confiança injustificada.
Em sistemas com vários componentes, anotem as dependências e as equipes de contato usando as referências internas pertinentes. Não presumam que quem assume sabe se uma falha em uma API externa, em um banco de dados ou em uma fila explica o sintoma observado.
Usar um template conciso e verificar se ele permite agir
O template deve ser conciso o bastante para ser mantido durante um turno e preciso o bastante para orientar uma decisão. Um exemplo hipotético pode ilustrar o formato, mas os valores devem ser preenchidos com dados observados em cada serviço.
Serviço e ambiente: [aplicação / componente / ambiente] Período de plantão: [início e fim, com fuso horário] Estado atual: [normal / degradado / incidente em aberto] Impacto observado: [fatos e abrangência conhecida] Incidentes: [identificador, estado e referência] Última verificação: [horário, sinal e resultado] Ações realizadas: [alterações e resultado observado] Próxima ação: [etapa concreta, responsável e prazo] Riscos ou hipóteses: [sinal, limite e como distingui-los] Runbook aplicável: [referência e condição de uso] Escalonamento: [para quem e em qual condição] Decisões pendentes: [decisão, responsável e data de revisão]
Por exemplo, uma equipe poderia registrar que um alerta de fila continua ativo, vincular o incidente existente e atribuir a verificação de sua evolução à função que assume o plantão. Deve indicar o horário da última observação e qual limite ou sinal confirmaria que a situação se normalizou. Não é necessário copiar cada evento do ticket: é necessário deixar claro o ponto de partida e a próxima verificação.
Verificar a passagem pela perspectiva de quem assume
Um documento completo não garante que seja utilizável. O teste prático consiste em quem assume conseguir explicar o estado, localizar a fonte atualizada, identificar sua primeira ação e saber como verificar o resultado, sem depender da memória de quem está encerrando o plantão. Se precisar pedir esclarecimentos repetidamente sobre os mesmos pontos, o formato ou o runbook não está atendendo à necessidade.
Revisem periodicamente as passagens para encontrar campos vazios, links quebrados, responsáveis ambíguos ou instruções que ninguém validou. Depois de um incidente, incorporem os aprendizados ao runbook ou ao processo adequado, em vez de transformar cada passagem em um arquivo histórico difícil de consultar.
O critério final é operacional: a informação diferencia fatos de hipóteses, indica quando foi atualizada, atribui uma próxima ação e define como escalar e verificar. Assim, a troca de plantão preserva o contexto sem criar um sistema paralelo de documentação ou acompanhamento.
