Bora dar sequência, aprendendo um pouquinho sobre a importância da observabilidade no nosso dia a dia, como é que a gente vai usar isso a nosso favor nesses sistemas que a gente tem que são cada vez mais complicados. Mas antes da gente começar a aprofundar em observabilidade, antes da gente começar a ver a importância disso, deixa eu me apresentar. Eu apresentei o Diego, me apresentei o Jacques para vocês e acabei não me apresentando. Eu leciono algumas aulas aqui no Devil's Full Cycle, então vocês já devem ter me visto em algumas das aulas por aí. E se não me viram, vocês me conheceram um pouquinho. Eu sou Nathan Pasquarelli Freitas, eu trabalho com tecnologia há mais de 20 anos, então desenvolvo, comecei desenvolvendo muito novo. Fiz bastante coisa ainda em desenvolvimento e engenharia de software. ainda em desenvolvimento em engenharia de software. Depois de algum tempo nessa área, júnior, pleno, sênior e etc., virei tech lead, cuidei de algumas grandes squads com alguns desafios bem complicados, desde migração de bancos, até bancos, bancos mesmo, de compra de um banco pelo outro banco, como é que você junta sistemas, como é que você refatora sistemas, como é que você cta sistemas, como é que você refatora sistemas, como é que você cria sistemas novos e assim por diante. Participei de muita coisa grande, quando a gente fala de desafios tecnológicos, tive a oportunidade de aprender com grandes mentes que trabalharam ao meu lado, então consegui aprender muita coisa ainda enquanto desenvolvedor e enquanto tech lead. E depois disso eu virei coordenador, então assumi um cargo de coordenação e fui coordenador de alguns times, tá? Então liderança ali de primeiro nível de alguns times de 20 a 30 pessoas de diversos tipos de sistema, desde sistemas em .NET, Java e assim por diante. As migrações para a Cloud, participei do começo das migrações para a Cloud e depois virei gerente e como gerente de sistemas eu estou atuando há mais de quatro anos. Nesses quatro anos também tive uma jornada bastante interessante em vários sistemas que eu não vou ficar mencionando aqui para vocês, de tudo quanto é tipo e estilo e etc. E no momento estou ainda como gerente de sistemas atuando com um time bastante grande, acho que mais de 100 pessoas no momento e vários desafios diferenciados, bastante grande, acho que mais de 100 pessoas no momento e vários desafios diferenciados sistemas que são muito requisitados e com muita necessidade de velocidade e tempo de resposta e de muita resiliência no fim do dia, tá? Então basicamente isso sou eu dou aulas aqui e também tenho outras propostas por fora também, se vocês quiserem me conhecer mais me adiciona aí no LinkedIn, fique à vontade pra mandar mensagem, eu sou super aberto para a gente ter uma parceria, a gente criar aqui uma relação também, na Tampa Ascora Elefreitas no LinkedIn, e daí a gente conversa, vocês conhecem um pouco mais de mim, caso interesse para vocês. Mas vamos à nossa aula, que é mais importante, mais interessante do que a minha própria vida, né? Então, falando da nossa aula, eu queria falar um pouquinho com vocês sobre como que a gente pode usar a observabilidade, como ela vai ser importante, principalmente para diagnosticar problemas. Então, como eu falei antes, não adianta você ter ali um avião sem você ter todos os parâmetros ali, todo o seu painel de comando, de serviços para você entender como as coisas estão funcionando no dia a dia. Se você não conseguir ver se a pressão da cabine está certa, se a sua turbina está funcionando e assim por diante, uma hora esse avião vai cair. Então é importante você conseguir enxergar isso. E quando você tiver um problema, e problemas ocorrem, podem acontecer, quando você tiver um problema no seu sistema, você precisa saber entender onde é para poder resolver. Então conseguir diagnosticar é super importante. Você precisa conseguir olhar para esse sistema e de forma analítica entender onde o problema está acontecendo. E não dá para você pensar em colocar informação adicional depois que o problema aconteceu. Porque imagina que você tem um problema instaurado, não é o momento de você criar novas coisas, não é o momento de você fazer deploy de novas coisas, é o momento de você deixar como está, analisar o que acontece para depois fazer novas implantações. Muita coisa que acontece é quando a gente não tem log, quando a gente não tem métrica, não tem as coisas ali para observar a nossa aplicação, quando dá um problema a gente começa a subir módulos com instruções para geração de log. E quando você faz isso, você acaba abrindo uma porta diferente, porque você mudou já o que tinha, você já não tem a mesma versão de código instalada, então você precisa começar a pensar um pouco nisso. Então, uma dica que eu dou é, se a gente tiver um sistema que ele está observável, a gente consegue fazer o diagnóstico de problema com mais facilidade, sem poluir o ambiente quando a gente está precisando resolver um problema. E poluir o ambiente quando a gente está precisando resolver um problema. E a gente consegue identificar rapidamente onde é o problema e resolvê-lo. E com isso a gente não gera impacto ali para o nosso cliente e garante a continuidade do nosso serviço, tá bom? Uma outra coisa que também vai ser muito importante é a melhoria de performance da aplicação, como eu falei antes. E aqui a melhoria de performance, eu vou para ambos os lados, tá? A primeira coisa é que quando você tem uma observabilidade muito boa, você consegue olhar o comportamento do seu sistema. E comportamento é importante, essa palavra é importante. Porque o sistema tem um comportamento, um comportamento normal. E quando ele começa a fugir da normalidade, você, tendo um sistema observável, você consegue ver essa mudança, essa variação de comportamento. E dada essa manutenção de comportamento, você consegue ver essa mudança, essa variação de comportamento. E dada essa manutenção de comportamento, você pode tomar algumas decisões. A primeira delas é começar a olhar para isso e analisar para ver se você consegue tomar ações posteriores a um problema. Então imagina que você começou a ter um aumento de CPU que você não estava prevendo, não teve muito aumento de chamada nem nada, mas começou a ter um aumento de CPU. Não é estranho? Você poderia pensar em o que pode acontecer. Será que você precisa aumentar a sua capacidade de processamento? Ou você precisa rever o sistema porque tem alguma coisa acontecendo? Aqui você consegue identificar gargalos que vão acontecendo no meio do caminho. Como é que você melhora isso? E daí, tem um outro ponto também. Imagina que você está lá com a sua aplicação, vários microserviços rodando, está tudo ok, e alguém de um sistema diferente faz alguma implantação e começa a gerar gargalo na sua aplicação porque teve um aumento de consumo. E daí, quando teve aumento de consumo, estava até previsto. Você estava prevendo para o seu microserviço aquele aumento de consumo. Você não tinha preparado a sua tabela para ter esse aumento de consumo, ou seja, seu banco de dados não aguentou tanto de thread que seus microserviços começaram a abrir. Porque quando começou a abrir, por exemplo, algumas dos selects do seu SQL, por exemplo, não estava funcionando muito bem e acabou gargalando no banco e começou a trazer problema para a sua aplicação, que gerou um impacto generalizado. Quando você tem uma observabilidade, você consegue ver que o banco de dados está sofrendo mais, que ele está tendo que processar mais e que ele está tendo mais dificuldade para dar a sua resposta. E com isso você já consegue se preparar para resolver o problema ali. Ou se alguma thread está com algum problema, você consegue matar um kill nela, por exemplo. Ou se você está tendo algum problema no seu microserviço, você também consegue trabalhar para resolver isso também. Ou seja, vocês estão vendo como é importante a gente conseguir enxergar o que está acontecendo para ver os gargalos pipocando e poder resolver antes de gerar o impacto. Uma outra coisa também que a gente pode fazer é o inverso. Imagina que você tem ali uma aplicação que ela tem um número X de capacidade de processamento, está usando um tipo de máquina no seu provedor cloud, que é super caro e não está tendo chamada suficiente para isso, não está gastando quase nada. Você pode usar uma máquina mais barata, quem sabe, você pode tentar ir por outro caminho para deixar isso mais barato e daí você melhora a performance também, porque você acaba sendo mais barato para fazer as coisas acontecerem. Então, você entender as anomalias, onde os gargalos estão acontecendo durante a aplicação, dentro do seu sistema inteiro, antes que isso torne um problema crítico, é super importante você também olhar para isso para conseguir reduzir consumos desnecessários, é super importante. Então, o ponto principal é, se eu enxergo, eu vejo o padrão. Se eu vejo o padrão, eu me antecipo. enxergo, eu vejo o padrão. Se eu vejo o padrão, eu me antecipo. Esse é o ponto principal quando a gente está falando de melhoria de performance. Uma outra coisa também é o tempo de inatividade. Pessoal, quando eu estou falando de tempo de inatividade é quando dá um problema. Dê um problema mesmo ali no sistema e o cliente está sendo impactado, tá bom? Tem um livro muito interessante que fala sobre essa métrica, que é o livro Accelerate. Ele fala sobre uma métrica chamada MTTR, para quem não conhece. É Main Time to Repair. O que isso significa? Quando você tem um problema em produção, um problema que está impactando o seu cliente, qual é a maior métrica que você tem que se preocupar? O tempo que você demora para responder. Então, vamos fazer um paralelo aqui com, por exemplo, um corpo de bombeiros. Imagina que está pegando fogo aqui na minha casa. Começou a pegar fogo, eu ligo para o corpo de bombeiros e o pessoal lá do corpo de bombeiros nunca ouviu falar do incêndio. A primeira vez, os caras acabaram, são novatos, nunca viram um incêndio na vida. Nunca fizeram teste e assim por diante. Eles vão ter que colocar as suas roupas de bombeiros, preparar os caminhões, pegar os equipamentos, mangueira, sei lá mais o que precisa, que eu não manjo tanto assim, de corpo de bombeiros, mas eles precisam se preparar e sair pra fazer ação ali no ambiente, beleza? Agora, imagina que eu não liguei. Como é que eles vão saber que tem um problema aqui em casa? Eles vão ter que ficar olhando de casa em casa? Basicamente é isso que a gente está falando. O tempo para apagar esse incêndio, e aqui eu fiz esse paralelo justamente porque normalmente quando a gente tem um problema, a gente compara com incêndio, querendo ou não, nós desenvolvedores e engenheiros, a gente acaba sendo meio bombeiro. E não adianta você querer primeiro, resolver o incêndio sem sem ter treinado antes. Então, uma coisa importante para vocês pensarem é, quando tem um problema, você se preparou para ele? Você sabe se pavimentar, colocar roupa, pegar os equipamentos certos para não esquecer de nada e assim por diante? Essa é a primeira coisa. A segunda coisa é, como que você fica sabendo que tem um incêndio? Você vai ter que ficar passando de casa em casa, batendo, oi, está tudo bem aí tem, então pensa que a observabilidade seria mais ou menos isso. Poxa, se tem aqui um prédio que tem alarme de incêndio que já dispara direto para o bombeiro, imagina que são seus alarmes realmente de observabilidade. Você não tem só a capacidade de enxergar, mas você tem a capacidade de reagir mais rápido quando você tem um problema acontecendo. E o seu tempo de fogo pegando vai ser bem menor. Então o tempo de inatividade que eu estou falando aqui é a mesma coisa. Quando a gente tem um problema em produção, quando tem um problema impactando o cliente, o que a gente quer fazer é diminuir o MTTR que eu falei para vocês. Quanto mais rápido a minha ação, quanto mais rápido eu resolver, melhor. Vai ser bem melhor para o meu cliente. Então o que eu quero que vocês tenham na cabeça é basicamente isso. A observabilidade vai ajudar vocês a diminuir esse impacto no cliente e a melhorar a sua relação com esse cliente e às vezes até passar como imperceptível. Então basicamente você consegue ser primeiro, proativo, se você tiver os alertas certos, às vezes era só uma fumacinha, nem chegou a ser um incêndio, só um princípio de incêndio. Você chegou ali, já conseguiu resolver antes daquilo virar um problema ou às vezes você consegue resolver tão rápido que o cliente nem entende que teve um problema, porque ele não vai ter visto. Então, isso é super importante quando a gente está falando em tempo de inatividade e como a observabilidade pode ser útil para isso. A observabilidade aqui nesse cenário é extremamente importante. Os meus times passam muito por isso e eles sabem reagir muito rápido. Eu tenho um grande orgulho dos times que eu formei serem muito bons nisso. E aqui, vamos lá. Não adianta a gente achar que não vai ter impacto em produção, isso eu acho que é um mito, tá? Que não vai ter um problema acontecendo, tem que ter testes, a gente tem que pensar em qualidade, a gente tem que fazer as coisas com calma e responsabilidade, sem sombra de dúvidas, mas a gente está mexendo em um ambiente, ele está o tempo cliente ser melhor, ter coisas melhores e conseguir ter uma experiência melhor, ou porque a gente não fez nada também, porque não fazer também gera impacto, você também tem código ficando obsoleto, nova versão do Java vindo, um monte de risco de cyber acontecendo, então você vai ter coisas que se você não se mexer para melhorar, vão gerar problemas. Então o tempo todo isso está em movimento, não é uma coisa parada, é uma coisa dinâmica, não é estática. Você precisa estar mexendo no sistema e vai acontecer de ter problema. O ponto é, quando tiver problema, como você entende o problema e reage a ele. Quanto melhor você for nisso, melhor vai ser o seu sistema, melhor vai ser a relação com o seu cliente, beleza? Outra coisa também é pra tomada de decisão informada que eu falo, tá? O que que significa? Quando a gente tá falando ali do dia a dia, hoje em dia a gente fala cada vez mais da utilização de dados pra tomada de decisão, beleza? Então, a gente não toma uma decisão de o que fazer, o que não fazer, prioridade de projeto, prioridade de pontos de resolução dentro de um sistema ali, com base em achômetro. Imagina que eu sou o tech lead ali da minha squad. Eu não posso chegar ali para o meu PM, para o meu líder de negócio, para a minha equipe, inclusive, e falar, gente, vamos priorizar esse mês aqui, melhorar, nesse sprint vamos melhorar tal coisa aqui da aplicação, porque eu acho que não está bom. Eu vamos melhorar tal coisa aqui da aplicação porque eu acho que não está bom. Eu acho que não está bom é complicado, né? Agora, se você consegue enxergar e observar o seu sistema, você consegue ver os gargalos que eu informei antes, você consegue ver o que está meio esquisito, o que pode ter algum problema ou não, e tomar decisões para ajustar isso ou para reduzir custo ou para aumentar a sua velocidade, a sua resiliência e assim por diante. Então você consegue tomar decisões mais fáceis. E imagina quando você quer levar isso, por exemplo, para uma tomada de decisão em alto nível. Sei lá, você quer falar com o chefe do seu chefe ou com outro chefe, alguém que está em um nível hierárquico maior e que tem uma visão um pouco mais estratégica e menos técnica do dia a dia. Quando você leva dados embasados de como as coisas estão acontecendo, facilita muito a sua vida para tomar decisão para essa discussão. Então, essas decisões estratégicas, elas precisam de dados que às vezes você vai capturar no seu sistema com observabilidade. Então, pensem nisso. Os ajustes técnicos que você às vezes quer fazer e não consegue, às vezes é porque você tem falta de dados que são gerados por esse tipo de observabilidade para você poder colocar isso em uma decisão estratégica no dia a dia e conseguir fazer o que você está querendo, beleza? Isso eu acho super importante, pessoal, porque a gente sofre muito para fazer as coisas no dia a dia para mostrar o nosso ponto de vista e às vezes é porque a gente mesmo não colocou o que precisava de observabilidade para conseguir contar a história do jeito certo. E até para comprovar que o que a gente está falando faz sentido, ou se a gente não está também viajando, que às vezes acontece, tá? Uma outra coisa importante também é a colaboração. Esse é um capítulo sensacional, gente. Quando a gente está falando de colaboração, o que eu estou querendo dizer? Imagina que você tem um sistema. Quem é o dono do sistema? Essa é uma pergunta interessante. A gente tem um sistema aqui que faz, por exemplo, faz toda a parte de contabilidade da sua empresa. Quem que é o dono do sistema? O dono do sistema é o desenvolvedor? É você? O engenheiro, arquiteto, sei lá, quem está fazendo ali a parte de tecnologia? Não. Por muito tempo a gente colocou os donos dos sistemas como nós, quem desenvolve, quem codifica. A gente é parte do sistema, a gente codifica ele. Os donos do sistema são muitos. E na minha opinião, eu gosto de fechar em quatro grandes atores aqui e alguns deles podem estar juntos. O primeiro deles seria a parte de negócios, que pode ser um PM, pode ser um líder de negócio, pode ser um analista funcional de negócio, etc. Não sei como chama na sua empresa. Mas a primeira pessoa é a pessoa que tem aquele olhar do negócio. Quanto que você ganha? Qual o P&L daquele negócio? Quanto que você gasta? Lucro? Esse tipo de coisa. Essa é a primeira pessoa, beleza? Ela é super interessada de que o sistema funcione, beleza? A segunda pessoa envolvida é você. é a pessoa que desenvolve o sistema, que preparou ele, que está fazendo aquilo acontecer. Beleza? Então a pessoa que codifica, está aqui, a segunda pessoa. Terceira pessoa que tem que se preocupar muito com esse sistema, operação. Ou seja, se você falhar, quem vai resolver? Tem que ter um time de operação ali para ter um contato telefônico, o que seja, e para resolver as coisas que você não pensou no sistema, ou aqueles casos muito críticos onde o próprio sistema capotou inteiro e não tem muito o que fazer. Então, aquele cenário caótico, a operação tem que estar aqui com a gente. E o último cara aqui que eu vou colocar, porque esse já está muito mais próximo dos times, é o run ou a sustentação. A sustentação também é super interessada porque ela está ali fazendo com que os projetos que você fez funcionem no dia a dia. Por que eu coloquei separado? Você pode estar pensando, poxa, na minha empresa já é junto. Sim, a gente já vai falar disso. Tem empresas que você tem o Build and Run junto. E é super importante. Normalmente isso funciona muito bem, é interessante. E eu concordo que deveria ser assim. Build and Run junto funciona muito. Ou seja, você codifica e você cuida da aplicação que você codificou. Então você não tem um time de sustentação. O próprio squad codifica e cuida. Ótimo, fácil. Muitas das squads já foram para isso. Se o seu time não foi, trata como quatro. Se o seu time já está junto, então são três grandes agentes. Você, time de negócio e time de operação. Fechou? Então você está falando aqui desses quatro agentes ou três, se ou três, se você já está fazendo esses dois pontos. Desses quatro agentes, como que eles se relacionam com o sistema? Como é que eles olham? Como que eles sabem quando está tendo problema, quando não está tendo problema? Quando você tem painéis de observabilidade, alertas, e todos estão sendo envolvidos na observabilidade do sistema, todos conseguem ser donos do sistema. Se não, só você, desenvolvedor, vai conseguir fazer. Você concorda? Se você não estiver dando formas das pessoas verem o que está acontecendo, como que elas vão poder compartilhar da responsabilidade com você? Então, quando você compartilha essa transparência, acessibilidade aos dashs, essa responsabilidade, as pessoas começam a olhar com muito mais cautela e começam a responder diferente ao que está acontecendo. Quando tem um problema, possivelmente essas pessoas já estavam acompanhando, essas pessoas são corresponsáveis e essas pessoas vão te ajudar a resolver, trazer uma colaboração gigantesca, tá bom? Eu queria encerrar com essa parte da colaboração porque ela é muito importante. Quando você tem um sistema observável por negócio e por operação, você vai criar uma parceria gigantesca com essa galera e você vai ver que a pressão do seu dia a dia começa a diminuir um pouco porque você compartilha com