O que é um incidente de TI? Tipos, causas e como identificar

Toda equipe de TI convive com incidentes. Ainda assim, poucas conseguem definir com precisão o que é um incidente, quais tipos existem e onde ele termina. Essa imprecisão custa caro: ela aparece no SLA medido errado, na fila mal classificada e no relatório que ninguém confia.

A confusão começa no vocabulário. No dia a dia, a equipe chama de incidente qualquer coisa que incomoda. Por outro lado, o ITIL trata o termo com rigor, porque dele dependem prazos contratuais, acionamento de plantão e indicadores de disponibilidade.

Neste guia, você vai ver a definição formal de incidente de TI. Além disso, cobrimos as características que o identificam, os tipos por origem e as causas mais frequentes. Por fim, traçamos a fronteira que separa incidente de problema, evento e requisição de serviço.

O que é um incidente de TI?

Um incidente de TI é a interrupção não planejada de um serviço ou a redução da sua qualidade acordada. Essa é a definição adotada pelo ITIL 4. Vale notar que a parada total não é obrigatória. Um sistema lento, um relatório que não gera ou uma transação intermitente também contam como incidente.

A expressão decisiva aqui é não planejada. Uma janela de manutenção comunicada com antecedência derruba o serviço, porém não gera incidente, porque o cliente concordou com aquela indisponibilidade. Em contrapartida, a mesma queda fora da janela vira incidente imediatamente.

Vale destacar que o framework ITIL mudou o vocabulário na versão 4. O que a v3 chamava de processo agora se chama prática. As definições dos termos operacionais, porém, permaneceram estáveis, conforme a documentação oficial do framework.

As três características que definem um incidente

Nem toda anomalia técnica se qualifica como incidente. Para receber esse rótulo, uma ocorrência precisa reunir três atributos ao mesmo tempo.

Primeiro, ela não foi planejada. Ninguém aprovou, agendou ou comunicou aquela degradação. Esse critério sozinho já separa incidente de manutenção programada, de janela de deploy e de teste de contingência.

Segundo, ela atinge um serviço acordado. Existe um compromisso, formal ou implícito, sobre disponibilidade e desempenho. Sem esse acordo como referência, não há como afirmar que algo saiu do esperado, porque nunca se definiu o esperado.

Terceiro, ela exige restauração e não investigação. O objetivo imediato é devolver o serviço ao usuário no menor tempo possível. Descobrir a origem também importa, mas isso pertence a outra prática, com outro ritmo e outro time.

Tipos de incidente de TI por origem

Classificar por origem ajuda a rotear o chamado para quem sabe resolver. A tabela abaixo reúne as seis categorias mais comuns nas operações brasileiras.

Repare que a última linha não descreve uma tecnologia, mas um comportamento. Essa categoria costuma ser a mais subnotificada, principalmente porque ninguém gosta de registrar que a própria equipe causou a parada.

O que não é incidente: problema, evento e requisição

Três conceitos vizinhos são confundidos com incidente todos os dias no service desk. Distinguir os quatro é o que mantém o SLA honesto.

O problema é a causa de um ou mais incidentes. Enquanto o incidente é o sintoma que o usuário sente, o problema é a razão por trás dele. Por isso a gestão de problemas de TI trabalha em outro prazo: ela busca a eliminação definitiva, não a restauração imediata.

O evento é qualquer mudança de estado detectável em um componente ou serviço. A maioria dos eventos é apenas informativa e nunca chega a um ser humano. Um evento só vira incidente quando o serviço entregue perde qualidade. Nesse sentido, a correlação de eventos existe justamente para filtrar o que merece virar chamado.

A requisição de serviço é um pedido previsto e autorizado no catálogo, como criar um usuário ou liberar um acesso. Nada quebrou, portanto não existe incidente. Confundir os dois infla artificialmente o volume de incidentes e derruba o indicador de disponibilidade sem motivo real.

Em resumo, use uma pergunta simples na triagem: algo que deveria estar funcionando parou de funcionar sem aviso? Se a resposta for não, provavelmente você está diante de um evento, de um problema ou de uma requisição.

As causas mais comuns de incidentes de TI

As origens se repetem com uma regularidade que surpreende quem olha os dados pela primeira vez. Cinco padrões respondem pela maior parte do volume.

Mudanças mal executadas lideram em praticamente toda operação madura. Deploys sem validação, alterações de configuração fora de janela e rollbacks mal testados derrubam serviços que estavam estáveis minutos antes.

Esgotamento de capacidade aparece logo em seguida. Disco que enche, memória que satura ou pool de conexões que estoura: todos avisam antes. Isso vale desde que alguém acompanhe a tendência, não apenas o estado atual.

Dependências externas completam o pódio. Provedores de nuvem, gateways de pagamento e links de operadora falham fora do seu controle. Ainda assim o incidente é seu, porque o usuário reclama com você.

Erro humano é a quarta origem. Segundo o levantamento do Uptime Institute, quase 40% das empresas sofreram uma interrupção grave desse tipo em três anos. Desses casos, 85% vêm de falha em procedimentos.

Por fim, aparecem as falhas de hardware e infraestrutura física. Elas são menos frequentes do que a intuição sugere. Contudo costumam gerar os incidentes de maior duração, porque dependem de peça, de fornecedor e de deslocamento.

Cabe ressaltar que identificar a origem recorrente é diferente de tratá-la. Essa investigação pertence à análise de causa raiz, que atua depois que o serviço já voltou.

Exemplos de incidentes de TI no dia a dia

A definição fica mais clara com casos concretos. Considere quatro cenários frequentes em empresas brasileiras de médio e grande porte.

Uma indústria opera com matriz e filial ligadas por dois links distintos. Em determinada manhã, o sistema de gestão para na fábrica. A paralisação é o incidente. A comutação para a rota alternativa é a solução de contorno. Já a razão pela qual o link primário parou de responder é o problema.

Um varejo percebe que o checkout demora quinze segundos para concluir. Ninguém viu erro na tela, mesmo assim a conversão despencou. Aqui existe incidente, porque a qualidade acordada caiu, ainda que o serviço continue no ar.

Um banco de dados corporativo esgota o pool de conexões às sextas-feiras à tarde. O relatório gerencial não gera e a diretoria fica sem número. Esse é um incidente recorrente, isto é, o candidato natural a virar um registro de problema.

Uma equipe publica uma regra de firewall sem validação prévia. Em seguida, um serviço interno fica inacessível para metade dos usuários. O incidente nasceu de uma mudança, portanto o tratamento passa também pela revisão do processo de aprovação.

O impacto de um incidente vai além do tempo fora do ar

Muita operação mede incidente apenas por duração. Essa leitura é incompleta, porque o mesmo tempo parado produz consequências muito diferentes conforme o serviço afetado.

Existe o impacto financeiro direto, que aparece em venda perdida, multa contratual e retrabalho. Existe também o impacto reputacional, mais lento e mais difícil de reverter, sobretudo quando o cliente descobre a falha antes da sua equipe.

Some-se a isso o impacto operacional interno. Cada incidente consome atenção de gente cara, interrompe projetos planejados e alimenta o ciclo em que a equipe nunca sai do modo reativo. Do mesmo modo, incidentes frequentes desgastam a confiança entre TI e as áreas de negócio.

É por isso que a classificação por gravidade importa tanto quanto a classificação por tipo. Uma matriz de severidade bem definida traduz impacto e urgência em um nível objetivo. Dessa forma, a decisão sai do julgamento individual de quem está de plantão.

Do incidente detectado ao incidente tratado

Identificar corretamente é o primeiro passo, não o último. Depois da definição vem a operação. Ela se apoia em quatro movimentos encadeados.

A detecção deve vir do monitoramento, não do usuário. Quando o chamado do cliente é a sua primeira fonte de informação, a operação já começou atrasada e o relógio do SLA corre há minutos.

O registro e a classificação vêm em seguida. Aqui a taxonomia deste artigo vira prática: tipo por origem, gravidade por impacto e urgência, além da separação clara entre incidente, requisição e problema.

A resposta segue um roteiro conhecido. Vale ter um plano de resposta a incidentes escrito antes da crise, porque ninguém desenha fluxo de acionamento com o sistema fora do ar.

Por fim, entra o encerramento com aprendizado. A resolução de incidentes só se completa quando o registro alimenta a base de conhecimento. Toda essa cadeia é o que a gestão de incidentes de TI organiza como prática contínua.

Conclusão

Um incidente de TI é a interrupção não planejada de um serviço ou a queda da sua qualidade acordada. Essa definição parece simples, no entanto ela sustenta decisões que valem contrato, orçamento e reputação. Sem ela, o SLA vira estimativa e a fila de chamados vira palpite.

Na prática, três disciplinas sustentam o resultado. A primeira é conceitual: separar incidente de problema, de evento e de requisição sem hesitar na triagem. A segunda é taxonômica: classificar por origem e por gravidade, com critério escrito. A terceira é técnica: detectar pelo monitoramento, antes que o usuário ligue.

Quem domina as três para de discutir se aquilo era ou não um incidente. Assim, a conversa muda de nível e passa a ser sobre reduzir volume, duração e recorrência.

Quer avaliar como sua operação detecta e classifica os incidentes hoje? Fale com um especialista da OpServices e entenda como estruturar essa camada.