Gestão de incidentes é um termo comumente utilizado por profissionais mesmo em práticas e áreas distintas. De modo geral, ele se refere às ações que visam prevenir, minimizar ou responder a incidentes e problemas relacionados às atividades de uma organização.
Há um longo histórico de desenvolvimento da gestão de incidentes como uma prática profissional, especialmente em áreas sensíveis, como segurança pública, saúde, indústria e alimentos. Assim, em áreas com maior profissionalização da gestão de incidentes, as práticas e as formas de atuação já são mais acessíveis e bem definidas.
Para a área de desenvolvimento de softwares e operações de TI, contudo, a gestão de incidentes possui um histórico relativamente recente. Naturalmente, isso faz com que mais desenvolvedores e gerentes de serviços e produtos digitais se preocupem com a melhoria da gestão de incidentes em DevOps.
Porém, em uma área com poucas referências, nem sempre é fácil encontrar informações que ajudem a aprimorar a gestão de incidentes e quais práticas devem ser adotadas.
Neste conteúdo, reunimos as informações mais importantes para entender e aplicar a gestão de incidentes em DevOps. Então, faça uma boa leitura e aproveite as dicas para o aprimoramento da gestão de incidentes no seu negócio e dos serviços prestados!
O que é a gestão de incidentes em DevOps?
Uma das formas de definir a gestão de incidentes é a associação com práticas que previnem e minimizam eventuais problemas. Em uma organização que lida, por exemplo, com alimentos, podem acontecer incidentes de contaminação, fornecimento de insumos, conservação e distribuição.
No entanto, em organizações que fornecem produtos e serviços digitais, os problemas são de natureza totalmente diferente. Ameaças de TI, ataques cibernéticos e violações de segurança são apenas alguns exemplos de preocupações comuns da gestão de incidentes em DevOps.
Desse modo, embora as etapas e os processos da gestão de incidentes em DevOps sejam, essencialmente, bastante similares à gestão de incidentes de outras áreas, a ênfase se dá em aspectos específicos do processo de gestão, como explicaremos no próximo tópico.
Quais são as etapas do processo de gestão de incidentes?
A gestão de incidentes na chamada “era do DevOps” se vale de princípios de comunicação aberta para que, por meio da transparência e da troca de informações, as equipes de operações e TI possam trabalhar juntas, garantindo maior assertividade e eficiência na reação aos incidentes enfrentados em sua rotina.
Espera-se que, seguindo as etapas a seguir, as equipes sejam capazes de aprender com os incidentes e com os erros cometidos, evitando que eles se repitam com frequência e que, quando forem inevitáveis, a reação seja cada vez mais ágil e eficiente.
1. Detecção
A proatividade na detecção de questões que possam causar problemas é a primeira etapa na cadeia que constitui a gestão de incidentes. Basicamente, não se deve aguardar passivamente que os problemas apareçam. Inevitavelmente eles vão acontecer e é melhor estar preparado de antemão.
Em arquiteturas de nuvem é raro que uma indisponibilidade ocorra de forma abrupta. Normalmente começa com uma degradação que torna os sistemas mais lentos. Eventualmente a degradação se transforma em uma indisponibilidade total.
O desafio de monitorar sistemas distribuídos em Cloud tornou-se tão grande que esta prática ganhou um nome próprio: Observabilidade. É um tema recorrente nosso e já cobrimos em outros artigos.
Uma das técnicas mais eficazes para identificar rapidamente uma degradação e prevenir uma indisponibilidade é analisar a latência (tempo de resposta) dos sistemas com curvas de Percentil, como podemos ver na figura a seguir, da plataforma da Elvenworks.
Nesta técnica, acompanhamos continuamente as curvas de Percentil 95, Percentil 90 e Percentil 50 da latência. O Percentil 50 pode ser considerado o comportamento típico percebido pela maioria dos usuários. O Percentil 95 e o Percentil 90 podem ser considerados os comportamentos percebidos pelos usuários “mais lentos”.
Quando as curvas do Percentil 95 e 90 começam a descolar da curva do Percentil 50, temos uma degradação e somos capazes de atuar sobre ela ainda com tempo para prevenir um impacto maior.
Quando ocorre essa detecção de problema, a equipe deve buscar identificar as possíveis causas-raiz e planejar as respostas imediatas que seriam mais adequadas para cada cenário. Na evolução ocorrerá o refinamento de ferramentas de monitoramento, sistemas de alerta e runbooks que facilitem as ações em resposta a quaisquer incidentes.
Uma das ferramentas mais interessantes para identificar causa-raiz de incidentes é a Matriz de Resiliência, que também já cobrimos em um outro artigo.
2. Resposta
A segunda etapa de reação aos incidentes é a resposta, que, basicamente, consiste na execução de ações já planejadas para um determinado cenário de problemas. Nessa fase, é necessário fazer uma avaliação de impacto e da gravidade do problema para definição das ações mais recomendadas.
Para minimizar ao máximo o tempo de espera para obtenção de respostas aos incidentes enfrentados em DevOps, assim como em outras áreas, é altamente indicado que as empresas mantenham equipes com escalas de plantão.
Dessa forma, independente do momento, sempre haverá um profissional para iniciar as atividades de resposta seguindo os protocolos previamente planejados ou para ao menos designar o problema a um respondente capacitado.
3. Resolução
A etapa de resolução é a mais objetiva, pois, quanto mais rápida a mobilização para responder a um incidente, mais rápida será a sua resolução. Por isso, é fundamental dar o devido valor às etapas anteriores, pois delas depende a eficiência da solução do problema.
Se a equipe contar com um bom sistema de comunicação e ferramentas de monitoramento, a tendência é que o tempo de espera para resolução de problemas comuns chegue o mais próximo possível de zero.
Contudo, é preciso ressaltar que não existe processo único e automatizado para resolver todo e qualquer problema. Dessa forma, o aperfeiçoamento da resolução sempre dependerá da continuidade das atividades de prevenção e monitoramento.
4. Análise
É perfeitamente normal que, na medida em que os sistemas crescem em complexidade, as falhas e incidentes também se tornem mais comuns e mais complexos. Mas isso não deve ser visto como um empecilho para a gestão de incidentes.
Todo problema enfrentado é também uma oportunidade para aprender e aprimorar os processos de gestão de incidentes. Por isso, esta etapa consiste em uma análise retrospectiva dos incidentes enfrentados, na qual a equipe se reúne para discutir informações e dados acerca de um problema ocorrido.
Assim, a análise contribui para o aperfeiçoamento das atividades preventivas de gestão de incidentes e para a sua profissionalização contínua, bem como para uma melhor capacidade de responder a problemas futuros, favorecendo a resiliência e estabilidade dos sistemas.
5. Preparação
Por fim, a etapa final do processo de gestão de incidentes nos leva de volta para o começo, pois a preparação consiste em avaliar como deve se dar a preparação para o próximo incidente.
Com as informações obtidas a partir da análise dos incidentes, devem ser atualizados protocolos de resposta, runbooks, ferramentas de monitoramento e sistemas de alerta, reiniciando o processo de gestão de incidentes desde sua etapa inicial.
Como garantir a eficácia das equipes de DevOps na gestão de incidentes?
Algumas práticas ajudam a garantir uma maior eficácia no trabalho das equipes de DevOps que cuidam da gestão de incidentes:
- Automatização dos processos e fluxos de trabalho: integra ferramentas de atendimento, monitoramento, chat e outras soluções que ajudam a simplificar os alertas de incidentes.
- Estreitamento da comunicação entre equipes: favorece uma comunicação mais transparente, garantindo que as pessoas certas sejam notificadas com as informações necessárias para dar início à resposta a um incidente.
- Uso de abordagens não repreensivas: evita que o constrangimento de membros da equipe atrapalhe o planejamento e desenvolvimento de soluções e respostas a possíveis incidentes futuros;
- Monitoramento de métricas de falha para gestão de incidentes: ajudam a entender a dimensão dos problemas e a embasar as discussões que levarão ao planejamento de respostas e soluções.
Como calcular as principais métricas de falha para gestão de incidentes?
As questões que envolvem métricas de falha para gestão de incidentes têm sido amplamente debatidas. Especialistas divergem argumentando que as métricas não são realmente úteis por não contemplarem as perguntas mais complicadas a respeito de COMO os incidentes são resolvidos, O QUE funciona (e o que não funciona), e, sobretudo, QUANDO os problemas escalam ou diminuem.
Mas é fato que métricas de incidentes como o MTTR (de Mean Time To Recovery), MTBF (Mean Time Between Failures), e MTTA (Mean Time to Acknowledge), juntas, podem dar uma boa dimensão dos problemas e direcionar respostas para as questões mais complexas que envolvem a verificação de integridade (health-checks) e a confiabilidade do sistema como um todo.
Como identificar cada métrica de falha?
Por serem várias siglas começando com “mean time” (tempo médio), e todas muito parecidas, a divergência já começa pelos nomes. MTTR, por exemplo, pode significar Mean Time To Recovery (ou Restore), Mean Time To Resolve (ou Repair) e Mean Time To Respond. Por isso seremos muito didáticos neste post, explicando uma a uma, começando pela mais popular de todas: o MTTR.
Mean Time To Recovery (MTTR)
Tempo médio de recuperação ou tempo médio de restauração (Mean Time to Recovery) é o intervalo de tempo gasto para se recuperar uma falha no sistema. O MTTR é calculado a partir da divisão do tempo total de inatividade durante um período específico pelo número de incidentes. Dessa forma, vamos supor que um sistema tenha ficado inativo por 1 hora em quatro incidentes ocorridos durante um período de 24 horas. Sendo assim, o MTTR seria de 15 minutos, ou 60 minutos (tempo total) por 4 (número de incidentes).
Essa é uma métrica de alto nível, boa para avaliar a existência de problemas e a velocidade do processo geral de recuperação.
Para tanto, você pode fazer algumas perguntas, como:
- Seu processo de recuperação é rápido o suficiente?
- Como ele se compara aos seus concorrentes?
- Existe atraso entre uma falha e um alerta?
- Os alertas estão demorando mais do que deveriam para chegar à pessoa certa?
- É possível descobrir rapidamente qual é o problema?
- Existem processos que poderiam ser melhorados?
- As equipes de manutenção são tão eficazes quanto poderiam ser?
- Se estão demorando demais, o que está atrapalhando o processo?
É preciso analisar muito além do Mean Time To Recovery para responder a todas essas perguntas. No entanto, essa métrica específica pode fornecer um ponto de partida valioso para diagnosticar se há algum problema com o processo de recuperação do sistema. O que nos leva a outros KPIs (indicadores-chave de desempenho) no processo de gerenciamento de incidentes, como o Mean Time to Resolve, sobre o qual falaremos a seguir.
Mean Time To Resolve ou Repair (MTTR)
Tempo médio para resolver ou tempo médio para reparar (Mean Time To Resolve) se refere à soma do tempo gasto para detectar a falha, diagnosticar o problema, repará-lo e também para garantir que a mesma falha não aconteça novamente.
Essa é considerada uma métrica associada à satisfação do cliente, usada em um cenário de incidentes não planejados. O MTTR oferece uma visão ampla para consertar e resolver incidentes, pois vai além do tempo de inatividade do sistema (downtime) e inclui o trabalho posterior. Este KPI também evita que incidentes semelhantes ocorram no futuro.
Para calcular o Mean Time To Resolve, some o tempo de resolução total e divida pelo número de incidentes, como na fórmula abaixo:
MTTR = Soma de todos os tempos para resolver o incidente / Número de incidentes
Mean Time To Respond (MTTR)
O tempo médio de resposta corresponde ao período entre o primeiro alerta e a resolução de um incidente. A métrica do MTTR costuma ser aplicada para medir o sucesso de uma equipe de segurança cibernética na neutralização de ataques ao sistema. Também ajuda a visualizar quanto tempo se resume aos sistemas de alerta e quanto corresponde ao trabalho real da equipe de segurança.
O Mean Time To Respond é calculado a partir da soma de todos os alertas de tempo de resposta com a divisão pelo número de incidentes:
MTTR = Soma de todos os períodos de resposta / Número de incidentes
Mean Time Between Failures (MTBF)
O tempo médio entre falhas (MTBF) é uma métrica para falhas em sistemas reparáveis, usada para rastrear a disponibilidade e a confiabilidade de um produto. O termo tem origem na indústria da aviação, onde as falhas de sistema significam consequências decisivas, não apenas em termos de custo, mas também em vidas humanas.
A métrica é útil para compradores que desejam ter a certeza de obter o produto mais confiável, viajar no avião mais seguro ou mesmo escolher o equipamento de fabricação mais seguro para uma fábrica. Quanto maior for o tempo entre as falhas, mais confiável é o sistema.
Calcular o MTBF também é simples. Primeiro, tomamos o número total de horas operacionais de determinado ativo durante um período específico. Em seguida, dividimos esse número pelo número de falhas que ocorreram ao longo do mesmo período de tempo, como na fórmula abaixo:
MTBF = Número de horas de tempo operacional / Número total de falhas
A disponibilidade, também conhecida como tempo de atividade (uptime), é um dos principais indicadores da eficácia geral de um equipamento. O tempo de atividade total pode ser expresso em termos de MTBF, juntamente com outra métrica que descrevemos acima, o MTTR (Mean Time to Repair).
Mean Time to Acknowledge (MTTA)
O MTTA (tempo médio para reconhecimento) mede quanto tempo leva para uma empresa responder, em média, a interrupções ou incidentes em todo o sistema de operações. Além disso, essa métrica é útil para rastrear a capacidade de resposta da equipe e também a eficácia do sistema de alerta.
Para calcular o MTTA, basta dividir o tempo total gasto para reconhecer todos os incidentes pelo número de incidentes em um determinado período.
Essa métrica rastreia a etapa mais importante para resolver os problemas ― reconhecer o fato de que algo deu errado e garantir ao cliente que o problema está sendo resolvido. Também mostra como a organização é responsiva aos problemas à medida que eles acontecem.
Para reduzir o MTTA, é preciso primeiro rastreá-lo.. A equipe está sofrendo de “fadiga de alerta” e demorando muito tempo para responder? É o momento em que essa métrica ajudará a sinalizar o problema.
No vídeo abaixo, nosso CEO Bruno Pereira usa uma analogia simples para explicar as métricas MTTA, MTTR e MTBF. Todos esses indicadores estão presentes na nossa plataforma de monitoramento One Platform!