3 problemas que percebi sendo DevOps solo

Salve, amigos(as)!

Há cerca de 1 ano, criei o hábito de documentar os problemas que resolvo no dia a dia. Sempre começo relatando o problema e, conforme vou resolvendo, anoto tudo. Fiz isso porque queria entender como meu cérebro reage aos desafios, como as linhas de raciocínio vão se montando, e também porque acredito que transformar problema em aprendizado tem valor.

Depois de 1 ano fazendo isso, consegui perceber alguns problemas de atuar como DevOps solo. E decidi compartilhar aqui 3 deles:

01 - Explicar o que foi feito

Uma coisa que percebi que atrapalha muito é fazer o time entender as automações. E não é porque eles são obrigados a entender, jamais. O problema é que o time acaba ficando tão dependente delas que, quando quebram, ninguém sabe resolver.

E não é só por falta de documentação, não. Muitas vezes é falta de entendimento mesmo, de prática. Quem já tentou manter documentação sabe que às vezes não podemos nos dar ao luxo de criar guias extremamente detalhados (explicando até o significado dos termos, por exemplo), ainda mais em time pequeno. E, mesmo documentando, nem sempre dá para prever todos os cenários.

Nesse contexto, automatizar é mais fácil do que fazer o time entender o que foi automatizado. E isso traz o medo de estar ausente e alguma automação quebrar... sem falar da possibilidade de a documentação ficar desatualizada.

02 - Fator Ônibus na prática

(Para conhecimento: Fator Ônibus ou "Bus Factor" é um termo do mercado americano. A ideia é: "Quantas pessoas do time precisam ser atropeladas por um ônibus para o projeto morrer?". Se é só você, seu Bus Factor é 1.)

Lembrando que esse post não é uma reclamação, e sim um ponto de vista.

Eu digo isso porque acredito que um dos pontos que mais empurram um profissional para a senioridade é resolver as coisas sozinho. Quando um problema novo aparece, você muitas vezes está sem norte, sem direção... às vezes precisa criar uma solução, arquitetar tudo do zero, e lidar com o excesso de opções é um problema.

Quando você tem mais pessoas na área, as visões se complementam. Surgem opiniões diferentes, pontos que você talvez não esteja percebendo, detalhes que fazem diferença. Isso poupa muito tempo e, às vezes, até dinheiro. O lado bom de estar solo é que isso te força a amadurecer rápido, porque você aprende a decidir com menos apoio e a assumir o peso da escolha.

03 - Apagar incêndio vs. Evitar o fogo

Muito do que fazemos na área é “evitar problema”. Então, o valor aparece pouco até algo quebrar. Normalmente, os resultados de um bom trabalho estão nos 2 minutos reduzidos em uma pipeline, e, pô, isso é tempo pra caramba(rsrs). xD

Só que nem todo mundo percebe isso na hora. Em time pequeno, muitas vezes o foco só vem quando se economiza grana, reduz falha, melhora estabilidade ou tira a dor de cabeça de alguém. Se você não souber mostrar isso, seu papel acaba sendo associado apenas ao do bombeiro que apaga o incêndio, e nunca ao da pessoa que evitou que ele começasse.

Foi uma experiência que me forçou a amadurecer. Entendi que o mercado funciona à base de resultados visíveis e que não basta apenas evitar o problema, você precisa aprender a traduzir a estabilidade do sistema em valor real para o negócio.

Bom, para o post não ficar muito longo, vou encerrar por aqui. Se engajar, trago mais problemas que identifiquei.

Mas me conta aí, você já viveu alguma dessas experiências? Ou alguma outra que faz sentido nesse contexto? xD