Bom pessoal, seguinte, então vamos começar oficialmente hoje o nosso terceiro dia, tá? Primeiro dia a gente falou bastante aí de System Design. No segundo dia, obviamente, a gente também focou bastante na parte de System Design, mas eu acredito que o grande foco de ontem, né? No nosso segundo dia, foi falar também um pouco sobre comunicação entre sistemas, né? Eu achei bem bacana também porque a Samira, ela trabalha com a gente na área de vendas. E alguém falou com a Samira? Já falou com a Samira em algum momento aqui? Alguém falou com a Samira? Já falou com a Samira em algum momento aqui? Então, ela encaminhou uma mensagem para mim via WhatsApp falando Wesley, tem uma pessoa que participou da semana, eu estava conversando com ela, não sei se ela, acho que estava contratando o nosso MBA, e o cara me encaminhou um paper exatamente fazendo a comparação de REST, GraphQL e GRPC. Depois, a Leonan me lembra, eu vou compartilhar com vocês. Tem vários papers desses na realidade, mas eu vou compartilhar aqui com vocês o paper. Eu achei bem legal alguns aspectos, algumas comparações que eles fizeram, tá? Então, aí ó, o Ricardo, foi o Ricardo que compartilhou. Show, Ricardo! Valeu aí pelo paper que você mandou aí pra nós, tá? Então, só querendo fazer menção aí, e pra você ver como é que a nossa equipe se fala internamente, tá, Ricardo? Se tivesse me xingado, ela ia falar também, viu? Bom, então é o seguinte, ontem a gente focou bastante nessa parte de comunicação, né? E também a gente pegou aquele System Design e a gente simplificou. Eu acho que a ideia principal ali era conseguir vocês terem uma ideia mais clara de System Design, isso te ajuda no dia a dia, tanto na empresa que você trabalha, pra você pensar nas soluções de uma forma mais geral. para você pensar nas soluções de uma forma mais geral. Obviamente, não dá para fazer em pouco tempo um curso, vamos dizer, de System Design de uma forma tão específica, porque tem muitos detalhes, tanto na parte de System Design como na parte de Design Docs. Obviamente, aproveitando e fazendo o Jabá, quem quiser saber mais sobre esse assunto, o nosso MBA tem, tá? Inclusive, tem aula comigo, tem aula com o Fabian Rezenkamp, que é um software engineer da Microsoft, e tem também aula com o Fernando Costa, que também trabalha na área de arquitetura de solução na Google. Então, assim, são vídeos bem bacanas, com nível de profundidade bem legal também, depois para quem quiser conseguir se aprofundar mais sobre esse assunto. Mas, independente disso que a gente viu nos dias de hoje, hoje é um dia que eu quero dar uma mergulhada para vocês conseguirem ter uma visão geral da área de DevOps e SRE. Quem aqui trabalha nessa área hoje em dia? Faz assim com o joinha como participante aí. Deixa eu colocar aqui só para eu ver. Tem uma paradinha aqui que dá para ver os participantes. O Adriano. Quem aí trabalha com o DevOps de forma geral, tá? E quem aí trabalha com SRE, na área de SRE. Ali, ó. Aí, ó, acabei de ver um cara muito bonito que levantou a mão agora aí. Espera um pouquinho. Esse cara tem que poder falar aqui. Tá? Espera um pouquinho que ele tem que aparecer aí. Ô, Leonan. Oi. Libera o microfone aí do Fernando. Tá, olha. Tenho certeza que eu acabei de ver a cara dele aí. Tá? E, galera, é muito louco essas coisas, né? Ontem o Fernando, ele mandou um print. O Fernando Costa da Google, que, inclusive, eu acabei de falar dele agora, né? Ontem o Fernando, ele mandou um print, o Fernando é o Fernando Costa da Google, que inclusive eu acabei de falar dele agora, né? E ontem eu falando sobre System Design, ele mandou um print que ele tava aqui assistindo, daí eu falando, cara, fico até constrangido, né, de você tá assistindo uma aula minha de System Design, sendo que você é o cara que faz o dia inteiro System design na Google pra tudo quanto é tipo de cliente, né? Então, e também manja pra caramba dessa área de SRE. Mas eu acho que o maior ponto que a gente tem que pensar aqui hoje, inclusive introduzindo nessa área, que dá pra perceber que a maioria das pessoas aqui não são dessa área ou não trabalham diretamente com isso, e eu acredito que muitos de vocês já ouviram falar no termo, pelo menos ou tem aquela noção mais ou menos sobre aquilo ali. Então a grande pegada aqui que eu quero trazer pra vocês é o seguinte, galera quem aqui sabe a diferença entre DevOps e SRE? Se você souber, coloca um joinha pra cima, ali na mãozinha do Zoom. Se você não souber, coloca joinha pra baixo. Se você sabe mais ou menos, coloca joinha pra baixo, tá? Só pra garantir. E galera, libera aí as câmeras, tá? Pra não ficar com um monte de tela preta aí, tem um monte de cara bonita, um monte de tela preta aí tem um monte de cara bonito, um monte de gente bonita aí tá eu tô aqui no escuro porque eu ah, ali ó, ó quem tá aí ó aí galera, esse eu fico envergonhado de ter que falar sobre system design, devops, sre perto desse cara aí bonito entendeu? aprendi tudo com você aham, aham aí galera, só pra vocês saberem esse é o Fernando. Cara, um dos caras que eu tenho, sabe aquele tipo de pessoa que você tem, que você fala assim, Deus, muito obrigado por ter me apresentado a essa pessoa, porque o cara faz uma diferença danada na sua vida e na vida de várias pessoas que você conhece. Esse é o cara aí, galera, tá? Então, esse é o Fernando, apresentado pra todo mundo. Prazer. Eu quero aqui colaborar com o que você falou ontem. Me chamou muita atenção te parabenizar pela sua aula de ontem. Fiquei metade da aula, tive que sair que eu tive um compromisso. Foi espetacular. As dicas que você deu, que você falou para as pessoas, o que elas teriam que prestar atenção nas entrevistas dos providers, dos vendors sobre system design, aonde que estão as dores, quais são as perguntas, as pegadinhas, o que acontece. Aquele é o caminho, gente. Desculpa até falar do carro, tá? Eu não queria perder a oportunidade de acessar o cara tá com a montanha em fogo, entendeu é, tô saindo do escritório agora e mas foi ótimo e foi, cara muito alinhado ao que a gente vê então, cara, parabéns aí pela aula de ontem que você deu, viu cara, foi ótimo agora eu vim escutar sobre SRE, né? Espero não decepcionar. Apesar de que a última vez que eu tive uma aula de SRE foi quando o Fernando me apresentou um cara de SRE da Google que toma conta simplesmente do google.com. Então dá para ter tido uma aula boa com os caras aquele dia também, né? Mas show de bola, galera. Então, o seguinte, quem perguntou, quem é esse cara, né? O Jorge perguntou. Esse cara é o Fernando Costa. Hoje, ele trabalha na Google na área de... na área de arquitetura e de solução de forma geral, né, ô Fernando? É, eu sou Customer Engineer. Então eu faço engenharia para vários clientes no Brasil. Atendo, já fiz, terceiro meu, tô indo pro quarto ano no Google, né, então eu faço isso pra, fiz isso pra várias empresas que a gente chama de corporate, agora eu atendo dois tipos de indústrias que são de financial. E fora isso, eu sou co-líder da disciplina de SRE pra América Latina. Então, eu falo de SRE com muitas empresas, sobre implementações de SRE, dores de SRE, como que as pessoas vêm vendo a mudança de SRE com o tema de IA também, né? Mas meu papel hoje aqui é assistir a aula. Então, galera, vocês entendem o que eu tô querendo dizer? A posição que eu tô aqui nesse momento pra querer falar de SRE, vocês conseguem compreender a parada, né? Mas eu vou tentar não decepcionar, tá? Então é o seguinte, pessoal. Valeu, Fernando, cara. E interrompa a hora que você quiser, meu amigo, tá? Interrompa, inclusive, para corrigir, se você quiser. Galera, seguinte, tá? Muita gente, hoje em dia, acaba ouvindo muito falar nesses termos. DevOps, SRE. O que, entre aspas, me deixa um pouco triste é muita gente colocar essas duas coisas exatamente no mesmo balaio como se fossem a mesma coisa. E não é. Apesar de ter uma zona que essas coisas estão trabalhando em conjunto, a visão de cada uma delas é completamente diferente. E quando eu falo completamente, é por uma questão principalmente de foco. Então, a nossa ideia hoje é a gente conseguir e trazer pra vocês os principais conceitos de DevOps. Eu sei que provavelmente muita gente aqui já ouviu falar de DevOps, pode ter uma ideia mais ou menos do que é, mas o grande ponto é que o que eu vejo muito é quando a gente sabe muito as coisas de ouvir falar ou não entende de uma forma tão clara um conceito ou outro e eu acho que a pior coisa que existe na realidade é quando você senta numa mesa e alguém fala de um assunto que você nunca ouviu falar. Daí você fala, ok, tá tudo bem, isso é normal, acontece comigo o tempo inteiro. Mas depois, as pessoas naquela mesma mesa, elas falam de um outro assunto, e daí você fala, eu não ouvi falar. Delas começam a falar de um outro assunto que você ouviu falar, mas você não tá entendendo absolutamente nada do assunto que você pensou que você sabia. Então, a minha ideia aqui não é, hoje, querer dar todos os detalhes do mundo sobre o que é DevOps, o que é SRE, todas as métricas, e como que as coisas funcionam, etc. Mas eu quero que, a partir de hoje, vocês consigam sentar na mesa e, pelo pelo menos não passar vergonha, vamos dizer assim. Eu acho que esses conceitos, se vocês entenderem, eu acredito que eles já geram, conseguem gerar para vocês até com uma linha um pouco mais linear de entendimento sobre esses aspectos. Então, a nossa ideia hoje aqui é a gente falar sobre DevOps, a gente vai falar aqui é a gente falar sobre DevOps, a gente vai falar um pouquinho de aquela história toda de cultura, cargo, a história do CALMS, eu não sei se vocês já ouviram falar. A gente vai também discutir um pouquinho sobre DevSecOps, que eu acredito que muita gente já ouviu falar também, mas acaba não entendendo quando começam a surgir algumas palavrinhas como SAST, DAST, YAST e coisas desse tipo. A gente também vai falar um pouco sobre infraestrutura como código, InfraScode. Nós vamos falar também de algumas ferramentas e algumas práticas e depois nós vamos ali para o mundo do SRE. e algumas práticas e depois nós vamos ali pro mundo do SRE, tá? Quando a gente for falar do mundo do SRE vocês vão entender uma ideia do que é o SRE os principais os principais princípios, ficou bonito, né? Os componentes que a gente considera chave, principalmente indicadores de serviços que é, inclusive, provavelmente é uma das coisas que o Fernando acaba trabalhando muito e entender a ideia acaba sendo simples. O problema é conseguir implementar ainda mais quando você está em grandes empresas, tá? Depois disso, a gente vai entender um pouco mais como que isso pode ajudar, quais são os principais desafios que você consegue encontrar nisso, qual que é o papel de você desenvolvedor se um dia você quiser trabalhar nessa área tá, quais são métricas que são importantes pra você ter noção a gente vai falar também sobre DoraMetrics, não sei se vocês já ouviram falar, quem aqui já ouviu falar em DoraMetrics ou entende o que é essa parada levanta a mãozinha, sempre quando eu perguntar, galera, mãozinha pra cima ou pra baixo, ali nos participantes ali do Zoom, que daí fica fácil de eu conseguir olhar, tá? E quando não souber, coloca a mãozinha pra baixo também, não tem problema nenhum. E a gente vai falar um pouco sobre a DoraMetrics também. Então, assim, galera, é um conteúdo denso, tá? É um conteúdo de forma geral que traz muito conceito. Tá? Então, se você tá aqui atrás de ferramenta e vê um monte de telinha, eu digo pra você que hoje você não tá no lugar certo. Mas se você quiser entender fundamentos de coisas que são importantes para que quando você consiga querer dar os passos nessa área, ou quando você estiver numa entrevista, ou quando você estiver conversando com outros times de outras áreas, você conseguir ter esses fundamentos, eu acho que esse é o principal ponto. Tem muita coisa que eu sempre estou repetindo, principalmente nesses últimos tempos, quando a gente está falando sobre IA, galera. O fato é que a geração de código, a programação de forma geral, como ela era antes, a coisa vai acabar da forma como a gente conhece. Aqueles montes de código que a gente gastava, aqueles tempos para fazer os crudes, aquelas implementações, aquele tempo gigante que você passava o dia inteiro para criar um monte de teste automatizado, esse mundo vai acabar. Porque essas paradas todas vão ser e já estão sendo geradas por IA. Eu não quero entrar, inclusive, nessas discussões que se o programador vai acabar e não sei o quê. O fato é que a forma de como a gente programa hoje já mudou e vai mudar de uma forma muito mais forte ainda e que a gente programa hoje já mudou e vai mudar de uma forma muito mais forte ainda e que a gente nem sabe como e esse aí é o grande ponto, agora no que então a gente tem que se preocupar no final das contas é pra você implementar qualquer coisa você tem que entender o que tá por trás, você tem que entender o que está por trás. Você tem que entender os conceitos. Se eu chegar para uma inteligência artificial hoje e falar cria um sistema que faça um gerenciamento de compras de ingressos. Todo mundo é desenvolvedor aqui e sabe que a gente pode trabalhar com um trilhão de linguagens, a gente pode trabalhar com um trilhão de bancos de dados diferentes, a gente pode trabalhar com um trilhão de linguagens, a gente pode trabalhar com um trilhão de bancos de dados diferentes, a gente pode trabalhar com um trilhão de tipos de arquitetura e de tudo quanto é jeito. O ponto é que aquele software de A, ele vai fazer de um jeito. Você pode ir tentando pilotar, mas a grande sacada é que o que por trás daquilo que ela está gerando, além de raciocínio que ela está trabalhando ali, está vindo entre aspas dela. Qual é o grande problema com isso? Se você não entende do que você está falando, se você não entende esses conceitos, você jamais vai conseguir criar qualquer coisa grande em qualquer grande empresa, porque o que importa hoje em dia não é mais só o código. É o que você sabe para você escolher como que esse código vai ser feito. E eu acho que quanto mais sênior, na realidade, você está como desenvolvedor, quanto maior a sua senioridade, eu não estou dizendo que você fica mais longe do código, muito pelo contrário. É necessário você continuar se especializando e aprendendo cada vez mais e etc. Mas quanto vai aumentando o seu nível de senioridade, a sua maturidade em entender fundamentos da sua profissão, ela vai ficando muito mais forte. E são esses fundamentos que vão fazer a diferença para você criar qualquer coisa grande. Se você não tem fundamentos de computação distribuída, raramente você vai conseguir trabalhar num ecossistema de microserviços. Se você vai trabalhar num sistema onde você tem vários tipos de consulta em bancos de dados e você não entender quais são as possibilidades de bancos de dados que você tem nos dias de hoje para cada caso de uso, você vai usar o MySQL para tudo. Basicamente, é isso que acontece quando a gente fica muito tempo fazendo a mesma coisa. E eu, por muito tempo, em vários e vários anos da minha carreira, eu percebia que chegava um momento que eu estava fazendo muita coisa repetitiva e eu não tava aprendendo nada que me virasse a chave e falasse, caraca, cara, faz tanto tempo que eu não aprendo coisa nova de verdade. E quando que a gente se toca que a gente aprendeu algo novo de verdade? Não é quando você vê uma ferramenta nova e bota ela pra rodar. É quando você entendeu o que que aquela ferramenta que na realidade tem um conceito por trás, conseguiu quebrar e virar uma chave aí na sua cabeça então esse aí eu acho que é o grande ponto, quando você não tem a ideia do qual é a linha de raciocínio que está sendo gerada pra você chegar naquele momento, você simplesmente vai ser somente aquele cara que vão passar um job pra você, pra você fazer aquele negócio, mas você nunca vai ser o cara que vai conseguir dar aquele job pra alguém porque pra você passar um job pra alguém, no final das contas você tem que ser a pessoa que entende desses conceitos que estão por trás. Então, hoje em dia, eu acho importante você saber programar, aprender mais linguagens, entender como que as coisas funcionam e tudo mais, né? Mas se a gente, no momento da carreira que a gente tá, ali de sênior pra cima, não conseguir balancear entre aprender tecnologia nova e aprender conceitos que estão sendo utilizados, aí a coisa muda de figura. O Fernando no início aqui, ele já soltou ali uma pérola muito clara. Eu ajudo muita, sou co-líder de SRE da América Latina e tem muitas coisas de implementação de SRE, já estão utilizando hoje e há, por exemplo. Então, é muito interessante de como essas coisas estão evoluindo, ainda mais quando você pode entrear seus bebês da fonte, por exemplo, do Fernando que trabalha na Google e que está vivendo esse mundo de A de perto nas grandes empresas. Então, a nossa sacada hoje aqui vai ser realmente entender esses principais conceitos aí, tá? Então, primeira coisa que a gente vai falar, tá? E eu vou tentar ser o mais breve possível em todos esses assuntos, para a gente não ter uma sessão muito grande e não ficar uma sessão também muito densa. Mas, ao mesmo tempo, né? Eu quero deixar muito claro os conceitos pra cada passo que eu for dando, em alguns momentos eu vou abrir o microfone aí pra gente discutir se alguém quiser colaborar falar alguma coisa também, vocês vão ficando à vontade, beleza? Mas a gente tem bastante coisa aí pra gente ver beleza? Então é o seguinte, como tem muita gente que não trabalha na área de DevOps, ou nunca trabalhou, mas eu acredito que todo mundo já deva ter ouvido falar em DevOps e tenha aquela ideia geral, vamos alinhar um pouco aí definição, conceitos, tá? Bom, DevOps, basicamente, qual que é a grande pegada? Ela é um conjunto de práticas, deixa eu compartilhar a minha tela, que a gente, pelo menos, para vocês não ficarem olhando só a minha cara aí o tempo inteiro, né? Deixa eu compartilhar aqui. Bueno, enquanto você está compartilhando aí, vamos passar a lista de presença? Tá, cola aí no chat, ô, Leonan. Galera, preencham aí a lista de presença, a galera que tá ficando presente nos eventos, a gente vai fazer uma mentoria gratuita aí com a galera. Amanhã. Fechou? Uma maravilha. Então deixa eu colocar aqui os meus quadradinhos aqui do lado, e eu descobri como que eu consigo fazer pra ninguém ficar pichando a minha tela agora. Descobri isso. Ontem a galera tava escrevendoando a minha tela agora, descobrir isso. Ontem a galera tava escrevendo aí na minha tela. Mas, galera, a grande sacada, tá? Quando a gente tá falando sobre DevOps de forma geral, é que simplificando, tentando simplificar um pouco o conceito, entenda DevOps como uma prática que acaba integrando de forma geral a área de desenvolvimento e a área de operação. Quando a gente está falando na área de operação, é toda aquela área que no final das contas vai manter o software no ar, que vai cuidar daquela infraestrutura, vai manter o software no ar. Que vai cuidar daquela infraestrutura, que vai fazer, ter formatos, inclusive, para conseguir implantar a sua aplicação no ar. Eu dei uma passada por isso sobre algumas aulas que eu coloquei na plataforma, apenas para dar uma nivelada de forma geral, mas a gente tem diversos fluxos de entrega. Isso aqui é um exemplo que eu dei que é onde você tem o desenvolvedor o cara que vai testar independente se é de forma automatizada ou não a gente tinha equipes de build e release era muito claro eu lembro que quando eu bati um papo com o Greg da Netflix que é um dos caras mais antigos agora ele se aposentou inclusive lá na Netflix, ele fazia parte desse time quando a Netflix tava crescendo. Eles tinham um time chamado de Build and Release. Resumindo a história, ele ficava pegando o código fonte todo dia do que os caras faziam, ele empacotava e botava em produção. Era isso que o cara fazia o dia inteiro, pra você ter uma ideia. Mas imagina com a carga, com a quantidade de gente que a Netflix trabalhava naquele momento. Então, você chegava até a ter pessoas especialistas só pra essa partinha. Buildar e publicar a aplicação. Mas esse cara aqui, ele não tinha tanto conhecimento do que tava acontecendo ali na aplicação. Então, quando você tá falando de DevOps, especificamente, a ideia é juntar o cara, tanto de desenvolvimento como de operação, botar esses caras juntos para colaborar. Então, quando você consegue botar esses caras juntos, você acaba tendo processos, testes, implantações de deploy, integração contínua, deploy contínuo, infraestrutura subindo de uma forma muito rápida ali de forma geral. Por quê? Porque a gente começa a partir do princípio, e isso é uma das coisas importantes, inclusive quando a gente fala de SRE, que a publicação do software, o deployment de uma solução, qualquer problema que você tiver com aquele negócio indo para o ar é problema de software também, porque no final das contas o software não foi para o ar publicado para as pessoas poderem utilizar. Então no final do dia, se você partir do princípio que tudo sempre é um problema de software, você vai começar a tratar a operação de uma forma geral como o processo de desenvolvimento de um software, não somente o ciclo, mas o processo do desenvolvimento de forma geral. O grande ponto é que desenvolvedor muda toda hora. O cara de infra e de operação, o que ele quer? Ele quer menos mudança. Quanto menos mudança, menos trabalho pra esse cara tem. Quando dá problema, a minha máquina funciona, o outro cara não estava funcionando, não mudei nada, eu só fiz o deploy. Quando tem algum problema, o desenvolvedor, o cara de infra não entende do software, o cara de software não entende de infra, e aí, cliente fora, tempo, dinheiro, estresse, e principalmente a culpabilidade. Quando começa a acontecer isso nas empresas, o tempo todo, o que acontece no final das contas? Nós tendemos a fazer menos deploy. Toda vez que você tem uma fricção para fazer qualquer coisa, você vai fazer isso menos. Qualquer coisa na sua vida que tiver fricção. Se você tiver que andar 5 quilômetros para sair da sua casa, para ir para a academia, é mais fácil. A chance de você não ir é maior. Se a academia estiver na sua esquina, a chance de você não ir é maior. Se a academia estiver na sua esquina, a chance de você não ir também é grande, mas é um pouco maior do que você chegar na academia 5km aí da sua casa. E a mesma coisa é, se toda vez que eu faço um deploy doer, se qualquer coisa que eu alterar no software vai gerar aquele estresse, a gente tende a segurar isso pra caramba. Eu tenho um vizinho aqui que ele trabalha na área de SAP, tá? Uma empresa muito grande. Ele tá num projeto aí que a estimativa era ter gasto ali 40 milhões de dólares pra implantação, e eles já estão chegando perto de 100 milhões de dólares pra implantar, e tá com dois anos de atraso o projeto. E as coisas que estão chegando perto de 100 milhões de dólares para implantar e está com dois anos de atraso o projeto. E as coisas que estão rodando, eles fazem o deploy uma vez por mês. Então, uma vez por mês, os caras estão ali todos estressados e é incrível a gente pensar que em 2025 a gente ainda encontra esse tipo de coisa. Mas por que esse deploy demora tanto para sair? Por que sai uma vez por mês, a cada 15 dias, a cada semana? Porque dói muito, porque o estresse é muito grande. Então, todas as vezes que você tiver fricções para fazer qualquer coisa, a gente vai ter problema. E no caso, aqui, quando a gente está falando de DevOps, a gente vai ter problema. E no caso aqui, quando a gente está falando de DevOps, a gente começa a remover esse tipo de fricção, e quando a gente começa a remover essa fricção, você tende a entregar mais, melhor e com menos dor. E aí as coisas começam a melhorar de uma forma geral. Deixa eu abrir o chat aqui, inclusive, para ficar melhor, para ver o que a galera tá colocando aí geral. Legal? Então, isso aí é um ponto importante. Agora, o grande ponto aí é o seguinte, que quando surgiu toda essa história de DevOps, tinha aquela história assim, DevOps é uma cultura, as pessoas estão transformando DevOps numa profissão e não sei o que e etc. Inclusive tem um tipo de uma sigla, e não sei o que, etc. Inclusive tem um tipo de uma sigla, eu não sei se alguém já ouviu falar em CALMS, tá? Alguém já ouviu falar em CALMS? Algo desse tipo, ó. C-A-L-M-S, né? Só pra não dizer que eu não cobri isso aqui, tá? Mas CALMS basicamente é uma, como se fosse uma abreviação, né? Stands for, para ser de culture, de cultura. Basicamente, é criação de cultura para você conseguir colaborar, legal? Para que as equipes consigam trabalhar juntas. O A vem de automation ou automatização, que vai fazer com que você consiga automatizar o máximo de processos pra você ter mais eficiência, reduzir erro humano, liberar as pessoas pra criarem outros tipos de tarefa, a não ser ficar fazendo um monte de tarefinha repetida. A gente fala muito num termo onde a gente vai falar que é chamado de toil, que é basicamente aquele trabalho e esforço duro, repetitivo, que é chamado de TOIL, que é basicamente aquele trabalho e esforço duro, repetitivo que você fica fazendo manual, que se aquilo fosse automatizado, você não teria que fazer o tempo inteiro, tá? E também, o L vem de LIN, né? Aquela mentalidade de LIN, né? A melhoria contínua, né? Eu vou entregar valor o máximo que eu puder, eu, tudo quanto é coisa que eu puder desperdiçar, eu vou diminuir, né? Então, eu quero fazer algo, eu tenho feedback rápido, eu quero ter feedbacks curtos de tudo que eu tô fazendo pra eu ter mais agilidade. A gente tem o M do CALMS, que é Measurement, né? Que é a medição, ou seja, pra você conseguir saber se você tá indo melhor, você tem que medir. E se você está indo melhor, você tem que medir. E se você mede, você tem métricas. Se você tem métricas, você consegue comparar a sua evolução para melhor ou pior. E aí a gente tem um trilhão de métricas. Por exemplo, sei lá, MTTR, Mean Time to Recover, por exemplo. Então, com diversos tipos de métricas, você consegue ver a evolução daquilo que você está fazendo. E o S do Calm significa Sharing, no final das contas, que é compartilhar conhecimento, prática. Por isso que vem muito dessa pegada de DevOps como uma cultura, porque não é de um dia para o outro que você consegue trabalhar dessa forma. Mas isso a gente estava falando há muitos anos atrás já. Essa história de DevOps é antiga de forma geral, partindo do princípio que a gente está em 2025, e muitos desenvolvedores, principalmente os desenvolvedores que entraram, que não faz muito tempo no mercado que entraram, às vezes isso que eu estou falando pode ser andar para frente, ou seja, algo normal, porque hoje em dia, muitas empresas, a maioria das empresas que eu conheço, já está enraizado isso de forma geral, principalmente porque a gente tem muita ferramenta, a gente tem tooling, a gente tem um monte de coisa que hoje em dia facilita o nosso processo. Antigamente a gente não tinha tanta coisa como nós temos hoje. Então era mais difícil. Com a colaboração de grandes empresas e ferramentas que estão disponíveis hoje em dia, você consegue fazer com custo muito baixo diversos tipos de automação e conseguir facilitar muito a sua vida nesses tipos de processo. Galera, só para vocês saberem, esse QR Code é o QR Code para você preencher caso você tenha interesse em entrar no nosso MBA em arquitetura full cycle. A gente está com pré-vendas nesse momento, antes de abrir as matrículas. E nessas pré-vendas nesse momento, antes de abrir as matrículas, e nessas pré-vendas os valores são mais reduzidos. Então, escaneie esse QR Code para que você bata um papo com a gente, a gente vai entender seu momento profissional, e aí quem sabe você vem estudar com a gente, fechou? Então, o lance é o seguinte, a grande sacada nos dias de hoje é que quando, em algum momento, esses processos, cada vez eles ficaram mais definidos, ou seja, eu tenho o desenvolvedor, ele passa ali por esteiras de CI, CD, faz a parte de teste, segurança, faz o build da aplicação, o release, o negócio vai pro ar, aí tenho toda essa parte de observação e monitoramento, observabilidade e o monitoramento, essas coisas começam a fazer parte de um mesmo contexto. E, de repente, você começa a encontrar desenvolvedores que começam a entender mais de operação, caras de operação que começam a entender mais de operação, caras de operação que começam a entender mais de desenvolvimento, pessoas que começam a entender mais sobre diversos tipos de ferramenta, de automações, que tiveram bastante experiência com isso. O que o mercado fez? Eu quero um engenheiro DevOps. A real é essa, que já começou a rolar. Eu quero um engenheiro DevOps. E daí, muita gente falou, do que você está falando, cara? DevOps é uma forma de integrar as paradas. Não, não, eu quero um engenheiro DevOps. É o cara que entende dessa parada aí, ó. Eu tenho o software, o cara vai conseguir configurar tudo, que eu vou dar um clique na hora que eu der um merge, uma pull request, e o negócio vai para o ar. vai pro ar. E no final das contas a gente começou a ter realmente pessoas que hoje em dia falam, eu sou DevOps Engineer por exemplo, e acabou virando uma normalização no final das contas. Então a ideia é que se você começar a entender mais de infraestrutura e a ideia não é você virar um CISA de mim, mas se você é um desenvolvedor sênior, que não tem o mínimo de conhecimento de infraestrutura, de cloud, de Linux, de ferramentas de CI, CD, ferramentas de análise estática, dinâmica de código, processos de infra como código e todo esse tipo de coisa, acredite, tá? Containers principalmente, o Kubernetes, Docker acredite, se você tá nessa situação hoje, é assim é um alerta vermelho pra você porque esse tipo de coisa qualquer desenvolvedor sênior hoje precisa saber tá? E tem gente que quando eu falo isso fica bravo porque agora tem que saber de tudo e não sei o que, cara, fazer o que? É o mercado infelizmente ou felizmente, é assim que funciona se você não entender disso, você não consegue trabalhar numa empresa necessariamente que tenha esse processo e mais longe, você não consegue ser uma pessoa que ajuda a liderar uma empresa dessa pra conseguir implantar esses tipos de processo, tá? Então, isso aí é um ponto, assim, mega importante pra vocês terem em mente, tá? Então, quando eu vou fazer um deploy, tem muita coisa por trás que acontece, ainda mais em empresas gigantes, né? E dependendo da empresa, a gente não consegue nem ter ideia de como aquilo funciona, imagina um banco com nível de compliance que esses caras tem, com a parte de segurança, imagina como deve ser uma esteira dessa para um software sair da máquina de um computador e entrar numa pull request até ele entrar em produção, como deve ser o nível de criticidade, ainda mais dependendo do tipo de operação, do tipo de software, do tipo de serviço que aquilo está indo para o ar. São coisas que provavelmente, se você não trabalha nem naquela área bancária, o Fernando falou que ele atende clientes na área de finanças e tudo mais. Cara, tem coisa ali que, se você senta na mesa, você não vai saber nem do que os caras estão falando, porque você não entende nem direito aquele contexto que os caras, o domínio que aqueles caras vivem naquele momento, tá? Então, esse aí é um ponto importante aí pra gente se ligar, beleza? Agora, o grande ponto aqui de tudo isso é que, no meio no meio de toda essa história, a gente começou, a gente não, né? Todo mundo começou a pensar, cara, se eu tenho o desenvolvedor, se eu tenho o cara de operação, o que toda aplicação precisa ter em volta dela, de forma geral, é segurança, tá? Não tem o que fazer, né? Segurança, cada dia a mais, é obrigatório em tudo. Qual que é o grande ponto? É que muitas empresas, ainda inclusive, tratam segurança como se fosse uma área totalmente separada, E eu não estou dizendo que não tem que ter uma área de segurança, tá? Entenda a diferença. Muitas empresas ainda tratam segurança como uma área separada da empresa. O que que acontece? Na hora que você está desenvolvendo, no seu processo, no seu ciclo de desenvolvimento, no seu ciclo de entrega, no seu ciclo de entrega, muitas vezes, essa parte de segurança, ela não está sendo levada em conta. O que acontece? Quando está tudo aprovado e etc, vai lá para uma área de SEC, nada passa, volta tudo e dá um monte de rolo. Por quê? Porque o feedback para essa área de segurança acaba sendo muito descolado da realidade do desenvolvimento e da entrega do DEV à operação. E é por conta disso que em muitos momentos e que isso já faz parte hoje em dia, a gente começou a ver o que? O termo DEV SEC OPS. E no final das contas é, hoje em dia, a gente começou a ver o que? O termo deve sec ops. E no final das contas é, como que eu coloco a área de segurança também em conjunto com a área de operação e desenvolvimento? Como que segurança consegue virar um layer aqui em conjunto com todo esse fluxo aqui. Como que eu consigo já fazer o meu software passando por coisas, por pontos de segurança que muitas vezes são básicos, mas acabam sendo ignorados ou você pega ou bug em produção ou quando cai na área de SEC, os caras vão falar, você está maluco querendo subir esse código, tá? Então, seria muito interessante a gente conseguir fazer com que essa área de segurança estivesse também mais envolvida com a área de software, tá? Isso é muito importante. Da mesma forma que você tem ainda a área de infraestrutura da sua empresa, a galera de administração, ainda que a gente tenha DBAs e tudo mais, isso não significa que trabalhar o desenvolvedor com o banco de dados diretamente hoje em dia seja algo complexo, né? Ou seja algo num mundo separado. Segurança não pode ser... Infraestrutura não é mais separado. Quando você desenvolve o software, você já está pensando em qual ambiente que o seu software vai rodar, não tem como você não fazer mais isso e a área de segurança acabou ficando a mesma coisa, então na hora que você acaba juntando essas coisas, você começa ter mais segurança, nesse caso eu estou dizendo segurança como confiabilidade de que você consegue minimizar a chance de você ter problemas segurança, e nesse caso eu estou dizendo segurança como confiabilidade, de que você consegue minimizar a chance de você ter problemas em produção. Minimizar, tá? A gente sabe que é muito claro. Não tem almoço grátis. Você nunca vai conseguir resolver nenhum problema. Você vai minimizar problemas, porque problemas vão acontecer sempre. E quando a gente está falando em DevSecOps, normalmente você vai ouvir algumas letrinhas claras em relação a tipos de verificação de segurança que você normalmente consegue, muitas vezes vezes plugar aqui nessa esteira tá? e quais são algumas dessas siglas ou ferramentas ou sistemas que normalmente você não vai querer ficar de fora e quando alguém falar isso na mesa de bar com outro desenvolvedor, você não vai fazer aquela cara de paisagem, tá? então, nós temos algo chamado de SAST, que no final das contas é Static Application Security Testing. Então, esse é um tipo de cara. tá então esse é um tipo de cara alguém consegue dar um exemplo pra mim de SAST nesse caso aí por favor me dê um exemplo aí de SAST galera seguinte galera sonar cube legal, show olha só que interessante toda vez que você tem um código esse código ele tem normalmente dois estados um estado é o estado de repouso do software ou seja, o software parado. Ele não está em execução. Então, nesse momento, eu posso fazer uma análise desse código. Uma análise do meu software. Então, eu posso analisar o código-fonte. Eu posso analisar o bytecode, o binário da aplicação. Tudo isso sem executar. Legal? E baseado nisso eu consigo identificar uma pancada de coisa. Eu consigo verificar, sei lá, teve gente que escreveu aqui SQL Injection, consigo ver coisas de SQL Injection, XSS, diversos tipos de problema, desde, sei lá, tokens da sua aplicação perdida no meio do código. A gente... Existem ali diversos padrões de problemas de segurança que existem e que as ferramentas, somente de olhar o seu código, ela consegue analisar. E existem diversas ferramentas que fazem isso e você consegue configurar essas ferramentas, inclusive criando graus de... Graus de... Graus de... Não é de rigidez, são policies na realidade, né? São políticas de segurança que você fala que se ele não cumprir essas políticas, a sua esteira, por exemplo, de CI, ela vai falhar, por exemplo. Então você consegue normalmente pegar muita coisa com esses tipos de revisão, vamos dizer assim. Mas nós temos um outro tipo de situação aqui, nosso caso, que é chamado de DAST, que é o famoso, ao invés de ser estático, ele é dinâmico. Então é Dynamic, Application, Security, Testing. Legal? O que o DAST faz? Diferente do SAST, no SAST a gente tem algo que a gente chama de White Box, ou seja, uma caixa aberta, uma caixa branca, que você consegue ver o que tem dentro. Aqui no DAST, a gente tem algo que é chamado de black box, que é uma caixa preta, uma caixa fechada, e que você não consegue ter nem acesso ao código. A única coisa que você consegue ver é entrada e saída. E, basicamente, no que acontece ali no meio, eu simplesmente consigo inferir o que está acontecendo. Então, tendo uma entrada e tendo tal saída, eu estou inferindo que aqui no meio está acontecendo algo. E é essa análise que você faz com esses tipos de ferramenta. Ou seja, normalmente, quando a aplicação está rodando, ou no ambiente de teste, ou no ambiente de produção, você consegue fazer esses tipos de verificação. Sei lá, por exemplo, uma ferramenta dessa consegue fazer verificações em endpoints e verificar se está conseguindo ter uma injeção de alguma coisa. Então, esses tipos de ferramenta ajudam a pegar esse tipo de problema. A gente tem algo que a gente chama de IAST, tá? E aí, ela é um pouco diferente, é um meio termo, que é Interactive Application Security Testing, tá? Esses caras aqui, no final das contas, ela é uma combinação de forma geral, falando a grosso modo, tá, galera? A galera de segurança vai pirar falando, olha, o YAST é só uma combinação de SAST mais DAST, tá? Mas, na realidade, a ideia é o seguinte, que de forma interativa, ela vai monitorando a aplicação, né? Ou seja, ela monitora em repouso, ela monitora enquanto ela está sendo utilizada e ela fica verificando isso o tempo inteiro para buscar a vulnerabilidade de segurança. Então, isso aí é importante a gente ter em mente. Como normalmente isso é feito? Existem diversos agentes que você pode rodar até na sua aplicação, e aí o agente normalmente acaba tendo acesso à sua aplicação, mas ele acaba tendo também acesso ao comportamento que a sua aplicação tem na hora que ele está sendo rodado, tá? Então isso aí é um ponto importante para vocês se ligarem. Ferramentas de SAST. SonarCube tem aquele Fortify, a Checkmarks. DAST, a gente tem uma ferramenta, galera, depois deem uma olhada, porque ela é open source usada pra caramba, né, que é todo mundo acho que já ouviu falar na OSP, né então, tem uma ferramenta chamada Zap, que é Zed Attack Proxy, tá, ela é gratuita é open source, né e ela ajuda muito pra fazer automação na parte de teste, de forma dinâmica. Mas tem uma pancada, tem NetSparker, tem a Burp Switch, tem diversas AppScan, se eu não me engano, que é da IBM, mas o grande ponto é que tem um trilhão de ferramenta aí que você consegue trabalhar pra fazer esse tipo de coisa, tá? Agora, o interessante é tudo isso acaba tendo diversos leis de verificação de segurança vai conseguir verificar tudo obviamente não mas já pensou se em todo momento que você desenvolve você consegue rodar esses caras muita coisa já vai ser barrada ali de longe, somente pelo fato de você conseguir trabalhar. Beleza? Então, esse é o grande ponto. Beleza? Leonan, dá uma moderada no chat aí, tem gente que tem que sair daí. Bom, seguinte, galera. Uma vez que deu para pegar essa ideia, é como que eu consigo colocar tudo isso numa esteira? Isso vai simplesmente automatizar tudo e não tem double check de nada? Muito pelo contrário, né? Hoje em dia, a gente tem formas de realizar deployments. A gente tem desde a continuous delivery, que normalmente, o que é? Você roda todo o processo, o sistema está liberado, vamos dizer, para ir para a produção, mas manualmente eu posso falar, vai para o ar e eu vou fazer todo esse acompanhamento. Ou tem a parte que é muito mais automatizada, que é a parte de continuous deployment, onde o negócio já vai direto para o ar. Vai depender muito do tipo de aplicação, do tipo de empresa, do nível de segurança e de diversas regras e políticas que a empresa vai adotar. O grande ponto é que quando você consegue juntar isso num único local, vai adotar. O grande ponto é que quando você consegue juntar isso, né, num único local, vai, né, fazer uma diferença muito grande pra você minimizar risco, de forma geral, aí da da empresa como um todo. Legal? Agora, o ponto aqui, de forma geral, é toda empresa tá preparada pra isso, né? Na maioria das vezes, não. Principalmente empresas que não são muito grandes. Agora, o fato é, você está preparado para isso? Ou você já trabalha numa empresa que tem esses processos? Agora, o ponto é, você seria capaz de você conseguir criar esses processos para a empresa que, você seria capaz de você conseguir criar esses processos pra empresa que você trabalha então isso aí eu acho que é um ponto assim importante aí pra todo mundo tem um tem uma pegada muito engraçada cara, tem aquele filósofo o Glovis de Barros Filho inclusive ele também deu aula, fez como participação também especial pra gente na Full Cycle. E um dia eu vi ele falando uma parada muito louca, do tipo assim, você pega um livro de filosofia, aí você lê um parágrafo, e daí você não entende. Daí você falou, não, deixa eu ler de novo. Você lê aquele parágrafo e você não entende. Você lê e fala assim, cara, velho, como que pode ser eu olhar pra uma coisa e não entender? A minha obrigação é ler aquele negócio e entender. Sabe por quê? Porque teve um cara que o cara criou essa parada. Então, se uma pessoa foi capaz de criar uma parada, como que eu, lendo aquilo, eu ainda não consigo entender o nível que eu tô de distância daquela pessoa que criou. E o que acontece no meio dessa história com a gente na tecnologia, é exatamente isso. É essa sensação de impotência que a gente acaba tendo em muita coisa que a gente faz. Às vezes a gente não consegue entender como é que funciona um ponteiro na linguagem de programação. Agora pensa que tem um cara que inventou o ponteiro. Saca? E a mesma coisa disso aqui. Tem coisas que acabam sendo aceitáveis a gente não entender porque a gente não tem nem interesse em ter um nível de profundidade técnica sobre alguns aspectos mas galera isso aqui que eu estou mostrando pra vocês se você não entender isso de forma geral, você está muito pra trás, eu não estou dizendo que você tem que implementar, você tem que fazer tudo isso sozinho e nada disso. Mas, galera, se você tem muita dúvida de como que esse fluxo, de como essas coisas chegaram ao ponto de como elas estão hoje, eu recomendo muito você dar uma aprofundada um pouco maior, eu recomendo muito você dar uma aprofundada um pouco maior, tá? Porque esse tipo de coisa, o melhor dia para você ter aprendido isso, sei lá, era 10 anos atrás, né? O segundo melhor dia para você começar a aprender mais sobre isso, hoje, tá? Então, essa que é a grande sacada aí. Então, esse é um ponto importante quando a gente trabalha com isso, agora o maior ponto aqui em relação a tudo isso é que pra que tudo isso funcione a gente tem algo chamado de infraestrutura infraestrutura. E é aqui que a coisa começa a ficar chata para muito desenvolvedor. Muito desenvolvedor pensa que o papel dele é desenvolver, e está tudo bem com isso. Mas aquela história, se você corre, faz corrida, tá tudo bem, imagina que você tá praticando um esporte, eu sou corredor, agora um dia falam, você vai fazer uma corrida, mas você vai correr na neve, eu preciso ser um esquimó pra correr na neve? Não, eu não preciso ser um esquimó pra correr na neve. Eu preciso ser um esquimó pra correr na neve? Não, eu não preciso ser um esquimó pra correr na neve. Mas, eu preciso entender de neve. Porque vai ser lá que eu vou botar meu pé. Eu tenho que saber se a neve é fofa, existem sete tipos de neve, eu tenho que saber que tênis que eu vou usar, e etc, etc. É a mesma coisa com desenvolvimento, galera. Tem muito desenvolvedor que começa a se eximir e falar, isso não é meu papel. Eu não preciso entender de cloud, eu não preciso entender o que é uma VPC, eu não preciso entender como é que funciona o Kubernetes, eu não preciso entender como é que funciona um proxy reverso, eu não preciso entender como é que é feito um cluster de não sei o quê. Eu não preciso entender os layers da camada, layer 4, layer 7, como é que funcionam os load balancers, porque eu sou desenvolvedor. Mas, no final das contas, sempre pense, se você vai correr na neve, você tem que entender o mínimo de neve. E tem muito desenvolvedor que fala, a minha aplicação tá pronta, tô dando PR no GitHub. Mas, você sabe aonde a sua aplicação vai rodar? Você sabe em qual situação que a sua aplicação vai rodar? Você vai saber o tipo de máquina que a sua aplicação vai rodar? Hoje em dia, quando você está falando de infraestrutura, de forma geral, e eu não estou dizendo que isso é o desenvolvedor que tem que colocar, mas você tem pools de máquinas. Principalmente se você está falando em clusters, sei lá, um cluster Kubernetes, você tem pools de máquinas. E cada tipo desse pool de máquina tem um poder computacional diferente. Às vezes aqui eu tenho máquinas que conseguem rodar CPU intensiva. Aqui às vezes eu tenho máquinas de memória intensiva. Aqui eu tenho máquinas de escrita intensiva. Então, dependendo do tipo da sua aplicação, a sua aplicação tem que ser apontada para um pool correto, para ela funcionar da melhor forma possível e não gastar dinheiro à toa da sua empresa. Às vezes, a gente como desenvolvedor fala, ah, minha aplicação precisa tanto de memória para rodar. Cara, de onde você tirou esse valor? Veio a fonte, meu cérebro acha que vai usar... Se você não tiver e não entender o mínimo de infraestrutura hoje em dia, você simplesmente não consegue ser um bom desenvolvedor. Porque um bom desenvolvedor vai conseguir criar uma aplicação sempre pensando no ambiente que essa aplicação vai rodar. Esse aí é um problema muito claro. E tem muita gente que é resistente a isso. Então, sabe aquela parada aceita que dói menos? É exatamente isso. Você tem que aceitar e tem que entender essas paradas. O grande ponto é que, por muito tempo, a forma de fazer deploy, os tipos de como que as máquinas eram organizadas, elas foram mudando ao longo do tempo. Hoje em dia, eu não quero nem chover no molhado aqui, mas nós temos o nosso querido amigo K8S, o Kubernetes, que usa essencialmente containers para trabalhar. E se você não sabe mexer com o Kubernetes, entenda, eu não estou falando para você ser administrador de um cluster Kubernetes. O que eu estou querendo dizer é que você precisa saber mexer com Kubernetes. Você precisa saber o que é um deployment, o que é um pod, o que é um replica set, o que é um stateful set, o que é um secret, o que são as partes de ambiente, como é que funciona um pulse, como é que o cluster é montado, como é que isso vai funcionar, o que é um sidecar. Es como é que isso vai funcionar, como é que o que é um sidecar. Esses tipos de coisas você precisa saber porque é ali que a sua aplicação vai rodar. Então, não tem como você não entender esse tipo de coisa. Agora, o grande ponto também no meio de toda essa história é que apesar de o Kubernetes em si ele conseguir gerar uma padronização de forma geral, padronização, né? De como que as empresas, as aplicações, elas vão rodar por conta dos containers. Ainda assim, nós temos diversos desafios no meio dessa história. Que é o quê? A rede, máquinas, clusters, permissões, disco. Tem muita coisa no meio dessa história. Agora, o ponto de tudo isso é que, conforme as empresas vão crescendo, conforme a gente vai tendo mais necessidade de modificar essa infraestrutura a gente por muito tempo caiu em algo chamado de click ops alguém já ouviu falar em click ops galera? quem aqui já ouviu falar em click ops? click ops? click ops é uma prática extremamente realizada até hoje nos dias de hoje click ops a click ops funciona assim preciso de uma máquina vou mostrar o processo do click ops aqui pra vocês tá preciso de uma máquina na google cloud então eu vou lá no painel da google cloud vou lá nas máquinas virtuais nova máquina passo as configurações as chaves e depois eu dou um clique criar máquina basicamente é isso que é o click ops preciso de uma nova rede nova rede e crio tá? o click ops é assim que funciona tem algum problema de trabalhar com click ops? e crio, tá? O ClickOps é assim que funciona, tá? Tem algum problema de trabalhar com ClickOps? Depende, se você tiver meia dúzia de máquinas na sua empresa, não vejo problema nenhum, porque, cara, a gente tá falando de pouca máquina, pouca infraestrutura e tudo mais, mas conforme a aplicação vai crescendo, a empresa vai crescendo, a empresa vai crescendo, a necessidade de infraestrutura ela vai ficando maior, esses tipos de coisa aqui ficam basicamente inaceitáveis. Por quê? Porque a chance de eu dar um clique errado, a chance de eu configurar algo de uma forma diferente do que outra máquina que eu fiz, sempre é muito grande. A chance de fazer besteira é muito grande. Aí, se um dia eu tiver 50 máquinas e eu precisar recriar isso em algum outro lugar, e eu precisar recriar isso em algum outro lugar, se eu quiser fazer um monte de configuração de rede, de subnet, de um trilhão de coisas, eu vou ter que refazer tudo do zero. Imagina o trabalho que não vai dar para você subir uma infraestrutura completa para rodar, botar a sua empresa para rodar. Um tempo atrás, teve um case muito famoso, eu não vou falar o nome da empresa mas eu acho que muita gente ficou sabendo, um tempo atrás nossa, já faz uns 4 anos a gente vai ficando duelo, mas teve uma empresa muito grande na área de varejo, que eles tiveram um ataque na área de segurança né dentro, se não me engano, foi dentro da AWS, de alguma forma alguém conseguiu entrar lá dentro na AWS e começou explorar as coisas lá dentro o grande problema naquele momento, sabe o que foi? eles não sabiam quem era, ou como era ou conseguiram identificar como que aquilo estava acontecendo o que que aconteceu no meio dessa história era ou conseguiram identificar como que aquilo estava acontecendo. O que aconteceu no meio da história? Eles tiveram que recriar a infraestrutura inteira da empresa numa outra região do zero e colocar tudo de novo no ar. Essa empresa ela ficou fora do ar por dias, tá? Diversos e-commerces do Brasil, parte desse mesmo grupo, acabou, tá? Ficando fora. Imagina o nível de prejuízo que acabou gerando ali, tá? Eu tô dizendo que recriar essa infraestrutura seria fácil? não, eu tô dizendo que essa empresa fazia tudo no click ops? com certeza não, porque eu conheço um monte de dev de lá inclusive gente de infraestrutura de lá mas o fato é que se você não tem uma documentação clara da sua infraestrutura, nunca você, entre astros, vai conseguir subir uma infraestrutura igual a outra. E o ponto é, sempre detalhes vão ficando para trás. Então, no meio dessa história, nesse caso a gente acaba tendo uma outra forma de começar a lidar com infraestrutura tá? que é o seguinte algo que hoje em dia chama IAC que também eu falo hoje em dia mas se você tá ouvindo falar isso somente hoje, novamente, isso também já é algo bem antigo. E IAC significa Infra-S Code. Então, no final das contas, você vai trabalhar de uma forma documental onde você coloca de forma cada vez mais declarativa tudo que a sua infraestrutura vai ter. E aí, a ideia principal é que você dê um comando e toda essa infraestrutura vai para o ar em determinado cloud provider. Ou até mesmo um premise, dependendo de quando você está trabalhando. E quando eu estou falando um comando, quando a gente fala em grandes empresas, obviamente não é um comando. Mas com certeza, um pedaço grande de uma infraestrutura, você consegue realmente utilizar um comando. Por quê? Porque todos esses detalhes que a gente fez aqui do ClickOps, eles estão declarados aqui dentro. Então, isso aí é muito, muito importante. Agora, o mais louco de tudo isso é que como você pode trabalhar de forma declarativa, você, no final das contas, tem um código. E se você tem um código, você tem o Git. E se você tem o Git, você tem PR. E se você tem PR, você também tem pipes de CI e CD. Então, a gente está falando que a sua infraestrutura tem Code Review. A gente está falando que a sua infraestrutura tem code review. A gente está falando que a sua infraestrutura pode ser aplicada através de uma esteira de CI e de CD. Olha que muito louco, galera. Então imagina que eu quero subir mais três clusters Kubernetes. Eu vou lá no meu arquivo de configuração, falo que eu quero três clusters, dou um merge na minha pull request, todo mundo revisou, deu um merge, aquele negócio roda e faz o provisionamento de mais três clusters ali pra mim. Então, é algo que não tem volta. Por quê? Porque click ops é insustentável pra qualquer negócio. Quando a gente tá falando de Infra-S Code, a gente está automatizando normalmente esse tipo de papel. Agora, olha só que interessante. Tem uma coisa muito interessante aqui. Perceba que a gente está falando Infra-S Code. A gente está falando de código. E se a gente está falando de código, a gente está falando normalmente também de desenvolvimento e é por isso que quando a gente está falando de IAC basicamente a gente não está falando mais de um simples script que um cara fazia para trabalhar e para executar uma operação. Não, não é criação de scripts. É realmente a declaração de como vai funcionar a sua infraestrutura. Você vai ter consistência, você vai ter agilidade, você vai ter redução de erro ali pra gente, tá? E o mais importante, na minha opinião, tá? É a gente ter reproduciibilidade. Eu consigo reproduzir exatamente o que eu fiz no ponto A pro ponto B. Esse aí é um ponto importante pra vocês conseguirem trabalhar. Quando você tem isso, é mais fácil você escalar, é mais fácil de você ter auditoria tá, então isso aí é um ponto importante, agora existem dois pontos importantes aqui de você falar de infra como código porque eu escrevi aqui e eu coloquei aqui pra vocês utilizando a palavra declarativa mas existe uma coisa interessante aqui coloquei aqui para vocês, utilizando a palavra declarativa. Mas existe uma coisa interessante aqui, porque a gente tem infrascode declarativa versus infrascode imperativa. Qual que é a diferença disso aqui? A declarativa, eu falo o que eu quero tá quero 3 máquinas se eu chegar aqui e mudar pra 4 e eu já ter 3 o que que vai acontecer ele simplesmente vai somar mais um legal a imperativa ele simplesmente vai somar mais um legal? a imperativa normalmente eu falo eu quero três máquinas ele vai subir três máquinas se eu vou lá e falo eu quero quatro máquinas ele vai subir mais quatro máquinas basicamente tá? ele não tem, ele não fica verificando o estado atual que você tem. Ele executa aquilo que você quer. Quando você trabalha de forma declarativa, você pensa em estado. Você fala, eu quero quatro máquinas. Então, ele vai dar um jeito de fazer a sua aplicação ficar em estado. Você fala, eu quero quatro máquinas. Então, ele vai dar um jeito de fazer a sua aplicação ficar nesse estado. Ele faz um diff e fala, ele está sim, para isso eu preciso fazer um planejamento para ficar desse jeito. Ele te mostra o que ele vai fazer, você aceita ou não. Basicamente, isso aí. Ok? Então, isso é um ponto importante. Declarativo, ferramentas, já tem gente no chat que eu vi aí falando de Terraform, né? Cara, Terraform é uma ferramenta fantástica, tá? Não é difícil de aprender, mas, obviamente, não tem como você usar o Terraform se você não entender o mínimo de cloud. Não tem como eu, no Terraform, conferir um cluster Kubernetes se eu não souber mexer com Kubernetes. Então, eu recomendo que todos, pelo menos, tenham uma noção de como um Terraform da vida funciona. O Terraform, por padrão, ele tem a H funciona, né? O Terraform, por padrão, ele tem a HLS, HashCorp, é que eu confundo o HLS com o protocolo de reprodução de vídeo, tá? Mas a grande sacada é que o Terraform não é a única ferramenta pra isso, opa, acho que a minha câmera deve ter desligado, peraí, tá? O Terraform foi criado pela Hashcorp. Teve um fork por conta de mudança da licença. Hoje, o Terraform... Existe o Terraform e o OpenTOFU, inclusive. E também existem outras ferramentas, como o Pulumi, por exemplo. É Pulumi, né? Toda vez eu confundo. O Lumi. Ou é Polumi? Bom, independente disso, ali você já escolhe a linguagem de programação que você quer programar. Então, eu posso fazer a minha infraestrutura em TypeScript, eu posso fazer a minha infraestrutura em Go. Terraform também tem ferramenta que você consegue utilizar a linguagem de programação com o projeto que eles fizeram ali. Mas no final do dia, eles vão sempre transformar pra linguagem da HashCorp. Agora, o grande ponto é que quando você tá trabalhando de forma imperativa, você pede, né, pra você fazer algo, ou seja, sei lá, eu vou dar um exemplo que eu vou pegar, sei lá, o CLI do Gcloud. Normalmente, isso aqui, ele vai executar uma ação e vai falar, eu quero isso, tá? Ele não tem, necessariamente, a força de entendimento como um trabalho declarativo tem, tá? De forma geral, ok? Então, isso aí é um ponto importante pra gente conseguir trabalhar show de bola? então é importante a gente trabalhar, mas se você tivesse que aprender uma coisa só nesse caso, eu olharia pro Terraform o Terraform no final das contas eu ia falar HLS, tá mas HLS é o protocolo de vídeo é HCL tá,LS é o protocolo de vídeo. É HCL, tá? Que é o HashCorp Configuration Language, se eu não me engano, tá? E... Cara, é bem simples trabalhar com Terraform. É bem maneiro, é bem gostoso de você ver essa parada funcionando. Recomendo a todos que vocês olhem. Mas de uma forma geral, ainda assim, a gente tá falando em diversas opções, né? Tem o Terraform, se você for olhar os cloud providers, eles têm diversas opções, sei lá, o próprio AWS, sei lá, tem o CloudFormation, que é difícil pra caramba entender aquela parada, e eu uso o Terraform, porque o CloudFormation, na minha opinião, é muito complexo, tá? Mas a gente tem diversas outras ferramentas, como o Pulumi, que eu tinha falado agora pra vocês, tem o Ansible, apesar do Ansible ele não ser tão bom em entendimento de estado como o Terraform é, então tem bastante opção aí pra vocês darem uma olhada. Mas por que que eu estou falando de tudo isso? Porque uma vez que você é desenvolvedor e o seu software participa desse ciclo, a infraestrutura vira um problema de software. Se o seu software não está no ar, você tem um problema e não interessa se é um servidor fora ou se é um bug no código. O que interessa é que o seu software não está no ar. Quando o desenvolvedor ele começa a entender que isso também de alguma forma afeta ele diretamente, ele pode pensar, cara, como que eu consigo diminuir essa fricção, entender mais como que o ambiente que eu vou fazer, que eu vou trabalhar vai rodar pra eu conseguir melhorar esses tipos de coisa, tá? Então isso aí é um ponto importante aí pra vocês conseguirem pensar em refletir. Tô dizendo que a partir de agora, todo mundo tem que ser especialista em segurança, em infraestrutura, em Docker, em Kubernetes, em Cloud, em Infra-S Code, eu não estou dizendo para vocês serem especialistas, mas galera, hoje em dia, se você não entender sobre containers, não ter uma base de Kubernetes, nunca rodou um Sonar Cube na sua vida, ou não subiu uma máquina com Terraform, são coisas que não são difíceis de fazer, você não precisa virar um especialista, mas você já tem que ter sentido como é que essa parada funciona, tá? Então, está aí a dica aí para vocês. Beleza? Então, aí então, vamos dizer que a gente navegou até agora sobre esse mundo de DevOps, a gente navegou um pouco sobre a ideia da junção de operação com o desenvolvimento, a gente começou a entender que desenvolvedores precisam também entender mais sobre infraestrutura e existem diversas ferramentas para desenvolvedores, inclusive, para trabalharem melhor com tudo isso. Agora, existe uma outra parte no meio dessa história que são aquelas três letrinhas chamadas de SRE, tá? Mas antes da gente entrar nessa parte da SRE, eu quero fazer um rápido break aqui com vocês. Um break é, novamente, tá, galera? Escaneiem esse QR Code, tá? Nesse QR Code, como que eu consigo colocar aqui? Nesse QR Code, você consegue pedir pra ter um contato com a nossa equipe, pra você entender melhor sobre o que a gente pode te ajudar no MBA em Arquitetura Full Cycle. A gente vai ter uma nova turma agora, tá? Que começa no dia 3, tá? a gente pode te ajudar no MBA em Arquitetura Full Cycle. A gente vai ter uma nova turma agora, que começa no dia 3, no dia 3 agora de fevereiro. Ou seja, você pode começar a estudar com a gente praticamente de imediato. Esse nosso MBA, ele tem o foco muito em fazer com que você consiga liderar projetos, arquitetar grandes soluções, desenvolver e participar de grandes times. Então, a nossa ideia aqui não é para você aprender um cursinho, para você mexer numa ferramentinha e etc. Não. A ideia aqui é que você consiga ter uma visão realmente global do que acontece na área de arquitetura, de solução de arquitetura de software DevOps SRE e soft skills que você vai precisar desenvolver pra você conseguir progredir na sua carreira tá, eu sei que provavelmente 95% das pessoas que estão aqui no momento já são desenvolvedores sêniores já são pessoas que tem uma maturidade suficiente pra conseguir no final das contas deixa eu só colocar meu celular aqui no ocupado no final das contas ir pra um nível que está além do código. Não que não tenha código, inclusive, no MBA. Ele tem. Mas ele foca muito mais em como você arquiteta uma solução. Como eu crio uma arquitetura decente na hora de desenvolver esse tipo de projeto. Então, isso aí, pessoal, é algo extremamente interessante. Então, nosso MBA, ele é reconhecido pelo MEC, ele é emitido, né? Ele é credenciado pelo MEC através da nossa faculdade, a Full Cycle hoje, ela tem uma faculdade que chama FCTec, que é a faculdade Full Cycle de Tecnologia, totalmente regulamentada pelo MEC, tá? Então, a ideia é que você consiga entender pelo MEC, tá? Então, a ideia é que você consiga entender essas etapas, tá? Ele é um curso de 18 meses, né? Então tem bastante coisa pra aprender. E se você tá participando dessa semana, eu queria fazer meio que um paralelo da semana que você tá tendo aqui com a gente, de como que a gente vai trabalhar no MBA. Basicamente, você tem aulas na nossa plataforma, onde você pode assistir, tem os exercícios, tem os cases, mas também, semanalmente, a gente tem esses tipos de encontros, onde são laboratórios que vão ser resolvidos, inclusive amanhã a gente está liberando um laboratório bem bacana de System Design da Netflix, que a galera vai poder fazer. E daqui 15 dias, eu vou fazer um lab resolvendo isso ao vivo com a galera e pegando as soluções, um pouco parecido do que a gente fez na segunda-feira. Então, o que você está experienciando aqui nessa semana, aqui na Full Cycle Tech Week for Seniors, é basicamente a dinâmica que a gente tem aí no MBA. E a reflexão que eu quero trazer aqui pra vocês, galera, nesse ponto, é o seguinte, tá? Se você acha que durante esses três dias, né, espero que muita gente aqui já esteja três dias aqui trabalhando, né? Fazendo isso com a gente, né? Também teve acesso à nossa plataforma e tudo mais. Se você acha que você aprendeu algo bacana, né? E que você tá aprendendo bastante coisa nesses três dias, imagina você poder sentar com a gente por 18 meses, tá? E indo em cada um desses aspectos cada vez mais a fundo para ir aprendendo com profissionais que realmente manjam daquela parada. Porque não é só o Wesley dando aula, porque eu não sou especialista em todas essas áreas. Ok? Então, como a gente estava com o Fernando agora aí, eu não chego nem perto de entender de System Design ou eventualmente de SRE, com certeza, do que o Fernando manja. O cara só trabalha com isso, entendeu? Mas a nossa ideia é conseguir ter juntado os melhores pra conseguir dar essas aulas. Então, a gente vai falar sobre design de software com Solid. Poxa, a gente contratou o Uncle Bob pra dar uma aula só de Solid pra vocês. Entendeu? Ah, precisa de arquitetura hexagonal? A gente pegou o Alistair Coburn pra falar sobre arquitetura hexagonal. Então, esse aí é um ponto importante. E, antes de finalizar aqui, galera, normalmente a gente tem algumas perguntas que as pessoas têm. Tem gente que já é formado e vai conseguir se matricular no MBA, vai fazer, vai receber seu certificado normal pelo MEC. Tem pessoas que estão estudando ainda na faculdade, mas gostariam de entrar no MBA. É totalmente possível. Se no momento que você finalizar o MBA, você já tiver finalizado a sua graduação, você vai receber normalmente também o certificado de conclusão de curso reconhecido pelo MEC bonitinho. Agora, se você não tem faculdade, ou se quando você terminar o MBA, você ainda não vai ter terminado a sua faculdade, o que que acontece nesse momento? A gente emite um certificado reconhecido pra você de extensão universitária da faculdade, tudo bonitinho pra vocês, tá? É registrado esse certificado e se em algum momento você terminar uma graduação, o que que a gente faz? A gente revoga esse certificado de extensão universitária e a gente gera o certificado Lato Senso de pós-graduação pra vocês do MBA, tá? Então, essa que é a grande sacada aí, tá? Então, deem uma olhada, tá? Eu vou colocar aqui de novo o QR Code pra vocês. Quando você escanear esse QR Code, vai pedir provavelmente o seu nome, o seu e-mail, você envia, a gente vai entrar em contato com você, a gente vai entender qual é o momento da carreira que você tá, e a gente vai falar se vale a pena você entrar nessa ou não. Lembrando que até domingo agora, nós estamos, na realidade, acaba sendo até sexta, né? Porque sábado e domingo a nossa área de comercial acaba não trabalhando. A gente está em épocas de pré-matrícula, certo? O que é pré-matrícula na realidade? É antes de a gente abrir as matrículas oficialmente que a gente vai abrir na semana que vem, tá? Então, se você fizer a as matrículas oficialmente que a gente vai abrir na semana que vem. Então, se você fizer a sua matrícula ainda nessa semana, você vai ter um desconto muito maior do que o valor que vai estar ali no site para vocês. Então, pessoal, escaneie esse QR Code, bata um papo aí com a nossa equipe. A gente tem diversas formas de pagamento desde pagamento à vista, pagamento parcelado no cartão, pagamento em 12 vezes, em 18 vezes, pagamento na recorrência, então tem diversas formas de pagamento, escaneia vamos bater um papo com a nossa equipe porque provavelmente isso cara, vai ajudar bastante mesmo na sua carreira, em 3 dias eu acredito que deu para você aprender bastante, mas acredite que em 18 meses dá para você ir muito mais a fundo nesses aspectos. Fechou? Então, isso aí é um ponto importante. Segundo ponto que eu queria falar, antes de a gente iniciar e falar especificamente sobre SRE, eu queria abrir o microfone para algumas pessoas ou tirar alguma dúvida ou comentar sobre os assuntos que a gente acabou tratando nessa parte de DevOps, nessa parte de DevSecOps, nessa parte onde a gente falou também sobre infraestrutura de forma geral, infraestrutura como código e etc. Então, vamos lá, galera. Já temos alguns candidatos aí que já levantaram a mão. E vamos, então, aí para o doutor Antônio. Fala aí. Olá, pessoal. Tudo bem? Boa noite. Olha, eu concordo muito contigo, Wesley, que ter a fronteira de conhecimento a ponto de trocar ideia com essas áreas é importante. Mas o que eu não concordo muito é você ter aquele conhecimento prático, porque hoje o que está acontecendo? Deixa eu explicar o que é conhecimento prático. Ah, o básico? Beleza, está tranquilo. Agora, o que é conhecimento prático. Ah, o básico? Beleza, está tranquilo. Agora, o que está acontecendo hoje é o que aconteceu um pouquinho atrás com o back-end e o front-end. Um cara, quando ele escolhe o front-end, ele fica especializado no front-end. É o cara que tem que pensar em cor, design, UI, tudo isso. Então, tem empresas que tinham um cara só para isso, e ainda tem, porque sabem que o cara tem uma especialidade, é a vibe dele, é o que dá prazer no trabalho dele, ok? Assim como o Beck. O Beck é um cara que eu diria que é tipo um engenheiro, né, que faz um carro. Muita gente não vê a engenharia do carro, mas só vê a lataria, a pintura bonita ou o design. Ou seja, você pegar um cara que se especializa, para se especializar em BEC, com todos os conhecimentos que nós temos aí, beleza. Comunicação, arquitetura, design, código, tem que saber clean arc, hexagonal, show de bola. Está dentro da nossa vibe. Agora, tem que ter um conhecimento que as empresas estão pedindo hoje. Isso é, veja bem é uma crítica, eu não estou querendo fazer uma crítica negativa, mas apenas para reflexão. É muito difícil ter toda essa especialidade. Eu entendo, concordo com você. Outra coisa que eu gosto de desenvolver, muitas vezes, a vibe do cara é eu gosto de desenvolver, eu gosto de pensar na solução, eu gosto de, por exemplo, pegar os requisitos, verificar o que é o domínio aqui, esse contexto aqui é o quê, como é que a gente vai conseguir capturar essa linguagem bíblica. Eu concordo com absolutamente tudo que você está falando e sou muito longe de achar que todo mundo consegue ser especialista em tudo, tá? Mas novamente, você falou, o meu negócio é, eu gosto de entender o domínio, ver os requisitos, cara, mas ao mesmo tempo que você tem que ver o requisito, o domínio, você tem que pensar que esse software, ele vai pro ar e às vezes, da forma como você tá cumprindo aquele requisito, existe um requisito não funcional que você não vai conseguir cobrir, porque você não está entendendo como que aquilo vai se comportar em produção dentro de um cluster de internets que vai ter 300 MB de memória. Concordo, mas para isso deveria haver uma área dentro da empresa específica para trocar, fazer essa ponte. Essa ponte. Então, você tem que... Cara, eu vou ser honesto com você, tá? Quem determina isso hoje é o mercado. É, exatamente. Então, quem determina isso hoje é o mercado exatamente então a gente pode concordar mas quando a gente vai pro mercado é assim o mercado tá querendo um cara que valha por 10 quer pagar em uma média de salário mas como um profissional que valha por 10 e depois fala que não consegue preencher mas eu vou ser bem honesto com você eu vou ser bem honesto com você acho que tem muita empresa que tenta fazer qualquer coisa Mas eu vou ser bem honesto com você, tá? Eu vou ser bem honesto com você. Acho que tem muita empresa que tenta fazer qualquer coisa desse tipo, só economizar, tentar pegar alguém que faz tudo e tudo mais. Mas, de forma geral, eu acho que é totalmente plausível, tá? Honestamente falando. Um desenvolvedor conseguir desenvolver bem, conseguir compreender como é que funciona a sua pipeline de entrega, entender de observabilidade, porque sem isso ele não consegue ver a própria aplicação, e ter o mínimo de entendimento de como a infraestrutura dele funciona. Agora, esse desenvolvedor, se ele não vai trabalhar especificamente ali com código pra de infraestrutura, eu não acho que esse cara tem que dominar e entender todos os detalhes do Terraform. Agora, ter essa noção tem que ter. O grande ponto que eu vejo é que hoje em dia tem muitos desenvolvedores que ainda e é uma questão de momento profissional e tudo mais, não conseguiram passar por todos esses pontos que eu acabei de falar. Eu não estou dizendo que todo mundo aqui tem que ser especialista nessas áreas, tanto que eu, inclusive, com certeza não sou. Mas ter passado por um sonar, ter entendido como é que funciona um agente para a parte de observabilidade, um open-teleno... Sim, mas no intercâmbio com a área de DevOps. No intercâmbio com a área de DevOps. A gente tem que ter um conhecimento para o que eles estiverem falando, a gente saber o que eles estão falando. Com certeza, mas não é só saber o que eles estão falando, você tem que entender por onde que a sua aplicação está indo. Se você entender isso, eu acho que está tudo bem e eu acho que é assim que funciona. Tanto que, para uma empresa, se todo mundo tivesse que entender especificamente de tudo, não ia ter gente criando software resolvendo o problema da empresa. Entendeu? Mas, de forma geral, quanto menor a fricção que a gente tem de botar o software no ar, vai ser melhor. E, obviamente, o desenvolvedor tem que ter essa noção. Agora, por isso que a gente tem devs que trabalham especificamente com DevOps para facilitar a vida do desenvolvedor. Ou também, hoje em dia, tem muito, como o caso clássico do Mercado Livre, o Fiori, que são essas plataformas internas de desenvolvimento, onde eles têm uma área inteira, não plataformas internas de desenvolvimento, onde eles têm uma área inteira, eu não sei quantos funcionários, só para manter uma plataforma, para que o desenvolvedor entre no sistema, clique em alguns botõezinhos, como se fosse simples assim, e botasse a aplicação dele lá no ar. Agora vou falar só uma outra coisa, só para finalizar a minha... Antônio, você me permite, cara, poder só passar para o Jefferson, porque tem algumas pessoas aqui que estão com a mão levantada. Mas é muito rápido mesmo, muito rápido. É o seguinte, se a gente ficar se concentrando apenas só em ferramenta, daqui a pouco quem te garante que a IA não vai fazer isso automaticamente, como é que fica o papel desse cara? Não, a IA já está fazendo, tá? A IA já está no meio de todas essas coisas, do nosso código e dessas ferramentas, inclusive, tá Mas eu acho que o importante é que a gente consiga resolver problemas compreendendo o contexto dentro daquela área de negócio, dentro da empresa, e conseguir perceber quais são os contextos delimitados, os subdomínios daquilo, e daí criar uma solução específica para o cara. Tem dúvidas. Então, para isso, a gente acaba se especializando num ponto. Não dá para me especializar. Eu tenho que ter raiz em alguma coisa que, para mim, são os fundamentos. Design Partner, arquitetura, o quê? A parte de tech. Tudo isso. Isso faz parte do desenvolvimento. Conhecer esse ASD é legal. Você saber como funciona é legal. Controle de versão. Isso faz parte do nosso ambiente. Agora, coisas mais específicas da infra, aí, cara, eu acho que aí já é demais, cara. Bom, cara, tem empresas, o que eu recomendo pra todo mundo, de forma geral, é entender esses conceitos, testarem, não é pra virar especialista, mas entender, ter a ciência dessas coisas, assim, é fundamental, porque vai fazer uma boa diferença, tá? Deixa eu ir aqui pro Jefferson. Fala aí, doutor Jefferson. Fala aí que eu me estendi um pouco. Pô, pessoal, beleza? Cara, é o seguinte, eu concordo com tudo que tu colocou ali, respeito o ponto do Antônio e tal, mas eu como venho do Full Cycle, desde o finalzinho do 2 lá, comprei o 3, agora comprei o 4, e venho acompanhando o meu crescimento conhecendo cada vez mais essas outras ferramentas e claro, é um gosto meu, eu quero fazer parte do maior contexto possível, gosto disso, tanto é que eu estou há 17 anos na mesma empresa, empresa pequena de interior, sabe como é que é, né? O cara faz de tudo um pouco. Nesse meio tempo já tive inclusive empresa de provedor de internet, que é na área de redes e lidava bastante com servidores e tudo mais, então é do meu perfil gostar de pôr a mão na massa e dessa outra parte de DevOps, enfim então eu acho que faz parte do contexto, todo sentido de saber quanto mais, não vou dizer que seja especialista, mas tu tem que saber até pra planejar um novo software ou trabalhar em cima de um novo software e ter mais qualidade. Eu vejo que as soluções e as coisas novas de produtos que a gente largou para os clientes nos últimos tempos, baseado no que eu aprendi no Full Cycle, cara, é absurdo o ganho que teve. Saindo um pouquinho do contexto, se me permitir, eu entrei em contato no final de dezembro, que eu tinha para fechar os cursos para a equipe, até o dia 15 agora, mais ou menos. E eu queria pegar o Full Cycle Junior para o pessoal que iniciou na empresa. Tem 4, 5 pessoal novo e queria colocar para eles, por conta da empresa. E aí tem como fazer esse mesh que eu não achei esse em algum lugar. Cara, eu te passo o link, eu peço pro Leonan colocar, mas entra em forms.fullcycle.com.br ou no próprio site nosso, tem uma área lá para empresas, entendeu? Você entrando ali, a gente entra em contato na hora contigo. Ou depois, qualquer coisa, me manda um e-mail também, wesley arroba fullcycle, eu encaminho internamente aqui pra você. Fechou? Beleza. Fala com o pessoal ali pelo Discord, mas... Cara, essa aí é a melhor frente mesmo, ou através das entradas dos dados no nosso site, ou pelos formulários, porque já entra direto no departamento principalmente se você for pra empresas, é até melhor, porque já entra na área de B2B, porque a gente tem uma área da empresa só pra contratos com empresas, inclusive. Beleza, então, valeu. Só agradecer mais uma vez que depois que eu comecei na plataforma aqui contigo, Wesley, lá das antigas cara, a minha mente expandiu, coisas que eu nem sabia que existia, foi um crescimento absurdo embora é uma empresa pequena de interior, eu consegui colocar algumas coisas em prática ali, então só agradecer a todo o pessoal aí e dizer pra quem tá querendo pegar o curso aí vai firme que não tem erro show de bola valeu aí cara, e temos o professor Alexandre Montanhau aí, cara. E temos o professor Alexandre Montanha. Fala aí, o cara já tem até o DevOps atrás dele, esse cara deve ter até tatuagem do Calmes aqui dentro. desse curso aí já tem muito tempo. E eu queria só compartilhar com vocês um pouquinho do meu pensamento aqui. Eu não sou muito velho, não. Eu tenho que avisar isso, porque senão o pessoal fala, porra, dinossauro? Mais ou menos, né? Eu comecei no final dos anos 80, eu fui técnico, trabalhei na Semig em vários lugares e fui durante 20 anos gestor de fábrica de software da TOTS, que é uma das maiores empresas de desenvolvimento de software. TOTS é cliente nossa, cara. Show de bola. Eu sou da origem do RM, depois fui para a gestão de fábrica de software, fiquei lá há muito tempo. E eu queria só dar um recado para a galera nova e para quem já está também na minha idade, que estar num momento desse aqui, e até indo um pouco de encontro do que o Antônio falou, não ao encontro, e aí, Antônio, é só uma pequena discordância, eu acho que esse tipo de conhecimento aqui é o conhecimento que nos deixa relevantes. Eu estou aqui com 35 anos de profissão, e eu já passei por muitos momentos na TI. Lá no início, para vocês terem uma ideia, o programador era responsável pelo front, pelo back, e pela máquina, pelo ambiente, pela rede. Então, eu configurei muito novel, Lantastic, para o meu software poder rodar. E a gente nunca sabe para que lado a tecnologia vai. A gente precisa estar preparado para o que vem. Hoje a gente está vivendo, eu já vi várias revoluções, de DOS para Windows, Windows para internet, internet para distribuída, rachou, frontback, banco de dados. Volta de novo e vai de novo. Volta de novo e vai de novo. E a gente só fica relevante porque a gente conhece as peças do quebra-cabeça. Então, quando a gente percebe que aquele tabuleiro está mudando, como eu estou percebendo agora e por isso eu estou aqui, é importante a gente entender qual é o próximo movimento. E conhecer isso aqui que você está falando, DevOps. Quando eu conheci DevOps, achei assim, tão espetacular, que, igual você viu aqui, é uma coisa que eu advogo e trabalho e dou aula disso aí também hoje em universidade. Eu entendo que a gente está diante de um novo momento, de um novo tempo. É importante a gente conhecer essas peças, é importante a gente entender esse tabuleiro, e aí, não só nomeças, é importante a gente entender esse tabuleiro, e aí não só nomear, é importante você sim entender onde você encaixa cada uma dessas peças. Porque a gente nunca sabe, com a IA, por exemplo, para onde a gente tem que ir. Eu vou fazer uma predição aqui, que eu posso estar completamente enganado, mas como eu já vivi muita coisa nessa área, eu acredito que agora é a hora e a vez de novo do generalismo. Porque as especificidades, elas estão sendo cobertas pelas IAS. Então é importante você saber um pouco de cada coisa, ou talvez até de uma forma mais extensa, de um colo de conhecimentos. Exatamente, para que você entenda como que você vai montar esse quebra-cabeça junto com a IA. Eu não acho que a IA vai substituir, mas ela não vai substituir os profissionais que se mantiverem relevantes. Então, eu queria só te dizer, Wesley, não sei se vai ser dessa vez que eu vou fazer o MBA, por questões minhas aqui, profissionais, mas eu estou namorando, isso a gente já tem muito tempo, e eu recomendo demais esse tipo de conhecimento para quem quer se manter relevante no mercado de trabalho, porque eu acho que existe uma longevidade muito grande, tenho visto muita gente aí, alunos meus, a galera dá muita desculpa, está difícil, sim, está difícil o mercado, tá, gente? Mas, cara, a gente precisa correr atrás. Mercado de TI é conhecer, estudar, é se especializar. E eu tenho 35 anos que eu decidi uma coisa. Eu tenho que ser aluno o tempo inteiro. Não dá pra você se colocar num momento que você fala assim, não tem mais nada pra aprender. Vai ser o momento em que eu vou parar ou talvez eu vou morrer. Porque área de TI é buscar esse conhecimento, buscar esse aprofundamento e entender essas peças e como que você vai usar. Então era isso. Eu queria deixar esse recado e agradecer muito aí por esse momento, Wesley. E pra mim é um prazer muito grande estar aqui falando pessoalmente com você. Pra Wesley. E pra mim é um prazer muito grande estar aqui falando pessoalmente com você. Prazer é meu, pô. Prazer é meu. Cara, eu acho que isso que você falou do generalismo, no momento que a gente tá eu acredito muito mesmo, porque o maior problema é você não saber o que você não sabe. Por mais que você não seja tão especialista. Óbvio, você sempre vai ser especialista em algo, né? Mas tem muita coisa especialista hoje em dia que a IA vai fazer muito melhor. E já tá fazendo muito melhor que a gente. Ou de uma forma muito mais rápida, ou muito próxima do que a gente faz. E a gente tá falando de três anos só de quando esse boom começou. Galera, daqui três anos, daqui um ano, cara, essas coisas estão mudando muito rápido e eu vou ser honesto com vocês. Nós da área de TI, nós somos as primeiras cobaias, na minha opinião. Porque aonde a tecnologia bate, ela bate primeiro em cima da gente, porque é a gente que acaba criando a tecnologia. Aí, conforme as coisas vão mudando, a gente vai ver as outras áreas sendo afetadas então, se quem vai tomar porrada primeiro com todas as histórias de Iá, com certeza a nossa área, ela já, a gente já a gente já começa a ver isso de cara né, então, eu acho que isso aí é um ponto, assim, importante pra colocar, eu vou deixar o Jair falar aqui, a gente continua e depois eu vou seguindo pras outras mãos aqui, que é o Alzemir, o Júlio, o Tales, etc. Mantenham as mãos aí só pra ficar uma fila, porque senão a gente não termina, eu não quero fazer uma sessão tão grande hoje aqui com vocês. Teve um dia que a gente ficou quatro horas e meia, galera. Então, vamos que vamos. Fala aí, doutor Jair, filme forte, cara? Beleza Wesley, beleza pessoal cara, eu peço licença poética aqui de 30 segundos pra fazer um puxa-saquismo leve porque o canal Full Cycle do YouTube me acompanhou desde o início da minha jornada no mundo da tecnologia eu tenho, cara, eu sou um bebê aqui frente a toda essa experiência que a gente tem aqui no chat a galera aí de 10, 15, 20, o professor agora de 30 anos de carreira, eu tenho só 5, estou engatinhando aí no BB, mas por ter todo esse ferramental aqui da Full Cycle disponível ali no YouTube desde o início, eu acho que isso me ajudou a ter um papel muito relevante nas equipes onde eu trabalhei, onde eu sempre buscava um aprofundamento de alguma ferramenta que a gente utilizava e o canal Fuso Raikou estava lá para me acompanhar, para me ensinar, o Wesley ali sempre mostrando os conceitos, muita coisa de Kafka, de Kubernetes, eu aprendi ali, GRPC, cara, acho que todos os temas por onde eu passei na tecnologia, tinha um vídeo da Fullcycle pra me ajudar, então fechando aqui o parênteses e já entrando também no tema que eu queria trazer, eu queria trazer uma tela mesmo, aproveitar esse momento aqui esses mentores de peso que a gente tem essa oportunidade aqui de ter pra expor uma tela e receber um conselho que é um plano de estudo, né, porque na área de tecnologia, como o Antônio mesmo mencionou, a gente vai ter um milhão ali de ferramentas, a gente vai ter, toda hora surge uma nova, seja a nível micro como um framework ali da nossa linguagem, uma nova forma de fazer, um novo paradigma, ou a nível macro ali, uma ferramenta que agora faz tudo, um key cloak da vida que agora cuida da autenticação toda para você, e um Kubernetes que agora faz toda a infra para você. Então, toda hora está surgindo novas ferramentas, milhões de ferramentas. E diante desse fato, para não ter um pesadelo à noite, para não ficar com aquela sensação ruim de que, cara, você nunca vai ser suficiente, você nunca vai ter 5% do conhecimento que existe na área da TI, eu tenho seguido um plano de conveniência. Então, por exemplo, cara, aqui onde eu estou, o que eles usam? Ah, eles usam isso, isso e essa ferramenta. Pô, seria muito interessante eu ter um conhecimento da outra? Seria, mas eu acho que o melhor agora é estudar essa, porque é essa que está implementando. E até acho que vai de encontro com alguns comentários que eu vi ali no chat, que é cara, é o mercado que decide, o mercado está aí, a melhor linguagem, o que o pessoal fala, que a melhor linguagem é a que põe comida na mesa, e assim é o melhor cloud provider ali, né? Qual que é melhor, AWS ou GCP? É a que a empresa usa. Então eu tenho seguido um pouco essa prática e por mais que a gente tenha ferramentas assustadoras pra cuidar de infra, pra cuidar de código, pra falar pra você se o seu código tá bom ou se tá ruim, dá pra você seguir uma priorização, você cria uma lista de prioridades, que é a que eu mais gosto, que eu preciso aprender, ou é a que eu tô usando mais? Ou é a que me dá mais problema no meu serviço? É a que tá me fazendo fazer hora extra, né? Eu não entendo essa ferramenta, e por isso eu tô fazendo hora extra pra caramba. Então eu tenho seguido aqui um pouco essa mentalidade, aí eu queria ouvir o conselho aí do mestre. Por favor, tire essa de mestre do lado. Mas, cara, eu sempre, eu tenho uma regra meio que de estudo que eu sigo, eu não sei se talvez possa ajudar algumas pessoas, mas eu sempre estudo três coisas de uma vez só. Então, eu elenco três tecnologias ou três conceitos ou varia muito do que eu estou estudando. Mas eu sempre tento trabalhar sempre em três frentes. Por quê? Porque cada frente acaba sendo um pouco diferente da outra e eu não fico bitolado só numa única coisa. Obviamente, né, se você tá numa empresa e a empresa tá usando o Go e você não é programador Go, cara, você vai ter que fazer uma maratona ali pra você aprender a linguagem pra você entregar pro seu trabalho, porque não adianta falar, ah, eu tava estudando Kafka, a empresa nem usa Kafka e eu não tô nem conseguindo entregar o que a empresa nem usa a Kafka e eu não estou nem conseguindo entregar o que a empresa está pedindo. Mas eu normalmente, eu separo sempre três coisas de forma simultânea que eu estudo, tanto porque às vezes você fica estudando sempre a mesma coisa, começa também a ficar meio cansativo e daí você começa a relaxar. Mas normalmente, ou eu estou estudando algo referente a uma linguagem, ou eu estou estudando algo referente ou ou essa área de infraestrutura, SRE, métricas, ou observabilidade, coisas desse tipo, que hoje em dia é muito relevante. Ou também eu estou focado em trends e hypes que acabam aparecendo. Hoje em dia, por exemplo, e é uma coisa importante de se aprender, é o mínimo que você já precisa saber. Agora, o grande ponto de tudo isso é como que eu priorizo? Minha prioridade vai exatamente como que você colocou que você faz. O que eu preciso mais é o que eu estudo mais, mas eu nunca deixo de estudar aquilo que eu acho que é importante, porque uma coisa que eu mais vi e que eu já fiz na minha carreira no passado e me arrependo, e eu não gosto de ver pessoas fazendo isso hoje com a carreira deles, que é você terceirizar a sua carreira pra empresa que você trabalha. A empresa trabalha com aquelas linguagens, com aquela stack, com aquele tipo de coisa. O que você faz? Você fica aprendendo cada vez mais daquilo. No dia que você sair da sua empresa, meu amigo, era aquilo que você sabia e daí para você se arranjar no mercado de novo, ferrou. Então, a minha dica é não terceirize a sua carreira para a sua empresa. Você sempre vai ter que estudar e entregar bem o melhor trabalho possível. Mas não se limite a estudar apenas no que você usa. Sempre estude algo de algo que você não está usando, nem que seja para fazer uma POC, uma prova de conceito, publicar códigozinho no GitHub, fazer brincadeira no seu computador. Por quê? porque, novamente empresa passa o conhecimento fica e você sempre tem que estar pronto pra sua próxima entrevista tem um negócio que normalmente chama ABC, vocês já viram falar? né? é sempre continue cozinhando vocês nunca always been cooking basicamente é cara eu vou dar um exemplo muito claro, eu tô hoje em dia aprendendo a tocar bateria era um instrumento musical que na minha opinião eu nunca seria capaz de aprender eu toco sax, toco flauta desde os anos, oito anos de idade fiz faculdade de música, o caramba quatro mas bateria pra mim era algo que eu nunca tinha pensado que eu iria aprender meu filho queria fazer aula de bateria um dia eu levei ele fazer aula de bateria, um dia eu levei ele na aula de experimental, saiu eu e ele matriculado, eu e ele matriculado, e a gente estuda junto agora aqui, inclusive. Eu até criei uma conta no Instagram, que eu boto os vídeos meu e dele que a gente está colocando. Mas, tirando o lance da bateria, eu estava assistindo um vídeo esses dias de um cara fazendo meio que as habilidades que um baterista brasileiro, que é um dos melhores bateristas do mundo, o Eloy Casagrande que tá no Sleep Knot hoje, ele tem e eles estavam falando sobre esse sempre continuar cozinhando, o que que significa? O cara tava falando esse conceito pra bateristas, mas serve exatamente pra gente, que o negócio é o seguinte mesmo enquanto você não está onde você quer estar, você tem que estar ficando preparado hoje pra isso porque se um dia aquela oportunidade bater na sua porta o que que vai acontecer? Você não vai tá pronto para ela. Mentalizem aí a empresa que você gostaria de trabalhar agora. Sei lá, vou imaginar que todo mundo aqui queria fazer que nem o Fernando e trabalhasse no Google. Aí o Fernando olha ali e fala assim, olha, esse Júlio Biana é o cara, velho. Eu acho que esse cara deveria vir aqui, trabalhar aqui na Google, ganhar não sei quanto, e, meu, ter a melhor experiência de trabalho na vida dele. Daí, o Fernando manda um e-mail pro Júlio e fala assim, cara, vem amanhã aqui fazer uma entrevista, porque abriu uma vaga pra você agora. E daí o Júlio vai falar, ótimo, tô indo aí amanhã, sabe por quê? Porque eu estudo todo dia, eu vim em todos os encontros da Tech Week, e eu tô me preparando todos os dias pra quando essa oportunidade bater na minha porta, eu tá pronto. O problema é que às vezes a gente fica reclamando tanto de falta de oportunidade, mas na real, essa oportunidade não vem, nem se ela viesse, você ia conseguir usar então é que nem os bateristas, o cara fala ah, arranja uma banda decente pra tocar meu amigo, mas se essa banda chegar agora e falar pra você tocar você consegue tocar? Não, então do que adianta então eu acho que o lance de tecnologia é exatamente a mesma coisa então, estude obviamente o que você tá aprendendo na sua empresa, o que você precisa entregar, você tem que honrar o local que tá pagando e tá ajudando a te sustentar de forma geral, mas ao mesmo tempo, você tem que pensar que você tem que tá preparado pra sua carreira, não apenas pra sua empresa. Fechou? Galera, eu vou voltar pro assunto de SRE e depois eu continuo aqui, a gente fala com o Alzemiro, com o Júlio e até tentar falar com o máximo número de pessoas que estão aqui hoje, fechou? fez sentido o que eu falei, galera? tirando as minhas analogias com bateria é que eu sempre acabo fazendo analogia com coisas que eu tô vivendo no dia a dia e quem não toca bateria, eu recomendo testar, tá? é um instrumento muito louco você tá estressado, você mete porrada em tudo e sai feliz mas vamos lá, galera. Lance é o seguinte, tá? A gente vai para um outro ponto agora aqui da nossa aula, que é sobre SRE, tá? SRE significa Site Reliability Engineer, tá? Esse termo, na realidade, né, ele foi criado, posso estar enganado com datas, mas se eu não me engano foi em 2003, por um vice-presidente de engenharia da Google. E a ideia desse cara, no final das contas, é conseguir, de forma geral, incorporar engenharia de software junto à infraestrutura e às operações da empresa, de forma geral. O que acontece? Da mesma forma que DevOps acaba pegando essa filosofia de colaborar de desenvolvedor com operação, o SRE tem um papel muito mais concreto de que o resultado final daquilo tem que ser confiável. E para eu tentar garantir essa confiabilidade, eu vou usar práticas de engenharia de software. Então, a palavra principal quando a gente está falando em SRE é confiabilidade. No final das contas, é isso. Então, no final das contas, SRE é uma abordagem de engenharia para operações de software que foi criado lá na Google. Tem um livro que eu recomendo, tá? Que todo mundo leia, se possível. Inclusive, tem a versão dele PDF, aberta, gratuita, na internet, que chama Site Reliability Engineer, tá? Que são as práticas adotadas pela Google. Então, depois busca um livrinho, um livro razoável, branco que tem uma capa azul. Depois eu procuro o link aqui, eu posso mandar para vocês. Então, no final das contas, quando a gente está falando em SRE, existem objetivos claros. Garantir confiabilidade, escalabilidade e eficiência dos sistemas em produção. Então, a diferença clara de SRE e DevOps é que o SRE, ele foca na confiabilidade operacional e é uma implementação prática em diversos aspectos dos princípios do DevOps. Mas entenda que enquanto enquanto o DevOps junta essas práticas de operação com desenvolvimento, o SRE, no final das contas, ele tenta, a todo momento, garantir que o resultado final disso aqui acabe funcionando. Ou seja, não adianta eu botar um sistema no ar. Se esse sistema no ar cair, existe algum problema. Não interessa o problema. O ponto é que ele caiu. O sistema estava no ar, deu problema no Paypal, que é o gateway de pagamento, e deu problema. Problema de confiabilidade. Ah, mas a culpa não é minha, não sou eu dono do PayPal. O PayPal que estava fora e aí a empresa ficou sem vender. E o que acontece? É falta de confiabilidade. Como que eu consigo resolver se o PayPal estiver fora do ar? Vamos botar outros gateways? Como que a gente pode conseguir rebalancear? Como que eu sei que o Paypal vai ficar fora do ar? Tá? Tem uma empresa muito grande, tá? Que eu... Tem um amigo meu que virou o principal engineer. Quem sabe eu trago ele... Na realidade, quem sabe não. Eu vou trazer ele pra uma das mentorias do nosso MBA, tá? Então, se você tá no nosso MBA, você vai ter uma mentoria com esse meu amigo que é principal, eu acho que só tem dois ou três principals dessa empresa bem grande, da maior big tech da América Latina no Brasil. E o que que acontece? Eu lembro que ele me falou foi ele? Acho que foi. Que um dos dias que ele foi entrar na empresa, começou a soar um monte de alerta lá. E esse alerta, na realidade, estava falando que daqui a tanto tempo, aproximadamente, não ia mais conseguir processar pagamento, porque o gateway de pagamento ia cair. E daí eles entraram em contato com o gateway de pagamento e falavam, vocês vão cair. Então daí eles entraram em contato com o gateway de pagamento e falaram, vocês vão cair. Então os caras falaram assim, não, aqui tá tudo bem. Né? Falaram assim, não, não tá tudo bem, vocês vão cair. Então os caras, tá caindo, entendeu? Então, o que que isso no final representa? Que se até mesmo o gateway de pagamento, que é uma empresa terceira, impacta no seu processo operacional, eu tenho que dar alguma forma de garantir confiabilidade no meu processo, mesmo que seja isso com terceiros. Então, o que os caras resolveram fazer? Monitorar o próprio gateway de pagamento. Quando eles começavam a ver que o tempo de resposta do gateway de pagamento começava a piorar, eles falavam, eu tenho que mudar esse cara agora e eu tenho que entrar em contato com esse cara, avisar ele, porque eu sei dele mais do que ele mesmo sabe dele. Então, vocês conseguem perceber como é que, quando a gente está falando em confiabilidade, é conseguir garantir que o software, ele está funcionando para ter aquela, para conseguir gerar aquele resultado, independente da onde seja esteja o problema. O SRE, ele tem uma filosofia muito de algo chamado, normalmente a gente chama de blameless, né? Na realidade, ele não fica buscando inculpar pessoas, mas tentando sempre culpar processos para que esses processos, eles sejam melhorados, tá? Então esse aí é o grande ponto. Falou em SRE a gente está falando em confiabilidade independente da parte do software que aquilo está sendo afetado tá? Então, seguinte confiabilidade é a prioridade da parada, tá? Então vou até colocar aqui, ó. Confiabilidade é importante. Outra coisa, automação. Uma das coisas que você vai fazer sempre quando você tá pensando em SRE é automatizar as coisas. Por quê? Existe uma parada chamada TOIL, né? É uma palavra em inglês que no final das contas é esforço repetitivo. Eu ia falar esforço repetitivo idiota, mas não é idiota. É um esforço repetitivo que normalmente te ocupa de fazer coisas mais importantes. Ok? Mesma coisa quando você fazia o seu software e não criava teste automatizado. Você tinha que ficar rodando toda vez na mão fazendo os testes. É um esforço repetitivo, bobo, no final das contas, porque se eu automatizo aquilo, eu não preciso ficar fazendo manualmente aquela parada o tempo todo. Então toda hora que você está pensando no SRE, ou em muitas coisas na tecnologia, mas SRE tem muito isso de filosofia, é como que eu consigo brigar com esse cara aqui para eu evitar erro humano, para eu ser mais rápido e conseguir usar recursos de uma forma melhor. Legal? Outra coisa importante de SRE, tá? Métricas, tá? Métricas de confiabilidade. O que que isso significa? Você não consegue saber se algo tá bom se você não consegue medir. Então, você tem ali no final das contas, níveis de serviços, métricas de níveis de serviço que vão conseguir te ajudar a conseguir verificar, né? Qual está o seu estado, como é o seu estado hoje em relação ao seu software, aos serviços que você está gerenciando. Então, a gente fala em automação, redução, vamos colocar aqui, redução de TOEIL automação métricas de confiabilidade e normalmente aqui, e aí que acaba sendo até um tema um pouco ligeiramente polêmico que no princípio e a ideia inicial é que a pessoa de SRE normalmente ele é um engenheiro de software. Tá? E normalmente quando eu falo isso, tem muita gente que às vezes fica brava comigo porque a pessoa é de infraestrutura e daí fala que ele trabalha com SRE e não é desenvolvedor e que eu estou errado. Mas, na realidade, eu quero explicar um pouco isso melhor. A grande sacada do SRE é você conseguir utilizar a engenharia de software para conseguir gerar mais confiabilidade, automação, reduzir esforço repetitivo e também conseguir produzir métricas para manter a sua aplicação cada vez mais confiável. Então, você utiliza esses recursos de engenharia de software, você programa, você cria ferramental, você faz uma toncada de coisa. E para você fazer isso, você tem que fazer o quê? Você tem que saber desenvolver. Significa que alguém que não é programador pode trabalhar na área ou como um papel, porque depende de como que a empresa faz. Tem empresa que fala que a minha filosofia é SRE. Mas a grande questão é eventualmente sim. Não acredito que tenha problema nenhum. Inclusive uma pessoa de infraestrutura é super recomendado estar nesses tipos de equipe porque ele consegue entender profundamente infraestrutura. Mas, obviamente, que ao longo do tempo, essa pessoa, ela vai ter que, de alguma forma, ir se adaptando e entendendo cada vez mais processos de engenharia de software. Não tô dizendo que esse cara vai ter que virar o programador pró- experiente porque ele era um CIS admin. Não. Mas SRE está ligado diretamente à implementação de engenharia de software nos processos de operação ali das aplicações. Então, normalmente, é importante ter um equilíbrio ali nesse caso em dev e ops, aqui nesse caso, tá? Em dev e ops aqui nesse caso. Ou seja, eu tenho que olhar muito para o desenvolvimento, tá? Mas ao mesmo tempo eu preciso olhar muito para a parte de operação para garantir que está tudo funcionando. E por isso que muita gente mistura que DevOps e SRE é tudo a mesma coisa. Na realidade não. A área de SREura que DevOps e SRE é tudo a mesma coisa. Na realidade, não. A área de SRE, o papel de SRE é também olhar para o DevOps. Porque a área, vamos dizer, de DevOps é uma área extremamente importante que faz exatamente o quê? Cuida do ciclo inteiro de entrega do software. Então, não tem como eu estar na área de SRE e não entender de DevOps. Mas não significa que pelo fato de eu estar na área de DevOps eu seja uma pessoa de SRE. Porque o foco é diferente. O foco do DevOps é entregar o foco do SRE é garantir que independente de qualquer coisa aquela parada está funcionando pode ser um problema de entrega pode ser entendimento que um bug sempre está acontecendo, entendimento de quando o sistema cai demora para recuperar, entendimento de quando cai, o que aconteceu deixa eu estudar, deixa eu tentar fazer com que esse problema não aconteça novamente, perceba que o foco do SRE ele é diferente ele olha para essa área mas não necessariamente uma pessoa de DevOps, ela está ali focando apenas na confiabilidade não necessariamente. Então, por isso que a gente não pode colocar DevOps e SRE no mesmo balaio, apesar de ter uma convergência muito forte. Então, é importante vocês conseguirem se ligar disso aí. Agora, quando a gente está falando disso, de SRE, e novamente, como essa parte de métricas, como eu falei pra vocês, é tão importante, no final das contas, a gente tem, vamos dizer ali, como que eu posso dizer? Componentes ou níveis, níveis de serviço. Ok? O que que isso, nesse caso, significa, galera? Significa o seguinte, que para que eu consiga entender esse nível de disponibilidade, de confiabilidade, de segurança, de garantir que as coisas estejam funcionando, eu preciso ter dados nas minhas mãos. Então, primeira coisa que eu preciso fazer é conseguir escolher quais são os indicadores que eu preciso olhar. E tem uma palestra super top que o Fernando da Google fez. Deve estar no nosso canal do YouTube que eu acho que é hiper conffiabilidade com inteligência artificial área de hiperconfiabilidade, o que é isso no final das contas? ele criou um software que varre todo o código fonte utilizando IA e aí ele entende tudo que o software faz qual que é o maior problema da área de SRE hoje em dia? ok, eu preciso ter métricas pra eu garantir o nível de confiabilidade a questão é quais são as métricas quais são os dados que eu tenho que olhar o que é importante pra esse software que eu não tô vendo então a sacada dele foi eu analiso o software inteiro são os dados que eu tenho que olhar? O que é importante para esse software que eu não estou vendo? Então, a sacada dele foi, eu analiso o software inteiro, a IA entende aquele software e ela traz para mim quais são os indicadores que eu tenho que olhar para eu conseguir gerar os meus indicadores de níveis de confiabilidade da minha aplicação. É fantástico essa ideia. Porque o maior problema nosso é que quando a gente fala, ok, vamos medir, criar métrica. Cara, eu vou medir o quê? Por que falar que eu vou medir CPU, memória, latência, essas coisas? Cara, é óbvio. Mas o que mais que eu tenho que medir? Porque a medição, ela não é só em relação a tempo de resposta é medição do negócio muitas vezes eu tenho uma loja virtual que tem não sei quantas pessoas acessando naquele momento, ela tem um pico normalmente todo dia de 100 vendas por minuto e agora está tendo 10 vendas por minuto vocês acham que deve ter alguma coisa errada com essa loja? Nesse momento que está tendo 10 vendas por minuto? Do nada! Provavelmente tem algo errado. Provavelmente não é um monte de cliente que falou, falou, agora eu não vou comprar. Provavelmente tem algum problema de software aí. Como que eu consigo antecipar isso? Bom, eu sei a quantidade de vendas por hora, caiu a quantidade de vendas por hora, está tendo uma anomalia se está tendo uma anomalia, pode ser que tenha algum problema deixa eu analisar, ou seja antes do meu telefone tocar eu já estou sentindo que eu estou tendo uma anomalia e eu consigo olhar, então primeira coisa que a gente tem que entender ali são algo que a gente chama de SLI, Service Level Indicator tá, basicamente são a gente chama de SLI, Service Level Indicator. Basicamente, são métricas, nesse caso, que vão indicar a saúde do sistema. Essas aí são algumas métricas básicas, que é aquilo que eu estava falando para você. Exemplo, isso não tem como fugir. Latência, disponibilidade, taxas de erro. Isso aí são métricas básicas. Mas existem diversos outros indicadores que eu preciso descobrir e é aí que está a inteligência de algum desenvolvedor ou de uma pessoa dessa área. Por exemplo, o Fernando. O cara pensou, cara, eu tenho essa solução, esse software. Eu não entendo direito tudo que esse software faz, mas provavelmente tem dado importante que eu preciso medir. Como que eu consigo descobrir? Cara, usou IA, ótimo. Tá? Ou seja, é uma saída. Por isso que entender o conceito, muitas vezes, é melhor do que você entender como desenvolver um programa porque desenvolver programa no momento da carreira que a gente está não é mais o problema tá aí nós temos outro tipo de cara, SLO que é no final das contas Service Level Objective no final das contas é Quais são as nossas metas De forma específica Tá Dos meus SLIs Ou seja, eu tenho meus indicadores Então por exemplo, eu quero garantir Que a minha latência Ela sempre seja abaixo de 50 milissegundos Esse aqui é o meu objetivo Por outro lado minha latência, ela sempre seja abaixo de 50 milissegundos. Esse aqui é o meu objetivo. Por outro lado, eu tenho um SLA, que é o Service Level Agreement, que é o que eu prometo. Aqui é o que eu miro. Aqui é o que eu prometo. Eu sempre vou mirar mais alto naquilo que é o meu objetivo. Mas eu vou prometer sempre um pouquinho menos para eu ter uma margem ali para mim de segurança, inclusive. Inclusive, uma margem não é só para erro. É uma margem de teste. Porque às vezes eu quero testar coisas novas pra melhorar algum comportamento se eu não tiver uma gordura entre o meu objetivo com o nível de serviço que eu tenho que entregar eu simplesmente chego num momento que eu não posso errar e se eu não posso errar, eu tenho medo de inovar essa que é a grande questão então, normalmente o SLA é o acordo com o cliente. Eu vou colocar de forma geral. É o que eu prometi, é o que eu garanti, é a palavra que eu dei. Mas eu tô mirando mais alto, porque eu quero ter gordura pra eu poder errar, mas eu quero ter gordura também pra eu poder testar. E aí, baseado nisso, eu tenho o famoso error budget. Que no final das contas, o que isso significa? É a minha tolerância de erro dentro dos meus SLOs. Aqui, por exemplo. Aqui. Por que eu tenho um budget em inglês é orçamento, né? Então é como se fossem créditos. Eu posso ficar fora do ar 10 minutos. Beleza. Fiquei no ar fora do ar 2. Opa, só tenho 8 agora de crédito, entendeu? Eu preciso testar algo pra facilitar minha vida. Vou rodar um teste? Vou. Opa, fiquei mais dois fora do ar. Agora eu só tenho mais quatro. E assim vai. Então, se eu não tiver esses indicadores claros, eu consigo perceber na hora o que eu tô violando. E é muito interessante que a maioria desses incidentes você consegue metrificar. Inclusive, tem milhares de ferramentas, até mesmo essas ferramentas como New Relic, Datadog, hoje em dia, até os incidentes eles já cruzam baseado com seus níveis de serviço que aquele sistema está prometendo e ele já começa a mostrar como é que está o seu cumprimento desses seus níveis de serviço ali. Então esse é um ponto importante. Agora, de forma geral, o que todo mundo sempre vai precisar? E aí tem ferramentas. Eu vou jogar sopra de letrinha de ferramenta ou coisas importantes. Você precisa monitorar e ter observabilidade. Então, você vai precisar de ferramentas como Prometheus para pegar métricas, você vai pegar a Grafana como dashboards, você vai pegar um New Relic, um Datadog, você vai pegar um Splunk, você vai usar as ferramentas do seu Cloud Providers, tá? Observabilidade é um assunto extremamente complexo, complexo pra caramba. Quando empresas grandes vão implantar observabilidade, caramba, quando empresas grandes vão implantar observabilidade, é algo muito difícil, tá? É difícil mesmo. Ah, observabilidade é métricas, logs e tracing, e etc. Cara, o buraco é muito mais embaixo. Eu tenho dois amigos muito próximos que trabalham em empresas grandes, empresas diferentes, que eles foram responsáveis por fazer implantação da parte de observabilidade em tro centros microserviços. Padronizar tudo, cara. Manter que tudo funcione, que todos os logs estejam no mesmo padrão, que todo mundo use o mesmo SDK, que todas as métricas sejam definidas da mesma forma, que a mesma ferramenta consiga ver tudo e que caiba no bolso da empresa é muito difícil. Então, observabilidade é importante, mas ao mesmo tempo, você precisa ter ferramentas que vão fazer gestão de incidentes. E práticas que você vai fazer isso. Por exemplo, a pós-mortem. O negócio deu ruim, galera, vamos sentar o que deu ruim. Por que deu ruim? Aonde que aconteceu? Ficou claro pra todo mundo? Inclusive, teve uma imersão ou a semana do Tech Lead, eu não tenho certeza, que eu dei até templates de pós-mortem pra galera utilizar. Teve muita gente que tá usando e curtiu. Depois eu posso dar uma olhada sobre isso. E, obviamente, ferramentas de automação e também gestão de mudanças, né? E nesse caso, quando eu falo em gestão de mudanças, é como que eu posso fazer com que as mudanças que eu crio no meu ambiente consigam rodar de uma forma mais segura, tá? Por exemplo, vou dar um exemplo bem claro aqui de gestão de mudanças. Qualquer coisa que muda o estado do seu sistema ou que muda o seu sistema acaba sendo uma mudança. Então, quando eu estou falando em gestão de mudança, aqui pra gente, eu posso estar falando de, por exemplo, deixa eu colocar aqui tipos de deployment quais são alguns tipos de deployment que vocês conhecem galera? quais tipos? coloquem aí alguns tipos de deployment que normalmente vocês conseguem trabalhar ali, tá? Bom, coisas importantes, por exemplo, Blue Green, ou seja, eu tenho a minha aplicação rodando, eu sobro uma nova infraestrutura pra minha versão B, aí eu mando o tráfego pra minha versão B, deu tudo certo, beleza, não deu, opa, volto para a versão A e a coisa foi. Tenho a Canary deployment, deploy a Canário. O que esse cara faz? Primeiro eu libero o sistema para 1% da base, 5%, vou analisando, 50%, as coisas estão funcionando, ou seja, estou com duas versões rodando ao mesmo tempo. Deu ruim? Volto, normal, faço rollback. Não deu ruim? Vou liberando até estar 100%, todo mundo com 100%. Então, existem várias formas de eu conseguir trabalhar. Existem, por exemplo, que é muito utilizado hoje em dia, feature flags, tá? Que inclusive tem ferramentas, tem soluções, tem empresas que prestam serviços apenas de feature flags. Basicamente, galera, eu conheço uma empresa bem grande, tá? Que inclusive teve um camarada aqui na live, já trabalhou nela que existem alguns sistemas que eles rodam que esses sistemas eles não passam entre aspas, mas por testes como assim? Passam pelos testes automatizados e o deploy ele já é contínuo, não passa por aprovação mais, vai direto pro ar, mas como que eles testam essa parada? Tudo com feature flags. Eles têm uma área administrativa falando, acabei de subir esse tipo de feature. Acabei colocando nessas condições. Aí, dentro da administração, de toda essa parte de feature flags, eu falo, eu quero liberar essa parada pra esse cliente. Normalmente, essas aplicações são multi-tenancy. Aí o que acontece? Faz essa liberação e vai sentindo como o cliente vai rodando e vai trabalhando com vários níveis de flags. Ou seja, os bugs acabam sendo pegos conforme as flags foram sendo liberadas. Quando descobriu que tem aquele negócio, opa, oculta de novo aquele tipo de funcionalidade. É uma abordagem, cara, que você tem que ter muito culhão pra fazer, mas quando funciona, a quantidade de deploy que acaba subindo, o nível de agilidade é muito grande e é muito fácil, no final das contas, de habilitar ou desabilitar qualquer tipo de funcionalidade. Mas você tem que ter um estudo e uma organização e um entendimento do nível de granularidade do sistema de uma forma muito clara. Então, assim, é bonito de falar, mas não é fácil de implementar. Quando está implementado, é uma maravilha. Novamente, será que não é você que está assistindo agora isso aqui, que às vezes ouviu falar nisso agora, começa a pesquisar e de repente você entende mais sobre isso bota isso na empresa que você está trabalhando e de repente a forma de como a sua empresa entrega software muda completamente por conta de você esse tipo de coisa galera que eu acho que é importante novamente produzir código é importante, cada vez mais eu tento aprender mais programar melhor, fazer o meu software cada vez ficar muito melhor, hoje mesmo eu gravei um vídeo sobre ponteiros fracos na versão 1.24 do Go onde vai ajudar muito a otimização de memória fazendo apontiros fracos na versão 1.24 do Go, onde vai ajudar muito a otimização de memória, fazendo apontamentos fracos. Ou seja, um nível de detalhe maior ainda pra utilização de ponteiros pra diminuir a locação em algumas situações do Garbage Collector. Cara, eu adoro aprender essa parada. Eu aprendi, comecei a usar, nem tá na versão tá como release candidate ainda, RC2, da versão 1.24 do Go, mas eu já tô brincando com essa parada porque eu curto pra caramba entender memória, entendeu? mas entender essa visão geral de como o processo de engenharia de software ele funciona como eu posso olhar pra minha equipe e falar galera, olhem isso aqui, vamos tentar fazer um piloto pra gente implementar porque isso aqui talvez ajude pra caramba já aqui no processo galera, isso não é o código que vai, que importa é a decisão que alguém que estudou um conceito entendeu, achou interessante e vai tentar implementar se o código vai ser gerado por IA, se vai ser um desenvolvedor se vai contratar uma ferramenta externa é uma outra história, mas perceba que quem faz isso é quem conhece que essa parada existe, novamente o nosso maior problema como desenvolvedor e principalmente quanto mais tempo a maior problema como desenvolvedor e principalmente quanto mais tempo a gente passa como desenvolvedor é a gente vai ficando cada vez mais arrogante, achando que a gente já ouviu de tudo e a gente nem sabe o que a gente não sabe. Aí a gente tem um cara do nosso lado chamado chat GPT que você acha ainda que você vai tirar todas as suas dúvidas, mas você não tira dúvidas de algo que você não sabe que você tem dúvida. E aí é o maior problema. Eu não sei que aquela parada existe e eu nunca vou perguntar sobre ela. Entendeu? Imagina que existe um planeta chamado Chapolin, sei lá. Cara, você nunca vai fazer uma busca sobre esse planeta porque você não sabe que esse cara existe. Então, entender que as coisas existem faz muito sentido, e com certeza isso é o que muda o jogo no mercado para as empresas, para os desenvolvedores, para as lideranças. Então, esse é um ponto importante para vocês conseguirem trabalhar. E também, a gente pode até falar em gestão de mudança, mas na realidade a gente pode até pensar em o quão resiliente, ontem a gente falou um pouco sobre a resiliência de sistemas. Quem lembra o exemplo que eu dei aqui ontem? Eu tenho a minha árvore, eu tenho um monte de vento batendo aqui na minha árvore tentando derrubar e ela tem duas opções ou ela quebra, ou ela ou ela enverga o que é se envergar? é não necessariamente ficar fora mas às vezes reduzir o seu nível de serviço mas garantir que alguma coisa pelo menos continue funcionando não necessariamente ficar fora, mas às vezes reduzir o seu nível de serviço. Mas garantir que alguma coisa, pelo menos, continue funcionando para não ter aquele blackout geral. Garantir que a sua aplicação, quando as coisas melhorarem, elas não perderam dados. Como que eu consigo fazer isso? Porque falar que a minha aplicação tem que ser resiliente é uma coisa. Provar que a sua aplicação tem que ser resiliente é uma coisa provar que a sua aplicação é resiliente é outra coisa qual é a forma que você pode provar que a sua aplicação é resiliente? você pode chegar e tirar ela do ar e ver o que acontece com os outros micro serviços sem ela aí você vê quão resiliente a parada está mas eu posso chegar e deixar essa aplicação mais lenta. Ou fazer que nem a Netflix, né? Eles têm uma prática, né, hoje em dia, que tem inclusive ferramentas pra isso, né? Que normalmente a gente chama isso de... Quem já ouviu falar? Acredito que a maioria de vocês já, né? Engenharia do caos. Engineering. O que que esse cara faz no final das contas? Eles têm alguns sistemas, né? Eu acho que tem um que chama Gremlin, depois vocês pesquisem, e tem o famoso que é o Chaos Monkey. Na realidade, esses caras, o que eles saem fazendo? Eles saem desligando o serviço, eles desligam regiões, eles desligam zonas de disponibilidade, eles tiram banco de dados fora do ar, é como se entrasse um maluco na sala e começasse a destruir seu data center. Enquanto isso está acontecendo, você vê o quão resiliente o seu sistema é. Então, tudo isso são formas de você conseguir provar e garantir. Porque enquanto está tudo funcionando, é fácil falar que você é resiliente. Até dar o primeiro problema. Aí você encontra aquele cisne negro, né? Tudo que você falou até agora se provou ao contrário, porque apareceu um problema. E aí, basta aparecer um problema para provar o quão errado você estava. Então, esse aí é o ponto importante. Quem aqui consegue bater no peito e falar as minhas aplicações aqui estão resilientes? Ah, está e não sei o que, tá. Você já tirou aquela outra do lado dela do ar? Você já desligou seu banco de dados? O que aconteceu se você desligar seu banco de dados? Até que ponto você pode deixar o seu sistema fora do ar, tá? Então no final das contas, quando a gente tá falando de SRE a gente acaba tendo uma série de benefícios tá? Quais são benefícios? Garanto XP do usuário eu reduzo custos, tá? Eu consigo alinhar muito mais deve e operação eu consigo melhorar de forma contínua tá, desculpe o meu português sem acento tá mas eu acho que esses tipos de coisa é o que acabam fazendo diferença, porque no final das contas o usuário final acaba sendo o mais importante agora qual que são desafios bem claros nesse caso equipe como que uma equipe pode aprender todas essas paradas? Como que eu vou conseguir definir os meus indicadores, que é o que eu já tinha falado, e os meus objetivos claros para eu conseguir trabalhar? E os objetivos, galera, tudo que é indicador, tudo que é objetivo, tem que ser extremamente pontual. É que nem meta de vendas. Você tem que vender 10.532,22 reais esse mês. Se você não bateu esse valor, você não cumpriu a meta. Se você bateu, você cumpriu. Se não, você ficou acima da meta. É simples assim. Métrica é muito claro. Eu tenho que ficar por 99,99% com uma latência de 50 milissegundos. Passou desse tempo, eu quebrei isso e simplesmente deu ruim. Então, conseguir definir SLI, SLO, é difícil. Uma outra coisa que é comum acontecer, Então, conseguir definir SLI, SLO é difícil. Uma outra coisa que é comum acontecer, resistência cultural. Muitas empresas não topam fazer isso, tá? E por diversos motivos. Ou é cultura, ou é tamanho da empresa, objetivo, cabeça, um monte de coisa. Mas, novamente, galera, não é porque a sua empresa não tem uma área, não tem o papel do SRE, não interessa como vocês queiram chamar, que você não tenha que entender o que é um SLI, um SLO, um SLA, um Euro Budget. Cara, faz uma brincadeira. Faz algumas contas na calculadora para você entender. Ou pega o sistema que você trabalha, pega os dados dele e fala. Como que estão aqui essas métricas? Seja você o SRE, você não precisa nem mostrar para o seu chefe, mas já é uma forma de você praticar. Então, no final das contas, a grande sacada do SRE, e inclusive para você vender isso dentro da sua empresa, é conseguir fazer o quê? Medir o sucesso. No momento que você chegar e falar aquele processo, eu gastava três pessoas todo mês para fazer isso, agora eu não gasto nenhum. Ficou automático e eu estou usando uma todo mês para fazer isso, agora eu não gasto nenhum. Ficou automático e eu estou usando uma máquina tanto para trabalhar isso. Aquele processo que ficava fora do ar e que a empresa deixava de vender tanto, isso não acontece mais por conta dessa ação. Quando você chega para um dono de uma empresa, para um CTO e falar, eu diminuí custo, eu diminuí problema, eu garanti menos estresse pra equipe e as coisas tão funcionando de uma forma mais livre você acha que alguém vai negar isso? é difícil negar agora, se você chegar e falar por favor, eu preciso de SLIs, SLOs SLAs, SLX SLOps qualquer coisa desse tipo o cara vai falar, esse cara aí já vem com um monte de por favor, eu preciso de SLIs, SLOs, SLAs, SLX, SLOPs, qualquer coisa desse tipo, o cara vai falar, esse cara aí já vem com um monte de modinha. Não tem nada a ver com isso. Se você prova o benefício, se você consegue trazer com dados, raramente isso quebra um pouco a fricção para você conseguir implantar qualquer coisa na sua vida em qualquer empresa, tá? Não é fácil. Tem níveis hierárquicos. Às vezes você não dá ordem em nada, você não manda em nada, mas pelo menos você já sabe que essa parada existe. Você é uma pessoa que consegue sentar, uma pessoa que consegue discutir. Você já fez alguma coisa parecida, tá? Então, basicamente, o engenheiro SRE, já que a gente está falando de Software Reliability Engineering, e a gente está falando, então, engineering como engenharia, então, o engenheiro SRE, ou a pessoa que trabalha ou tem esse papel dentro da empresa, ele tem que ter equilíbrio entre o desenvolvimento e operação. Ele tem que pensar, sempre automatizar o que ele conseguir e garantir eficiência. Ele tem que conseguir ter práticas claras para conseguir monitorar e observar os sistemas. E ele tem que conseguir ter claramente uma forma de resolver incidentes e prever e prevenir que esses incidentes voltem a acontecer. Então, basicamente eu acho que se você fosse definir, depois eu até vou mandar isso para o Fernando, para ver se ele tem mais algum item que ele poderia adicionar, mas se você consegue equilibrar desenvolvimento e operação, se você consegue automatizar e garantir eficiência, se você consegue colocar prática para monitorar e observar, se você consegue resolver incidentes e se você consegue prevenir novos incidentes, evitando qualquer tipo de problema futuro, cara, provavelmente esse tipo de coisa é muito forte no papel de SRE. Agora, existem algumas coisas que tem que virar cultura nessa área. Por exemplo, deu ruim, tive um problema ali na minha aplicação. Então, existem algumas práticas claras. Vou colocar aqui, culturais SRE. Deu ruim, eu preciso ter pós-mortem. Basicamente, deu ruim, eu preciso ter post mortem tá basicamente e normalmente isso é chamado de blameless blameless post mortems o que que é isso? é você culpar processo e não culpar pessoas, quando a coisa dá ruim né, e o cara deu update sem o ar, o problema não tá no cara que deu update sem o ar É você culpar processo e não culpar pessoas. Quando a coisa dá ruim, né? E o cara deu o update sem o ar, o problema não tá no cara que deu o update sem o ar. O problema tava o banco de dados permitir acontecer o update sem o ar daquela forma. O problema tava aquele cara que entrou faz cinco dias na empresa ter acesso ao banco de dados de produção pra rodar um problema desse tipo. Ou o problema tava no teste que permitiu com que aquele negócio foi pra produção. Então, no final das contas, a grande sacada de tudo é que sempre tem pessoas e as pessoas fazem caca, mas sempre são os processos que deixam as pessoas fazerem caca. Né? Você tem uma criança e você fala, não brinque com Mas sempre são os processos que deixam as pessoas fazerem caca. Você tem uma criança e você fala, não brinque com faca. A criança pega a faca e se corta. A culpa da criança é de quem deixou a criança pegar a faca. É exatamente o que a gente faz no dia a dia. É fácil culpar, mas quem deixou a faca na mesa para a criança se cortar? A sacada está aí. E por isso que a cultura do SRE nesse caso é, deu ruim alguém fez merda, ok mas a merda, no final, desculpa meu português, tá? mas a merda aconteceu na ponta mas até ela chegar ali alguém deixou isso passar e se passou, o problema não é só daquela pessoa é de quem deixou passar mas quem deixou isso passar e se passou, o problema não é só daquela pessoa é de quem deixou passar mas quem deixou passar, não interessa é o processo então esse é o grande ponto importante o grande ponto importante, ficou bonito né a post-mortem outra coisa importante compartilhar novamente o mesmo esquema do calmes ou seja, todo mundo tem que entender o que tá acontecendo pra evitar qualquer tipo de problema futuro. Eu tenho eu tinha um amigo, agora eu tenho dois amigos que são pilotos de avião. É interessante que no condomínio que eu moro aqui, galera, tem piloto pra caramba, cara. E é muito louco ser amigo de piloto de avião, porque você conversa com ele e aí você começa a fazer aquelas perguntas, né, tipo, cara, vocês usam mesmo todos aqueles botões que aparecem? Ah, tá. Cara, aconteceu aquele acidente, o que você achou, cara? Meu, por que você faz aquela voz lá, senhor comandante, e não sei o que, por que que o ar-condicionado do avião é tão frio? Você começa a fazer aquele monte de pergunta idiota pro piloto. Mas, uma coisa, cara, que eu aprendi com ele, esse meu amigo chama Anderson, cara, o cara é fantástico. Ele tem muitas horas de voo, voou em muitas companhias aéreas, no mundo inteiro. E muitas horas de voo, voou em muitas companhias aéreas no mundo inteiro e ele também dá simulador de voos pra treinar pilotos que tão tirando licença aqui nos Estados Unidos e quando você conversa com ele ali de uma forma séria é muito interessante como que esses caras, eles tem backup, eles tem redundância e eles têm processo. É incrível como as coisas funcionam. Aconteceu isso, o outro cara pega uma checklist e fala, aperte esse botão, vire, se aconteceu isso, faça isso, se aconteceu isso, faça aquilo, se aconteceu isso, faça aquilo, se aconteceu isso, faça aquilo. E os caras são treinados pra todos os processos. Por quê? É o que ele fala. Infelizmente, eu só estou rodando esse processo porque algum avião caiu e morreu um monte de gente. Alguém entendeu porque o avião caiu. E agora, quando acontece isso, o que vai rolar? A gente consegue prevenir. E o tempo todo os caras têm treinamento. Por quê? Porque cada hora descobre um problema, descobre um negócio e eles conseguem compartilhar isso pra tudo quanto é lugar. Tá? E a gente vê isso em várias áreas, cara. A área de aviação é incrível como que os caras têm isso, né? Por quê? Porque você consegue prevenir um monte de problema futuro. O grande ponto é que na maioria das empresas, essa parte do compartilhar parece lindo, né? Falar, ah, é compartilhar, vamos melhorar a comunicação. Cara, compartilha o caramba e melhora a comunicação, nada, cara. É filosofia, é tudo isso. Cara, na real, na prática, não acontece. Se essa parada não for feita de forma intencional não acontece, não adianta ter um pós-mortem e caiu um sistema, e daí eu botei lá no meu na minha documentação na issue do github ou no no meu confluence, não interessa se isso não for feito de forma intencional esse compartilhamento não vai acontecer porque as pessoas não tem um radar pronto pra descobrir que aconteceu um incidente que aconteceu aquilo, não, o alarme tem que apitar, todo mundo tem que saber o que aconteceu, tem que ter grupos pra todo mundo se comunicar as coisas tem que ser muito mais claras e isso é em qualquer área, galera, eu vejo aqui na Full Cycle, a gente não é uma empresa grande, galera, direto dá uns rolos gigantes aqui, eu não tô falando na área de desenvolvimento, às vezes na área de desenvolvimento também mas na área de marketing, na área de vendas cara, tudo é problema de comunicação na maioria das vezes problemas bestas que acabam acontecendo em qualquer tipo de empresa por conta de comunicação, então se essa parada não for intencional é lindo, né a minha cultura é compartilhar cara, velho, se a sua cultura é compartilhar, você tem que fazer isso de forma intencional, se você não tá fazendo personal você não tem essa cultura, a verdade é essa tudo que você não faz de forma intencional, na realidade vocêissional, você não tem essa cultura. A verdade é essa. Tudo que você não faz de forma intencional, na realidade você não faz. Você faz na cagada. A real é essa. Entendeu? Se você é magro e não faz exercício físico e não faz dieta, saiba que você é magro na cagada, cara. Porque se uma pessoa não tem o biotipo igual o seu, ela vai engordar e acabou. Simples assim. E se você é gordo, cara, você também não é gordo à toa. Eu digo isso com gordo, ex-gordo, sei lá, como vocês queiram me chamar, entendeu? Então, tudo que você não faz de forma intencional, você não faz. A real é essa. Você faz sem querer. E isso é deixar pra sorte. E se você tá falando em SRE, que é garantir confiabilidade, você não pode deixar nada para a sorte. Basicamente, eu acho que é essa que é a grande sacada. E um outro ponto aqui que é importante é errar. Mas o erro aqui é controlado. Então, tem muita gente que fala que a beleza do SRE mas o erro aqui é controlado tá? então tem muita gente que fala que a beleza do SRE é a cultura de poder errar daí você fala assim cara velho, vai pra qualquer empresa desse mundo e fala, cara você gosta que o seu time erre? entendeu? você gosta que o seu time erre? eu falei, claro que não se eles pudessem acertar todas, eu queria. Já pensou? Eu na minha empresa, ninguém errar. Né? E daí falaram, não, mas... Errar é cultural, né? Porque quando a gente erra, a gente aprende coisa nova. Tá, mas e se não errasse? Não ia ser melhor ainda assim? Né? Seria seria muito melhor, mas o ponto que não é possível, mas já que você vai errar esse erro, ele tem que ser da forma mais controlada possível porque mesmo sendo controlado, errar já é um erro, quando acontece de forma descontrolada, é porque a coisa foi pra casa do chapéu, no final das contas é essa, o que é errar de forma controlada? é você fazer testes específicos pra verificar algumas algumas suposições que você tem né? E que esse tipo de erro vai gerar esse impacto e esse impacto que acontecer não vai ferrar aqui o meu error budget, o meu SLA o meu SLO essa que é a grande sacada e novamente, é outra coisa linda falar isso erre de forma controlada cara, é difícil pra caramba errar de forma controlada, porque errar já é fácil agora falar pra mim que se controle pra você errar, né, você pode errar, mas só aquele pouquinho. Você quer ficar fora do ar? Só 10 milissegundos. Depois a gente vê. Cara, é difícil pra caramba. Então, novamente, se essa parada não for intencional, você não vai errar de forma controlada. Você vai continuar errando como você sempre errou. O erro controlado é pra testar hipóteses, pra evitar como você sempre errou. O erro controlado é para testar hipóteses para evitar ou melhorar um determinado processo. E na hora que você vai testar essa hipótese, ela pode dar certo ou pode dar errado. Se der errado, você sabe que você errou, ferrou um pouquinho ali, mas você sabia que você tinha esse custo, esse preço a pagar. Então, esse é o tipo de coisa. Então, tudo preço a pagar tá, então esse é o tipo de coisa, tá, então tudo que a gente acaba falando, tá, se a gente fosse organizar a ideia do SRE galera eu traduziria SRE como ter clareza do que está acontecendo na empresa, no seu software, na sua operação. Quando eu consigo ter essa clareza de verdade, eu consigo ter N opções para começar a melhorar aquilo que eu preciso melhorar para garantir a confiabilidade nos sistemas. Então, tem algumas coisas importantes que eu queria que vocês anotassem rapidamente antes da gente finalizar, galera. Mas tem algumas métricas que eu queria que vocês soubessem muito, provavelmente muitas delas vocês já sabem, mas vale como uma checklist rápida pra você ter aí, tá? Disponibilidade, tá? Que é o tempo que o sistema está funcionando, a latência, que é o tempo de resposta nas suas requisições, taxa de erro, ou seja, a taxa de erro baseada nas requisições que estão falhando, capacidade, ou seja, uso de recursos, baseado na capacidade total. Ou seja, eu tenho uma máquina com 10 GB de RAM, estou com 50 GB de RAM sendo utilizado, ou seja, tenho 50%. Essas são dados que você tem que estar claro num dashboard para você. Baseado na minha capacidade computacional hoje, quanto que eu estou utilizando? A minha taxa de erro está quanto? Quanto que está a minha latência? Quanto que está a minha disponibilidade? Esses são dados que você tem que estar muito claro. E aí, a gente começa a entrar em algumas outras métricas, por exemplo, MTTR, que métricas, por exemplo, MTTR, que é Mean Time to Recovery, tá? Que é o tempo médio pra gente resolver esses incidentes. Agora, essas métricas aqui, elas são bem claras e simples e é interessante como a gente, em muitos sistemas, a gente não tem. Mas quando a gente está pensando em métricas pra gente finalizar, existe uma parada chamada de Dora Matrix vocês já ouviram falar em Dora Matrix? eu já até inclusive gravei um vídeo no canal do YouTube falando sobre isso tá? então esse aí é um ponto importante aqui para vocês Dora, tá? o que que no final das contas, DORA Matrix significa, tá? Existe, depois vocês buscam, que é a DevOps Research and Assessment, tá? Eles pegam grandes empresas e começam a tentar olhar essas empresas através de algumas métricas pra ver como que acaba tendo o seu processo de produtividade, eficiência e de forma geral. E os caras têm algumas métricas que são interessantes vocês saberem que existem e eventualmente poder utilizar. Uma métrica é chamada de LTCM, ou você pode chamar que é Lead Time for Changes. Tá? O que que essa métrica diz aqui pra mim? Basicamente, ele mede o tempo em que você fez um commit daquela funcionalidade do seu código até aquele código ir pra produção. Tá? Ou seja, o tempo que demorou pra, desde quando eu deixei algo pronto, pra ele ir pro ar. Basicamente, o objetivo nesse caso é avaliar o quão ágil tá a sua equipe pra entregar valor. Porque, se eu faço as coisas, as coisas não foram para o ar, o que adianta? Eu estou com baixa agilidade. Agora, eu faço um negócio, o negócio já vai para o ar, cara, eu consigo entregar valor muito mais rápido. Então, o grande indicador nesse caso é que os times que têm um lead time de horas, ou pouquíssimos dias e muito longe de semanas são times que tem um bom desempenho aí a gente tem uma outra métrica que é deployment frequency ou seja, a frequência de deploys que a gente acaba fazendo ou seja, ele acaba medindo quantas novas alterações, quantos novos deployments que você acaba fazendo em produção. Novamente, qual que é o objetivo? Entender a cadência que as nossas equipes, elas entregam as funcionalidades e eventuais correções. Uma coisa que é interessante com isso, galera, é que essas métricas DORA aqui, elas podem ser feitas por equipe e não pela empresa inteira. Então, eu posso avaliar equipes diferentes trabalhando em contextos similares e eu consigo avaliar como estão as métricas comparando uma equipe com a outra. Então, isso é um parado importante. Legal? Ou seja, um time que tem alto desempenho, muitas vezes eles fazem diversos deploys diariamente. Não é que nem o caso da galera... Bom, não vou falar. Aí a gente tem outra métrica, que é o Mean Time to Recovery. Que no final das contas, é o famoso MTTR. Que é o seguinte, é o tempo médio de recuperação. Ou seja, quando deu pau num serviço e o meu sistema teve uma falha ou um incidente, quanto tempo eu demorei pra me recuperar desse incidente tá, então isso aí é um ponto importante aqui pra gente, legal? ou seja, o objetivo aqui é avaliar a capacidade que a equipe tem de lidar com o problema e restaurar as paradas pra elas voltarem pro ar, tá, então isso aí é um ponto importante. Normalmente dizem que os times que conseguem resolver incidentes em menos de uma hora são times bons, tá? Somente para vocês saberem. E tem também outra, que é a quarta métrica, que é o Change Failure Rate, tá? Ou seja, a taxa de falhas De mudança Ele mede a porcentagem da mudança Ou seja, das implantações Em produção Que resultaram em falhas Como assim? Não adianta nada eu fazer 10 deploys Por dia, para dizer que eu sou ágil Mais desses 10 deploys 9 em Deurumpau. Concordam comigo? Então não adianta eu falar que eu tenho um bom desempenho aqui em deployment frequency, se o meu change failure rate está ruim. Está dizendo apenas que eu estou fazendo muito deploy, mas que os meus deploys são muito cagados. A real é essa que está acontecendo, entendeu? Então por isso que essas métricas, elas não podem ser vistas de forma isolada, elas têm que ser vistas em forma em conjunto, porque senão é muito claro, né, que as coisas acabam não tendo sentido, tá? Normalmente, taxas de falha, se eu não me engano, menor que 15%, é ligeiramente aceitável pra uma boa equipe basicamente, se eu não me engano, é isso tá agora galera, se vocês começarem a perceber é, vocês conseguem verificar que apesar de a gente ter falado bastante de DevOps quando a gente começa olhar esses tipos de coisa, não são coisas apenas de desenvolvimento ou só de operação são coisas que verificam a capacidade da equipe de entregar do sistema ficar no ar de eu conseguir controlar minha capacidade computacional em gastar muito dinheiro com orçamento de eu evitar erros bobos, de eu testar de forma controlada e saber até onde eu posso errar. Então, por isso que eu digo, não dá pra colocar SRE e DevOps no mesmo balaio. Eles estão diretamente ligados, mas o papel dessa parada é diferente. Então, toda vez que alguém fala, ah, eu trabalho com DevOps e SRE. Aí você tem que pensar, tá, explica melhor. É DevOps ou SRE, ou qual mais a parte que você está trabalhando ali? Porque é muito genérico você simplesmente falar DevOps e SRE quando você tem clareza do que é DevOps e o que é SRE. Dá para perceber que o foco do SRE é diferente do foco do DevOps. Mas é muito claro que não dá para trabalhar ou ter o papel de SRE sem o DevOps. Tanto que grandes ferramentas que são feitas para automatizar os nossos processos que fazem parte do DevOps, são criados pela área de SRE. Então, acho que esse aí é o grande ponto. Às vezes dá um nó na cabeça, mas quando você pensar em SRE, pensa em confiabilidade independente do que está acontecendo. Basicamente, é isso que vocês têm que acabar colocando. Beleza, galera? E, pessoal, o Leonan passou a lista de espera. Leonan, se você puder passar de novo, cola aí no chat para a galera, tá? E quem tiver participado aí de todas as aulas, amanhã a gente vai ter uma mentoria aberta, basicamente a gente vai falar de carreira, de coisas técnicas e vai ser um momento muito bom, porque não é só aula só coisa densa, conversando esse tipo de coisa, mas é algo que todo mundo pode aprender em conjunto a gente já fez diversas sessões desse tipo e normalmente elas são muito proveitosas. E eu vou tentar trazer um convidado especial e bem famoso e que vai ajudar, vai gostar bastante de participar e vocês vão gostar também, tá? Então, por favor, assinem essa lista e tem algo importante novamente eu queria falar. Se você tá na dúvida, escaneie esse QR Code, tá? Fale com a nossa equipe. Porque você pode, tá? Nessa pré-matrícula do MBA, conseguir desconto para você começar nessa nova turma, agora, em fevereiro. E aprender, obviamente, muito mais do que tudo isso que eu acabei de falar aqui pra vocês. E também, né, eu vou pedir também depois pro Leonan colocar aí pra vocês além da lista de presença, a pesquisa de satisfação, o NPS. O que acontece? Cada vez que você preenença a pesquisa de satisfação o NPS o que acontece? cada vez que você preenche essa pesquisa pra gente, galera é muito importante, por quê? porque a gente tá lendo todas as respostas a nossa ideia é a gente sempre melhorar, né? não dá pra tá muito longe de fazer um evento e ser as coisas totalmente perfeitas não dá pra agradar todo mundo, mas, de forma geral, a gente quer ouvir, a gente quer entender. Então, por favor, dê um feedback da aula de hoje. Está aí o link no chat para todo mundo. O Leonan acabou de colocar. Clique, dê esse feedback honesto com a gente, porque eu não tenho dúvidas que vai ajudar bastante, me ajudar, ajudar toda a equipe que preparou todo esse evento aqui pra vocês, eu só sou a ponta da lança, porque pra fazer tudo isso acontecer, teve muita e muita gente por trás desde a parte de comunicação marketing, manter as coisas funcionando, o Leonan, todos os dias dessa hora, o Aleph, cara, tem uma galera gigante aqui que tá ajudando pra tudo isso acontecer, e queria agradecer toda a equipe nossa aqui da Full Cycle mesmo, porque eu gosto muito de fazer o que eu faço, mas jamais seria, nem de longe, seria capaz de fazer qualquer coisa parecida com o que a gente está fazendo, se eu não tivesse uma galera top aí por trás mantendo as coisas funcionando, tá? Então eu queria agradecer toda a equipe também aí que tem ajudado. E também, obviamente, né, não tem evento se vocês também não estivessem participando. E uma coisa que normalmente eu gosto de falar sempre é não é porque algo é de graça que é um investimento. A pior coisa que tem é quando você pega algo de graça e que você não usou ou que você gastou simplesmente o seu tempo e não gerou valor nenhum pra você. Tá? Então, eu quero agradecer de forma, assim, da forma mais honesta possível de todo mundo que conseguiu participar desses dias, que a gente teve sessões aqui super longas e eu tive e tenho o maior prazer de fazer isso. É o que eu gosto de fazer do coração mesmo e eu sei que se tem gente voltando é porque de alguma forma isso gerou valor tá, então queria agradecer que vocês estão aí porque se você tá aqui agora é porque de alguma forma você tá investindo o seu tempo, você poderia tá assistindo televisão nesse momento. Isso não significa que não tem alguém olhando para a tela do computador e olhando a TV também ao mesmo tempo. Ou não estar com dois monitores assistindo Netflix e assistindo aqui também. Mas, de forma geral, você está aqui na sala, vi muita gente anotando, um monte de gente participando aí no chat. Então, queria agradecer aí todo mundo por ter participado e tá participando amanhã a gente vai ter mais uma sessão é uma sessão muito mais light uma sessão menos densa hoje eu acho que foi um dos dias mais densos que teve mas galera, eu poderia ter escolhido ficar mostrando um monte de ferramentinha aqui pra vocês sério mesmo, ia ser até mais popular porque todo mundo ia sair com um monte de ferramentinha aqui pra vocês. Sério mesmo. Ia ser até mais popular. Porque todo mundo ia sair com um monte de código fonte, uma ferramentinha pra clicar e testar. Mas na real, eu queria muito ter tido essa aula, tá? Queria muito ter tido essa aula algum tempo atrás. Porque demorou muito pra mim, pra eu conseguir ter esse nível de clareza e novamente, eu estou longe de chegar perto de um Fernando da Vida, do André Omar, do Manuel que dá aula do nosso MBA na área de DevOps SRE, se você olhar as apresentações dele, a aula dele, o nível de profundidade que as coisas vão é muito maior do que isso que eu acabei de mostrar mas eu acho que pra vocês conseguirem ter uma visão geral eu acho que essa aula foi uma bela de uma introdução pra mostrar aí a ponte a ponta do iceberg, tá? então isso pra mim é sabe aquela parada que às vezes é mais fácil você ser popular mostrando as coisinhas hype, um monte de coisinha, porque a gente adora essas coisas, a gente que é desenvolvedor, né? Mostra uma ferramenta, mostra uns negócios rodando, olha isso aqui, cara, todo mundo fica, pô, maluco. Eu adoro ver essas coisas, né? Mas, no final do dia, cara, essas ferramentas todas vão passar, vão morrer, vão ser trocadas, vão ser descartadas. Eu já vi essa fita um monte de vez. Mas esses tipos de conhecimento aqui, eles são cumulativos. A gente vai colocando, guardando no bolso. Meu professor de bateria, ele fala assim, ó, você aprendeu essa virada, né? Guarda bem, bota ela no bolso. Quando aparecer uma outra música que você acha que coube, meu amigo você faz ela, você vai aprendendo e vai botando no bolso, então eu acho que o que vocês aprenderam aqui hoje, dá pra colocar muita coisa no bolso, porque em algum momento vocês vão usar, em algum momento vocês vão ouvir os termos em algum momento isso pode te ajudar numa entreviro, em algum momento pode ajudar você a implantar um projeto novo que você está pensando e está tentando organizar como que as coisas vão funcionar, tá? Então a ideia é que vocês tentem colocar no bolso, tá? Esses conceitos, esses principais pontos aí pra vocês e de coração mesmo, tá? Eu agradeço todo mundo e agradeço duas vezes pra quem escanear o QR Code, entrar em contato com a nossa equipe e agradeço três vezes ainda quem se matricular e a gente poder se encontrar mais vezes aqui, né? Mas como aluno aí da FCTec pra conseguir estudar com a gente durante um bom tempo aí. Tá bom? Show de bola, galera? Então, pessoal, muito boa noite aí pra vocês, até amanhã, porque amanhã tem mais, cara, não acabou, e eu espero que vocês tenham aprendido bastante aí, espero que... Tô curioso, na real, tá? Sendo bem honesto com vocês, eu tô bem curioso pra ver como é que vai ser o feedback. Essa foi uma das aulas que eu pensei muito como que eu ia apresentar. Eu pensei muito como que eu ia apresentar. E eu falei, eu vou apresentar de uma forma densa, mas que eu acho que é da forma que as pessoas pelo menos precisam entender esses conceitos do que ficar mostrando ferramenta eu tinha um planejamento no início, eu mudei e resolvi fazer desse jeito porque na real tem muita gente que não sabe desses pontos e tá focando muito em ferramenta e acaba perdendo conceito das coisas, ferramenta e a faz, esses conceitos vão ajudar. Ferramenta IA faz. Esses conceitos vão ajudar a gente pedir pra IA fazer pra gente. Então, esse que é o negócio. Maravilha? Galera, muito boa noite. Escanei o QR Code. Quero ver você no nosso MBA com a gente. Se você não sabe o que é um MBA em arquitetura full cycle, vou pedir também pro Leonan colocar aqui no chat o endereço mba.fullcycle.com.br. Lá tem todas as matérias, todas as explicações e a gente está no momento de pré-venda, onde você consegue pagar mais barato para começar agora em fevereiro na nossa turma. Fechou? Boa noite, galera. Tudo de bom para vocês. Fiquem com Deus. Tenham uma ótima semana. Espero aí que vocês tenham aproveitado a sessão de hoje. Valeu, galera.