Há um movimento consistente de amadurecimento nas áreas de tecnologia, e a gestão de problemas em TI, como pondera Rolando Bonaccorsi, Diretor de Operações da Vert Analytics, responde por uma pergunta que o atendimento emergencial não alcança. Restabelecer o serviço resolve o sintoma do dia. Descobrir por que o serviço caiu e impedir que caia de novo pela mesma razão pertence a outra disciplina.
A confusão entre as duas frentes explica boa parte dos incidentes reincidentes em operações de grande porte. Equipes dimensionadas para apagar incêndio acumulam chamados fechados sem causa identificada, e o mesmo defeito retorna semanas depois com outro número de protocolo. O registro cresce, a percepção de instabilidade também, e a área perde a chance de converter interrupção em aprendizado permanente.
Incidente e problema cumprem funções distintas
Um incidente é a interrupção ou a degradação de um serviço em curso, com prazo de resposta curto e meta de restabelecimento. Um problema é a causa subjacente que produziu aquele incidente, e pode permanecer ativa mesmo depois de o serviço voltar ao normal. Tratar as duas coisas no mesmo fluxo faz o time priorizar sempre o urgente, porque o urgente tem cronômetro e o estrutural não.
Na prática, a separação exige fila própria, responsável designado e indicador independente. Rolando Bonaccorsi dimensiona a diferença ao tratar o problema como registro vivo, aberto enquanto a causa não for eliminada, e não como tarefa encerrada junto com o chamado de origem. Sem fila distinta, o estrutural vira pauta recorrente de reunião e nunca vira trabalho planejado, com data e responsável definidos.
A análise de causa raiz e seus limites
Métodos de análise de causa raiz partem de uma pergunta encadeada, buscando o fator que, removido, impediria a repetição do evento. Conforme assinala Rolando Bonaccorsi, especialista em gestão de operações de TI e excelência em serviços, o risco do método está em parar no primeiro culpado disponível, normalmente uma mudança mal testada ou um componente antigo, quando a causa real se distribui entre processo, arquitetura e capacidade.
Uma falha de disco que derruba um sistema inteiro raramente é um problema de disco. Falta de redundância, ausência de teste de recuperação e dependência não mapeada entre serviços compõem o quadro, e cada um pede ação diferente. Análises que não chegam à camada de desenho produzem planos curtos, cumpridos com facilidade, e nenhuma redução real de reincidência.
Indicadores que mostram se a repetição caiu
Contagem bruta de incidentes diz pouco sobre maturidade, porque pode cair por queda de demanda e subir por melhora na detecção. Indicadores úteis isolam a repetição, como a proporção de chamados associados a problemas já conhecidos, o tempo médio entre ocorrências do mesmo defeito e o percentual de registros encerrados com causa confirmada, em vez de encerramento por normalização espontânea.
A leitura cruzada desses números, que Rolando Bonaccorsi examina como termômetro de confiabilidade, mostra se a operação aprende ou apenas responde mais rápido. Reduzir o tempo de atendimento sem reduzir a frequência indica equipe treinada em um ambiente que continua frágil, e a economia de minutos no restabelecimento não compensa o desgaste acumulado de usuários e áreas de negócio.
O registro de erros conhecidos como ativo operacional
Boa parte do ganho de gestão de problemas em TI vem de algo pouco glamouroso: a base de erros conhecidos. Rolando Bonaccorsi delimita o valor desse acervo ao apontar que soluções temporárias documentadas, com sintoma, contorno e situação da investigação, encurtam o atendimento seguinte e evitam diagnóstico repetido por plantonistas diferentes na mesma semana.
Manter a base atualizada depende de disciplina de registro no momento da crise, quando ninguém tem tempo para escrever. Operações mais maduras resolvem o impasse com um passo obrigatório de fechamento, curto e padronizado, que transforma o que foi descoberto às duas da manhã em informação recuperável. Sem o registro, cada repetição começa do zero.
