Principais KPIs para Gestão de Incidentes
Em um mundo onde as experiências digitais são uma prioridade, um sistema sólido e bem pensado em monitoramento e na gestão de incidentes pode fazer a diferença entre um negócio próspero e receita perdida.
Sabemos que o ideal (e utópico) é não acontecerem incidentes e que o sistema esteja pronto pra catástrofes. Mas na vida real é diferente.
Incidentes ocorrem constantemente em sistemas e infraestruturas de tecnologia e, se os indicadores corretos não estiverem sendo monitorados corretamente, esses incidentes podem levar a problemas maiores, como tempo de inatividade não planejado do sistema, comprometimento da experiência do cliente e, por fim, perda de dinheiro.
Quando isso acontecer, reagir e resolver rapidamente o problema ajudará a tornar o seu sistema ainda mais confiável. O monitoramento dos KPIs mais importantes de seus negócios pode ajudar a criar sistemas de gerenciamento de incidentes mais eficientes, reduzir o número total de incidentes em seu sistema e criar um serviço ainda mais confiável para seus clientes. No entanto, saber quais KPIs você deve ficar de olho — e quais são mais relevantes pro seu time — pode ser outro desafio.
KPI (Key Performance Indicator ou, em português, Indicador Chave de Performance) é basicamente uma informação sucinta, clara e relevante que fornece uma visão ampliada e determinística sobre metas e definição de sucesso da sua empresa, área, produto e/ou software.
O termo é mais utilizado para definições de negócio do que técnicas e acabamos nos apegando mais à terminologia dos OKRs do que dos KPIs. No fundo, ambos são bem similares, tem objetivo e uma forma de validar, algum número associado a ele, porém metas de KPI representam o desempenho de um processo ou projeto já em vigor, enquanto as metas do OKR são um pouco mais desafiadoras e ambiciosas.
Mas, independente de como vai chamar e utilizar, vamos falar um pouco mais sobre os principais indicadores em relação ao gerenciamento de incidentes e como eles podem ajudar a melhorar significativamente o seu processo de gerenciamento de incidentes.
# Incidents Over Time
- Incidentes ao longo do tempo
- O que significa: O número médio de incidentes durante um período de tempo especificado (por exemplo semanal, mensal, trimestral, anual etc);
- O que ele pode mostrar: Rastrear o número de incidentes ao longo do tempo pode ajudar a revelar tendências à frequência, bem como problemas no processo de desenvolvimento de software, teste, implantação e fornecedores;
# Mean Time to Detect (MTTD)
- Tempo médio para detectar
- O que significa: O tempo médio entre o problema de fato e a sua detecção (normalmente automatizada);
- O que pode mostrar: O MTTD pode mostrar com que rapidez e eficácia sua monitoria consegue perceber que um problema está acontecendo ou está para acontecer, inclusive antes mesmo do incidente de fato;
# Mean Time to Acknowledge (MTTA)
- Tempo médio para atuar
- O que significa: O tempo médio entre um alerta do sistema e um membro da equipe reconhecer e atuar no problema;
- O que pode mostrar: O MTTA pode mostrar com que rapidez e eficácia seu time está lidando e respondendo aos alertas de sistema e iniciando de fato a mitigação e correção;
# Mean Time to Repair (MTTR)
- Tempo médio para resolução
- O que significa: O tempo médio gasto desde que o problema ocorreu até a restauração dos serviços;
- O que ele pode mostrar: o MTTR pode mostrar a rapidez e eficácia com que sua equipe é capaz de resolver problemas e restabelecer os serviços em si conforme eles surgem;
# Mean Time to Failure (MTTF)
- Tempo médio para a falha
- O que significa: O tempo médio em que o sistema fica “up” e funcional antes de uma nova falha;
- O que ele pode mostrar: O MTTF pode indicar recorrência em determinados problemas, falhas de priorização pelo time e atuação em backlog técnico bem como ser um fator determinístico para a qualidade do software produzido;
MTTD, MTTA, MTTR e MTTF podem ter abordagens um pouco diferente de acordo com a interpretação e qual é a literatura base. Abaixo colocarei alguns imagens exemplificando o fluxo de companhias como Atlassian e Splunk:
# Service Level Agreement (SLA)
- Acordo de nível de serviço
- O que significa: Nível da qualidade do serviço em contrato;
- O que pode mostrar: O SLA descreve o acordo entre você (o provedor) e seus clientes em relação a métricas como Uptime e Response Time. Deve-se sempre estar em uma faixa saudável acima para evitar problemas contratuais; Monitorar esse indicador é monitorar se você cumpre o que promete. Apesar de chamarmos de SLA, o que acompanhamos é o SLI e onde ‘miramos’ é no SLO;
- Service Level Agreement (SLA) é o acordo do nível de serviço em contrato com o cliente. Um exemplo seria vender um serviço e dizer que o uptime dele será >99,95%. Normalmente, caso não cumprido, o cliente fica protegido por alguma cláusula;
- Service Level Indicator (SLI) é o indicador de nível de serviço, que é o aferimento do valor real executado em um período específico. Por exemplo, no último mês tivemos um uptime de 99,789%;
- Service Level Objective (SLO) é o objetivo do nível de serviço, ou seja, temos um número “minimo” garantido pro cliente em contrato (SLA), um número real (SLI) e onde desejamos estar (SLO). Um exemplo seria almejar ter no próximo mês um SLI >99,99%
# Application Performance Index (Apdex)
- Índice de performance da aplicação
- O que significa: Nível de satisfação do “cliente” considerando taxa de sucesso, tolerância e falha baseado em métricas das respostas;
- O que pode mostrar: Esse indicador imprime a experiência final do cliente com o seu serviço — Sessões frustradas, status code, tempo de resposta elevado etc. Serve como um termômetro principalmente para a identificação de anomalias e validação de novas implementações;
O cálculo do Apdex pode ser feito da seguinte maneira para um serviço Web:
Onde T seria o tempo de resposta da aplicação. Porém, outros fatores também são considerados para esse cálculo. Um Apdex com T = 1 segundo terá uma requisição de 0,5 spontuando como frustrado caso o seu status code seja 4XX ou 5XX;
Outro exemplo prático para T = 0,5 s e
- Satisfeitas: 50 requisições
≤ 0,5 s; - Toleradas: 32 requisições
>0,5 se≤2,0 s; - Frustradas: 18 requisilções, sendo: 8 requisições
>2,0 se 10 com status code500; - Total = Satisfeitas + Toleradas + Frustradas
- Apdex = (Satisfeitas + Toleradas/2) / Total
- Apdex = (50 + 32/2) / 100
- Apdex = (50 + 16) / 100
- Apdex = 66 / 100
- Apdex = 0,66 ou 66%
# Uptime
- Tempo de atividade
- O que significa: O tempo (fração) que os serviços estão funcionando corretamente dado uma janela de tempo;
- O que pode mostrar: Essa métrica é bastante direta, mostrando o quão disponível é o seu serviço. Quanto mais próximo de 100%, mais disponibilidade é oferecida aos seus clientes. O tempo de atividade de 99,9% é considerado muito bom pelos padrões da indústria, enquanto 99,99% é considerado excelente. Embora a perfeição seja quase impossível, o objetivo deve ser sempre manter esse número o mais alto possível;
Olhar para o processo e seus indicadores é muito importante para entender se nosso software realmente está satisfazendo o nosso cliente e entender se quando enfrentamos um problema somos verdadeiramente eficientes em identificar, corrigir e garantir que não a falha não ocorra novamente.
