Por Renato Ornelas,
Como ganhar velocidade (e aprendizado) na resolução de problemas?
Você já passou horas perseguindo um defeito até descobrir, pelo fabricante, que era um bug recém-identificado ou “conhecido”, mas que você acabou encontrando do jeito mais doloroso? A lição central deste tema é simples: escalar cedo economiza tempo, reduz impacto no cliente e acelera o aprendizado do time.
Por que escalar mais cedo?
Em operações de rede, o objetivo número um é reduzir indisponibilidade e impacto. Investigar por conta própria é importante para evoluir tecnicamente, mas há alguém do outro lado sendo afetado agora. Escalar quando alguém pode ajudar não desmerece sua capacidade é agir com foco no serviço e no cliente.
Há empresas que adotam como prática: abrir o chamado no fabricante assim que o incidente começa, enquanto o time interno segue investigando. Se a equipe resolve, o chamado é fechado. Se for bug, o processo já está adiantado.
Softwares evoluem rápido e, às vezes, falham. Ter contratos de suporte ativos (com Juniper, Huawei etc.) é essencial para obter correções, ferramentas de diagnóstico e priorização.
Caso real: duas frentes, uma solução
Em um incidente na rede da OpenX, o time identificou um comportamento estranho e escalou imediatamente internamente e para o fabricante. Atuamos em duas frentes:
- Fabricante: forneceu ferramentas para inspecionar o tráfego anômalo.
- Time OpenX: criou filtros para bloquear os pacotes maliciosos.
O desfecho foi a soma das duas expertises e o restabelecimento rápido do serviço.
4 sinais de que está na hora de escalar
- Você esgotou os procedimentos que conhece e não teve sucesso.
- O problema está fora da sua especialidade (ex.: OLT/GPON, se não é seu domínio).
- O incidente está crescendo e você não consegue estimar a resolução.
- O cliente está impaciente ou severamente impactado (sem serviço, por exemplo).
Como escalar do jeito certo (checklist)
Leve contexto e evidências para quem vai assumir:
- Logs e saídas de comandos relevantes.
- Procedimentos já executados (o que tentou e o resultado).
- Sintomas e impactos observados (quem, quando, onde).
- Hipóteses testadas e próximos passos sugeridos.
Isso evita retrabalho, acelera o diagnóstico e eleva seu próprio repertório técnico. E, por favor: acompanhe o caso após escalar. Não é “passar a bomba”; é colaborar e aprender.
Cultura que favorece a velocidade
Na OpenX, normalizamos o escalonamento interno e com parceiros. Quando algo foge do usual, envolvemos rapidamente especialistas e o fabricante. Escalar não é demérito; é maturidade operacional. O foco total é resolver o problema no menor tempo possível.
Para levar com você
- Escalar cedo reduz o impacto e acelera a recuperação.
- Suporte ativo com fabricantes não é luxo; é requisito de confiabilidade.
- Cheque os 4 sinais sempre que um incidente travar.
- Escale com um dossiê: fatos, evidências e passos já dados.
- Acompanhe e aprenda: cada incidente deve aumentar suas “ferramentas mentais”.
Na próxima vez que um problema cabeludo aparecer, não desperdice tempo precioso. Escale cedo, atue em conjunto e feche o ciclo com aprendizado. É assim que operações de alta performance vivem e evoluem.