Olá, recém-chegado. Ouvi falar de ti!
Aprendeste Kubernetes de uma ponta à outra, automatizaste tudo o que podia ser automatizado e geriste pipelines. Estudaste estratégias de CI/CD, ferramentas de IaC e as peculiaridades do YAML como se a tua vida dependesse disso.
Parabéns, conseguiste o emprego de Engenheiro de DevOps!
Deram-te acesso à consola da cloud, ao pipeline de compilação e, possivelmente — horror dos horrores — acesso root em produção (sem pressão).
A maioria dos processos de integração de novos profissionais em DevOps é um cocktail frágil de “lê esta documentação aleatória de 2021”, “pergunta por aí” e “não mexas nesse script, achamos que ainda faz alguma coisa”.
A função raramente é bem definida e as expectativas são absurdamente elevadas, enquanto a documentação é escassa. Além disso… algumas implementações parecem poder despertar uma maldição ancestral.
Embora a entrevista possa ter sido sobre ferramentas, os teus primeiros 90 dias são sobretudo sobre pessoas, processos e prioridades. É aqui que ganhas credibilidade, descobres o que não está documentado e estabeleces os alicerces da infraestrutura em que a tua equipa pode confiar.
Este manual não vai resolver a infraestrutura da tua equipa da noite para o dia. Mas vai ajudar-te a evitar parecer a pessoa que a estragou.
Vozes do terreno
“A lição mais importante que aprendi é a rapidez com que precisas de compreender os teus clientes — ou seja, os programadores — e as suas preferências. Na Pixar, cheguei a configurar um sistema de CI que ninguém utilizava até adicionar alertas por e-mail. Afinal, era assim que gostavam de ser notificados. Noutra empresa, promovemos a adoção de testes através da gamificação, com classificações em direto no escritório. A cultura não é apenas um detalhe de contexto — é o verdadeiro pipeline de entrega.” -Tara Hernandez, VP de Produtividade dos Programadores na MongoDB
A função: DevOps vs. Engenharia de Plataformas vs. SRE
Comecemos pelo aviso eterno: “DevOps é uma cultura, não um título profissional.” Claro, Jan — mas o título profissional continua a existir. E, na prática, isso significa muitas vezes uma combinação de especialista em automação, arquiteto de sistemas, SRE e especialista em ferramentas internas.
Supostamente, és um facilitador, um multiplicador, um campeão da velocidade de entrega. Mas a verdade é que serás a pessoa a quem recorrem quando:
- A compilação falha e ninguém sabe porquê.
- Alguém precisa de um novo ambiente de preparação agora mesmo.
- Está iminente uma auditoria de conformidade e há segredos expostos em texto simples.
- “Devíamos mesmo automatizar isto” transforma-se em “Podes automatizar isto?”.
Engenharia de Plataformas é DevOps com uma marca melhor.
SRE é DevOps com um SLA.
Independentemente do nome que lhe deem, a tua função é fazer com que as coisas escalem, permaneçam disponíveis e não sejam uma porcaria.
Os primeiros 30 dias: não mexas em nada (ainda)
Dica n.º 1: Mapeia a infraestrutura, não apenas a arquitetura
Descobre aquilo por que és responsável: fornecedores de serviços de nuvem, pipelines de CI/CD, orquestração de contentores, gestão de segredos e fluxos de trabalho de incidentes. Cria o teu próprio “mapa da infraestrutura” para visualizares o conjunto tecnológico. Ganhas pontos extra se incluíres ligações para painéis ou scripts ativos.
Have an account? Log In
Dica n.º 2: Descobre o raio de impacto
Todas as organizações de DevOps têm uma configuração do tipo “não mexas nisso”. Faz um inventário de tudo o que possa explodir se for utilizado incorretamente. Isto inclui:
- Scripts de implementação que estabelecem ligação SSH à produção (porquê… porquêêêê?)
- Trabalhos do Jenkins modificados pela última vez em 2019
- Manuais de procedimentos armazenados num PDF
- Ficheiros Terraform que nunca chegaram realmente a ser aplicados
Pergunta: O que não está documentado, mas é crítico? Quem é o responsável? E qual é o plano de reversão se algo falhar?
Dica n.º 3: Assiste a uma implementação — ou, melhor ainda, acompanha uma em direto
Aprenderás mais com uma única implementação (e os seus contratempos) do que com horas de documentação. Que passos são manuais? O que é instável? O que é conhecimento tribal e o que está formalizado? Ainda não estás aqui para apresentar ideias geniais. Estás aqui para recolher informação.
Deverás conseguir seguir um commit desde a integração até à produção de olhos fechados. Compreende:
- O pipeline de CI/CD (onde falha, onde cria estrangulamentos)
- Gestão de segredos (não os coloquem em variáveis de ambiente)
- Fluxos de aprovação (estamos a fazer implementações YOLO a partir do Slack?)
Não implemente código. Limite-se a observar a canalização e a tomar notas.
Vozes do terreno
“Uma boa integração nem sempre é acompanhada por uma boa documentação. Por vezes, a única forma de atravessar o caos é através da curiosidade e da persistência. Quando entrei para uma equipa e me atribuíram um lançamento complexo sem documentação, fiz engenharia inversa de todo o fluxo. Essa experiência ensinou-me: se a documentação está em falta, tornamo-nos na documentação.” –Anant Agarwal, CTO da Aidora
Os primeiros 60 dias: identificar riscos, reduzir a fricção
Dica n.º 4: consiga uma vitória em 5 minutos
Procure tarefas com muita fricção e baixo risco que possa automatizar através de scripts ou modelos. Estas melhorias de “1%” facilitam-lhe a vida e ajudam a criar uma boa relação com a equipa. Basta encontrar uma tarefa que demora mais 5 minutos do que devia e torná-la mais rápida:
- Invólucro de shell para configurar o desenvolvimento local
- Um auxiliar de CLI
- Um módulo Terraform reutilizável
- Script para eliminar ambientes de teste bloqueados
- Notificação do Slack para compilações que falham
Pequenas vitórias criam confiança. A confiança dá-lhe margem para fazer grandes mudanças.
Dica n.º 5: audite o pipeline de CI/CD com extremo rigor
Observe os tempos de compilação. Observe a cobertura de testes. Observe o que falha diariamente. Faça perguntas como:
- Podemos executar os testes em paralelo?
- Isto poderia ter sido evitado mais cedo no CI?
- Estamos a colocar as dependências em cache?
- Estamos a fazer a implementação aquando da integração… ou com fé e uma oração?
Não está aqui para apontar o dedo. Está aqui para tornar o fluxo livre de fricção.
Vozes do terreno
“Numa recente transição de uma aplicação com tráfego elevado, não havia documentação alguma — tivemos de descobrir tudo através de tentativa e erro, rapidamente. O meu conselho? Utilizem a IA de forma intensiva. Desde a análise de registos à engenharia inversa de APIs, a IA ajudou-nos a integrar e estabilizar o sistema mais rapidamente do que alguma vez conseguiríamos sozinhos. Transforma tarefas rotineiras e penosas em progresso real.” –Denis Tiumentsev, engenheiro principal de DevOps na Integro Technologies
Dica n.º 6: crie painéis que as pessoas utilizem realmente e clarifique a responsabilidade
Grafana, Prometheus, Datadog — isso não importa. O que importa é:
- A sua equipa consegue ver a taxa de sucesso das implementações?
- Os alertas significam alguma coisa ou são apenas ruído?
Há alguém a acompanhar as taxas de erro antes de os utilizadores se queixarem? Quem é responsável pelo pipeline de compilação? Pelos gráficos Helm? Pelas configurações de DNS? Os limites de responsabilidade raramente são claros. Faça uma lista das zonas cinzentas e clarifique-as com a sua equipa. Isto evita acusações mútuas mais tarde.
Agora é responsável pela visibilidade. Faça com que conte.
Os primeiros 90 dias: criar confiança através da fiabilidade
Dica n.º 7: implemente algo que aumente a estabilidade
Pode ser:
- Adicionar alertas a um sistema com monitorização insuficiente
- Melhorar a cobertura de testes no ambiente de pré-produção
- Reduzir a instabilidade nos pipelines de CI
- Refatorar um script bash que estava a um rm -rf de uma catástrofe
Não tem de ser algo enorme. Tem de fazer com que a sua equipa respire mais tranquilamente.
Vozes do terreno
“Uma das primeiras vitórias numa nova função de DevOps foi implementar um pipeline centralizado de CI/CD com reversão automatizada e fluxos de trabalho GitOps. Antes disso, a equipa dependia de scripts fragmentados e soluções improvisadas manuais. Isto reduziu os tempos de implementação em mais de 50% e fez-nos passar da resolução constante de problemas para uma fiabilidade proativa. A credibilidade resultante dessa implementação fez uma enorme diferença.” –Divya Parashar, engenheira sénior principal
Dica n.º 8: Escreva um memorando de comentários sobre o “DevEx”
Recolha comentários anónimos ou informais dos programadores sobre os aspetos em que a infraestrutura os atrasa. Apresente o que aprendeu e sugira experiências (por exemplo, desenvolvimento local mais rápido, ambientes efémeros e melhor registo de eventos).
Escreva um documento intitulado “Eis o que aprendi e o que vou fazer a seguir”. Este é um roteiro (e talvez uma lista de conquistas ;). Partilhe-o com o seu responsável e com a equipa.
Crie uma lista “Não me posso esquecer disto”:
- As particularidades estranhas que descobriu
- A infraestrutura sombra que ninguém admite ser responsável por gerir
- O conhecimento tácito que só o Carl, da equipa de TI, parece conhecer
Transforme essa lista em documentos, automatizações ou tarefas — ou mantenha-a à mão. Isto mostra à liderança que está a criar sistemas à prova de falhas.
Vozes do terreno
“Concentre-se nos resultados que pode controlar hoje. Tenha presente por que razão o seu trabalho é importante para os clientes — essa mudança de perspetiva faz toda a diferença durante os primeiros 90 dias.” –Rukmini Reddy, vice-presidente sénior de Engenharia na PagerDuty
More Articles
Dica n.º 9: Escolha um único projeto de grande impacto e comece a defini-lo
A esta altura, já deverá ter informação suficiente para identificar uma área importante a melhorar. Utilize a reta final dos seus primeiros 90 dias para definir o âmbito, divulgá-la e obter alinhamento.
- Migre tarefas instáveis para o GitHub Actions
- Substitua um servidor único por infraestrutura como código
- Crie um caminho recomendado para os programadores criarem novos serviços
Comece por algo pequeno e demonstre o seu valor. Documente tudo.
Considerações finais
Esperemos que, nos seus primeiros 90 dias, consiga estabilizar as coisas, pôr implementações em produção e, mais importante ainda, evitar que os engenheiros gritem para o vazio.
Esses primeiros dias destinam-se a criar tração para o longo prazo. Encontre as falhas e documente como um maníaco!
Vozes do terreno
“Não tem de provar o seu valor num único dia. Respire. Concentre-se primeiro na estabilidade e só depois na velocidade. Faça perguntas aparentemente parvas desde cedo — só se tornam mais difíceis de fazer mais tarde. E lembre-se: um sistema aborrecido que funciona é melhor do que um sistema vistoso que avaria.” –Pablo Gerboles, diretor executivo da Alive DevOps
Não é a sua primeira aventura tecnológica?
Este manual de DevOps faz parte de uma série em crescimento destinada a novos colaboradores que querem causar impacto antes de alguém lhes atribuir a “responsabilidade por sistemas legados”.
👉 Está agora a começar numa função de Engenheiro de Segurança? Nós ajudamo-lo:
Os primeiros 90 dias: edição de cibersegurança
👉 Prefere mais as confirmações de código do que o acesso à raiz? Consulte:
Os primeiros 90 dias: edição para engenheiros de software
E sim — teremos mais funções em breve. Fique atento ou, melhor ainda, subscreva o boletim informativo para não perder a próxima.
