Como a IA Transformará as Práticas de DevOps e SRE | Better Stack Podcast Ep. 12
BBetter Stack
Computing/SoftwareAuto EnthusiastManagementTelecommutingMental HealthInternet Technology
Transcript
00:00:00Vou colocar desta forma: abra um projeto no Claude Code e peça para ele projetar uma ponte
00:00:05Ou um arranha-céu
00:00:08E então eu quero que você pegue esse projeto e vá construí-lo
00:00:12E depois eu quero que você vá sentar lá dentro. Você vai se sentir confortável fazendo isso?
00:00:16Você vai se sentir confortável dirigindo sobre essa ponte que ele projetou?
00:00:19Exatamente até... até você parar de balançar a cabeça. Precisamos desses engenheiros lá
00:00:25Bem-vindos ao Better Stack Podcast, onde conversamos sobre desenvolvimento de software, IA e todo tipo de nova tecnologia
00:00:32Eu sou um dos seus apresentadores, Andris, e estou acompanhado hoje por Wishes. Olá, e
00:00:38Amin Astani. Olá, Amin. Como vão as coisas? É um prazer tê-lo aqui.
00:00:44Sim, ah, obrigado pelo convite. É um enorme prazer. Então, pelo que sei sobre você,
00:00:51eu diria que você é
00:00:53meio que um mago de SRE. Você entende muito bem desse assunto, apresenta seu próprio podcast sobre o tema,
00:01:01então estamos curiosos sobre como você começou nessa área e como tem sido a sua jornada
00:01:08na carreira de desenvolvimento de software até agora.
00:01:11Sim, boa pergunta, Andris e Wishes. Obrigado pelo convite. É, como eu comecei?
00:01:17Bem, quando eu estava no ensino médio, a mãe da minha namorada me apresentou o Red Hat Linux.
00:01:23Ela estava fazendo um curso de ciência da computação na faculdade comunitária e ela
00:01:29simplesmente me mostrou a área de trabalho dela, que não era Windows, não era Mac. Eu fiquei muito confuso. O que era aquilo era um ambiente KDE rodando em
00:01:37Red Hat Linux, e eu fiquei fascinado. Comecei a me envolver com isso lá no penúltimo ano
00:01:44do ensino médio e depois consegui meu, an
00:01:47diploma em Ciência da Computação, fiquei muito interessado em infraestrutura, em sistemas operacionais e em ensinar um computador a fazer coisas
00:01:55que antes nós não controlávamos. Então esse foi o começo.
00:02:00Então você sempre foi um defensor do software livre, imagino, se você usa Linux.
00:02:06Ah, 100%
00:02:08O Linux tem sido o meu sistema principal
00:02:10há mais de duas décadas, tipo desde
00:02:122005.
00:02:15Certo. E quando foi o momento em que você começou a levar SRE a sério?
00:02:20Sim, isso foi há cerca de 10 anos. Antes disso, eu era um profissional de operações clássico em uma empresa de
00:02:29SaaS em rápido crescimento chamada Acquia. Se você já ouviu falar do Drupal, o fundador do projeto open source Drupal
00:02:34fundou uma empresa que fornecia serviços profissionais, hospedagem e suporte para sites em Drupal.
00:02:38Então eu fazia parte da equipe de operações deles, mas conforme a empresa crescia — e era um crescimento vertiginoso —
00:02:45muitos, muitos clientes grandes cujos nomes você reconheceria, com essa escala veio muito trabalho manual repetitivo. Pronto,
00:02:51agora estamos falando de SRE. Havia muito trabalho manual, muitos incidentes.
00:02:55Começamos a esbarrar na realidade de operar em grande escala versus a arquitetura com a qual
00:03:01originalmente começamos e os processos com os quais começamos. Então eu comecei a ler O Projeto Fênix. Me interessei
00:03:09pela prática de administração de sistemas em nuvem, que foi o primeiro livro sobre SRE.
00:03:12Não era o livro de SRE do Google, SRE ocupava algumas páginas e trazia 12 práticas.
00:03:17E novamente, fiquei muito, muito intrigado e comecei a praticar.
00:03:21E eu na verdade não sei o que é O Projeto Fênix. Ah, meu Deus!
00:03:26Sim, sim. O Projeto Fênix foi como o livro original de DevOps.
00:03:31É um livro muito bom.
00:03:34É uma história sobre
00:03:39o vice-presidente de operações de TI lidando com alguns problemas organizacionais significativos
00:03:45e, através da orientação de um mentor misterioso que mais tarde descobrimos ser membro do conselho da empresa,
00:03:53ele está ensinando sobre
00:03:55conceitos
00:03:56de fabricação industrial à antiga e como isso se aplica diretamente à engenharia de software e operações de TI.
00:04:05Isso introduziu muitos conceitos que ainda uso hoje e sobre os quais converso com clientes hoje, porque é extremamente relevante.
00:04:11Então sim, esse foi o livro original, mas além disso,
00:04:13eu li um monte de coisas, muito no mundo de gestão.
00:04:18Então, além de todo o material técnico que eu lia para aprimorar minhas habilidades como SRE e engenheiro de software,
00:04:24há também a parte de gestão, porque DevOps e SRE são uma prática sociotécnica.
00:04:29Você está fazendo a ponte entre o que a tecnologia pode fazer e como os humanos a utilizam para gerar bons resultados de negócios.
00:04:36E imagino que haja muito erro humano envolvido nisso e na forma de lidar com ele, certo?
00:04:42Sim, com certeza absoluta. Quer dizer, tem um livro sobre erro humano que você provavelmente deveria ler também.
00:04:50Há um senhor... o nome dele me escapa agora, mas ele é
00:04:57tipo um professor em Sydney, na Austrália, e tudo o que ele aborda são acidentes aéreos e como o erro humano...
00:05:05é enorme. É muito útil na cultura de post-mortem: o erro humano não é onde terminamos.
00:05:10Tipo, se você diz: 'Ah, o motivo pelo qual tivemos este incidente de produção foi erro humano',
00:05:16não, isso é o começo da discussão, não o fim. Quais fatores contribuíram para
00:05:21que aquela pessoa, naquele lugar, digitasse o comando errado e destruísse o banco de dados de produção?
00:05:27Tipo, ele deveria ter acesso ao banco de dados de produção? As ferramentas são ergonômicas? Ele dormiu na noite passada?
00:05:34Com que frequência ele foi acionado? Sabe, existem todo tipo de fatores.
00:05:38Então sim, quando as pessoas falam em erro humano, eu imediatamente me identifico com esse livro. Vou ter que te passar um link para as notas do episódio.
00:05:45Sim, acho que me lembro do meu primeiro
00:05:49contato com testes ponta a ponta. Eu estava ouvindo um curso em que alguém contou
00:05:54sobre um incidente em que havia algum tipo de software desenvolvido para
00:05:58cirurgiões, e era preciso clicar nos botões em uma determinada ordem.
00:06:03Mas os cirurgiões se acostumaram tanto a clicar neles que começaram a clicar
00:06:07tão rápido que o software começou a apresentar falhas, e ninguém esperava que isso pudesse acontecer.
00:06:13Então isso é bem interessante.
00:06:15Sim, com certeza a interseção entre humanos e automação é algo a que devemos prestar atenção sempre nos produtos que operamos.
00:06:25Sim.
00:06:26E também fiquei sabendo que você começou
00:06:28com DevOps e SRE na era dobipe, em que você tinha que usar Pagers. É verdade?
00:06:35Sim, na verdade sim. A primeira vez que fiquei de plantão, recebi um
00:06:42pager físico. E olha só, caramba! Que ano foi isso?
00:06:46Foi em 2005.
00:06:48Nossa, legal. Meu primeiro emprego na área de tecnologia... oh, isso é ótimo.
00:06:55Eu trabalhava em uma garagem, como toda startup de sucesso faz, em Plant City, na Flórida.
00:07:02O pai de um bom amigo meu
00:07:04tinha um projeto paralelo onde ele geria um serviço de hospedagem web, de e-mail e um provedor de acesso discado a partir da garagem dele.
00:07:12O nome dele é Curtis Fellaini — tenho enorme respeito por ele — e ele
00:07:18me ensinou tudo o que eu sabia. Mas sim, nós rodávamos essa ferramenta de plantão chamada WhatsUp Gold.
00:07:24E tudo o que ela fazia... o nome eu conheço, e o que ela fazia... ela não fazia verificações de HTTP,
00:07:33ela fazia pings ICMP para os servidores. Era um ping à moda antiga, e se não recebesse uma resposta,
00:07:40ela enviava
00:07:42um alerta. Eu carregava um pager por algum tempo enquanto trabalhava lá.
00:07:48Imediatamente depois, quando trabalhava na minha alma mater com supercomputação (HPC), era o Nagios
00:07:54e, sabe, mensagens de texto para o celular.
00:07:57Isso foi uma escolha deliberada ou, a essa altura, tecnologias mais novas já haviam surgido, como você disse, mensagens SMS e coisas assim?
00:08:07Quer dizer, sim, naquela época havia mais ferramentas,
00:08:11embora limitadas, mas havia mais ferramentas disponíveis para monitorar
00:08:15a infraestrutura na época. E quando eu estava no departamento de HPC na Universidade do Sul da Flórida,
00:08:22já lidávamos com escalas de centenas de servidores, porque é HPC,
00:08:27são racks de servidores executando tarefas de computação. Então precisávamos
00:08:31de algo um pouco mais avançado do que
00:08:34um pager. E o conteúdo do alerta também importava, porque se você recebesse apenas
00:08:40uma mensagem, pensava: 'Ah, ok, preciso ir verificar o que está acontecendo pelo bipe'.
00:08:45Mas com o Nagios você recebia pelo menos algum contexto, como 'este servidor
00:08:50caiu' ou 'este serviço associado a este servidor caiu'. Então, mesmo naquela época,
00:08:56você já tinha certa sofisticação em termos de poder configurar,
00:09:01sabe,
00:09:03o que você queria monitorar por host ou por serviço.
00:09:06Com certeza bem antes de SLOs, nem pensávamos nisso.
00:09:13Estávamos apenas pensando: esta porta está aberta e me dá a resposta que eu espero?
00:09:17Nossa, 2005. Acho que eu estava no ensino fundamental nessa época, nem pensava em ciência
00:09:26da computação
00:09:28naquela época.
00:09:30É, não parece, mas sou mais velho do que aparento. É, eu percebi. Bem, você tem uma ótima aparência. Muito obrigado!
00:09:37Então, pesquisando um pouco, parece que você trabalhou no Meta. O que você fazia?
00:09:43E como era trabalhar no Meta?
00:09:45Nossa! Eu era um engenheiro de produção
00:09:48e um gerente de engenharia de produção, então
00:09:52o que isso basicamente significa é que é a versão deles de SRE. E eu trabalhei em dois projetos: o primeiro, por apenas alguns meses,
00:10:00eu trabalhei em uma equipe chamada Conveyor. Acho que existem até artigos públicos publicados para o IEEE sobre
00:10:06o Conveyor. O Conveyor é provavelmente um dos maiores sistemas de CD do planeta.
00:10:11Então, todos os artefatos de compilação gerados para os serviços de backend no Meta
00:10:18passam pelo Conveyor, e há uma distribuição progressiva de todas as alterações para milhares e milhares e milhares de serviços de backend.
00:10:25Eles são estritamente internos ao Meta?
00:10:29Apenas interno, é.
00:10:31Mas sim, há um artigo do Boris Gubbels que você deveria ler sobre
00:10:37o que eles construíram, e é muito, muito interessante.
00:10:39Então eu estive lá por alguns meses enquanto eles estavam escalando aquilo
00:10:43e ajudando com os alertas, porque no início
00:10:46é como qualquer coisa, você recebe centenas de alertas por semana e eu pensei: “espera,
00:10:49vamos limpar isso e
00:10:51sabe, colocar a observabilidade deles num ponto em que pelo menos soubessem quando as falhas estavam acontecendo”. E eu também
00:10:58criei alguns
00:11:00como você diria, procedimentos de emergência para desativar recursos principais usando a ferramenta de feature flag deles,
00:11:06só para garantir que conseguíssemos nos recuperar rapidamente de incidentes.
00:11:10Então fiz isso por alguns meses, mas a maior parte do meu tempo foi gasta
00:11:13em outra equipe que
00:11:16era um Heroku interno, por assim dizer. Então você tem serviços sem estado muito simples,
00:11:23e sabe, as equipes estão criando isso o tempo todo e você precisa rodar isso em algum lugar, e essa
00:11:29equipe e esse serviço existiam para tornar esse processo simples, porque antigamente subir um serviço era muito difícil. Então eu fui o primeiro
00:11:37engenheiro de produção
00:11:40nessa equipe e foi bem insano. Mas foi isso que eu fiz lá.
00:11:44Foi definitivamente muito divertido. Havia pessoas com quem trabalhei que
00:11:48tinham cérebros cinco vezes
00:11:51maiores que o meu, sabe? As pessoas com quem você trabalha em empresas assim são
00:11:55super brilhantes e eu aprendi muito lá. Eu ia dizer, acho que há uma empresa chamada Honeycomb e
00:12:02a pessoa que a fundou, Charity Majors, estava na Meta?
00:12:06Você a conhece? Chegou a conhecê-la?
00:12:09Sim, eu a conheci. É muito, muito interessante
00:12:12você perguntar isso. Eu a conheci num evento do Observability Days há um ano e meio em Boston. Eu a conheci pessoalmente,
00:12:20sim, ela trabalhou na Meta, e
00:12:22a inspiração para o Honeycomb veio de uma
00:12:26ferramenta de observabilidade em escala planetária chamada Scuba.
00:12:30Exato, então eu usei o Scuba e gostei muito, e fico muito feliz que ela
00:12:37esteja fundando uma empresa para fazer isso. Ela e eu temos conversado no LinkedIn de vez em quando ultimamente
00:12:44por causa do nosso interesse em comum sobre
00:12:47como a programação agêntica vai influenciar a confiabilidade, então
00:12:51temos conversado de vez em quando sobre esse assunto.
00:12:54Mas sim, ela é uma pessoa muito legal e é um privilégio conversar com ela de vez em quando.
00:12:59Sim, sim. Na verdade, isso é um ótimo gancho para o que também queríamos te perguntar. Para onde você acha que a IA
00:13:06vai levar o SRE, o DevOps e todas essas práticas?
00:13:13Nossa, ok. Excelente propaganda, muito obrigado. Vou direto ao ponto aqui.
00:13:19Temos engenheiros de software que receberam
00:13:24uma ferramenta incrível, que é o desenvolvimento agêntico. Todo mundo está conseguindo código gerado magicamente com facilidade de ferramentas como o Claude e afins.
00:13:35Então isso significa que haverá uma quantidade de código de uma ordem de grandeza maior
00:13:39fluindo pelo nosso
00:13:42fluxo de valor, nossos pipelines de CI/CD, nossos testes, revisões, implantação de código, resposta a incidentes, procedimentos de gerenciamento de mudanças, tipo,
00:13:50todo esse código vai passar pelo sistema que cada um de nós construiu para nossas empresas.
00:13:56E isso significa que vamos testar o limite
00:13:58de todas essas capacidades. Então, por exemplo,
00:14:01há uma relação
00:14:04linear
00:14:06entre o número de alterações que você pode fazer em um software e o número de chamados ou de incidentes que você recebe.
00:14:12Isso é um fato estabelecido,
00:14:14então
00:14:15é razoável assumir que se você aumentar o fluxo de código pelo seu pipeline em 10 vezes,
00:14:20você terá 10 vezes mais alertas.
00:14:23Então, como
00:14:26sua organização responderia a isso, né? Essa é realmente a questão. Então, do lado de SRE, eu prevejo
00:14:32que no futuro nós, o pessoal de operações, seremos muito,
00:14:39muito populares, porque seremos onde está o gargalo agora.
00:14:42Não se trata mais de apenas escrever código e colocá-lo em produção. Agora é: como o operamos?
00:14:49Está funcionando? Está atendendo às expectativas do cliente?
00:14:51E
00:14:53então
00:14:55eu prevejo que essa será a principal mudança.
00:14:58É um grande desafio, porque muita coisa pode dar errado durante essa transição.
00:15:04Você pode, como mencionei, ter muito mais incidentes. Como você está aprendendo com as falhas e,
00:15:09sabe, continua fazendo os post-mortems? Está construindo um pipeline de CI/CD que realmente funcione, sabe,
00:15:15e basicamente garanta que o esforço humano seja sempre de alto impacto?
00:15:20Então a parte engraçada é que temos nos preparado para este evento há décadas. É só que, sabe,
00:15:27tendemos a pensar nisso em termos de Big Tech, onde você tem 20.000 engenheiros,
00:15:31mas
00:15:33agora temos organizações menores que conseguem produzir 10 vezes mais código e, portanto, o fluxo é o mesmo.
00:15:38Então, todos esses fundamentos
00:15:40sobre os quais essas empresas maiores têm escrito e falado na última década, agora
00:15:47todos nós vamos precisar realmente colocar em prática.
00:15:49Tipo, todos os fundamentos precisam ser seguidos. E tem isso,
00:15:53mas também há a questão de que
00:15:56as organizações (como as de desenvolvimento de software) se estruturaram em torno da ideia de que, nossa, o que leva mais tempo,
00:16:03o maior ralo de tempo, é codificar.
00:16:05Então precisamos garantir que os engenheiros passem o máximo de tempo possível programando. Se isso não for mais verdade,
00:16:09temos que nos reorganizar em torno daquelas atividades que agora tomam mais tempo.
00:16:15Portanto, haverá uma certa mudança na forma como gerenciamos essas organizações e, finalmente,
00:16:20e acho que você tem visto isso em relação à tendência de IA para SRE,
00:16:23sobre a qual tenho falado com frequência e no meu podcast, de que vamos precisar introduzir com habilidade
00:16:31essa tecnologia nos lugares apropriados, onde possamos extrair muito proveito dela para realizar essas operações, certo?
00:16:37Porque, por exemplo, existem empresas por aí — acho que um bom exemplo é o incident.io —, onde você recebe um alerta
00:16:44e, antes mesmo de você sair da cama,
00:16:47já existe um fluxo de trabalho agêntico que diz: “Ok, que alterações foram feitas na base de código recentemente?”
00:16:53O que os alertas realmente dizem? O que as métricas realmente dizem?
00:16:59e tenta fazer um primeiro diagnóstico, de novo, antes mesmo de você sair da cama e tirar o sono dos olhos.
00:17:04Portanto, existem algumas áreas em nossas responsabilidades operacionais que podem
00:17:09obter muitos benefícios da IA, mas você não deve simplesmente adotar tudo.
00:17:12Tipo, você precisa, precisa pensar em quais são os problemas reais, qual é o retorno sobre o investimento
00:17:16Mas enfim, essa é a minha tese. Na verdade, vou dar um webinar daqui a algumas semanas sobre esse exato assunto
00:17:23Isso é muito interessante porque, hum, o caso de uso que você mencionou antes,
00:17:29de sair da cama e já receber um alerta sobre algo,
00:17:32isso já foi implementado na prática? Porque
00:17:36uma coisa que vejo que pode dar errado é que, digamos que você tenha níveis de triagem onde, na primeira triagem,
00:17:43talvez a IA consiga resolver sozinha. Mas aí, no segundo momento, precisamos de um humano no circuito e, às vezes, o que eu
00:17:51— só para fazer uma comparação com a programação, às vezes vejo o Claude programando e, quando ele está raciocinando, ele diz:
00:17:56“Devo fazer isso” e então ele pensa: “Espera um segundo,
00:17:59não,
00:17:59provavelmente devo apagar tudo isso, recomeçar e fazer assim”.
00:18:02E sinto que a mesma coisa pode acontecer com esses bots de gerenciamento de incidentes. Eles pensam: “Ah, isso é uma correção fácil.
00:18:10Espera, talvez eu consiga resolver sozinho” — situações assim.
00:18:13Não, você está 100% certo.
00:18:15Acho que esta citação da IBM dos anos 1970 tem circulado bastante ultimamente: nunca peça a um computador para tomar
00:18:22uma decisão de gestão. Então, o que quero dizer com isso é que há duas maneiras de usar
00:18:27isso,
00:18:29essas ferramentas de IA ou automação em geral. Existem duas filosofias sobre automação
00:18:32sobre as quais as pessoas têm escrito. A primeira é chamada de princípio residual (leftover principle), onde você basicamente diz: “Ah, ok, vamos ter um software” —
00:18:38não precisa ser IA, podem ser apenas ferramentas — que faz todas essas coisas para nós
00:18:43de forma autônoma, em nosso nome, sem precisarmos pensar nisso.
00:18:46E então a nós, humanos, é deixado o que sobra, que tipicamente são as coisas para resolver as quais você precisa de um PhD.
00:18:51Hm,
00:18:53primeiro que isso
00:18:54não é muito viável, porque aí você gasta todo o seu orçamento contratando doutores,
00:18:57e também está depositando confiança demais em um sistema que roda autonomamente, e se ele tomar a decisão errada, você está em apuros.
00:19:04A mais
00:19:07filosofia mais viável é o chamado princípio compensatório, em que você multiplica a força do esforço humano
00:19:15Você permite que os computadores e a automação façam aquilo que fazem bem, e permite que os humanos façam o que
00:19:22os humanos fazem bem,
00:19:25que é:
00:19:26Nós entendemos o contexto dos nossos sistemas. Entendemos o problema que estamos tentando resolver e a experiência do cliente.
00:19:33Há muito contexto em nossas mentes que torna
00:19:38muito mais vantajoso usarmos isso do que deixar a IA fazer tudo. Então, para responder à sua pergunta de forma mais direta,
00:19:44acho que essa reformulação com IA realmente não deveria
00:19:50fazer alterações em produção, a menos que seja em um caminho bem restrito e bem definido.
00:19:58Vou te dar um exemplo: reversões automáticas de código. Fazemos isso de forma automática sem IA, se você pensar no Kubernetes,
00:20:06certo? Se você tem um deployment e está mudando a versão da sua nova imagem de container e os seus
00:20:13testes de prontidão não têm sucesso, adivinha?
00:20:16A alteração não vai ser aplicada.
00:20:19Certo. Então esses mecanismos são muito simples, fáceis de entender e nos permitem realizar alterações com segurança.
00:20:26Sabe, esses tipos de problemas bem definidos, acho que você pode deixar para a automação fazer, e a automação já faz.
00:20:32Mas ter
00:20:35a IA agora dizendo “sim, devemos fazer essa alteração na nossa infraestrutura” sem a intervenção humana,
00:20:41acho irresponsável. Acho que nós, humanos, voltando ao ponto sobre restrições, acho que
00:20:46nosso tempo vai ser direcionado para:
00:20:49“Esta é realmente a decisão certa a tomar?”
00:20:52Sabe, dar essas aprovações, revisão de código e revisão de qualquer alteração na infraestrutura,
00:20:59acho que será onde
00:21:00vamos gastar muito do nosso esforço.
00:21:03E sim, vamos querer automatizar isso onde for possível, mas isso exige disciplina e um histórico de segurança.
00:21:09Sim, e outra pergunta com base no que você disse antes é sobre essa comparação linear de que quanto mais código você tem,
00:21:19mais incidentes você vai ter. Então, você tem trabalhado como consultor
00:21:22nesta área. Você tem ouvido que as empresas estão passando por isso agora, tipo,
00:21:28já que estão
00:21:30gerando
00:21:31ou delegando mais código para a IA, elas estão tendo mais incidentes como resultado?
00:21:36Com certeza, com certeza absoluta.
00:21:39Com certeza, e eu acrescentaria a isso dizendo que existem outros modos de falha que estão começando a surgir devido
00:21:47a
00:21:49essa mudança. Acho que um exemplo bem fácil de pensar e raciocinar
00:21:53é
00:21:54os seus pipelines de CI/CD ficando sobrecarregados; a latência entre ter um artefato construído e ele ir para produção está demorando cada vez mais
00:22:00porque há simplesmente mais alterações passando por eles. Então, sim, as organizações estão começando a
00:22:05sentir essas dores já. Quer dizer, só para dar um exemplo rápido de estudo de caso, eu tenho um
00:22:12cliente para quem fiz uma avaliação recentemente, porque parte do meu trabalho é analisar
00:22:17a postura operacional de toda a empresa, como eles entregam código, como o executam, e dar orientações sobre o que fazer a seguir.
00:22:24Então, uma das equipes pensou: “Sim, essa parada de IA é muito boa, vamos começar a produzir algumas funcionalidades”.
00:22:31E eles fizeram, mas
00:22:33eles não mudaram a forma como fazem os lançamentos, não tinham um bom e sólido processo de revisão de código
00:22:38e, por isso, o número de incidentes disparou imediatamente. Então,
00:22:43em vez de focarem no código e entregarem tudo o que achavam que iam fazer, eles ficaram soterrados por reclamações de clientes
00:22:49e incidentes.
00:22:51Então, tipo, sim, isso não é teórico, está acontecendo agora.
00:22:55Essa ordem de grandeza maior de alterações em produção vai
00:23:01revelar
00:23:03todos os elos fracos na sua postura operacional.
00:23:06E quando você é como um
00:23:09médico de SRE que tem um cliente com esse problema, qual é a sua sugestão sobre o que fazer neste caso,
00:23:16como você acabou de mencionar?
00:23:18Pois é. Eu mencionei isso antes: todos aqueles fundamentos de que falamos
00:23:24ao longo da última década ou duas, nós temos que focar neles.
00:23:27Tipo, as equipes
00:23:29precisam, por exemplo, ter uma estratégia de testes válida.
00:23:35Elas precisam saber que o código que estão se preparando para enviar para produção é de alta qualidade.
00:23:39Todas as coisas que aprenderam no passado... Eu sou um grande defensor de objetivos de nível de serviço,
00:23:43sou um grande defensor de SLOs,
00:23:47porque isso nos permite entender a saúde do nosso sistema de produção do ponto de vista do cliente.
00:23:52Então isso
00:23:54é uma grande peça do quebra-cabeça, pois permite regular, de forma orientada a dados, a quantidade de alterações
00:23:59que você está fazendo em produção em termos de solicitações de recursos e coisas assim. Assim,
00:24:03Você não está arriscando sua fonte de receita atual
00:24:07Enquanto busca novas fontes dela
00:24:10Esse é o motivo de negócios para querer SLOs. Uma coisa que notei com os SLOs na empresa anterior em que trabalhei
00:24:16eles diziam algo como
00:24:19Cada equipe deve, sabe, manter suas metas de SLO e, para algumas equipes, como estávamos avançando muito rápido
00:24:25Não estábamos atingindo essas metas
00:24:28E aí muitas equipes ficavam para trás
00:24:30E a decisão da gestão era: tanto faz, é mais importante lançar funcionalidades do que manter as metas de SLO
00:24:36É
00:24:37E essa é provavelmente a maior razão pela qual o SLO não tem sido tão eficaz quanto o Google prometeu há dez anos
00:24:44Porque o fato é — e já falei sobre isso em conteúdos anteriores — você pode ter um programa de SLO
00:24:49Você pode passar pelo processo de colocar engenheiros em uma sala para pensar: qual é a jornada do usuário?
00:24:55Vamos quantificá-la, implementar observabilidade
00:24:57e configurar o Prometheus ou OpenTelemetry e criar painéis bem bonitos, mas
00:25:01Se o gerente de produto
00:25:05Se a organização de produtos não estiver disposta a colaborar
00:25:07Se a equipe executiva não estiver disposta a colaborar
00:25:09então
00:25:12É desperdício
00:25:14Aí você só tem SREs e talvez os engenheiros trabalhando isolados dizendo: ei, as coisas não estão bem
00:25:19e, sabe
00:25:21A liderança quer continuar lançando. Para que o SLO seja bem-sucedido
00:25:26Ele precisa ser um jogo jogado por todos. E quando avalio
00:25:32a postura de SLO das organizações — o que é algo que faço muito —, costumo fazer essa pergunta: se um orçamento de erro é gasto
00:25:38O que o gerente de produto faz?
00:25:41Se o gerente de produto responde: ok, na próxima sprint vamos mudar o escopo da próxima sprint
00:25:46Ótimo
00:25:48Você está com maturidade média. Se ele não faz isso
00:25:50Sua maturidade é baixa. Na verdade, desenvolvi um modelo de maturidade de SLO de um a cinco — um sendo imaturo e cinco otimizando — para ajudar
00:25:58As empresas a entenderem em que ponto da jornada estão, mas você tem razão, muitas organizações não fazem isso
00:26:03Elas não adotam SLOs de verdade. Elas têm um painel, têm métricas, os engenheiros ganham bônus por isso
00:26:08mas
00:26:10As decisões de negócios não são tomadas usando o SLO
00:26:12É só geração de alertas
00:26:16E os tipos de clientes que você atende, que procuram você, em que
00:26:21situação eles estão para que
00:26:24Necessitem da sua assistência? Estão em uma situação boa, ruim, ou intermediária?
00:26:28Depende. Costumo trabalhar com clientes em dois pontos de inflexão. O primeiro ponto de inflexão é tipo
00:26:37A empresa em estágio inicial que acabou de receber uma rodada de financiamento, a equipe de vendas está arrasando, encontraram o product-market fit
00:26:44Mas são inexperientes e nunca lidaram com infraestrutura de nível empresarial antes
00:26:49Nunca venderam para clientes corporativos e estão começando a ceder
00:26:53Sob a pressão desse aumento de escala, o que é muito parecido com a experiência que tive no início da minha carreira
00:26:59É algo que conheço muito bem porque vivi isso. Esse é o primeiro ponto de inflexão
00:27:04E é um ponto de inflexão divertido. É um bom problema para se ter, embora possa ser estressante para quem trabalha lá
00:27:09O segundo ponto de inflexão
00:27:12Geralmente ocorre quando você é uma organização maior e precisa começar a padronizar
00:27:17Como você opera em várias equipes?
00:27:21Talvez você tenha um programa de SRE e precise avaliar a eficácia dele, se os processos estão funcionando
00:27:28Se o modelo de engajamento está funcionando, se as equipes de engenharia e produto estão realmente participando do processo
00:27:34Então, empresas que fazem muitas aquisições
00:27:37Normalmente me procuram porque estão tentando domar essa fera, pois a cada nova aquisição
00:27:44Há uma pilha tecnológica totalmente nova para integrar, então há muita governança de alto nível a se considerar
00:27:50Para garantir que todos estejam jogando pelas mesmas regras
00:27:55Com certeza
00:27:57E eu acho que com as empresas menores, como você mencionou, aquelas que captaram recursos
00:28:02Com a inteligência artificial por aí e as pessoas usando IA para criar funcionalidades
00:28:06Essa falta de estrutura vai aumentar, porque as pessoas simplesmente criam recursos e os lançam usando IA
00:28:13Sem pensar em logs, métricas, rastreamentos ou qualquer coisa do tipo
00:28:16Quais são as coisas mais marcantes que você nota nas empresas menores que chegam até você com problemas que
00:28:23São óbvios para você, mas que elas não enxergavam como um problema?
00:28:27Sim, acho que já mencionei isso em uma resposta anterior, mas vou formular de cima para baixo
00:28:34então,
00:28:36o que eu vejo claramente é um ciclo de feedback interrompido entre o que está acontecendo em produção
00:28:41e o que está acontecendo na experiência do cliente, e depois no que diz respeito à priorização de produtos.
00:28:46E eu vejo isso há muito tempo em várias equipes, muitas equipes. Provavelmente é o problema mais comum.
00:28:55Então, quando trabalho como consultor,
00:28:58uma das coisas em que penso nos bastidores é como garantir que esse ciclo de feedback seja estabelecido.
00:29:03É incrível
00:29:05quantas empresas passam por um incidente,
00:29:08os clientes ficam chateados,
00:29:10abrem chamados no suporte e o suporte fica inundado
00:29:13de chamados. O suporte tem esse dom incrível para dar à organização de engenharia de produto, que se chama feedback. Eles sabem
00:29:23o que está irritando o cliente, o que o impede de aproveitar o serviço e o que potencialmente o está motivando a sair.
00:29:30E eu tenho visto repetidas vezes
00:29:33esse feedback ser completamente ignorado ou colocado em uma prioridade menor do que o trabalho de novas funcionalidades,
00:29:41e o resultado final é
00:29:44vapor total em funcionalidades, mesmo com o produto pegando fogo, e para mim
00:29:51isso é algo que percebo imediatamente quando entrevisto e avalio equipes.
00:29:55Mas geralmente, quando você trabalha dentro da empresa, você não vê isso porque pensa: sou engenheiro de software,
00:29:59sou incentivado a entregar funcionalidades. Entreguei 50 recursos no último trimestre, ótimo, vou receber meu bônus.
00:30:05Os gerentes de produto pensam a mesma coisa:
00:30:07sim, lançamos esses projetos, este cliente assinou conosco porque fizemos isso. Enquanto isso,
00:30:11os clientes atuais estão furiosos, não estão felizes com o que está acontecendo.
00:30:16Portanto, ciclo de feedback quebrado
00:30:19e isso se deve à cultura em São Francisco ou apenas porque
00:30:22as pessoas só querem parecer melhores que seus concorrentes? Não sei. Por que você acha que isso acontece?
00:30:28Não acho que seja inerente a São Francisco. Acho que é inerente aos negócios em geral, às estruturas de incentivos,
00:30:36às culturas empresariais, porque
00:30:39quando
00:30:41você
00:30:42tem diferentes departamentos,
00:30:44à medida que a empresa cresce e isso acontece naturalmente porque você precisa organizar os esforços,
00:30:49você começa a isolar em silos.
00:30:51Tenho engenheiros de software aqui, gerentes de produto ali. Talvez eles estejam integrados
00:30:55às equipes de engenharia, mas têm seu próprio conjunto de incentivos. O suporte e o pessoal de DevOps e SRE
00:31:01têm seus próprios incentivos, mas são todos separados e conflitantes,
00:31:06certo? E
00:31:09tipicamente,
00:31:11nesta fase do jogo, ninguém sentou com eles para dizer:
00:31:13como mudamos nossa estrutura de incentivos para que
00:31:18todos estejamos caminhando na mesma direção? Uma das coisas que a Meta fez
00:31:21e de que eu realmente gostei, e acho que funciona muito bem,
00:31:25é que ao avaliar o desempenho de um engenheiro, pelo menos nas equipes com as quais trabalhei,
00:31:31eles não olhavam apenas para funcionalidades,
00:31:34mas também para excelência operacional, excelência em produção, e avaliavam: em quais incidentes eles participaram?
00:31:41Em que trabalho de confiabilidade trabalharam? Em que trabalho de escalabilidade trabalharam?
00:31:45Como tornaram o sistema mais confiável e operável? E isso contava para saber se receberiam o bônus
00:31:51ou se seriam promovidos. Era uma parte importante
00:31:54dos critérios.
00:31:57Então,
00:31:58quando eles realmente começaram a focar nisso, significou que os incentivos para os engenheiros de software mudaram. Na equipe em que eu estava,
00:32:05onde estávamos realmente
00:32:07impulsionando isso junto com os líderes de engenharia com quem eu trabalhava,
00:32:12esses engenheiros magicamente começaram a vir até mim e dizer: ei, gostaria de participar de um trabalho de confiabilidade com você.
00:32:18Posso assumir este processo de teste de carga?
00:32:20Claro. Com certeza. Aqui estão os manuais de procedimentos, aqui estão alguns scripts, vá em frente,
00:32:25e é incrível o que acontece quando os incentivos mudam.
00:32:29Portanto,
00:32:31acho que essa é uma progressão natural para qualquer organização: se você é uma startup minúscula onde todo mundo é dono de tudo,
00:32:38está tentando conseguir financiamento e conquistar aqueles clientes iniciais e mantê-los felizes,
00:32:43acho que os incentivos já estão alinhados,
00:32:45caso contrário a empresa não sobreviveria. Mas à medida que você cresce e tem essa separação de responsabilidades,
00:32:51fica cada vez mais difícil manter uma estrutura de incentivos alinhada em toda a organização.
00:32:55Então sim, é aqui que as questões sociotécnicas começam a surgir quando falamos de SRE e DevOps.
00:33:00Legal. E você também mencionou que, com essa aceleração total em IA,
00:33:06as pessoas precisarão de mais profissionais como você trabalhando nessa área, e por outro lado,
00:33:12ouvimos dizer que a engenharia de software está morrendo, que não há mais vagas, certo?
00:33:17Então, você acha que para os desenvolvedores júnior que estão ouvindo este podcast,
00:33:23SRE e DevOps são uma boa área para entrar neste momento específico? Sim e sim. Então,
00:33:30eu vou contestar isso e não serei a pessoa a dizer que a engenharia de software está morta.
00:33:36Na verdade, eu acho que os fundamentos
00:33:38são ainda mais
00:33:41importantes.
00:33:43Compreender as linguagens de programação e como elas funcionam, os algoritmos e como eles funcionam, é ainda mais importante,
00:33:50porque
00:33:53como devemos revisar o código gerado por uma IA?
00:33:56E como devemos projetar sistemas que funcionem? Porque se você simplesmente der a um modelo LLM: ei, projete esta arquitetura,
00:34:04Você tem certeza de que vai funcionar? Tipo, vou colocar dessa forma: abra um projeto no Claude Code
00:34:08e peça para ele projetar uma ponte
00:34:11ou um arranha-céu,
00:34:15e então eu quero que você pegue esse projeto, vá construí-lo
00:34:18e depois se sente dentro dele. Você ficaria confortável fazendo isso?
00:34:22Você ficaria confortável dirigindo sobre a ponte que ele projetou?
00:34:25Exatamente. Até que você pare de balançar a cabeça, precisamos desses engenheiros lá.
00:34:31Certo, e quanto ao pessoal de SRE e DevOps? Sim, obviamente
00:34:34precisa haver mais de nós, porque é para lá que o gargalo está indo. Se estamos fazendo tantas mudanças no sistema,
00:34:39definitivamente precisamos garantir que ele esteja saudável, que compreendamos as implicações das mudanças na produção,
00:34:43que tenhamos um pipeline de CI/CD, um fluxo de valor que, extrapolando para o nível superior,
00:34:51seja saudável, monitorado e tratado como um serviço de produção. Na minha visão, todas essas habilidades se tornarão ainda mais importantes.
00:34:58A forma como costumo ver isso é um pouco como a corrida de F1: você tem uma equipe de pit stop,
00:35:04e essa equipe de pit stop sabe tudo sobre aquele veículo, pode trocar qualquer peça e dá ao piloto a capacidade de dominar aquela pista de corrida.
00:35:12Você precisa dessas pessoas,
00:35:15porque isso dá aos gerentes de produto e arquitetos o ambiente necessário para
00:35:22iterar rapidamente e lançar essas mudanças sem que esses gargalos aconteçam.
00:35:27Então, na minha visão,
00:35:29tipo,
00:35:30é um ótimo momento para ser um SRE. Sinto que alguns anos atrás era diferente, porque todo mundo estava sendo demitido,
00:35:35mas acho que
00:35:37se você realmente focar nos fundamentos, se entender
00:35:39Linux e sistemas, bem como a parte sociotécnica, basicamente o que significa ser um SRE,
00:35:46acho que você pode ir
00:35:49muito longe
00:35:51nesta carreira. Mas precisamos estar informados sobre o advento do desenvolvimento agêntico,
00:35:57não podemos enfiar a cabeça na areia em relação a isso.
00:35:59Você mencionou
00:36:02The Phoenix Project? Sim, o livro.
00:36:05Então, quais outros recursos você acha valiosos para alguém que quer mergulhar fundo neste assunto?
00:36:12Nossa, quero dizer, há vários. Deixe-me listar os livros de peso.
00:36:18O DevOps Handbook é bom. Senti que, quando esse livro foi lançado,
00:36:21ele era um ótimo resumo de tudo o que aprendi antes de o livro sair. É um ótimo
00:36:27lugar completo para consulta. Leading Change, de John Kotter,
00:36:30fala sobre liderança em mudanças transformacionais nas organizações.
00:36:34Ele fornece uma estrutura e, quando você é um SRE em uma equipe ou tenta impulsionar uma transformação de confiabilidade,
00:36:41é algo bom de se conhecer. O livro Toyota Kata,
00:36:45que fala sobre como a Toyota promove a melhoria contínua na fabricação de veículos,
00:36:52é muito útil. Um dos primeiros a criar o sistema. Sim, acho que já ouvi falar. É,
00:36:59kaizen
00:37:02era o conceito da Toyota.
00:37:04O milagre econômico japonês foi o que criou o Agile
00:37:07e o DevOps, foi o precursor disso. Outro livro: The Practice of System and Network Administration,
00:37:13mencionei, acho que eles devem ter uma nova edição, muito útil.
00:37:17Sim, os livros de SRE que o Google produz são bons, mas faço uma ressalva:
00:37:22São livros que foram escritos por pessoas que trabalham em empresas absolutamente gigantescas
00:37:27e que têm orçamento infinito,
00:37:30então as práticas e as formas como eles lidam com as coisas vão ser diferentes da forma como você lida com as coisas na sua
00:37:35startup de quatro pessoas, mas acho que
00:37:37juntar todas essas peças vai dar a você uma compreensão a partir de um engenheiro,
00:37:44a partir
00:37:44de um líder
00:37:46e de um estrategista sobre como impulsionar iniciativas de DevOps e SRE.
00:37:49Então acho que tenho uma perspectiva única, porque penso nisso de forma holística. Não estou apenas me aprofundando
00:37:55em tudo o que faço é Kubernetes e faço o Kubernetes funcionar. Estou tentando fazer as equipes funcionarem
00:37:59e, depois disso, descobrimos os problemas técnicos e os resolvemos.
00:38:03E para todos os ouvintes, deixaremos os links dos livros mencionados nas notas do episódio.
00:38:09Hum, eu ia perguntar, voltando à IA, concordo com você que as pessoas devem aprender os fundamentos e que
00:38:16a engenharia de software ou o desenvolvimento não vão a lugar nenhum, mas há uma espécie de tendência
00:38:21em que vejo cada vez mais pessoas enviando código para produção sem revisá-lo,
00:38:26e tenho certeza de que são pessoas no Twitter ou no X, ou apenas
00:38:30pessoas se exibindo, não é realmente verdade.
00:38:32Mas, mas há alguns líderes de pensamento, como pessoas que comandam empresas de IA, como Dario, o Musk, dizendo: ei,
00:38:39tipo, no ano que vem, 2027, sei lá,
00:38:41você poderá escrever código e publicá-lo sem olhar para ele, ou poderá escrever código,
00:38:47tipo, código compilado sem escrever na linguagem de programação, para compilar esse código, e assim as linguagens vão morrer. O que você acha disso?
00:38:54Eu duvido seriamente que esses líderes de pensamento estejam de plantão,
00:38:58porque se estivessem, estariam dizendo algo completamente diferente.
00:39:02Não faz sentido.
00:39:04Eles não estão, não estão na infra, não são do grupo de segurança da informação
00:39:08reclamando sobre
00:39:09vulnerabilidades sendo introduzidas, e não estão lidando com o que acontece quando os clientes ficam chateados. Tipo,
00:39:13claro, LLMs podem produzir
00:39:16código sintaticamente correto,
00:39:21um tanto lógico.
00:39:23Eles acertam uns 20, 30%?
00:39:25Talvez.
00:39:29Mas mesmo assim,
00:39:31você ainda vai precisar de monitoramento e observabilidade adequados,
00:39:37sabe, testes em produção. Ok, se você quer testes em produção, como defende a Charity,
00:39:42há algum
00:39:45investimento pré-requisito que você tem que fazer, e na visão dela
00:39:48será a observabilidade, entendendo o comportamento do seu software. Mas mesmo assim, se eu,
00:39:54sabe,
00:39:56fosse um governo e precisasse comprar software,
00:39:59ele tem que atender aos meus controles de segurança.
00:40:03Se eu fosse uma empresa médica e você estivesse escrevendo um software que é literalmente responsável por manter pacientes vivos,
00:40:09você realmente acha que quer que um LLM gere isso sem revisão? Isso seria inaceitável.
00:40:15Isso nos leva de volta ao exemplo da ponte ou do arranha-céu. Você realmente quer que um LLM projete uma ponte ou um arranha-céu
00:40:21e simplesmente o envie, despeje a argamassa e o vergalhão e vamos lá? Não.
00:40:27Não, de jeito nenhum.
00:40:31Sim, essa analogia da ponte e do arranha-céu é uma excelente forma de ver as coisas, nunca tinha pensado nisso.
00:40:37Sabe, se você fosse um engenheiro
00:40:39do zero ao herói, você gostaria de caminhar sobre a sua própria ponte que acabou de construir?
00:40:43Sim, e aqui está a coisa em que temos que pensar: então eu estava mencionando o Curtis,
00:40:49eu adoro aquele cara, no início deste episódio.
00:40:52Ele era um PE,
00:40:56um engenheiro profissional em engenharia elétrica, o que significava que ele foi para a faculdade,
00:41:02fez o exame de PE, estagiou em uma empresa por vários anos e, eventualmente, após fazer uma prova difícil,
00:41:09só aí e somente aí ele pôde realizar projetos de engenharia. Há um alto nível de disciplina
00:41:18em como
00:41:21você faz as coisas. Quer dizer, é a mesma coisa com os médicos,
00:41:23você aprende a parte acadêmica, mas depois fica na prática por anos sob supervisão antes de poder realmente exercer a medicina.
00:41:30E há uma razão para isso. É porque
00:41:33as decisões que tomamos têm ramificações massivas nas vidas dos seres humanos, no meio ambiente
00:41:40e no mundo. E o software ainda não
00:41:44alcançou esse patamar
00:41:47ainda, e não estou necessariamente dizendo que precisamos emular esses modelos, mas
00:41:52precisamos pelo menos
00:41:54reconhecer os riscos que estamos introduzindo, precisamos ter a disciplina de, quando estamos construindo coisas que afetam vidas humanas,
00:42:01ter essa disciplina. Precisamos pensar nos riscos, precisamos pensar nos resultados adversos,
00:42:05precisamos assumir a responsabilidade e acho que
00:42:08há muitas organizações que não querem ouvir isso porque isso freia a capacidade delas de progredir,
00:42:14mas
00:42:16por que estamos escrevendo software? Estamos resolvendo problemas para as pessoas, não deveríamos estar introduzindo novos.
00:42:23Sim, e é um ponto muito interessante o que você disse sobre seu amigo, desculpe, esqueci o nome dele, o PE, engenheiro profissional Curtis, porque o Curtis...
00:42:31Sim, porque aqui no Canadá
00:42:33houve uma discussão sobre o fato de que, para ser chamado de engenheiro, você realmente precisa de uma certificação profissional
00:42:40e, então, houve o debate de que os engenheiros de software não deveriam ter o título de engenheiro porque não conquistaram essa certificação.
00:42:48Sim.
00:42:51Sim, isso faz todo o sentido, faz todo o sentido.
00:42:53Sim, o nível de disciplina é completamente diferente entre a nossa indústria e a deles.
00:42:57Sim, exatamente. Hum, eu queria abordar algo que você escreveu no seu
00:43:03perfil do LinkedIn, você mencionou: de esgotamento e gargalos a equipes e sistemas confiáveis e ágeis.
00:43:12Então, qual é a sua experiência com o esgotamento profissional?
00:43:16Oh, meu Deus. Eu tenho muita experiência com esgotamento.
00:43:21Sabe, como profissional de operações em organizações de rápido crescimento,
00:43:26existem
00:43:28definitivamente pessoas que têm complexos de herói, pessoas que querem se provar, pessoas que têm
00:43:35aquelas pequenas coisas na psicologia em que sentem que precisam
00:43:39intervir e assumir as coisas por conta própria. É uma vulnerabilidade, certo? Síndrome do impostor,
00:43:45todas essas tendências que todos nós temos como pessoas, o desejo de agradar aos outros, todas essas coisas podem contribuir para o esgotamento, em que você
00:43:52estão tão motivadas a provar aos outros que estão fazendo um bom trabalho que não escutam o próprio corpo,
00:43:59não está ouvindo
00:44:02as suas emoções, o seu estado emocional. Você não está sendo introspectivo. Você não está dando a si mesmo tempo e espaço para descansar.
00:44:08Sua relação com o descanso é disfuncional, tipo, houve um período de tempo em que eu achava que o descanso era ruim,
00:44:14que a ociosidade
00:44:16era desperdício, quando, sabe, em
00:44:20nesta fase da minha vida agora, em que penso muito sobre essas coisas, não, o descanso
00:44:25dá a você a capacidade de fazer os grandes esforços mais tarde.
00:44:29Sabe, as pessoas que praticam fisiculturismo não estão na academia todos os dias
00:44:35trabalhando cada grupo muscular, elas dão a si mesmas tempo
00:44:40para reconstruir as fibras dos músculos.
00:44:45Então, por que nós
00:44:47achamos
00:44:49que não podemos fazer isso quando se trata de nossas mentes?
00:44:51Então esse é o tema, mas eu me lembro
00:44:55que, depois de sair da Meta, eu fui tipo o paciente zero na onda gigantesca de demissões,
00:45:01então fui afetado pelas demissões. Foi, desculpe por isso.
00:45:04Ah, não, quero dizer, a Moto não existiria se não fosse por isso. Ok, legal,
00:45:08das cinzas uma fênix, né? Tipo, essa foi a minha resposta a isso,
00:45:13mas aquele período em que estou abrindo meu próprio negócio
00:45:18e dando um passo para trás na indústria e pensando em como quero trabalhar, realmente me fez
00:45:23ficar muito ciente do esgotamento que eu estava carregando comigo e não estava reconhecendo e,
00:45:32sabe, eu me lembro no início da minha carreira de ser o administrador de sistemas rabugento, e se houver pessoas
00:45:38da Acquia ou ex-funcionários da Acquia ouvindo isso, vocês sabem do que estou falando.
00:45:42Eu costumava ser bem rabugento
00:45:44e, tipo, hoje sou muito jovial porque trabalhei um pouco em mim mesmo, mas
00:45:49isso era esgotamento e eu não reconhecia.
00:45:51Eu só achava que muitas pessoas vinham até mim com solicitações
00:45:56quando deveriam estar fazendo isso sozinhas, tipo, leia a página do manual, sabe do que estou falando?
00:45:59Lidei com muito esgotamento e acho que minha empresa e a forma como a conduzo me dão o espaço
00:46:04para
00:46:07enfrentar
00:46:08esses desafios de frente e interagir com o trabalho de uma forma mais saudável
00:46:13e que se alinhe melhor com a forma como meu cérebro funciona, o que eu quero na minha vida e garantir que
00:46:20Sabe, eu não estou
00:46:23vivendo para trabalhar. Estou trabalhando
00:46:25para ter experiências que me preencham. Sabe o que digo?
00:46:28O que você acha disso? Eu sei, acabei divagando um pouco,
00:46:31mas eu ia dizer que com o administrador de sistemas
00:46:34resmungão, consigo me identificar, não por mim mesmo, mas em empresas onde trabalhei, sempre há um cara que
00:46:40sabe subir o Kubernetes ou entende tudo de AWS, e se você quer algo dele,
00:46:44ele fica relutante, mas vai lá e faz, embora não queira fazer. Então me identifico com isso,
00:46:49mas sim, entendo por que isso acontece e de onde vem, puramente pelo fato de ocorrer com frequência e,
00:46:56portanto, compreendo a frustração.
00:46:59E é isso, acho bom dar uma pausa nisso e, hum, você precisa trabalhar em si mesmo e tentar outras coisas,
00:47:05com certeza. Há uma responsabilidade pessoal nisso, mas também é preciso estar muito atento à cultura
00:47:11dos ambientes em que você trabalha, às equipes das quais faz parte, às pessoas com quem interage
00:47:15e garantir que você escolha lugares que sejam melhores para você. Eu sei, o mercado de trabalho ainda está um pouco estranho,
00:47:21pode ser difícil fazer
00:47:22esse tipo de escolha e conseguir dizer que simplesmente vai para outro lugar.
00:47:26Isso pode ser bem difícil de afirmar, eu reconheço isso também, mas pelo menos ter consciência
00:47:30de onde você está, ouvir suas emoções, escutar seu corpo e fazer algo a respeito
00:47:36acho que é uma grande peça do quebra-cabeça. Tem uma
00:47:39médica, a doutora Maslach, ela criou algo chamado inventário de Burnout.
00:47:44Ela originalmente o projetou para o pessoal médico porque ela era da área da saúde,
00:47:49mas o inventário de Burnout e a pesquisa dela são extremamente aplicáveis à tecnologia.
00:47:56E você pode até, tipo,
00:47:58assistir a algumas palestras dela. Acho que ela fez
00:48:01palestras para o evento anual de DevOps que o autor de O Projeto Fênix
00:48:06organizava.
00:48:08Então,
00:48:09sim, eu li um pouco sobre o aspecto clínico do Burnout, além de ter vivido isso pessoalmente.
00:48:15Sim, e estou super feliz que essa demissão tenha virado algo bom para você, abrindo caminho
00:48:24para você fundar sua própria empresa. E acho muito interessante que, pelo que vejo nas suas postagens,
00:48:31você toca essa empresa
00:48:33basicamente na estrada, certo? Você está
00:48:35mudando o tempo todo. Basicamente leva um estilo de vida nômade. É isso mesmo? Exato.
00:48:42Eu vivo como nômade. Estou literalmente nesta ligação usando Starlink no meio do deserto em Nevada agora,
00:48:50eu converti minha picape Tacoma...
00:48:54Eu a chamo de Molly. Converti minha picape em uma
00:48:59estação de batalha móvel. Estou em pé
00:49:02na caçamba da picape,
00:49:04hum,
00:49:05e tenho um alojamento confortável, 300 watts de energia solar,
00:49:09uma geladeira, sabe, um sistema elétrico que eu mesmo construí. Então fiz desta picape
00:49:16uma minicasa e trabalho de todo lugar, desde a minha propriedade aqui em Nevada até
00:49:23o estacionamento de um cinema AMC em algum lugar em Boston. Eu trabalho de qualquer lugar, o que é muito divertido.
00:49:29Faço esse tipo de coisa
00:49:31há dois anos e meio. Comecei a Chirtomoto há três anos,
00:49:34vivo como nômade há dois anos e meio e tem sido a melhor experiência e aventura da minha vida, tipo,
00:49:41sabe,
00:49:43trabalhando nas montanhas. Um urso já subiu na minha picape uma vez.
00:49:46Ah, nossa!
00:49:48É, como foi isso?
00:49:51Foi um pouco assustador. Naqueles dias, eu estava em uma barraca de teto,
00:49:54não nessa minha camper legal de agora. Era um urso preto ou um urso pardo?
00:49:58Bem, eu estou vivo, logo era um urso preto. Ah, legal.
00:50:02Era o maior urso preto que já vi, era gigantão.
00:50:06Estava procurando cestas de piquenique ou algo assim,
00:50:08mas
00:50:09ele subiu na caçamba onde eu estava dormindo em cima, no suporte de cama com a barraca de teto, e o peso mudou.
00:50:17Tive que pegar as chaves no bolso, apertar o botão do alarme e pronto.
00:50:21Fiz isso e o urso fugiu quando o alarme disparou.
00:50:24Sim, depois disso entendi a necessidade de construir algo fechado, como isto aqui. Pelo menos o urso não me vê
00:50:30nem consegue entrar, então...
00:50:33Você mencionou Nevada e Boston, então faz uma viagem transcontinental com sua picape todo ano? Sim, todo ano.
00:50:42Na verdade, pretendo voltar para o Nordeste daqui a um mês. Agora tenho um trailer de carga de 1,80m por 3m que estou convertendo.
00:50:48Logo depois desta ligação, vou furar paredes, instalar janelas, exaustores
00:50:52e mil watts de energia solar, fazendo tudo do bom e do melhor. Vai ser o meu
00:50:58QG móvel e escritório onde posso trabalhar durante o clima inclemente.
00:51:02Muito legal. E para alguns engenheiros ou pessoas que também se interessam por isso,
00:51:08qual é o preço para construir uma minicasa móvel como a que você fez?
00:51:13Quer dizer, o trailer de carga é bem econômico, você consegue comprar um por uns quatro a cinco mil e depois,
00:51:20dependendo do que precisar fazer, o preço pode subir, mas é preciso isolá-lo termicamente,
00:51:24obviamente, colocar ventilação e eletrificação.
00:51:27Há todo um universo de pessoas por aí que fazem esse tipo de coisa.
00:51:31Hum, eu sou apenas um dos poucos que combinou vida nômade com tecnologia e fez dar certo.
00:51:36Mas a picape, sabe, é uma Tacoma com uma camper personalizada em cima de uma empresa chamada Go Fast.
00:51:41Comprei esta usada, mas, hum...
00:51:44Sim, depende muito das suas necessidades. Quer dizer, vejo gente curtindo a vida até em um Prius,
00:51:51sabe? E também vejo pessoas em veículos mais sofisticados, mas
00:51:55o custo inicial pode ser baixo se você entender um pouco de carros e estiver disposto a
00:52:01trabalhar e colocar a mão na massa.
00:52:04Então, o que inspirou você a iniciar esse empreendimento de
00:52:07acampar, viajar e
00:52:10equipar seu carro?
00:52:11Sim, bem, eu só havia morado em dois lugares antes
00:52:14dessa jornada, passava a vida inteira trabalhando e basicamente fazendo o que as pessoas me diziam para fazer,
00:52:21o que se espera de um jovem, sabe: ir para a faculdade, obter um diploma, conseguir um bom emprego
00:52:26e progredir. Eu fiz isso
00:52:28e,
00:52:29no fim dessa estrada corporativa, percebi: 'Cara, não estou tão feliz
00:52:34com isso quanto deveria'. Conquistei coisas enormes, mas não estou sentindo satisfação. E desde que abri meu próprio negócio e percebi:
00:52:41'Será que eu realmente quero pagar todo esse aluguel na região metropolitana de Boston?'
00:52:44Se eu não ficasse em Boston, o que faria? E encontrei um vídeo no YouTube de um cara que pegou um caminhão da U-Haul,
00:52:51sabe, um caminhão de mudança,
00:52:53e o transformou em um apartamento sobre rodas, e pensei:
00:52:55'Uau,
00:52:58isso é bem legal'.
00:53:00Comecei a pesquisar obsessivamente no YouTube e descobri que há toda uma
00:53:05comunidade de pessoas que vivem assim. Eu apenas
00:53:08pesquisei, assisti a vários vídeos e decidi vender tudo.
00:53:13Não renovei o contrato daquele apartamento
00:53:16e rumei para o oeste no meu Civic. Poucos meses depois, consegui a Molly, montei tudo
00:53:22e comecei. Mas sim, foi a compreensão de que eu tinha muita
00:53:28experiência de vida para recuperar.
00:53:31Sabe, passei tempo demais, ironicamente, em um podcast de tecnologia, passei tempo demais
00:53:37no computador e pouco tempo lá fora no mundo. Percebi que precisava dessa experiência para me equilibrar, porque
00:53:44sou mais do que apenas um cara obcecado por desenvolvimento, sou um ser humano com o meu
00:53:49próprio estilo.
00:53:52Preciso sair um pouco e tocar grama.
00:53:55Preciso tocar grama e tenho tocado muito mais do que grama por aqui: rochas,
00:53:59Sabe, montanhas, água, todo tipo de coisa. Tem todo tipo de coisa para tocar por aí. É, com certeza.
00:54:04Você mencionou o incidente com o urso, houve alguma outra
00:54:08aventura interessante enquanto esteve na estrada?
00:54:12Nossa, tantas! Fiz o Cinnamon Pass no Colorado com amigos, que é uma trilha off-road,
00:54:18um pouco técnica, um pouco desafiadora. Fui para o Wyoming, visitei Yellowstone, Grand Teton.
00:54:24Acampei em terras públicas perto de lá onde dá para ver os ursos. Às vezes ouço
00:54:30burros selvagens onde estou. Vi cavalos selvagens há alguns dias;
00:54:34você os ouve andando, olha pela janela da barraca e lá estão eles, alguns cavalos.
00:54:39Mas...
00:54:41Sim, cruzei o país várias e várias vezes,
00:54:45e...
00:54:47Sim, tem sido legal. Tenho uma namorada que topa
00:54:51encarar minha loucura e partimos juntos para aventuras,
00:54:54hum, e, é, tem sido divertido. Quer dizer, isso daria um episódio inteiro sobre todos os lugares malucos por onde passei
00:55:01Ah, é
00:55:03Parece demais. Provavelmente tem um episódio no seu próprio podcast, né?
00:55:08Sobre isso, sabe, deveria ter, porque geralmente eu, bem, porque eu trago um convidado e a gente fica conversando sobre, sabe
00:55:15o assunto, mas talvez eu devesse fazer um só falando sobre isso
00:55:20Sim, até as, hum, as suas opiniões e lições sobre o burnout, acho que seria um
00:55:25episódio muito útil para muitos engenheiros, especialmente hoje em dia, porque eu sinto que
00:55:29nos prometeram que a IA vai
00:55:33nos tornar mais produtivos e que trabalharemos menos horas, quando na realidade eu sinto que é o opuesto, basicamente
00:55:41Às vezes você acaba esgotado pela quantidade de trabalho que se espera que você faça com essas ferramentas agora disponíveis
00:55:50Sim, minhas opiniões sobre isso provavelmente seriam consideradas bem subversivas
00:55:53E vou parar por aí, onde precisamos, precisamos, precisamos de mais trabalhadores. Vamos ser honestos
00:55:58É isso que nós somos. Nós somos trabalhadores. Precisamos de condições mais humanas
00:56:03Totalmente
00:56:06Sim, concordo
00:56:08Sempre gostamos de perguntar aos nossos convidados: você tem alguma opinião polêmica sobre SRE, DevOps,
00:56:14IA, qualquer coisa relacionada à tecnologia? Sim. Certo, opinião polêmica, e digo isso com a maior quantidade de
00:56:22respeito, não pretendo fazer gatekeeping da prática de SRE
00:56:26mas vou dizer o seguinte: se você tem um cargo de SRE, se você tem um título de trabalho
00:56:29que é SRE
00:56:32e agora está no canto escrevendo YAML
00:56:34e sendo acionado no pager
00:56:37quero que você questione seriamente se isso é de fato um papel de SRE
00:56:40SRE é uma prática em que você pega um sistema não tão confiável
00:56:45e o transforma em um sistema confiável
00:56:47e faz os clientes felizes por meio de SLOs
00:56:50gerenciamento de toil, planejamento de capacidade, certo? Todas essas responsabilidades operacionais de ordem superior e usando engenharia de software
00:56:59Isso é muito, muito importante. Isso é a prática de SRE
00:57:01Portanto, YAML não é uma linguagem de programação; se é isso que você faz na maior parte do tempo,
00:57:06eu te encorajo, sabe, a ir para águas mais profundas. É ótimo por aqui,
00:57:11há uma comunidade ótima, muitas pessoas que ficarão mais do que felizes em te ensinar, mas
00:57:15certifique-se de encontrar funções que te desafiem e o ajudem a crescer
00:57:18O livro 'The Phoenix Project' popularizou a palavra DevOps, e desde então há pessoas que são engenheiros de DevOps e que fazem o quê?
00:57:26Você disse, tipo, escrever YAML e, hum,
00:57:29escrever Kubernetes e todas essas coisas, e é meio que o DevOps
00:57:33de que o livro falava não é alguém que faz isso. É mais como o que você explicou: unir duas diferentes,
00:57:39qual é a palavra?, tipo, não sistemas, mas disciplinas juntas?
00:57:43E acho que é bastante comum, como eu disse, no mundo ver 'eu sou um engenheiro de DevOps',
00:57:48'estou aprendendo DevOps', e é tipo, não é isso, é
00:57:51o que você explicou. É difícil agora unir isso porque agora é tão comum que as pessoas sejam engenheiros de DevOps
00:57:56que não é visto como o que você explicou. Mas sim, é difícil voltar atrás agora, não é?
00:58:02Sim, quero dizer, estamos falando de semântica e nomes, então tentarei qualificar o que estou dizendo quando me refiro a DevOps
00:58:09Sim, de fato
00:58:10Não estamos falando de um conjunto de ferramentas. Não estamos falando de uma equipe específica, sabe, título, ferramenta ou equipe, as pessoas falam sobre isso
00:58:15o tempo todo. Não, não é isso, é a prática de unir
00:58:19tecnologia, pessoas, liderança, processo, para que possamos entregar software ao cliente da maneira mais rápida possível,
00:58:27colaborativa e o mais benéfica possível para o negócio. Para mim, é isso que o DevOps é, e os meios para chegar
00:58:34lá são diversos
00:58:35Não é só o Kubernetes, o Kubernetes é uma peça do quebra-cabeça. Não é só, sabe, CI/CD,
00:58:40é uma peça do quebra-cabeça. Às vezes também é sentar e ouvir as pessoas. Às vezes é falar sobre construir visão e estratégia, às vezes,
00:58:47sabe, é sobre dar folga aos seus times depois que eles foram acionados no pager uma vez demais às 3 da manhã
00:58:52DevOps é sobre essa visão
00:58:55holística, em vez de apenas as ferramentas. As ferramentas são legais, eu entendo, as pessoas querem vender as ferramentas,
00:59:01mas essa é apenas uma faceta de toda a experiência. Sim, por falar em ferramentas, você tem alguma ferramenta favorita que usa?
00:59:08Nossa, ok. Deixe-me pensar sobre isso. Sim, vou sugerir uma. Então,
00:59:14tem
00:59:15havido muitos incidentes no GitHub recentemente
00:59:20e nós meio que pegamos o hábito de 'ei, eu gostaria que meus processos de build e meus pipelines de teste estivessem
00:59:26hospedados internamente'. Existe uma ferramenta que você pode executar em vez disso, se quiser hospedar suas próprias coisas,
00:59:32chamada Concourse
00:59:35E eu gosto do Concourse. Ele permite que você construa pipelines muito sofisticados
00:59:38para testes, build, entrega ou o que quer que seja, usando YAML; cada pequena seção roda em um container,
00:59:47mas você o hospeda por conta própria. E o motivo pelo qual eu realmente gosto dele
00:59:50é que a comunidade de código aberto,
00:59:53tipo, a governança é o seu próprio modelo de governança,
00:59:56não pertence a uma empresa que pode, sabe, trocar a licença e transformá-la em um SaaS,
01:00:01o que já vimos muitas vezes em outros projetos. Então, se você está ficando frustrado com,
01:00:06sabe,
01:00:09usar o serviço em nuvem da moda para o seu CI/CD, dê uma olhada no Concourse, use-o, execute-o on-premise
01:00:16Sabe, talvez você esteja retrocedendo cinco ou dez anos em termos de filosofia, mas pode ser mais estável. Quem sabe?
01:00:20Legal. Nunca ouvi falar dele. Vou ter que dar uma olhada
01:00:23Sim, eu também
01:00:26É bom. Oh, existem algumas empresas por aí que definitivamente o utilizam
01:00:29E, é, amigos não deixam amigos rodarem o Jenkins, tipo, isso já era. Não façam isso, não façam isso
01:00:35Então você está dizendo que o Jenkins está morto?
01:00:38Eu disse isso?
01:00:41Não, não, não, não foi uma pergunta pegadinha
01:00:44Mas o que estou dizendo é que há algumas opções mais recentes
01:00:47e acho que as pessoas não querem mais escrever scripts Groovy. Então, sim,
01:00:51outras coisas por aí também foram um pé no saco para mim
01:00:54Sim, quando eu usei
01:00:57Sim
01:00:59Muito bom
01:01:01Tem algo que você queira divulgar, tipo, você tem um podcast. Tem mais alguma coisa de que queira falar antes de terminarmos?
01:01:06Claro, vamos lá. Sou sempre grato por isso. Sim,
01:01:09eu sou consultor na minha empresa Cherto Moto, que é c-e-r-t-o-m-o-d-o.io. Sou especializado em avaliar
01:01:18a postura de confiabilidade, DevOps e SRE das empresas. Se você recebe muitos alertas no pager,
01:01:22se não está entregando com frequência, se os clientes estão zangados,
01:01:26deve definitivamente reservar um tempo no meu calendário. Também apresento um podcast chamado Reliability Rebels,
01:01:31onde entrevisto pessoas conversando sobre
01:01:33como SRE não se resume apenas a ferramentas, mas também a desafiar o status quo
01:01:38falando sobre o aspecto sociotécnico. E no dia 24
01:01:41de fevereiro, farei um webinar sobre
01:01:45a
01:01:47enxurrada de código de IA
01:01:48Acho que chamo de tsunami de código de IA. E faço webinars mensalmente falando sobre todo tipo de assunto interessante,
01:01:54então se você tiver interesse, confira meu site e poderá aprender tudo sobre isso. Muito obrigado pela oportunidade de divulgar
01:01:59Imagina. Obrigado. Obrigado por
01:02:03falar sobre todas essas, desculpa, aventuras e lições aprendidas. Foi muito divertido ter você,
01:02:09então obrigado a todos por ouvirem este episódio do Better Stack Podcast.
01:02:13Inscrevam-se no nosso show onde quer que vocês obtenham seus podcasts: Apple, Spotify, YouTube, escolham o seu favorito, mas por enquanto,
01:02:20é um adeus da minha parte
01:02:22É um adeus da minha parte
01:02:25E um adeus da minha parte
01:02:33(música animada)