Gestão de mudanças: aprovar alterações pelo nível de risco

Operações de TI · 4 min

Tratar todas as alterações da mesma forma cria filas e lotes maiores. Veja como classificar mudanças por risco, pré-autorizar as repetitivas e gerar evidência sem depender de uma reunião semanal.

Gestão de mudanças: aprovar alterações pelo nível de risco

TL;DR

Um circuito único de aprovação pode criar atrasos desnecessários ao tratar da mesma forma alterações com riscos diferentes.
A investigação DORA sobre DevOps associa processos de aprovação mais leves, revisão por pares e automatização a melhores resultados na entrega de software.
Distinguir alterações padrão, normais e de emergência permite concentrar a análise humana onde o risco é maior.
Os registos de aprovação, testes e implementação podem ser gerados pelo próprio fluxo de trabalho, respeitando os requisitos de controlo e segregação de funções.
A transição exige inventário fiável, testes, mecanismos de reversão e revisão contínua dos resultados.

O comité de mudanças tornou-se um ponto de espera

Em muitas organizações, qualquer alteração à infraestrutura ou às aplicações percorre o mesmo circuito: pedido formal, reunião semanal de um comité de aprovação (CAB, Change Advisory Board) e janela de implementação definida. O modelo procura proteger os sistemas em produção, mas nem todas as mudanças apresentam o mesmo nível de risco. A renovação de um certificado, uma alteração de configuração previamente testada e a migração de uma base de dados crítica podem exigir procedimentos de avaliação e aprovação diferentes. Quando todas seguem o mesmo circuito, acumulam-se pedidos, aumenta o tempo de espera e podem surgir implementações agrupadas em lotes maiores. Para quem gere operações de TI, o desafio é adequar os controlos à criticidade e ao impacto de cada alteração, sem comprometer a rastreabilidade.

Mais aprovação formal não significa menos falhas

O programa de investigação DORA (DevOps Research and Assessment), que não deve ser confundido com o regulamento europeu de resiliência operacional digital, analisou esta relação no relatório State of DevOps de 2019. A investigação identificou efeitos negativos dos processos pesados de aprovação externa no desempenho da entrega de software, sem demonstrar que estes se traduzissem numa menor taxa de falhas das alterações. Como alternativa, recomenda aproximar a revisão das equipas que executam o trabalho, recorrendo à revisão por pares e à automatização de testes, verificações e monitorização. Estas conclusões não significam que os comités de mudanças sejam dispensáveis: continuam a ter utilidade na coordenação entre equipas, na comunicação e nas decisões que exigem avaliação do impacto no negócio. A aplicação destas práticas a alterações de infraestrutura deve considerar o risco e os requisitos de controlo de cada organização.

Classificar alterações por risco antes de as aprovar

Uma abordagem comum consiste em distinguir três tipos de alteração. As alterações padrão são repetitivas, de baixo risco e bem documentadas, como determinadas configurações previamente testadas, podendo ser pré-autorizadas desde que sigam um procedimento aprovado e fiquem registadas. As alterações normais exigem avaliação e autorização proporcionais ao risco, idealmente por quem conhece os sistemas e as suas dependências. As alterações de emergência seguem um circuito acelerado, com as autorizações e a revisão posterior previstas no procedimento aplicável. Os critérios de classificação devem ser explícitos e considerar os serviços afetados, a facilidade de reversão, a exposição de dados sensíveis e o histórico de falhas. Uma CMDB atualizada ajuda a identificar outros sistemas que podem ser afetados por uma alteração aparentemente isolada.

A evidência pode ser gerada pelo próprio processo

Uma das razões para manter processos formais de aprovação é a necessidade de demonstrar controlo perante auditores, clientes ou entidades reguladoras. A investigação DORA indica que a revisão por pares, apoiada em automatização, pode contribuir para um processo de entrega fiável, sem depender exclusivamente de aprovações externas. Na prática, cada alteração deve ficar associada a um pedido, à identificação do responsável, às autorizações aplicáveis, aos resultados dos testes e ao registo da implementação. Plataformas de gestão de serviços, ferramentas de automatização e mecanismos de infraestrutura como código podem produzir parte desta evidência de forma automática, desde que os registos sejam fiáveis e os acessos estejam devidamente controlados. Quando parte da operação está entregue a terceiros, por exemplo num contrato de gestão de infraestrutura, as alterações executadas pelo fornecedor devem integrar o processo de gestão de mudanças acordado com o cliente. Os requisitos concretos de evidência e segregação de funções devem ser validados de acordo com as obrigações aplicáveis.

Medir a espera e o resultado de cada alteração

A investigação DORA recomenda analisar a proporção de alterações que exigem aprovação manual antes da entrada em produção, distinguindo-as pelo perfil de risco, bem como o tempo de espera associado às aprovações externas. Estes indicadores devem ser analisados em conjunto com a frequência de alterações que originam incidentes, a necessidade de reversões e o tempo de recuperação. Se as alterações de baixo risco aguardam vários dias por aprovação, sem que o processo acrescente valor proporcional, pode existir margem para simplificação. Por outro lado, se uma categoria apresenta falhas frequentes, a resposta pode passar por reforçar os testes, melhorar os procedimentos de implementação ou rever os mecanismos de reversão, em vez de acrescentar automaticamente mais um nível de aprovação. Uma boa observabilidade dos serviços permite detetar rapidamente degradações após uma alteração e apoiar decisões de reversão com base em dados.

Um processo proporcional exige disciplina e revisão contínua

Aprovar alterações de acordo com o nível de risco pode ajudar a reduzir tempos de espera, evitar implementações agrupadas em lotes maiores e concentrar a atenção humana nas decisões de maior impacto. A transição depende, porém, de condições que nem todas as organizações reúnem à partida: inventário fiável, procedimentos documentados, testes adequados, mecanismos de reversão e registos consistentes. Sem estas bases, a pré-autorização de alterações pode apenas transferir o risco para a operação. Uma evolução gradual, começando pelas mudanças mais repetitivas e revendo periodicamente a sua classificação com base nos resultados, tende a ser mais prudente do que reformular todo o processo de uma só vez. O equilíbrio entre agilidade, segurança e controlo deve ser avaliado caso a caso, em função da criticidade dos serviços, das responsabilidades contratuais e das obrigações aplicáveis.