Rolando Bonaccorsi

DevOps e a distância entre entregar rápido e entregar estável

Isaac Norvale
Isaac Norvale
5 Min de leitura

Enquanto o mercado avança em integração contínua, a prática de DevOps segue em consolidação nas áreas conduzidas por Rolando Bonaccorsi, engenheiro de computação com MBA executivo. Velocidade de entrega virou argumento central de venda de ferramenta, ainda que a estabilidade daquilo que chega ao usuário raramente apareça com o mesmo destaque nas apresentações comerciais do setor. Entrega frequente e entrega confiável pedem investimentos diferentes.

Frequência alta de implantações, isoladamente, diz pouco sobre a saúde de uma operação de tecnologia. Um time que publica dez vezes por semana e gasta metade do tempo corrigindo o que publicou não avançou em relação ao modelo anterior, porque apenas trocou entregas grandes e raras por incidentes pequenos, frequentes e distribuídos ao longo do mês. O usuário final percebe a diferença antes de qualquer painel interno.

O que a frequência de entregas revela?

Entregas menores reduzem o risco associado a cada mudança, na ponderação de Rolando Bonaccorsi. Um pacote pequeno concentra poucas alterações, facilita o diagnóstico quando algo falha e permite reverter sem desfazer semanas de trabalho de várias equipes ao mesmo tempo, vantagem que aparece com clareza durante um incidente em horário de pico. Reversão rápida vale mais que diagnóstico completo no momento da falha.

A frequência, porém, só melhora o resultado quando acompanhada de testes automatizados confiáveis. Publicar rápido sem rede de proteção aumenta a exposição do negócio, porque o erro chega ao usuário antes de qualquer verificação, e a descoberta acaba dependendo do cliente que abre chamado para relatar o comportamento estranho. Cobertura de teste vira, nesse arranjo, condição de segurança operacional.

Estabilidade medida por reversão e reparo

Indicadores consolidados na indústria observam quatro dimensões, sendo duas de velocidade e duas de estabilidade. Frequência de implantação e tempo entre escrever e publicar formam o primeiro par, enquanto tempo de restauração do serviço e taxa de falha em mudanças compõem o segundo, com leitura conjunta obrigatória para evitar conclusão parcial. Um indicador isolado conta história incompleta ao comitê de tecnologia.

Como analisa Rolando Bonaccorsi, Diretor de Operações da Vert Analytics, o segundo par costuma receber menos atenção nas apresentações internas de resultado. Times maduros conseguem melhorar os quatro indicadores ao mesmo tempo, o que contraria a ideia bastante difundida de que velocidade e confiabilidade disputam necessariamente o mesmo espaço. Processos bem desenhados sustentam os dois lados da conta.

Automatizar o caminho, não apenas o código

Esteiras de entrega automatizam compilação, teste e publicação, embora o gargalo real apareça com frequência em etapas manuais de aprovação. Comitês semanais para autorizar mudanças de baixo risco anulam boa parte do ganho técnico obtido com a automação, porque o código pronto aguarda agenda de reunião para chegar à produção. Fila de aprovação transforma investimento técnico em tempo parado.

Conforme informa Rolando Bonaccorsi, especialista em gestão de operações de TI e excelência em serviços, classificar mudanças por risco resolve boa parte do impasse. Alterações padronizadas e reversíveis seguem por caminho automático, e apenas o que envolve risco relevante passa por avaliação humana detalhada, com critério documentado e conhecido por todas as equipes envolvidas. A lista de mudanças padronizadas cresce conforme a confiança aumenta.

Quando velocidade vira dívida operacional?

Pressão por prazo produz atalhos que ninguém registra, nos termos definidos por Rolando Bonaccorsi. Configuração feita direto no ambiente de produção, teste desativado para liberar a entrega e documentação adiada formam um passivo que só cobra juros meses depois, geralmente durante um incidente em fim de semana prolongado. O custo recai sobre quem não participou da decisão original.

A prevenção passa por tornar o passivo visível para quem decide prioridade. Registrar em lista única cada atalho aceito, com responsável e prazo de correção, transforma decisão informal em item de planejamento. Sem registro, a dívida técnica desaparece do radar da liderança e reaparece na forma de indisponibilidade em horário crítico. Reservar parte de cada ciclo para quitar o passivo mantém a conta sob controle.

Compartilhe este artigo