Por Renato Ornelas,
Você já viveu a madrugada inteira tentando resolver uma falha crítica e, quando tudo “volta”, ninguém sabe quem fez o quê, qual mudança realmente resolveu e como evitar a repetição? Este episódio da série Como a OpenX resolve problemas é sobre diagnosticar em equipe com método, não com gritos no “war room”.
War room não é juntar gente: é ter processo
Quando um incidente é grande, montar um time dedicado faz diferença. Mas sem método vira ruído. O primeiro passo é eleger um líder e líder não é o “mais técnico no teclado”. É quem:
- Comunica com direção/gestão e suporte (status, prazos, próximos passos).
- Define prioridades e distribui tarefas claras (“você olha firewall”, “você checa interfaces”, “você valida OSPF/BGP”).
- Mantém um canal único de comunicação, evitando coro de “faz isso” atrás do operador.
- Acompanha KPIs/dashboards para saber, em tempo real, se melhorou ou piorou.
Regra de ouro: líder não aplica configuração em produção durante a crise. Ele pilota o time.
Papéis claros e foco absoluto
Cada pessoa cuida do seu domínio e só dele. Encontrou algo fora do seu escopo (ex.: você está em interfaces e viu BGP flapar)? Sinalize ao líder. Ele repassa para quem está no BGP. Isso evita colisões e “duas mãos no mesmo teclado”.
Evite colisões de configuração
Mudanças simultâneas quebram mais do que consertam. Em ambientes Juniper, use:
- configure private para isolar seu candidato e impedir que um commit incompleto de outra pessoa vá junto.
- Checagem de sessões de configuração ativas antes de commitar, para não sobrepor o trabalho alheio.
Documente hipóteses e commits
Crises longas viram amnésia operacional. Registre o que foi mudado, por quem e por quê. Sempre que possível, valide a hipótese de forma controlada:
- Aplique a mudança e confirme com métricas/cliente: melhorou?
- Reverta para testar causalidade: piorou/voltou o sintoma?
- Se não mudou nada, descarte e siga para a próxima hipótese.
Sem esse ciclo, você “dá sorte” hoje e sofre de novo amanhã.
KPIs e telemetria durante a crise
Quem está digitando não deveria vigiar gráfico. Tenha alguém (ou o líder) dedicado a painéis, alarmes e triagem. É comum um commit “consertar A e derrubar B” e isso só aparece rápido no dashboard.
Roteiro rápido de War Room (checklist)
- [ ] Defina o líder e o canal único de comunicação.
- [ ] Divida o problema por subsistemas (interfaces, roteamento, ACLs/firewall, DNS, etc.).
- [ ] Atribua donos e tarefas objetivas com ordem de execução.
- [ ] Padronize mudanças: ticket/nota curta com hipótese → ação → hora → resultado.
- [ ] Use configure private (ou equivalente) e verifique sessões ativas antes do commit.
- [ ] Tenha alguém olhando KPIs/telemetria e informando o líder em ciclos curtos.
- [ ] Faça testes controlados (aplica → mede → reverte, se necessário).
- [ ] Feche a crise com post-mortem: causa-raiz, linha do tempo, ações preventivas.
Quando o incidente é grande, método vence força bruta. Com liderança clara, papéis definidos, disciplina de mudança e métricas à vista, o time anda na mesma direção rápido, com menos retrabalho e com aprendizado reutilizável para a próxima.