Valider la migration

Déplacez le trafic uniquement après la réussite des portes de comportement, de sécurité, de performances, d'observabilité et d'annulation.

Avant le basculement, suivez les étapes de validation suivantes :

  1. Relancez les événements capturés et comparez les sorties attendues, les erreurs, les codes de statut, les en-têtes, le schéma de corps, les métadonnées d'objet, les écritures en aval, les effets secondaires, les journaux et le comportement des alarmes.
  2. Exécutez des tests de charge et d'échec qui couvrent la durée p95/p99, la durée maximale, la marge de la mémoire, les chemins sensibles au démarrage à froid, la simultanéité maximale, l'ancienneté du carnet de commandes ou de la file d'attente, les tempêtes de nouvelle tentative, les limites de débit en aval et les symptômes de capacité.
  3. Testez les charges utiles mal formées, les événements en double, les messages empoisonnés, l'indisponibilité en aval, le refus d'autorisation, la rotation de clé secrète, la défaillance du réseau, le comportement du délai d'expiration, la prévention des boucles et les conditions d'annulation.

Passage aux fonctions OCI

Déplacez le trafic uniquement après la réussite des portes de comportement, de sécurité, de performances, d'observabilité et d'annulation.

Pour basculer vers OCI Functions, procédez comme suit :

  1. Vérifiez que les points de contrôle de validation fonctionnels, de performances, de sécurité et opérationnels ont réussi.
  2. Enregistrez le propriétaire du basculement, le propriétaire de l'annulation, les critères de réussite, les déclencheurs d'annulation et le temps de récupération attendu.
  3. Geler les modifications d'application non liées pendant la fenêtre de basculement.
  4. Achetez une partie limitée et observable de la charge globale vers OCI Functions si possible.
  5. Surveillez les résultats métier, les erreurs, les délais d'attente, la latence, la limitation, le carnet de commandes et les échecs en aval.
  6. Augmenter le trafic seulement après le passage de la période d'observation convenue.
  7. Arrêtez le basculement et exécutez le plan d'annulation si un critère de réussite requis échoue.
  8. Ne lancez la prochaine vague de migration qu'une fois que les propriétaires de l'application et des opérations ont accepté les résultats de production.

Si le routage basé sur un pourcentage n'est pas disponible, limitez l'exposition initiale par déclencheur, bucket, file d'attente, région ou autre limite de charge de travail contrôlée.

Valider après la migration

Vérifiez que la charge globale migrée répond aux exigences en matière d'architecture, de comportement, de performances, de sécurité et d'opérations.

Pour effectuer une validation après la migration, procédez comme suit :

  1. Le rôle de charge globale, l'inventaire source, l'architecture cible, les alternatives, l'évaluation des risques, les limites de service et le comportement d'appel cible sont documentés.
  2. Les inventaires des déclencheurs, des dépendances, de la sécurité, de la mise en réseau et des opérations sont suffisamment complets pour qu'un réviseur puisse reproduire la décision cible.
  3. Les événements capturés produisent les codes de statut attendus, les en-têtes, le schéma de corps, les métadonnées d'objet, les écritures en aval, les effets secondaires, les journaux et le comportement des erreurs.
  4. Chaque déclencheur comporte des tests de format de charge utile, de nouvelle tentative, d'échec, de tri, de comportement de batch, d'idempotence, de livraison en double, de routage de lettre morte ou d'échec et de messages empoisonnés, le cas échéant.
  5. Durée p95/p99, durée maximale, marge de la mémoire, chemins sensibles au démarrage à froid, simultanéité maximale, ancienneté du carnet de commandes ou de la file d'attente, nombre de délais d'attente, comportement de l'accélérateur ou 429, et limites de débit en aval répondent aux exigences de charge globale.
  6. Les contrôles de simultanéité protègent les systèmes en aval et évitent les pics de nouvelles tentatives ou la croissance du carnet de commandes non limité.
  7. Les appels de service autorisés réussissent et les chemins refusés échouent en toute sécurité. Les clés secrètes ne sont pas présentes dans le code source, les images, les journaux, les vidages d'environnement, la sortie d'intégration continue, les traces de pile ou les messages d'erreur.
  8. Les dépendances privées et externes requises sont accessibles via des chemins réseau approuvés. Les journaux, mesures, alarmes, tableaux de bord, traces, classeurs d'exécution, déclencheur d'annulation, propriétaire, étapes, temps de récupération attendu et approbations finales sont terminés avant le déplacement du trafic.

Questions et atténuations courantes en matière de migration

Evitez ces échecs courants de conception, d'intégration et d'opération de migration.
  • Traiter toutes les fonctions Lambda de la même façon : classez chaque fonction par rôle, déclencheur, dépendances, comportement d'exécution, profil de trafic et besoins opérationnels avant de choisir la cible.
  • Choix de OCI Functions trop tôt : validez la charge utile, le délai d'expiration, la mémoire, la dépendance, l'appel, la simultanéité, la mise en réseau et l'intégration avant de refactoriser le code.
  • En supposant que les données traitées d'événement sont identiques : créez un adaptateur de gestionnaire OCI et réexécutez les événements source capturés avant de connecter les déclencheurs de production.
  • Ignoration des couches et des dépendances natives : dépendances de package dans l'image de fonction OCI ou l'image de base partagée, puis test de la taille de l'image, du démarrage, des bibliothèques natives et des versions de dépendance.
  • La traduction IAM est trop large : mettez en correspondance les actions d'exécution observées avec les stratégies OCI avec le moins de privilèges possible et testez les chemins refusés, et pas seulement l'accès Happy-path.
  • La sémantique de file d'attente ou de flux de données diffère : concevez une idémpotence explicite, une nouvelle tentative, une défaillance partielle, une destination d'échec, un classement et une gestion de la contre-pression.
  • Les événements d'objet provoquent des boucles : utilisez des préfixes ou des filtres d'entrée et de sortie distincts et validez le comportement de création, de mise à jour, de suppression, de nouvelle tentative, de duplication et de prévention des boucles.
  • Les opérations sont reportées : activez les journaux, les mesures, les alarmes, les tableaux de bord, les classeurs d'exécution, les tests d'échec et les vérifications d'annulation avant le déplacement du trafic de production.