DevOps é o acordo de que quem constrói o software também responde por como ele é publicado e por como se comporta em produção, com a automação fazendo o trabalho repetitivo. Para quem contrata, vale perguntar: o que barra uma versão ruim? Quanto tempo leva para voltar atrás? Quem fica sabendo quando algo quebra? Dá para pedir prova de cada resposta.
O que a definição diz
A AWS define DevOps como a combinação de cultura, práticas e ferramentas que ajuda uma organização a entregar aplicações e serviços mais rápido. A parte cultural é derrubar o muro entre duas equipes que historicamente andavam separadas: desenvolvimento e operações.
A definição não diz que ferramenta comprar. Por isso, na hora de contratar, eu peço prova e ignoro lista de ferramentas. A diferença para SRE e engenharia de plataforma está neste outro artigo, e como medir o resultado, no de métricas DORA. Aqui vai o que eu pediria a quem me vende DevOps. Se quer ver como fazemos, está na página de DevOps.
Quatro coisas que você pode pedir e conferir
Primeiro, um pipeline capaz de barrar uma versão. Peça para ver uma versão que ele já parou. Numa plataforma SaaS de análise de portfólios, toda versão roda uma hora sob observação antes de chegar à produção. Ela passa por smoke tests e checagens de saúde, e uma trava a interrompe se a taxa de erros 5xx (falhas do servidor) sobe.
Segundo, infraestrutura como código com o plano à vista. O plano é a lista do que a ferramenta vai alterar, e alguém precisa lê-la antes de aplicar. Pergunte o que acontece se a mudança destrói alguma coisa. Na nossa infraestrutura, uma mudança que apagaria um recurso que ninguém citou é barrada antes de ser aplicada.
Terceiro, rollback ensaiado, com o tempo e o ambiente onde foi medido. Nessa plataforma o ensaio foi de ponta a ponta: 72 segundos para voltar e 124 para avançar de novo, em desenvolvimento. Rollback em produção não medimos, então não há número para mostrar.
Quarto, produção conferida contra o que foi testado. Como você sabe que o que está no ar é o que passou nos testes? Nossa resposta é fazer o deploy por digest, a impressão digital da imagem exata que saiu do build. Numa plataforma de publicidade com IA que construímos para um cliente, cada release confere o digest que de fato ficou no ar. Na plataforma de análise de portfólios, a primeira versão pelo pipeline novo saiu com as 12 imagens em execução conferidas contra o que havia sido publicado (outubro de 2026).
O que mudou em um cliente
Na plataforma de análise de portfólios, os releases em produção passaram de 1,15 por semana (abril a julho de 2026) para entre 3,7 e 4,0 por semana nos últimos 30 dias, até o começo de outubro. A taxa de falha do pipeline de release caiu de 23% (77 de 334, todo o histórico) para 4% (1 de 25 desde julho de 2026).
Não é mérito só nosso: nos últimos 90 dias atuaram na plataforma um engenheiro de plataforma da Clouditive com um agente de IA, o responsável de DevOps do cliente e cerca de oito engenheiros dele. O resto está no caso completo.
Contratar um engenheiro ou comprar um pacote?
Depende de você conseguir descrever o fim do trabalho em uma página. “Todo push passa por varredura de segredos, checagem de tipos, lint e build, e toda tag de versão é publicada por digest” é um critério de aceite. “Melhorar nosso DevOps” não é.
Com o critério escrito, o pacote de CI/CD e IaC constrói ou refaz o seu pipeline e a sua infraestrutura como código por US$ 4.000 fixos, em 2 semanas. Sem critério, ou para trabalho contínuo, compensa contratar horas de um engenheiro: um sênior sai por US$ 45 a 50 a hora, ou US$ 7.200 a 8.000 por mês com 160 horas, com mínimo de 6 meses. Você entrevista quem vai fazer o trabalho.
Quando ainda não precisa
Um time pequeno, com uma aplicação só numa plataforma gerenciada, raramente precisa de alguém de DevOps em tempo integral. Precisa de duas coisas: uma trava que roda na máquina do engenheiro antes do push (segredos, tipos, lint e build) e versões que saem por tag. É o que usamos nas plataformas que construímos do zero, e cabe num pacote de 2 semanas.
Alguém dedicado passa a fazer falta quando publicar dá medo, demora, ou depende de uma pessoa que lembra os passos de cabeça.
Peça ao seu time que mostre uma versão que o pipeline barrou. Se não existir nenhuma, você já sabe por onde começar, e o serviço de DevOps explica como fazemos.
Fontes
- AWS, “What is DevOps?”, consultada em 8 de outubro de 2026.
- Números da plataforma de análise de portfólios: medição própria, outubro de 2026.