Bom, pessoal, como eu falei para vocês, chegava num momento que isso aqui era insustentável. Então, o que a gente começou a ter a partir de um momento? Deixa eu até traçar uma linha aqui, só para deixar bem claro que o panorama nesse momento mudou. E aí a gente chegou nessa parte de cultura DevOps. Primeira coisa, por que a gente tem esse nome DevOps? Basicamente, é juntar o dev e operação. Para que esses caras pudessem trabalhar em conjunto. E para isso, o que a gente tem aqui? A gente precisa um. Tá? A gente precisa de que o desenvolvedor entenda o mínimo de infra operação e etc. Ok? E do lado do desenvolvedor, não sei nem por que eu pintei a corzinha aqui, mas eu preciso que o cara de infra tenha o básico de desenvolvimento. Porque no final das contas, nesse momento a gente cai numa necessidade muito grande, que é o quê? Tooling. Então quando a gente está falando em DevOps ou SRE ou qualquer coisa desse tipo, a gente está falando desses caras trabalharem em conjunto o tempo inteiro. Ou seja, que a empresa realmente tivesse uma cultura de fazer um processo de melhoria contínua pra que esse ciclo ele acontecesse mais rapidamente. Ok? E quando esses caras, eles conseguem trabalhar junto, ou seja, a área de dev e a área de operação, a gente diminui toda essa fricção. Né? E quando a gente diminui essa fricção, a gente tem a possibilidade de melhorar muito mais os processos, se todo mundo entender um pouco de tudo. E aí a gente precisa de algo no final das contas que é chamada de tooling. E o que que é tooling no final das contas? É ter ferramentas, processos, automações para que tudo isso aconteça de forma mais fluida então, no final das contas o que que acontece? quando eu chego nesse momento de dev, qa e etc tudo isso existe até hoje, normalmente a área de qa existe mas build e release monitorar e tudo isso, eles acabam fazendo parte de um ciclo muito grande. Por quê? Porque aqui o desenvolvedor já vai começar a trabalhar com práticas, ou normalmente a gente chama isso de awareness com mais conhecimento do ambiente de produção até a gente chegar em momentos onde nós chegamos com containers por exemplo, eu estou dando um exemplo de containers, se eu desenvolvo muito próximo ao ambiente em que esse software vai pro ar a chance de dar problema é muito menor mas quando isso começa a acontecer eu obrigatoriamente, eu tenho que conseguir entender melhor sobre esses ambientes, um pouco melhor sobre a estrutura, a parte de rede, a parte de comunicação entre um sistema e outro. Então eu preciso e sou forçado a deixar esse ambiente o mais próximo possível de produção. E se isso acontece, naturalmente essa parte aqui ela vai funcionar um pouco melhor. A área de testes, ela sempre existiu e ainda sempre, e ela ainda existe em muitas empresas. Mas o desenvolvedor aqui nesse momento, ele é obrigado também a testar de forma automatizada. Por quê? Porque se eu testo isso de forma automatizada, as principais operações, eu tenho menos risco de ter problemas em produção. Certo? Menos risco. Agora, o grande ponto é que quando eu testo de forma automatizada, grande parte dos problemas que eu acabo tendo aqui, eles já são resolvidos por padrão. O que eu preciso garantir é que antes desse cara entrar em produção, esses testes e tudo que acontece aqui, eles acabam sendo mitigados pra caramba. Então, esse aí é o grande ponto da situação. Bacana? Então, uma vez que isso começa a acontecer, essa área que normalmente ficava fazendo o build e o release, o que que acontecia? Esses processos, eu vou tirar acontecia? Ela, esses processos, tá? Eu vou tirar o QA daqui, tá, pessoal? Mas eu não tô querendo dizer que essa etapa aqui não possa ter QA, tá? O que eu tô querendo dizer aqui é que nessa etapa aqui, a gente começa a ter um processo um pouco separado, tá? E qual que é esse processo separado nesse momento? Esse processo se chama de CI e CD. Ou seja, deploy, integração contínua, e deploy contínua, né? Acredito que você já trabalhe nesse formato nos dias de hoje, já entenda direito como é que funciona uma esteira de CA e CD, mas na real, quando o desenvolvedor sobe alguma coisa, aqui a gente testa, a gente faz o build, a gente conseguea, a gente faz o build, a gente consegue fazer o release de forma integrada testável, e pra isso aqui nesse momento, novamente a gente cai nessa situação, eu tenho tooling, ou seja, eu tenho um ferramental que me ajuda a chegar exatamente aqui nessa situação, tá? Ou seja, eu tenho exatamente caras que são desenvolvidos, feitos por desenvolvedor, que são entendidos pela área de operação, que a área de operação também desenvolve em conjunto, ou só ela, porque ela também entende um pouco de desenvolvimento. Então, quando a gente acaba caindo nesses aspectos, as coisas começam a funcionar melhor. E aí, a gente vai para uma outra parte, que é a parte de monitorar. Mas naquela época, o que acontecia? Monitorar é soar alarme. Por que eu estou dizendo isso? Porque monitorar é, na realidade, algo reativo. O que é algo reativo? Você espera um problema acontecer, quando acontece, alguém te avisa, que nesse caso é a área de monitoramento, o monitor, os alertas, e daí você toma alguma ação. E, então, o que acontece? Atualmente, a gente adicionou um cara aqui, que é monitorar e observar. O que isso significa? O monitoramento é quando eu fico esperando algo acontecer. O observar é entender o porquê realmente isso aconteceu. Porque daí esse tempo aqui de recuperação vai ser muito melhor. esse tempo aqui de recuperação vai ser muito melhor. E para que isso aconteça, o desenvolvedor também tem que conseguir, nesse caso, entender o que está acontecendo com o sistema. Então, o desenvolvedor, nesse momento, tem que entender mais de servidor, ele tem que entender de utilização de logs, ele tem que entender mais de servidor, ele tem que entender de utilização de logs, ele tem que entender a parte de comunicação, tracing, ele tem que conseguir olhar no final das contas tudo o que está acontecendo no sistema que possa afetar a aplicação. Inclusive, métricas de um servidor. Como que está a CPU, como que está a memória, às vezes o sistema mudou, começou a exigir mais recurso computacional. Então, nesse momento, tanto a área de operação precisa monitorar e observar, quanto o desenvolvedor precisa monitorar e observar. E para que isso aconteça, esse cara aqui tem que nascer aqui dentro. Essa parte aqui tem que nascer obrigatoriamente aqui dentro. Se ela não nasce aqui dentro, o que isso acontece no final das contas? É se observar acaba se tornando impossível. E ele acaba se tornando impossível por um único caso, um único sentido. É porque eu não tenho, no final das contas, condição de fazer com que eu tenha insumos o suficiente para eu fazer esse observar, que hoje a gente chama de observabilidade. Então, quando a gente cai nesse momento, a gente acaba gerando essa cultura de integração, ou seja, o desenvolvedor e a operação, eles trabalhando em conjuntos de uma forma muito mais harmoniosa e processual, onde uma área entende um pouco melhor da outra, fazendo com que o fluxo de trabalho acabe trabalhando em conjunto. Legal? Então é gerada essa cultura. O grande ponto é que, num momento, isso acaba virando um cargo também. A gente vai falar isso em seguida e depois a gente vai entrar na área de SRE, tá bom? Vamos nessa.