Gestão de problemas e incidentes: qual o objetivo e como fazer?
Quando a infraestrutura ou os sistemas falham ou travam inesperadamente, o tempo de inatividade de TI pode ter um impacto direto nos resultados financeiros e nas operações de negócio.
De acordo com o Gartner, o custo médio do tempo de inatividade de TI pode chegar a US $5.600 por minuto em operações complexas onde a TI é extremamente crítica (ex: operadoras de cartão, e-commerce, redes sociais, etc).
Embora a prática de gestão de incidentes contribua para uma resposta rápida e eficiente às falhas de TI, é no gerenciamento de problema que existe uma oportunidade de reduzir significativamente a recorrência de incidentes ou até mesmo evitar que eles aconteçam.
Se quiser conhecer mais sobre essa prática e descobrir o quanto ela pode transformar os resultados das operações de TI, continue lendo este artigo.
O que é gerenciamento de problemas?
O gerenciamento de problemas (também conhecido como gestão de problemas) é uma das 34 práticas descritas pelo ITIL e consiste em uma abordagem sistemática para identificar a causa de incidentes de TI atuais ou potenciais.
Em resumo, o objetivo é eliminar a causa raiz e evitar que o problema se repita. E caso isso seja inevitável, ao menos minimizar o seu impacto.
É importante entender que os problemas causam incidentes, e não o contrário. Os incidentes nada mais são do que a pior consequência possível de problemas que não foram resolvidos em tempo hábil.
A prática de gerenciamento de problemas é sempre reativa aos problemas: não os previne
de ocorrer pela primeira vez.
A distinção proativo/reativo refere-se a como a investigação do problema se relaciona com os incidentes:
A gestão proativa de problemas ajuda a evitar que incidentes ocorram na primeira vez
A gestão reativa de problemas ajuda a evitar a recorrência de incidentes e pode ajudar a resolver incidentes abertos.
Qual é o objetivo da prática de gerenciamento de problemas?
O objetivo principal do gerenciamento de problemas é reduzir a probabilidade e o impacto dos incidentes, identificando as causas reais e potenciais dos incidentes, gerenciando soluções alternativas e erros conhecidos.
É importante assumir a premissa de que nenhum serviço é perfeito.
Todo serviço tem erros ou falhas que podem causar incidentes. E estas falhas ou erros podem ter origens das mais variadas possíveis.
Por exemplo, um erro em um contrato de terceiros tem tanta probabilidade de causar um incidente quanto a de um dispositivo de rede.
Muitos erros são identificados antes de um serviço entrar em operação e são resolvidos durante o design, desenvolvimento ou teste. No entanto, alguns permanecerão desconhecidos e seguirão até o ambiente de produção, podendo causar incidentes que serão percebidos pelos usuários e clientes de um serviço.
Portanto, em última instância, a prática de gestão de problemas visa identificar e analisar erros nos produtos da organização, a fim de minimizar seus impactos negativos nos serviços prestados.
Qual a diferença entre gestão de incidentes e gestão de problemas?
Não dá pra seguirmos adiante neste texto antes de assegurar o seu entendimento sobre estes dois conceitos: problemas e incidentes.
Para explicar a diferença entre estes dois, destaco abaixo um trecho do meu livro ITIL® na Prática: Gerenciando Problemas de Infraestrutura e Serviços de TI.
Para entender melhor o contexto do Gerenciamento de Problemas, vamos refletir sobre uma situação bem cotidiana:
Quando contraímos uma gripe, um resfriado ou alguma outra doença mais séria, nós sofremos reações, como tosse, febre, vômito, dores de cabeça, etc.
São sintomas que apresentamos quando nosso organismo não está funcionando como deveria, e que podem prejudicar a nossa saúde e as nossas atividades rotineiras de alguma forma.
De acordo com a frequência e a gravidade dos sintomas, muitas vezes é necessário buscar a sua causa, para assim poder combater a origem, evitar a recorrência ou consequências mais graves. Nestes casos, normalmente procuramos um médico especialista e somos submetidos a uma série de exames e diagnósticos.
Quando finalmente a causa do(s) sintoma(s) é identificada, temos duas possibilidades:
Tratar a causa de forma definitiva (antibiótico, cirurgia, etc.);
Quando o tratamento definitivo da causa não é possível, como uma doença sem cura, ou mesmo quando o tratamento não seja viável, os sintomas podem ser aliviados ou controlados através de soluções temporárias (medicamentos, terapia, etc.) que são indicadas pelo médico especialista.
No contexto dos Serviços de TI também funciona assim.
A diferença é que os sintomas são as falhas que ocorrem na operação normal de um serviço de TI (ex.: uma aplicação apresentando erro, internet lenta, um e-mail que não sai da caixa de saída).
Com isso, podemos chegar ao consenso de que um incidente nada mais é do que um sintoma. E à causa não identificada de um ou vários incidentes (sintomas, falhas), dá- se o nome de ‘Problema’.
Veja na tabela abaixo as principais diferenças entre a gestão de incidentes e a gestão de problemas.
Gestão de IncidentesGestão de ProblemasObjetivoResolver os incidentes para restabelecer a operação normal do serviçoEncontrar a causa raiz dos incidentes para evitar que ocorram novamenteFocoCurtíssimo prazo - Resolver imediatamente o incidenteMédio-longo prazo - investigar, analisar e encontrar uma correção para a causa raiz do problemaExemploServidor travado - Corrigir o erro de configuração e reiniciar o servidorServidor travado - Corrigir as falhas do sistema ou do processo que causaram o erro de configuraçãoReincidências Seguir a modelos de incidentes para responder a incidentes repetidos de forma consistenteAnalisar tendências e padrões em incidentes repetidos para impedir que eles ocorram novamente
Quais são os benefícios da gestão de problemas?
Uma gestão de problemas, quando bem executada, pode trazer uma série de benefícios - inclusive financeiros - para a empresa.
Otimização do tempo
Uma das principais contribuições da prática de gestão de problemas é o mapeamento dos erros conhecidos e a documentação das soluções de contorno. O que consequentemente reduz o tempo de resposta aos incidentes.
Um erro conhecido se trata de um problema que foi analisado e, embora ainda não resolvido, já possui uma solução de contorno.
Uma solução de contorno reduz ou elimina o impacto de um incidente ou problema para o qual uma resolução completa ainda não esteja disponível. Algumas soluções de contorno também podem reduzir a probabilidade de incidentes.
Redução de custos
A base de erros conhecidos e as soluções de contorno também favorecem a redução de custos, uma vez que a atuação de equipes especializadas se tornam cada vez menos necessárias em casos já conhecidos e mapeados anteriormente.
Produtividade
Ao endereçar os problemas e evitar todo o retrabalho em torno das reincidências, a produtividade das equipes de TI aumenta. Isso permite que possam se dedicar mais aos projetos e inovações.
Uma vez que os serviços estejam com estabilidade e disponíveis, isso também favorece a produtividade de clientes e usuários do serviço, que muitas vezes são os próprios colaboradores da empresa.
Colaboração
A gestão de problemas envolve interação entre equipes multidisciplinares e investigação profunda da causa dos problemas. Por conta disso, uma cultura forte de colaboração e blameless é extremamente importante para que as equipes se sintam confortáveis para atuarem nos problemas.
Melhoria contínua do serviço
A gestão de problemas contribui para a melhoria contínua dos serviços, podendo ir além do tratamento de problemas de infraestrutura. Isso é especialmente possível quando a gestão de problemas é incorporada como uma competência e não como uma área especializada dentro da empresa.
Por exemplo, se uma organização decide tratar cada não conformidade de seu sistema de gestão como um problema, terá segurança de que o processo de tratamento das não conformidades passará por atividades criteriosas de diagnóstico e investigação da causa raiz, trazendo mais eficiência para as atividades de melhoria contínua.
Satisfação do cliente
Sabemos que a percepção de valor e a satisfação do cliente são influenciadas pela experiência como um todo e não somente por indicadores mais tácitos, como disponibilidade de serviços.
Mas certamente a satisfação dos clientes e a confiança na TI será positivamente influenciada se houver menos incidentes.
O processo de gerenciamento de problemas
Existe um conjunto de atividades e abordagens que favorecem os resultados esperados pela prática do gerenciamento de problemas. A seguir você irá conhecer a anatomia de um bom processo para gerenciar problemas.
Abordagem proativa vs reativa
Existem duas abordagens para a gestão de problemas:
Gestão de Problemas reativa: Analisa incidentes que já acontecem, ajudando a resolvê-los e evitando que voltem a ocorrer
Gestão de Problemas proativa: Previne a ocorrência de incidentes pela primeira vez descobrindo desvios no desempenho dos serviços pelos alertas da infraestrutura de monitoramento, vulnerabilidades e bugs relatados por fornecedores, resultados de auditorias, etc.
De forma mais prática, a abordagem reativa espera por um problema e depois o corrige. Normalmente essa manifestação acontece por meio de um incidente. Imagine, por exemplo, a instalação de um alarme contra roubo após uma casa ser roubada.
Por outro lado, a abordagem proativa identifica estratégias para evitar a ocorrência de problemas. É como instalar uma segurança doméstica inteligente antes que o roubo (incidente) ocorra.
Na tabela abaixo há um resumo das diferenças:
Gestão de problemas reativaGestão de problemas proativaAbordagemResolver problemas que causam incidentesTomar medidas para prevenir futuros problemas (e seus incidentes resultantes)ObjetivoReduzir a frequência e a repetição de incidentesAssegurar a melhoria contínua de todo o sistemaDesencadeadorIncidentes existentesRiscos potenciaisImplementaçãoAnalisar a causa por trás de um incidente, e corrigirAnalisar futuros riscos e implementar medidas proativamente
Atividades da gestão de problemas
As principais atividades envolvidas na gestão de problemas são descritas a seguir.
1. Identificação do problema
Dependendo da abordagem utilizada (proativa, reativa, ou ambas) um problema pode ser identificado a partir da seguintes fontes:
Informações sobre incidentes em andamento
Registros e relatórios de incidentes
Dados de monitoramento
Dados de configuração do serviço
Vulnerabilidades notificadas por fornecedores
Descoberta de erros no ambiente de produção por parte de desenvolvedores, designers ou testers
experiências compartilhadas por usuários e comunidades especializadas
eventos da monitoração da infraestrutura, descobrir desvios no desempenho dos sistemas que ainda não se qualificam como incidentes
auditorias técnicas e outras avaliações.
2. Registro, priorização e atribuição do problema
Uma vez identificado, o problema deve ser registrado, priorizado é atribuído.
A categorização inicial de um problema geralmente inclui algumas das seguintes informações (se conhecidas ou razoavelmente presumidas) :
Descrição
Incidentes associados e suas soluções
Itens de configurações e/ou classes de Itens de Configurações associados
Impacto estimado e probabilidade de incidentes futuros
Serviços associados e potencialmente afetados
Impacto na organização e nos clientes
Impacto estimado e probabilidade de incidente
Cada organização define a forma que irá priorizar os problemas. Mas é recomendável seguir algumas diretrizes, como:
Priorizar apenas apenas quando há um conflito de recursos
Considerar a possibilidade dos problemas serem planejados usando um único backlog, juntamente com outras tarefas (planejadas e não planejadas).
Se um problema for tratado por várias equipes, ele será priorizado dentro de cada equipe, dependendo da disponibilidade de recursos, tempo de conclusão desejado e tempo de processamento estimado.
Ferramentas de visualização, como Kanban, e princípios Lean, como a limitação do trabalho em andamento, são úteis para uma priorização eficaz.
3. Investigação e determinação da causa raiz
A análise de causa raiz não deve se limitar ao item de configuração, mas incluir todas as dimensões, como comportamento do usuário, erros humanos, etc.
Várias técnicas de determinação de problemas podem ser empregadas nesta etapa. A tabela a seguir apresenta algumas delas e em quais situações são mais aplicáveis.
SituaçãoAbordagens e técnicas sugeridasProblemas complexos onde uma sequência de eventos deve ser elaborada para determinar exatamente o que ocorreu
Análise cronológica
Posto de observação técnica
Incerteza sobre quais problemas devem ser endereçados primeiro
Análise de valor de impacto
Brainstorming
Incerteza se a causa raiz apresentada é, de fato, a causa raiz
5 Por quês
Teste de hipóteses
Problemas intermitentes que não podem ser recriados ou repetidos em um ambiente de teste
Posto de observação técnica
Kepner-Tregoe
Diagrama de Ishikawa
Brainstorming
Incerteza sobre onde começar para problemas que aparentam ter múltiplas causas
Análise de Pareto
Kepner-Tregoe
Diagrama de Ishikawa
Brainstorming
Buscando identificar o exato ponto de falha para um problema
Diagrama de Ishikawa
Kepner-Tregoe
Mapa de afinidade
Brainstorming
Incerteza por onde começar na tentativa de encontrar a causa raiz
5 Por quês
Kepner-Tregoe
Brainstorming
Mapa de afinidade
4. Desenvolvimento de um plano de resolução
Quando um problema é analisado (ou seja, os erros nos produtos foram localizados e seu impacto nos serviços foi avaliado), ele assume um status de erro conhecido.
Soluções definitivas para problemas podem desencadear a necessidade de projetos. Algumas soluções corrigem erros, mas outras podem introduzir soluções de contorno.
As soluções de contorno são procedimentos que não corrigem a raiz do problema, mas podem reduzir a probabilidade dos incidentes resultantes do problema ocorrerem. Além disso, as soluções de contorno também podem ajudar a resolver os incidentes mais rápido e melhor quando eles ocorrem.
De toda forma, soluções de contorno que se tornam definitivas devem ser evitadas sempre que possível.
Muitos erros conhecidos permanecem abertos por muito tempo se não puderem ser resolvidos com eficiência e continuam afetando os serviços. Nesses casos, a organização pode se concentrar em maximizar a eficácia e a eficiência do tratamento de incidentes (às vezes até o nível de detecção e resolução totalmente automatizadas), mas os registros de problemas devem permanecer abertos e revisados periodicamente.
5. Resolver e encerrar
Os registros de problemas podem ser fechados somente se uma das seguintes condições for atendida:
O problema é resolvido: o risco de incidentes associados ao problema é removido ou reduzido a um nível aceitável.
O problema não afeta mais a organização.
Por onde começar o gerenciamento de problemas?
Uma das perguntas mais frequentes sobre a gestão de problemas é: por onde começar?
Não há respostas certas a respeito disso. Em geral, organizações que nunca fizeram gestão de problemas provavelmente irão iniciar por uma abordagem reativa, mirando em incidentes críticos e reincidentes.
A partir do momento em que a gestão de problemas vai sendo incorporada no dia-a-dia das equipes, é possível iniciar abordagens proativas, olhando para dados de monitoramento ou até mesmo ampliando o escopo para questões dos serviços como um todo e mais próximas do negócio
Quais são os fatores de sucesso do gerenciamento de problemas e como mensurar?
A prática de gestão de problemas deve se preocupar com os seguintes fatores de sucesso
Identificar e compreender os problemas e seu impacto nos serviços
As organizações devem entender os erros em seus produtos, pois podem causar incidentes e afetar a qualidade do serviço e a satisfação do cliente. A prática de gestão de problemas garante a identificação de problemas e, assim, contribui para a melhoria contínua de produtos e serviços. Isso é mais eficaz se executado de forma proativa em vez de reativa.
As métricas-chave para mensurar este fator de sucesso são:
Número dos problemas identificados ao longo do período
Número de incidentes que não estão associados a erros conhecidos
Número de incidentes que exigem investigação urgente de problemas
Otimizar a resolução e mitigação de problemas
Quando os problemas são identificados, eles devem ser tratados de forma eficaz e eficiente. Raramente é possível corrigir (remover) todos os problemas nos produtos e serviços de uma organização, mas a identificação sem resolução é significativamente menos valiosa para a organização e seus clientes.
Deve ser definida uma abordagem equilibrada para a mitigação de problemas, que considere os custos associados, riscos e impactos na qualidade do serviço.
As métricas-chave para mensurar este fator de sucesso são:
Número de incidentes evitados pela resolução de problemas
Número de incidentes resolvidos com soluções fornecidas pela investigação de problemas
Número de erros conhecidos que permanecem abertos
A atuação da TI na gestão de problemas
Não há prescrição sobre como a TI deve se organizar para fazer a gestão de problemas.
Em geral, há dois papéis específicos desta prática que podem ser encontrados nas organizações: gerente de problemas e coordenador de problemas.
Esses papéis são frequentemente introduzidos em organizações onde o número de problemas é alto. Em outras organizações, as atividades de gestão de problemas são coordenadas por uma pessoa ou equipe responsável pelos itens de configuração, serviço ou produto ao qual o problema está associado. Pode ser o proprietário do recurso, proprietário do serviço ou proprietário do produto, respectivamente.
Conclusão
Problemas e seus incidentes resultantes podem causar uma enorme pressão sobre as organizações de TI e as empresas. O uso da prática de gestão de problemas oferece uma abordagem estruturada para reduzir esses problemas.
Se você implementar abordagens reativas e proativas, estará sempre um passo à frente dos problemas. E esse é o único caminho para evitar uma TI cujo trabalho é apenas enxugar gelo.