Capítulo 59 — Gestão de Mudanças

59.1 Objetivo

Este capítulo define o processo pelo qual toda alteração na plataforma — código, configuração, infraestrutura, integrações, banco de dados ou dependências externas — é avaliada, aprovada, executada e auditada antes e depois de chegar ao ambiente de produção.

A gestão de mudanças não é burocracia sobreposta ao desenvolvimento: é o mecanismo que garante que o trabalho produzido pelos ciclos de evolução (Capítulo 55) chegue à produção de forma controlada, com risco avaliado, responsável designado, plano de rollback definido e comunicação adequada aos tenants afetados. Em uma plataforma multi-tenant de missão pública, uma mudança mal gerida não afeta um sistema — afeta dezenas de órgãos e seus cidadãos simultaneamente.

59.2 Contexto

A plataforma opera com cadência contínua de deploy: patches chegam ao pipeline diariamente, releases minor são emitidos a cada quinze dias, e releases major marcam os marcos trimestrais de cada horizonte do roadmap. Esse ritmo é uma vantagem — mudanças menores e mais frequentes são intrinsecamente menos arriscadas do que acúmulos mensais. Mas frequência sem controle produz o resultado oposto: instabilidade contínua e perda de rastreabilidade.

O processo de gestão de mudanças equilibra dois imperativos que se tensionam: velocidade de entrega, exigida pela parceria e pelo roadmap de sessenta meses, e estabilidade operacional, exigida pelos SLAs (Capítulo 53) e pela natureza dos serviços públicos suportados. O equilíbrio é alcançado não pela redução de frequência, mas pela classificação inteligente do risco de cada mudança e pela aplicação de controles proporcionais a esse risco.

O processo descrito neste capítulo está integrado ao pipeline DevSecOps (Capítulo 40), opera sobre a infraestrutura de Kubernetes (Capítulo 38) com estratégias de deploy progressivo, e alimenta os registros de observabilidade (Capítulo 41) e auditoria (Capítulo 45) da plataforma.

59.3 Escopo

O processo cobre todas as mudanças que afetam o ambiente de produção da plataforma, incluindo:

• deploy de nova versão de serviço ou componente de frontend;
• alteração de configuração com efeito sobre comportamento em produção;
• migration de schema de banco de dados;
• atualização de dependências de runtime ou infraestrutura;
• mudança em regras de roteamento, API Gateway ou balanceador;
• atualização de certificados TLS, secrets ou credenciais de integração;
• alteração de configuração de RabbitMQ (filas, exchanges, políticas);
• mudança em políticas de IAM, grupos de segurança ou regras de rede;
• onboarding de novo tenant que implica alteração de configuração de infraestrutura compartilhada.

Não são escopo deste capítulo: mudanças restritas aos ambientes de desenvolvimento e homologação sem promoção a produção; configurações de tenant realizadas por administradores via Módulo de Administração (Capítulo 27) dentro dos limites de parametrização; e operações de suporte que não alteram o código ou a infraestrutura da plataforma.

59.4 Classificação de Mudanças

Toda mudança é classificada em uma de três categorias antes de qualquer aprovação ou execução. A classificação determina o fluxo de aprovação, a exigência de janela e o protocolo de comunicação.

59.4.1 Mudança Padrão

Mudança de baixo risco, procedimento bem estabelecido, executada pelo pipeline de forma automática sem aprovação humana ad hoc. O controle é garantido pela própria estrutura do pipeline — testes automatizados, scanning de segurança, deploy progressivo, rollback automático — não por revisão manual de cada ocorrência.

Exemplos: atualização de imagem de container sem mudança funcional, correção de bug com cobertura de teste adequada, ajuste de variável de ambiente sem impacto em comportamento de negócio, renovação automatizada de certificado TLS.

O registro da mudança padrão é automático: o pipeline gera entrada de auditoria com hash do commit, artefato gerado, ambiente destino, timestamp e resultado. Nenhuma ação humana adicional é necessária para o registro.

59.4.2 Mudança Normal

Mudança que altera comportamento funcional, introduz nova capacidade, atualiza dependência com impacto potencial em integrações, ou modifica configuração de infraestrutura com risco identificado. Requer revisão técnica e aprovação do Change Advisory Board (CAB) antes da execução em produção.

Exemplos: release minor com novas funcionalidades, atualização de versão major de dependência crítica, mudança em schema de banco de dados, alteração de configuração de RabbitMQ, novo endpoint de integração com sistema externo, mudança em regras de autorização do IAM.

Mudanças normais são planejadas com antecedência e executadas em janelas de manutenção definidas. A aprovação do CAB é condição necessária para abertura da janela.

59.4.3 Mudança Emergencial

Mudança que não pode aguardar o ciclo regular de aprovação do CAB por risco ativo — vulnerabilidade crítica em exploração, falha que compromete integridade de dados ou disponibilidade de serviço essencial, ou necessidade de rollback imediato após incidente. O fluxo de aprovação é comprimido, não eliminado.

Exemplos: patch de vulnerabilidade com CVSS ≥ 9.0, rollback após incidente SEV-1, correção de falha que está causando perda de dados em produção.

A mudança emergencial requer aprovação verbal do Platform Operations Manager e do PRODEMGE Platform Officer, documentada formalmente no sistema de gestão de mudanças em até duas horas após o início da execução. O registro retroativo é obrigatório e auditado — a ausência de registro retroativo é tratada como violação de processo, não como exceção tolerada.

59.5 Arquitetura do Processo

O processo de gestão de mudanças opera em cinco fases sequenciais: submissão, avaliação de risco, aprovação, execução e encerramento. As fases se comprimem nas mudanças padrão — onde pipeline automatiza tudo — e se expandem nas mudanças normais e emergenciais.

59.5.1 Fase 1 — Submissão

O autor da mudança registra a Change Request (CR) no sistema de gestão de mudanças, preenchendo:

• descrição técnica da alteração e motivação;
• componentes afetados (serviços, banco de dados, infraestrutura, integrações);
• tenants afetados (todos ou subconjunto);
• classificação proposta (padrão, normal, emergencial);
• plano de execução com etapas sequenciais;
• plano de rollback com critérios de ativação e etapas de reversão;
• evidências de validação em homologação (testes executados, aprovação funcional, scan de segurança);
• janela proposta para execução.

Para mudanças padrão, a submissão é gerada automaticamente pelo pipeline a partir dos metadados do commit e do artefato de build. O autor humano não preenche o formulário — o sistema o faz.

59.5.2 Fase 2 — Avaliação de Risco

Cada CR recebe uma pontuação de risco calculada pela combinação de quatro dimensões:

A pontuação de risco é calculada automaticamente pelo sistema de CR a partir dos campos preenchidos e dos metadados do pipeline. O resultado orienta — mas não substitui — a deliberação do CAB para mudanças normais.

Mudanças com pontuação de risco alto que forem submetidas como padrão são automaticamente reclassificadas e encaminhadas ao CAB com alerta. O autor não pode forçar a classificação padrão em mudança de risco alto.

59.5.3 Fase 3 — Aprovação

Mudanças padrão: aprovação automática pelo pipeline após execução bem-sucedida de todos os gates obrigatórios (testes, scan, build). Nenhuma intervenção humana adicional.

Mudanças normais: aprovação pelo Change Advisory Board em reunião semanal realizada às terças-feiras às 14h (horário de Brasília). O CAB é composto por:

• Platform Operations Manager (Parceira) — presidente da sessão;
• PRODEMGE Platform Officer — representante da PRODEMGE;
• Tech Lead do domínio afetado — representante técnico;
• Security Officer — participação obrigatória para mudanças com impacto em IAM, rede ou dados pessoais.

O CAB delibera sobre cada CR submetida até a véspera (segunda-feira, até as 18h). As decisões possíveis são: aprovação sem ressalvas, aprovação condicional (com ajuste solicitado antes da execução), rejeição com justificativa técnica, ou postergação para o próximo ciclo com solicitação de evidências adicionais.

Aprovações condicionais exigem confirmação do autor antes da abertura da janela. A confirmação registra que as condições foram atendidas e é parte do histórico de auditoria da CR.

Mudanças emergenciais: aprovação por dois responsáveis — Platform Operations Manager e PRODEMGE Platform Officer — por qualquer canal (telefone, mensagem instantânea), com registro imediato no sistema de CR. A ausência de aprovação bipartite documentada impede a classificação da mudança como emergencial e a expõe a processo de revisão disciplinar de processo.

59.5.4 Fase 4 — Execução

A execução de mudanças normais obedece ao processo de release consolidado no Capítulo 51, adaptado ao escopo específico da CR:

CR aprovada pelo CAB
    │
Confirmação de janela com tenants afetados
    │
Snapshot de estado pré-mudança (configurações, métricas de referência)
    │
Execução do plano de mudança (pipeline ou procedimento manual)
    │
Monitoramento intensivo durante a janela (30 min para deploys de código)
    │
    ├─ Métricas dentro do esperado → progressão do rollout
    └─ Anomalia detectada → ativação do plano de rollback
    │
Validação pós-execução (smoke tests, health checks, métricas normalizadas)
    │
Encerramento da janela com confirmação de sucesso ou rollback

Para mudanças que envolvem migration de banco de dados, o processo segue o padrão Expand-Migrate-Contract: a migration de schema é executada em fase separada do deploy do serviço, com validação de compatibilidade retroativa antes de ativar a nova versão. Isso garante que instâncias da versão anterior do serviço continuem operando sobre o schema novo sem falha — eliminando a necessidade de downtime coordenado.

Mudanças emergenciais executam o mesmo fluxo técnico, com a distinção de que a janela é aberta imediatamente após aprovação bipartite, sem aguardar o ciclo regular do CAB.

59.5.5 Fase 5 — Encerramento

Toda CR é encerrada formalmente com registro de:

• resultado da execução (sucesso, rollback parcial, rollback total);
• tempo de execução real versus estimado;
• anomalias observadas durante a janela e como foram tratadas;
• lições aprendidas (obrigatório para CRs com rollback ou anomalia);
• confirmação de monitoramento pós-janela (métricas 24h após a mudança).

O encerramento é feito pelo autor da CR com revisão do Platform Operations Manager. CRs sem encerramento formal em até 48 horas após a janela geram alerta automático.

59.6 Change Advisory Board — Operação

59.6.1 Cadência e Formato

O CAB reúne-se semanalmente. A pauta é fixada na véspera com todas as CRs submetidas no ciclo. Cada CR tem no máximo dez minutos de deliberação — CRs que demandam análise mais extensa são postergadas para a semana seguinte com solicitação de documentação complementar.

A reunião é registrada em ata com decisão explícita para cada CR deliberada. A ata é disponibilizada no repositório de governança em até quatro horas após o encerramento da reunião.

59.6.2 Reunião de Emergência

Quando uma mudança emergencial requer deliberação colegiada — por ambiguidade na classificação ou impacto excepcionalmente amplo —, o Platform Operations Manager convoca reunião de emergência do CAB com participação mínima de dois membros. A decisão é documentada com as justificativas do caráter emergencial e a ausência de tempo hábil para o ciclo regular.

59.6.3 Delegação

Em ausência do representante da PRODEMGE, o PRODEMGE Platform Officer designa substituto com os mesmos poderes deliberativos. A ausência sem designação de substituto atrasa as CRs da semana — não as aprova por omissão. Isso preserva o princípio de que a PRODEMGE tem voz ativa na aprovação de mudanças normais em produção.

59.7 Comunicação de Mudanças

59.7.1 Protocolo para Mudanças com Impacto nos Tenants

Toda mudança normal com impacto perceptível para administradores ou usuários finais segue o protocolo de comunicação estruturado:

Mudanças que afetam apenas infraestrutura sem impacto perceptível para o tenant (ex.: atualização de versão de nó Kubernetes, rotação de secret interno) não requerem comunicação proativa, mas são registradas no histórico de mudanças acessível ao PRODEMGE Platform Officer.

59.7.2 Status Page

A status page pública da plataforma é atualizada com antecedência de 48 horas para janelas de manutenção planejadas. Durante a janela, atualizações de progresso são publicadas a cada 30 minutos. O encerramento é publicado imediatamente após a confirmação de conclusão.

Mudanças emergenciais têm sua execução refletida na status page em tempo real — o operador de plantão atualiza o status antes de iniciar a execução e ao encerrar.

59.8 Rollback

59.8.1 Plano de Rollback Obrigatório

Toda CR de mudança normal deve incluir plano de rollback detalhado antes da aprovação do CAB. CRs sem plano de rollback são rejeitadas automaticamente pelo sistema e não chegam à pauta do CAB.

O plano de rollback especifica:

• critérios de ativação (quais métricas ou eventos disparam o rollback);
• responsável pela decisão de rollback durante a janela;
• etapas técnicas da reversão com comandos ou procedimentos específicos;
• tempo estimado de rollback;
• estado esperado da plataforma após o rollback.

59.8.2 Rollback Automático

Para deploys de código executados via pipeline, o rollback automático é configurado por padrão: se métricas de taxa de erro ou latência ultrapassam os thresholds configurados durante os primeiros 30 minutos após o início do rollout, o Argo CD reverte para a versão anterior sem intervenção humana.

# Critérios de rollback automático — configuração Argo CD Rollouts
analysis:
  templates:
  - templateName: error-rate-analysis
  args:
  - name: service-name
    value: "{{args.service-name}}"
  startingStep: 1

# Template de análise
apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
  name: error-rate-analysis
spec:
  metrics:
  - name: error-rate
    interval: 1m
    successCondition: result[0] <= 0.05  # 5% de taxa de erro
    failureLimit: 2
    provider:
      prometheus:
        address: http://prometheus:9090
        query: |
          sum(rate(http_requests_total{status=~"5.."}[5m]))
          /
          sum(rate(http_requests_total[5m]))

O rollback automático é notificado imediatamente: alerta no canal #incidents do Slack, e-mail ao autor da CR e ao Platform Operations Manager, e entrada de auditoria com a sequência de eventos que disparou a reversão.

59.8.3 Rollback de Banco de Dados

Migrations de banco de dados são a categoria de mudança com rollback mais complexo. O padrão Expand-Migrate-Contract mitiga o risco: colunas e tabelas antigas são mantidas até que o novo código esteja estável em produção, e só então removidas em fase de Contract em ciclo subsequente.

Quando o rollback de uma migration é inevitável, o processo requer:

• script de rollback de schema validado e testado em homologação antes da janela;
• snapshot de banco executado imediatamente antes da migration;
• validação de integridade referencial antes e após o rollback;
• comunicação imediata ao PRODEMGE Platform Officer com análise de impacto em dados.

Migrations irreversíveis por natureza — por exemplo, remoção de coluna após consolidação de dados — são tratadas como mudanças de risco alto e requerem aprovação explícita do PRODEMGE Platform Officer além da aprovação do CAB.

59.9 Janelas de Manutenção

59.9.1 Janelas Planejadas

As janelas de manutenção padrão para mudanças normais são definidas no início de cada mês para o mês seguinte:

• Janela padrão: terças e quintas, das 23h às 02h (horário de Brasília);
• Janela de impacto reduzido: domingos, das 01h às 05h, reservada para mudanças de escopo amplo (release major, migration de banco com escopo abrangente).

A escolha de horários fora do pico de operação dos órgãos é deliberada: os órgãos estaduais operam majoritariamente em horário comercial (08h–18h), e os canais digitais de atendimento ao cidadão têm pico até as 22h nos dias úteis.

59.9.2 Cancelamento de Janela

Janelas canceladas são notificadas com mínimo de quatro horas de antecedência. O cancelamento registra o motivo (problema identificado em homologação, dependência não resolvida, decisão de cautela pelo CAB) e a nova janela proposta.

Cancelamento recorrente de janelas — três ou mais cancelamentos do mesmo CR em sequência — aciona revisão mandatória do escopo da mudança e das evidências de homologação pelo CAB.

59.9.3 Janelas Emergenciais

Mudanças emergenciais não aguardam janela planejada. A comunicação aos tenants afetados é feita com o mínimo de tempo viável — em geral, simultânea ao início da execução, com explicação do caráter emergencial. O registro da janela emergencial no sistema de CR precede o início da execução.

59.10 Auditoria e Rastreabilidade

59.10.1 Registro Completo de Mudanças

Toda mudança em produção gera registro permanente no sistema de gestão de mudanças com:

• identificador único da CR;
• autor e aprovadores com timestamp de cada aprovação;
• classificação e pontuação de risco;
• referência ao commit, tag ou artefato implantado;
• referência ao item de backlog ou incidente que originou a mudança;
• resultado da execução e tempo de janela;
• qualquer anomalia registrada durante a janela;
• confirmação de encerramento.

O registro é imutável após o encerramento — alterações requerem processo de correção com justificativa e aprovação, preservando a trilha original.

59.10.2 Relatório Mensal de Mudanças

O Platform Operations Manager produz relatório mensal de mudanças para o PRODEMGE Platform Officer com:

• total de CRs por categoria (padrão, normal, emergencial);
• taxa de rollback por categoria;
• mudanças emergenciais com análise de causa;
• aderência às janelas planejadas;
• tendência de Change Failure Rate (meta: ≤ 5% das mudanças normais resultam em rollback ou incidente);
• CRs postergadas por mais de dois ciclos com justificativa.

O relatório é insumo direto para a revisão trimestral do processo pelo Comitê de Evolução (Capítulo 55).

59.10.3 Integração com Observabilidade e Auditoria

O sistema de gestão de mudanças envia eventos de início e encerramento de janela para a plataforma de observabilidade (Capítulo 41), permitindo correlação entre mudanças e anomalias de métricas. O timestamp de cada deploy é anotado nos painéis do Grafana, tornando visível a correlação entre mudança e qualquer variação de comportamento dos serviços.

Todos os registros de CR são integrados ao sistema de auditoria (Capítulo 45), com retenção de sete anos conforme política de conformidade da plataforma.

59.11 Feature Flags como Controle Complementar

Feature flags permitem dissociar o deploy do código da ativação da funcionalidade. Esse mecanismo é complementar ao processo de gestão de mudanças, não substituto: o deploy do código com flag desativado segue o mesmo pipeline e processo de aprovação; a ativação do flag segue processo próprio.

A ativação de feature flag em produção é tratada como mudança normal quando afeta comportamento percebido por usuários, e como mudança padrão quando restringe a ativação a um subconjunto de tenants em fase de piloto controlado. O CAB tem visibilidade sobre flags ativos e sobre os critérios de rollout planejados.

Flags criados sem data de remoção planejada são rejeitados pelo processo de revisão de código. A proliferação de flags sem critério de remoção cria dívida técnica de configuração que degrada a manutenibilidade ao longo do tempo.

59.12 Fluxo Completo — Mudança Normal

Desenvolvedor conclui feature em branch
        │
Pull Request: revisão de código + testes automatizados
        │
Pipeline CI: SAST, SCA, testes de integração, build
        │
Deploy em Integration (automático)
        │
Testes de integração automatizados (isolamento multi-tenant verificado)
        │
Deploy em Homologation
        │
Validação funcional com PRODEMGE (≤ 5 dias úteis)
        │
        ▼
Submissão de CR ao sistema de gestão de mudanças
  - Descrição técnica
  - Componentes e tenants afetados
  - Pontuação de risco (calculada)
  - Plano de execução
  - Plano de rollback
  - Evidências de homologação
        │
        ▼
Deliberação do CAB (reunião semanal — terça, 14h)
  ├─ Aprovado sem ressalvas → agendamento da janela
  ├─ Aprovação condicional → ajuste + confirmação → agendamento
  ├─ Rejeitado → retorno ao autor com justificativa
  └─ Postergado → nova submissão com complementação
        │
        ▼
Comunicação aos tenants (7 dias antes da janela)
        │
Lembrete aos tenants (2 dias antes)
        │
        ▼
Abertura da janela de manutenção
  - Snapshot de estado pré-mudança
  - Execução do plano (canary ou blue-green)
  - Monitoramento intensivo (30 min)
  ├─ Sucesso → rollout progressivo até 100%
  └─ Anomalia → ativação do plano de rollback
        │
        ▼
Validação pós-execução (smoke tests, health checks)
        │
Comunicado de encerramento aos tenants
        │
        ▼
Encerramento formal da CR
  - Resultado registrado
  - Lições aprendidas (se rollback ou anomalia)
  - Monitoramento 24h confirmado

59.13 Métricas do Processo

Os indicadores são revisados mensalmente pelo Platform Operations Manager e reportados trimestralmente ao Comitê de Evolução.

59.14 Boas Práticas

A mudança ideal é pequena, reversível e validada exaustivamente antes de chegar ao CAB. Isso não é princípio filosófico — é consequência direta da arquitetura de microsserviços: serviços pequenos com contratos estáveis permitem mudanças de escopo limitado e rollout independente. A gestão de mudanças incentiva ativamente esse padrão: CRs com escopo menor têm pontuação de risco menor, processo de aprovação mais rápido e janelas mais curtas.

Planos de rollback devem ser testados em homologação, não escritos apenas como documentação. Um plano não testado é uma hipótese, não uma garantia. A exigência de evidência de rollback testado nas CRs de risco alto é deliberada e aplicada pelo CAB na revisão.

A distinção entre deploy e ativação — mediante feature flags — é uma ferramenta de redução de risco legítima e encorajada. Deploy de código com flag desativado é intrinsecamente menos arriscado que deploy com ativação imediata: qualquer problema de build ou runtime é isolado antes de qualquer usuário ser afetado.

Janelas de manutenção são reservas de capacidade operacional, não obrigações de execução. Se a validação em homologação revelar problema entre a aprovação do CAB e a abertura da janela, a janela deve ser cancelada. O custo do cancelamento — comunicação aos tenants, reagendamento — é menor que o custo de executar uma mudança com dúvida não resolvida.

59.15 Justificativas Técnicas das Decisões

59.15.1 Classificação Tripartite em vez de Binária

A distinção entre padrão, normal e emergencial — em vez de simplesmente aprovada e não aprovada — existe porque os controles adequados para uma atualização de imagem de container são fundamentalmente diferentes dos controles adequados para uma migration de banco de dados de escopo amplo. Aplicar o mesmo processo a ambas produziria um dos dois erros: burocratizar demais o cotidiano ou subavaliar mudanças críticas. A classificação tripartite com critérios objetivos elimina esse dilema.

59.15.2 CAB Semanal em vez de Contínuo

A reunião semanal fixa concentra a deliberação e permite que os membros do CAB cheguem preparados. Um processo de aprovação assíncrona contínua — onde aprovadores respondem a notificações individuais — produz deliberação fragmentada e sem o benefício da discussão técnica entre pares. A cadência semanal é suficiente para a velocidade de deploy da plataforma; releases minor quinzenais têm tempo de folga em relação ao ciclo semanal do CAB.

59.15.3 Rollback Automático como Controle Primário

O rollback automático baseado em métricas é mais confiável que o rollback manual em janelas noturnas, onde atenção humana e tempo de reação são naturalmente reduzidos. O threshold de 5% de taxa de erro é conservador o suficiente para evitar falsos positivos em picos normais, mas sensível o suficiente para detectar regressões reais antes que se propaguen para 100% do tráfego em uma estratégia canary.

59.15.4 Rejeição Automática de CRs sem Plano de Rollback

A exigência técnica — não apenas formal — de plano de rollback antes da deliberação do CAB garante que o tempo de reunião seja gasto em revisão de conteúdo, não em solicitação de complementação básica. CRs chegam ao CAB completas ou não chegam.

59.16 Trade-offs

A exigência de aprovação bipartite para mudanças emergenciais adiciona fricção em momentos de pressão. O custo desse atrito é menor que o custo do risco oposto: mudanças executadas sob pressão, sem segunda opinião, são a principal fonte de incidentes sequenciais — onde a tentativa de corrigir uma falha introduz outra. A bipartição cria um segundo par de olhos que, em situações de estresse, tem valor desproporcional à fricção que introduz.

A cadência semanal do CAB implica que mudanças normais submetidas após a véspera aguardam até a semana seguinte. Esse atraso médio de seis dias é aceitável para o ritmo de evolução da plataforma — que opera com ciclos de quinze dias para releases minor — e preserva a qualidade da deliberação. Mudanças que não podem aguardar seis dias são candidatas à reclassificação como emergenciais, e a reclassificação levanta a pergunta necessária: por que não havia planejamento suficiente?

O padrão Expand-Migrate-Contract para migrations de banco elimina a necessidade de janelas de downtime coordenado, mas introduz períodos transitórios em que schema antigo e novo coexistem. Esse período transitório exige que o código novo seja retrocompatível com o schema antigo e que o schema novo seja compatível com o código antigo — uma restrição de desenvolvimento que aumenta levemente a complexidade de cada migration. O benefício — zero downtime para o tenant — justifica amplamente essa restrição.

59.17 Alternativas Descartadas e Razões

Aprovação assíncrona por e-mail sem reunião: eliminaria a discussão técnica colegiada que é o principal valor do CAB. Aprovações individuais assincrônicas produzem quórum sem deliberação — cada aprovador decide isolado, sem o benefício de questionar o colega sobre um ponto que observou. Descartada.

Janelas de manutenção diárias: aumentaria a frequência mas reduziria a previsibilidade para os tenants. Os administradores de órgãos precisam de previsibilidade para planejar comunicação interna e para escalar equipes de suporte nas janelas. Janelas previsíveis semanais são operacionalmente superiores a janelas imprevisíveis diárias. Descartada.

Rollback manual obrigatório (sem automação): exigiria operador humano disponível e atento durante toda a janela de canary, aumentando o custo operacional e a dependência de atenção humana sustentada em horários de manutenção noturnos. O rollback automático baseado em métricas é mais consistente e mais rápido. Descartada.

Mudanças padrão sem qualquer registro: eliminaria a rastreabilidade completa do histórico de produção. A impossibilidade de correlacionar uma anomalia com uma mudança recente — porque a mudança "não precisava de registro" — é um anti-pattern de operação. Todas as mudanças têm registro, com grau de formalidade proporcional ao risco. Descartada.

59.18 Riscos e Mitigações

59.19 Benefícios

O controle estruturado de mudanças produz benefícios que se manifestam ao longo do tempo. A baixa taxa de Change Failure Rate — consistentemente abaixo de 5% — constrói confiança nos tenants: administradores de órgãos aprendem que as janelas de manutenção anunciadas terminam como planejado, sem incidentes sequenciais. Essa confiança reduz a resistência a atualizações e acelera a adoção de novas funcionalidades.

A rastreabilidade completa de mudanças simplifica a investigação de incidentes: quando um comportamento anômalo é observado em produção, a correlação com a última mudança executada está disponível imediatamente no sistema de CR e nos painéis de observabilidade. Isso reduz o MTTR de incidentes que têm mudança como causa raiz.

O processo de rollback automático e os critérios explícitos de ativação reduzem a dependência de decisões humanas sob pressão. Operadores de plantão sabem exatamente quando o sistema reverteu automaticamente e quando precisam atuar: a ambiguidade que paralisa equipes em incidentes de madrugada é eliminada por regras definidas com antecedência.

59.20 Impactos Arquiteturais

A gestão de mudanças pressupõe e reforça características arquiteturais específicas da plataforma. Microsserviços com contratos estáveis permitem deploys independentes e rollbacks localizados — uma mudança em um serviço de domínio não exige rollback de toda a plataforma. Essa independência é um requisito arquitetural, não apenas uma conveniência operacional.

O suporte a deploy progressivo — canary e blue-green — é requisito de infraestrutura para a gestão de mudanças funcionar conforme descrito. Plataformas sem suporte a deployment gradual forçam o binário deploy completo ou nenhum deploy — eliminando a capacidade de rollback automático baseado em métricas de tráfego real.

A separação entre deploy e ativação via feature flags requer que a plataforma mantenha infraestrutura de avaliação de flags em runtime sem impacto perceptível de latência. A implementação atual garante avaliação de flags em memória com cache distribuído, preservando o SLA de latência dos serviços.

59.21 Integrações com Outros Componentes

O processo de gestão de mudanças integra-se com:

• Pipeline DevSecOps (Capítulo 40): o pipeline é a implementação técnica da fase de execução para mudanças padrão e para a execução controlada de mudanças normais. Os approval gates do Argo CD implementam o controle de promoção entre ambientes.
• Observabilidade (Capítulo 41): métricas de taxa de erro e latência são a base dos critérios de rollback automático. O sistema de anotação de deploys nos painéis do Grafana é o mecanismo de correlação entre mudança e comportamento.
• Auditoria e Rastreabilidade (Capítulo 45): todos os registros de CR são armazenados no sistema de auditoria com imutabilidade garantida e retenção de sete anos.
• Gestão de Incidentes (Capítulo 51): incidentes com mudança identificada como causa raiz referenciam a CR correspondente. O processo de postmortem analisa se o processo de gestão de mudanças foi seguido e se houve falha de controle.
• Sustentação e Suporte (Capítulo 52): a equipe de suporte é notificada sobre todas as janelas de manutenção planejadas, para que possa antecipar o aumento de chamados no período pós-mudança e escalonar equipe conforme necessário.
• Gestão da Evolução (Capítulo 55): cada item concluído no ciclo de desenvolvimento é candidato a uma CR. O pipeline de mudanças é o mecanismo pelo qual entregas de evolução chegam à produção.

59.22 Relacionamento com Outros Capítulos

59.23 Referências Internas

• ADR-701 — Estratégia de deployment (canary vs. blue-green)
• ADR-702 — GitOps com Argo CD
• ADR-1519 — Cadência de releases
• ADR-1520 — Change Advisory Board — composição e frequência

59.24 Rastreabilidade PRODEMGE

Edital CP 001/2026:

• Exigência de operação contínua com controle de mudanças estruturado ao longo dos sessenta meses de vigência da parceria.
• Manutenção da disponibilidade e integridade dos serviços durante atualizações.

Plano de Negócio (Anexo I):

• Item 3.4.4 — Suporte e Sustentação: o processo de gestão de mudanças é o mecanismo que garante que sustentação e evolução coexistam sem comprometer a estabilidade operacional.
• Item 4.1.19 — Operação: responsabilidade da Parceira pela operação controlada, com supervisão da PRODEMGE via participação no CAB.
• Item 5.11 — Estratégia de Evolução da Plataforma: implantação incremental com rollback, monitoramento contínuo e versionamento controlado são operacionalizados pelo processo deste capítulo.

Funcionalidades (Anexo III) — impacto na pontuação de 60%:

• Bloco 6, Item 6.5 — Registro e auditoria de atividades: todos os registros de CR compõem a trilha de auditoria permanente da plataforma, integrando o sistema de auditoria do Capítulo 45.
• Bloco 6 — Infraestrutura, Segurança e Governança: gestão de mudanças estruturada é capacidade de governança avaliada neste bloco, diretamente evidenciada pela documentação deste processo.

Capacidades (Anexo IV) — impacto na pontuação de 30%:

• Bloco 3, Item 3.2 — Capacidade de operação e sustentação contínua: o processo de gestão de mudanças é evidência direta da capacidade de sustentação estruturada, com SLA preservado durante a evolução contínua.
• Bloco 4, Item 4.1 — Capacidade de evolução contínua da solução: a gestão de mudanças é o mecanismo que torna a evolução contínua segura e rastreável, não apenas tecnicamente possível.

Sustentabilidade (Anexo V) — impacto na pontuação de 10%:

• Bloco 3, Item 3.1 — Estrutura de governança corporativa: o CAB com participação bipartite PRODEMGE-Parceira é evidência de instância decisória formal documentada.
• Bloco 3, Item 3.3 — Segurança da informação e proteção de dados: o controle de mudanças em configurações de IAM, segurança de rede e acesso a dados pessoais é componente da política de segurança da plataforma.

59.25 Resumo

A gestão de mudanças é o processo que converte entregas de desenvolvimento em implantações controladas de produção. O processo classifica cada mudança em padrão, normal ou emergencial, aplicando controles proporcionais ao risco: automatização total para mudanças de baixo risco, aprovação colegiada pelo CAB para mudanças com impacto funcional, e aprovação bipartite comprimida para situações que não admitem espera.

O rollback — automático para código, documentado e testado para banco de dados — é planejado antes de cada janela, não depois de um problema. A comunicação estruturada aos tenants preserva a previsibilidade que órgãos públicos precisam para operar com segurança. E a rastreabilidade completa de toda mudança executada garante que qualquer anomalia possa ser correlacionada com sua causa em minutos, não em horas.

A integração com o pipeline DevSecOps, a observabilidade e a auditoria transforma o processo em um sistema fechado: mudanças entram pelo desenvolvimento, percorrem aprovação, janela e execução, e encerram com registro permanente e monitoramento pós-implantação. Nenhuma mudança em produção fica fora desse ciclo.

59.26 Decisões Arquiteturais — ADR

59.27 Próximo Capítulo

O Capítulo 60 detalha a Gestão de Configuração, cobrindo o controle de configurações de serviços, infraestrutura e integração ao longo do ciclo de vida da plataforma — o complemento estático ao processo dinâmico de gestão de mudanças descrito neste capítulo.