O Projeto Phoenix e como se tornar um Capitão DevOps

Boa tarde!

O texto abaixo trata das seguintes coisas:

TL;DR

- Como eu comecei a trabalhar com DevOps - por pura sorte
- Como ler o livro The Phoenix Project me ajudou a evoluir - me trazendo uma perspectiva mais adiante
- Por quê eu escrevi esse tipo de coisa - porque é legal e eu gosto

Intro: Onde eu estava quando eu li esse livro e como eu estou agora

Como tudo nessa área está sujeito a vir com várias opiniões, eu não vou tentar esconder que eu também tenho as minhas, e acho que seria justo antes de mais nada eu dizer o contexto em que eu estou para ter as opiniões que eu tenho.

Eu trabalho como programador desde julho de 2021 numa empresa bem grande. Esse é o meu primeiro emprego e, mesmo que eu tenha começado como estagiário e sem nenhuma experiência prévia profissionalmente, eu fui jogado logo de cara para trabalhar na equipe de DevOps da minha empresa para ajudar a suportar os sistemas e processos que ditam o dia a dia de mais de 600 outros desenvolvedores.

Quando eu entrei no time de DevOps eu nem sabia o que era DevOps de fato (e há controvérsias de que ninguém sabe direito), então aconteceu uma coisa bem extraordinária que foi eu tendo um período de exposição a muita coisa nova em pouco tempo.

Dito isso, eu acabei dando muito certo, porque quanto mais eu aprendia sobre o que era DevOps, mais eu sentia que é exatamente esse o tipo de coisa que me traz uma satisfação absurda de mexer.

Em que momento aconteceu esse estalo de eu realmente começar a dizer "Eu gosto pra pimba do que eu faço"? Eu diria que foi mais ou menos quando eu passei de apenas ouvir o que meus colegas diziam e tentar absorver o máximo de conhecimento daquilo para começar de fato a entender o que estava sendo dito, e poder entender intuitivamente porque as decisões estavam sendo tomadas de determinada maneira.

Para ser mais preciso, esse momento foi mais ou menos quando eu absorvi o que estava escrito no The Phoenix Project.

Uma das coisas que mais me ajudou a expandir meus horizontes

Antes de falar do livro em si, uma tangente.

Eu adoro não saber absolutamente nada sobre algum assunto, talvez é por isso que DevOps e a área de programação no geral me atrai tanto, porque eu nunca vou conseguir saber de tudo, portanto eu nunca vou parar de aprender e pegar novas perspectivas sobre as coisas.

Considero que eu tive muita sorte, de entrar direto numa das áreas com que eu mais me identifiquei. Sei que nem todo mundo tem essa sorte, e eu gostaria de expor outras pessoas a coisas interessantes que talvez elas não soubessem antes.

Eu não cheguei no Phoenix Project sozinho. Eu só comecei a ler ele porque um dos meus colegas me recomendou extensivamente. Esse colega em específico era um dos caras que no começo falava um monte de coisa sobre "Deploys" e "Pipelines" e eu não entendia bulhufas, então tamanha foi minha satisfação quando eu consegui estudar o suficiente para poder manter um diálogo com ele.

Nem todo mundo vai ter esse colega para ficar falando as coisas que você não sabe para você anotar e ir correr atrás. Acho que escrevendo esse tipo de coisa e compartilhando com os outros eu consigo atuar como um mensageiro desse cara, e fazer outras pessoas ficarem menos intimidadas com a área.

Como diria Tim Maia, LEIA O LIVRO

Como eu disse antes, foi muito bom pra mim ler o Phoenix Project logo no começo, porque ali tinha muita coisa que eu não entendia e eu fui anotando para correr atrás ou perguntar para o meu colega que sabia mais do que eu.

Mas por quê ler esse livro especificamente

Consigo listar alguns pontos:

1. Ele não é um livro super técnico. Na verdade ele é uma historinha de como um cara pega uma empresa e transforma ela completamente para melhorar a performance de todo mundo. Eu pessoalmente achei super divertido.
2. Ele te traz uma perspectiva de como as coisas são feitas com e sem as práticas que ele te apresenta, e também conta um pouco de como as coisas chegam na forma em que estão dentro de uma empresa
3. Existem vários personagens que representam tipos de pessoas numa empresa, e depois de ler você vai começar a associar os personagens com gente que você conhece na vida real e se sentir louco
4. Existiam conflitos no livro que me prepararam para lidar com conflitos parecidos no meu próprio trabalho, então quando eu terminei de ler eu já estava menos cru.
5. Se você ler esse livro primeiro, à medida que você for estudando tecnologias específicas você vai se ligar do porquê elas são realmente úteis.

Alguns dos conceitos mais importantes que eu extraí do Phoenix

Acho que um disclaimer que eu tenho que fazer antes dessa parte é que eu li esse livro por volta de fevereiro/março desse ano, então eu estou mais me baseando no que eu me lembro e nas partes específicas que eu destaquei. Vai estar meio fora de contexto, mas acho que dá pra extrair um conhecimento legal.

Tem esse diálogo de uma parte do livro que eles estão prestes a botar pra funcionar um novo processo que vai afetar a empresa inteira (inclusive é parecido com uma situação que eu mesmo enfrentei recentemente).

We spent a lot of blood, sweat, and tears creating our old change management policy, and everyone still blew it off. What makes you think this will be any different?”
I shrug. “I don’t know. But we’ll keep trying things until we have a system that works,

Tem também essa frase que não lembro do contexto mas tem bastante a ver com o diálogo acima.

We need to create a culture that reinforces the value of taking risks and learning from failure and the need for repetition and practice to create mastery.

Acho que essa é uma das mudanças de mentalidade mais legais que eu peguei. Por via das dúvidas deixo aqui meu ALERTA DE OPINIÃO.

Muitas pessoas que começam a trabalhar com programação entram na área porque elas gostam de ver alguma coisa que elas mesmas fizeram funcionar. Infelizmente todas essas pessoas são seres humanos, então muitas vezes elas vão achar que estão entregando algo funcionando quando na verdade existe um edge case super específico que faz tudo explodir.

Isso acontece com todo mundo e a gente não deveria se martirizar por conta disso. Muito pelo contrário, existe o princípio do Fail Fast que diz que você tem que tentar ao máximo fazer as coisas de modo que elas dêem errado o mais rápido possível.

Eu acho isso muito legal porque ao invés de vermos erros humanos como algo que deve ser imperdoável, trazemos a parte de errar para dentro do processo em que fazemos as coisas. Obviamente de nada adianta errar se logo em seguida não pensamos sobre o erro para corrigir o curso, mas existe muita coisa a ser aprendida de erros, então não devemos ter medo de cometê-los se formos conscientes a respeito.

FIM(?) DA OPINIÃO

Outro pedaço de sabedoria é o conceito do Brent e como as coisas ao redor dele são desenvolvidas.

You’re standardizing Brent’s work so that other people can execute it. And because you’re finally getting those steps documented, you’re able to enforce some level of consistency and quality, as well. You’re not only reducing the number of work centers where Brent is required, you’re generating documentation that will enable you to automate some of them.”

O Brent é o cara da infra que não consegue tirar um dia de descanso. A frase only Brent knows é um conceito bastante difundido entre os entendedores, e esse pedacinho acima mostra um pouco de como eles fizeram para remediar a situação e tirar a dependência do Brent.

No caso a solução foi documentar e automatizar processos críticos.

Eu quero focar um pouco mais na parte da documentação de coisas aqui. Eu particularmente gosto bastante de documentação, mas apenas quando ela é usada como uma maneira de distribuir conhecimento entre times. Ter documentação é uma boa rede de segurança, mas quanto mais formas de disseminar conhecimento tiver, mais seguro todo mundo vai estar e menos pessoas vão ter que ser chamadas durante as férias.

Focar em ter algum tipo de documentação dos conceitos importantes para o time é uma forma muito boa de garantir que todo mundo saiba pelo menos o suficiente para trabalhar com a maioria dos processos sobre os quais um time é responsável. Eu já escrevi um textão inteiro sobre documentação e como escrever otimizando apenas para o que é útil que talvez eu compartilhe aqui em outro momento.

A parte que eu acho mais legal desse trecho é a perspectiva de encarar a documentação de processos como um passo para automatizá-los. Sempre é melhor ter um computador fazendo algo repetitivo do que um ser humano seguindo uma documentação de como fazer, justamente porque humanos são muito bons em cometer errinhos que passam despercebidos. Acho que esse é o princípio de muitas coisas que existem no mundo DevOps, particularmente os conceitos de X as Code.

Seguindo para mais um trechinho que eu quis trazer:

“Remember, outcomes are what matter—not the process, not controls, or, for that matter, what work you complete

Esse trechinho é um pouco mais para mim mesmo, porque eu adoro ter orgulho das coisas que eu faço, e eu às vezes perco o foco e, como diz meu chefe, começo a querer fazer a feijoada sem ter terminado o arroz com feijão.

Sempre importante lembrar: sua tarefa como programador não é fazer o código mais tecnicamente impressionante. É fazer o código que mais traga benefícios para os interessados. A definição de "interessados" aqui também é importante, porque o seu eu do futuro também é um dos interessados, então não dá pra sair criando código gambiarra como se não houvesse amanhã porque isso vai voltar para te morder depois.

Outro pensamento que sai dessa parte é que você tem que estar atento à forma com que você faz as coisas. De nada adianta você usar um Super Agile da vida se você passa mais tempo discutindo sobre se um card deveria ser de categoria X ou Y se isso não está te ajudando a entregar resultados melhores mais rápido.

Acho que eu devia ter posto um alerta de opinião aqui também.

Último pedaço que eu quis trazer:

Because of our rapid progress, we decided to shrink the sprint interval to two weeks. By doing this, we could reduce our planning horizon, to make and execute decisions more frequently, as opposed to sticking to a plan made almost a month ago.

O conceito de fazer uma coisinha pequena e parar para pensar sobre o que foi feito é um dos alicerces do Agile, e de muitas práticas do DevOps também. Existem poucas coisas que eu diria que são universais, mas esse lance de pegar feedback sobre o que você está fazendo o mais frequentemente possível te ajuda a fazer decisões com base no que realmente é importante, e diminuir o impacto de decisões erradas. Eu gosto bastante disso.

Inclusive eu quero tentar fazer isso com meus textos aqui também, então vou tentar mantes essas postagens aqui relativamente curtas e fáceis de escrever, mesmo que eu tenha que dividir um assunto em grandes partes. Vamos ver se essa ideia vai funcionar.

Li o livro, e agora?

O próprio Phoenix Project tem uma sessão de "epílogo" chamada Where DevOps Came From, que diz algumas influências que ajudaram a formar o DevOps como conhecemos hoje e que também serviram de inspiração para a historinha do livro. Dessa sessão tem a famosa palestra do Flickr de "10+ deploys a day" e o livro "Continuous Delivery" que eu gosto bastante.

Eu também tenho vários outros recursos que eu uso para estudar (muitos deles livros), e pretendo ir mencionando eles à medida que eu for escrevendo aqui também.

De qualquer forma, espero que se você chegar ao final do Phoenix Project você consiga pelo menos considerar uma perspectiva diferente sobre o seu trabalho com software. Mesmo se você não tiver interesse em DevOps especificamente, ainda acho que é algo que toda pessoa que trabalha com software deveria ler.

E se você estiver interessado em DevOps, eu vou seguir escrevendo coisas e compartilhando aqui, como uma forma de documentar o que eu vou aprendendo e de trazer esses conceitos para mais pessoas.

Acho que é isso, até a próxima!