Blog/Artigos · Operações
Tipos de mudança, o CAB que não vira gargalo, change failure rate e como implantar do zero, com ITIL 4 e métricas DORA.
Rabi Nachman ensinou que o mundo inteiro é uma ponte muito estreita, e o essencial é não ter medo. A frase completa importa: não é não atravessar, é atravessar sem paralisar. Mudança em produção é essa ponte. Quase todo incidente grave nasce de uma mudança, e a reação imatura é uma de duas: ou atravessar correndo sem olhar, e cair, ou congelar de medo e nunca entregar nada. GMUD, gestão de mudança, é a disciplina de atravessar a ponte estreita com controle, sem o pânico que paralisa e sem a pressa que derruba.
É um dos fatos mais consistentes da operação: a maioria das interrupções não vem de hardware velho nem de ataque, vem de uma mudança que alguém fez. Um deploy, uma alteração de configuração, um ajuste de infraestrutura. Isso leva dois tipos de organização a dois extremos ruins. A que teve incidentes demais trava tudo com burocracia e comitês, e a entrega morre. A que tem medo de burocracia não controla nada, e o incidente vira rotina.
GMUD, ou change enablement no vocabulário do ITIL 4, existe para o meio-termo maduro: controlar o risco da mudança sem matar a velocidade da entrega. A mudança de nome no ITIL 4, de change management para change enablement, é proposital: o papel não é impedir mudança, é habilitá-la com segurança. A ponte não some, e ninguém deveria atravessá-la de olhos fechados nem se recusar a atravessar; o objetivo é a travessia controlada.
O ITIL 4 classifica a mudança em três tipos, e o segredo de uma GMUD que não vira gargalo está aqui. A mudança padrão é pré-aprovada: baixo risco, procedimento conhecido e repetido, como aplicar um patch de rotina; ela não precisa de aprovação a cada vez, só de um registro. A mudança normal passa por avaliação e aprovação proporcionais ao risco. A mudança emergencial segue um rito acelerado para restaurar serviço no incidente, com aprovação posterior.
O erro que mata a GMUD é tratar tudo como mudança normal, exigindo comitê até para o trivial. Isso cria a fila que faz o time contornar o processo por fora, e aí o controle vira ficção. A maturidade está em maximizar o que é padrão, catalogando as mudanças seguras e repetidas como pré-aprovadas, para que a energia de aprovação se concentre no que é realmente arriscado. Quanto mais coisa é padrão, mais rápido o time entrega e mais foco sobra para a mudança que merece atenção.
O Change Advisory Board, o comitê de mudança, é a peça mais mal usada da GMUD. Na versão disfuncional, é uma reunião semanal onde dezenas de mudanças esperam a bênção de pessoas que não entendem o detalhe técnico e carimbam por medo. Isso não reduz risco, só adiciona atraso e uma falsa sensação de controle. O CAB útil é ágil: avalia risco e prontidão, foca nas mudanças normais de maior impacto e delega o resto.
O DevOps maduro mostrou que aprovação humana em massa não correlaciona com menos falha; o que correlaciona é automação e revisão por pares no fluxo. Por isso a tendência é o CAB deixar de ser gargalo síncrono e virar governança que define políticas e revisa exceções, enquanto a aprovação do dia a dia acontece no pull request, com gate automatizado. O comitê pensa a política; a pipeline aplica. É assim que a travessia fica controlada sem uma reunião no caminho de cada passo.
O controle mora na avaliação de risco e no rollback pronto, não numa reunião no caminho de cada passo.
Montar GMUD do zero sem virar burocracia segue uma ordem. Primeiro, um registro único de mudanças, para ter visibilidade do que muda; sem isso, não há gestão, há adivinhação. Segundo, catalogar as mudanças padrão, o maior volume, para pré-aprovar o seguro e liberar o time. Terceiro, definir avaliação de risco simples e plano de rollback obrigatório para a mudança normal. Só então, quarto, um CAB leve para exceções. Começar pelo comitê é o erro que gera a burocracia que todo mundo odeia.
E a métrica que diz se a GMUD funciona não é quantas mudanças foram aprovadas, é o change failure rate, uma das quatro métricas DORA: a fração de mudanças que causam degradação e exigem correção. Junto com o tempo de restauração, ele revela a verdade que interessa: você está atravessando a ponte com controle ou caindo dela. O objetivo maduro é entregar rápido e com baixo change failure rate ao mesmo tempo, e os dados do DORA provaram que velocidade e estabilidade andam juntas quando o processo é bom, não em troca uma da outra.
GMUD é atravessar a ponte estreita da mudança com controle, sem o medo que paralisa nem a pressa que derruba: tipos de mudança para calibrar o rigor, o padrão pré-aprovado para acelerar, o CAB para política e exceção, e o change failure rate como verdade. Implantada do zero na ordem certa, registro antes de comitê, ela habilita a entrega em vez de travá-la. O ITIL 4 e o DORA dão o método. A IA avalia risco, classifica e mede o CFR, mas decidir como controlar a travessia sem matar a velocidade continua sendo trabalho de quem responde pela operação.
Gerente de Operações, Tecnologia e Infraestrutura (SRE) numa central de registros. Trabalho com tecnologia desde 2009 e com cibersegurança em tempo integral desde 2015, em infraestrutura crítica, fintech e banking. Escrevo sobre o que eu opero: confiabilidade, segurança, governança e IA que passa por gate antes de chegar em produção.
Operaçõesשֹׁרֶשׁ
Incidente apaga o fogo; problema tira a lenha. Sem gestão de problemas, o mesmo incidente volta todo mês. RCA, cinco porquês, Ishikawa e KEDB, com o método do ITIL 4.
Operaçõesחֲצֹצְרֹת
No incidente, a prioridade é restaurar, não achar culpado. Papéis claros, severidade objetiva, comando único e postmortem blameless são o que transformam o caos em processo.
