Beleza, vamos observar aqui esse diagrama de sequência. É um diagrama de sequência de um e-commerce. Então, aqui a gente está representando diversas jornadas. A gente tem um registro logo no comecinho. A gente também tem a parte de login nem todas as jornadas elas estão completas aqui né aparentemente mas para a gente conseguir ilustrar aqui o nosso exemplo acho que funciona bem tá é só finalizando a gente tem a parte de login, faz a verificação checa se a conta existe ou não faz a verificação uma vez checado e estando certo existe o usuário a gente bate aqui num outro micro serviço pra validar as informações do produto, faz a busca num banco de dados, retorna com a informação, retorna para o microserviço aqui, Consumer, faz a compra do serviço, interagindo com esse microserviço de compra, e a gente tem aqui a parte do retorno, tem o pagamento envio de e-mail o produto é enviado e o a mensagem de produto enviado e o logout do usuário tá a gente pode quebrar esse esse desenho nessa jornada e a gente poderia ter várias outras jornadas, né? De repente a gente tem uma jornada só de compras, a gente tem uma jornada só de registro, a gente tem uma jornada só de cadastro de produto, né? Tudo isso são jornadas que o nosso software, o nosso produto, né? Vai oferecer. E o ideal é que a gente tenha SLOs em cima de cada uma dessas jornadas, tá? E que a gente também tenha os diagramas de sequência e faça ali os SLOs baseados nesses diagramas de sequência, tá? E por que isso é importante? Porque o SLO vai medir a jornada completa, né? Então, pensando aqui numa jornada, por exemplo, de compra, a comunicação entre todos os microserviços, se for uma jornada síncrona, todos os microserviços até o retorno. Então, beleza, a gente vai conseguir mensurar esse valor e vai conseguir ter a experiência ali, os valores da experiência dessa jornada em específica, mas a gente pode ter jornadas menores ali dentro, que é importante que a gente tenha também essa visibilidade. E quando a gente for montar os dashboards de SLI e tudo mais, a gente também conseguir ter o passo a passo, a interação de cada um desses serviços. Então, aqui por exemplo, a gente tem uma comunicação do microserviço de produto com o banco de dados. É importante a gente ter uma visibilidade só desse pedaço aqui também, porque muitas vezes o alerta que vier para a gente do SLO, ele vai vir e falar assim, puta, jornada tal está com problema, e aí a gente tem que começar a investigar ali e entender aonde pode estar o problema, né? Então, muitas vezes não está na jornada completa, está só num pedacinho. A gente tem que ter possibilidade de chegar nesse pedaço, nesse trecho que está com problema, né? esse pedaço, nesse trecho que está com problema. Então, imagina que a gente teve um total de 3.663.000 requests no mês. Desse total, 97% foram requests com sucesso. A gente teve um 90% de 432 e um 99% de 891 milissegundos, certo? A gente teve alguns SLOs estabelecidos, então a gente teve aí um SLO estabelecido, por exemplo, de 97%, uma latência para P90 de menor do que 450 milissegundos e para P99 menor que 900 milissegundos. Então, diante disso, a gente pode entender que a gente conseguiu estar dentro, né? A gente não teve o rompimento de nenhum dos SLOs que foi estabelecido nesse cenário específico. Tá? E o error budget de 30 dias, quando a gente fala aí do SLO de 97% de disponibilidade, a gente permitia até 109 mil falhas. Então, perceba, quando a gente fala de porcentagem, aqui a gente acabou tendo muitas requisições ao longo do mês, consequentemente, a gente acabou também tendo um valor razoável de falhas que a gente permitia. Falando de IP90 menor do que 450 milissegundos, nós tivemos, na verdade, a gente permitia até 366 mil requests, IP99 abaixo de 900 milissegundos para 36.632 requests. Então, pensando em um produto de altíssima resiliência, a gente sempre vai ter ali os diagramas de sequência bem estabelecidos, a gente vai ter SLOs bem definidos para as jornadas mais críticas, esses valores de 97%, P90, P99, são valores que estão dentro da razoabilidade ali do ponto de vista de experiência do usuário. Então, 900 milissegundos é bastante, tá bom, mas a gente está falando de um P99, né? A gente tem um desvio muito baixo que pode ficar ali acima desse tempo. Então, é importante que quando a gente estiver fazendo as definições desses SLOs, a gente consiga ter tudo isso em mente. definições desses SLOs a gente consiga ter tudo isso em mente pensando em ambientes novos muitas vezes acontece da gente não conseguir ter muito bem estabelecido essas métricas então a gente vai acabar se a gente realmente for um sistema totalmente novo a gente não tiver muito como mensurar esse tipo de coisa a gente pode ir ali com um P90 de 500 milissegundos, alguma coisa nesse sentido, ou vai adequando ali conforme faz mais sentido, e conforme vai entrando mais requisições, a gente vai conseguindo ter mais base de dados, a gente vai fazendo o refinamento desses SLOs, para que a gente consiga estar sempre o mais próximo possível, entregando a melhor experiência do usuário possível também. E para auxiliar na geração de métricas de SLO e Error Budget, também podemos nos apoiar em algumas ferramentas. Algumas aí open source, né? Tem o SLO Generator e o Slot. E pensando em ferramentas enterprise, a gente tem o Dynatrace e o Datadog. Eu particularmente tenho experiência mais com o SLO Generator e é uma ferramenta muito boa desenvolvida pelo Google a gente consegue rodar ela ali dentro dos clusters Kubernetes elas rodam como Chrome Job batem ali na nossa ferramenta de métricas, fazem a query com base nos contratos de SLI, e aí por baixo dos panos geram todas as métricas de SLO já calculadas com base no contrato, e a gente consegue fazer depois a consulta de todas essas métricas geradas e montar os dashboards, nosso grafano ali com as informações geradas por essas ferramentas. E falando das ferramentas Enterprise, é bem mais simples, a gente consegue ter módulos específicos para SLO, então acaba facilitando um pouco a vida. E aqui a gente também tem um vídeo de demonstração, onde é utilizado essa ferramenta, o SLO Generator, em um ambiente produtivo. Vamos dar uma olhadinha. Bom, eu abri o vídeo aqui. Vamos dar uma olhadinha em um ponto específico. Vamos dar uma olhadinha num ponto específico. Se a gente for ver aqui, a gente está basicamente abrindo um diagrama de sequência de uma das jornadas. Então, a gente tem aqui diversos microserviços, certo? E desses diversos microserviços a gente tem as interações entre eles e basicamente o SLO que a gente vai medir é o tempo total, no caso aqui essa jornada do discovery, né? Então bate todos esses microserviços, tem o retorno e a gente vai ter alguns SLOs em cima dessa jornada em específico. um retorno e a gente vai ter alguns SLOs em cima dessa jornada em específico. Se a gente der uma olhada aqui, a gente consegue ver o exemplo de um contrato, então é um contrato aqui como eu comentei da jornada do discovery ea gente tem algumas especificações nesse caso aqui a descrição está falando que é um a gente precisa ter um p90 né atingir que um p90 de até 500 milissegundos certo nessa jornada discovery, então a gente está falando de uma jornada de um SLO de latência. A gente está utilizando como exporter a ferramenta promissions e essa é a expressão. Se vocês forem dar uma olhada aqui é basicamente um PROMQL que está sendo executado, então a gente está pegando aqui uma métrica do GIM, que é gerado ali por uma aplicação Go, e fazendo a observação em cima de 500 milissegundos. Desses 500 milissegundos, a gente também consegue analisar na linha 34, que o nosso target, o nosso goal é 1,090. Então, aqui é onde representa o nosso SLO, de fato. Então, o que vai acontecer? Basicamente a ferramenta vai bater no Promifius, vai executar essa query, que é a query que está em expression, que basicamente é o nosso SLI. Então ele está pegando todas as requisições de até 500 milissegundos, que tem o status code 200 ou 400, e dividindo pelo total de requisições. Com base nisso, a gente vai conseguir saber qual foi o percentil de requisições dentro de 500 milissegundos e esse gol P90 vai ser calculado de acordo com a ferramenta. E se a gente avançar um pouquinho aqui, a gente também tem alguns dashboards, como eu comentei, relacionados aos SLIs. Então, para cada uma daquelas interações que a gente tinha dentro do diagrama de sequência, a gente tem aqui uma observação. Então, a gente tem um clique que bate num microserviço, esse microserviço que bate num outro microserviço, esse cara que bate num dynamo. Então, a gente destrinchou aquele SLO em diversas etapas e a gente consegue ter aqui também uma visibilidade do que está acontecendo da interação entre cada um dos micro serviços. Então, o que vai acontecer? Na simulação, a gente basicamente fez um teste de chaos, esse teste de chaos ele fez com que o nosso error budget fosse queimado a ponto de ficar totalmente, de ficar fora né, e a gente está olhando aqui numa janela de uma hora, então para a janela de uma hora a gente já estourou o nosso error budget estabelecido, não temos mais nenhuma margem, e aí nesse caso foi gerado alguns alertas, e a gente conseguiu ter ali o aviso de que essa jornada está com problema. E aí beleza, o que o time de SRE vai fazer? Vai entrar aqui nos dashboards, vai começar a analisar, tentar entender o que pode estar acontecendo, vai olhar a ferramenta de trace, vai olhar a ferramenta de log, e tentar entender ali qual pode ter sido a causa raiz para aquele problema em específico.