Bom, pessoal, a gente começou a falar muito sobre a cultura de como as coisas começaram a trabalhar. Mas o que acontece? A necessidade de tanto deploy todo dia, de tanta mudança em sistema todo dia, fez com que esse processo às vezes começasse a virar um caos. Por quê? A gente precisava de ferramentas, desenvolvedores que tivessem conhecimento de infra, caras de infra que entendessem mais de desenvolvimento, e a gente começou a ter caras mais coringas. Pessoas que são especializadas cada vez mais nesse tipo de fluxo. O cara ele entende muito bem às vezes de observar a aplicação, ele entende um pouco mais de infraestrutura, o desenvolvedor consegue fazer o setup de servidores, o cara de infraestrutura consegue olhar código e ajudar a desenvolver e criar ferramentas. Então, chega num momento entre que a gente começa a ter o cargo de DevOps na empresa. Ou seja, onde as próprias empresas falam, eu preciso de pessoas dedicadas só para isso. Não adianta eu pegar um desenvolvedor ou outro cara, eu preciso de uma área, eu preciso de alguém especialista nisso. E aí, nesse momento, a gente começa a ter cargos nessa área de DevOps especializados em fazer o quê? Esses tipos de fluxo. Então, esses caras, eles conseguem entender esse fluxo, eles conseguem trabalhar com diversas ferramentas, eles criam ferramentas, as grandes empresas começam a criar iniciativas para que esse processo seja cada vez mais fluído. E, então, começa esse mundo do DevOps. A parte mais louca é que chega num momento que a gente começa a adicionar algo aqui, que é a parte de SEC também, que é a parte de segurança. Então, só para você saber que no meio dessa esteira aqui, a gente também começa a lidar um pouco mais com a parte de segurança. O que isso significa? Significa que existem diversos layers que a gente começa a perceber que o software, né, ele começa a ter problemas que são muito comuns. Bugs, esquecer código de API dentro do código, utilizar bibliotecas que tenham problemas de segurança e que não é necessariamente problema do desenvolvedor que está desenvolvendo o software em si, mas sim das dependências. Eu consegui ter uma lista bem clara, algo que normalmente a gente chama de S-BOM, com todos os detalhes de tudo que está sendo utilizado no software, licenças e tudo mais. Eu preciso de scanners, ferramentas de análise estática de código para fazer diversas verificações, então cada vez esse processo vai ficando mais complexo. O fato é que quando essa cultura é estabelecida e essas pessoas que começam a trabalhar nessa área de forma mais específica, elas começam a entender melhor esse fluxo e tudo isso acaba gerando muito, mas muito benefício para as empresas. Porém, o que acontece? Esses caras estão focados no quê? Na solução que está sendo desenvolvida. Ou seja, no universo do software ou da área que eles estão trabalhando. Então, isso aqui é um ponto importante para você entender. Esses caras, eles têm o universo do software. Então, isso aqui é um ponto importante. Eles têm o universo do software. Então isso aqui é um ponto importante, eles têm o universo do software. Então aqui eles estão pensando no software funcionar, ou seja, principalmente nos processos de implantação. Ou seja, o software é implantado, eles conseguem monitorar quando algum problema dá, ou monitorar, inclusive, esse software e entender os principais problemas. Mas o objetivo deles é um objetivo muito mais técnico aqui para a gente. Agora, o fato aqui é que chega num momento que aquela pergunta de quem é a culpa, ela começa a voltar porque muitos erros acontecem. Então, a gente começa a ver demoras em partes específicas do processo. Ou seja, uma esteira que demora quando um problema está no ar, do tempo que eu comecei a desenvolver até aquele software estar em produção, ele demora um pouco mais. Quando acontece um incidente, quanto tempo eu fiquei fora do ar? Como é que eu consigo garantir mais qualidade naquilo que eu estou fazendo para fazer com que tudo aquilo comece a melhorar. Então, a gente começa a ter outras necessidades. E essa necessidade, no final das contas, ela acaba entrando num contexto parecido com o desses DevOps, porque a parte de subir o software, garantir ali que ele está funcionando, sendo observado, ela está coberta. Mas ele é um objetivo muito técnico no aspecto de simplesmente fazer o software funcionar e ficar rodando no ar. As preocupações estão ali focadas nisso. Mas existem outras consequências quando esse fluxo não está funcionando muito bem. E aí a gente vai para um outro ponto que é chamado de SRE. E a gente vai ver isso no nosso próximo vídeo.