Vamos falar um pouco melhor agora sobre as métricas de incidentes. Bom, as métricas de gerenciamento de incidentes são essenciais para avaliar e aprimorar continuamente a eficácia do processo. Elas oferecem insights valiosos sobre o impacto, tempo de resolução e frequências de diferentes tipos de incidentes, permitindo otimizar a resposta e garantir a disponibilidade contínua dos serviços críticos. Quais são as principais métricas? Time to Resolution, ou TTR, que é o tempo total necessário para resolver um problema ou incidente relatado, desde o momento em que é reportado até ser completamente resolvido. Man Time to Repair, ou MTTR. MTTR é o tempo médio necessário para reparar um sistema ou componente e restaurá-lo a condições operativas. Man-Time to Resolve, também MTTR, que é o tempo médio necessário para resolver completamente um incidente ou problema, incluindo o tempo de reparo, testes e retorno do serviço. Man-Time to Onology. Bom, o MTTA é o tempo médio que uma equipe leva para reconhecer que um incidente ocorreu após ter sido reportado. Número de incidentes por período de tempo. O número total de incidentes reportados dentro de um período específico, então, mês, semana, ou um call específico. E, por fim, o Man-Time Between Failures, o MTBF, que é o tempo médio entre falhas sucessivas de um sistema ou componente, certo? É medida a nível de confiabilidade. Bom, vamos analisar aqui um pouco melhor, em cima desse desenho, que eu acho que vai ficar um pouquinho mais fácil. Se a gente for pegar, tudo começa com o relato aqui do problema, então a gente tem aqui o nosso altage sendo iniciado. A partir desse momento, foi gerado aqui pela nossa monitoração uma alerta, então geralmente os alertas, eles têm um pooling ali, né? Então, ele vai bater no Sport, porque ele bateu aqui, ele viu que estava com um problema, e aí, X tempo depois, ele fez a mesma verificação, viu que continua com um problema, e aí sim é que esse alerta foi gerado, né? Então, a gente poderia dizer que esse cara aqui é nosso MTTA, por exemplo, o tempo que a gente levou para ter o conhecimento de que a gente está com um problema no ambiente. Aqui foi onde a gente iniciou o nosso reparo e aqui é quando ele volta a funcionar normalmente. Então, do tempo que a gente iniciou até o tempo de resolução e deixar o nosso sistema 100% funcional, a gente tem o nosso MTTR falando aqui de Man Time to Repair, certo? Quando a gente pega do tempo do incidente até, de fato, a gente resolver, a gente tem o Man Time to Respond, que também a gente poderia estar falando aqui como MTTR, certo? como MTTR, certo? E do tempo total, que seria desde quando de fato começou o problema até a gente resolver 100%, a gente tem o Man Time to Recover, certo? Aí beleza, vamos supor que a gente conseguiu deixar esse sistema funcional e em paralelo o time foi trabalhando aqui e a gente conseguiu encontrar, identificar um fix, né? Para que a gente cons feito essa correção, a gente tem o Man Time to Resolve, que é basicamente, a gente conseguiu botar ele no ar, trabalhou em paralelo, viu ali qual era o problema, trabalhou num fix e aplicou esse fix para esse sistema estar 100% protegido, vamos dizer assim, 100% confiável. E aí a gente tem, beleza, aqui está tudo funcionando bem, mas mais para frente a gente identificou uma nova falha, então não necessariamente a mesma falha que aconteceu que fez com que a gente gerasse esse fix, mas a gente teve uma falha novamente. Então, daí a gente está falando do MTTF, o tempo médio entre falhas aqui do nosso sistema. E por fim, a gente tem aqui também o Man-Time-To-Failure, que é o tempo médio para falhar, que seria a gente pegando desde o começo de quando a gente teve o primeiro problema, até quando a gente teve aqui também o nosso segundo problema.