Bom pessoal, seguinte no vídeo anterior a gente estava contando a história e o panorama geral quando a gente estava falando do mundo, como que o mundo era há algum tempo atrás, e na realidade esse mundo ainda existe mas ele tende a mudar ou deixar de existir ao longo do tempo, então é o seguinte, a gente chegou no momento de, de quem é a culpa? O momento crítico, as pessoas discordando, né? E quando eu falo brigando, tá? O antagonismo eu não tô falando do lado pejorativo, o pessoal saia na porrada e ficava xingando um outro. Às vezes acontecia, mas na real, o ponto é que são objetivos diferentes. Mas, pega um momento que o problema tem que ser resolvido. Então, a gente precisa resolver o incidente. Então, nesse momento, aconteciam algumas coisas bem claras. A primeira coisa é que a galera de infraestrutura não entende do software de forma geral. Normalmente eles têm alguns scripts, algumas documentações, algumas checklists para eles verificarem quando tiver algum problema. Mas no final das contas, ele não entende do software. Então, ele realmente também, muitas vezes, tende a dizer que deve ser algo que mudou no software e que eu não consigo ver e nesse momento eu preciso de desenvolvedor. eu preciso de desenvolvedor. E quando a gente chama esse desenvolvedor em conjunto com o cara de infraestrutura, o desenvolvedor fala, eu não entendo de infra. Talvez possa ser o banco de dados, pode ser servidor, configuração e etc. Então, tem um gap de conhecimento muito grande entre essas duas áreas. Então, nesse momento, esses caras batem cabeça, sentam juntos e aí até conseguir chegar na solução. Então, eles resolvem esse problema e daí, nessa hora, vai ter uma discussão, obviamente, no bom sentido, pra sentar junto, entender, e quando essas duas coisas acabam se juntando, normalmente o problema é resolvido mais rapidamente, independente de qual área. O grande ponto é que se a gente perceber nos dias de hoje, às vezes o problema que acontece num software, o problema não necessariamente era um bug do desenvolvedor ou uma forma errada de como a pessoa operou o software. Às vezes acontece que nem um efeito cascata. Às vezes o problema realmente é dos dois. Uma configuração, uma mudança que o desenvolvedor fez que gerou um pequeno bug e esse bug não era visto em produção, não estava na checklist do cara de infraestrutura, ali para ele não trazia nenhum log, não trazia nada, e aí de repente o que acontecia, o cara de infra, também ele não tinha essa capacidade de entender configurações, etc. Muitas vezes o que ele tinha é um arquivo jar do Java, que ele subia, fazia o deploy e daí a coisa era para estar funcionando. Então eles resolviam esse incidente falando, ah, o problema estava nessa configuração e essa configuração não conseguiu ajustar no servidor e alguma coisa desse tipo. Então, o que acontecia, eles resolviam esse incidente em conjunto. O problema é que o tempo de falha nesse momento, o tempo onde o sistema ficou fora do ar, ele acabava sendo muito grande. E aí, nesse caso, acabava gerando problemas de grana, problemas de clientes bravos, e assim por diante, acabava afetando a empresa. O ponto aqui é, como que eu consigo melhorar esse processo e assim por diante, acabava afetando a empresa. O ponto aqui é, como que eu consigo melhorar esse processo, fazer com que isso acontecesse de forma mais rápida, mais fluida e também de uma forma que quando a gente tiver erro, nós conseguíssemos fazer essa recuperação desse incidente de uma forma mais rápida, tá? E eu tenho uma observação muito importante aqui pra vocês, pessoal, que era o seguinte, nessa época, né, era deploy uma vez por mês, uma vez por mês. Trimestre, semestre. Ou seja, o deploy não acontecia na maioria das vezes diariamente. Era toda uma preparação para o famoso dia do deploy que as coisas iriam acontecer. Então, isso acontecia e já tinha todo esse problema quando um deploy às vezes acontecia. Agora, imagina nos dias de hoje, onde a dinâmica e a tecnologia é ainda mais utilizada do que antigamente, onde acontecem muitos e muitos deploys. Então, se você olha, mercado livre é 10, 15, 20 mil deploys ali por dia. Como é possível uma área de infraestrutura conseguir fazer tanto esse ciclo, que normalmente, inclusive, era até manual, óbvio, sempre teve scripts e ferramentas que automatizavam, mas conseguir dar vazão para isso era quase que impossível. Mas chegou um dia que isso acabou virando insustentável. Então, vamos para a outra parte do nosso vídeo, onde eu vou falar, trazer a ideia do DevOps para você entender realmente, de de verdade o que é o DevOps e depois em seguida o que a gente faz a gente traz alguns exemplos e depois a gente vai pra outro momento que é o famoso momento do SRE, fechou? então vamos nessa