Como desenvolvedor você deveria entender de Ops

Esse post é a tradução de algo que escrevi no dev.to há um tempo atrás.

Então, qual seria o motivo da afirmação do título? No post original eu abruptamente respondo dizendo que é por conta de DevOps, pra em seguida dizer que não é tão simples assim (fica melhor em inglês a “piada”). Alguns diriam que você deveria aprender Ops simplesmente porque sim, fim de papo. Independentemente das suas razões, eu acho que você deveria aprender Ops para ser um desenvolvedor melhor e para impulsionar sua carreira.

Minha visão de DevOps

DevOps não é só Desenvolvimento + Operações… Pense nos objetivos conflitantes que tínhamos para desenvolvedores e para operações “antigamente” (espero que você não esteja lidando com isso hoje em dia): Desenvolvedores eram recompensados por entregar novas funcionalidades e novas mudanças no produto, enquanto operações eram recompensadas por manter tudo estável, vilanizando mudanças que desenvolvedores faziam.

Uma quantidade enorme de metodologias foram criadas, ou emprestadas, para se livrar desse conflito, como Blameless Postmortems e Just Culture . Outro exemplo é Error-Budgeting, que usa SLAs e SLOs (service level agreement e service level objective) para definir quão estável algo deve ser, e também quão instável isso ‘tem’ que ser. Isso deixa tudo claro para os dois lados, corta gastos e encoraja mudanças no ritmo correto.

Essas coisas, juntamente com práticas LEAN, sumarizam os pilares organizacionais e culturais do DevOps. Eles são cruciais, mas frequentemente ignorados por algumas pessoas (pessoas tendem a focar na parte mais técnica do DevOps). Os outros pilares usam automação para se livrar de tarefas repetitivas e aprimorar tomadas de decisão inteligentes, com dados extraídos, monitorando, observando e usando esses dados como guias.

Com isso em mente, eu diria que há muito mais a respeito de DevOps do que somente desenvolvedores saberem Ops.

Então, por que você, sendo um desenvolvedor, precisaria aprender um pouco de Ops, se não é por conta de DevOps? Eu vou te dar quatro razões que respondem essa pergunta numa vibe mais orientada à sua carreira (em vez de orientada à organização - para algo organizacional, por favor leia Production Excellence ). Talvez sua empresa ou a sua posição atual não requisitem esse tipo de conhecimento, mas tê-lo te ajudará a ser um desenvolvedor melhor em geral, te ajudando a escrever serviços melhores e te dando mais “poder”.

1 - Você pode fazer parte de decisões/discussões importantes

Conhecimento de operações pode te abrir muitas portas. Se sua empresa tem um comitê de arquitetura ou algo similar, ter esse tipo de conhecimento pode contribuir bastante para que você faça parte dele, ou te ajudar a trazer coisas para que o comitê discuta. Você passa a poder ajudar em decisões referentes a stack, arquitetura, e até negócios.

Imagine que sua empresa tem um delay considerável nas respostas de alguns de seus serviços. Uma possível solução seria a de re-implementar alguns desses serviços e parte da arquitetura. Todavia, isso pode acabar demandando muito tempo e esforço, não sendo ideal. Uma solução mais adequada poderia ser uma mistura de mudanças de arquitetura de software e de infraestrutura, preferencialmente com menos esforço e menos tempo. Você poderia acabar encontrando uma solução assim tendo esse conjunto de conhecimentos. Em seguida trazer para discussão com os especialistas de cada área.

2 - Você pode escrever serviços melhores

Da mesma forma que você pode passar a oferecer respostas melhores para problemas que possam surgir referentes a arquitetura e código, conhecimento em operações pode te ajudar a prever problemas que estariam prestes a acontecer.

Seu desenvolvimento pode ser modular e focado no que o seu serviço está tentando resolver. Mas a habilidade de visualizar problemas, referentes a como seu serviço interage com outros serviços e com os sistemas que o seguram em pé, é crucial para aplicações com SLOs e SLAs muito altos. Isso faz seus serviços tanto confiáveis quanto disponíveis.

Idealmente, com alguma bagagem de administração de sistemas ou de operações, você também sentirá a necessidade de fazer com que seus serviços sejam “observáveis”. Com operabilidade e observabilidade você faz com que seja possível ter pessoas on call (de sobreaviso) com menos estresse.

3 - Ficar on call (de sobreaviso) pode te fazer escrever sistemas mais tolerantes a falha

Aqui eu não estou falando somente de conhecimento de operações, mas também de experiência de estar on call. Com experiência suficiente nisso, você começa a ver os pontos frágeis e partes mais propensas a falha no seu sistema. Isso começa a te afetar, e de certa forma a te irritar. E quando você retorna para o desenvolvimento de código, isso te influencia a escrever algo mais operável e melhor.

Esse tópico é parecido com o anterior, mas eu acredito que a experiência de estar on call traz algo que só ela pode trazer: empatia por operabilidade de serviço. O item 2 se refere a conhecimento de operações que você consegue adquirir lendo ou escutando outras pessoas. Esse tópico aqui se refere ao conhecimento que você adquire por sua própria experiência e como isso posteriormente te afeta a escrever um código melhor.

4 - Você pode fazer parte de todo o ciclo de vida do seu código

Você pode escrever código e testá-lo; você sabe como aplicar CI/CD nele, e sabe como operá-lo em produção. Você também sabe como “observar” e monitorar tudo. Eu não digo que você estará fazendo tudo isso o tempo todo, mas você tem o conhecimento e idealmente fez isso anteriormente.

Sua empresa não deve (ou não precisa) esperar que todos conheçam todas essas coisas. Mas ter esse conhecimento irá te recompensar imensamente. E por esse motivo, essa busca deve ser encorajada por sua empresa.

E como proceder agora?

Espero que eu tenha te convencido a aprender um pouco sobre operações . Se você não sabe por onde começar, aqui estão algumas opções:

Leitura

Eu gosto do opsschool readthedocs . Tem muitos tópicos nessa wiki que estão sem conteúdo, mas é uma boa lista de assuntos para que você faça pesquisas adicionais na internet e em bibliografias.

Há muitos livros de tecnologias específicas que eu poderia sugerir, mas é melhor que você procure por eles baseado no que sua empresa usa e o que você quer aprender.

Para um conhecimento geral de admnistração de sistemas você pode dar uma olhada em The Practice of Cloud System Administration e UNIX Linux System Administration Handbook.

Para Linux, Linux Programming Interface System Handbook é um ótimo livro. De maneira geral faz mais sentido usá-lo como referência ou consulta.

Para redes você pode ler Computer Networks by Tanenbaum.

Você pode ler essas referências sobre observabilidade: Honeycombio Guide to Achieving Observability e Distributed Systems Observability .

Eu sei que parece muito, mas não se sinta intimidado por tudo isso! Lembre-se, não existe a necessidade de ler tudo. Além do mais, aqui está a melhor forma de aprender um pouco de operações e administração de sistemas:

Just do it! (apenas faça!)

Veja se sua empresa dá a opção de tentar outras posições e vá em frente. Peça por mentoria e tente ficar on call algumas vezes. Se você tem pessoas à sua volta que saibam alguma coisa, conversar com elas e compartilhar conhecimento pode ser a melhor forma de aprender. Contanto que você tenha habilidades sólidas de desenvolvimento, conhecimentos adicionais sobre operações te ajudarão a conquistar muito mais em sua carreira!

Aqui está o post original.