Bom pessoal, no vídeo anterior a gente falou de uma forma bem específica aí, tá? Sobre o que é, né? O que que o DevOps começou a ser transformado Ele acabou se tornando um cargo, uma área, uma área de especialistas Pra conseguir fazer isso funcionar Porém, o grande ponto é que apenas isso não era mais o suficiente, tá? Por quê? isso não era mais o suficiente, tá? Por quê? Porque chega num momento em que apenas fazer o build e deploy de um software garantir, né, ferramentas pra eu conseguir verificar quando alguma coisa tá com problema ou entender o comportamento desse cara, ele não é mais o suficiente. Porque a gente precisa aqui de algo que é chamado de reliability, né, ou confiabilidade. O que que isso significa? Como que eu consigo garantir que aquilo que eu estou fazendo é confiável? fazendo é confiável. No final do dia, o cliente, a empresa, ela não quer saber se o problema é de dev ou de infra. O que ela quer garantir é que aquilo esteja funcionando de uma forma confiável. Ou seja, ele quer garantir o funcionamento do software no ar de uma forma confiável. E para eu conseguir confiar nisso, eu preciso ter muita coisa ali emparelhada. E o que significa isso no final das contas? Significa que para eu ter mais confiabilidade, contas. Significa que pra eu ter mais confiabilidade, eu preciso ter métricas claras do que é considerado um software confiável. Legal? Porque um software confiável, ele pode ser um software que, se ele ficar uma hora fora do ar por mês, ainda assim ele é confiável, porque ele não afeta, ele não é tão crítico. Agora, o Google, ele não pode ficar um segundo fora do ar, porque se você der google.com ou digitar na sua barra de endereço, essa parada tem que funcionar. Então, se você começa a perceber, o nível do que é considerado confiabilidade, ele muda muitas vezes de acordo com a criticidade do software. Então, eu preciso ter métricas claras do que é confiável, porque eu tenho que conseguir balancear custo e benefício. Eu não vou gastar um milhão de reais para colocar um servidor em todas as zonas de disponibilidade de um cloud provider, e botar isso tudo multiregião, com bancos de dados dobrados em todos os lugares, para garantir o máximo de disponibilidade possível de um software que 10 pessoas vão utilizar. Então, a gente precisa ter esse balanceamento. Uma vez que a gente tem esse balanceamento, eu começo a criar o quê? Objetivos. O que são objetivos? É garantir disponibilidade do software aqui para a gente. E eu começo a ter acordos com clientes com essa garantia. Ou seja, é um acordo para dar garantias que isso esteja funcionando. Agora, sabe aquela parada? Se eu falo que o meu software para o meu cliente, que ele pode ficar uma hora por mês fora do ar, eu não vou colocar o meu objetivo de deixar e criar processos pra que esse software, ele garanta que ele vai ficar apenas uma hora fora do ar. Por quê? Porque se o meu objetivo for igual ao meu acordo, eu tô bem ferrado, porque eu preciso agir mais rápido. Então, normalmente, o meu objetivo acaba sendo sempre menor, maior do que os clientes. Então, se aqui eu posso ficar uma hora fora do ar, na realidade aqui eu vou colocar 30 minutos. E o acordo com o meu cliente, aqui eu vou colocar uma hora fora do ar, na realidade aqui eu vou colocar 30 minutos. E o acordo com o meu cliente, aqui eu vou colocar uma hora. Então, o meu objetivo é sempre conseguir bater esse cara aqui. Então, aqui a gente começa a falar de algo que a gente chama de SLO, Service Level Objectives, tá? E aqui a gente começa a falar de SLA, Service Level Agreement. Agora, o grande ponto aqui é, cada vez que o meu software cai do ar, eu tenho um orçamento. E o orçamento não é de dinheiro. Na realidade, é como se fosse créditos. Então, por exemplo, se eu combinei que o meu software pode ficar uma hora fora do ar por mês, e daí, de repente, o meu software tá 20 minutos fora do ar por mês, isso significa que agora eu só posso ficar mais 40 minutos fora do ar, né? Então, isso aqui, né, um budget, ou um error budget, né, isso aqui significa o quê? Que através de métricas e definições, eu posso falar, é a partir disso aqui que eu tenho que trabalhar agora. Se eu já tive um problema, esse problema tem que ser sanado. E em diversos momentos também, a gente começa a ter outras métricas que vão começar a validar o funcionamento do software desde o desenvolvimento, do tempo de desenvolvimento até ele estar em produção, ou do tempo em que o software caiu do ar até esse software voltar a funcionar, o tempo entre um problema acontecer e eu descobrir a causa que esse erro aconteceu, ou o tempo e eu descobrir a causa que esse erro aconteceu ou o tempo de eu descobrir de conseguir fazer a resolução desse tipo de bug. Então, se você olhar aqui, aqui a gente está muito mais focado em garantir que isso esteja funcionando, independente de qualquer coisa. O que que isso quer? Independente de qualquer coisa. Eu vou deixar uma coisa bem clara aqui. Vamos imaginar que eu tenho um software aqui pra mim. Então eu tenho o meu programa, o meu service. E aqui eu tenho um gateway de pagamento. Certo? Esse meu software, ele está funcionando bem. Ele manda as transações pro gateway de pagamento. O que que acontece aqui? Esse gateway de pagamento. O que acontece aqui? Esse gateway de pagamento, ele sai do ar. O que acontece? Esse meu software não consegue trabalhar da forma como ele deveria e vai trazer prejuízo para a empresa. E a minha pergunta aqui é, de quem é a culpa? Muita gente vai falar do sistema de pagamento. Mas na realidade, a culpa é da empresa. Por quê? Porque o cliente dela não quer saber que o problema está com a Cefaz, que a nota não foi emitida, ela não quer saber se o problema tá com o Paypal que não conseguiu processar o pagamento o que o cliente tá preocupado é se o negócio está funcionando, então isso aqui começa a sair das mãos de quem desenvolve e às vezes acaba indo pra terceiros e quando isso acontece a gente acaba ficando de mãos atadas de quem desenvolve e às vezes acaba indo para terceiros. E quando isso acontece, a gente acaba ficando de mãos atadas. A pessoa ou a área, principalmente a área de confiabilidade, que é o que a gente chama de SRE, que é Site Reliability Engineers, o que eles acabam fazendo? que é Site Reliability Engineers, o que eles acabam fazendo? Eles começam a falar o seguinte, se esse problema está acontecendo e gera problema de confiabilidade no meu software, como que eu resolvo isso? E daí essa área vai estudar esses problemas, vai estudar esses incidentes, vai entender tudo que está acontecendo e vai falar. Por exemplo, quando um cara tiver problema, vai para o outro cara. Usa dois gateways, então. Ou seja, a gente começa a ter áreas focadas em garantir que quando algo de ruim aconteça, eu não coloque culpa. Ou seja, quando a gente está falando de SRE, não existe mais culpa. O que existe é processos e entendimentos dos problemas. Não tem sujeira embaixo do tapete. O meu objetivo é garantir as coisas funcionando. E isso é independente se é um sistema de terceiro, se é o meu data center, se foi um Google, uma AWS que caiu e daí eu fiquei fora do ar e mesmo assim eu estou pagando. Vamos imaginar que eu tenho um servidor, ele está rodando na AWS, aquela zona de disponibilidade ficou fora, o meu sistema caiu. Daí o cara de SR vai falar, poxa, deu problema de zona de disponibilidade, mesmo na AWS. Vamos botar em duas zonas de disponibilidade. Aí, deu problema nas duas. O que eu vou fazer? Ok, eu vou trabalhar multiregião, porque se aquela região deu problema, eu tenho outro problema. Cada trabalhar multiregião, porque se aquela região deu problema, eu tenho outro problema. Cada vez que você vai criando mais esses tipos, mais caro as coisas vão ficando. Mas eu vou conseguindo aumentar o nível de confiabilidade. Então a área de SRE ela não está preocupada com quem errou. Ela está preocupada em como fazer com que isso não aconteça de novo. E por isso que a área de SRE, de forma geral, ela olha isso aqui de uma forma muito clara. Ela olha muito isso aqui de uma forma muito clara. Mas perceba que o objetivo da área de SRE é outro, é garantir confiabilidade. E para garantir confiabilidade, eu tenho que fazer com que esse processo aqui, toda essa parte aqui, funcione muito bem. Então, a área de SRE acaba trabalhando muito em conjunto com as práticas de DevOps. E é por isso que muita gente mistura DevOps e SRE porque, invariavelmente, a área de SRE ela tem que entender todo esse processo de DevOps e fazer com que o tempo de recuperação seja menor, fazer com que o tempo de descoberto de uma falha seja menor, porque o objetivo dele é garantir a confiabilidade. Então, normalmente, a galera de SRE, ela entende muito bem, tanto dessa área, mas ela tem um objetivo mais abrangente do que fazer isso aqui. O objetivo e a abrangência dela é o quê? Fazer com que as coisas funcionem independente de onde o problema, de onde o problema aconteceu. Então aí nesse momento a gente entra e acaba entendendo mais sobre SRE. E aí a gente começa a ter práticas, ferramentas, para que se eu tive um problema na minha infraestrutura, eu consigo subir essa infraestrutura rapidamente em um outro lugar. Como que eu faço isso? Poxa, se eu conseguisse deixar a minha infraestrutura muito mais declarativa, com um clique eu subiria a minha infraestrutura inteira. Opa, vamos criar uma ferramenta, talvez, chamada Terraform, que eu consiga ter uma infraestrutura como código. Então, tudo isso ajuda o quê? A mitigar problemas de confiabilidade. Então, o DevOps é apenas mais uma área que a área de SRE tem que estar ciente. Mas a área de SRE acaba englobando qualquer área da empresa que possa gerar problemas de confiabilidade. Então, essa que é a grande sacada, então, quando a gente tá falando de SRE. Fechou? Pessoal, essa introdução que eu acabei de dar aqui é muito mais pra nivelar você do que trazer ferramentas e fazer um monte de coisa aqui. Quando a gente estiver no evento da Full Cycle Tech Week for Seniors, a gente vai trabalhar de uma forma mais prática, de uma forma mais clara, a gente vai falar de tooling, a gente vai falar de processos e tudo mais, mas sem essa base, essa introdução, acabava ficando um pouco mais difícil para a gente aproveitar melhor o evento. Então, eu espero que você tenha entendido isso que eu acabei de falar, tá? Pra que nós pudéssemos aproveitar melhor o nosso evento. Então, assista isso, né? Garanta que esses conceitos eles fiquem claros pra você pra que no evento a gente consiga aproveitar ao máximo e gerar Garanta que esses conceitos, eles fiquem claros pra você, pra que no evento a gente consiga aproveitar ao máximo e gerar muita troca aí de figurinhas, tá bom? Então, um grande abraço e lembrando, tá? Participe de todos os dias do evento. Vai ter um nível de pessoalidade muito grande. A gente vai conseguir fazer muita coisa legal. Fechou? Abração e até o nosso evento da Full Cycle Tech Week for Seniors.