Planos de Mudança

O que é um Plano de Mudança

O Plano de Mudança é o documento operacional que orienta a execução da mudança. Ele é gerado automaticamente pelo sistema com base nas informações do ativo e do compliance assessment aprovado, e pode ser enriquecido pela IA com procedimentos específicos para o stack tecnológico. A criação está bloqueada até que o governance gate do ativo esteja aprovado.

Criar um plano de mudança

1. Aguarde o Governance Gate ser aprovado

   O botão "Create Change Plan" só aparece quando o compliance assessment vinculado está com status governance_approved e não há findings críticos abertos no Doctor AI.
2. Defina os parâmetros do plano

   Confirme a estratégia de migração, namespace alvo no OKD, cluster de destino e data estimada de cutover.
3. Gere o plano

   Clique em "Generate Plan". O sistema chama o MigrationProcedureGenerator que monta todos os procedimentos, steps e checklists.
4. Revise e aprove

   Um usuário com migration-plans.approve aprova o plano para execução.

Estrutura do plano gerado

Procedimentos (Markdown)

Procedimento	Conteúdo
Migration Procedure	Runbook geral da migração — fases, comandos, verificações
Containerization Procedure	Guia de conteinerização com exemplo de Dockerfile e manifests OKD/K8s
Cutover Procedure	Passo a passo do dia do cutover (janela de manutenção, switch de DNS, validação)
Rollback Procedure	Plano de reversão caso o cutover falhe
Validation Checklist	Checklist de validação pós-migração
Day-2 Operations	Guia de operações Day-2 no Kubernetes/OKD

Fases de migração (Steps)

O plano é dividido em fases, cada uma com steps atribuídos a um papel específico:

Fase	Papel responsável	Atividades típicas
1. Preparation	Platform Engineer / Architect	Análise de requisitos, setup do ambiente OKD, criação de namespace
2. Containerization	Developer	Criação do Dockerfile, build e push da imagem, testes locais
3. Configuration	Platform Engineer / Developer	Criação de ConfigMaps, Secrets, ajuste de variáveis de ambiente
4. Data Migration	DBA	Dump, restore, validação de integridade no banco de destino
5. Deployment	Platform Engineer	Apply dos manifests, configuração de routes/ingress, HPA
6. Testing	Developer / QA	Smoke tests, testes de carga, validação funcional
7. Cutover	Platform Engineer / Operations	Switch de tráfego, atualização de DNS, monitoramento
8. Post-Migration	Operations	Monitoramento 72h, decommission do ambiente legado

Checklists

O sistema gera checklists automáticas organizadas por categoria:

• Pre-cutover — Validações antes de iniciar o cutover
• Cutover — Ações durante a janela de migração
• Post-cutover — Validações após o cutover
• Rollback triggers — Condições que acionam o plano de rollback

Executar o plano

Com o plano aprovado, a equipe pode executar os steps diretamente na plataforma:

• Cada step pode ser marcado como Pending → In Progress → Done
• Steps Blocking interrompem o progresso se não concluídos
• Steps Rollback Trigger ativam automaticamente o plano de rollback se falhar
• Checklists são marcadas individualmente na interface

Campos principais

Campo	Descrição
migration_strategy	Estratégia: rehost, replatform, refactor, re-architect
target_platform	Plataforma alvo (okd, kubernetes, openshift)
target_namespace	Namespace no cluster de destino
target_cluster	Nome do cluster de destino
estimated_cutover_date	Data estimada para o cutover
estimated_effort_days	Esforço total estimado em person-days
estimated_duration_weeks	Duração estimada em semanas
status	draft → approved → in-progress → completed

Gerar novamente

Caso as informações da aplicação mudem, o botão "Regenerate Plan" reprocessa todos os procedimentos e steps. O plano anterior é substituído.