Fala galera, beleza? Vamos voltar aqui pra conversar um pouquinho. Agora vocês passaram aí pelas aulas com o Jaques, aposto que vocês estão adorando. O Jaques é um cara muito fera. Então, vamos retomar pra falar de algumas coisas numa visão um pouco mais estratégica de como a gente consegue implementar tudo isso que o Jaques está falando com vocês, tudo isso que a gente viu no hands-on, como que a gente vai fazer isso acontecer no dia-a-dia, tá? Então, eu fazer isso acontecer no dia a dia, tá? Então eu vou começar a colocar para vocês um conceito que é extremamente importante, que são os KPIs. Para quem não está acostumado nas grandes organizações ou nas organizações que estão mais evoluídas em processo normalmente, a gente trabalha com esse conceito. Quais são as chaves de resultado de performance que eu vou olhar? Então antes da gente aprofundar, só para vocês entenderem um pouquinho do porquê disso, quando a gente está falando de camadas de liderança, de decisões estratégicas, a gente tem o costume de olhar muito em indicador. Por quê? Tem uma máxima na administração, quando a gente está falando de gestão e etc., que fala que a gente não consegue gerenciar aquilo que a gente não consegue medir. Vou dar um exemplo. Imagina que na sua casa você precisa saber se você está ganhando mais dinheiro do que gastando. Se você não conseguir medir a sua conta corrente para saber se você está com mais dívida do que mais proventos entrando, mais grana entrando, dificilmente você vai conseguir gerenciar isso. Você não vai saber, vai ser meio que no tato que a gente fala. Você vai saber basicamente com base no que você está vendo ali no dia a dia, mas sem ter certeza daquilo que está acontecendo. Você não tem uma forma gerencial de ver aquilo. Então, por isso, quando a gente fala de dashboards gerenciais, a gente está falando de uma porrada de indicadores para a gente começar a entender como que as coisas estão funcionando. Bom, então, quando a gente está falando desse tipo de metodologia, desse tipo de pensamento, a gente utiliza os KPIs em conjunto com os OKRs. Ou seja, uma empresa vai lá, define quais são os seus objetivos-chave, ou seja, os OKRs estão dentro desses objetivos-chave, para com esses objetivos a gente descer para os times e os times começarem a entender quais são as chaves de performance de indicador do dia a dia, ou seja, o nível mais granular, como que aquilo vai conseguir ajudar a gente a atingir aqueles objetivos. Então, eu vou falar, não vou ficar aqui aprofundando muito no KPI, porque não é a ideia ensinar para vocês KPI. Depois, se vocês quiserem dar uma olhada, é importante, mas só para vocês terem uma ideia, esse é um nível granular que a gente desce para a gente tomar as decisões mais táticas ali no dia a dia de como a gente vai fazer as coisas. E saber conectar isso com observabilidade é o que vai fazer vocês conseguirem sair do outro lado. Então, quando a gente está falando dos conceitos aqui de uma aplicação observável, é super importante você conseguir conectar com o dia a dia, com a estratégia e com o negócio. Então, a gente vai começar a falar um pouquinho disso, tá bom? Então, antes de qualquer coisa, vamos falar sobre essas métricas-chave de desempenho, tá? Quando a gente está falando delas na observabilidade, elas vão ser extremamente importantes para a gente monitorar a saúde e o desempenho dos sistemas. Só que ela não garante só que os sistemas estão funcionando conforme o esperado. O que elas mais garantem é como que a gente vai conectar isso, essa visão técnica com os objetivos estratégicos daquele negócio. Se você não conseguir conectar, dificilmente você vai conseguir fazer o seu dia a dia acontecer. Então aqui a grande sacada dessa aula que a gente vai estar discutindo é, não adianta você saber tudo isso que a gente está ensinando, é de você saber implementar, se você não conseguir ter a habilidade de convencer e de explicar isso no dia a dia para um squad, para um time, para o seu chefe, para o seu líder de negócio e assim por diante. Como que você vai discutir com a sua estrutura que não é tão técnica que você precisa fazer isso? Você precisa conseguir conectar os mundos e acho que aqui é um grande papel que a gente como engenheiro de software, a gente como desenvolvedor tem que fazer, são essas conexões. Aquela ideia de um dev, de um engenheiro que só sabe codar, não existe mais. Agora você precisa ter todo um aparato de comunicação e de organização que precisa ser extremamente apurado para você conseguir fazer as coisas acontecerem. Tecnologia é extremamente complicado. Então, assim como um negócio tem que te explicar como as coisas funcionam para você poder desenvolver, você precisa conseguir conectar a tecnologia aos resultados de negócio. Então aqui a gente vai falar muito sobre isso, tá? Então como é que a gente implementa os KPIs certos, que podem transformar a maneira como a gente está entendendo o que está acontecendo, operando e conseguindo gerenciar, garantindo eficiência, resiliência a longo prazo daquela aplicação e no final daquele negócio. Então isso vai ser extremamente importante, tá bom? Vamos começar a entender um pouquinho mais disso aqui, tá? Quando a gente está falando dos QPIs na observabilidade, eles vão ajudar muito a gente a monitorar a saúde ali. Então, entender que quando a gente tem algum problema, antes dele virar um problema crítico que pode atrapalhar muitos objetivos de negócio, aqueles OKRs que eu falei. Então, como é que a gente vai trabalhar para monitorar o nosso sistema e não deixar ele impactar os nossos objetivos? Vou dar um exemplo básico só para a gente começar. Imagina que você está com o sistema de Marketplace e você não está monitorando, não tem nada disso aqui que a gente vai falar, que a gente já aprendeu com o Jacques, etc. Você não sabe monitorar, você não enxerga o que está acontecendo na sua aplicação. Aí chega no momento lá de uma Black Friday, momento onde você tem mais venda, onde o negócio está falando, agora é minha hora de ganhar dinheiro. E cai a aplicação porque você não conseguiu entender que tinha, sei lá, um tópico Kafka que estava ali enchendo de fila de mensagem e você não vai conseguir mais process aplicação apenas, você vai derrubar todo um objetivo de negócio de talvez um ano de trabalho, pra conseguir chegar naquela Black Friday, com os melhores preços, com as melhores parcerias e assim por diante, já gastou dinheiro com endomarketing, marketing, etc e vai acabar jogando tudo isso no lixo, porque você não monitorou olha como é importante. Quando a gente olha no dia a dia, nem sempre a gente conecta desse jeito. Muitas vezes a gente só traz que, poxa, aplicação, a gente precisa ter observabilidade, a gente precisa ter dashboard, não sei o quê. Quando você traz só de um jeito genérico, não conecta com essas pontas, dificilmente as pessoas vão entender a importância de você estar observando aquilo para não gerar este impacto, que daí sim é o que gera um baita de um trabalho para todo mundo no dia a dia. O impacto basicamente só em sistema pouca gente vai entender. E não é porque não deveriam entender, mas é o dia a dia. Nem sempre elas entendem, nem sempre todo mundo está no mesmo nível de conhecimento técnico que você. Então aqui a gente precisa fazer essas conexões, tá bom? Então uma outra ideia também é avaliar o desempenho das aplicações para a gente ver tempo de resposta, eficiência e assim por diante, para a gente ter uma melhor experiência de usuário. Que assim como o problema de estar totalmente fora, uma experiência ruim também pode te fazer perder muito dinheiro ali no dia a dia. Por exemplo, imagina que você está assistindo streaming, está tentando assistir alguma coisa na Netflix e ela não funciona. Você basicamente vai mudar para um outro programa de streaming e vai assistir outra coisa. Ele acabou de te perder. Se isso acontecer direto, você uma hora vai parar de assinar a Netflix, vai assinar um outro programa de streaming e assim por diante. Então você precisa estar ali sempre em alto nível para conseguir garantir esse desempenho. Uma outra coisa também é você alinhar as operações aos objetivos do negócio, ou seja, você conseguir conectar isso tudo que eu falei para vocês, ou seja, um tempo de resposta de um programa de streaming para uma experiência de usuário que pode acabar deixando a sua plataforma porque você não conseguiu dar aquela experiência que ele esperava, ou seja, você conectou com o objetivo possivelmente de engajamento que um programa de streaming tem. Até para quem está vendo aí, a maior parte dos programas de streaming está começando a colocar conteúdo de propaganda e assim por diante. Ou seja, para eles já começa a não valer apenas a mensalidade, eles já começam a colocar uma perspectiva de engajamento, parecido com o que as redes de TV faziam, o que as redes de TV fazem até hoje, elas precisam te deixar presos ali para você conseguir gerar outro tipo de grana para eles, que é de marketing e assim por diante. Ou seja, é um objetivo de negócio importante e interessante para quem está olhando streaming. E quando a gente está olhando para a observabilidade, precisa estar conectado, tá bom? Vamos lá. Quais são os tipos de KPIs comuns quando a gente está falando de observabilidade? Vamos falar primeiro dos detalhes do KPI e depois a gente vai começar a entender como conectar tudo isso. Tem vários tipos. E quando a gente está falando, um dos primeiros e mais vistos é o tempo de resposta. Então, quando a gente está falando de tempo de resposta, ele vai medir ali quando você tem uma solicitação, quanto tempo ela demora para responder. Eu vou dar um exemplo para vocês. Eu costumo fazer muito isso quando eu estou falando com times de negócio, quando a gente está falando com pessoas não técnicas. muito isso quando eu estou falando com times de negócio, quando a gente está falando com pessoas não técnicas. Se eu falar para você que uma aplicação demora 10 segundos para responder, isso é pouco ou é muito? Para você que trabalha com aplicações já, possivelmente você sabe se isso é pouco ou se é muito. Para alguém que não trabalha, essa pessoa não sabe. Ela não sabe se 10 segundos é pouco ou se 10 segundos é muito. 10 segundos parece pouco, certo? Agora quando você olha pra um tempo de espera de resposta de aplicação é ridiculamente grande é muito alto. Faz o seguinte eu costumo dizer o seguinte, se você acha que 10 segundos é rápido, vamos ficar aqui 10 segundos parados e quietos, sem falar nada durante uma reunião e começa a cronometrar quando você coloca isso, você vai ver que a galera já tem a tendência a querer pegar o celular, a querer se mexer, porque 10 segundos é muito tempo. Então você já se perdeu, você já não quer mais estar naquela conversa. Então 10 segundos não dá, não dá para falar sobre isso. Quando a gente está falando então de tempo de resposta, quando você vai falar com um líder de negócio, com alguém que não está acostumado, é legal você conseguir trazer essa visibilidade do que é um tempo de resposta longo e por que é importante a gente medir esse tempo? Porque se você não medir, você possivelmente vai perder o seu cliente para outra pessoa que está fazendo isso com mais velocidade e que tem uma experiência melhor e mais otimizada. Se você está falando de um streaming, poucos milissegundos já vão fazer você perder. Se você está falando de um sistema de contratação ou de consulta de algum tipo de saldo ou de consulta de uma plataforma como iFood para buscar comida, etc., você tem outros tempos de resposta que podem ser aceitáveis. É legal você discutir isso com todo mundo que está ali para decidir qual vai ser o seu objetivo de QPI aqui, o quanto vocês querem atingir de tempo de resposta para você conseguir colocar isso na sua observabilidade. A importância disso é que você vai conseguir ver ali a satisfação do usuário no final de uma experiência. Então, você vai conseguir saber se isso funcionou. E além disso, quando a gente está falando, por exemplo, de cloud, o gateway da AWS, se eu não me engano, ele está fechando ali uma comunicação em 30 segundos, acho que é alguma coisa assim, se eu não me engano. Faz tempo que eu não vejo qual que vem a configuração básica dele, normalmente eu trabalho com no máximo 15 segundos mas se eu não me engano, quando você faz o deploy dele, ele vem com 30 segundos, ou seja, se você passar de 30 segundos, você perde a conexão e nem tem mais a experiência pra medir, você não vai nem conseguir medir se o seu cliente gostou ou não, porque ele perdeu a sessão, já era, foi embora, você nem sabe se aquele cliente vai voltar. Então, tudo isso é extremamente importante, você está vendo? Para você trazer para os times, para vocês entenderem. Então, eu vou lá, de novo, um exemplo. Monitorar o tempo de resposta de uma API para garantir que ela responda em menos de 200 milissegundos. Se ela começar a responder mais de 200 milissegundos, você deveria subir um alerta pra falar olha, essa experiência já tá começando a gerar algum tipo de problema pro usuário. Possivelmente eu tô perdendo venda, eu tô perdendo clientes engajados e assim por diante, porque a minha experiência não tá tão boa. Isso é extremamente importante de pensar. Pra mim, 200 milissegundos é um bom tempo de se pensar ali pra ser o máximo da maior parte das coisas, a não ser que você tenha uma aplicação que tem que ser extremamente rápida. A minha aplicação hoje no meu time que é mais rápida e que precisa ter esse tempo de resposta é de 60 milissegundos em consulta de saldo. Então ela precisa ser super rápida e ela está conseguindo manter ali no P95 esses 60 milissegundos. Se ela passar de 100, ela já alarma, porque a gente já entendeu que mais do que 100 é ruim para esse tipo de experiência. Eu coloquei 200 aqui no exemplo, porque eu acho que 200 para a maior parte das aplicações vai funcionar. Algumas você pode até aceitar ir um pouco além, ser um pouco maior do que isso, e outras não. Sem contar que a gente pode até trabalhar com mensageria e com coisas assíncronas quando for possível, mas quando você precisa de resposta direta, é legal você pensar nesse tipo de QPI, tá bom? Outra coisa também que é uma coisa que a gente tem que olhar é a disponibilidade, tá? A disponibilidade também é normalmente mais conhecida e mais aceita pelos times quando a gente está discutindo. Que é o uptime, você pode ouvir desse jeito também, dependendo da roda de conversa que você tiver. E aqui quando a gente está falando dessa disponibilidade, é o quanto de tempo que o seu sistema está operacional. Ou seja, no 100% dele, pensa que você tem ali uma janela de tempo. Seu sistema é 24 por 7, ele está funcionando o tempo todo durante um mês. Dentro desse um mês, dentro dessas horas do mês, quantas horas ele ficou fora de serviço? Quantas horas ele ficou fora de serviço vai ser quanto de disponibilidade que ele ficou fora. Então, por exemplo, imagina que a gente precisa de uma disponibilidade de 99,99% em um serviço de pagamento online. Parece maluquice, né? 99,99%, eu não posso falhar. Mas quando você coloca no tempo, você vai ver que você vai acabar ficando um tempo aceitável fora do ar, com 0,01% de abertura pra você ficar fora do ar. Quando você tá falando de um pagamento online, um minuto fora do ar significa um minuto de estar sem vender. É como se você estivesse numa loja, lá na 25 de março, e na hora que tá no meio do Natal você fechasse a porta. É basicamente isso. Cara, tô aqui, tá tudo funcionando, eu vou fechar a porta aqui em 5 minutinhos. eu vou fechar a porta aqui em 5 minutinhos, só para ir ali comer um lanche no meio do Natal, você vai perder venda para caramba. Então, aqui é uma coisa que você tem que pensar que para o seu negócio é extremamente importante também. Taxa de erro também. Essa daqui também é normal do dia a dia, a gente acaba vendo bastante, que é o quanto que as suas requisições estão ali respondendo com algum tipo de erro. Então então te retornando alguma resposta de erro de API ou de erro de requisição e assim por diante não precisa ser API necessariamente, então aqui quando a gente está falando desse tipo de chamada quantas vezes eu peço alguma coisa e quantas vezes eu retorno um erro, então vou dar um exemplo aqui do da minha API lá, que eu falei agora de saldo pode ser um bom exemplo se eu faço 10 requisições e das 10, duas dão erro, eu já vou estar ali com 20% de falhas. Horrível, péssimo. Então, quanto mais requisições você tem, mais falhas você pode abrir ali, porque é percentual. Mas aqui, falando desse paralelo aqui, de 10 requisições, duas vai dar 20% de falha. Então, horrível uma aplicação que está muito ruim nesse cenário. Então, a gente precisa colocar quanto por cento de falha a gente suporta. Então, a taxa de erro, a taxa de vez que a sua API vai responder com algum tipo de problema. Então, aqui, por exemplo, monitorar a taxa de erro 500 no servidor web para identificar o problema e responder rapidamente. Pode ser esse caso, como eu falei, você está ali no seu app buscando o saldo e ele retorna algum tipo de erro 500. Isso vai gerar uma taxa de erro lá para você acompanhar também como KPI e garantir que ela não está aumentando. Porque, de novo, também quanto maior, pior a experiência do usuário. Uma outra também super importante, muita gente acaba deixando de lado, é a latência. É o tempo que uma solicitação leva para viajar da origem até o destino e retornar. A gente fala muito do tempo de uma API para responder, de uma aplicação, de um grupo de aplicações com banco de dados, etc. Mas as latências são extremamente importantes. Eu vou dar um exemplo de alguns tipos de latência que eu já tive que trabalhar. Eu já tive que trabalhar com uma aplicação que ela começava sua consulta aqui em São Paulo em uma AWS, ela estava em um ambiente cloud, AWS, saia desse ambiente cloud ainda em São Paulo e ia para outro ambiente cloud, e depois desse outro ambiente cloud ela ia para a North Virginia, lá nos Estados Unidos, aí desse ela ia lá para uma Azure, que eu não me lembro onde estava nos Estados Unidos esse servidor Azure. Então está vendo que ele teve três, três, uma, duas, três, três, quatro mudanças de ambiente. Nessas quatro mudanças de ambiente eu vou ter tempo de latência. Então tempo de latência do app do meu usuário até a minha cloud, beleza? Depois da minha cloud até a outra cloud de São Paulo, dois. Depois dessa para a terceira lá em North Virginia. E por último para a quarta lá na Microsoft. Todo esse tempo de latência, ou seja, o tempo que essa informação passa para ir de um lugar para o outro pela rede, vai ser um tempo que eu preciso controlar, preciso entender como é que está funcionando. Tempo aqui de... a gente pode falar de telecom, talvez. Eu preciso entender como é que está funcionando. Tempo aqui de... A gente pode falar de telecom, talvez. Esse tempo de telecom, ele tem que ser colocado na conta e eu preciso começar a entender se ele não está tendo nenhum tipo de ruído, nenhum tempo de demora, tá bom? Então, esse tipo de coisa é extremamente importante também porque vai compor para o usuário como um tempo total ali de resposta para o que ele está tentando acompanhar. Então, a latência de um provedor de serviço, eu coloquei aqui um exemplo, ela deveria estar ali garantindo abaixo de 50 milissegundos de um lugar para o outro. Na minha opinião, abaixo de 50 milissegundos ainda é muito alto dependendo do que você estiver falando. Você pode trabalhar com o CloudFront, com vários tipos de estratégia para você conseguir diminuir isso. Nesse caso que eu falei para vocês, usar 4 clouds era horrível, a arquitetura não estava das melhores então você pode trabalhar essa arquitetura também para simplificar e assim por diante então aqui são algumas ideias para você resolver mas vamos falar de observabilidade para observabilidade você tem que observar se essa latência está aumentando ou diminuindo para você tomar algum tipo de decisão algum tipo de estratégia até com seus servidores entender como é que você melhora isso, tá bom? que você melhora isso, tá bom? Outra coisa também é o throughput, ou seja, o quanto que você consegue entregar isso aqui. Tá bom, você está recebendo um monte de coisa, mas o quanto que a nossa aplicação aguenta moer. A gente costuma brincar assim quando a gente está falando do ambiente no dia a dia. Quanto que uma aplicação trabalha ali e consegue entregar. Ou seja, o quanto de dados eu consigo processar e transmitir em um determinado período. A importância é que, quando você tem sistemas que eles precisam processar grandes volumes, por exemplo, um marketplace, como eu falei, numa Black Friday, ele vai ter que processar grandes volumes. Um sistema de pagamentos, por exemplo, no iFood, tem que processar uma porrada de coisa ali no dia a dia. O de busca do iFood também, que você acaba buscando muito mais do que até pagando. Então, quando você está falando do throughput dessas aplicações, elas precisam ser muito altas. Você precisa ter um throughput que consiga resolver e responder tudo isso. Então, monitorar o throughput de uma plataforma de vídeo, por exemplo, ali sob demanda um streaming, para garantir se a entrega está sendo fluida e se o conteúdo está conseguindo rodar sem ficar travando, sem ficar parando durante picos de tráfego ali, quando você tem muita gente requisitando ao mesmo tempo, sei lá, lançou um Game of Thrones, Game of Thrones não, estou ficando velho né, lançou Casa do Dragão House of Dragons lançou um novo episódio ali, vai ter uma porrada de gente entrando, está bombando, talvez acabe estourando aqui o throughput das aplicações elas tem que conseguir aguentar respostas senão você vai ter ali uma experiência horrível para o usuário. Então aqui são alguns desses KPI's de observabilidade que a gente tem que ficar bem atento.