Maturidade DevOps: Um Diagnóstico Prático

"DevOps não é cargo, não é ferramenta, não é time separado. É cultura de colaboração entre quem desenvolve e quem opera."

Ter Docker e um pipeline não diz se uma equipe entrega com segurança. É preciso olhar o caminho entre uma mudança no código e o resultado em produção.

Os cinco estágios abaixo são um roteiro meu para diagnóstico, não uma classificação oficial da DORA. Use-os para encontrar o próximo gargalo, sem transformar os rótulos em competição entre times.

Os 5 Níveis de Maturidade DevOps

---

Nível 1: Inicial (Caos Controlado)

Situação: Deploys manuais, ambientes inconsistentes, "funciona na minha máquina".

Características:

• Deploy é evento traumático
• Rollback é rezar e restaurar backup
• Não há versionamento claro de configurações
• Time de Ops é reativo (apaga incêndio)

O que observar: frequência de entregas, tempo até produção, falhas e tempo de recuperação. Registre a situação atual antes de fixar metas.

Plano de Ação:

1. Versionamento de código (Git) se não tiver
2. Documentar passos de deploy atual
3. Criar primeiro ambiente de staging
4. Automatizar pelo menos o build

---

Nível 2: Repetível (Processos Definidos)

Situação: Processos existem, mas ainda são manuais. Há checkists, mas humanos executam.

Características:

• Deploy segue script ou runbook
• Existe staging, mas nem sempre reflete produção
• Testes existem, mas não bloqueiam deploy
• Monitoramento reativo (alerta quando já quebrou)

O que observar: onde o processo ainda depende de execução manual e quanto tempo uma mudança espera em cada etapa.

Plano de Ação:

1. Implementar CI básico (build + testes automatizados)
2. Criar pipeline de deploy semi-automatizado
3. Paridade entre staging e produção
4. Alertas básicos de infraestrutura

---

Nível 3: Definido (Automação Consistente)

Situação: CI/CD funcionando, IaC (Infrastructure as Code) em uso, práticas padronizadas.

Características:

• Deploy com um clique (ou merge)
• Infraestrutura versionada (Terraform, Pulumi)
• Testes automatizados bloqueiam deploy
• Observabilidade básica (logs, métricas, traces)

O que observar: se a automação reduziu tempo sem aumentar mudanças problemáticas. Compare indicadores do mesmo serviço ao longo do tempo.

Plano de Ação:

1. CD completo (deploy automático em staging, manual em prod)
2. Feature flags para releases graduiais
3. Dashboards de observabilidade
4. Runbooks para incidentes comuns

---

Nível 4: Gerenciado (Métricas Guiam Decisões)

Situação: DORA Metrics acompanhadas, SLOs definidos, cultura de melhoria contínua.

Características:

• Deploys múltiplos por dia
• Rollback automatizado em caso de falha
• SLOs com error budget
• Blameless post-mortems

O que observar: indicadores de entrega e confiabilidade juntos, respeitando o contexto do serviço.

Plano de Ação:

1. Canary deployments ou blue-green
2. SLOs formalizados com error budget
3. Processo de post-mortem estruturado
4. Self-service para desenvolvedores

---

Nível 5: Otimizado (Elite)

Situação: Continuous deployment total, experimentação constante, engenharia de caos.

Características:

• Commit vai para produção em minutos
• Feature flags são usadas onde ajudam a lançar mudanças com controle
• Chaos engineering em uso
• Platform team servindo desenvolvedores

O que observar: capacidade de fazer mudanças pequenas, recuperar falhas e aprender com incidentes. Entregar várias vezes ao dia não é uma meta universal.

---

As métricas DORA hoje

A documentação da DORA descreve cinco métricas para avaliar a entrega de um serviço ao longo do tempo:

1. Frequência de deploy: quantas entregas chegam à produção.
2. Tempo de uma mudança: do commit até a produção.
3. Tempo de recuperação de deploy com falha: quanto leva para restaurar o serviço após uma entrega problemática.
4. Taxa de falha de mudanças: proporção de deploys que exigem intervenção imediata.
5. Taxa de retrabalho de deploy: proporção de deploys não planejados para corrigir incidentes.

O antigo MTTR aparece em muitos materiais, mas a formulação atual distingue o tempo de recuperação de um deploy com falha. Compare cada aplicação com ela mesma e investigue os gargalos em conjunto com o time. Os números isolados não explicam a qualidade do produto.

---

Onde engenharia de plataforma ajuda

Uma plataforma interna pode reduzir trabalho repetido quando vários times enfrentam os mesmos obstáculos:

• Time de plataforma constrói self-service
• Desenvolvedores usam abstrações, não ferramentas brutas
• Padronização com flexibilidade
• Developer Experience como métrica

Leia mais em: O Fim do DevOps Como Conhecemos

---

O Próximo Passo

1. Diagnóstico: Em qual nível você está?
2. Priorização: Qual o próximo passo mais impactante?
3. Execução: Pequenas melhorias consistentes

Quer mapear gargalos de entrega no seu contexto? Fale comigo.

Referência

• DORA: métricas de desempenho de entrega de software