Vamos lá galera, a gente acabou de falar bastante sobre dashboards, mas nem só de dashboard visualmente. Brincadeiras à parte, mas quando a gente está falando de dashboard, ele é muito importante para você fazer análises preditivas, para você conseguir se preparar para um possível problema que pode acontecer, ou até para tomar alguma decisão estratégica para melhorar sua aplicação, seu negócio e assim por diante. Então a gente abordou bastante sobre os dashboards. Os dashboards são extremamente importantes no nosso dia a dia. Mas os dashboards não vão resolver tudo. Vamos ser bem honestos? Você não vai acordar, abrir seu dashboard e ficar com ele aberto o dia inteiro. E por mais que você seja essa pessoa, caso você queira acordar e ficar com o dashboard aberto ali o dia inteiro, uma hora você vai dormir. E aí? Quem vai estar olhando como as coisas estão acontecendo no seu sistema? Como que você vai estar atento às mudanças que estão acontecendo ou que podem impactar o seu cliente, impactar o seu negócio? Não tem como você fazer isso só com dashboard. Os dashboards são bons para quando você está ali presente, analisando e prestando atenção neles. Mas o nosso dia a dia é cheio de coisa, cheio de coisa para resolver, você tem que ter a sua vida também, você tem que ter o seu dia a dia ali e o seu time inteiro preparado para atuar caso aconteça algum problema. E como é que você vai saber que tem um problema? Você precisa que alguém te conte. Então os alertas eles vêm para te ajudar nisso. Então a gente não pode contar só com dashboard, a gente tem que ter alertas estruturados para a gente conseguir saber se está tudo bem, para a gente conseguir ser acionado o mais rápido possível em caso de algum tipo de problema ou em caso de algum tipo de desvio de comportamento que a gente pode prever para conseguir atuar caso aconteça alguma coisa. Então quando a gente está falando de alerta, vamos definir aqui rapidamente. Aqui a definição e a configuração dos alertas, eles vão ser componentes essenciais para uma estratégia de observabilidade eficaz. Por quê? Se você pensar em observabilidade onde você tem só dashboard, você não está tendo formas de se acionar caso algo saia do controle. Aquilo que eu acabei de falar para vocês, você vão permitir que a equipe de TI e desenvolvimento, eles respondam rapidamente aos problemas e vão minimizar impactos em usuários e garantir a continuidade dos negócios. Tem uma métrica que eu já falei com vocês, chama MTTR, Mean Time to Repair. É muito falada num livro que chama Accelerate. Eu vou aqui dar dica para todos vocês lerem esse livro livro esse livro é denso, é o livro mais chatinho ele é bem sobre processo então quando você for ler, você vai ver que ele é um livro meio chato de ler mas eu dou a dica aqui de ler, porque ele fala sobre vários indicadores, é como se fosse uma tese de mestrado ali de doutorado e etc, que fala sobre vários indicadores que mostram como esses indicadores de tecnologia conseguem mostrar que uma empresa é boa ou ruim, ou seja, quanto que ela está conseguindo ter de impacto no mercado com base nos seus indicadores. Eles categorizam lá esses indicadores em alguns grupos até você chegar à elite. Então, quando você busca um indicador elite, significa que você está buscando que a sua empresa seja acima das demais e que você consiga responder rápido a tudo e quanto é tipo de situação. E dentro desses indicadores tem um cara que chama MTR, é o Main Time to Repair. Esse cara, ele vai falar sobre o tempo que você demora pra descobrir um problema e resolver esse problema. Então, quanto tempo fica um problema em produção, um problema impactando o seu cliente? Quando a gente está falando de alertas de tecnologia, isso é extremamente importante. Mas os alertas não são só para isso, não são só para falar sobre interrupção do sistema. Você também vai ter alertas de negócio, caso aconteça alguma coisa muito maluca. Sei lá, o seu concorrente acabou de fazer alguma oferta extremamente maluca, você começou a perder vendas monte, monte, arrudo, não está conseguindo mais competir com ele. É importante você ter esse tipo de alerta. E outros tantos, ou seja, começou a cair o número de usuários entrando na sua página, você precisa ter usuários entrando para conseguir vender. Também é importante você ter alerta. Bom, entenderam já, né? Quando a gente está falando de alerta, é super importante ter esse carinha aqui configurado para ajudar a gente no dia a dia. E vamos falar um pouquinho aqui do que são alertas no fim do dia, tá? Pra quem não tá tão acostumado. Alertas são ali as notificações automáticas que vão informar as equipes sobre condições anômalas ou problemas em sistema de TI. Qual que é a grande sacada aqui? Você precisa ter uma coisa que chama previsibilidade. Como que você vai falar que uma coisa é anômala? Olha que palavra bonita. Como que ela vai ser uma coisa que não é normal, tá? É uma coisa diferente do normal se você não sabe o que é o normal. Pra você saber o que é o normal, você tem que conseguir traçar um paralelo do que você entende como continuidade do sistema, que você entende como um ambiente que é comum, que tem certa previsibilidade. Ou seja, se você tem por exemplo, 10% de usuários a mais entrando na sua página todo dia no dia que entrar zero usuários, você sabe que você tem um problema porque você tem uma projeção do que você espera, quando você fala que a sua CPU, por exemplo, ela tem que estar ali batendo até 40% de CPU normalmente, quando você olha com base em histórico e com base no que você tem para processar para frente, você entende que até 40 está tudo bem. Aí bateu 50, você fala, putz, temos um problema, está vendo? Você conseguiu pensar nessa visão futura do que pode acontecer. E quando a gente vai falar de alerta, são esses gatilhos automáticos que eles vão avisar a gente quando tem alguma coisa que não é muito dentro do comum, uma coisa que a gente não previu. Então é super importante você primeiro entender quais são as métricas, quais são as coisas que você vai medir e o que você vai considerar como comum para você também não sair gerando alertas de mais nem alertas de menos, beleza? Eles vão ser ali configurados para acionar quando alguma métrica ultrapassar um limite definido. E esse limite definido é a cereja do bolo, é o segredo da coisa. Você tem que saber definir esse limite e afinar ele conforme o tempo for passando. Vai permitir que as equipes respondam de novo rapidamente o que a gente está buscando aqui é MTTR. Eu quero que essa sigla fique na sua cabeça. O que você está buscando é diminuir MTTR. Então aqui a gente está tentando responder rapidamente a crise quando a gente está falando de tecnologia e quando a gente está falando de negócio, você está tentando resolver talvez algum problema de negócio, alguma coisa que pode estar impactando vendas e assim por diante, tá bom? Então quais são os alertas que a gente tem normalmente? Alertas de desempenho, eles vão notificar ali sobre alguma degradação que você tem na sua aplicação, por exemplo. Então aumento de tempo de resposta, diminuição de throughput, aumento de CPU, aumento de uso de memória RAM e assim por diante. Esses alertas de desempenho, você pode falar tanto de alertas de desempenho de máquina, ou seja, como que a sua máquina está conseguindo responder, sua infraestrutura, e com base nisso você sabe que você vai ter outros tipos de problema, ou você pode falar de alertas de desempenho de execução, de quanto que você está conseguindo ter de throughput, tempo de resposta, etc. Você viu que são diferentes? Uma coisa é o quanto que a minha máquina está conseguindo responder, ou seja, o quanto que a minha infraestrutura está indo bem, e outra coisa é o quanto que a minha aplicação e o que eu desenhei está conseguindo responder em cima disso. Uma coisa impacta diretamente na outra, óbvio, mas aqui o que a gente está falando são desses alertas de desempenho. Quando a gente está falando de alertas de disponibilidade, eles são ali quando o serviço está indisponível ou com baixo nível, ou com nível abaixo do aceitável no serviço. Então aqui aquele negócio que a gente falou, alerta do tipo, putz, está tendo 5% de taxa de erro, isso é bom, isso é ruim isso é comum ou não ou está tendo 2% quanto que é considerado bom e quanto que não é considerado bom, quando a gente está falando de disponibilidade, é sobre isso que a gente está dizendo, tá bom? E tem os alertas de segurança, que eles vão disparar ali quando tem algumas detecções de tentativa de acesso não autorizado, ou seja, alguém está tentando invadir, está tentando fazer algum tipo de cyber ataque na sua aplicação, beleza? Então são basicamente esses três tipos de alerta que a gente vai trabalhar mais fortemente no dia a dia e vamos falar um pouco agora de como a gente vai fazer para esses alertas serem eficazes, tá bom? Então alguns passos que a gente pode seguir aqui, eu coloquei aqui três grandes itens para a gente pensar. O primeiro dele é identificar quais são as métricas críticas, tá bom? Então, identificar ali o que afeta diretamente a experiência do usuário, a operação e assim por diante. Então, pode ser tempo de resposta, taxa de erros, uso do CPU. Você definir quais são as métricas que você vai usar para geração de alerta é o primeiro passo. É extremamente importante. E aqui eu estou falando muito dos alertas técnicos, porque normalmente são os primeiros que a gente ataca. Mas ter alertas de negócio também é super importante, aqueles alertas de marketing também são importantes. É bem importante você falar com o seu interlocutor ali e entender quem são as pessoas que acabam utilizando esse tipo de informação e às vezes até gerar alertas específicas para áreas específicas, tá bom? Outra coisa também é determinar, depois que você decidiu, ó, é isso aqui que eu vou olhar, é determinar o que é apropriado, tá? Então, uso de CPU, bateu 80%, tá tudo bem ou não? Eu vou até dar um outro caso, quando você pega, por exemplo, uma aplicação, ela está ali normalmente consumindo 40% de CPU, foi para 60%, gera um tipo de alerta, beleza? Foi para 80%, outro tipo de alerta. Às vezes você consegue escalando os alertas que você tem. Um alerta de, sei lá, 95% de uso de CPU, cara, já é muito crítico. Talvez um alerta de 60% é para você olhar, mas você não precisa se desesperar. Então é importante você ter esse tipo de julgamento na hora de definir esses limiares aqui de alerta, tá bom? Então quando você está definindo esses limites, é importante você compreender bem o que você vai fazer quando um alerta for gerado. Isso é super importante. Então quando você está definindo o alerta, é o que eu vou medir e o que eu vou fazer quando acontecer alguma coisa, porque eu vou ser chamado pensa assim, um alerta é algo está acontecendo, o que eu vou ter de ação e aqui eu vou aproveitar para dar mais uma dica, é onde muitos dos times falham, porque quando a gente está falando de ação após o alerta você precisa estar preparado também, imagina que dá um alerta de uso de CPU igual eu falei para vocês, o uso de memória ou muita taxa de erro e você pega e tem alguém do seu time que é acionado. Esse alguém do seu time ele não conhece aquela aplicação. Ele vai buscar documentação, não tem. Aí ele vai buscar lições aprendidas, não tem. Uma lista de telefones de com quem falar caso aconteça, por exemplo, um problema em banco de dados e esse cara não é especialista em banco de dados, não tem. Se você não se estruturou, não adianta nada o alerta, porque você vai entrar numa sala, vai começar a trabalhar no assunto, vai ter seu time sendo acionado, e o seu time vai estar ali correndo com a barata tonta, não vai saber por onde começar. A não ser que seja o time que desenvolveu, conhece e domina aquela aplicação. Então, você está vendo como você acaba tendo algum tipo de de alerta e ação posterior que não são tão eficientes, não adianta nada o seu alerta ser super bom. Se você não preparou o seu time para ser acionado, você vai ter um problema também, tá bom? Outra coisa super importante, como eu falei, alertar por gravidade. Então, você pode colocar por nível de urgência, tem os críticos importantes ou informativos. Então, quando você pega, por exemplo, olha, está aumentando o uso do CPU, mas ainda tudo bem, não é um problema. Você pode gerar um alerta informativo. Ah não, bati 70%. Aí é um alerta mais ali importante pra você começar a olhar pra esse cara. E puta, bateu 95? Crítico. A mesma coisa pra taxa de erro. Tô com 1% de taxa de erro. Pode ser que pro seu seu cenário 1% seja aceitável, 2% já é outro cenário e assim por diante. Então é super importante você definir qual é a gravidade de cada tipo de alerta. Agora vamos falar um pouquinho sobre algumas boas práticas na hora de você configurar a alerta. A primeira boa prática é você evitar alertas excessivos. Quando a gente está falando de alerta excessivo, muita gente comete o erro de fazer tudo isso que eu falei. Acabei de ver a aula do Natan ali, a aula do Jacques ensinando como é que faz, o Diego, e falam, putz, que legal, um monte de coisa bacana. Vamos aplicar tudo isso e colocar uma porrada de alerta, uma porrada de dashboard? Isso é uma falha, tá bom? Você precisa entender quais são os alertas que são realmente importantes e como que você vai fazer pra gerar esse tipo de ação de acionamento e assim por diante. Por que que isso é importante? Porque imagina que se você tem uma porrada de alerta, nada é alerta. O ponto é, se tem muita coisa sendo alarmada, muita mensagem e muito recado chegando pros times, eles vão começar a não olhar para aquilo, vão começar a não dar importância. Então saber as formas de acionamento, saber como é que você vai mandar esses alertas, como que você vai fazer os times entenderem a informação e a situação é importante. Se você gerar um monte de alerta, para cada problema, por mais trivial que seja, você vai fadigar os alertas, vai fadigar o tempo do time e aí eles vão começar a ignorar as notificações. Se eu não me lembro, se eu me lembro bem, tem uma fábula que chama Pedrinho Lobo, que fala que toda hora o Pedrinho ia lá e falava que tinha um lobo vindo, que tinha um lobo vindo, alguma coisa assim. E até o dia que o lobo apareceu. Era sempre mentira e todo mundo ia lá e tentava ajudar o Pedrinho. E daí, em determinado momento, o lobo realmente aparece e o Pedrinho pede ajuda e não dá certo. Sei lá, o lobo mata o Pedrinho. Não lembro direito dessa fábula. Mas é algo mais ou menos assim. É a mesma coisa quando a gente está falando de alerta. Se você tiver toda hora alerta sendo gerado, quando acontecer um problema, a galera vai achar que é só mais um Então é extremamente importante você ter alertas que sejam realmente importantes e você ir afinando eles, como eu falei, ao longo do tempo para você deixar cada vez mais coerente com o dia a dia dos times e com o dia a dia do que você tem para tocar aí, tá bom? funcionando, esse é um outro ponto muito crítico, quantas vezes eu achei que o time tinha configurado o alerta, todo mundo achou a gente foi lá e falou, putz, está configurado esses alertas aqui estão tudo certinho vai dar certo deu limiar, deu problema, chegou no que a gente imaginava que tinha que ser alertado e ninguém foi alertado e daí a gente pegou o problema um tempo depois, MTTR foi lá em cima. A gente demorou em vez de uma hora para resolver, demorou, sei lá, quatro horas para resolver. Por quê? Porque o alerta não estava funcionando. Então a gente achou que ia ter um alerta e não teve alerta. Não teve ninguém para avisar a gente. E a gente acabou sendo pego de calça curta. Aí você acaba se desesperando um pouco mais, tendo que agir com mais velocidade ainda e muito mais desorganizado. Então aqui quando você configura os alertas, é bom você testar e ver se realmente eles continuam funcionando, se não teve nenhuma alteração que pode ter tirado seus alertas e assim por diante. Então acompanhar para ver se está tudo ok também é extremamente importante, tá bom? Uma outra coisa muito importante é usar alertas aninhados ou compostos. Você precisa ali, basicamente, combinar vários alertas que eles são menores e um único alerta maior para facilitar o entendimento da equipe, não chegar um monte de comunicação. Então, imagina que você vai lá configurar alerta de uso de CPU. Por exemplo, você tem 500 aplicações, você não precisa mandar 500 mensagens de uso de CPU. Você pode juntar tudo e só falar, olha, X aplicações estão ok, X aplicações não estão ok. Por exemplo, isso é um jeito. Aí se você precisar do analítico, você vai gerar um alerta talvez mais crítico quando alguma delas bater um uso muito grande e assim por diante. Então é importante você pensar em aninhar esse tipo de alerta para você não gerar uma porrada de alerta. Então, basicamente é isso, tá bom gente? e quando a gente tá falando de integração dos alertas com os fluxos de trabalho que também é super importante, é o que eu falei pra vocês o alerta ele é pra alguma coisa pra alguma ação ser tomada se é um alerta que não vai gerar nenhum tipo de ação, não precisa ter tá bom? se for um alerta que não vai gerar nenhum tipo de ação, não precisa ter. Se for um alerta, nem que seja informativo, um alerta que ele é informativo, ele é para alguém olhar aquilo e falar, putz, beleza, preciso prestar atenção nesse assunto. Então, os alertas, eles precisam ter algum porquê. Então, foi lá que você definiu, a mesma coisa que você fez para dashboard, a gente vai pensar para alerta. Quem são as pessoas que vão ser acionadas, quem são as pessoas que vão receber alerta, quem são as pessoas interessadas nessa comunicação, quem são as pessoas que são necessárias pra atuar quando algo assim acontecer. Então, essas pessoas precisam ter um jeito de ser acionadas e elas precisam ter um jeito de trabalhar depois do acionamento, ou seja, o que elas vão fazer quando isso acontecer. Então, aqui, eu costumo fazer uma brincadeira com o corpo de bombeiros. Não sei se você já viu naqueles filmes que os bombeiros vão lá, recebem um chamado, se vestem, colocam aquela roupa de bombeiro, descem naquele caninho lá e correm para o caminhão. Esse trabalho, como eles sabem que a hora que dá um alerta, que toca o telefone, ou que tem algum tipo de chamado, eles precisam colocar a roupa, pegar todos os equipamentos, quais colocar roupa, pegar todos os equipamentos, quais são esses equipamentos, descer no caninho e depois ir para o caminhão. Imagina que deu alerta, tem cinco bombeiros ali no corpo de bombeiros, um deles vai vestir a roupa, vai fazer tudo isso que eu falei, o outro vai, sei lá, escovar o dente, o outro pensa e fala, putz, eu não preciso da minha bota, esquece a bota, por exemplo, vai colocar a roupa e vai sair descalço. Então, você está vendo que tem uma organização no corpo de bombeiros? Eu acho isso super importante porque parece bobo, mas eles têm uma organização muito boa. Quando acontece um problema, eles já sabem o que fazer. Teve um alerta, eles vão lá, colocam a sua roupa, equipam, descem para o caminhão, pegam o caminhão e sai. Ótimo. Então eles já sabem como montar tudo isso, todo mundo sabe o que fazer e qual é o seu momento, eles devem treinar e ensaiar pra isso. Se você conhece bombeiros, deve saber melhor do que eu. Eu não conheço tanto o dia a dia deles, mas eu tenho certeza que é super organizado. Então quando você tá falando desse tipo de acionamento, alerta, que você tem que ir rápido porque o tempo de resposta é extremamente importante, você precisa estar ensaiado para isso. Então, quando você está falando de alerta, se esse alerta estiver integrado com o fluxo de trabalho que, por exemplo, vai gerar uma rastreadibilidade do que teve de problema, vai gerar um acionamento certo de informação para todo mundo, vai deixar já preparado algum tipo de fluxo de trabalho para esse time conseguir executar, já automatiza o que precisa ser automatizado para essas pessoas poderem entrar e trabalhar de forma mais direcionada no problema e assim por diante. Então, você pensar em alertas que eles automatizam o fluxo de trabalho para o time que vai entrar é super importante. E você também pode fazer automação de resposta. Então, para alguns tipos de alerta que você já sabe o que acontece, já sabe o que vai rolar, você pode colocar automação que vai resolver isso sozinho. Você não precisa nem do time entrar. Então, por exemplo, o que eu falei lá de uso de CPU. Putz, está batendo o uso de CPU muito alto. E você ia, sei lá, rebootar a aplicação? Você ia desligar e voltar ela? Se você for fazer isso, você pode colocar, talvez, alguma automação que com base no alerta vai cair ali num tópico e você já lê isso e já faz algum reset de aplicação já repensa em desligar e ligar a instância e assim por diante pode ser uma ação temporária até que o time entra e entenda o que está acontecendo e assim por diante então isso é super importante também tá bom? outra coisa super importante também foi o que eu falei pra vocês, documentar a resolução porque se você documenta a resolução você consegue primeiro, garantir que tudo tá funcionando muito bem olhar pra trás e ver o que vocês podem aprender com isso, e o principal a próxima pessoa que pegar algum problema semelhante pode resolver usando o mesmo tipo de ação, beleza?