Iniciando agora o módulo de Site Reliability Engineering, SRE, Princípios e Práticas. Bom, nesse módulo falaremos com mais profundidade sobre os princípios, então passaremos sobre a questão de operação como um software, objetivos de nível de serviço, software, objetivos de nível de serviço, redução de TOEIL, automação, reduzir o custo de falha, responsabilidade compartilhada e também sobre algumas práticas, como observabilidade, on-call e resposta a incidentes, post-mortem e root cause analysis, testes, capacity planning, desenvolvimento e produto. Bom, alguns desses pilares, quando a gente fala aqui de princípios e práticas, a gente já acabou comentando, falando bastante sobre alguns assuntos como automação, a gente chegou a falar bastante também sobre responsabilidade compartilhada, citamos bastante também a questão das práticas de teste, desenvolvimento, então alguns desses pilares eu vou acabar não me estendendo muito até para não ficar tão repetitivo tá em alguns outros a gente vai acabar dando um pouco mais de foco então quando a gente fala aqui de objetivos de nível de serviço, passaremos por a definição de SLI, SLO, SLA, Error Budget, Política de Consequência. Vamos deixar um pouco mais azeitado aí essa questão conceitual do que é TOEI ou do que não é. Vou falar bastante aqui também sobre algumas práticas relacionadas a Oncall. A gente vai falar com mais profundidade mais pra frente sobre observabilidade, explorando um pouco mais cada um dos pilares. Capacity Planning é a mesma coisa, né, pós-mortem também vai ter alguns use cases pra gente passar. Então, espero que vocês gostem aí do que tem por vir compreender e medir os comportamentos essenciais de um serviço é fundamental para gerenciar eficientemente isso envolve definir e cumprir um nível de serviço para os usuários, através de SLIs, SLOs e SLAs. Essas métricas indicam o que é importante, os objetivos desejados e como reagir caso o serviço não atenda as expectativas. Escolher as métricas certas permite ações corretivas adequadas e dá confiança à equipe de SRE na integridade do serviço. adequadas e dá confiança à equipe de SRE na integridade do serviço. As principais responsabilidades dos SREs não são apenas automatizar todas as coisas e manter o ambiente de operações. As tarefas e projetos diários são conduzidos pelos SLOs, garantindo que os SLOs são defendidos a curto prazo e que podem ser mantidos a médio e longo prazo. Podemos até afirmar que sem os SLOs não há necessidade de SREs. Uma coisa que é de suma importância vocês terem em mente é que os SLOs são uma métrica mais gerencial, vamos dizer assim, e que está intimamente relacionado à experiência do usuário. Então, a gente pode afirmar que se um SLO está sendo atendido, teoricamente esse usuário ou usuário final, consumidor desse serviço, ele está feliz. E se o SLO não está sendo atendido, significa muitas vezes, do ponto de vista operacional, não de funcionalidade, que esse usuário não está feliz. Quando a gente fala de SLOs, todos os produtos, ou cada produto, vai ter diversos SLOs. a gente vai ver um pouquinho mais para frente mas eu particularmente gosto de traçar esses SLOs com base nas jornadas tá bom vamos definir aqui um pouquinho melhor cada um desses nomes. SLIs são os indicadores, então são as métricas que são utilizadas para qualificar o desempenho ou a qualidade de um serviço, como latência, disponibilidade, durabilidade ou taxa de transferência. O que que seria um SLI? A gente poderia estar falando que um SLI, por exemplo, é uma quantidade de chamada GRPC concluída com sucesso e que esteja abaixo de 100 milissegundos, por exemplo. Então, a gente estaria falando de um SLI mais relacionado à latência. Então, a gente estaria falando de um SLI mais relacionado à latência. Uma outra possibilidade seria a gente medir, por exemplo, a quantidade de solicitações HTTP com sucesso. E aí já seria, por exemplo, um SLI mais relacionado à disponibilidade. E assim vai, a gente consegue definir diversos SLIs. O que é importante vocês entenderem é que basicamente o SLI vai ser uma métrica que a gente vai utilizar para poder fazer os cálculos dos SLOs. Então o SLI está muito mais voltado para uma métrica técnica, para um mundo mais técnico, diferente do SLO. Beleza, então o que são de fato esses SLOs? Os SLOs são metas do quão bem um produto ou serviço deve operar. metas do quão bem um produto ou serviço deve operar. Então, por exemplo, 99,5% de disponibilidade da API de consulta ao saldo. Certo? Uma coisa que é importante, tá? Esses SLOs, nesse exemplo, por exemplo, a gente sempre vai observar sobre algum período... Esse SLO sempre vai estar sobre um período de observação. Então geralmente a gente tem ali SLOs de uma hora, certo? Que são SLOs que a gente utiliza para fazer uma observabilidade, entender se a gente está, de repente, com algum problema, a gente conseguir ter uma resposta mais rápida. E a gente também tem os SLOs de 30 dias ou 4 semanas, que seriam os SLOs mais utilizados ali, mais voltados para KPIs, para a gente conseguir mensurar, por exemplo, se um serviço está indo bem ou está indo mal, se ele é resiliente, se ele não é, se vem causando algum transtorno do ponto de vista operacional ou não. E os SLAs? Os SLAs é o que a gente já conhece, já é mais famoso aí no nosso universo, é um acordo formal entre o provedor de serviços e seus clientes. Não atendendo, geralmente existe alguma multa, alguma questão contratual onde a empresa tem que cumprir, mas nada de muito novo. Uma coisa que dá para observar aqui é que quando a gente fala do SLA, a nossa meta é 99,7. Quando a gente está falando do SLO, a meta aqui foi para 99,5. Então, é uma meta que é um pouquinho menor. E a gente pode entender que o SLO é uma meta interna. Não é uma meta para fora, é uma meta mais interna para a gente medir a qualidade do serviço que a gente está prestando. Beleza, junto com essa sopa de letrinhas a gente também tem o error budget, que é a quantidade tolerada de desvios de um determinado período de tempo sem comprometer os objetivos do serviço. Então, o que isso quer dizer? Dependendo da sua meta, você vai ter um budget maior ou menor para você queimar durante o período de observação. O que eu quero dizer com isso? quero dizer com isso? Puts, eu tenho um SLO super agressivo de 99,8, de 99,9, por exemplo, e o SLA é 99,99, por exemplo. Pô, quanto mais perto dos 100%, menos tolerância a falha a gente tem, né? Então, o que eu quero dizer com isso? Pô, se a gente estabelecer, por exemplo, um SLO de disponibilidade, de, sei lá, de uma jornada de compras, né? De algum e-commerce, alguma coisa nesse sentido. E essa jornada for de 99,9 e a gente tiver ali uma hora, duas horas de indisponibilidade no mês, isso já pode ser o suficiente para a gente ter alguma política de consequência acontecendo, que inclusive é o próximo item aqui que eu vou comentar, que são diretrizes ou políticas estabelecidas para determinar as consequências de exceder esse error budget. Então, nesse caso, o que a gente pode estar comentando aqui? Nesse mesmo exemplo, eu tenho um SLO de 99,9, eu acabei excedendo, fiz uma mudança ali e gerei uma indisponibilidade de uma hora, uma indisponibilidade não planejada de uma hora no meu ambiente, consequentemente eu vou passar por uma política de consequência que pode ser eu não fazer mais implementações dentro daquele período estipulado. Isso pode ser uma política de consequência. Ou, de repente, sei lá, eu conseguia fazer as minhas GMUDs ali todas sem passar por nenhum tipo de CAB ou sem passar por nenhum tipo de revisão, por review de algum engenheiro mais sênior dentro da empresa e a partir de então eu vou ter que passar sei lá, pelos próximos três meses, alguma coisa nesse sentido então, dependendo da criticidade do ambiente de quão rigoroso foi o nosso SLU ou não, do quanto a gente extrapolou esse hurd budget ou não, a gente pode ir determinando ali também algumas políticas de consequência relacionadas a isso.