Gestão de problemas: guia prático para provedores

Resumo

• O incidente fecha quando o serviço volta, mas o registro de problema só fecha quando a causa some.
• Cada problema tem um dono, uma análise baseada em dados e uma próxima ação com data.
• Enquanto não há correção, o contorno vira erro conhecido e fica escrito para todo o turno.
• A correção quase sempre passa por uma mudança planejada, com janela, teste e plano de volta.

O que é gestão de problemas no NOC

É um processo separado do atendimento de quedas, com registro próprio para cada causa ainda não resolvida. O objetivo não é voltar o serviço, e sim impedir que ele caia de novo pelo mesmo motivo.

O NOC que só apaga incêndio fecha o chamado quando o serviço volta. A mesma OLT reinicia de novo na semana seguinte, outro técnico atende, reinicia de novo, e o ciclo continua sem ninguém perguntar por quê.

A gestão de problemas quebra esse ciclo abrindo um registro para a causa e acompanhando até a correção. Como a correção quase sempre mexe na rede, ela anda junto com a gestão de mudanças em redes, que garante que o conserto não vire a próxima queda.

Diferenças entre incidente e problema na operação de um provedor

Ponto	Incidente	Problema
Objetivo	Voltar o serviço	Eliminar a causa
Prazo	Minutos ou horas	Dias ou semanas
Quem conduz	Operador de turno	Dono técnico do assunto
Exemplo	Bairro sem internet às 21h	Porta PON que cai sempre que chove
Resultado	Serviço normalizado	Correção ou contorno documentado

Incidente, problema e erro conhecido

Entre o problema aberto e a correção aplicada existe um estado intermediário. O erro conhecido é o problema cuja causa já foi achada, mas que ainda não tem conserto definitivo no ar.

Nessa fase, o contorno fica escrito para o operador de qualquer turno. Se a porta PON cai quando chove, o procedimento diz o que conferir e o que fazer enquanto a caixa de emenda não é trocada.

Como funciona a gestão de problemas?

Um gatilho abre o registro, um dono conduz a análise e a causa encontrada vira contorno documentado e depois correção por mudança. O registro só fecha quando a falha para de voltar.

1. 1 · Gatilho

   Abrir o registro

   Incidente repetido, queda grande ou causa desconhecida abre um problema ligado aos chamados.

2. 2 · Dono

   Dar responsável

   Uma pessoa com conhecimento do assunto responde pelo registro até o fim.

3. 3 · Análise

   Achar a causa com dados

   Linha do tempo, gráficos, registros dos equipamentos e mudanças recentes.

4. 4 · Contorno

   Registrar o erro conhecido

   O que o turno faz enquanto a correção não sai, escrito e acessível.

5. 5 · Correção

   Corrigir por mudança

   Janela, teste e plano de volta, e depois a confirmação de que a falha parou.

O ciclo pode terminar sem correção, quando o custo de corrigir é maior que o de conviver com o contorno. Essa decisão também fica registrada, com quem decidiu.

Gatilhos para abrir um registro de problema

Sem critério escrito, o registro só é aberto quando alguém lembra, e isso quase nunca acontece no meio de um turno cheio. Três gatilhos simples resolvem a maior parte dos casos.

• Repetição: o mesmo equipamento ou o mesmo sintoma gerou dois ou mais incidentes num período combinado.
• Tamanho: a queda atingiu muitos assinantes ou um cliente corporativo com contrato de nível de serviço.
• Causa desconhecida: o serviço voltou, mas ninguém sabe dizer por que caiu.

Gestão de problemas passo a passo

O roteiro abaixo cabe no sistema de chamados que o provedor já usa e não pede ferramenta nova. O que ele exige é disciplina para abrir o registro e alguém responsável por fechar.

1. Crie o tipo problema: um campo ou categoria no sistema de chamados, com ligação para os incidentes de origem.
2. Escreva os gatilhos: deixe claro, num parágrafo, quando o operador deve abrir um registro novo.
3. Nomeie o dono: cada registro tem uma pessoa responsável, não um grupo ou uma fila.
4. Monte a linha do tempo: horário de cada evento, alerta, ação e mudança, tirados dos sistemas e não da memória.
5. Ache a causa: use cinco porquês ou diagrama de causa e efeito até chegar a algo que se possa corrigir.
6. Documente o contorno: escreva o erro conhecido onde o turno consulta, com o sintoma e o que fazer.
7. Peça a mudança: a correção entra no fluxo de mudanças com risco avaliado, janela e plano de volta.
8. Confirme e feche: acompanhe por um período e só feche quando o incidente parar de se repetir.

A gestão de problemas exige pouca estrutura e muita constância. Uma reunião curta por semana, revendo os registros abertos e a próxima ação de cada um, já evita que eles fiquem esquecidos.

Quando vale investigar a fundo e quando basta contornar?

Nem todo problema merece semanas de análise. A decisão depende de quanto a falha custa cada vez que volta e de quanto custa descobrir e corrigir a causa.

Como priorizar os registros de problema abertos

Situação	Frequência	Alcance	Caminho sugerido
Falha rara e pequena	Baixa	Poucos assinantes	Contorno escrito e revisão ocasional
Falha frequente e pequena	Alta	Poucos assinantes	Investigar, porque o custo se acumula no atendimento
Falha rara e grande	Baixa	Muitos assinantes	Investigar e preparar plano de resposta
Falha frequente e grande	Alta	Muitos assinantes	Prioridade máxima, com dono sênior e revisão diária

A tabela serve para ordenar a fila, não para descartar registros. Mesmo o problema que fica só no contorno precisa estar escrito, para não voltar a ser surpresa no próximo turno.

Exemplo: a OLT que reinicia toda terça-feira

Um caso ilustrativo mostra como o registro de problema muda o desfecho de uma falha repetida. Os detalhes são hipotéticos, mas o padrão é comum em provedores regionais.

Durante um mês, uma OLT de um POP reinicia quatro vezes, sempre na terça de madrugada. Cada vez, um operador diferente atende, vê o equipamento voltar sozinho e fecha o chamado como resolvido.

1. Gatilho: na revisão semanal, alguém nota quatro incidentes no mesmo equipamento e abre um problema.
2. Linha do tempo: os gráficos mostram a memória da OLT subindo aos poucos e caindo a zero a cada reinício.
3. Comparação com mudanças: o registro de mudanças aponta uma rotina de coleta nova, ligada no mesmo mês.
4. Causa: a rotina consulta a OLT com frequência alta demais, e a memória não é liberada até o reinício.
5. Contorno e correção: o intervalo da rotina é aumentado por mudança normal, e a memória para de crescer.

Sem o registro de problema, a falha continuaria aparecendo como quatro incidentes isolados. O guia sobre OLT reiniciando sozinha mostra outras causas possíveis para esse sintoma.

Ferramentas de análise de causa

A análise de causa usa dados, não opinião. Quatro técnicas simples dão conta da maioria dos casos de rede.

• Linha do tempo: o que aconteceu, em que ordem e com horário, de preferência tirado dos sistemas.
• Cinco porquês: perguntar o motivo até chegar numa causa que se possa corrigir.
• Diagrama de causa e efeito: separa equipamento, processo, pessoas e ambiente.
• Comparação com mudanças: muita falha começa logo depois de uma alteração na rede.

Que dados ajudam a achar a causa?

Ajudam o histórico do monitoramento, os registros dos equipamentos e o registro de mudanças, todos com horário confiável. Quanto mais longo o histórico, mais fácil enxergar o padrão.

O monitoramento de rede é a principal fonte, desde que guarde semanas ou meses de dados e não só os últimos dias.

No Zabbix, os eventos e gráficos de cada item mostram quando a métrica começou a fugir do normal, e não só quando o alerta disparou.

No Grafana, colocar lado a lado a métrica suspeita e as janelas de mudança costuma resolver metade da análise. Se a curva muda de comportamento logo depois de uma alteração, a hipótese principal já está na mesa.

• Relógio sincronizado: sem NTP em todos os equipamentos, a linha do tempo mistura horários e engana.
• Logs centralizados: registros guardados fora do equipamento sobrevivem ao reinício.
• Registro de mudanças: quem mexeu, onde e quando, para comparar com o início da falha.

O mesmo histórico permite avisar antes da próxima queda, como mostra o guia de análise preditiva de falhas. Para ver onde a gestão de problemas se encaixa entre as outras práticas da operação, leia sobre a implantação de ITIL na operação.

Erros comuns na gestão de problemas

Os erros mais comuns fazem o registro ficar aberto para sempre ou fechar cedo demais. Quase todos vêm da falta de dono ou da pressa em encerrar.

A Táquion Tech faz a análise de causa junto com a equipe do provedor e entrega cada correção como pedido de mudança, com risco, janela e plano de volta definidos.

Checklist mensal da gestão de problemas

Uma revisão por mês mostra se o processo está funcionando ou só gerando registros. O indicador final é simples: os incidentes repetidos precisam diminuir.

Quando a operação tem clientes corporativos, a queda de incidentes repetidos aparece também no SLA, porque cada reincidência evitada é uma indisponibilidade a menos no relatório do mês.

Perguntas frequentes sobre gestão de problemas

Serviços ligados a este guia

• Desenvolvimento de dashboards personalizados para provedores Modernização e automação
• Gestão de operadoras para empresas Redes corporativas
• Hospedagem de ERP de provedor Data center, energia e servidores
• NOC 24x7 para provedores NOC e operação de rede
• Inventário de equipamentos para provedores NOC e operação de rede
• Página de status para assinantes para provedores NOC e operação de rede
• Relatório pós-incidente para provedores Suporte N3

Fontes

1. Google, Site Reliability Engineering, Postmortem Culture: análise sem caça a culpados.
2. AXELOS, ITIL 4 Service Management: prática de gestão de problemas.