Fala galera, beleza? Vamos falar um pouquinho sobre as principais armadilhas que a gente acaba caindo no dia a dia quando a gente está falando de implementar observabilidade, tá bom? É importante a gente entender onde a gente já errou para vocês conseguirem ter aí uma observabilidade que faça mais sentido e consiga ajudar realmente vocês no dia a dia. Então a gente vai passar um pouquinho em como que a gente vai focar nas métricas corretas, como que a gente vai configurar alertas que são mais relevantes, como a gente vai ter contexto e como que a gente vai minimizar falsos positivos ou negativos e até automatizar a resposta a incidentes aqui, para a gente conseguir ter efetividade nos nossos dashboards e na nossa observabilidade, tá bom? Então vamos começar a falar um pouquinho sobre alguma das principais armadilhas que eu já vi no dia a dia e que eu queria compartilhar com vocês. A primeira delas que eu queria falar é o excesso de dados, tá bom? Quando a gente está falando de uma sobrecarga de dados, a gente acaba gerando uma porrada de problemas. Então quando a gente está falando do dia a dia, se você estiver coletando muito dado, também é um problema. Então você fala assim, olha, eu tenho um sistema que não tinha nada de observabilidade. Vou começar a coletar tudo quanto é tipo de dado. Vai gerar um problema. Então o importante é você ter um equilíbrio. Não dá para você também coletar tudo quanto é tipo de dado. Você tem que coletar dados estratégicos. Não dá para não ter dado, para você viver sem observabilidade, então o que a gente sempre fala é isso. Mas o que a gente vê acontecendo no dia a dia é que os times que não estão acostumados a implementar observabilidade, quando começam, eles acabam pendendo para o outro lado. Fica todo mundo muito ansioso para colocar muita observabilidade e acaba incluindo dados adicionais, dados que não são necessários e que não precisam ser monitorados. Então, muitas das métricas que a gente acaba colocando e os dados que a gente acaba coletando, elas não têm uma estratégia clara. Então, o principal foi o que a gente combinou aqui. Para falar de observabilidade, isso tem que ser tratado como backlog do time. Tem que ser discutido, tem que ser entendido e tem que ter uma estratégia para isso, tá bom? Então, quando a gente está falando desse tipo de assunto, de sobrecarga de dados, normalmente os dashboards vão ficar confusos, vão ter dificuldade para você entender o que realmente é importante, o que precisa ser feito, o que precisa ser visto e assim por diante. Então, quando a gente está falando das consequências disso, normalmente você vai ter dificuldade de encontrar a informação relevante, porque você tem tanta informação que a relevante acaba virando uma agulha no palheiro. Então, você precisa conseguir olhar muitos dados até chegar no dado que realmente você precisa de informação crítica e de informação estratégica, tá bom? Uma outra coisa também é sobre desempenho. Quando você está fazendo a coleta de muito dado, você acaba sobrecarregando o seu sistema de monitoramento e você tem um desempenho mais fraco. Então quando você precisar atuar em algum tipo de dashboard ou atuar fazendo algum tipo de tracing, você vai ter muito mais lentidão para conseguir buscar os dados, fazer os selects e assim por diante. E com isso você vai acabar tendo uma degradação no seu tempo para conseguir corrigir um problema ou para conseguir identificar um problema. Uma outra coisa também que eu acho importante de falar, quando a gente está falando sobre carga problema tá bom uma outra coisa também que eu acho importante de falar quando a gente tá falando sobre carga de dados eu vou entrar na guarda desses dados também rapidamente então quando eu tô falando da sobrecarga de dados tanto para mostrar quanto para guardar você acaba gerando um outro problema que é de finops é caro guardar dado então quando você tá falando lá que você vai guardar tudo quanto é tipo de log tudo quanto é tipo de informação sem uma estratégia clara do que você está tentando ver, você vai acabar gerando um custo adicional que muitas vezes pode ser prejudicial para o seu negócio. Então todos esses pontos tem que estar na nossa cabeça quando a gente vai falar de observabilidade. Outra coisa também, vamos pensar em como a gente vai diminuir esse tipo de problema. Vamos focar nas métricas que são mais críticas, então é legal você definir quais são as métricas que vão ser essenciais para o objetivo de negócio e quais são os dados que são essenciais para você conseguir monitorar a sua aplicação, não adicionando muitas coisas a mais. Se você tem uma dúvida de uma coisinha ou outra, tudo bem você colocar, mas muito cuidado para você não incluir muita coisa. O importante é você tentar focar nos objetivos de negócio e no que você vai precisar pro dia a dia, tá bom? Outra coisa também importante é você regular essas métricas porque objetivos mudam, estratégias mudam e assim por diante. Então, conforme as coisas vão rolando, você eliminar aquelas métricas que podem não fazer mais sentido e que não estão gerando mais nenhum insight acionável. É super importante também. Outra coisa também importante da gente falar, e a gente já falou um pouquinho durante as nossas conversas aqui, eu acabei tocando nesse assunto, mas um assunto importante são os alertas que são irrelevantes ou excessivos, tá bom? Então quando a gente está falando de alerta, você configurar alertas que façam sentido é super importante. A gente já falou disso, até contei a história do Pedrinho Lobo. Então, quando a gente está falando de alertas relevantes, você precisa ter ali os alertas que vão gerar algum tipo de ação também, ou seja, não adianta você receber uma porrada de alertas onde você não tem ação nenhuma para fazer e nem adianta você receber muitos alertas que você vai acabar deixando de lado e vai acabar não atuando neles. Então, como eu disse aqui, você tem como consequência, acaba ignorando ali alertas que são críticos, quando você tem muito alerta chegando, você acaba tendo que focar no seu dia a dia de trabalho e vai deixando de lado os alertas críticos e vai acabar deixando passar um outro problema. Uma outra coisa também é que você vai reduzir a eficácia operacional, ou seja, você vai ter uma sobrecarga de alerta irrelevante e a galera vai acabar tendo que olhar para muita coisa e vai ficar mais improdutiva no dia a dia também. Como que você vai evitar isso? De novo, classificando os alertas por nível de urgência, a gente já falou disso, então classificar esse alerta no que é crítico, o que é importante, o que é informativo e estabelecer o que vai acontecer para cada tipo de alerta. Então, para um alerta crítico, quais são as ações requeridas? Para o importante, quais são as ações requeridas? E para o informativo, quais são as informações requeridas? E até o tom da conversa para cada tipo de alerta desse. Cada tipo de alerta pode vir declarado de forma fácil qual é o tipo dele, porque daí os times têm mais facilidade de entender o acionamento que está sendo gerado e de conseguir executar o que precisa ser executado dado o alerta que foi gerado. Uma outra coisa também importantíssima são os alertas compostos. A gente fala muito de alerta unitário, mas os alertas compostos são muito importantes. Então você pode pensar em alertas que só vão ser estartados quando você tiver múltiplas condições problemáticas. Aí sim você vai conseguir gerar um alerta. Eu coloquei aqui um exemplo só para vocês entenderem do que eu estou falando, porque eu sei que tem pessoas que podem não conseguir compreender o que são alertas compostas. Então vamos lá. Quando a gente está falando de um SaaS, por exemplo. Tem uma empresa lá que ela está fornecendo software como código. Você está contratando isso direto. Você pode configurar ali um alerta crítico que vai disparar só quando a taxa de erro do sistema ficar acima de 5% por mais de 10 minutos. Ou seja, se ela ficar 5% por 1 minuto, ele não dispara nada. Se ela ficar 5%, acabou de ficar, não vai disparar. Ele vai disparar só quando tiver 10 minutos acima de 5% de taxa de erro. E daí com isso você vai ter só um alerta mostrando a criticidade desse alerta. Aqui você podia fazer um combinado. Você podia, por exemplo, deu o primeiro pico de 5% de falha, dentro de um minuto, por exemplo, você já gera um informativo. Deu em 10, um importante. Deu em 20 minutos, um crítico e assim por diante. Então você consegue ir se organizando para fazer também com categoria e com tempo de composição de alertas, você consegue gerar alertas que são mais eficientes também, mais eficazes, tá bom? Outra coisa também são os contextos. Isso é muito importante, muita gente acaba falhando nisso também, quando a gente está falando dos contextos, se você não tiver um dado contextualizado, você pode acabar gerando um alerta ou uma informação que vai gerar um falso positivo também ou pode gerar um falso negativo então por exemplo, se tem um aumento repentino ali de uso de CPU você pode falar, pô, está acontecendo alguma coisa no meu sistema, uma desgraceira do nada começou a aumentar a minha CPU. Mas se você coloca um contexto adicional, por exemplo, que está tendo uma Black Friday, está tendo um aumento de tráfego e tem muita gente entrando no sistema, você começa a entender que não é um problema. Realmente teve muita gente entrando e o CPU vai aumentar. E tudo bem, você tem que acompanhar, você tem que tomar ações, etc. Mas é diferente da CPU aumentar por nada. Então aqui você tem um motivador para esse CPU ter aumentado. Então você precisa ter o contexto do porquê as coisas estão acontecendo. Então quando a gente está falando de alerta e de monitoração, é importante você ter esse cruzamento de informações. Então quando você tem falta de contexto, você pode tomar decisões incorretas. Então, por exemplo, você está vendo ali que você tem um aumento de CPU, ao invés de você tentar fazer um aumento ou uma escala de aplicação e assim por diante, você pode acabar querendo refatorar alguma coisa porque acha que está errado e assim por diante e acaba gerando outro impacto. Aqui, extrapolando, tá gente? e acaba gerando outro impacto, aqui extrapolando, tá gente? Então você pode acabar tomando uma decisão incorreta. Outra coisa também, você pode ter ali um diagnóstico ineficiente, você pode acabar decidindo a coisa errada também, pelo diagnóstico que pode ser ineficiente, e você pode entender a causa, a raiz errada do problema. Então ter essa correlação vai ser super importante. Como que você evita? Correlacionando os dados, então sempre que você puder, você ter correlação de dados diferentes para você conseguir compreender as métricas com mais contexto, tá bom? Outra coisa também, usar dashboard contextualizado, então que eles mostrem dados em conjunto, que nem eu falei, número de clientes usando, número de CPU, memória RAM e assim por diante, vai mostrar para você uma visão mais geral do que está rolando. E outra coisa que eu coloquei como um exemplo prático, uma plataforma de streaming, quando você correlaciona o pico de latência com o lançamento de novos episódios ou de uma série, isso vai mostrar que, óbvio, você acabou de lançar uma série, vai ter um pico de latência, então está tudo bem. Agora, não lancei nada e do nada teve um pico de latência, é importante entender o que aconteceu, se está tendo realmente mais usuários acessando ou se não. E daí você vai entender essa latência, se faz sentido atual ou não. Quando a gente está falando aqui também de alertas de falso positivo e falso negativo, são os acho que na minha opinião os piores. Porque quando você tem falso negativo ou falso positivo, você acaba sendo pior do que não ter alerta. Eu vou explicar por quê. Imagina que você tem um falso positivo. Então, o alerta foi lá e acionou para um problema que não existe. Você vai colocar todo um time indo atrás de um problema que não existe, um fantasma ali no código, uma coisa que não tem problema. E quando você faz isso, você vai saturando o time, separa o time do dia a dia de trabalho e coloca ele para atuar em uma coisa que não tem problema, ou seja, é total desperdício, você está jogando dinheiro no lixo e você está saturando o time. Quando acontecer um problema, realmente, o time vai perder a confiança nos alertas. Quando a gente perde a confiança, isso vai gerar um outro problema, porque a cultura de observabilidade começa a cair. Porque você entende que é cultural, você olhar a alerta, você colocar o seu time para entrar, você conseguir executar alguma ação, é cultural. Você precisa formar o time para que isso aconteça. E quando esses alertas começam a ser ineficientes, começam a ser um falso positivo, esse time vai começar a perder essa cultura que é muito crítica, porque por cultura é difícil fazer o time fazer isso, é complicado. Então é importante você conseguir compreender também é os alertas que têm falso positivo resolvê los muito rápido tá bom e quando está falando de falso negativo é pior ainda porque você está vendo que tem um problema acontecendo sei lá tem um monte de usuários reclamando e você quando vai olhar os seus alertas ou seus dashboards você vai ver que não tem nenhum problema então Então isso vai gerar outra coisa. Você vai ficar não só cego, mas você vai ficar com a informação errada, vai acabar tomando ações mais lentas e vai demorar muito mais tempo para conseguir compreender o que está acontecendo. Então é importantíssimo você também olhar para isso, porque você está confiando naquilo, está confiando naquele paraquedas e ele não abriu. Você está lá no seu dia a dia de trabalho, ao invés de estar olhando um dashboard, está confirando um alerta e esse alerta falhou. Então aqui vai acabar gerando todo esse problema, que a gente está falando de tempo de resolução de problema e até do time conseguir compreender o que está acontecendo. Então aqui, como consequência de falso positivo, você pode ter ali ações desnecessárias, vai acabar fadigando e também gerando muito desperdício e os sócios negativos podem deixar ali problema real acontecendo e a gente acabar tendo uma falha muito maior do que isso graças a esse tipo de alerta errado. E como que a gente vai evitar isso? Primeiro, ajuste fino dos limiares ali porque normalmente quando você pega isso é porque a gente decidiu errado o limiar do que é um problema e o que não é, tá bom? Então quando você vai configurar esse limiar, é importante você ficar ajustando ele, principalmente nos primeiros meses, depois você fez uma implantação, depois você colocou uma coisa ali para executar, você analisar aquilo para ver se aquilo é um comportamento normal ou não é normal, para você diminuir essa probabilidade de um falso positivo pelo seu, por esse afinamento, por esse ajuste fino do que realmente é um problema ou não, tá bom? Outra coisa também é o aprendizado contínuo, você está sempre ali usando a técnica de aprendizagem de máquina para ajustar esses parâmetros, alerta com base em padrão de uso histórico de incidente também vai ser super importante, porque daí você vai conseguir olhar o comparativo do que já aconteceu para tomar decisões futuras. Então aqui, por exemplo, eu coloquei um exemplo prático para a gente olhar, em um banco digital, o ajuste de limiares de alertas para transações suspeitas com base em padrão de comportamento histórico do cliente reduz o número de alertas falsas que necessitam investigação manual. Aqui a gente está falando de usar ferramentas de mercado que já tem prontas, de você entender os alertas de suspeita, de fraude e assim por diante, com padrão no histórico de comportamento do cliente. Então você consegue usar esse tipo de alerta dentro de uma ferramenta de utilização, de validação, de investigação ali, beleza? Uma outra coisa também é a falta de automação e as respostas lentas, então de novo um alerta ele vai gerar, num primeiro momento quando você tem um alerta, ele vai gerar no time um desafio ou uma ação, se o seu time não estiver preparado pra dar uma resposta então se o seu time não estiver ensaiado, se você pensar assim pra quando ele ter aquele alerta, o que eu faço, qual documentação eu acesso, quais são os dashboards que eu tenho, onde eu consigo fazer tracing, como que eu tenho que entrar em uma sala e resolver um problema, e pensar em hipóteses e resolver hipóteses. Se tudo isso não está preparado, você vai acabar tendo uma resposta muito lenta ao incidente. Então não vai adiantar nada o seu alerta, não vai adiantar nada a sua monitoração. Você nada, o seu alerta não vai adiantar nada a sua monitoração, você precisa ter um time que saiba usar isso, saiba usar essas ferramentas esse é o primeiro ponto quando a gente está falando do segundo ponto é automação mais do que a cultura do time mais do que preparar o time, você pode automatizar vários processos, se você tem essa falta de automação você acaba sobrecarregando o time e você acaba também sendo mais lento. Então, quanto mais automatizado tiver, melhor. E a automação, muito cuidado também, porque você tem que afinar as automações, porque nem sempre a resposta a um incidente é a mesma. Então, é importante você tomar muito cuidado quando você for automatizar algo, você pode gerar um problema ainda maior se você não pensar numa automação bem pensadinha, beleza? Por exemplo, imagina que você foi lá e gerou um problema na fatura do seu cliente e processou alguma coisa errada, gerou um problema e você tem uma automação que vai reprocessar. Dependendo de como foi esse problema, o reprocessamento pode piorar e agravar mais os dados que foram gerados erroneamente. Então é importante você compreender quando pode automatizar e quando não. E voltar e refinar esse assunto toda hora. Voltar e revisar. Você está vendo que eu estou falando toda hora de voltar e revisar? Porque é constante. Não é algo que você coloca lá e esquece e acabou. É uma ferramenta que você tem que estar constantemente analisando. Então aqui quando a gente está falando de falta de automação e tempo de resposta lento. Você vai ter ali um aumento de inatividade. de automação e tempo de resposta é lento, você vai ter ali um aumento de inatividade, ou seja, você pode ter um maior tempo do seu sistema fora e um prejuízo financeiro para a sua empresa, ou seja, o seu MTTR vai ficar muito alto e uma carga de trabalho elevada para você não ter automação, como eu falei para vocês acabando que por tirar o time do dia a dia de trabalho e por poder fazer melhorias ele vai acabar tendo que atuar em coisas que poderiam ser automáticas, beleza? Como que a gente evita implementar automação, então usar scripts automatizados, não só pra incidente direto, ou seja, imagina que você teve um incidente, postou um alerta em algum tópico e você tem uma automação lá sei lá, um lambda que vai executar lendo isso pra fazer algum tipo de ação. Isso é o jeito, tá bom? Mas você tem outros jeitos, por exemplo, de já deixar pronto scripts para busca de dados, você pode já deixar pronto algum tipo de ação que o próprio time acaba tendo que executar. Então, se você deixar essas coisas prontas para algum analista entrar, analisar e falar puta, é isso que eu preciso fazer, e já ter aquilo de forma um pouco mais padronizada de execução, também pode ajudar, tá gente? Nem sempre a automação tem que ser aquele supra-sumo, aquela coisa que faz tudo automático. Às vezes você ter algum tipo de script já preparado já ajuda bastante também, se você ainda não conseguiu chegar no nível de ter tudo automatizado, sem precisar da ação humana, beleza? Outra coisa também é o monitoramento contínuo. Você está ali monitorando sempre e diminuindo o tempo de inatividade e outra coisa também é a que eu coloquei um exemplo prático, uma plataforma de e-commerce pode implementar script automatizado para detectar e reiniciar automaticamente instâncias que estão sobrecarregadas por exemplo, aumentou muito o CPU, pode reiniciar caso seja o cenário, beleza?