SRE e Observabilidade: A Jornada Real da UNICRED

0:00conflitos. Ali, ah, eu preciso de um SRE, mas não sabia se era o SRE que cuidava da plataforma, se era o SRE que fazia um papel de devops ou se era um SRE no monitoramento ou se era na observabilidade. Então, gerava esses conflitos. Acho que uma das primeiras coisas que a gente tem que ter de objetivo com relação a pipeline de DevOps e infra como código no geral, é, acho que até mais do que elas sejam sofisticadas, é elas sejam consistentes.

0:24Na real, nós conseguimos amarrar todas as dificuldades que nós temos e então muitas vezes em padronizações e governança, né? Em resumo, tu consegue canalizar ali literalmente dizendo assim: "Cara, faz isso que vai dar certo". Você vai cada vez mais pilotar os agentes para desenvolver esse código para você do que você de fato começar a escrever código. Muito bem, muito bem, meus amigos do PPT não compil. Estamos aqui para mais um episódio e hoje aqui do meu lado está o Bruno da Elvin fazendo, fazendo as vezes de cohost pela primeira vez, hein, Brunão? Verdade, uma nova experiência aí, mas tô animado aí com conteúdo, com uma turma muito boa, que tem uma jornada interessante para compartilhar.

1:05É verdade. Hoje a gente vai entender aqui uma jornada de maturidade, de operação de tecnologia que os caras prometeram que vão abrir um monte de coisa aqui pra gente, vão ser bem transparentes, né?

1:16Isso, sem tomar atalhe, né? Vivendo aí as experiências com todos os desafios mesmo.

1:22É isso aí. Hoje a gente tá aqui com o Mesquita e com o NES da Unicred, uma cooperativa de crédito e que passou por uma grande jornada de evolução aqui da operação de tecnologia.

1:36Dá um oi aí pra galera, Mesquita. Fala, fala aí um pouquinho de você, cara.

1:40Bom, eu sou o Fábio Mesquita, mais conhecido como Mesquita, né? Estou, né, na área de TI há 25 anos, aproximadamente, e vou gostar muito de contribuir aí com podcast hoje.

1:53Show de bola. E estamos aqui com o com o NES também da Unicred. Dá um oi pra galera aí, cara. Fala.

1:59Boa noite. Tudo bem?

2:00Fala de ti um pouco.

2:02Prazer estar aqui conversando com vocês.

2:03Obrigado. Eu, meu nome é Cristiano Nes.

2:06O pessoal me conhece como Nes.

2:09Tem alguma coisa a ver com o monstro do Lago Nes? Cara, eu juro que eu pensei em falar isso.

2:13Ah, mas eu falei, achei, achei que ia ficar chato, mas eu digo, cara, como é que se escreve Nes? É igual um monstro, o monstro do Lago N. Geralmente ou ele NES também é os dois. Ou Supernes.

2:27Superness. Verdade. Verdade.

2:30É, depende do ano que tu nasceu, né, cara? Então, quando É, é, é verdade. Eu, por exemplo, eu como eu já tenho muitos anos de nascido, eu consegui pegar todas as referências.

2:38Pegou todas? Os mais novos. Um é o mais perto da Supernessa. É, é exatamente.

2:44E acho que eu tô no mercado há um bom tempo também. Nem faço essas contas, mas na Unicred aí desde 2019.

2:52Show de bola. E vocês todos trabalham com com a infraestrutura, né?

2:59Eu eu atualmente eu tô atuando ali como líder ali do time de confiabilidade e DevOps sobre a gestão do Não dá spoiler saudoso mesquita.

3:09E também tá aqui com a gente o Felipe, que vai fazer uma uma transformação aqui no meio do episódio, vai vir falar com a gente aqui um pouquinho de plataforma, mas dá um oi de longe aí, Felipe.

3:22E aí?

3:24Então, sou o Felipe. Trabalho na Unicred aí por volta de uns 4 anos na parte de de engenharia de de derrops, então controlando aí as esteiras da de entrega da Unicred. Show de bola. Acho que vamos ter aqui uma grande experiência para compartilhar, né? Vamos falar um pouquinho sobre como é a operação de tecnologia, vamos falar sobre os problemas que acontecem. Fala um pouco de cultura também, né, Bruno? Como que isso rola dentro da da das empresas para ter de fato uma cultura de observabilidade, de resiliência, de tolerância à falha. Quais são as consequências que isso tem no dia a dia, no desenvolvimento de software? Como que a IA entra no meio do caminho? como que a gente evoluir para uma plataforma interna de desenvolvimento. Acho que tem bastante coisa pra gente conversar aqui e vocês que viveram e vivem isso na pele vão poder compartilhar bastante com a gente aqui. Acho que o papo vai ser muito bom.

4:19Problemas que acontecem em outro país, não aqui com a gente.

4:22É, não, aqui aqui é tranquilo.

4:23Pegar exemplos fictícios assim. Ftiços.

4:25Isso. Exato. Porque Brasil aqui a gente não tem problema nenhum.

4:28Tem tem um programa bom no Sul lá que tangos e tragédias. Então as coisas acontecem na esbia. Ah, sim. Que é um outro país.

4:37Outro país.

4:37É.

4:38Então vamos lá que o episódio tá muito bom. Mas antes, compartilha já o episódio, deixa o seu like, você pode fazer qualquer comentário, a qualquer momento que a gente sabe exatamente o horário que você comentou e etc. E eu fico responsável por eu rotear para esses caras aqui. Se quiserem fazer uma pergunta pro Mesquita, pro NES, pro Felipe, pro Brunão, coloca aí seu comentário, sua dúvida que a gente faz acontecer e ela vai ser respondida.

5:03Beleza? Se você curte o nosso trabalho, você pode ser membro também do PPT no Compila. Sendo membro, você contribui aqui com o PPT no Compila. E se você quiser contribuir também de uma forma mais objetiva, [email protected].

5:17Mas a maior contribuição sua é o seu like, é compartilhar o episódio, é fazer o nosso nossa comunidade cada vez maior.

5:26Vamos lá que o episódio tá muito bom.

5:28Bora.

5:44Antes da gente começar, eu quero fazer uma oferecer para vocês aqui a cerveja oficial do PPT não compila. Hoje, Brunão, você vai de APA e APA.

5:56É, cara, o bom de ser de casa é que você acaba provando todos esses upgrades aí do canal, né? você começa a pegar esse inventário, quando vai melhorando, né, a gente vai colhendo fruto aí.

6:06É isso aí. Tá, tá com a gente, né? Vai e colhendo as benfeitorias. Mesquita, você vai de IPA? É isso?

6:14Isso aí.

6:14Ó, aqui sua IPA Inés St. Nesse frio vai bem, hein?

6:20Aproveitar as fotos.

6:22Isso aí. Então aqui Maralto, a cerveja oficial do PPT no Compila. Se você olhou aqui, viu na câmera, ficou com vontade, a sua boca salivou, você pode ganhar também uma maralto aqui com a gente no PPT no Compila. É só você ir lá no nosso Instagram agora, manda uma DM no nosso Instagram escrito Marto, todo episódio a gente vai sortear um pack de Maralto aqui, ó, essa caixinha do tesouro para os nossos ouvintes. Você vai vir retirar aqui no estúdio e vai assistir um episódio junto com a gente. Então vamos lá com essa cerveja maravilhosa.

7:01Meus amigos, eu queria que vocês falassem um pouquinho da Unicred pra gente começar a entender, contextualizar o problema que a gente vai destrinchar aqui nesse episódio.

7:15Perfeito. Bom, eu tenho um um tempo considerável de de Unicred, né? Então tem um tem um histórico, né, de patrimônio aí, né?

7:25Patrimônio já na empresa, né? trabalhei em algumas áreas até chegar na na área de operações digitais, operações de TI, confiabilidade, DevOps, né? Eh, Unicred é uma empresa que tem o DNA do cooperativismo, né, no contexto de crédito, né, e esse DNA eu me identifiquei com valores, enfim. Então, é uma empresa muito muito boa de trabalhar eh dentro desse, desse contexto, né, de tecnologia, por ser uma instituição financeira, vocês mais do que eh eu sabem que a gente tá tem que estar sempre de acordo com regulações, né?

8:07Sim. É uma área muito regulada, né, cara?

8:09Exato. O crime cibernético tem vem evoluindo cada vez mais, né? Então a gente precisa estar sempre antecipando nas situações e convidei umas para me apoiar nessa nessa caminhada, né? Então ele também tem uma uma bagagem muito grande em relação à observabilidade, monitoramento, devops, sre, né? Então, eh acredito que a gente vem fazendo um trabalho, vem colhendo frutos, né? Elvin vem nos apoiando também.

8:45A Unicred é uma cooperativa de crédito, certo?

8:49E vocês atendem qual nicho exatamente?

8:52Quem quem é o cliente principal de vocês? Como você consegue explicar um pouquinho de como é essa operação?

8:58Sim. Eh, Unicred, o nicho é área da saúde, né? Focado em médicos, profissionais de saúde, eh, enfermagem, né? A gente vem vem trabalhando como planejamento estratégico em expandir, né? porque a área da saúde ela é muito vasta, né? Tem outras oportunidades.

9:16Eh, então o nosso público fundamentalmente é médicos. Tem algumas cooperativas, porque daí dentro do contexto Unicred, né, ela até recentemente mudou de níveis, né, ela era uma cooperativa com confederação, centrais e cooperativas, e ela eh eliminou segundo nível, então ela uma confederação e as cooperativas direto. Então, com isso, né, reduziu fricção, né, melhorou a a operação como um todo. Então, dentro desse contexto, né, de de uma confederação e cooperativas, né, algumas cooperativas, né, espalhadas pelo Brasil tem uma livre admissão, né? Exemplo, cooperativa de Mato Grosso, onde o agro é muito forte, né?

10:02Então, essa cooperativa premium capital, né? Tem outras cooperativas do sistema, né? Mas a grande maioria é somente o nicho da saúde.

10:12Entendi.

10:12Né? Como cooperados. Entendi. Então o o médico, ele fazendo parte, o médico, enfermeiro, etc., profissional de saúde, fazendo parte dessa entidade de classe, ele pode participar da cooperativa e aí ele tem acesso a taxas melhores.

10:30Eh, é mais ou menos isso o espírito, isso, né? É o conceito básico do cooperativismo, né? Onde eh se não se tem lucro, né? Todo todo o resíduo, né?

10:42do que a gente chama de sobras, né?

10:45Então a gente paga a operação, investe, né, em evolução e o que sobra é dividido entre os cooperados, né? Então além disso, claro, né? Taxas mais atrativas, né? A gente tem tem uma regulação, né?

10:59em relação ao ao BASEN, não tem muitas diferenças tributárias em relação aos grandes bancos, mas tem algumas mudanças assim que são pontuais, mas que são entendi eh que trazem benefícios, né, para pro cooperado.

11:13E e Nés, como que é essa operação olhando pra tecnologia, que que sustenta isso, isso tudo, olhando falando de infraestrutura, aplicações, etc? Acho, acho que uma coisa até interessante ali que o Mesquita tava trazendo antes até da tua pergunta ali é que o cooperado quando ele quando ele se torna um cooperado na Unicred ele tem uma uma cota capital, né? É uma coisa que diferencia também. Hoje tu paga, geralmente nos bancos, tu acaba pagando por alguma taxa mensal para ter direito a alguns serviços. E a cota capital é uma das opções de como tu se tornar um cooperado. Então é um valor ali que tu vai eh tendo como montante e aquilo ali, juntamente com o que tu vai utilizando dos serviços, vai fazendo que essas sobras que o mesquita falou vai calcular o o que tu vai ter depois nessa nessa divisão aí das sobras pro cooperado ao fim de um de um ano, por exemplo.

12:16Entendi. Então é um processo interessante e trazendo aí o do ponto do que a gente tava falando do histórico ali, né? O Mesquita fechou 15 anos já, né?

12:27Já fechei.

12:28Debutou já esse esse ano, né? Debutando.

12:31Daqui a pouco a carteira de trabalho dele vira maior de idade já. O registro esse ano debutou ali. Eu eu entrei no sistema cooperativo faz eh em 2019. Eu comecei no sistema cooperativo justamente para entrar dentro dessa operação.

12:47O a empresa tava começando, né, a a crescer, a se reorganizar.

12:52E quando eu entrei, eu entrei justamente para para construir uma operação de 24x7.

12:59Existia infraestrutura, recursos, data center ainda era numa salinha de servidores, era um era um prédio com várias salas e vários andares e essa operação não tinha um um sistema integrado ali de monitoramento, de uma operação 24x7. Então, era algo um pouco mais eh eh mais modelo raiz, como a gente costuma dizer, né? Então, quem sustentava era um Mesquita, as outras equipes meio que no amor, né, num sobreviso, cuidando. Então, era um dando a mão pro outro, era bem um sistema de cooperativismo, colaboração.

13:37O SRE, eh, cooperativista. É, naquela época nem se nem se nem se falava ainda nesse nesse tema ainda. Na em 2019 ali 2020, a gente começou a operação eh do monitoramento e de e de NOC em março de 2020, quando a gente começou a operar e ter uma operação de NOC 24x7. Nessa época a gente ainda não estava com a Elvin, era uma outra empresa parceira. A Elv, a gente foi conhecer ao longo dos anos ali, né, quando a gente começou a evoluir a parte de monitoramento, quando a gente começou a olhar paraa observabilidade, quando a gente começou a olhar para outros temas, né, à medida de que tu vai amadurecendo, que tu vai construindo, a gente acabou conhecendo a Elvin. E aí a gente começou no início a namorar, né? A gente ficou acho uns dois anos, né, trocando ideias, vai volta, né? E, e, e mindset da Elvin, ele fechava muito com o que a gente pensava, né, sobre parceiros também, né, a forma como a gente se relaciona e e faz negócio. Então, o negócio ele tem que ser bom pros dois lados e a gente não trata muito como fornecedor, mas sim como parceiro. Então, a Elv ela entrou muito nisso. A gente entrou cooperação com a Elvin em 2000 e acho que era 23, 24. É, acho que foi 24, mas a gente começou a namorar lá em 22, mais ou menos. Sim.

15:03Então essa operação veio evoluindo de monitoramento pro NOC, pra operação com a Elvin. Aí foi crescendo a operação dentro do time, a empresa foi crescendo muito, a infraestrutura, recursos. A gente saiu do do data center que era a sanha de servidores, levou para data centers maiores, chegou a trazer aqui o nosso data center para Equinixic em São Paulo. Então a gente foi evoluindo aos pouquinhos e crescendo e pensando ali para sustentar o crescimento estratégico que o Mesquita comentou ali, né? a gente tem um objetivo de crescimento aí pros próximos anos bastante agressivo para atender o mercado e mantendo ainda o nosso nicho.

15:42E dessa forma que a gente veio crescendo ali, veio evoluindo a operação com monitoramento, observabilidade, entrou essa esse contexto de SRE que passou por um momento talvez aí de conflitos, né, da própria dor do crescimento, né, nós tínhamos uma equipe que era eram devolves, distribuídos dentro dos times para atender toda todos os times de produto, desenvolvimento.

16:07Depois a gente começou a a unificar aqueles devoles e transformar num time de prestação. Então, centralizamos os devops e aí começamos a a atender todos os times. Depois a gente começou a a evoluir no sentido de distribuir melhor esses devops viraram SRE.

16:27Depois essa evolução, ela virou ali uma segmentação de esses SREs, eles mantinham toda a estrutura, tanto de recursos, plataforma, atendendo serviços, pipeline, CCD e passamos a segmentar ali com uma engenharia de plataforma. Então, uma parte desse grupo virou engenheiros de plataforma para justamente eh dar sustentação paraa plataforma. E uma outra parte desses SREs, eles mantiveram eh o apoio dentro dos times de produto, principalmente no que tange ali a pipeline, CCD, para apoiar os produtos nos desenvolvimentos, né? E agora, eh, nessa evolução, a gente acabou, eh, segmentando, né, no crescimento para o o conflito que foi gerado com até esse nome de SRE, a gente acabou alterando e esses SREs vir voltaram a ser devol do dia a dia e criamos um time de engenharia de confiabilidade que é o o SRE na na sua tradução.

17:34um rebranding, um rebranding, mas muito porque dentro da Unicred a gente acabava tendo muitos conflitos. Ali, ah, eu preciso de um SRE, mas não sabia se era o SRE que cuidava da plataforma, se era o SRE que fazia um papel de devops ou se era um SRE no monitoramento ou se era na observabilidade. Então, gerava esses conflitos. Então a gente acabou segmentando e e aí tendo um time de monitoramento e observabilidade que cuidava muito da parte de infraestrutura com ABCs e e esses recursos de operação do Nokia, onde entrou a Elvin, tivemos estruturamos o time com os devops que atendiam eh os times, atendem hoje os times de produto no desenvolvimento, no apoio no dia a dia, né, no no devops aí dos times de produto e construímos esse time de engenheiro de confiabilidade ade muito voltado pra parte de observabilidade de produtos, onde a gente eh implementou ali ferramentas eh como Dina 3 Grafana, APM para essa parte de observabilidade dos produtos e que é a evolução natural do do monitoramento e aí o time de engenharia de plataforma realmente criando e e sustentando a parte de plataforma. Então a gente acaba consumindo os recursos que esse time de engenharia de plataforma acaba criando, assim como os outros times de infraestrutura, cloud, network. O o você contando essa trajetória, eu me me deu uns flashbacks aqui, Brunão, porque a gente eu eu lembro bem assim uns 8, 9 anos atrás quando se falava em DevOps, né? tava, a gente tava muito falando daquele modelo de times distribuídos com colaboração entre infraestrutura e e desenvolvimento, né?

19:17E aí esse cara que tinha o papel de DevOps ali, ele nada mais era do que o cara que fazia o pipeline dentro daquele daquele guidance corporativo que o cara tinha lá, um Jenkins ainda na época, que tinha as regras dos steps ali, era o cara que pilotava o a automação de build deploy, digamos assim, né? É, em vários aspectos era o cara que jogava o artefato por cima do muro, tentar não deixar o negócio capotar, né?

19:43Mas assim, até essa e descrição que que o NES teve, né, até a gente se conheceu muito nesse contexto, né, da da Unicred, evoluindo a cultura e maturidade dos times, querendo ir para esse modelo, né, que traz o shift left mesmo, né, você antecipa o que for possível em termos de validação de qualidade e tudo. E esse conflito, né, digo que que apareceu e é comum, né, a gente acompanha muito na a evolução ali das topologias de time, né?

20:08Tem team topolog, tem uma outra literatura do do Fusion Teams, né?

20:12Fusion Teams.

20:12É muito essa reorganização dos perfis e competências, né? E aí eu enxergo muito, né, na na linha que o Ness comentou, né?

20:20Eu enxergo que você tem dois caminhos chave. Claro que tem tem alguns contextos mais você pode ter, por exemplo, um time que eles chamam de um subsistema complexo, tipo um cara, você pode ter um sistema de risco, alguma coisa que vale ter um time 100% autônomo, porque ele tá lidando com algo que não é trivial colaborar, mas o caminho mais comum é você ter, né, de fato engenheiros de plataforma que olham temas que são mais ou menos ortogonais aos times, né? monitoramento, segurança, otimização de custo. Tem algumas competências que ela tem que funcionar dentro de cada contexto de negócio. O ideal é que você, claro, dê liberdade para estimismo, mas você consiga ter um denominador comum que permita essa evolução em conjunto, senão você vai ter que otimizar 10 vezes a mesma coisa.

21:02Então é meio complicado.

21:03Tem que ter uma diretriz corporativa, né? Exato. Senão você acaba precisando tomar tanta decisão em cada contexto separado que você não consegue andar pra frente. Então acho que esse baseline, definição do que que é padrão corporativo, o que que te permite, né, já ter aquela decisão que te acelera, acho que isso é muito bom, fazer parte desse contexto de plataforma e ao mesmo tempo você vai ter alguns caras que são focados, de repente na necessidade de um time específico, né? Um cara de um um motor de crédito, um cara ali que vai fazer um antifraalde. Tem tem problemas ali que cada time tem a sua competência.

21:32Tem um time de mobile, tem um time de canal também, né? É comum que você tenha um cara que fica focado em deixar confiável aquele contexto específico, né? E ao mesmo tempo ele bebe da fonte, né, das definições de plataforma que facilitam o trabalho dele. Porque senão se for pensar, o cara de um canal mobile, por exemplo, se ele tiver que revisitar todas as decisões de pipeline, quality gates, governança, o que que pode fazer com relação a tudo, cara, ele vai demorar seis meses só para decidir o baseline dele. Quanto seria? falar, cara, vou partir do teu padrão corporativo aqui que já tá validado, vai te dar velocidade. Eu só vou de repente discutir o que de repente não se aplica a mim, né? Por exemplo, você pega um contexto de engenharia mobile, às vezes você tem que ter mais de um produto que compartilha o mesmo app. Aí tem pontos que são um pouco complicados, mas exceto por isso, tem muita coisa que você fala, cara, tudo que é padrão aqui eu vou aceitar e aí eu vou ter pista livre para colocar meu produto no ar sem precisar rediscutir se ele faz sentido ou não. E aí você vai ter essas linhas de especialização. Só que esse caminho, né, quando você tira às vezes um time de produto, né, da autonomia máxima que ele tinha, às vezes era muito centralizado, verticalizado, não era eficiente, mas tinha autonomia. você vai para um modelo que vai ser mais eficiente, mas de repente não tem a mesma autonomia, é natural que vai gerar conflito. Cada empresa vai ter o seu equilíbrio. O tamanho desse time de produto versus o time de plataforma em cada lugar vai variar. Mas acho que nesse conflito você acaba vendo, cara, quem é que tem competência para cuidar de cada assunto, quem é que resolveu bem um tema, né?

23:01Acho que é um processo natural, tem alguma fricção, porque senão, se você não tem algum nível de fricção, todo mundo aceita ficar com algo nota seis ali. Ninguém vai buscar o que que é realmente melhor.

23:15Você que tá aí escutando esse episódio bacana e quer levar toda essa tecnologia, essas novidades pra sua empresa e não sabe como, chama o time da Vembers. A gente pode ajudar vocês com desenvolvimento de software, com arquitetura de soluções, a entender os problemas que vocês estão vivendo e sair do outro lado com uma solução bem bacana. E se você tá escutando o podcast para aprender coisas novas, faz o seguinte, manda um e-mail pra gente no peoplecare@vemers.

23:43E você pode fazer parte também do nosso grupo de talentos. Valeu.

23:49Agora o time do Relações Públicas vai gostar mais de mim. Eu acompanhou bem essa evolução do próprio mercado se acomodando, né? Porque a gente, se a gente olhar lá da época onde quando teve o manifesto ágil, onde a gente começou a falar de ter produtização nas empresas, tratar os o os squads, etc., com orientação a produto, com a segmentação no cliente, a gente saiu de um modelo que era basicamente silos corporativos, né? Então tinha infraestrutura que só falava com software através de ticket. O desenvolvimento de software falava com negócio só através de reunião. Era esses grandes silos que não iam para lugar nenhum juntos. Cada um resolvia o seu próprio problema.

24:41Uhum. E aí parece que teve um momento, né, que a gente foi pro outro extremo.

24:48Uhum.

24:48A gente produtizou tantos times Sim, que parecia que uma empresa era um um grande hub de aceleradoras startup, cada um fazendo seu próprio negócio, sem uma condução corporativa adequada.

25:02Aí eu acho que isso de fato deu uma acomodada, né, Brunão, esse modelo que você colocou faz muito sentido. Você tem um baseline único e aí você vai especializar para aquilo que é a característica do teu produto.

25:13Uhum.

25:13Isso é essencial para você governar um ambiente onde você tem um mínimo de de características comuns para para exatamente como você falou, não ter que tomar várias decisões para o mesmo assunto várias vezes, né?

25:29É. E agora é engraçado, né, que teve um capítulos intermediários nesse processo, né, teve uma época que surgiu o famoso modelo, que na verdade não era modelo, era uma intenção e tal do Spotify, né, aquelas squads ali.

25:40A gente falou disso dos episódios atrás aí, a gente tava até falando, acho que foi um episódio que a gente estava falando de experiência do desenvolvedor, que tem muito a ver com plataforma também. Sim, sim.

25:49Porque nessa época, cara, uma coisa que fala, [ __ ] mas o Spotify ele tem esse modelo e etc e faz 200, 300 deploys por hora.

25:59Cara, mas tá entregando o quê? Porque continua tocando música igual para mim aqui.

26:04Por que que fez tanto deploy?

26:06Deixa do jeito que tá.

26:07Eu acho que às vezes o pessoal leva isso para um extremo. Por exemplo, cara, eu eu peguei a transição, né, quando começou a ter adoção de métodos a aqui no Brasil lá para 2006, 2007, foi a primeira vez que eu participei de um time de chamado de ágio, né, um time scrun, etc. Só que aí isso também foi para um nível tão extremo que parecia que a agilidade era mais importante do que o que você tava fazendo de produto.

26:30Acho que isso chegou num tal nível de de desperdício, de paranoia ali, que, cara, até foi meio que desacreditado, né, o papel do agilista. Às vezes tinham caras que eram super habilidosos, o cara resolvia confir, só que por alguns excessos, né, tanto o modelo do Spotify foi um pouco desacreditado, depois os caras falaram: "Não, é, na verdade era uma intenção, era para comunicar para onde a gente tava indo". enquanto tava colando. Não, esse modelo aqui é muito bom, não. E de teve uma época que o próprio Spotify falou: "Não, cara, não é, não é isso aí não". Exato. Os os ritos, né, do ágil são mais custos do que o meio virou o objetivo. Não faz, se vocês lembrar, eu acho que antes de muito de bem antes de tudo isso, quando se começou a falar de IT Uhum.

27:14também era mais ou menos a mesma coisa, né? E aí tu pegava o by the book e falei: "Cara, eu tenho que criar uma empresa só para implementar isso aqui dentro da empresa, porque é Exato. É, mas e e aí tu mistura muito e eu e eu acho que isso entra em quase tudo que tu vê de modelo, né? O pessoal acaba querendo usar como uma receita, né? Seja o método ágil, seja o ID, seja o próprio MBook. Então, ou tu é muito evangelista e isso aqui que tá fazendo tá errado. Eu falei, tá errado no livro, mas isso é uma orientação, uma boa prática. Eh, na aqui em casa isso aqui funciona e eu não tô seguindo aquela regra, mas eu tô entregando, eu tô fazendo, tá dando certo.

27:53Então é muito, eu acho também tu entender ali o que que faz ou não faz sentido, né? É, é, eu gosto muito assim de fazer benchmark de quem tentou fazer algo que tem a ver com que eu tô querendo resolver, falou: "Cara, me conta o que que você tentou, o que que deu certo, que que deu errado e tal".

28:07Livre às vezes de nomenclatura, porque às vezes a nomenclatura ela mais te limita do que te facilita, né? E eu acho que é um pouco isso, né? Quando você vai numa linha, né? Apesar de toda essa questão do modelo que não era bem modelo, né, do Spotify, etc., cara, emergia um conceito ali do do backstage, cara, 2019 para 20, etc., cara, backstage, portal de desuendor, etc.

28:26Aquilo ali embarcava um objetivo de você dar autonomia para time de produto, definindo ali num contexto as configurações comuns, tudo que você não precisa decidir. Por exemplo, cara, não vou ter que decidir como que a plataforma trabalha com ambiente de nuvem, com um ambiente de, cara, uma série de coisas já escolhidas por você que se você topar aquele padrão te dão velocí muito bom. Isso independente se o se o time era fofinho, se não era, etc., Isso te dava mais velocidade porque tinha um monte de coisa padronizada e automatizada em escala. Isso traz eficiência. Então acho que é muito dessa linha de você ver o quanto que aquilo encaixa com o que você tá querendo fazer, o quanto que que não encaixa, né?

29:03E aí todo todos esses temas, esses capítulos ali de observabilidade, segurança, gestão de custos, fala: "Cara, será que meu time precisa gerenciar custo de nuvem de um jeito diferente dos outros? Por quê? O que que eu tenho de tão específico aqui? Talvez até tenha, mas muita coisa você fala: "Cara, eu não quero me preocupar com isso aqui, porque eu sei que vai ter um time de plataforma especializado para resolver aquilo ali muito bem e ao mesmo tempo eu quero ter o máximo de foco no meu cliente, no meu problema que eu tô querendo resolver pro negócio. E aí eu vou aceitar esses padrões definidos no nível company level ou business unit level, né, que vão me trazer velocidade porque, cara, minhas discussões aqui de release não não vou rediscutir nada que já foi acordado, né, isso de maneira geral traz muita velocidade, né? E essas práticas, né, que eu que eu peguei bem, acho que o momento em que tava virando lá na Unicred, né, para essa cultura s era muito, cara, o que que é realmente essencial para eu colocar no meu processo que vai me dar velocidade, autonomia, preservando a autonomia dos times e o que que é, né, na na prática uma prática que é melhor você deixar o time sendo 100% autônomo para ele resolver ali. Isso aí foi bem interessante porque assim no final acho que um dos benefícios, né, da gente e escolher um tema um pouco mais especializado, né, por exemplo, srebidade, são temas que não é toda empresa que foca nisso, né, são acho que relativamente poucos. Você consegue de certa forma escolher quais são os times, os ambientes que estão tentando de verdade fazer aquilo ali funcionar, porque você pega, cara, um problema na nas essências, você não pega aquele problema que é um furufur ali, não. CL ali é um problema, pô, é um conflito real que acontece. Você pega um time que tinha até ano passado um papel X, ele passa a ter um papel meio zona cinza ali com o outro. Cara, isso aí assim, até você acertar como que você vai praticar, você vai tentar um, dois, três modelos que não vão funcionar. Vão vir discussões que se possível sempre, né, sempre focados em resolver o problema e menos em vaidades e tal. Até você chega num ponto que, cara, você percebe que a empresa atinge um patamar de maturidade, velocidade muito melhor porque os conflitos necessários eles aconteceram, né? Acho que isso aí faz parte, né?

31:04Então foi bem interessante.

31:05Eu acho que a evolução da maturidade em relação aos modelos aplicados também, acho que eles eles vão, né, um pouco dos conflitos que o Nes trouxe em relação a quando a gente implementou o time de SRE, mudou o nome, voltou para DevOps, né? Acho que eh até bem pouco tempo atrás tudo era infraestrutura e os times de produtos, né, os times de, né, que gerenciavam aplicações, muitas vezes não entendiam de fato o contexto de cada time. Quando a gente aplicou o modelo SRE, a gente sabia que tinha uma jornada, né, para que ele fosse aplicado fim a fim e chegar, né, num numa evolução. Eh, passamos por alguns desafios, reformulamos algumas estratégias, né, e colhemos frutos com isso. Acho que esse é um ponto importante, né? Acho que também correlacionou ao modelo em que a gente estava buscando mais observabilidade para antecipar problemas, antecipar, né, situações que por ser uma gestão financeira a gente, né, tem que tem um transacional que tem que tá online tanto quanto Itaú, tanto quanto Bradesco, por exemplo, né, sendo menos cooperados, digamos assim, mas tem que tá no ar, né, porque a gente tem essa concorrência indireta, né, porque o nosso nosso público ele é direcionado.

32:16ao profissional da saúde, mas ele também pode estar usando outras instituições e escolher em algum momento, né? O digital vem muito forte para isso. A gente, por isso que nesse plano de crescimento a gente tá falando muito digital também, né? Então a TI ela apoia muito esse processo como um todo, né? Então, engenheiro de plataforma, sre são métodos que a gente vem usando hoje, né, para melhorar o nosso dia a dia.

32:39Eu eu acho legal você colocou, porque acho que a frase que mais marcou agora, quando você falou, até um tempo atrás era tudo infraestrutura.

32:50É o cara da TI, né? É, exatamente. E cara, isso era um problema pelo seguinte, o cara o desenvolvedor, ele ficava no no mundo dele do do software desenvolvendo ambiente local dele e fazia aquele deploy, rodava aquele pipeline, etc. Muitas vezes o cara na infraestrutura não sabia nem o que era aquela aplicação. Então o cara olhava lá o verdinho de memória, disco e CPU, tá tudo certo. E não tinha uma pessoa que tivesse um pé em cada lado, falar: "Meu amigo, essa implementação tua aqui não tinham medo".

33:26Exatamente. Que conseguisse olhar o comportamento da aplicação dentro do ambiente de run time, saber o que foi desenvolvido, como é aquele código e também ter o olhar sobre infraestrutura, porque aí ficava dois bichos diferentes, cara, que não não a comunicação não rolava, né?

33:41É. E hoje assim, até é uma discussão que a gente tem tido sobre os novos perfis de aplicação que tem surgido, né, assistidos ali por agente J, etc. Muitas vezes assim, a disponibilidade, ah, alguma coisa tá disponível, tá rodando, tá rápido, não garante nada. Você pode ter alguma coisa que tá com uma latência excelente, não tá dando erro necessariamente, só que ela tá respondendo coisas que não fazem sentido.

34:03Exatamente. Tá, tá errando muito rápido.

34:05Se você não entende, né, o que que é o objetivo daquilo, é, se você não entende o objetivo que aquele componente tem, né, qual o problema de negócio que ele resolve, você definir se ele tá funcionando ou não, é meio vago, né? É tipo olhar pra aplicação, cara, essa aplicação ela tá vazando o dado com uma latência baixíssima. Tá, tá lindo, tá?

34:23Hoje a gente tava conversando ali, a gente a gente tá fazendo um durante essa semana, a gente tá em a gente fica em Porto Alegre, né? A gente tem uma sede aqui em São Paulo também, mas a gente tá com um grupo de profissionais durante essa semana aqui fazendo um um como é que a gente poderia dizer ali? um alinhamento, um alinhamento ali, mas uma imersão. Era essa a palavra que eu tava querendo buscar ali. E hoje a gente até trouxe, eu trouxe esse exemplo numa discussão que era o eu subi a máquina ali com infraestrutura, com IS, um Windows com IS rodando, tu foi lá e botou a tua aplicação a rodar. Não tá funcionando a aplicação, mas eu olho do meu lado, a máquina tá no ar e essa tá rodando. Não, mas não tá funcionando. E aí é aquele negócio que tu tava fazendo na aqui funciona. Mas tá tudo OK. Mas a aplicação não responde.

35:10E e é esse ponto que tu tava trazendo ali. Eu acho que essa essa conexão ali, acho que eh o que o Bruno tava dizendo também antes, a gente falando ali de frameworks, de métodos e tal, tudo isso que a gente vai falando no final é processo. Embaixo de tudo isso é processo, entra, processa e uma saída. Então tu tá sempre busca, se tu não parar para olhar, para evoluir esse processo, vê onde dói, né? ver aonde a coisa tá travando, aonde tá freando, onde é que não tá evoluindo, onde é que a gente pode melhorar, onde é que a gente pode conectar essas áreas, né? Eh, tu não vai conseguir evoluir. E o que o Bruno trouxe ali também, a gente tava eh eh a gente, eu acho que a a humanidade, a tecnologia em si, passou por um momento de de dispersão, né? Cada um num canto.

35:58E hoje o que a gente tá fazendo, inclusive durante essa semana, é justamente uma imersão e conexão, né?

36:05conectando essas áreas pra gente tentar buscar justamente buscar uma uma conexão maior, né, entre os times, entre as áreas. é o volume de volume de informações e enfim tudo que impacta a gente é tão alto que acaba que assim, se você não consegue ter esses momentos de juntar o time para todo mundo ficar de verdade no mesmo contexto e poder ter essas decisões mais profundas, de fato tomadas com consciência, cara, você fica meio que no automático. Isso é é complicado. Isso é um ponto aqui que eu vejo assim, eh tem várias coisas muito convenientes que dão mais liberdade, principalmente para quem tem família, criança, etc. esse modelo do remoto distribuído, cara, uma vez que você sabe que que você quer executar, [ __ ] você tem acesso, informação, contexto, você consegue executar melhor ali focado no teu canto. Agora, o que você não sabe ainda que precisa ser feito, que você precisa decidir em conjunto, etc., Cara, é muito muito complexo tentar cada um encontrar o seu tempinho ali. É muito complexo. Então eu acho que uma das complexidades que a gente veio tendo nesses últimos anos, né, que assim a gente tá lidando com um problema complexo, com uma velocidade de mudança maior do que a gente sempre teve e a gente no final das contas tá tendo menos troca e colaboração com com os membros do time do que a gente costumava ter.

37:21Então, algumas coisas que eram triviais, você conversa no almoço, no café e etc.

37:25você vai amadurecendo aquela decisão que você precisa tomar daqui a um mês. Às vezes você precisa meio que compactar esse processo, falar: "Cara, estamos resolvendo o que a gente combinou para esse trimestre aqui, só que a gente precisa decidir o que a gente vai fazer no próximo, etc." Acho que tem que criar essas imersões mesmo que vão te, cara, chegamos até aqui, próximo passo vai envolver tais desafios, tais decisões e tal. Esse é o tipo de coisa, cara. Tem uma galera que é muito, não, não vai no modelo remoto assim, cara, assim, talvez seja, minha data de nascimento é antiga, né? Eu não consigo.

37:53É a mesma minha. A gente nem combinou, hein? Mas então o o Bruno tá falando o que eu penso e a gente nem trocou essa ideia.

38:01É uma questão assim de de eh como que você conecta, né? Eh, tudo que você precisa fazer e lidar com decisões que tm que ser tomadas. Às vezes você precisa agregar várias competências e pontos de vista ao mesmo tempo ali. Isso é um desafio absurdo de gestão. E, por exemplo, um dos temas que a gente tá discutindo muito agora é o que a gente entrega como SRE, como engenheiro de plataforma. Cara, quando eu olho trei, primeira vez que eu vim aqui no no PPT, cara, acho que o chat EVT tinha acabado de sair, tava longe de ter discussão de agente aí e tudo isso que tá rolando.

38:33Cara, o que a gente precisa entregar de de SRE, observabilidade hoje é muito diferente do que era 4 anos atrás. E um ponto que é interessante, nessa época, a gente até conheceu o time Unicred e tal, dentro de um contexto ali de formação, SRE, a nuvem e tal, cara, passou 3, 4 anos, ninguém mais tá tá assim sabendo responder exatamente tipo assim que perfil que é o contrato, porque assim, muitas coisas de entregas del fala, pô, o que o camarada precisava entregar em termos de infraestrutura tr 4 anos atrás era uma coisa. Agora, cara, muita coisa se ele aceitar um um bom padrão de arquitetura, etc., vem meio que resolvido para ele. Só que aí ele tem que dar aquele próximo passo, que entender, cara, a minha a minha infraestrutura do produto X, ela não é genérica, não é igual a do produto Y. Eu preciso decidir o que que é importante para aquilo ali. E tem uma galera que às vezes não faz esse salto. E e eu eu acho, Brunão, que isso vai tomar uma evolução eh ainda maior agora com a escala que a gente tá tendo de desenvolvimento software com IA.

39:35Uhum. E a gente vai ter um encapsulamento, digamos assim, desses caras que fazem engenharia de plataforma, que criam os guidance, criam os todos os guardios para essas aplicações.

39:49A minha visão que isso vai cair tudo para dentro do Harnas. E aí o cara que desenvolve, ele não vai mais ter essa preocupação de, pô, eu vou fazer signo padrão A ou padrão B, porque quando ele for especificar a aplicação, o Harness já vai ter isso em marcado e isso já vai ter ter a esteira de DevOps ali já mais azeitada, né?

40:10É, é engraçado isso. Até na linha, né, das abstrações. A gente começou no dado momento, pô, era bare metal puro, aí você começa a ter máquina virtual, depois de um tempo você começa a ter contêiner, etc. Nessa perspectiva, né, da engenharia de plataforma, acaba quando você começa a ter esse building block ali do do IDP, né, que te ajuda a conectar um pouco melhor as coisas e você começa a ver, cara, dado que o cara vai usar um agite ali para acelerar o que ele vai ter, etc., eu vou querer de certa forma abstrair para não ter lockin com modelo, etc. Mas eu quero poder embarcar as minhas escolhas como empresa, como time aqui, para não precisar decidir tudo de novo. É uma outra abstração. Só que, cara, tem uma galera que mal e mal se apropriou ali do que que é o o ganho que você tem por adotar um IDP. Então, assim, e é uma velocidade, cara, que é assim, o pessoal brinca, né? Quando você tem agora um desenvolvimento ali assistido por um Cloud Code, um Codex, Antigravity e outros, é como se você tivesse às vezes um um aquela grade release waterfall de se meses, só que acontece a cada duas semanas. E aí, cara, desenvolver ficou barato, ficou rápido, você tem 95% do código escrito por a gente, mas quem que dá qualidade e governança aquilo, né? Assim, e outra coisa que eu brinco com o pessoal, fala, cara, eu trabalho no problema de observabilidade há um bom tempo, cara.

41:25Se você não escreveu aquele código, você não pensou naqueles logs, não, não desenhou, não decidiu um monte de coisa, como que você vai fazer trushut em produção? Procurando Kirinha no log, procurando, cara, é muito comp.

41:37Esse é um ponto interessante. Eu quero até trazer isso para para abusar da da franqueza que vocês tiveram aqui falando dessa evolução, etc., para fazer uma pergunta ainda nessa linha, porque eh o eu acho que a grande discussão agora, Brunão, tá tá mais em como eu trabalho a IA para ela gerar do jeito que eu quero do que como eu reviso para saber se ela fez do jeito que eu precisava.

42:06Uhum.

42:07Né? E aí começa essas discussão de engenharia e e harness plataforma para que eu eu dê pro desenvolvedor fazer isso e ele consiga eh desenvolver do jeito que deveria ser. A Iá faça do jeito que que seguir os padrões da companhia, né?

42:24Mas a pergunta que eu quero fazer é dentro desse período que a gente até discutiu aqui, poxa, as pessoas se conversam menos, tem lá suas vantagens do do full remoto, que o cara foca mais, mas também tem algumas interações aqui.

42:41Eu tenho para mim um edidor de sinergia das empresas, principalmente da área de TI. Você quer entender se o time tá rodando e se ele tá sincronizado? Eh, você tem que ver uma sala de guerra durante um tratamento de incidente.

42:57Uhum.

42:58Dependendo da quantidade de mortes que tem ali, Uhum. Seu time pode estar mais ou menos engajado. E aí a pergunta que eu queria fazer para vocês é dentro dessa desse amadurecimento que vocês tiveram, desse processo de observabilidade, do papel de DevOps, do SRE, eh, como que vocês tratam o incidente hoje? Porque é muito comum a gente ter dois dois extremos, né? O cara era DevOps/SRE e ele pilotava os pipelines ali e trabalhava proativamente para não ter o problema. Mas em muitos lugares o sre era o cara que era a SUAT, o cara que vinha com o caminão de bombeiro, chamava todo mundo de burro na sala e ficava fazendo praticamente um trouble shooting sozinho ali dentro do do incidente. Como foi essa trajetória com vocês? Eu eu acho que há uns dois anos atrás a a nossa sala de guerra ela acontece ela acontecia várias vezes durante a semana. Pelo menos uma vez por semana acontecia uma sala de guerra. Ela durava pelo menos umas 4, 8 horas e ela tinha 50, 80 pessoas de diversas áreas e diversos níveis até o diretor dentro da sala. Porque porque é sempre uma maravilha, né? que o diretor da sala, o que o que pro técnico era um horror, né? Então, então assim, tu já deve saber que isso gerava várias crises dentro dos times, né? Por causa da pressão, acontecia alguma coisa.

44:34Então, como é que tu fazia naquela época, né? Naquela época, parece que é décadas atrás, né? A gente tá falando dois anos atrás.

44:41Dois anos atrás, nós tínhamos, nós tínhamos bons profissionais com muito conhecimento e muitas ferramentas dispersas e não conectadas. Então, na hora da sala eu chamava alguém a eu eu é é força de expressão, mas conectava uma pessoa que conhecia de banco, uma de infraestrutura, uma de rede, uma que conhecia de uma aplicação, uma que conhecia de grafana, uma de uma de log, uma de o pouco de trace que se tinha.

45:07Então tu conectava várias pessoas para conseguir que numa sala com em discussões e navegando em dezenas de painéis começasse a entender aonde é que é o problema, aonde começou o tu sabe que tu tem o problema, mas aonde é o problema? Qual é a causa raiz? Isso aqui é isso aqui é uma causa ou uma consequência? Eu eu afetei ou fui afetado? Então tu começar a navegar nisso, né? E aí essa experiência ela vai fazendo com que uma parte dessa turma ela ela viva isso todos os dias e os outros 80 eles estão ali só de papagaio de pirata, né, querendo saber que horas volta, como é que volta e e será que não é aquilo e será que não é aquele outro?

45:50Então, dando palpite sem sem embasamento nenhum e isso vai gerando uma pressão dentro dos times ali.

45:56E aí muitas vezes tu acontece alguma coisa, tu já meio que já sabe onde é que é.

46:02Aí em tal coisa, vou lá e restarto restarto A, B, C, D numa determinada ordem, normalizou e fica acompanhando, tá tudo bem e vamos torcer para não acontecer de novo. Então, a gente vivia numa numa coisa assim, a gente vivia no momentos muito tensos, até onde a gente eh começou ali num num talvez num corte onde a gente realmente implementou, por exemplo, Dina Trace, que foi é um outro parceiro nosso forte também ali, num meio que numa força tarefa que para se parou um grande grupo, falou: "Essa semana a gente tem que descobrir o que que tá acontecendo". E aí a gente conseguiu muito rápido implementar e começar a ter uma observabilidade do ambiente e aí começar a entender aonde eram os problemas. E isso junto com vários notáveis dentro da Unicred ali que começaram também a demandar, investir o seu tempo para buscar resolver alguns problemas que eram críticos da empresa e que normalmente foram acontecendo devido ao crescimento.

47:08Então a gente vê evoluindo. Uhum.

47:11De lá para cá, essas salas de guerras começaram a ser menores.

47:16Uhum.

47:16Com pessoas mais dedicadas, específicas.

47:19E o tempo dela muito menor, porque aí tu já sabe, é aqui qual ação, o que eu faço, começou a delimitar e aí tu começou a ter menos. Eu não tenho os números aqui em mãos, mas a gente a gente e mede isso ali e em quantidade, a gente começou a ter menos em o que a gente chama de incidente crítico, que é aquilo que abala parou a empresa, abala a fé da da empresa, a credibilidade da empresa.

47:43No primeiro ano reduzimos 100%, [ __ ] né? Aí estamos caminhando aí para reduzir mais 100% desse residual para o terceiro ano.

47:51E aí, e aí tu começa com uma questão cultural, que é eh o o uso das ferramentas, ele começa a a transbordar e de uma forma orgânica eh outras pessoas absorver, entender, consumir e tu começa a ter eh o que a gente chama de de preditivo, preventivo e entender comportamentos, né, para evitar que a eh incidentes críticos aconteçam. Então tu já começa a entender, ó, tem alguma coisa acontecendo.

48:19Teve uma RDM ontem, deu tudo certo, né?

48:22Testaram, validaram, mas hoje de manhã a gente começou a ver um comportamento mudar à medida em que novos que os cooperados começam a transacionar. Então tu começa a identificar e tu começa a tomar uma ação rápida antes que aquilo vire uma crise.

48:35É a partir de um comportamento, né, da de uma aplicação ou até de um ambiente, né? Acho que acho que foi importante que nestas trouxe. Acho que o tu começou falando também sobre, né, o o fato do remoto, né, ser um um fator em relação a ao afastamento das pessoas, em relação a a se ao se sentir dono, né, daqui a pouco da de uma situação de crise. Eh, eu acho que toda essa todo esse processo que a gente passou, ele fortaleceu um pouco do nosso DNA de cooperativismo, né?

49:09E a gente criou ritos, né, em relação a preventivo, né? Então, ontem numa sala de guerra, há bem pouco tempo atrás, a gente mais apontava dedos, ó, o problema é aqui e ali. A gente propõe situações dentro de uma sala preventiva, dizendo, ó, tô vendo um comportamento que tá degradando a minha solução tal.

49:33O pessoal começou a se ajudar mais, né?

49:35E com isso reduzi, né? E eu acho que um um dos sucessos aí da jornada é isso, né? A gente conseguir reduzir os incidentes críticos, né, em relação a ao a forma como a gente age de forma preventiva, mesmo com as pessoas em boa parte remota, mas se ajudando cada vez mais, né? Acho que esse ano mesmo a gente trouxe isso pro não produtivo, porque o não produtivo gera, né, uma antecipação, nem chega em produção um problema. Uhum. Então acho que trazendo que o Nas, corroborando com o que o Nas trouxe aqui, acho que é a gente vive numa evolução muito positivo em relação a esse tema.

50:19Você que tá aí escutando esse episódio bacana e quer levar toda essa tecnologia, essas novidades pra sua empresa e não sabe como, chama o time da VemBS. A gente pode ajudar vocês com desenvolvimento de software, com arquitetura de soluções, a entender os problemas que vocês estão vivendo e sair do outro lado com uma solução bem bacana. E se você tá escutando o podcast para aprender coisas novas, faz o seguinte, manda um e-mail pra gente no peoplecare@vems.

50:48E você pode fazer parte também do nosso grupo de talentos. Valeu.

50:53Agora o time do Relações Públicas vai gostar mais de mim.

51:02Acho que o grande ponto chave, né, Brunão, é a quantidade de informação disponível que você tem num momento desse, né?

51:08Porque se você tá numa sala de guerra, onde você não tem um PM, você não tem de fato um raio X, o que que tá acontecendo? E aí você depende daquele superherói que já passou por isso em algum momento e fica todo mundo nervoso, sem saber o que vai, testando hipótese, tudo é e é o pior cenário possível, né? Porque isso isso leva o atrito. Agora, quando você tem capacidade de analisar as informações, tem instrumentação, você tem um monitoramento ajustado, até o clima fica mais leve, né?

51:38É que a as arquiteturas foram evoluindo, né? Você pega uma arquitetura de 15 anos atrás, ela tinha um servidor de aplicação, tinha um banco de dados, tinha pouquíssima eh conexão externa, né? Você vai para um cenário, você tem microsserviço, tem às vezes dezenas de aplicações que passam pela jornada do teu cliente final, você identificar exatamente o que que de fato, né, o Ness comentou, né, o que que foi impactado versus o que que impactou causa efeito, é muito mais complexo. Então, essas capacidades, por exemplo, de de tracing, de você ver, cara, o que que pode ter influenciado esse ambiente, teve uma mudança no ambiente, seja um deploy numa nova feature, né, ou eventualmente uma mudança de configuração, atualizou servidor de aplicação, enfim, tem n pontos ali que podem ser ser o ofensor, né, só que se você não consegue capturar, né, de fato esse comportamento histórico, ver, cara, quando começou a degradar essas marcações na linha do tempo, né, muito do do time series, você começa, cara, ter que cada vez que tem um incidente, você levanta 10, 15 hipóteses. Enquanto o que a gente gostaria, né, até até um contracenso isso, né? Mas quando você tem uma sala de crise muito grande, embora você possa pensar, cara, eu tenho mais gente disponível, mais competência, mas só você começa a ter aquela divisão. Tem aquelas poucas pessoas que t de fato capacidade de identificar e resolver um problema. Só que você tem 50 pessoas, elas vão gastar metade ou mais do tempo dela dando atualização sobre o incidente em vez de focar em resolver. Exatamente.

53:04Então, às vezes essa proposição de papéis tem um papel interessante nesse contexto de resposta incidente que é do instant commander, né? Que o NES comentou: "Pô, é normal que você tenha um um stakeholder importante na empresa, alguém que já conhece as pessoas, já conhece do negócio, ele veste essa camisa porque, [ __ ] alguém tem que fazer". Mas se você consegue ter essa visão clara, cara, quais são os times que eu preciso articular? Qual foi o produto? Qual foi o ponto de impacto?

53:28que você democratiza um pouco mais essa competência ao longo de vários times, cara, você já não precisa ter, por exemplo, um gerente entrando numa sala de crise com tanta frequência, um diretor, menos ainda, né? Então, acho que isso vai e até a operação, né, Brunão, porque eh eu já vi em algumas empresas quando você tem uma crise grande, sei lá, uma aplicação importante que tá fora do ar, etc. às vezes o cara que não tem nada a ver com aquilo, ele tá fazendo o trabalho dele ali e aí ele, pô, sai da mesa dele ou liga para alguém para tomar uma decisão ou fazer uma coisa da operação dele e aí o cara fala: "Cara, tá maior sala de guerra, tá maior crise, você não tá lá ajudando?" Às vezes o cara nem pode ajudar, mas aí ele fica nessa pressão de, "Pô, cara, tu tá vendo isso e a empresa toda tá parada." E aí dentro desse framework você ter de fato, quem deve estar participando, quem deve est conduzindo, quem de fato tem condições de resolver e naturalizar isso, você mata essa cultura do desespero, né? Porque aí fica 200 caras que não tem a menor condição de ajudar olhando para dentro de uma de uma sala, você não produz mais e atrapalha quem deveria, quem conseguiria resolver, né?

54:37Essa é a proposição de papel, né? E você ensaiar mais isso, né? Por exemplo, vocês comentaram, né? essa questão preventiva. Às vezes o pessoal gosta de fazer um negócio que chama pré-morte, né, que você tentar fazer alguma coisa no SRL tem muito a cultura do launch checklist, você pensar tudo que tem que tá OK para eu poder considerar que uma release tá boa pra produção, passa por um ambiente de homologação, é muito bom que você tenha observabilidade, guard rails completos num ambiente não produtivo para tentar. Shift left é um pouco isso, né, cara? Identifica e resolve quando é barato, né? Porque depois que chegou em produção teve impacto, é, é mais doloroso, né? Então, acho que tudo isso vai numa linha legal, mas assim, olhando isso no retrovisor, é fácil identificar, pô, mas isso é óbvio, mas cara, quando você tá na dor ali no meio do da da crise, né, é difícil de enxergar. E eu vejo que assim essa evolução, né, que envolve o mix ali de cultura, processos, ferramentas, né, te coloca numa capacidade de de preparação muito melhor que o SR para mim é inclusive primeiro capítulo da SR, ele fala lá, cara, esperança não é uma estratégia, não adianta falar, espera ter problema.

55:41A gente a gente isso tem que virar um corte. Qual que é esperança? Não é estratégica. a gente, a gente brinca que a gente eh comenta, né, entre nós, a gente tinha muita sorte, a gente tem muita sorte porque tem coisas que dão certo, não sei como é famoso mais sorte que juízo, né?

55:58Mais sorte que juízo. Hoje, hoje a gente tá muito melhor estruturado, né? E o que o e o que o Bruno, o que o Bruno trouxe ali é uma das coisas que a gente eh implementou junto com a Elvin, né? Além da gente implementar eh o Command Center, a operação 24x7 que a que a que a Elvin acaba tocando, a gente acabou depois implementando o que a gente chama de comand incident commander, que é justamente o papel daquela pessoa que tá acompanhando o incidente que tá acontecendo, é o cara que orquestra, porque no meio do no meio da crise, no meio da dor, eu não posso estar ali eh como um sobreaviso, um plantonista ou, né, que geralmente o pior momento é o da noite. da madrugada, tu trata com sobreviso e com plantonista, gente na madrugada, onde tu tem menos recursos.

56:43Então eu não posso estar ali com aquele cara dando satisfação, ao mesmo tempo pesquisando, ao mesmo tempo e escalando e ligando aqui. Então tem alguém que é esse incidente comander, uma operação que a gente montou com a 24x7, sempre acompanhando o que tá acontecendo durante o ambiente. Qualquer coisa que saiu fora do trilho, ele já puxa, já monta uma sala, já envolve as pessoas responsáveis, já conecta, já liga, já escala, ele não deixa a coisa morrer e cuida para que tudo isso aconteça.

57:12O cara que reporta não pode ser o cara que resolve, então ele não consegue fazer nenhum dos dois, né?

57:16Que é o que acontecia muito antes, né? E e tinha uma coisa que nós tínhamos também que eh durante o horário comercial a gente dependia de um determinado profissional, mas se tu tem mais de um problema ou se ele não tá, tu já tu já tem que escalar e tu já tu já fica depende. Então tu já começa a montar uma operação onde isso vai funcionar 24x7 sem tu te preocupar com a pessoa, mas sim com o processo.

57:40É com o papel, né? É porque e assim e acho que é diferença, né, de fato quando você entra numa sala de crise, que é um negócio para quem nunca viveu isso ou tá vivendo pelas primeiras vezes, é muito estressante. Então, se o cara já entra sabendo como articular, ele sabe, cara, qual o time que teve um impacto ali, quem são os times que dependem daquilo ali, como que funciona, por exemplo, uma área de governança, que [ __ ] tem toda uma colaboração entre papéis, se você já chega com alguém que sabe o processo, ele já tem um runbook para seguir, cara, a quantidade de decisão que ele vai ter que tomar, quantidade de coisa que depende daquele insight genial, reduz absolutamente. Se você democratiza isso, você tem 10, 12 caras com esse papel, né, dentro da empresa que sabem vestir aquele aquele papel, né, você consegue isso, tratar mais problemas de paralelo e você consegue eliminar praticamente todo o improviso que você existiria se você não tivesse um processo desenhado assim, né? Então, acho que isso é bem interessante porque no final ele reduz estresse, reduz a quantidade de pessoas envolvidas, né? você passa a ter um cara, vai ser muito muito efetivo no papel de documentação, o criba lá ou tem tem ali alguns papéis ali que são nomeados ali, tem o stente comédia, tem o scriba, etc. São caras que, cara, vão estar focados na documentação e no trouble shooting. Você tem o o especialista do produto, né, que é o cara que vai fazer o trouble shooting eh melhor do que ninguém, porque ele conhece aquela regra de negócio e arquitetura. E você tem ao mesmo tempo caras que vão ajudar aquele cara a se manter focado porque eles vão articular todo o resto que precisa acontecer enquanto o incidente ele é resolvido, depois documentado. No final ambiente regulado, você tem essas etapas, né?

59:09Não, não basta você resolver o problema, você tem que documentar, reportar, medir impacto, o que que aconteceu, né? Isso quando você tem três, quatro papéis atuando em conjunto, cada um sabendo o que que ele tem que fazer, cara, é muito mais efetivo, com menos estresse envolvido e, cara, não precisa mobilizar a empresa inteira, né? Esse esse é um ponto importantíssimo, né? Porque um dos erros mais comuns que muita empresa comete no em sala de guerra, em em situação de estresse, como uma disponibilidade geral, etc. Cara, você baixa tuas tuas eh seus muros de governança para tentar resolver isso mais rápido. Então, o engenheiro tem acesso já direto à produção, faz configuração para ver se se resolve, ver se volta.

59:54E se não tem um cara lá documentando, você vai ter um problema da descrição de ambiente.

59:59Uhum. pro futuro e muito provavelmente aquela mudança que o cara na tentativa e erro fez e não desfez vai causar um outro incidente no futuro e que o cara fala: "Pô, mas quem mudou isso daqui que não deveria estar assim".

60:12Não é raro. Eu eu já vivi em sala de crise nisso em que às vezes você não sabe exatamente o que que resolveu o problema. Você tentou tanta coisa ali, 10.

60:22É, se começa, né, Brun? Que se você não sabe o que resolveu, você não resolveu.

60:26Você só você só restabeleceu, né? E isso era, isso era uma realidade, eu acho, muito do nosso passado. Hoje em dia, eh, quando acontece os eventos, a gente consegue entender qual é o problema, o que que tem que fazer. tu consegue corrigir e tu consegue determinar, olha só, a gente corrigiu.

60:48Agora, pra gente melhorar, para que a gente tenha maior performance, resiliência, evitar que isso aconteça, a gente tem uma capacidade maior, tem que ajustar parâmetros, isso e aquele outro. Então tu tu tem um direcionamento muito melhor, justamente também porque tu tem um ferramental bem instrumentado, tu tem três, tem log, tem métrica, tem algo que te dá essa essa visão de uma forma muito clara, né? E tem acho que padrões que vão vindo em cima disso, né?

61:14Aí um pouco mais na na linha de engenheria de plataforma até daqui pouco que a gente engaja o Felipe para contribuir bastante nisso também, né?

61:21Você começa a ter uma confiabilidade pensada, decidida, né? Por exemplo, cara, que que eu posso fazer quando o componente X falha? Posso fazer um circuit breaker e parar de chamar aquele componente enquanto ele tá com problema e depois eu volto? Ou eu posso ter um modelo no qual eu tenho uma feature flag lá que o cara desligo essa feature, tá com problema, etc. Daqui a pouco eu volto. Isso aí, por definição, já é um negócio que tá pensando, cara, tá as coisas podem dar problema. Eu vou tentar pensar qual que é a minha decisão quando cada uma delas acontecer, porque eu não quero que o impacto seja tão grande quanto seria se eu não tivesse nenhum plano. E aí você elimina essas decisões tomadas no improviso, porque você pensa, cara, tem uma aplicação que ela depende de um banco de dados, de um serviço de fila, de uma API A ou B aqui, cara, são quatro, cinco dependências, eu posso decidir o que que eu posso fazer, alguma coisa sobre aquela falha num componente que não é o meu, uma dependência que não foi, ou até mesmo de um parceiro, né? Exato.

62:13Enfim, tem parceiros como processadoras aqui.

62:15Exato. Algumas você, cara, pode tomar uma decisão que vai mitigar muito do impacto. Em alguns momentos não. Cara, por exemplo, foi um deplo que aconteceu, teve um impacto, um efeito colateral não previsto no componente X ali. Cara, às vezes tem muita empresa que fala, cara, teve um um problema causado logo depois de um do de um deploy. Faz rollback imediato, depois que você depois você pergunta o que que aconteceu.

62:40Nem pensa. Então tem esse tipo de coisa, parece óbvio, né? A gente fala que é take for granted, né? Mas cara, se você não tem esse critério definido, cara, até você decidir, faz um roback longe, o cara fala: "Cara, mas e aí? E se piorar, se eu fizer", cara, começa a ter aquelas Sim. Não, e tem que ser uma decisão tomada antes, né? Porque no calor do momento é muito difícil, porque aí o que que vai acontecer? Você fez o deploy, você colocou a aplicação tá rodando e começou a falhar, começou a degradar.

63:10Vai ter um cara que fala: "Cara, faz Rober que vamos ver o que é." Mas vai ter sempre um cara que vai falar: "Ah, não, acho que eu já sei o que é. Pera aí, sim, pera aí que eu vou gerar outro pacote que eu acho que já sei o que é, bicho." Aí já fodeu, não. E aí esse próximo pacote não vai ter tido nenhuma das validações que precisam ter, nenhum guard rail, etc.

63:29Ex. É um pet. É, tu sabe que só cresce a montanha de cocô que vai crer, né? Tu sabe que eh e isso que tu trouxe ali já aconteceu algumas vezes ali, que é, por exemplo, tu vai tu vai fazer uma uma mudança na, sei lá, num horário ali 2as da manhã, 1 da manhã, né, de menor impacto e tal, vai ter uma parada no produto, eh, tu determina ali qual é o melhor horário, se tu vai ter que ter uma parada. Aí tu faz aquela mudança, faz todos os testes de validação, pô, tudo certo.

63:59É 2 horas, mas não tem ninguém usando.

64:00Não tem ninguém usando. Aí 7:30 da manhã tu começa a mudar um comportamento.

64:06Aí tu começa a analisar. Pô, começou a tá meio estranho. E aí como a gente já tem tudo instrumentado, tu começa a perceber isso, o pessoal já, olha só, tem um alerta aqui, tem um comportamento aqui, degradação de performance, começou a dar erro, tu monta a sala assim, teve alguma RDM?

64:24Teve aonde? Nesse Ah, mas esse serviço aí não tem nada a ver, não volta. Não teve nenhuma mudança só essa. Volta.

64:32E quantas vezes tu já ouviu, né? Não tem HBC também. É, tem às vezes, às às vezes tem Hback. É engraçado, né? Eu sei lá, mas para, para fechar, ou pior, eu já ouvi também, tipo, cara, volta pra última versão. [ __ ] qual que é a última versão?

64:50Já, já aconteceu. Eu já vi isso aí também, mas acontece muito. Não no Brasil, na Noruega acontece muito.

64:55Não é, eu eu já eu já vi, mas eu eu vi num podcast isso aí. Não não não foi na vida, mas e acontece disso de tu voltar para tu não acreditar que aquilo tá causando a mudança, mas cara, volta e vamos testar. tu volta, normalizou, cara, não faz sentido nenhum, não importa, depois a gente investiga. E depois você descobriu o que que era, mas realmente não fazia sentido. Mas mas é é essa esse mindset disso, cara, não mudou nada, gerou teve não mudou nada em princípio, mas teve mudança. Então isso acontece também e às vezes tu no correr de um incidente, de uma crise, tu tá na versão um, volta para para zero, aí tu voltou para um, dois, ah, qual é que tava aqui já já se perdeu?

65:40Sim, já eu já passei por situações, por exemplo, eh eu trabalhei um período com gator e um premis.

65:47Acontece ainda os neandertes às vezes ainda tem esse tipo de coisa. Eh, e cara, aconteceu um incidente bizarro.

65:55Uma vez eu era responsável pelo pelo IPI Gator, né? Parou, simplesmente parou.

66:00Parou o portal da empresa, parou portal de recebendo de contas, de pagamento, um pandemônio. Os caras olhando lá, [ __ ] P Gator parou de responder. Falei: "Cara, como assim, cara? Não pode ser.

66:14Como é que para o IP Gate? É a mesma volumetria. Volumetria não dobrou a a quantidade de requisições. Que que tá acontecendo?" [ __ ] aí você vai lá dar aquele reset no PH. Bom, aí estabiliza, aí começa a degradar, degradar, degradar.

66:29Que que teve de mudança? Ah, cara, só teve um deploy no app ontem nada a ver.

66:33Foi no app, no mobile, tal, cara.

66:37Corta, corta toda, corta as aplicações que, que tiveram mudança, desliga, coloca um, um um rate limite para todas essas aplicações.

66:49Vamos ver. Estabilizou. No fim das contas, sabe o que que estava acontecendo, meu amigo? fizeram um deploy no app que entrava num bug que ele ficava fazendo chamada para PI em loop e ele fludava o o EP gate não tinha rate limit e aí derrubava todas as outras aplicações porque era um premise, era uma coisa só, não tinha escal, mas é exemplo do que do que a gente falou, né? Às vezes o aplicação que aparentemente não tem absolutamente nada a ver com isso, sim. Sim. causa um impacto muito maior e e vira um uma bola de neve, né? Uma pergunta que eu queria fazer vocês, novamente abusando da franqueza, vocês têm eh como foi esse processo de instrumentalizar todo esse ambiente para poder ter essa visão mais ampla sobre a observabilidade, o APM e essa visão mais transparente do ambiente? Por que que eu tô perguntando isso? Da mesma forma que a gente tem o fator cultural e a pressão de negócio de, pô, não, não faz rollback porque eu tenho que entregar essa feature hoje, cara. Descubra, descobre qual que é o problema, porque isso tem que tá no ar, porque cronograma, não sei o que lá, o negócio tá no meu pé, tem que rodar também acontece. Você sabe que APS aplicações têm débitos técnicos, muitas vezes elas são opacas, aplicações legadas, você precisa ter um esforço para instrumentalizar ela, porque ela não é tão modernizada que você pega lá um um drace e ele já se autoinstrumenta, por exemplo. Às vezes você tem que instrumentalizar ela de uma forma mais mais rústica, digamos assim, né?

68:27Mais raiz, mais raiz.

68:29E e aí você ouve aquela, cara, eu não posso parar para fazer isso porque eu tenho coisa para entregar. Também é uma coisa que acontece muito na Noruega, aqui no Brasil nem tanto.

68:38Uhum.

68:38Mas como foi essa essa conscientização de tipo, gente, disponibilidade não é só um problema de infraestrutura e arquitetura. Eu preciso de que o software também aceite ser observar observável, digamos assim, e aí fazer esse trabalho de esforço em conjunto.

68:58É, é que dentro da nossa estrutura a gente só usa coisa de última geração, não tem nada de legal.

69:05Ah, então beleza. Então realmente é coisa da Noruega, muito fácil.

69:10Mas eh eu eu acho que o que faz assim quando a gente entrou com Daina 3, a gente estava começando a discussão da jornada de observabilidade, que era uma iniciativa que a gente tava começando a eh a digamos aí a a descobrir, né? Fazendo um discover assim. E e a nossa intenção inicial era a gente trabalhar com o que a gente tinha. Então, a gente tinha um pouco de Open Telemetry instrumentado comer e a nossa ideia era evoluir dentro do que a gente tinha de de ferramental, ou seja, vamos melhorar o que a gente tem, né, aprender e evoluir para depois o e ao mesmo tempo, né, a gente tava olhando ferramentas eh enterprise, data dog, dinrace e outras ferramentas, só que eh isso era o que a gente tava querendo fazer. Mas o destino ele ele a realidade ela a realidade ela é um pouco diferente.

70:09Então a realidade ela não quis esperar a gente nessa jornada. Tem tempo, né?

70:13É. Ela falou assim: "Olha só, eu tô eu tô meio e hoje em dia muita gente com ansiedade, TDAH". Então ela tava meio nervosa, ela falou: "Vamos acelerar isso aí, ó, vamos acelerar". E e aí veio esses problemas, salas de guerra e tal e veio assim um um meio top down, gente, precisamos fazer alguma coisa. Então foi meio uma mobilização.

70:33E nessa mobilização é que a gente conseguiu fazer essa instrumentação, porque aí veio na época o Dana 3 que a gente tava começando os contatos, a gente a gente meio que assim uma segunda de noite, eu falei: "Olha só, eu preciso de alguém amanhã pra gente instrumentar o DA Trace aqui". Meu cara falou: "Fechou". Pegou alguém. No outro dia de manhã eles estavam em sala com a gente e e a gente instrumentou da Trace assim porque juntou plat, a gente passou por todos os a toda a burocracia que seria normal, a gente passou tudo aquilo ali, né? E vamos direto. É como se tivesse tudo sobre o nosso domínio e controle. Junta IFI, junta plataforma, junta todo mundo e mão na massa. E a gente conseguiu um instrumental da Trace assim numa semana. a ferramenta em si, né, com a gente a a própria arquitetura que ela oferece, ela facilita muito isso, muito pra forma como a gente tava naquela época, a forma como a gente estava organizado também dentro dos produtos.

71:33Então ela ela acelerou muito, facilitou muito essa instrumentação. A gente teve alguma algumas dificuldades que a gente foi descobrindo, mas isso acelerou muito pra gente ter essa visibilidade no ambiente produtivo, porque tu instrumentou, tu já tu já começa a ver.

71:47Dali a gente foi fazendo um trabalho que aí vem mais da jornada mesmo, que é como é que a gente vai tá OK? Uma coisa é tua instrumentar, outra coisa é como é que eu dou visibilidade eh de cada produto, de cada vertical de produto, de cada funcionalidade para que eu de alguma forma consiga dar essa visão, tr trazer uma métrica de tudo isso que tá instrumentado. E a gente começou a fazer um trabalho junto com todos os times ali, organizar, montar painéis e trazer uma eh um modelo que a gente definiu na época que a gente estruturou, como é que a gente vai ter um modelo de observabilidade dentro dos times de produto, porque a gente não tinha nada.

72:31E ali a gente começou a a a modelar essa estrutura para replicar para todos os times. Então ali a gente fez do dentro do ambiente produtivo.

72:41O que antes era o que tu falou era cada time instrumentava a aplicação lá com openetri. Cada um, um na versão um, na dois, um na três, um na quatro, tinha todas as versões disponíveis, não era muito bem estruturado, foi algo mais artesanal que trazia algum pouco de informação, mas que não era muito bem estruturado. Então, para pegar três, se tu ier num lugar, para ver log, tu vai no outro lugar, para ver métrica, tu vai no lugar, muitas ferramentas, né, de conservabilidade para para coletar essas informações e conectar, né, quando tu precisava.

73:13Então, assim que a gente instrumentou isso lá em 2024 e aí veio evoluindo, né, isso no ambiente produtivo.

73:21Esse ano a gente começou a a a gente começou a instrument começou não, a gente instrumentou já no ambiente não produtivo e aí a gente buscou algumas soluções para para essa instrumentação.

73:34E o que a gente tá usando no ambiente não produtivo hoje é uma uma solução que se chama coot, uma solução que a gente eh eu até vi num na internet, eu vi alguma alguma apresentação, alguma coisa de um de uma de uma outra empresa, na verdade um cara que trabalha com monitoramento com os ABCs, e ele comentou assim sobre a ferramenta e eu fui dar uma olhada e aí trouxe para dentro do time. o pessoal começou a analisar, investigar, testar, a gente começou, pô, um negócio interessante, assim, trazia eh conectava com o que a gente estava fazendo. E aí ali seria um desafio, porque aí já a instrumentação já é um pouquinho diferente. Mas o que facilitou dentro desse controle que dentro no no assim no último do ano passado para cá, a gente começou a modernizar a nossa pipe, então a gente começou aí com uma com uma estrutura muito mais organizada. Depois o Felipe vai trazer um pouco. E aquilo começou a trazer pra gente um controle que antes a gente não tinha idealmente e e simplificou o processo de tu eh poder conectar qualquer coisa dentro do nosso ferramental sem gerar esse problema que tu trouxe. A gente instrumentou todo o ambiente que a gente chama de TST e HLG sem o time de produto se envolver em nada.

74:53Uhum. É uma que a gente montou um modelo, né? Acho que a cultura que tu trouxe no início ali da quando a gente, né, enfim, implementou o Dana Trace, porque hoje, digamos assim, a gente tá mais agnóstico em relação a ferramentas. Claro que o Dana Trace naquele momento ele se fez necessário.

75:08Por quê? Porque a gente não tinha tempo, né? E a gente precisava implementar alguma coisa que nos desse uma visão do ambiente como um todo e criasse um modelo de observabilidade por produto, né? Então, com indicadores, com SLO, com tudo mais. Então, a partir desse modelo que a gente olhou pro NP Prod, né, e pensou, pô, aqui pode ser qualquer outra ferramenta que nos entregue, né, o mínimo viável para que a gente possa olhar o ambiente como um todo e antecipar situações, né? Eu acho que é é muito mais na visão de mudança de cultura em relação à observabilidade.

75:44Uhum.

75:45Né, do próprio time de produto, né?

75:48Ainda é um desafio. Por quê? Porque eh para muitos times assim, pô, quem é que olha log, quem é que olha painel? É monitoramento, é CRE. Sim, sim, né? Então isso é uma cultura que a gente dia, né? Então assim, dentro de governança, a gente buscou um modelo em que, pô, vamos trazer esses números para que a gente possa, né, mostrar daqui a pouco que a aplicação A, B, C ou D tem gaps e que a gente precisa trabalhar nesses debs técnicos, né? Acho que essa cultura nos ajudou bastante em relação a evoluiu muito, mas é um trabalho vivo, é um trabalho que não dá para até um ponto que é interessante nessa linha do tempo.

76:29Agora ficou meio que no brain, né, que você vai fazer a coleta de obserabilidade com Open Telemet de um jeito padronizado, independente de qualquer ferramenta. você vai olhar 2 anos e meio, 3 anos atrás, não era tão era um gap muito grande entre a observabilidade nativa de um agente específico, né? Danat fazia de um jeito, o Data Dog fazia de outro, etc. E o Open Telem ele tava um passo atrás, ele era promissor, mas ele não resolvia o problema ainda. E agora tem uma abordagem que o pessoal chama às vezes de tierização. Só fala: "Cara, eu tenho a minha aplicação mais crítica possível aqui que eu preciso na melhor cobertura, que o time já conheça, etc.

77:10Isso aqui eu vou embarcar a ferramenta que hoje tem o maior domínio e que eu mais confio. Vamos dizer que isso seja o Dan. Só que cara, eu vou ter 80 outras aplicações, eu tenho ambiente não produtivo e etc. Eu ter alguma coisa nota 7, né? em vez de não ter nada, [ __ ] já é muito melhor. Se eu posso eh fazer um denominador comum ali da coleta, logs, metric trace, tudo vai ser coletado de um jeito semelhante ali. E eu vou decidir para cada aplicação, para onde eu envio esses dados, cara, você já te permitiu, né, um shift left, né, você pegar uma observabilidade muito boa, log de erro aparecendo no ambiente não produtivo, tracing disponível também, que vai num nível de de maturidade muito interessante, né? Então assim, eu acho que parte é assim uma uma ferramenta que foi um acelerador, só que se tentasse fazer a abordagem de agora dois anos atrás não tava disponível também. Não era não era um negócio não, cara, isso aqui é óbvio, vai lá que vai dar, não é?

78:05A gente tá caminhando para separar a o dat, digamos assim, a visualização daquilo que você carrega do protocolo que vai que que o Open Telemetry tá tá tá cada vez mais se consolidando, né? E só um ponto que eu queria comentar que é é interessante. Eu sou engenheiro de software originalmente, né? Já viram lá da raiz. Inclusive ele já foi o cara que causou incidente.

78:29Não é hoje ele só captura.

78:31Se você não causou nenhum incidente, você não tentou fazer nada.

78:33É verdade. Se você nunca causou um incidente, você não tem história.

78:38Só que um dos pontos que eu me frustrei bastante, eu bem no começo da carreira passei por alguns ambientes alto volume, né? globo.com, alguns ambientes aí que tinham 30, 40 milhões de usuários dia, cara, você era obrigado a fazer teste de carga, automatizar um monte de coisa, cara, era obrigatório porque sem aquilo você não não atingia nada de de relevante em produção. E aí, de certa forma, eu fiquei meio frustrado quando eu vi que, cara, tem muito engenheiro de soft, mas assim, a grande maioria não se importa nem um pouco com observabilidade, porque ela considera que obsvabilidade é um problema de um outro time, é um outro grupo, não é problema dele, é o cara que fica noque, que se vire para ver a luzinha piscada, olhar o painel.

79:16Sabe quando você fica assim desiludido, eu falei: "Caraca, mas é sério mesmo?" Não, é sério? E aí quando você aceita que isso é verdade, você começa a procurar caminhos que que agora são possíveis, né? Antigamente não era tão possível, que o pessoal chama da autoinstrumentação, que é o quê? Você tem um um cluster cubernet, você tem aplicações de determinado tipo e arquitetura, você pode tornar aquela coleta de dados ali de logs, metric strace automática, sem precisar que o desenvolvedor mexa qualquer palito ali no produto dele, ele simplesmente vai embarcar o produto dele daquele jeito padrão ali e os dados vão ser extraídos de um ambiente num nível bem legal. Não, não, não. Talvez o melhor possível.

79:56Talvez se você fizer algo um pouco mais custom, você vai chegar no nível um pouco mais profundo, cara. Mas é muito melhor do que você teria.

80:02É, dois anos atrás, como você falou, você ainda tinha que embarcar o a a library do agente dentro da própria aplicação.

80:09E aí esse hoje a gente tá transparente, tanto pro na trace como no corot ali a gente já tem instrumentado métrica, log, trace sem o time fazer nada. Quando você não precisa que o time de produto mude a dinâmica dele, o dinheiro de software saia da sprint dele para te ajudar com a observabilidade, quando a observaridade deveria ser sentimento de ownership dele também, o negócio anda é muito melhor. E aí você ideal seria esse, né?

80:34E isso leva a gente para nosso uma um outro tópico que eu quero discutir com vocês, que é engenharia de plataforma.

80:40Como que eu faço isso sem fricção, né?

80:43Então, pra gente falar disso, a gente vai fazer um uma máscara edição aqui, ó, um e a gente já vai voltar com esse assunto.

80:56Feita a nossa mágica aqui da edição, o Mesquita está um pouco mais alto.

81:04Bem-vindo, Felipe, vai falar aqui com a gente agora para dar continuidade do assunto aqui de eh engenharia de plataforma, né? Porque a gente falou justamente sobre esses pontos de você tem uma escala natural evolução ali de ter um guidance, né, ter um playbook ali de observabilidade, de pipelines, etc. Isso não pode ser ser rediscutido o tempo todo e não pode ser também uma preocupação do time de de produto o tempo todo. Então, faz muito sentido que isso seja embarcado numa plataforma para que o cara não tenha que tomar a decisão a todo momento e também não tenha que ter um overhead de desenvolvimento e de tomada de decisão técnica para isso. Porque se você tiver que competir entre implantar um monitoramento e observabilidade e implantar uma fit feature de negócio, você sabe quem que vai perder, né? Então isso tem que tá em marcado já. Isso tem que negóci tem que vir no tem que vir no sangue. E como é que vocês estão evoluindo lá nesse sentido?

82:08É, hoje nós passamos aí algum um período de alguns bons anos com com uma esteira que era um pouco problemática, vamos dizer assim. ela nos esteira de negócio, né? esteira de de pipelines de negócio.

82:21Nós temos essas essa subdivisão, ela ela nós ela ela tinha algumas amarrações que nós não conseguíamos garantir uma certa um certo controle e uma certa padronização.

82:34Então, por exemplo, nós tínhamos esteiras ã com com plataformas, nós passamos por por ferramentas como Jenkins, Jordops, enfim, mas ficava muito ao controle do desenvolvedor ele se preocupar com os manifestos. Então ele tinha que tá gerenciando os manifestos, se preocupando em geração de controles de wingers, de config maps, de de credenciais, muitas vezes expostas em determinados arquivos, o que se torna vulnerável. Então a esteira ela tinha algumas amarrações complexas e que gerava uma vulnerabilidade bem considerável. Então, de um um ano e pouco para cá, nós passamos pel uma evolução bem considerável, onde nós conseguimos gerar essas amarrações, onde eu começo a omitir, vamos dizer assim, do desenvolvedor completamente o vínculo dele se dele precisar fazer essas alterações. Então, eu comecei dentro de um de um, nós chamamos hoje de uma pipeline bem simplificada. Então vamos pensar que uma pipeline de há um pouco tempo atrás ela tinha uns 100 linhas.

83:41Então a eu brincava que a criatividade do desenvolvedor ali ela ela fluía, né?

83:46Ela tinha então os os steps faziam parte, então o cara podia criar o template que ele queria, ele botava shell script no meio, ele botava credencial no meio e ninguém avaliava nada. Então era uma pô uma pipeline, né?

83:58Então eu tinha lá 800 aplicações em produção e tinha poderia ter 800 pipelines diferentes. Faz sentido? Não faz sentido, né? Então, nesse do de um tempo para cá, então, nós passamos então a ter uma pipeline de em torno de 10 linhas mais ou menos, onde ele só tem autorização, vamos dizer assim, de mexer em nenhum parâmetro, que é definir qual a versão da aplicação. Ou melhor, nós chamamos de framework, sabemos que não é ele diretamente um framework, mas ele define lá, por exemplo, se é uma aplicação Java ou e e basicamente a versão. Então, o parâmetro que ele controla é Java 8, Java 11, Java 17, Java 21, Node 20, Node 24. um exemplo, então é o único parâmetro que ele que ele que ele cuida. O que que tem para dentro, né? Então, mas assim, como que ela funciona? Então ela tem um template principal onde eles não têm acesso e nesse template principal eu consigo definir padrões. Então lá eu amarro dizendo assim: "É obrigado passar pelo Sonar, é obrigado a passar pel uma ferramenta de análise de código, é obrigado a, por exemplo, subir para determinado registre, é obrigado a passar pel scan de vulnerabilidade X.

85:05Então eu consigo as imagens Docker, você que define tudo que eu defino, todo o padrão de git de gits, né? hã, ele em Gitow, enfim, ele tá atrelado dentro desse template que eles não mexem. Então eles não têm hoje uma certa autorização de tá mexendo nessa estrutura onde eu te falei, eles mexiam em muitos parâmetros. Hoje eu não consigo. Então, por exemplo, um time de engenharia de software define uma premissa que alguma regra de negócio que o sonar vai ter determinadas características. Eu consigo transmitir para todo mundo aquele mesmo template, coisa que eu não conseguia antes. Eu consigo transmitir apenas fazendo uma alteração, uma regra, um parâmetro.

85:44Agora eu distribuo para todo mundo. Por mais simples que seja, não era a nossa realidade há pouco tempo. Então, a partir de agora isso funciona de forma bem natural. Então isso eu tô falando de build, né, de geração de artefatos, né, de de imagem, que é o nosso core. Hoje nós focamos muito em desenvolvimento em cima de de containerização e em cima de cubs, por exemplo. E quando nós passamos por uma esteira daí de uma parte de entrega, que é a parte de deploy mesmo, releases, assim, aí nós fazemos aquela abstração que o cara se preocupava com geração de manifestos que agora ele não precisa mais. Então nós temos uma staack de devops, né, onde os devops na no no mecanismo aquele que foi comentado de fusiones, eles eles apoiam muitas vezes. Então nessa geração desses manifestos, que é uma versão atual, e os deploys melhoraram tanto a nível de rollback e padronização, absurdamente. Tu imagina que o cara que gerava manifestos e emo mal indentados, alguma coisa assim, acontecia de forma recorrente, agora não acontece mais. Então mudou muito de um tempo para cá.

86:50Até o controle de versões, se você precisar fazer, etc. Tem tudo versionado diversõ hoje, hoje hoje a esteira, só para dar um um resumo para vocês, ela ela não faz deploy diretamente, né? Uma esteira de deploy não faz diretamente em cima do do do ambiente. Nós trabalhamos com Gitops na parte de Argo, Argo CD, onde ele consome esses manifestos para nós, né? Qual que é a questão em cima disso, né? É que eu tenho todos os manifestos e emoversionados. Quando tu trabalha diretamente às vezes com um um litops de um outro formato, tu pode ter uma certa variação. Então o que eu deploi eu tenho certeza exatamente da versão que eu tô subindo.

87:28Então tem algumas amarrações aí que aconteceram. Até comentei sobre as credenciais que vinham, tinham algumas coisas que ficavam expostas. Hoje nós trabalhamos com com o mecanismo de Valt também, que também tá amarrado nesse gits, onde como que eu comito uma credencial via Gitops pro Argo Consumir se eu tô gravando num num repositório, né, um conteúdo. Então isso hoje tudo é muito amarrado e e tem funcionado muito bem. Eu acho que em cima de tudo isso que foi falado aqui de obseverabilidade e tal, eh tem um pouco um bom percentual em cima dessa nova esteira. Nós chamamos muitas vezes, né, o time conhece lá às vezes como 2.0 e 3.0, todo mundo fica um pouco na dúvida, mas vamos considerar como uma uma pipeline 3.0 assim da Unicred. E ela tem uma maturidade bem interessante, ela foi avaliado por vários parceiros, fizeram uma análise assim de de o que que ela usa e ela tem se saído muito bem. As entregas estão muito interessantes assim.

88:19Uhum.

88:20Tanto a nível de deploy, qualidade, quanto a nível de rollback. Claro que sempre pode passar por evolução, né? Nós estamos em tecnologia, então a tecnologia ela sempre vai nos proporcionar novas funções, novas ideias, enfim, né? Não existe certo e errado, mas nesse momento tá atendendo bem muito melhor do que estava antes, né? Então estamos vivendo isso.

88:36E quando você evoluir, evolui todo mundo junto, né?

88:39Porque evoluir a plataforma, não, você não vai ter um time mais evoluído do que o outro, etc. E culturalmente, como foi essa essa absorção? Não aparece ainda aquele dev que chega para você falar: "Cara, minha aplicação só funciona se o Docker File for assim. Eu tenho que ter rodar isso aqui no meu Docker File.

88:56Acontece. Ã, mas nós temos uma premissa muito interessante que os Devops, por eles estarem dentro dos times, essa cultura nós conseguimos disseminar de forma bem legal. Então o problema com Dockerf, nós sempre vamos sugerir para eles uma um certo uma melhoria, um hardening para ela que ele fique um pouco mais eficiente, né? Que ele não seja um um Dockerfile grande, complexo e muitas vezes pesado, né? Para gerar imagens menores.

89:22Uhum. Eh, que casado a isso, nós estamos numa evolução agora de constante hardening. Então, nós sabemos que existem parceiros que fazem hardenings de imagem, mas nós estamos pensando o nosso hardening devido a algumas características que nós temos. Então, eu não tenho autorização de sair pegando imagens do de um Docker Hub, puxando para dentro e largando a minha aplicação em produção.

89:39Qual sentido faz eu pegar simplesmente um artefato assim de imagem e confiar nele? É, porque eu não passo pelo mínimo de um scan, já que eu tenho uma esteira automatizada para isso.

89:49A chance de você injetar alguma coisa numa num imagem Docker Hub, como já aconteceu, por exemplo, com bibliotecas Node, etc., muito grande.

89:57Desculpa para não conseguir.

89:58É, então esse ponto agora do supply chain, né, você controlar exatamente de onde que veio, o que que é, quais são as versões aceitas ali e tal, é um baseline bem importante, porque senão, cara, você tem que na prática verificar tudo, inclusive coisa que não tem nada a ver com o teu produto, né? Então acho que isso é um ponto e até um ponto que o Felipe comentou que eu acho que é interessante. Acho que uma das primeiras coisas que a gente tem que ter de objetivo com relação a pipeline de DevOps e infra como código no geral, é acho que até mais do que elas sejam sofisticadas, é que elas sejam consistentes, né? Se você executar 100 vezes que tem o mesmo resultado, quando você alcança isso aí você fala: "Cara, beleza, é o mesmo resultado, agora eu quero prevenir o problema X que pode acontecer. Você vai colocando guard rails, etc. Mas se você consegue trazer isso em cima de um processo que já é consistente, até para uma pessoa que navega entre o produto A, produto B, essa flexibilidade de times, você começa a ter todo mundo capaz de de entrar ali num cenário que que ele vai reconhecer e vai conseguir contribuir. Você tem cada time numa pipeline freestyle ali, [ __ ] é, não tem denominador comum, né? Então é tudo um trouble shoot em custom que no final você vai ter que revisitar o óbvio a cada vez, né? esse ponto da da consistência. Primeiro, isso isso passa muito também pela pela cultura do desenvolvedor, né? Porque tem aquele desenvolvedor que ele vai querer passar por esse processo, como falou, o cara quer fazer o custom desde o começo porque ele se acha o analista de infra, ele se acha o arquiteto, desenvolvedor, etc. A gente sabe que tem esse perfil.

91:27Hum. Noruega, né? na Noruega, como disse lá no começo.

91:30Uhum.

91:30Eh, agora o cara que de fato ele aceitar, cara, é esse aqui meu bent, o meu rtime, pipeline tá pronto, guardio, tá certo? Eu vou sentar e codar a regra de negócio, esse cara ele vai viver muito mais feliz.

91:44Uhum.

91:45Ele vai evitar um monte de problema na vida dele.

91:47Eu eu eu acho o eu acho que o que o Felipe trouxe, o que tu questionou, o Felipe trabalhou na nessa pipe junto com outros colegas ali também. Eu acho que dá para dizer o ano passado, né, Felipe?

92:00Foi uma boa parte.

92:01Então, tipo assim, tu o que que tu faz ali? Tu tu constrói, só que ninguém tá usando.

92:08Aí tu tem que começar a convergir todo mundo para essa nova pipe. E aí entra o que tu falou da cultura ali também. Então, a gente tinha um compromisso para esse ano de migrar 50% do ambiente, de todos os produtos, de todos os serviços do ambiente até o final do ano.

92:32Isso é o compromisso que que nós, como o time deopes, ali assumiu eh como um indicador lá, como um K.

92:40Uhum. Só que dentro do time a gente tinha um compromisso nosso, se nós vamos migrar 100% até o meio do ano. E aí a gente deu aquele gás ali, organizou no primeiro semestre muito forte pra gente conseguir fazer isso.

92:57Uhum.

92:58Não pelo indicador. O indicador ele é ele é ele é importante, sim.

93:04ele tá conectado a outras coisas que são relevantes, mas pelo valor que a gente entendia que a migração dessa pipe e trazer todos os serviços para essa nova pipe, ele vai trazer pros times, pra Unicred, para nós, em termos de controle, de performance, de segurança.

93:23Então, a gente olha lá na frente e vê tudo que vai entregar, que os times ainda não sabem, mas que pra gente chegar lá, a gente teria que trazer todo mundo para cá. Então, a gente foi muito forte com isso, migrando eh esses ambientes com automações, com controle, com ondas, levando isso. A gente não chegou no 100%. A gente, digamos, a gente fez que nem a Dilma, a gente chegou no 100% no meio do ano e a gente dobrou a meta, porque no fim a gente foi descobrindo ali alguns outros, alguns outros itens que ficam uns rabichos, né?

93:51Algumas coisas que não estavam mapeadas ali.

93:53Aham.

93:54E a gente foi descomissionando também, porque tu vai descobrindo coisa que tá lá rodando, que não tem dono, que não serve para nada, ninguém usa. Opa.

94:02Vamos, vamos desligar. Então, tu também vai dando uma uma limpada, mas a gente sabia da relevância, a importância desse serviço, desse trabalho que foi feito, pra gente poder eh evoluir, porque dentro do que a gente vinha falando de processo, de cultura, eh existe os times que às vezes não querem fazer porque eh tem particularidades e aí tu olha assim, pô, ele não encaixa aqui, mas eh ele tem uma particularidade, ele tem um um modelo, ele tem algo o que não tá encaixando aqui dentro. Beleza? Então não vamos migrar, vamos migrar os vamos migrar o que é que a gente chamava lá, o que é migrável, a gente vai levar o resto a gente vai avaliar.

94:44Vamos estudar. Vamos.

94:45O bom é que esse, esses pontos fora da curva, né, esses outsiders, eles vão ajudar a plataforma a evoluir com, né, porque, [ __ ] não prevíamos isso na plataforma e essa aplicação requer isso. Vamos evoluir a plataforma, põe esse cara para dentro. Outros casos como esse tão cobertos, né? Exato.

95:04Então aquilo que foge, né? Aqueles outliers ali é é um conceito de de evolução.

95:10Faz parte, né?

95:10Faz parte. Então, pô, primeira versão natural que não atenda todo mundo, né?

95:15Mas se conseguir fazer um 70 30, beleza, agora esse 30 vai evoluir e a plataforma uma hora vai ficar cada vez mais madura, né?

95:23Isso aí. E é assim que a gente tá buscando evoluir e trazendo essa essa segurança, esse contexto ali para dentro do ambiente para trazer melhores recursos, mais estabilidade, mais escalabilidade, mais velocidade.

95:35É, ninha de ter pipelines que são consistentes e que você consegue deixar muito menos variável, né? Ao mesmo tempo você melhora a tua frequência de deploy, porque você consegue fazer um negócio muito mais direto ao ponto, né? Sem ter que ficar fazendo coisas custom para para cada release, né? E você acaba melhorando também teu change rate, né?

95:53Porque como você tem menos peças móveis que são parametrizáveis, assim, você chega no denominador comum mais coeso, né, cara, a tua frequência de de deploy com falha não vai ter a princípio mais a ver com etapas de pipeline, vai ter puramente a ver com code base de aplicação. Não é que você elimina bug, né? Isso não existe. Você vai precisar ter ainda uma boa cobertura de teste, etc. Mas aquelas variáveis que você poderia ter de processo, elas já não existem mais, né? você passa a ter uma uma expectativa ali sobre o que que é o ambiente e trabalhando com o ambiente não produtivo de uma visão legal, né?

96:28Você nunca deveria chegar em produção e pegar um problema que você não viveu antes, né? Isso é uma boa boa prática que no final sensibiliza ali na galera que gosta muito de Dora Matrix, States of Devops, né? Change fill rate, deployment são coisas que você vai te habilitar a ter velocidade com qualidade, né? Não não velocidade a qualquer custo, né?

96:48Agora você tocou num ponto chave que eu estava segurando para soltar essa bomba em cima da mesa nesse momento.

96:56Como é que isso se aplica agora nesse contexto de uma sprint que era duas semanas dura 2 horas num desenvolvimento com com a EAI assistida? Eu tenho uma resposta que ela não é completa ainda. Isso tá sendo debatido lá dentro, porque a parte de governança de a é uma das partes mais complexas que as organizações vão sofrer, né, a partir de agora. E como é uma evolução muito rápida, né, então depois eu posso citar um exemplo do que do que tá sendo desenvolvido até pel time pelo nosso time assim, enfim, que entra nesse fluxo. Nesse momento nós não temos um ponto de entrada para eles.

97:34Isso é a primeira dificuldade, né? como que tu entra com software desenvolvido por IA, seguindo todas essas regras ali para trás. Nesse software que eu que eu que eu posso citar aqui, que tá sendo 100% desenvolvido por IA, hoje ele passa exatamente no fluxo que eu acabei de citar para ti. Então, primeiro ele já é um bom um primeiro norte, né? Um primeiro um primeiro controle que nós temos é passa na mesma esteira, sonar passa na mesma esteira de segurança, né?

98:02Eh, aí começa, nós começamos a se preocupar com algumas outras coisas que é que são as arquiteturas de referência, por exemplo, né? Então, como que esse essa aplicação tá sendo criada? ela está aderente ao processo de arquitetura de referência que tá sendo desenvolvido pelo time de engenharia de software, por exemplo. Isso é uma etapa que a própria Unicred de forma geral precisa ter como premissa na esteira, que aí entra como um braço, que é as próprias IAs hoje já fazendo essa pré-análise, né, desse código que tá sendo desenvolvido, se aquela aplicação tá aderente à arquitetura. Mas na camada que que eu posso te falar hoje claramente é que o que tá sendo desenvolvido, que normalmente passa pelo nosso time, um desenvolvimento que nós estamos fazendo, ele passa já nessa nessa esteira. é um tipo de premissa, porque ele é muito rápido, mas para nós é independente se ele vai ser entregue eh de forma rápida ou não, a esteira é a mesma. E o provisionamento dessa esteira pelo time de VOPS, por exemplo, hoje é muito rápido. O que nós estamos fazendo, te dando até um overview aqui sobre isso, o que nós estamos fazendo para acelerar essa entrega é o IDP que o próprio Bruno comentou. Então, nós estamos num desenvolvimento com a utilização de a de um IDP interno, onde nós acreditamos que os delays, né, o tempo da da idealização até a produção, vamos dizer assim, que nós temos aqui uma linha, ele é mais curto hoje. Então, com o apoio do de um de um IDP, ele vai nos nos auxiliar para que ele seja mais rápido e mais padronizado. Então, com uma entrada de um produto sendo com a origem de a ou ele sendo uma demanda de negócio, por exemplo, de um 100, a o canal de de de criar essa essa esteira e deixar ela apta para esse cara subir, não importa se vai ser em uma hora ou se vai ser em duas semanas ou até mesmo 30 dias, é o mesmo. Porque o nosso problema não é a criação da esteira que já é automatizada e agora com o IDP agiliza mais. É sim, como que eu garanto que qualquer produto da Unicred tenha o devido controle ou a devida análise já de forma automatizada, vamos dizer assim, sem que precise alguém rodar algo, pegar algo.

100:17Se eu simplesmente canalizar todos os serviços pelo mesmo canal onde eu tenho todos os controles, seja sejem eles de segurança, de arquitetura, de governança, de tudo, que é o que é a nossa meta, nós estamos cobrindo alguma delas, mas não total, não todas ainda, é isso que nós almejamos ali na frente.

100:35Eu acho que é é meio que uma evolução, né? Porque a gente passou por um momento em que esses gates eram manuais ali com o cara do geralmente o o analista de governantes, quase que pessoais, né?

100:50É, quase que pessoal. O cara falava: "Fez teste de carga".

100:54Uhum.

100:54"Tá passando no sonar." Era um comitê ali de mudança que fazia, "Não, não vai subir." Aí o cara já desenvolveu tudo, tá na data de entrega e tomava um bloque, né?

101:04Sim. A gente automatiza isso.

101:06É, o complicado desse bloco, principalmente, era quando o critério não era previamente acordado. Assim, se você sabe, cara, o regulamento para colocar em produção são essas regras aqui, cara. Se você não se preparou, né, teu launch checklist, etc. Para aquilo ali, cara, é um risco que você decidiu tomar.

101:24O complicado é que muitas vezes não tinha um critério claro de qual que era a barra para aquela release específica.

101:30Às vezes algumas eram mais exigentes, outras menos, né? E aí você eu vi em alguns cenários um cenário que você tinha um conjunto de regras que era um pouco maleável, né? E aí quando tinha aquela pressão de negócio para realmente subir alguma coisa, começava a ter um padrão de cara quase todo dia tinha hot fixa. Eu falava: "Cara, não é possível.

101:49Como que você tem, cara? Isso na Noruega é terrível, velho.

101:52Nossa.

101:53E aí isso isso é complicado. Esse pessoal, os Vikings é sofrem muito.

101:58Você passa a ter um um fast track ali que não tem toda a governança porque é uma hot fix, né? Você fala: "Pô, como é que eu vou deixar o negócio quebrado em produção? Não coloca ali, né? Só quer ir junto.

102:09Iam algumas coisas ali que eram features, né?

102:11E isso de fato quando você consegue ter esse denominador comum, né? O meu launch checklist, ele é padronizada independente de qual release, aquelas etapas ali tem que ser cumpridas e você consegue parametrizar esse processo para ele sempre ser executado ali de um ambiente não produtivo em diante, né?

102:29Ele te trazendo esse resultado mais assertivo, né? Cara, o time que escolheu não se preparar da melhor forma, ele tá assumindo o risco de atrasar uma release em produção, porque, cara, o preparatório dele, ele não fez, né? O maior problema é é essa coisa cultural, né?

102:46bem que você bem colocou o a gemmude emergencial de Hot Fix carregada de feature que o cara deveria ter entregado semana passada, não entregou. E aí a governança não sabe, não tá registrado em log.

102:58Uhum.

102:59E o cara fez uma mudança que não tá registrada, quebrou alguma coisa e ninguém tá olhando para isso.

103:05É, o cara não tem rastabilidade ali que aquela aquele ID não não gira ali, por exemplo, não tracker, cara. Ele deveria vir acompanhado só da mudança que tá descrita ali, mas se você não faz um code review ali, cara, às vezes o cara embarca.

103:19Exato. O cara embarca, o cara fez uma mudança, sei lá, criou um índice no banco que travou tudo. Uhum.

103:24E aí o cara falou: "Não, cara, mas aqui foi só um hot fix de escrita no disco, por exemplo." Uhum.

103:28E aí o cara, coitado do do SRE, tá tá perdido, né? Tá, tá vendido. Mas eu queria pedir a tua ajuda, Brunão, para fazer um glossário aqui até para ajudar nossos ouvintes. Quando a gente tá falando de IDP, a gente não tá falando de identity provider, a gente tá falando de um outro conceito, né? Explica pra galera. é o que o pessoal na engenheria de plataforma chama, né, de internal developer portal, né, que você tem algo que dentro daquela empresa materializa uma série de padrões e escolhas, né, e habilita todos os times que vão desenvolver produto ali, né, possam já partir desse desse acordo, né, entre times ali que fala, cara, se você quiser seguir o caminho feliz que a plataforma te entrega, todos esses assuntos aqui que são decisões que você não quer tomar, né, segurança, qualidade, etc. Já estão feitos por você.

104:15O famoso vem com o pai.

104:16É exato.

104:17Vem, confia, confia que você vai ser feliz.

104:20Seguindo, seguindo, né, o fluxo, na real, nós conseguimos amarrar todas as dificuldades que nós temos eh muitas vezes em padronizações e governança, né?

104:30Em resumo, tu consegue canalizar ali literalmente dizendo assim: "Cara, faz isso que vai dar certo." É esse é o caminho, né? tu tá totalmente aderente, porque ele vai tá aderindo a tudo. Se ele passa por fora do do processo, que às vezes não é uma opção, né? Mas às vezes nós sabemos que que processos eh precisam ser contornados por diversos motivos. O negócio funciona assim, não podemos ser o o negócio vem primeiro, né, em alguns casos, mas também sempre com segurança. Mas enfim, se tu tá pedindo pelo ID, tu sabe que tanto a parte de self service, que é o a principal ideia, né, que o que o cara lá da ponta ele possa promover a stack dele sem saber uma linha, por exemplo, de um manifesto, ele simplesmente, por exemplo, ele precisa de um ingressive e não, eu quero acessar a URL com a minha aplicação tal, mas abstraindo completamente o que que é um ingress ou se é um gateway de API por baixo.

105:22Isso é a abstração que o ITP normalmente gera, né, pras pessoas. Então essa publicação já com o próprio Bruno comentou, né, uma o que que são os requisitos num checklist para mim pegar hoje uma aplicação de homologação, por exemplo, que já passou por ambiente de teste, homologação, o que que é o requisito para mim ter uma garantia certa que essa aplicação, certo não existe na tecnologia, mas eu vou usar o certo aqui, que ela vai sair de homologação e vai entregar em produção.

105:49Uhum. todos os checklist, todas as criações, toda a configuração, a criação da base e coisas que podem sim estar amarrado ou não, tá tudo pronto.

105:58Sim. Hoje, quem é que faz essa análise, né, sem um IDP ou sem uma esteira que que garanta isso, tem que ser uma persona, então tem que ser alguém que faça isso. Então, nós tentamos muit muitas vezes dentro desse fluxo é tirar essa camada do DevOps, essa obrigatoriedade que o time de produto vai olhar para ele, vai cobrar ele no sentido, cara, dá uma olhada para mim se tá tudo pronto realmente, para mim ter uma garantia, que é o papel do DevOps, né, é dar uma olhada, mas nós estamos tentando criar uma lógica e uma inteligência. E aí entra Ia, entra IA nos auxiliando, né, a também vincular as necessidades ao próprio turbo shooting também a análise do que nós queremos.

106:36Então, com a evolução natural do IDP, ele começa também ter essas essas amarrações para nós ter mais segurança e mais entrega com efetividade, né?

106:45E eu acho que isso é meio que um caminho sem volta assim, porque a gente tá mudando a forma de desenvolver software de forma definitiva, né? Uhum.

106:54Então, a aquela forma mais artesanal, mais ruts, digamos assim, que a gente fazia há tr 4 anos atrás, ela vai deixar de existir. Você vai cada vez mais pilotar os agentes para desenvolver esse código para você do que você de fato começar a escrever código.

107:13Uhum. E quando você tem um repositório de regras corporativas que que podem estar, por exemplo, concentradas dentro do INDP, onde você defina quais são as aplicações, etc., Isso facilita muito, né, Brunão, como você mesmo falou no durante o episódio, o shift left, eu começo a levar essas essas premissas Sim, sim, para dentro da EAI e do meu harness, para que além da verificação que eu preciso fazer naturalmente depois, aquele código já nasça dentro do compliance, do que eu estipulei dentro daquela plataforma, né? Então, cara, sei lá, tô aqui viajando e eu corro um risco muito grande porque daqui se meses as coisas podem estar completamente diferentes, mas eu posso ter, por exemplo, um IDP onde eu defino minha plataforma, one time, minha característica, etc. Cara, aquilo vira uma skill, eu boto no meu codex e ela já vai nascer da forma corporativa que eu deveria, né?

108:09Acho que tem tem alguns princípios, né, que, por exemplo, eu gosto bastante e daquela tem galera do Heroco muito tempo atrás, né? propôs aqueles padrões lá do 12 factor app, né, que são princípios ali de como que você constrói uma arquitetura e etc, que seguem sendo bem válidas, né? Algumas dessas questões, se você começa a ter esse advento, né, de um de um IDP, algo que te força a seguir aquele padrão e esse padrão vai te levar para essas boas práticas, por exemplo, né, você externalizar configurações credenciais, você não embarcar aquilo ali dentro. Cara, para você navegar entre diferentes ambientes, você vai basicamente parametrizar. Olha, no ambiente de produção, a a chave que eu vou ler com a credencial é aqui em homologação, aquele outro. Mas, cara, o produto ele se comporta da mesma forma, né? Você só tá mudando o parâmetro.

108:56Olha, stage assim, produção aquele outro jeito, né? Então isso torna a tua arquitetura inclusive mais portável, né?

109:03Você não precisa fazer uma reconfiguração eh por completo, não.

109:07Você, cara, teu baseline de arquitetura é o mesmo. Teus princípios ali de cor tem uma preferência, né, de uma aplicação mais transiente, etc, que não seja tão stateful, né? Então, que você pode portar do ambiente A para ambiente B sem precisar levar tudo que tá envolvido ali, né? Isso acaba se materializando, né, na visão do IDP, né, como você comentou, né? E aí quando você vai nessa visão de de harness, né, que você pode embarcar algo na linha até de um de um modelo que você vai usar para ser um assistente de de desenvolvimento de código, que vai ter suas regras de segurança, cara, empresa pode escolher, por exemplo, pode ter empresa que vai falar: "Cara, aqui eu não quero nenhum modelo proprietário, eu só quero modelo open weight lá, open source, etc." Era uma decisão que ela pode tomar e se ela vai nessa linha, né, de um IDP e de um de um harness, né, ela pode materializar ali dentro das escolhas que ela fez.

109:52Então, acho que isso é bem interessante e cabe a gente, acho que quem trabalha com tecnologia saber navegar nessas abstrações. Você tem que entender o que que tem por baixo, o que que você pode ou não mexer, o que que é seguro você mexer ou não. E saber que se você comprar as escolhas que foram feitas ali, a tua vida vai ser mais simples, porque você não vai ter que decidir aquela cacetada de detalhe, [ __ ] qual que é subnet, qual que é, cara, tem muita coisa, rating límite, tudo que a gente falou hoje, né, são coisas que, cara, em algum lugar alguém vai ter aquela escolha consciente. Cara, em homologação, meu rate limit, mas em produção eu já sei que o rate limitado de acordo com o que é a minha expectativa, né? Então, todas essas decisões, se eu sou um cara que tá lançando uma nova API aí do Pix, cara, não quero decidir tudo que tá por baixo ali, cara. Isso aí é é no final trazer um overhead, uma carga cognitiva pro time que ele não precisa para que ele conteste negócio. Sim. E e eu acho que isso vai ficar cada vez mais naturalizado, né? Porque acho que o desenvolvedor ele tá aceitando. E aliás eu deixo a recomendação aqui, assistam o episódio que a gente falou sobre experiência do desenvolvedor, que tem tá muito ligado a inclusive ao conceito de plataforma, etc. Ele tá começando a entender que ele pode delegar algumas coisas, ele não precisa estar no controle de tudo, né?

111:11Porque isso é saudável, né? E a partir do momento que ele tá delegando até o a a própria geração de código para controlar o resultado e e ver a efetividade do que ele tá desenvolvendo e não a linha que tá sendo escrita, faz muito sentido que esse cara em algum momento se adapte a entender que, cara, eu vou delegar isso daqui para um uma outra camada de de controle de outros profissionais estão olhando isso para mim. Sim.

111:39E eu vou desenvolver dessa forma porque faz mais muito mais sentido, né? E as o as grandes empresas, por exemplo, um um cara que sempre grava aqui com a gente e fala muito sobre plataforma, eh o Juliano Martins, um abraço para ele, que ele foi head de plataforma no Mercado Livre. Cara, no Mercado Livre é tudo IDP, cara, 18.000 deplo por mês, né?

112:03Exatamente. É, é, é muita coisa. Os caras fizeram uma plataforma interna, aí entrou, foi agora tá, acho que tá indo, tá vendendo pro mercado e tal. E cara, não tem como você humanamente numa empresa tamanho do Mercado Livre com 18.000 deploymentos por mês, tomar decisão de Docker File a cada entrega que tá tá sendo feita, cara.

112:23Não ia fazer 18.000.

112:24Exatamente. Ia fazer ou vai ter 200.000 Exato.

112:28Proficionais para fazer isso.

112:29Exatamente. Então, eh, é uma questão de escala e é uma questão de de fato a gente começar a colocar as camadas de decisão ou de controle onde de fato faz sentido, né?

112:39Sim. E diferente do Spotify, tu vê as mudanças, né?

112:44Exatamente. Exatamente. Spotify, a gente nessa nessa linha, né? Eh, se você consegue ter essa linha de de abstração, né? Você começa a ter assim uma equipe mais enxuta que consegue mexer o ponteiro com relação ao resultado, sei lá, o cara que vai pilotar segurança, né? Se ele vai conseguir usar e essa pilha, né, de decisões de arquitetura, etc., em cima de um de um IDP, de uma solução que entregue end to end, cara, ele vai poder tomar a decisão muito mais profunda, porque ele vai poder abstrair algumas outras que não competem a ele.

113:16por exemplo, cara, ah, eu vou tomar uma decisão com relação à segurança, quais são as imagens, como que o meu processo, né, de que vou escolher as imagens de base ali e tal, se ele puder ignorar completamente finops, eh, temas ali de eh orquestração de API, cara, a vida dele fica mais fácil, ele gera um um artefato com uma qualidade melhor dentro da competência dele, né? Eu tenho visto, né, uma um movimento, né, das equipes em geral ficarem mais enxutas e especializadas, mas isso só é possível se você aceita algumas abstrações, decisões que você não vai tomar, porque não não cabe, né, não dá mais pra gente navegar com tanta complexidade se você tiver que decidir tudo por baixo, né?

113:56Alguém já tomou essa decisão e já pensou nisso por você, né?

113:59É. E e a gente tava falando antes ali sobre capacidade eh dos profissionais, né? Eu acho que hoje a gente a gente tem buscado muito olhar pelo soft skill também dos profissionais e para entender porque tu acaba tendo profissionais às vezes tecnicamente muito bons.

114:15Sim.

114:16Mas que não tão com a talvez com o mindset ali tão tão abertos a poderem se adaptar a novas novas rotinas. É que nem tu pegar um cara que tá assim, como a gente diz ali, se criou com B metal, depois foi pend, depois foi pra nuvem e o negócio dele é é é servidor e VM, é operar, né?

114:40O ele e a primeira coisa que vem na cabeça dele é isso. Ele não pensa ali quando vem um serviço, um produto, uma aplicação, um negócio e que aquilo ali pode ter um outro tipo de tecnologia envolvida, que tu pode ter tudo automatizado, instrumentado. Sim. Fresh Code já é um negócio que já é já era para ser tão commodity.

114:59Sim, verdade.

115:00E e tem gente que ainda não pensa nisso, né?

115:02Não tem cara pilotando ali no painel do do da do Vem da unha até hoje, sabe? E é mais comum do que acontece lá na Noruega, mas isso acontece na Noruega acontece bastante. E e eu acho que essa questão cultural ela envolve muito do que vocês estavam trazendo ali também de como essas pessoas estão desenvolvendo, como elas estão preparadas ali para esse crescimento. Porque se se a gente não olhar para isso, não olhar pra Iá, não olhar para esse estudo, como as coisas estão crescendo, não se não procurar se adaptar, entender como isso pode melhorar o meu trabalho, ao invés de ficar se agarrando no My Pressions ali, né?

115:39Uhum. Sim, sim.

115:40Tu vai acabar ficando para trás inevitavelmente.

115:43É isso. Tem até acho que uma questão num nível cultural da organização, né? Você tem que aceitar que nessa linha evolutiva, mudança de cultura, de práticas, plataforma, etc., você vai ter algum nível de quebra ali, né? Nem tudo vai dar certo. Você vai ter que ter uma tolerância falha e o cara sentir que, [ __ ] se ele errou, mas dentro do que foi combinado, etc., ele não vai ser aquela aquela mita a questão do do blameless, né? Você focar muito no resultado e não ficar caçando ali culpados, né?

116:11E e acho que isso a gente para ter qualquer mudança disruptiva, né? Quando você sai do on do do bare metal, vai pra virtualização, vai pra contêiner, daqui a pouco, cara, a gente se coloca numa situação meio frágil de você passar ser meio iniciante ou inexperiente numa tecnologia nova, numa abordagem nova. É natural, né? você vai ter que fazer algo que te tira da zona de conforto, mas porque você percebe que aquilo ali bem aplicado, se eu acertar a mão, vai me colocar num patamar diferente. Mas a gente a tem que aceitar, né, que a gente dura um tempo, vai ter que ser frágil, você vai ter, cara, vou tentar fazer algo que eu nunca fiz antes. [ __ ] a primeira vez que eu fiz um um uma release em produção com um agente pilotando tudo, cara, ali falar, cara, o quanto que eu confio nisso aqui agente.

116:54Então, isso é é complexo, né? Só que assim, a gente nessa linha, né, cultural e nessa questão até de soft skills que você mencionou, o cara tem que ter e eu gosto muito daquela visão do mindset de crescimento versus mindset fixo, né?

117:05Você falar: "Cara, eu ainda não sei fazer isso aqui, mas eu sou capaz de me desenvolver, vou pegar, etc. E ao mesmo tempo, se eu me desenvolver, eu vou me manter valioso e atualizado." Isso te coloca numa posição de, cara, eu ainda não sei, eu ainda não domino, vou ser frágil durante um tempo até eu ganhar aquela nova competência, né? Mas isso aí vai ser um investimento que vai me trazer dividendos lá na frente, porque eu vou fazer melhor, mais rápido e etc.

117:29Só que tem gente que às vezes pode ser por vaidade ou porque já não tem mais nenhuma paixão na né, quando ele tá, ele pode falar: "Cara, não, [ __ ] vou procurar os ambientes em que essa competência que eu adquiri ao longo de 10 anos, ela ainda seja valiosa." E aí isso é é fato, cara. Muda muito. E hoje eu prefiro tipicamente, né? Claro que você tem que ter a competência, ela é valiosa. Você pegar um cara que resolve um problema complexo, isso é valioso. Só que acho que é é importante a gente setar a expectativa de que, cara, mais importante do que aquela do que aquela competência que ele foi moldando ao longo do tempo é a abertura dele de estar e disposto a perseguir novos problemas, novas coisas que ele vai resolver, porque independente do momento em que a empresa tá, esse cara vai est comprado com resolver o problema certo.

118:14Não pode ser problema, certo?

118:15Tem que continuar gerando competência, né? Ele não pode ficar preso à competência que ele obteve, mas ele ter voltar a ser competente em coisas novas. Até porque, cara, a gente tá vivendo um momento da nossa profissão agora que daqui a se meses a gente pode tá falando de outras coisas.

118:30Sim, sim. É, a requalificação ela é contínua hoje em dia, né? Você não tem, sei lá, antigamente é, ela sempre foi, mas ela tá cada vez mais rápida, eu acho. Sim, sim. É quando eu, cara, era meu javeiro das antigas lá, cara, você aprendia, sei lá, um novo framework por ano ali, o pessoal mais avançado falava: "Cara, você tem que aprender uma nova linguagem de programação por ano". Cara, nunca achei isso tão fácil assim num nível básico, entende? Beleza. Agora, cara, você consegue colocar coisa em produção sem nem saber a linguagem por baixo. Se você tiver um bom princípio de direito de software, pega até umas lingu, pessoal brinca, né?

119:04Tem umas linguagens que são tipo right on, que é tipo pearl, né? você escreve, ninguém lê aquilo ali para cara, se você fez algo que foi pra produção sem nem você entender, você consegue passar de ano mesmo não dominando aquilo, né? E quando você vai para essa linha de, cara, se até a linguagem ela é meio, não digo que é commodity, mas ela é um conhecimento que você não precisa dominar profundamente, os problemas que você vai ter que resolver não são mais no nível da linguagem, não são mais no nível, pô, antigamente dinheiro de software tinha que saber para caramba de SQL e ele tinha que aprender para cada banco era, cara. Agora é, tem RM, tem um monte de coisa ali que faz t automático, né? Abstraind que é que é uma uma da uma das ideias do IDP, né? abstraem um pouco e a gente até, desculpa te atrapalhar, mas a gente até agora pegando IA, isso que a gente fala de IDP, esse processo todo, eh, dentro ali do time de VOPS, a gente montou meio que uma squad de profissionais e que estão parttime trabalhando no desenvolvimento de um piloto, de um protótipo do de um similar a um IDP, a gente chama de UDP.

120:12Uhum. Uhum.

120:14E e é e é porque a Unicred Devops Porto começou assim justamente para resolver os problemas que a gente que a gente tinha.

120:22Problema do DP que não tem controle de pacote, cara.

120:24Mas exatamente aí agora a gente tá piadinha interna entrega rápid rápid entrega rápido. Era essa aí a ideia.

120:33E e a e aí a gente tá fazendo justamente essa essa experimentação e é um piloto na na dentro da nossa superintendência do uso do cloud code.

120:42Uhum. no desenvolvimento. Então, em várias em várias áreas fazendo essa experimentação e dentro da nossa área a gente começou a construir ali essa essa solução ali. Sim.

120:52E tu vai experimentando, tu vai criando, tu vai construindo e tu entra nessa n assim, alguns entram nessa claro nessa roda que assim exato.

121:01É quase que uma droga.

121:02E eu vou ter que chamar vocês para mais um episódio, porque a gente tá virando 2 horas de episódio já.

121:08Parece ser menos, mas a gente está aqui já há um bom tempo trazendo essa e e aqui a gente tá num terreno que a gente tem muito que falar, né?

121:21Porque a gente vai começar a falar sobre o uso de inteligência artificial, futuro dessas esteiras que a gente tá falando.

121:27A gente vai pode ficar aqui para mais três episódios. Dá fazer uma série, 24 horas.

121:34Exatamente. Então, pra gente já encaminhar pro fim, desculpa cortar a vibe que tava muito boa, eu queria que vocês dissessem um conselho, uma palavra amiga pro cara que ainda tem eh muitos incidentes críticos por ano, porque vocês tiveram uma jornada de evolução incrível que a gente ouviu aqui, né, que passa por entender que tem um problema e entender que esse problema precisa ser resolvido.

122:04né? E tem muito gestor que ainda vive em negação, né? Ele acha que não tem um problema, que ele não precisa evoluir.

122:09Eu eu queria que vocês dessem uma palavra para esse cara, que que esse cara precisa eh começar a a olhar diferente na vida dele a partir de agora?

122:20Cara, o que eu o que eu converso bastante com o time ali, eh, na nossa área a gente precisa ter muita resiliência.

122:29Às vezes a gente não gosta de uma pessoa, não gosta de uma área, pega a birra com alguém, pô, sempre trava com aquele cara, sempre trava com aquele time e e começa a cair numa discrença e falar assim: "Cara, nunca dá certo, sempre é difícil, sempre é complicado.

122:47Isso é a vida te colocando as barreiras, as dificuldades. Se tu parar ali, tu já perdeu. Então, não desiste. Se tu acredita naquilo ali, se tu entende que aquilo vai trazer resultado, se aquilo vai ser bom, acredita, luta por aquilo ali. Não desiste no primeiro não. Se a gente, eu, eu eu converso com o time ali, se a gente parasse no primeiro não, a gente não tava aqui, meu. Eu não existia, tu não tava aí, a gente não tinha evoluído, que a gente evoluiu. É cansativo, é, mas eu acho que, cara, toda a empresa tem isso. Às vezes a gente olha pra grama do vizinho, acha que é mais verde, mas quando tu vai cortar a grama lá e vai lá, cara, tem os mesmos problemas. A gente conversa com várias empresas de vários tamanhos, todos têm os mesmos problemas. Então, não desistir, eu acho que é a palavra resiliência.

123:37Se todo, se alguém falar que a cozinha dele é limpinha e não tem nenhum problema, desconfie. Exato. Sempre tem um paninho de prato sujo. Tem, Felipão, dá uma o cara que tá tá olhando para esse assunto de DP, etc. Vê isso como um grande desafio.

123:54Cara, eu vejo que que ter um ter uma padronização das coisas pro cara que tá começando, que ele enxerga que o mundo tá tá caindo no colo dele, problemas acontecem, nós estamos em tecnologia, tem lugares, como nós falamos agora, com mais problemas, tem lugares com menos problemas.

124:13Mas com confiar e saber lidar com as situações, como o Nes mencionou, conversando com todas as áreas e tendo um bom diálogo, tu consegue, se tu tiver essa credibilidade, conseguir buscar isso, tu consegue orquestrar e amarrar os processos, né? Quando uma concepção, fazendo um padrão como a questão do do IDP, é o IDP, no final das contas é a conversa com todas as áreas amarrando processos. Então, se tu tem uma boa comunicação com todo mundo, tu consegue ter esse tu ser protagonista muitas vezes de iniciativas que ali na frente tu vai tá podendo resolver n resultados.

124:54Então, problemas que tu tem com diálogo com todo mundo, logo tu pode criar estratégias, né, usando hoje a própria inteligência artificial, podendo te auxiliar aí a tá melhorando tanto a organização quanto trazendo novas ideias. Eu acho que basicamente é isso.

125:09E para fechar assim o que a gente fala, nada acontece quando a gente querum e sim quando tem que acontecer. Tem um momento certos para tudo.

125:17Então às vezes a gente acelera muito, tá com muita ansiedade, mas às vezes, cara, não aconteceu porque não tá no momento, no meu, no teu.

125:24A vida e a empresa tem um tempo diferente da gente.

125:26Exato. Sim, sim.

125:27E aí, Brunão, queria também as suas considerações finais. Você que acompanhou e participou de todo essa essa evolução aqui com a com a Unicred, queria que você desse suas considerações e o cara que tá precisando de um parceiro também para avançar por todos esses objetivos, né, por todos esses desafios, como que ele encontra a Elvin para poder ajudar ele?

125:51Legal, bacana, cara. Um um ponto que eu que eu sempre valorizo muito, né, eu comento, né, qualquer coisa que a gente vai fazer que é diferente, a gente vai de fato errar bastante até chegar, né, no resultado. Eu particularmente gosto muito de fazer benchmark para ver, cara, o que que alguém que tá num nível de maturidade ou de repente já alcançou um sucesso interessante naquilo ali, que ele tentou que deu certo, deu, se eu puder errar menos por conta própria, porque eu conheci um pouco, né, da tentativa e e aprendizagem dos outros, acho que isso sempre é válido, mas é é o que o pessoal fala, né, cara, muitas vezes é mais transpiração e determinação para seguir tentando, mesmo quando você quebra um pouco a cara, né, do que achar que você vai ter um [ __ ] um insight genial. O teu plano A vai ser direto.

126:34Não, cara, você vai ter que tentar terar, viver desafios, aprender com eles e a cada, sei lá, a cada vez que você tenta de novo, já aprendendo um pouco mais com aquilo, você vai chegar um pouco mais perto do resultado, talvez você vai errar de novo, né? Mas acho que esse objetivo e essa linha eh contínua ali de aprendizado, muito nessa linha, né, de blameless, né, você não não procurar culpados e sim procurar aprendizado, esclarecimento, acho que é um ponto que que é bem legal. E, cara, eu gosto muito, né, dessa visão do do SRE que o Google eh promove bastante, né, porque eu acho que ela de fato se aplica em uma ampla gama de empresas, não vou dizer todas, mas uma ampla gama.

127:13Claro que cada uma escolhe que se é o modelo operacional, se ela vai trabalhar de um jeito ou de outro, como que ela vai trabalhar. Tem muita coisa aberta para você decidir, mas ela e consistentemente entrega um modelo operacional mais maduro do que você estava quando você começou. Então acho que esse caminho, né, de buscar coisas de SRE, modelo mais confiável, tem uma prática de engenharia melhor, normalmente correlaciona com o que eu vejo de produtos de sucesso. Aí eu tô falando produto de sucesso de negócio mesmo, não tô nem falando o produto cuja engenharia é maravilhosa, porque acho que tem muita coisa que uma engenharia bem feita proporciona um resultado de negócio também interessante, não é automático, né? A gente tem que sempre conquistar esse tipo de coisa. Mas acho que foi foi bem interessante ver essa trajetória, né, de de cultura, uma prática que vai melhorando a cada semana, a cada experimento. E você vê, cara, o quanto que a a qualidade das discussões, o paradigma de operação evoluiem, cara, num intervalo curto, cada 6 meses, 12 meses, é impressionante. Então, acho que, cara, eu super admiro o que o pessoal conseguiu fazer lá em termos de de cultura, de maturidade. E, cara, você vê trabalho consistente gerando, né, a cada semana parece que você progride pouco. Você vê, cara, o pouquinho que você moveu o ponteiro a cada semana, olha para trás, um ano que passou, cara, é muita diferença. Então, acho que isso é bem legal. Todo mundo, né, que se identifica um pouco nesse tema, né, de engenheiras de confiabilidade e tudo.

128:36Não vou dizer que na época que eu tinha cabelo, porque isso seria mentira, né?

128:39Já não tenho cabelo há muito tempo, mas eh já tem bastante tempo que a gente vem tentando eh aplicar e sre, essas práticas de observabilidade em produtos digitais, isso normalmente tem trazido um resultado bacana. Então, se você tá vivendo desafios como esse, né, de cara problemas em produção, sala de crise que não não tem uma luz no fim do túnel e falar, você quer de repente ver caminhos que você pode tentar seguir, a gente sempre tá feliz em contribuir, cara. Tô sempre presente nas redes, nos eventos, meetups e tudo. Então pode me chamar que vou ter o prazer em contribuir, tentar trazer um pouco de de opções ali pro pessoal eh evoluir, se possível ter um nível de maturidade, assim como o Unicred conseguiu, por muito mérito próprio deles lá, de seguir tentando e seguir sempre buscando a próxima opção que vai funcionar, independente se aquela opção inicial não, não foi exatamente a que acertou na mosca, né?

129:28Então é perfeito. É, acho que é isso, fica, fica essa lição aqui pra gente que é uma jornada, né? É uma maratona, não é uma corrida, né? Tem tem que ser passo a passo e e uma evolução contínua, né? Não tem não tem receita de bolo, não tem mágica, né?

129:46Então é trabalho e evolução na veia, né?

129:50Excelente.

129:51Tem que ter paciência, procurar os exemplos, fazer benmark, conversar e botar para rodar.

129:58E se gostou dessa conversa, se inscreve, curte e compartilha. O cara é muito influencer, cara. Obrigado por isso.

130:05Muito bom, meus amigos. Obrigado demais.

130:08Vocês foram muito bem. Parabéns pelo trabalho que vocês têm desenvolvido. Foi uma lição aqui impressionante para todo mundo que que acompanha, que gosta desse assunto de operação de tecnologia.

130:19Obrigado. Próxima vez traga um churrasco gaúcho para fazermos aqui em São Paulo.

130:24Brunão, obrigado novamente pela contribuição aqui com a gente. E você que acompanhou a gente até agora, muito obrigado pela audiência de vocês. Se você curtiu esse papo, compartilha, coloca nas suas redes sociais, manda no slack da empresa, manda do grupo da família, manda pro e-mail do diretor, sei lá, manda para todo mundo. faça a palavra eh eh ganhar outras outras mentes, porque é uma grande lição aqui.

130:52A gente sempre quer contribuir com a vida de com a vida profissional de todo mundo. E se você acha que pode contribuir ainda mais com o PPT no Romilas, você pode ser membro do canal, vai lá no YouTube. No YouTube você tem a opção de se inscrever e ser membro do canal. Você vai contribuir com o PPT no compila com valor todos os meses. E se você quiser fazer uma contribuição esporádica, você pode usar o pix@ pptnocompila.com.br.

131:17Meus amigos, obrigado novamente. Papo foi muito bom. Valeu,