Tema Entrega & automação no blog UCloud.
Velocidade que a produção não paga
Deploy frequente só é virtude se você detecta regressão rápido e recupera mais rápido ainda. Pesquisas DORA mostram que times de alta performance combinam throughput e estabilidade — não escolhem um em sacrifício do outro. Pipeline verde sem métrica em produção é teatro; board de sprint verde com alerta vermelho segunda de manhã é o cenário clássico do deploy da sexta às 17h.
No caso típico: feature flag ligada em 80% do tráfego, métrica de erro subindo só no segmento novo, mas dashboard agregado “dentro do normal”. Sem correlação deploy ↔ sintoma em menos de uma hora, o time debate se é infra ou código enquanto o usuário vê timeout. Governança operacional, aqui, não é PMO segurando botão — é critério de pronto: testes que falham de verdade, observabilidade com labels de versão, rollback ensaiado, runbook atualizado, SLI monitorado por release.
Mudança pequena e frequente ajuda — desde que cada pedaço seja reversível e observável. Canary sem métrica de negócio (taxa de checkout, conclusão de matrícula) só adia a surpresa.
Três camadas que sustentam o ritmo
Pipeline e plataforma. CI que roda teste a cada commit; CD que não depende de herói no fim de semana. Golden paths de platform engineering evitam que cada squad reinvente Jenkinsfile, política de ambiente e padrão de secret. Template de serviço já vem com health check, métricas RED/USE exportadas, e gate de migração de banco revisado.
Operação no loop. SRE e plantão entram cedo quando o serviço é crítico — não só quando já queimou. Error budget informa prioridade de backlog tanto quanto feature: se o budget do trimestre queimou em seis semanas, a próxima sprint não é só “inovação”. Postmortem sem ação rastreável no backlog é ritual vazio. Blameless não significa sem consequência — significa consequência em sistema, não em culpado.
Memória institucional. ADR, runbook curado, mapa contextual: o que o time decidiu no sprint 14 não deveria ser redescoberto no sprint 28 porque alguém saiu. Knowledge Operations entra aqui — não como projeto paralelo, como o que impede a mesma pergunta no chat toda semana e a mesma causa raiz em incidentes repetidos.
Change advisory sem paralisia
CAB tradicional virou piada em muitos lugares porque virou fila de aprovação sem critério. CAB útil responde: qual o blast radius desta mudança? Qual rollback em menos de X minutos? Quem está de plantão? Janela alinhada com pico de negócio? Mudanças standard — deploy de app com flag, patch de segurança com runbook — passam em trilha rápida. Mudanças novel — schema breaking, migração de dados, alteração de rede — exigem revisão expandida.
Em contrato de entrega com a UCloud, documentamos padrão de change por criticidade do sistema. O objetivo não é mais reunião — é menos surpresa em produção.
Métricas que importam além da velocidade
Lead time e deployment frequency são visíveis no board. O que separa maturidade é o par change failure rate e MTTR: quantas mudanças geram incidente ou rollback, e quanto tempo para restaurar serviço. Time que acelera deploy sem acompanhar esses dois números exporta risco para operação — e para o contrato de suporte que herda o caos.
Correlacionar release com incidente exige disciplina mínima: tag de versão em métrica, log estruturado com build ID, anotação em timeline de incidente. Sem isso, retrospectiva vira opinião.
Quando agile vira desculpa
Sinais de alerta que vemos em diagnóstico de entrega: “não dá tempo de teste” como norma; dívida técnica infinita sem quota de capacidade; dependência de pessoa única para deploy; ambiente de staging que não replica integração crítica; documentação tratada como sprint “quando sobrar”. Nenhum é problema de metodologia — é problema de governança operacional mal definida.
Agile com governança não é menos agile. É agile que a produção aguenta repetir toda semana.