Validar a Migração

Mova o tráfego somente após a passagem dos portões de comportamento, segurança, desempenho, observabilidade e rollback.

Antes da transferência, siga estas etapas de validação:

  1. Repetir eventos capturados e comparar saídas esperadas, erros, códigos de status, cabeçalhos, esquema do corpo, metadados do objeto, gravações downstream, efeitos colaterais, logs e comportamento de alarme.
  2. Execute testes de carga e falha que abranjam a duração de p95/p99, duração máxima, espaço livre na memória, caminhos sensíveis ao início a frio, simultaneidade de pico, atraso ou idade da fila, tempestades de repetição, limites de taxa de downstream e sintomas de capacidade.
  3. Teste payloads malformados, eventos duplicados, mensagens de veneno, indisponibilidade downstream, negação de permissão, rotação de segredo, falha de rede, comportamento de timeout, prevenção de loop e condições de rollback.

Reduza para o OCI Functions

Mova o tráfego somente após a passagem dos portões de comportamento, segurança, desempenho, observabilidade e rollback.

Para passar para o OCI Functions, siga estas etapas:

  1. Confirmar se os portões de validação funcional, de desempenho, de segurança e operacional foram aprovados.
  2. Registre o proprietário da transferência, o proprietário da reversão, os critérios de sucesso, os acionadores de reversão e o tempo de recuperação esperado.
  3. Congelar alterações de aplicativo não relacionadas durante a janela de transferência.
  4. Encaminhe uma parte limitada e observável da carga de trabalho para o OCI Functions quando possível.
  5. Monitore saídas de negócios, erros, timeouts, latência, limitação, backlog e falhas downstream.
  6. Aumentar o tráfego somente após o período de observação acordado.
  7. Interrompa o cutover e execute o plano de rollback se um critério de sucesso necessário falhar.
  8. Comece a próxima onda de migração somente depois que os proprietários do aplicativo e das operações aceitarem os resultados da produção.

Se o roteamento baseado em porcentagem estiver indisponível, limite a exposição inicial por acionador, bloco, fila, região ou outro limite de carga de trabalho controlado.

Validar Após Migração

Confirme se a carga de trabalho migrada atende aos requisitos de arquitetura, comportamento, desempenho, segurança e operações.

Para validar após a migração, siga estas etapas:

  1. A função da carga de trabalho, o inventário de origem, a arquitetura de destino, as alternativas, a classificação de risco, os limites de serviço e o comportamento de chamada de destino são documentados.
  2. Os inventários de acionamento, dependência, segurança, rede e operações estão completos o suficiente para que um revisor reproduza a decisão de destino.
  3. Os eventos capturados produzem códigos de status, cabeçalhos, esquema do corpo, metadados do objeto, gravações downstream, efeitos colaterais, logs e comportamento de erro esperados.
  4. Cada trigger tem testes para formato de payload, repetição, falha, ordenação, comportamento em batch, idempotência, entrega duplicada, roteamento de dead-letter ou falha e mensagens de veneno, quando aplicável.
  5. duração p95/p99, duração máxima, headroom de memória, caminhos sensíveis ao início a frio, simultaneidade de pico, idade de backlog ou fila, contagem de timeout, comportamento de acelerador ou 429 e limites de taxa downstream atendem aos requisitos de carga de trabalho.
  6. Os controles de simultaneidade protegem os sistemas downstream e evitam tempestades de repetição ou crescimento de backlog ilimitado.
  7. As chamadas de serviço permitidas foram bem-sucedidas e os caminhos negados falharam com segurança. Os segredos não estão presentes no código-fonte, imagens, logs, despejos de ambiente, saída de CI, rastreamentos de pilha ou mensagens de erro.
  8. As dependências privadas e externas necessárias podem ser acessadas por meio de caminhos de rede aprovados. Logs, métricas, alarmes, painéis, rastreamentos, runbooks, trigger de rollback, proprietário, etapas, tempo de recuperação esperado e aprovações finais são concluídos antes da movimentação do tráfego.

Sobre Questões e Mitigações Comuns de Migração

Evite essas falhas comuns de projeto, integração e operações de migração.
  • Tratando todas as funções Lambda da mesma forma: classifique cada função por função, trigger, dependências, comportamento de runtime, perfil de tráfego e necessidades operacionais antes de escolher o destino.
  • Escolhendo Funções do OCI muito cedo: valide payload, timeout, memória, dependência, chamada, simultaneidade, rede e ajuste de integração antes de refatorar o código.
  • Supondo que os payloads de evento sejam idênticos: crie um adaptador do handler do OCI e repita os eventos de origem capturados antes de conectar os triggers de produção.
  • Ignorando camadas e dependências nativas: as dependências do pacote na imagem de função ou na imagem base compartilhada do OCI e, em seguida, teste o tamanho da imagem, a inicialização, as bibliotecas nativas e as versões de dependência.
  • A tradução do IAM é muito ampla: mapeie ações de runtime observadas para políticas do OCI de menor privilégio e teste os caminhos negados, não apenas o acesso ao caminho feliz.
  • A semântica da fila ou do fluxo é diferente: design idempotência explícita, repetição, falha parcial, destino da falha, ordenação e tratamento de contrapressão.
  • Loops de causa de eventos de objeto: use prefixos ou filtros de entrada e saída separados e valide o comportamento de criação, atualização, exclusão, repetição, duplicação e prevenção de loop.
  • As operações são adiadas: ative logs, métricas, alarmes, painéis de controle, runbooks, testes de falha e verificações de rollback antes da movimentação do tráfego de produção.