A evolução das métricas de disponibilidade MTT: Da indústria à tecnologia da informação
Em Tecnologia da Informação (TI), um incidente é definido como qualquer evento não planejado que interrompe ou reduz a qualidade do serviço de TI. Pode ser uma interrupção completa do serviço, a degradação significativa da performance ou qualquer evento que cause impacto negativo nos usuários, nos processos ou nos sistemas de TI. Os incidentes podem ser causados por falhas técnicas, erros humanos, eventos externos, entre outros fatores.
Por outro lado, um incidente de negócio em Tecnologia da Informação refere-se a um incidente que tem um impacto direto nos processos de negócio de uma organização. É um incidente que afeta as operações e atividades críticas de negócio causando interrupções significativas ou prejuízos financeiros. Por exemplo, uma falha em um sistema de pagamento online de uma empresa de comércio eletrônico que resulta na impossibilidade de realizar transações e perda de vendas é considerado um incidente de negócio.
A distinção entre um incidente geral de TI e um incidente de negócio é importante porque nem todos os incidentes têm o mesmo impacto e prioridade. Incidentes de negócio tendem a receber atenção priorizada e sua rápida resolução é essencial para minimizar o tempo de inatividade, evitar prejuízos financeiros e manter a satisfação dos clientes.
É comum que as equipes de suporte de TI utilizem classificações de incidentes para categorizar e priorizar sua resolução. Essas classificações levam em consideração a gravidade do impacto nos negócios, a urgência e a prioridade para a organização. Isso permite que a equipe de suporte priorize adequadamente seus esforços e recursos para resolver os incidentes de negócio de maneira rápida e eficaz.
Na governança de TI, utilizamos as métricas conhecidas pela sigla em inglês MTT* (Mean Time to…), que em tradução literal é conhecido como Tempo Médio para Raparar, Identificar, Resolver, os incidentes em TI.
A coleta dessas métricas permite à uma empresa avaliar melhor a maturidade de seus processos e traz ideias de melhorias de processos e ferramentas.
Métricas MTT - Origens industriais: Eficiência operacional
O conceito de métricas baseadas em MTT começou a ser desenvolvido na indústria no início do século XX, em especial durante a Revolução Industrial. A expansão de fábricas e máquinas complexas trouxe a necessidade de medir e melhorar a confiabilidade e a eficiência operacional. A introdução de sistemas mecânicos e eletrônicos nas linhas de produção incentivou a criação de padrões para monitorar falhas e tempos de reparo.
Nos anos 1950 com o surgimento de técnicas de manutenção preditiva e preventiva, as métricas como MTBF (Mean Time Between Failures - Tempo Médio Entre Falhas) que mede o tempo médio entre falhas dos sistemas/componentes e MTTR (Mean Time to Repair - Tempo Médio Para Reparar) que mede o tempo médio de repação do ambiente, foram formalizadas em setores como o aeroespacial e o militar. Esses ambientes demandavam equipamentos confiáveis, e a análise de dados históricos sobre falhas ajudava a prever problemas e reduzir o tempo de inatividade.
Evolução no contexto tecnológico
Com o avanço da computação e da eletrônica a partir das décadas de 1970 e 1980, as métricas de disponibilidade começaram a migrar para sistemas digitais. A introdução de computadores pessoais, servidores e redes transformou as métricas industriais em ferramentas essenciais para a gestão de sistemas tecnológicos.
Durante essa transição, as métricas MTT foram adaptadas para incluir contextos específicos de TI:
- MTTF (Mean Time to Failure - Tempo Médio de Falha) foi aplicado para prever a vida útil de componentes de hardware ao medir o tempo médio de falha dos componentes;
- MTTR tornou-se central para medir a eficiência da equipe de suporte técnico em resolver problemas e restaurar serviços;
- MTBF foi incorporado como um indicador chave para medir a confiabilidade de sistemas críticos, como servidores e bancos de dados.
Os desafios na era digital
Com o advento da Internet, serviços baseados em nuvem e a demanda por disponibilidade contínua, as métricas MTT evoluíram novamente para atender as exigências de ambientes de alta complexidade. Na década de 2000, organizações começaram a adotar práticas como Site Reliability Engineering (SRE) e DevOps, que enfatizam a importância da automação e da visibilidade em tempo real sobre sistemas.
Nesse contexto, o uso de MTT se tornou central na medição de disponibilidade. Em sistemas modernos, o objetivo é não apenas reparar falhas, mas minimizar interrupções de serviço para o usuário final. Outras variantes dessas métricas também surgiram, como:
- MTTI (Mean Time to Identify - Tempo Médio para Identificar) que mede o tempo médio para identificar a causa de um problema;
- MTTA (Mean Time to Acknowledge - Tempo Médio para Reconhecer) que mede o tempo médio para reconhecer um incidente após a detecção.
Métricas MTT na prática atual
Atualmente empresas de tecnologia como Google, Amazon e Netflix utilizam métricas MTT em conjunto com outras abordagens analíticas para garantir a disponibilidade de serviços. Uma nova prática surgiu e é conhecida como AIOps e enfatiza a utilização de aprendizado de máquina para automatizar a detecção e correção de problemas, diminuindo consequentemente o MTTR dos incidentes, em conjunto com ferramentas avançadas de monitoramento e logging que permitem medições em tempo real.
Além disso a crescente ênfase na experiência do usuário levou à um novo paradigma: O tempo de reparo não é apenas uma métrica operacional, mas também uma medida do impacto na confiança do cliente e na reputação da marca.
Desafios das métricas MTT
A instituição VOID (Verica Open Incident Database) analisa uma extensa base de dados de incidentes de grandes organizações e anualmente publica um relatório detalhando importantes descobertas. No relatório de 2023 a instituição reforçou as conclusões dos relatórios dos anos anteriores e o cuidado da utilização da métrica MTTR como única fonte de análise e tomada de decisão. Se na base de incidentes não há uma distribuição normalizada dos dados então medidas de tendências centrais como média e mediana não representam seus dados de forma precisa. Então quando se pensa que com os dados estamos dizendo algo sobre a disponibilidade dos sistemas, na verdade estamos usando métricas não confiáveis.
Em outras palavras o relatório afirma que ao analisar uma base de MTTR, incidentes com o mesmo MTTR podem ter níveis diferentes de surpresas e incertezas em como o time conseguiu identificar a causa, e podem conter riscos distintos de tomadas de decisões de mitigação. Ou seja, trazem apenas dados técnicos e não complementam informações de usuários, pressões de negócio e de times financeiros.
O relatório propõe:
- Utilização de SLO e outras maneiras de medição de feedback do cliente;
- Tratar incidentes como oportunidades de aprendizado para as equipes;
- Favorecer análises aprofundadas;
- Tratar os membros dos times como a solução e não o problema (no blame culture).
E você como trabalha com os as métricas de disponibilidade em sua empresa?