Smashing Podcast Episódio 42 Com Jeff Smith: O que é DevOps?

Neste episódio, estamos falando sobre DevOps. O que é, e é uma string para adicionar ao seu arco de desenvolvimento web? Drew McLellan fala com o especialista Jeff Smith para descobrir.

Mostrar notas

• Jeff no Twitter
• Livro de Jeff Operations Anti-Patterns, DevOps Solutions
• DevOps atingíveis

Atualização semanal

• Fazendo a ponte entre designers e desenvolvedores escrito por Matthew Talebi
• APIs React úteis para construir componentes flexíveis com TypeScript escrito por Gaurav Khanna
• Soluções CSS inteligentes para desafios comuns de interface do usuário escritas por Cosima Mielke
• Dicas e truques para avaliar designers de UX/UI escritos por Nataliya Sambir
• Resolvendo problemas de CLS em um site de comércio eletrônico com tecnologia Next.js, escrito por Arijit Mondal

Transcrição

Drew McLellan: Ele é um profissional de DevOps que se concentra em níveis atingíveis de implementações de DevOps, independentemente de onde você esteja em sua jornada. Ele é diretor de operações de produção da plataforma de publicidade digital Centro, além de palestrante, compartilhando seu conhecimento de DevOps com públicos de todo o mundo. Ele é o autor do livro Operations Anti-Patterns, DevOps Solutions for Manning Publishing, que mostra como implementar técnicas de DevOps no tipo de ambiente imperfeito em que a maioria dos desenvolvedores trabalha. Clooney o considera o melhor fabricante de aviões de papel de uma geração? Meus amigos do Smashing, dêem as boas-vindas a Jeff Smith. Olá Jeff. Como você está?

Jeff Smith: Estou arrasando, Drew, como você está?

Drew: Estou bem. Obrigada. Isso é bom de ouvir. Então eu queria falar com vocês hoje sobre o assunto DevOps, que é uma de suas principais áreas-chave. Muitos de nossos ouvintes estarão envolvidos no desenvolvimento da web e de aplicativos, mas talvez tenham apenas uma familiaridade vaga com o que acontece no lado operacional das coisas. Eu sei que aqueles de nós que podem trabalhar em empresas maiores terão equipes inteiras de colegas que estão fazendo operações. Estamos apenas gratos que o que quer que eles façam, eles estão fazendo bem. Mas ouvimos falar de DevOps cada vez mais, e parece uma daquelas coisas que, como desenvolvedores, devemos realmente entender. Então, Jeff, o que é DevOps?

Jeff: Então, se você perguntar a 20 pessoas o que é DevOps, você pode obter 20 respostas diferentes. Então, vou dar minha opinião sobre isso, tudo bem, e saiba que se você estiver em uma conferência e mencionar isso, poderá brigar com alguém. Mas, para mim, DevOps é realmente sobre esse relacionamento entre, e focamos em dev e operações, mas realmente esse relacionamento entre equipes e como estruturamos nosso trabalho e, mais importante, estruturamos nossos objetivos e incentivos para garantir que eles sejam alinhados para que trabalhemos em direção a um objetivo comum. E muitas das ideias e conceitos centrais do DevOps vêm do velho mundo, onde dev e ops sempre foram adversários, onde havia esse conflito constante. E quando você pensa sobre isso, é por causa da forma como essas duas equipes são incentivadas. Uma equipe é incentivada a promover mudanças. Outra equipe é incentivada a manter a estabilidade, o que significa menos mudanças.

Jeff: Quando você faz isso, você cria esse conflito inerente e tudo se espalha a partir daí. Então DevOps é realmente alinhar essas equipes e objetivos para que trabalhemos em direção a uma estratégia comum, mas também adotando práticas de ambos os lados, para que dev entenda mais sobre operações e ops entenda mais sobre dev, como uma forma de ganhar e compartilhar empatia uns com os outros para que possamos entender a perspectiva de onde a outra pessoa está vindo.

Jeff: Mas também para aprimorar nosso trabalho. Porque, novamente, se eu entender sua perspectiva e levar isso em consideração no meu trabalho, será muito mais benéfico para cada um de nós. E há muito que as operações podem aprender com os desenvolvedores em termos de automação e como abordamos as coisas para que sejam facilmente reproduzíveis. Então é essa mistura e habilidades. E o que você está vendo agora é que isso se aplica a diferentes combinações de grupos, então você está ouvindo coisas como DevSecOps, DevSecFinOps, DevSecFinHROps. Só vai continuar crescendo e crescendo e crescendo. Portanto, é realmente uma lição que podemos eliminar em toda a organização.

Drew: Então, é pegar alguns dos conceitos que entendemos como desenvolvedores e espalhar nossas ideias ainda mais na organização e, ao mesmo tempo, aprender o que podemos das operações para tentar levar todos adiante.

Jeff: Com certeza, sim. E outro aspecto das operações, e você mencionou um pouco na introdução, é que achamos que é apenas para essas organizações maiores com equipes de operações dedicadas e coisas assim, mas uma coisa a se pensar é que as operações estão acontecendo em sua organização, independentemente do tamanho. É apenas uma questão de você fazer isso, ou se há uma equipe separada fazendo isso, mas de alguma forma você está implantando código. De alguma forma você tem um servidor rodando em algum lugar. Portanto, as operações existem em algum lugar da sua organização, independentemente do tamanho. A questão é: quem está fazendo isso? E se for uma única pessoa ou um único grupo, o DevOps pode ser ainda mais importante para você, pois você precisa entender os tipos de coisas que as operações fazem.

Drew: Como desenvolvedores profissionais, quão importante você acha que é para nós ter uma boa compreensão do que é DevOps e o que significa implementar?

Jeff: Acho super importante, especialmente nesta fase da jornada do DevOps. E a razão pela qual eu acho importante é essa, acho que somos sempre mais eficientes, novamente, quando entendemos o que nossos colegas estão fazendo. Mas a outra coisa é ser capaz de levar em consideração as preocupações operacionais durante o desenvolvimento do projeto e a implementação de qualquer tecnologia. Então, uma coisa que aprendi em minha carreira é que, embora eu achasse que os desenvolvedores eram mestres do universo e entendessem tudo o que tinha a ver com computadores, na verdade não é o caso. Acontece que há muitas coisas que eles terceirizam para operações em termos de compreensão e, às vezes, isso resulta em escolhas de design específicas ou escolhas de implementação que podem não ser ideais para uma implantação de produção.

Jeff: Eles podem estar bem em desenvolvimento e testes e coisas assim, mas quando você chega à produção, é um pouco diferente. Portanto, não quer dizer que eles precisam possuir todo esse conjunto de conhecimentos, mas pelo menos precisam saber o suficiente para saber o que não sabem. Assim, eles sabem quando se envolver com as operações desde o início, porque esse é um padrão comum que vemos quando o desenvolvimento faz uma escolha. Eu nem direi fazer uma escolha porque eles nem estão cientes de que é uma escolha, mas há algo que acontece que leva a uma decisão abaixo do ideal para operações e desenvolvimento foi completamente inconsciente. Então, apenas ter um pouco mais de conhecimento sobre operações, mesmo que seja apenas o suficiente para dizer, talvez devêssemos trazer as operações para obter sua perspectiva antes de seguirmos em frente. Isso pode economizar muito tempo, energia e estabilidade, obviamente, no que se refere a quaisquer produtos que você esteja lançando.

Drew: Eu vejo tantos paralelos com a maneira como você está falando sobre a relação entre dev e ops como temos entre design e dev, onde você tem designers trabalhando talvez em como uma interface funciona e parece e tendo um bom entendimento de como isso realmente será construído na função de desenvolvimento, e trazer os desenvolvedores para consulta pode realmente melhorar a solução geral apenas por ter essa comunicação clara e uma compreensão do que cada um faz. Parece que é o mesmo princípio usado no DevOps, o que é muito, muito bom de ouvir.

Drew: Quando penso nas coisas que ouço sobre DevOps, ouço termos como Kubernetes, Docker, Jenkins, CircleCI. Há anos que ouço falar do Kubernetes. Ainda não tenho ideia do que seja, mas pelo que você está dizendo, parece que DevOps não é apenas sobre... Não estamos falando apenas de ferramentas aqui, estamos? Mas mais sobre processos e formas de comunicação em fluxos de trabalho, certo?

Jeff: Absolutamente. Então, meu mantra nos últimos 20 anos sempre foi ferramentas de processo de pessoas. Você leva as pessoas a comprar a visão. A partir daí, você define como será o seu processo para alcançar essa visão. E então você traz ferramentas que vão modelar qualquer que seja o seu processo. Então, eu sempre coloco ferramentas no final da conversa sobre DevOps, principalmente porque se você não tem esse buy-in, então não importa. Eu poderia criar o maior pipeline de implantação contínua de todos os tempos, mas se as pessoas não acreditarem na ideia de enviar todas as alterações diretamente para a produção, isso não importa, certo? De que adianta a ferramenta? Portanto, essas ferramentas definitivamente fazem parte da conversa, apenas porque são uma maneira padronizada de atingir alguns objetivos comuns que definimos.

Jeff: Mas você precisa ter certeza de que as metas que estão sendo definidas fazem sentido para sua organização. Talvez a implantação contínua não faça sentido para você. Talvez você não queira enviar todas as alterações no minuto em que elas forem lançadas. E há muitas empresas e organizações e razões pelas quais você não gostaria de fazer isso. Então, talvez algo como um pipeline de implantação contínua não faça sentido para você. Portanto, embora as ferramentas sejam importantes, é mais importante se concentrar no que vai agregar valor à sua organização e, em seguida, modelar e implementar as ferramentas necessárias para conseguir isso.

Jeff: Mas não fique online e descubra o que todo mundo está fazendo e pense, oh, bem, se vamos fazer DevOps, temos que mudar para Docker e Kubernetes porque essa é a cadeia de ferramentas. Não, não é isso. Você pode não precisar dessas coisas. Nem todo mundo é Google. Nem todo mundo é Netflix. Pare de ler postagens da Netflix e do Google. Por favor, apenas pare de lê-los. Porque isso deixa as pessoas animadas e elas ficam tipo, bem, isso é o que temos que fazer. E é como, bem, eles estão resolvendo problemas muito diferentes dos problemas que você tem.

Drew: Então, digamos que estou iniciando um novo projeto, talvez eu seja uma empresa iniciante, criando software como um produto de serviço. Tenho três desenvolvedores, tenho um repositório Git vazio e tenho sonhos de IPOs. Para participar de uma abordagem DevOps para construir este produto, quais são os nomes dos blocos de construção que devo ter em termos de pessoas e processos e por onde começo?

Jeff: Então, no seu exemplo específico, o primeiro lugar com o qual eu começaria é apostar o máximo possível e usar algo como Heroku ou algo para esse efeito. Porque você fica tão empolgado com todas essas coisas da AWS, coisas do Docker e, na realidade, é tão difícil construir um produto de sucesso. A ideia de que você está se concentrando na parte do DevOps é tipo, bem, eu diria que terceirizar o máximo possível até que se torne um ponto problemático. Mas se você está nesse ponto em que está dizendo tudo bem, estamos prontos para levar essas coisas para dentro de casa e estamos prontos para levá-las ao próximo nível. Eu diria que o primeiro lugar para começar é, onde estão seus pontos de dor? quais são as coisas que estão causando problemas?

Jeff: Então, para algumas pessoas, é tão simples quanto testes automatizados. A ideia de que ei, precisamos executar testes toda vez que alguém faz um commit, porque às vezes estamos enviando coisas que são capturadas por testes de unidade que já escrevemos. Então talvez você comece com integração contínua. Talvez suas implantações demorem horas para serem concluídas e sejam muito manuais, então é aí que você se concentra e diz, ok, que automação precisamos para tornar isso um caso de um clique de botão? Mas eu odeio prescrever um general, é aqui que você começa, só porque sua situação particular e seus pontos de dor específicos serão diferentes. E a coisa é, se é um ponto de dor, deveria estar gritando com você. Deve ser absolutamente gritando com você.

Jeff: Deve ser uma daquelas coisas em que alguém diz, oh, o que é ruim em sua organização? E deveria ser como, oh, eu sei exatamente o que é isso. Então, quando você aborda dessa perspectiva, acho que as próximas etapas se tornam bastante aparentes para você em termos do que na caixa de ferramentas do DevOps você precisa descompactar e começar a trabalhar. E então se tornam essas mudanças incrementais mínimas que continuam chegando e você percebe que, à medida que obtém novos recursos, seu apetite por coisas abaixo do padrão se torna muito pequeno. Então você vai de, oh sim, as implantações levam três horas e tudo bem. Você coloca algum esforço nisso e a próxima coisa que você sabe, em três semanas, você fica tipo, cara, eu não posso acreditar que a implantação ainda está levando 30 minutos. Como podemos reduzir isso de 30 minutos? Seu apetite se torna insaciável por melhorias. Então as coisas meio que se espalham a partir daí.

Drew: Estive lendo seu livro recente e isso destaca o que você chama de quatro pilares do DevOps. E nenhuma delas são ferramentas, como mencionado, mas existem essas quatro áreas principais de foco, se você preferir, para DevOps. Percebi que a primeira delas é a cultura, fiquei bastante surpreso com isso, em primeiro lugar, porque esperava que você falasse mais sobre ferramentas e agora entendemos o porquê, mas quando se trata de cultura, parece estranho coisa a ter no início. Há uma base para uma abordagem técnica. Como a cultura afeta o sucesso da implementação de DevOps em uma organização?

Drew: … como a implementação de DevOps pode ser bem-sucedida em uma organização.

Jeff: A cultura é realmente a base de tudo quando você pensa sobre isso. E é importante porque a cultura, e nós entramos nisso um pouco mais a fundo no livro, mas a cultura realmente prepara o cenário para as normas dentro da organização. Certo. Você provavelmente já esteve em uma empresa onde, se você enviou um PR sem testes automatizados, isso não é grande coisa. As pessoas aceitam e seguem em frente.

Jeff: Mas há outras organizações onde isso é um pecado capital. Certo. Onde se você fez isso, é como, “Uau, você está louco? O que você está fazendo? Não há casos de teste aqui.” Certo. Mas isso é cultura. Essa é a cultura que está impondo essa norma para dizer: “Isso não é o que fazemos”.

Jeff: Qualquer um pode escrever um documento que diga que teremos casos de teste automatizados, mas a cultura da organização é o que impõe esse mecanismo entre as pessoas. Esse é apenas um pequeno exemplo de por que a cultura é tão importante. Se você tem uma organização onde a cultura é uma cultura de medo, uma cultura de retribuição. É como se você cometer um erro, certo, isso é um sacrilégio. Certo. Isso equivale a traição. Certo.

Jeff: Você cria comportamentos nessa organização que são adversos a qualquer coisa que possa ser arriscada ou potencialmente falhar. E isso acaba deixando muitas oportunidades na mesa. Por outro lado, se você criar uma cultura que abrace aprender com o fracasso, abrace essa ideia de segurança psicológica, onde as pessoas possam experimentar. E se estiverem errados, podem descobrir como falhar com segurança e tentar novamente. Você obtém uma cultura de experimentação. Você obtém uma organização onde as pessoas estão abertas a novas ideias.

Jeff: Acho que todos nós já estivemos nessas empresas onde é como, “Bem, é assim que é feito. E ninguém muda isso.” Certo. Você não quer isso porque o mundo está mudando constantemente. É por isso que colocamos a cultura na frente e no centro, porque muitos dos comportamentos dentro de uma organização existem por causa da cultura que existe.

Jeff: E o fato é que atores culturais podem ser para o bem ou para o mal. Certo. O que é irônico, e falamos sobre isso no livro também, é que não são necessárias tantas pessoas quanto você pensa para mudar a cultura organizacional. Certo. Porque a maioria das pessoas, há detratores, e depois há apoiadores, e depois há cercas quando se trata de qualquer tipo de mudança. E a maioria das pessoas são babás de cerca. Certo. É preciso apenas um punhado de apoiadores para realmente inclinar a balança. Mas, no mesmo sentido, é preciso apenas um punhado de detratores para inclinar a balança.

Jeff: Não é preciso muito para mudar a cultura para melhor. E se você colocar essa energia nisso, mesmo sem ser um líder sênior, você pode realmente influenciar a cultura da sua equipe, que acaba influenciando a cultura do seu departamento, que acaba influenciando a cultura da organização.

Jeff: Você pode fazer essas mudanças culturais como um colaborador individual, apenas defendendo essas ideias e esses comportamentos em voz alta e dizendo: “Esses são os benefícios que estamos obtendo com isso”. É por isso que eu acho que a cultura tem que estar na frente, porque você tem que fazer com que todos acreditem nessa ideia e eles precisam entender que, como organização, valerá a pena e apoiá-la.

Drew: Sim. Tem que ser um modo de vida, eu acho.

Jef: Exatamente.

Drew: Sim. Estou realmente interessado na área de automação porque, ao longo da minha carreira, nunca vi alguma automação implementada que não tenha sido benéfica. Certo. Quero dizer, além da coisa estranha, talvez, onde algo é automatizado e dá errado. Geralmente, quando você reserva um tempo para se sentar e automatizar algo que está fazendo manualmente, sempre economiza tempo e espaço na cabeça, e é apenas um peso fora de seus ombros.

Drew: Ao adotar uma abordagem DevOps, que tipo de coisas você procuraria automatizar em seus fluxos de trabalho? E que ganhos você esperaria ver com isso ao concluir as coisas manualmente?

Jeff: Quando se trata de automação, a seu ponto, muito raramente há um momento em que a automação não tornou a vida melhor. Certo. O problema que as pessoas encontram é encontrar tempo para construir essa automação. Certo. E geralmente, no meu trabalho atual, para nós, na verdade, é o objetivo do pedido. Certo. Porque em algum momento você tem que dizer: “Vou parar de fazer isso manualmente e vou automatizar”.

Jeff: E pode ser quando você recebe um pedido em que diz: “Sabe de uma coisa? Isso vai levar duas semanas. Eu sei que normalmente resolvemos isso em algumas horas, mas levará duas semanas porque essa é a solicitação que é automatizada.” Em termos de identificar o que você automatiza. Na Central, eu uso o processo onde, basicamente, eu amostraria todos os diferentes tipos de solicitações que chegaram em um período de quatro semanas, digamos. E eu os classificaria como trabalho planejado, trabalho não planejado, trabalho de valor agregado, trabalho árduo. A labuta é um trabalho que não é realmente útil, mas, por algum motivo, minha organização precisa fazê-lo.

Jeff: E então identificar aquelas coisas que são como, “Ok, qual é o fruto mais fácil do qual podemos nos livrar se automatizarmos isso? O que podemos fazer para simplificar isso?” E alguns dos critérios foi o risco do processo. Certo. Os failovers automatizados de banco de dados são um pouco assustadores porque você não os faz com tanta frequência. E mudanças de infraestrutura. Certo. Dizemos: “Com que frequência estamos fazendo isso?” Se estivermos fazendo isso uma vez por ano, pode não valer a pena automatizar porque há muito pouco valor nisso. Mas se é uma daquelas coisas que estamos recebendo duas, três vezes por mês, ok, vamos dar uma olhada nisso. Tudo bem.

Jeff: Agora, quais são as coisas que podemos fazer para acelerar isso? E o fato é que, quando falamos sobre automação, instantaneamente saltamos para “Vou clicar em um botão e isso será feito magicamente”. Certo. Mas há tantas etapas diferentes que você pode fazer na automação se se sentir enjoado. Certo. Por exemplo, digamos que você tenha 10 etapas com 10 comandos CLI diferentes que você normalmente executaria. Sua primeira etapa de automação pode ser tão simples quanto executar esse comando ou pelo menos mostrar esse comando. Certo. Diga: “Ei, é isso que vou executar. Você acha que está tudo bem?” "Sim." "OK. Este é o resultado que obtive. Tudo bem se eu continuar?” "Sim." "OK. Este é o resultado que obtive”. Certo.

Jeff: Dessa forma você ainda tem um pouco de controle. Você se sente confortável. E depois de 20 execuções, você percebe que está apenas acertando, sim, sim, sim, sim, sim, sim. Você diz: “Tudo bem. Vamos encadear todas essas coisas e tornar tudo um.” Não é como se você tivesse que pular no fundo do poço, clicar nele e esquecê-lo logo de cara. Você pode entrar nisso até se sentir confortável.

Jeff: Esses são os tipos de coisas que fizemos como parte de nosso esforço de automação, como podemos acelerar o tempo de resposta disso e reduzir o nível de esforço de nossa parte? Pode não ser 100% no primeiro dia, mas o objetivo é sempre chegar a 100%. Começaremos com pequenos pedaços com os quais automatizaremos partes com as quais nos sentimos confortáveis. sim. Nós nos sentimos super confiantes de que isso vai funcionar. Nesta parte estamos um pouco arriscados, então talvez tenhamos alguma verificação humana antes de prosseguirmos.

Jeff: A outra coisa que analisamos em termos de automação, mas qual valor estamos agregando a um processo específico? E isso é particularmente importante para operações. Porque muitas vezes o ops serve como intermediário para um processo. Então o envolvimento deles nada mais é do que alguma coisa de acesso. Certo. É como, bem, ops tem que fazer isso porque ops é a única pessoa que tem acesso.

Jeff: Bem, é como, bem, como terceirizamos esse acesso para que as pessoas possam fazer isso? Porque a realidade é que não estamos preocupados com o fato de os desenvolvedores terem acesso à produção. Certo. Estamos preocupados com o fato de os desenvolvedores terem acesso irrestrito à produção. E isso é realmente uma coisa de segurança. Certo. É como se minha caixa de ferramentas tivesse apenas facas afiadas, eu vou ter muito cuidado com quem eu entrego isso. Mas se eu puder misturar a caixa de ferramentas com uma colher e um martelo para que as pessoas possam escolher a ferramenta certa para o trabalho, então é muito mais fácil emprestar isso.

Jeff: Por exemplo, tivemos um processo em que as pessoas precisavam executar scripts Ruby ad hoc em produção, por qualquer motivo. Certo. Precisa limpar dados, precisa corrigir algum registro ruim, seja o que for. E isso sempre viria através da minha equipe. E é como, bem, não estamos adicionando nenhum valor a isso porque não posso aprovar esse ticket. Certo. Eu não faço ideia. Você escreveu o software, então de que adianta eu sentar no seu ombro e dizer: “Bem, acho que é seguro”? Certo. Eu não adicionei nenhum valor para digitá-lo porque estou apenas digitando exatamente o que você me disse para digitar. Certo.

Jeff: E na pior das hipóteses, e no final, eu sou apenas um obstáculo para você porque você está enviando um tíquete, então você está esperando que eu volte do almoço. Voltei do almoço, mas tenho essas outras coisas para trabalhar. Dissemos: “Como automatizar isso para que possamos colocar isso nas mãos dos desenvolvedores e, ao mesmo tempo, abordar qualquer uma dessas preocupações de auditoria que possamos ter?”

Jeff: Colocamos em um fluxo de trabalho do JIRA, onde tínhamos um bot que automatizava a execução de comandos especificados no ticket do JIRA. E então poderíamos especificar no ticket do JIRA que era necessário a aprovação de um dos vários engenheiros seniores. Certo.

Jeff: Faz mais sentido que um engenheiro aprove o trabalho de outro engenheiro porque eles têm o contexto. Certo. Eles não precisam ficar sentados esperando pelas operações. A parte de auditoria é respondida porque temos um fluxo de trabalho claro que foi definido no JIRA que está sendo documentado conforme alguém aprova, conforme alguém solicitou. E temos automação que está puxando esse comando e executando esse comando literalmente no terminal. Certo.

Jeff: Você não precisa se preocupar comigo digitando errado. Você não precisa se preocupar comigo pegando o bilhete errado. Isso aumentou o tempo de retorno desses ingressos, algo como dez vezes. Certo. Os desenvolvedores são desbloqueados. A minha equipa não está empenhada em fazer isto. E tudo o que realmente levou foi uma semana ou duas semanas de investimento para realmente desenvolver a automação e as permissões necessárias para obter acesso a ela.

Jeff: Agora estamos completamente afastados disso. E o desenvolvimento é realmente capaz de terceirizar algumas dessas funcionalidades para partes inferiores da organização. Eles o empurraram para o atendimento ao cliente. É como agora quando o atendimento ao cliente sabe que esse registro precisa ser atualizado para o que for, não precisa de desenvolvimento. Eles podem enviar o script padrão que aprovamos para essa funcionalidade. E eles podem executá-lo exatamente no mesmo fluxo de trabalho que o desenvolvimento faz. É realmente uma benção ao redor.

Jeff: E então isso nos permite empurrar o trabalho cada vez mais para baixo em toda a organização. Porque à medida que fazemos isso, o trabalho fica cada vez mais barato porque eu poderia ter um desenvolvedor sofisticado e caro executando isso. Certo. Ou posso ter uma pessoa de atendimento ao cliente que está trabalhando diretamente com o cliente, executando-o enquanto está ao telefone com um cliente corrigindo um problema.

Jeff: Automação, eu acho, é a chave para qualquer organização. E o último ponto que direi sobre isso é que também permite que você exporte expertise. Certo. Agora, eu posso ser a única pessoa que sabe como fazer isso se eu precisasse fazer um monte de comandos na linha de comando. Mas se eu colocar isso em automação, posso dar isso a qualquer um. E as pessoas sabem qual é o resultado final, mas não precisam conhecer todas as etapas intermediárias. Aumentei meu valor dez vezes ao enviá-lo para a organização e pegar minha experiência e codificá-la em algo que é exportável.

Drew: Você falou sobre automatizar tarefas que ocorrem com frequência. Existe um argumento para também automatizar tarefas que acontecem com tanta frequência que leva muito tempo para um desenvolvedor voltar à velocidade de como deveria funcionar? Porque todos estão esquecidos. Faz tanto tempo. Já faz um ano, talvez ninguém tenha feito isso antes. Existe um argumento para automatizar esse tipo de coisa também?

Jeff: Isso é um ato de equilíbrio difícil. Certo. E eu sempre digo para analisar caso a caso. E a razão de eu dizer isso é que um dos mantras do DevOps é se algo doloroso, faça com mais frequência. Certo. Porque quanto mais você faz isso, mais memória muscular ela se torna e você começa a malhar e resolver esses problemas.

Jeff: O problema que vemos com a automação de tarefas muito raras é que o cenário do ambiente tende a mudar entre as execuções dessa automação. Certo. O que acaba acontecendo é que seu código faz suposições específicas sobre o ambiente e essas suposições não são mais válidas. Então a automação acaba quebrando de qualquer maneira.

Drew: E então você tem dois problemas.

Jeff: Certo. Certo. Exatamente. Exatamente. E você fica tipo, “Eu digitei errado? Ou é isso? Não, essa coisa está realmente quebrada.” Assim-

Jeff: Digitando errado ou isso não, essa coisa está quebrada. Então, quando se trata de automatizar tarefas infrequentes, nós realmente analisamos caso a caso para entender, bem, qual é o risco se isso não funcionar, certo. Se errarmos, estamos em um estado ruim ou apenas não terminamos essa tarefa? Portanto, se você puder ter certeza de que isso falharia graciosamente e não teria um impacto negativo, vale a pena tentar automatizá-lo. Porque, no mínimo, você tem uma estrutura de entendimento do que deveria estar acontecendo porque, no mínimo, alguém será capaz de ler o código e entender, tudo bem, isso é o que estávamos fazendo. E não entendo por que isso não funciona mais, mas tenho uma compreensão clara do que deveria acontecer pelo menos com base no tempo de design quando isso foi escrito.

Jeff: Mas se você estiver em uma situação em que uma falha possa levar a alterações de dados ou algo assim, geralmente erro por precaução e mantenho o manual apenas porque se eu tiver um script de automação, se encontrar algum documento de confluência que tem três anos de idade que diz execute este script, costumo ter cem por cento de confiança nesse script e o executo. Certo. Considerando que, se for uma série de etapas manuais documentadas há quatro anos, eu vou ficar tipo, preciso fazer alguma verificação aqui. Certo? Deixe-me passar por isso um pouco e falar com algumas pessoas. E, às vezes, quando projetamos processos, vale a pena forçar esse processo de pensamento, certo? E você tem que pensar no componente humano e como eles vão se comportar. E às vezes vale a pena tornar o processo um pouco mais complicado para forçar as pessoas a pensar que devo fazer isso agora?

Drew: Existem outras maneiras de identificar o que deve ser automatizado através do monitoramento de seus sistemas e medição das coisas? Quero dizer, penso em DevOps e penso em dashboards como uma das coisas, bons gráficos. E tenho certeza de que há muito mais nesses painéis do que apenas bonitos, mas é sempre bom ter painéis bonitos. Existem maneiras de medir o que um sistema está fazendo, para ajudá-lo a tomar esse tipo de decisão?

Jeff: Absolutamente. E isso meio que segue para a parte de métricas das câmeras, certo, quais são as coisas que estamos rastreando em nossos sistemas para saber se estão operando com eficiência? E um dos tipos comuns de armadilhas das métricas é que procuramos erros em vez de verificar o sucesso. E essas são duas práticas muito diferentes, certo? Portanto, algo pode fluir pelo sistema e não necessariamente apresentar erros, mas não necessariamente passar por todo o processo da maneira que deveria. Portanto, se soltarmos uma mensagem em uma fila de mensagens, deve haver uma métrica correspondente que diga: “E esta mensagem foi recuperada e processada”, certo? Se não, certo, você vai rapidamente ter um desequilíbrio e o sistema não funciona como deveria. Acho que podemos usar métricas como uma maneira de entender também coisas diferentes que devem ser automatizadas à medida que entramos nesses estados ruins.

Jeff: Certo? Porque muitas vezes é um passo muito simples que precisa ser dado para limpar as coisas, certo? Para as pessoas que estão em operações há algum tempo, certo, o alerta de espaço em disco, todo mundo sabe disso. Oh, estamos cheios de disco. Ah, esquecemos que é final de mês e o faturamento correu e o faturamento sempre enche os logs. E então o log VAR está consumindo todo o espaço do disco, então precisamos rodar um log. Certo? Você pode ser acordado às três da manhã para isso, se for de sua preferência. Mas se sabemos que esse é o comportamento, nossas métricas devem ser capazes de nos dar uma pista disso. E podemos simplesmente automatizar o comando de rotação do log, certo? Ah, atingimos esse limite, execute o comando de rotação do log. Vamos ver se o alerta desaparece. Se isso acontecer, continue com a vida. Se isso não acontecer, então talvez a gente acorde alguém, certo.

Jeff: Você também está vendo isso muito mais com automação de infraestrutura, certo, onde é como, “Ei, nossas solicitações por segundo estão atingindo nosso máximo teórico. Talvez precisemos dimensionar o cluster. Talvez precisemos adicionar três ou quatro nós ao pool do balanceador de carga.” E podemos fazer isso sem necessariamente exigir que alguém intervenha. Podemos apenas olhar para essas métricas e tomar essa ação e, em seguida, contratar essa infraestrutura quando ela estiver abaixo de um determinado limite, mas você precisa ter essas métricas e ter esses ganchos em seu ambiente de monitoramento para poder fazer isso. E é aí que entra toda a parte de métricas da conversa.

Jeff: Além disso, também é bom poder compartilhar essa informação com outras pessoas, porque uma vez que você tem dados, você pode começar a falar sobre as coisas em uma realidade compartilhada, certo, porque ocupado é um termo genérico, mas 5.200 solicitações por segundo é algo muito mais concreto sobre o qual todos podemos raciocinar. E acho que muitas vezes, quando estamos conversando sobre capacidade ou qualquer coisa, usamos esses termos ondulados, quando, em vez disso, poderíamos olhar para um painel e fornecer valores muito específicos e garantir que todos tenham acesso a esses painéis, que eles não estão escondidos atrás de uma parede de operações que só nós temos acesso por algum motivo desconhecido.

Drew: So while sort of monitoring and using metrics as a decision-making tool for the businesses is one aspect of it, it sounds like the primary aspect is having the system monitor itself, perhaps, and to respond maybe with some of these automations as the system as a whole gives itself feedback on onto what's happening.

Jeff: Absolutely. Feedback loops are a key part of any real system design, right, and understanding the state of the system at any one time. So while it's easy in the world where everything is working fine, the minute something goes bad, those sorts of dashboards and metrics are invaluable to have, and you'll quickly be able to identify things that you have not instrumented appropriately. Certo. So one of the things that we always talk about in incident management is what questions did you have for the system that couldn't be answered, right. So what is it, or you're like, “Oh man, if we only knew how many queries per second were going on right now.” Certo.

Jeff: Well, okay. How do we get that for next time? How do we make sure that that's radiated somewhere? And a lot of times it's hard when you're thinking green field to sit down and think of all the data that you might want at any one time. But when you have an incident, it becomes readily apparent what data you wish you had. So it's important to sort of leverage those incidents and failures and get a better understanding of information that's missing so that you can improve your incident management process and your metrics and dashboarding.

Drew: One of the problems we sometimes face in development is that teammate members, individual team members hold a lot of knowledge about how a system works and if they leave the company or if they're out sick or on vacation, that knowledge isn't accessible to the rest of the team. It seems like the sort of DevOps approach to things is good at capturing a lot of that operational knowledge and building it into systems. So that sort of scenario where an individual has got all the information in their head that doesn't happen so much. É uma avaliação justa?

Jeff: It is. I think we've probably, I think as an industry we might have overstated its efficacy. And the only reason I say that is when our systems are getting so complicated, right? Gone are the days where someone has the entire system in their head and can understand it from beginning to end. Typically, there's two insidious parts of it. One, people typically focus on one specific area and someone doesn't have the whole picture, but what's even more insidious is that we think we understand how the system works. Certo. And it's not until an incident happens that the mental model that we have of the system and the reality of the system come into conflict. And we realize that there's a divergence, right? So I think it's important that we continuously share knowledge in whatever form is efficient for folks, whether it be lunch and learns, documentation, I don't know, presentations, anything like that to sort of share and radiate that knowledge.

Jeff: But we also have to prepare and we have to prepare and define a reality where people may not completely understand how the system works. Certo. And the reason I think it's important that we acknowledge that is because you can make a lot of bad decisions thinking you know how the system behaves and being 100% wrong. Certo. So having the wherewithal to understand, okay, we think this is how the system works. We should take an extra second to verify that somehow. Certo. I think that's super important in these complicated environments in these sprawling complex microservice environments. Whereas it can be very, it's easy to be cavalier if you think, oh yeah, this is definitely how it works. And I'm going to go ahead and shut the service down because everything's going to be fine. And then everything topples over. So just even being aware of the idea that, you know what, we may not know a hundred percent how this thing works.

Jeff: So let's take that into account with every decision that we make. I think that's key. And I think it's important for management to understand the reality of that as well because for management, it's easy for us to sit down and say, “Why didn't we know exactly how this thing was going to fail?” And it's like, because it's complicated, right, because there's 500 touch points, right, where these things are interacting. And if you change one of them, it changes the entire communication pattern. So it's hard and it's not getting any easier because we're getting excited about things like microservices. We're getting excited about things like Kubernetes. We're giving people more autonomy and these are just creating more and more complicated interfaces into these systems that we're managing. And it's becoming harder and harder for anyone to truly understand them in their entirety.

Drew: We've talked a lot about a professional context, big organizations and small organizations too. But I know many of us work on smaller side projects or maybe we volunteer on projects and maybe you're helping out someone in the community or a church or those sorts of things. Can a DevOps approach benefit those smaller projects or is it just really best left to big organizations to implement?

Jeff: I think DevOps can absolutely benefit those smaller projects. And specifically, because I think sort of some of the benefits that we've talked about get amplified in those smaller projects. Certo? So exporting of expertise with automation is a big one, right? If I am… Take your church example, I think is a great one, right? If I can build a bunch of automated tests suites to verify that a change to some HTML doesn't break the entire website, right, I can export that expertise so that I can give it to a content creator who has no technical knowledge whatsoever. Certo. They're a theologian or whatever, and they just want to update a new Bible verse or something, right. But I can export that expertise so that they know that I know when I make this content change, I'm supposed to run this build button.

Jeff: And if it's green, then I'm okay. And if it's red, then I know I screwed something up. Certo. So you could be doing any manner of testing in there that is extremely complicated. Certo. It might even be something as simple as like, hey, there's a new version of this plugin. And when you deploy, it's going to break this thing. Certo. So it has nothing to do with the content, but it's at least a red mark for this content creator to say “Oh, something bad happened. I shouldn't continue. Certo. Let me get Drew on the phone and see what's going on.” Certo. And Drew can say, “Oh right. This plugin is upgraded, but it's not compatible with our current version of WordPress or whatever.” Certo. So that's the sort of value that we can add with some of these DevOps practices, even in a small context, I would say specifically around automation and specifically around some of the cultural aspects too.

Jeff: Right? So I've been impressed with the number of organizations that are not technical that are using get to make changes to everything. Certo. And they don't really know what they're doing. They just know, well, this is what we do. This is the culture. And I add this really detailed commit message here. And then I push it. They are no better than us developers. They know three get commands, but it's the ones they use over and over and over again. But it's been embedded culturally and that's how things are done. So everyone sort of rallies around that and the people that are technical can take that pattern.

Jeff: … around that and the people that are technical can take that pattern and leverage it into more beneficial things that might even be behind the scenes that they don't necessarily see. So I think there's some value, definitely. It's a matter of how deep you want to go, even with the operations piece, right? Like being able to recreate a WordPress environment locally very easily, with something like Docker. They may not understand the technology or anything, but if they run Docker Compose Up or whatever, and suddenly they're working on their local environment, that's hugely beneficial for them and they don't really need to understand all the stuff behind it. In that case, it's worthwhile, because again, you're exporting that expertise.

Drew: We mentioned right at the beginning, sort of putting off as much sort of DevOps as possible. You mentioned using tools like Heroku. And I guess that sort of approach would really apply here on getting started with, with a small project. What sort things can platforms like Heroku offer? I mean, obviously, I know you're not a Heroku expert or representative or anything, but those sorts of platforms, what sort of tools are they offering that would help in this context?

Jeff: So for one, they're basically taking that operational context for you and they're really boiling it down into a handful of knobs and levers, right? So I think what it offers is one, it offers a very clear set of what we call the yellow brick road path, where it's like, “If you go this route, all of this stuff is going to be handled for you and it's going to make your life easier. If you want to go another route, you can, but then you got to solve for all this stuff yourself.” So following the yellow brick road route helps because one, they're probably identifying a bunch of things that you hadn't even thought of. So if you're using their database container or technology, guess what? You're going to get a bunch of their metrics for free. You're going to get a lot of their alerting for free. You didn't do anything. You didn't think anything. It's just when you need it, it's there. And it's like, “Oh wow, that's super are helpful.”

Jeff: Two, when it comes to performance sizing and flexibility, this becomes very easy to sort of manage because the goal is, you're a startup that's going to become wildly successful. You're going to have hockey stick growth. And the last thing you necessarily really want to be doing is figuring out how to optimize your code for performance, while at the same time delivering new features. So maybe you spend your way out of it. You say, “Well, we're going to go up to the next tier. I could optimize my query code, but it's much more efficient for me to be spending time building this next feature that's going to bring in this new batch of users, so let's just go up to the next tier,” and you click button and you move on.

Jeff: So being able to sort of spend your way out of certain problems, I think it's hugely beneficial because tech debt gets a bad rap, but tech debt is no different than any debt. It's the trade off of acquiring something now and dealing with the pain later. And that's a strategic decision that you have to make in every organization. So unchecked tech debt is bad, right? But tech debt generally, I think, is a business choice and Heroku and platforms like that enable you to make that choice when it comes to infrastructure and performance.

Drew: You've written a book, Operations, Anti-Patterns, DevOps Solutions, for Manning. I can tell it's packed with years of hard-earned experience. The knowledge sort of just leaps out from the page. And I can tell it's been a real labor of love. It's packed full of information. Who's your sort of intended audience for that book? Is it mostly those who are already working in DevOps, or is it got a broader-

Jeff: It's got a broader… So one of the motivations for the book was that there were plenty of books for people that we're already doing DevOps. You know what I mean? So we were kind of talking to ourselves and high-fiving each other, like, “Yeah, we're so advanced. Awesome.” But what I really wanted to write the book for were people that were sort of stuck in these organizations. I don't want to use the term stuck. That's unfair, but are in these organizations that maybe aren't adopting DevOps practices or aren't at the forefront of technology, or aren't necessarily cavalier about blowing up the way they do work today, and changing things.

Jeff: Eu queria escrever para eles, principalmente colaboradores individuais e gerentes de nível médio, para dizer: “Você não precisa ser um CTO para fazer esse tipo de mudança incremental, e você não precisa ter esse toda a revolução de vendas para poder obter alguns dos benefícios do DevOps.” Então foi uma espécie de carta de amor para eles dizerem: “Ei, você pode fazer isso em pedaços. Você pode fazer isso sozinho. E há todas essas coisas que você pode não pensar que estão relacionadas ao DevOps porque você está pensando nisso como ferramentas e Kubernetes.” Nem todas as organizações… Se você fosse para este estado de Nova York, como o governo estadual, você não iria simplesmente entrar e implementar o Kubernetes da noite para o dia. Certo? Mas você pode implementar como as equipes conversam entre si, como trabalham juntas, como entendemos os problemas uns dos outros e como podemos resolver esses problemas por meio da automação. São coisas que estão dentro da sua esfera de influência que podem melhorar o seu dia a dia.

Jeff: Então, era realmente uma carta para essas pessoas, mas acho que há dados suficientes e informações suficientes para as pessoas que estão em uma organização DevOps coletarem e dizerem: “Ei, isso ainda é útil para nós. ” E muitas pessoas, eu acho que identificam rapidamente lendo o livro, que eles não estão em uma organização de DevOps, eles apenas mudaram de cargo. E isso acontece bastante. Então eles dizem: “Ei, nós somos engenheiros de DevOps agora, mas não estamos fazendo esse tipo de prática que é discutida neste livro e como chegamos lá?”

Drew: Então parece que seu livro é um deles, mas existem outros recursos aos quais as pessoas que desejam começar com DevOps podem recorrer? Existem bons lugares para aprender essas coisas?

Jeff: Sim. Acho que DevOps For Dummies de Emily Freeman é um ótimo lugar para começar. Ele realmente faz um ótimo trabalho ao organizar alguns dos principais conceitos e ideias, e para o que estamos nos esforçando. Então esse seria um bom lugar para começar, apenas para obter uma visão geral do terreno. Acho que o Phoenix Project é obviamente outra grande fonte de Gene Kim. E isso é ótimo, isso meio que prepara o cenário para os tipos de problemas que não estar em um ambiente DevOps pode criar. E faz um ótimo trabalho ao destacar esses padrões e personalidades que ocorrem em todos os tipos de organizações repetidamente. Eu acho que faz um ótimo trabalho de destacar aqueles. E se você ler esse livro, acho que vai acabar gritando para as páginas dizendo: “Sim, sim. Este. Este." Então, esse é outro ótimo lugar.

Jeff: E a partir daí, mergulhando em qualquer manual de DevOps. Eu vou me chutar por dizer isso, mas o Manual do Google SRE foi outro ótimo lugar para procurar. Entenda que você não é o Google, então não sinta que precisa implementar tudo, mas acho que muitas das ideias e estratégias deles são válidas para qualquer organização e são ótimos lugares onde você pode pegar coisas e dizer como: "Ok, vamos tornar nosso ambiente de operações um pouco mais eficiente". E isso, acho que será particularmente importante para desenvolvedores que estão desempenhando um papel de operações, porque se concentra muito no tipo de abordagem programática para resolver alguns desses problemas.

Drew: Então, eu tenho aprendido tudo sobre DevOps. O que você tem aprendido ultimamente, Jeff?

Jeff: Kubernetes, cara. Sim. O Kubernetes tem sido uma verdadeira fonte de leitura e conhecimento para nós. Então, estamos tentando implementar isso no Centro atualmente, como um meio de capacitar ainda mais os desenvolvedores. Queremos levar as coisas um passo adiante de onde estamos. Temos muita automação, mas agora, quando se trata de integrar um novo serviço, minha equipe ainda está bastante envolvida com isso, dependendo da natureza do serviço. E não queremos estar nessa linha de trabalho. Queremos que os desenvolvedores sejam capazes de levar uma ideia do conceito ao código e à implantação, e fazer isso onde o conhecimento operacional é codificado dentro do sistema. Assim, à medida que você se move pelo sistema, o sistema o está guiando. Então, achamos que o Kubernetes é uma ferramenta que nos ajudará a fazer isso.

Jeff: É incrivelmente complicado. E é um pedaço grande para morder. Então, descobrir como são as implantações? Como aproveitamos esses operadores dentro do Kubernetes? Como é o CICD neste novo mundo? Então tem havido muita leitura, mas nessa área você está aprendendo constantemente, certo? Não importa há quanto tempo você está nisso, há quanto tempo você está fazendo isso, você é um idiota em algum aspecto desse campo em algum lugar. Então, é apenas algo que você meio que se adapta

Drew: Bem, tiro o chapéu como eu digo, mesmo depois de todos esses anos, embora eu meio que entenda onde isso fica na pilha, ainda não tenho ideia do que o Kubernetes está fazendo.

Jeff: Eu me sinto parecido às vezes. Parece que está fazendo um pouco de tudo, certo? É o DNS do século 21.

Drew: Se você, o ouvinte, gostaria de ouvir mais de Jeff, você pode encontrá-lo no Twitter, onde ele é sombrio e nerd, e encontrar seu livro e links para apresentações anteriores e postagens de blog em seu site, reachabledevops.com. Obrigado por se juntar a nós hoje, Jeff. Você teve alguma palavra de despedida?

Jeff: Continue aprendendo, vá lá, continue aprendendo e converse com seus colegas. Fale, fale, fale. Quanto mais você puder falar com as pessoas com quem trabalha, melhor compreensão, mais empatia você gerará por elas, e se houver alguém em particular na organização que você odeia, certifique-se de falar com eles primeiro.