Comment savoir si les affirmations de recouvrement d'un fournisseur du CDC seront justifiées ?

Testez l'état de redémarrage, la mise à jour, la validation, le comportement de relecture, les diagnostics et les limites de récupération avant de choisir une plateforme CDC.

La plupart des démonstrations de CDC montrent que le processus fonctionne comme prévu. Les données circulent. La cible se met à jour. Le tableau de bord reste au vert. Mais une évaluation de la reprise après sinistre d'un CDC doit répondre à une autre question:

Que se passe-t-il lorsque le chemin se brise ?

Les recommandations AWS Well-Architected préconisent de tester la résilience dans des conditions difficiles, dans des environnements aussi proches que possible de la production. Elles mettent en garde contre la conception de la résilience sans vérifier le comportement de la charge de travail en cas de pannes et de surcharges inattendues.*

Une preuve de concept de plateforme, ou POC, donne à votre équipe l'occasion d'observer comment le système se comporte lorsque la réplication prend du retard, s'arrête pendant un traitement actif, perd l'accès immédiat à l'historique source requis ou doit prouver que la cible récupérée est correcte.

L'objectif n'est pas de créer une panne artificielle qui ne se produirait jamais en production. Il s'agit d'évaluer si la plateforme permet une reprise visible, testable et fiable dans des conditions représentatives de votre environnement.

Réponse rapide: Comment tester la récupération du CDC lors d’une preuve de concept ?

Un plan de contrôle pratique de reprise d'activité du CDC devrait tester huit domaines:

1. Visibilité des retards et des arriérés
2. Visibilité de l'état de redémarrage et de récupération
3. Rattrapage historique
4. Rattraper le retard et stagnation de la reprise
5. Diagnostic et preuves de défaillance
6. Validation post-récupération
7. Impact de la relecture et sur les consommateurs en aval
8. limites de récupération et limites de resynchronisation

Pour chaque test, il convient de se demander quelle condition a été introduite, ce que les opérateurs pouvaient observer, l'état de la plateforme, ce qui s'est passé pendant la récupération, les preuves restantes et ce que la plateforme n'a pas pu établir. Chaque conclusion doit être liée à la source, la cible, la topologie, la version, la configuration et le scénario de défaillance testés.

La norme est simple: montrez-nous ce qui se passe lorsque le chemin est interrompu. Ensuite, montrez-nous comment nous pouvons savoir que la récupération a réussi.

Avant la preuve de concept: commencez par identifier les lacunes à tester.

Atteindre ce stade signifie que vous avez probablement déjà déterminé que la reprise mérite une évaluation plus approfondie. Ne répétez pas l'intégralité de l'évaluation de l'état de préparation au sein du POC. Intégrez plutôt les lacunes documentées dans l'environnement actuel au plan de test.

Si ces lacunes n'ont pas été documentées, commencez par vous référer à la question: « Quand un problème de récupération CDC devient-il un problème de plateforme ? » et documentez les lacunes de récupération dans l'environnement actuel avant de définir la preuve de concept.

Définissez ensuite l'environnement que la preuve de concept est censée représenter. Au minimum, documentez:

• Technologies et versions source et cible
• Méthodes de capture et d'application
• topologie de réplication
• taux de transaction normaux et de pointe
• Politiques de journalisation des sources, de journalisation ou d'historique conservé
• Conditions du réseau et de la cible
• Exigences de transformation et de modification de schéma prises en charge
• Objectifs de récupération et scénarios de rechargement ou de resynchronisation inacceptables
• Consommateurs en aval, sensibilité à la relecture et dépendances commerciales

Une démonstration générique fournit des preuves limitées.

La question importante n'est pas: La plateforme prend-elle en charge la récupération ? C'est: Comment la récupération fonctionne-t-elle pour notre source, notre cible, notre configuration, notre charge de travail et nos exigences opérationnelles ?

Des capacités aux preuves

Les noms des fonctionnalités ne constituent pas une preuve. Les tests ci-dessous permettent de passer de la question « Prendrez-vous en charge cette fonctionnalité ? » à « Montrez-nous comment elle fonctionne en cas de besoin de récupération. »

Test POC 1: Faire en sorte que la réplication prenne du retard

Créer une situation contrôlée où la réplication reste active mais ne parvient pas à suivre le rythme de l'activité source. L'objectif est de déterminer si les opérateurs peuvent distinguer un fonctionnement normal, un retard croissant, une tentative de rattrapage en cours et une tentative de rattrapage bloquée.

Demandez au fournisseur de démontrer l'ampleur du retard, la taille et la direction du retard, où se produit le retard, si le traitement progresse et ce qui arrive à l'exposition de l'historique source à mesure que l'écart augmente.

Ce que montre une manifestation forte

L'ampleur et la direction du problème sont toutes deux visibles. Les opérateurs n'ont plus besoin de déduire l'état d'avancement du rétablissement à partir d'un indicateur vert. Ils peuvent déterminer l'écart par rapport à l'objectif, localiser le retard et constater si la situation s'améliore.

Test POC 2: Arrêter la réplication pendant le traitement actif

Introduisez une interruption sécurisée et prise en charge pendant le déroulement des transactions. Un arrêt propre peut démontrer un comportement normal au redémarrage, mais ne reflète pas nécessairement ce qui se produit lors d'un arrêt brutal, d'une interruption réseau, d'une défaillance de la cible ou de tout autre événement réaliste.

Demandez au fournisseur de vous indiquer quel état de redémarrage ou de traitement a été conservé, la signification de chaque marqueur, l'endroit où le traitement devrait reprendre, la limite de transaction applicable et si le travail peut être réessayé ou retraité.

Ce que montre une manifestation forte

Les opérateurs peuvent examiner l'état pertinent avant le redémarrage et comprendre le fonctionnement de la plateforme. Le fournisseur peut distinguer les états de capture source, de traitement, de transport et d'application à la cible, le cas échéant.

Test POC 3: Test de la prise en charge de la récupération historique

Pour la capture des modifications modifiées (CDC) basée sur les journaux, les modifications accumulées peuvent dépendre des journaux actifs, des journaux archivés, des journaux système ou d'autres sources d'historique conservées. Testez la chaîne de dépendances avec le modèle de conservation utilisé dans votre environnement de production.

Demandez au fournisseur d'expliquer quel historique est requis, où il se trouve, qui contrôle sa conservation, comment il est récupéré, si la plateforme peut le traiter directement et où s'arrête la limite de récupération prise en charge.

Ce que montre une manifestation forte

Le fournisseur explique comment la plateforme localise et traite l'historique requis et ce que les opérateurs peuvent surveiller. La réponse est spécifique à la source et à la configuration, et non une affirmation générique selon laquelle la récupération des journaux archivés est prise en charge.

Test POC 4: Créer un rattrapage bloqué

Commencez par rattraper le retard, puis ajustez les conditions relatives à la source, au réseau, à l'application ou à la cible afin que l'écart existant cesse de se réduire ou de s'accroître. Cela permet de vérifier si la plateforme fait la distinction entre l'activité et les progrès réels.

Demandez au fournisseur de vous indiquer l'évolution du carnet de commandes, les taux de traitement et d'application actuels, l'avancement des dossiers, les nouvelles tentatives ou les limitations, l'impact sur la source et la cible, ainsi que la base de toute estimation d'achèvement.

Ce que montre une manifestation forte

La progression et la stagnation du rattrapage présentent des différences notables. Les opérateurs peuvent ainsi observer si l'écart se réduit, se stabilise ou s'aggrave, et les estimations d'achèvement reposent sur les conditions observées plutôt que sur un débit théorique.

Test POC 5: Préserver et analyser les preuves de défaillance

Provoquer une défaillance représentative de la source, du réseau, de la réplication ou de la cible et évaluer les preuves restant disponibles avant et après le redémarrage.

Demandez au fournisseur de démontrer comment les opérateurs enquêtent sur la défaillance, comment le contexte de traitement et les erreurs sont corrélés, combien de temps les preuves sont conservées, ce qui peut être exporté et quelles preuves supplémentaires de la source, du réseau ou de la cible sont encore nécessaires.

Ce que montre une manifestation forte

Les opérateurs peuvent ainsi suivre le traitement en cours par le pipeline, l'évolution du délai ou du débit, le composant à l'origine de l'erreur, l'état du système après l'incident et les mesures de récupération prises. Ces informations précieuses ne disparaissent pas lors du redémarrage du processus.

Test POC 6: Valider la cible récupérée

Un redémarrage réussi prouve que la réplication a repris. Cela ne garantit pas que la cible est complète, à jour et correcte. Il est recommandé d'intégrer les anomalies connues lorsque cela est possible et sans risque, telles qu'une insertion ou une mise à jour manquante, un enregistrement inattendu, un doublon, une suppression manquante, une valeur obsolète, une différence de transformation ou un problème d'ordre lorsque la séquence est importante.

Demandez au fournisseur de démontrer comment les différences entre la source et la cible sont identifiées, quels objets ou fenêtres d'incident peuvent être ciblés, quelles clés et valeurs sont comparées, comment les écarts sont présentés et quelle validation supplémentaire reste à la charge de l'équipe opérationnelle.

Ce que montre une manifestation forte

La plateforme identifie les différences spécifiques et explique clairement ce que la comparaison prouve et ne prouve pas. Un nombre de lignes ou un processus terminé identiques ne constituent pas une preuve universelle d'intégrité.

Test POC 7: Relecture du test et impact sur le consommateur final

Accumulez les modifications pendant une interruption et traitez-les lors de la reprise. Incluez les types d'événements sensibles à la relecture lorsque cela est possible sans risque. La relecture n'est pas systématiquement problématique, mais une relecture invisible ou mal comprise peut l'être.

Demandez au fournisseur de vous montrer la fenêtre de relecture, les enregistrements ou types d'événements concernés, le volume et le débit attendus, le comportement de nouvelle tentative ou de traitement répété, les considérations relatives à l'ordre de commande et les preuves restantes après la mise à jour.

Pourquoi l'idempotence est importante

Une plateforme de réplication ne peut pas rendre idempotente une application de paiement, de notification, d'inventaire ou de flux de travail. Elle peut toutefois fournir suffisamment d'informations aux équipes en aval pour déterminer si la suppression, la déduplication, le séquençage ou l'activation coordonnée est nécessaire.

Ce que montre une manifestation forte

La relecture est visible et attribuable. Les équipes en aval peuvent estimer ce qui arrivera et quand, comprendre si un traitement répété est possible et évaluer si des mesures de protection côté consommateur sont nécessaires.

Test POC 8: Démontrer la limite de récupération

Chaque plateforme CDC présente des situations où un redémarrage ou une mise à jour ne sont pas appropriés. Une resynchronisation ciblée, une resynchronisation plus large ou un rechargement complet peuvent être nécessaires lorsque l'état de récupération est indisponible, que l'historique source requis ne peut être traité, que la cible est incohérente, que des modifications non prises en charge sont survenues ou que la validation révèle des écarts importants.

Demandez au fournisseur d'expliquer quels scénarios prennent en charge le redémarrage, la mise à jour des données historiques, la resynchronisation ciblée, la resynchronisation plus large ou le rechargement, et quelles preuves indiquent aux opérateurs que la procédure de récupération normale ne s'applique plus.

Ce que montre une manifestation forte

La réponse est spécifique, nuancée et adaptée à l'environnement proposé. Définir honnêtement les limites de récupération est un signe de maturité, non de faiblesse.

Documentez ce que le POC a réellement prouvé.

Une preuve de concept rigoureuse doit laisser des traces allant au-delà des captures d'écran, des comptes rendus de réunion et d'une simple déclaration de réussite. Pour chaque scénario, il convient de consigner les conditions du test, les éléments observés, le résultat de la récupération, l'évaluation, les limitations et le suivi nécessaire.

L'objectif n'est pas d'attribuer un score de récupération générique, mais de déterminer si la plateforme a démontré les capacités requises par votre environnement dans les conditions de test.

Utilisez la feuille de travail d'évaluation du point de contact de reprise du CDC . Cette feuille de travail constitue le document de travail pour l'évaluation. Utilisez-la pour:

• Définir la source, la cible, la topologie, la charge de travail, le modèle de rétention et les objectifs de récupération
• Planifiez les huit scénarios de reprise
• Capturez les comportements observables et les preuves retenues
• Capacités d'évaluation: démontrées, partiellement démontrées, non démontrées ou non applicables
• Limitations, dépendances et questions ouvertes relatives aux documents
• Comparez les fournisseurs uniquement dans des conditions équivalentes.
• Appuyez la recommandation finale par des preuves.

Une capacité ne doit pas être qualifiée de démontrée uniquement sur la base de la documentation produit, de supports de présentation ou d'explications verbales. L'évaluation doit refléter un comportement observable et des preuves conservées de la configuration testée.

Notre équipe opérationnelle habituelle pourrait-elle utiliser les éléments de preuve présentés ici pour comprendre la défaillance, gérer le rétablissement et confirmer la situation sans dépendre entièrement du fournisseur ou d'un seul spécialiste interne ?

Erreurs courantes de récupération du CDC POC

Tests en mode nominal uniquement: un test de charge initiale réussi et un test de réplication en régime permanent permettent d’établir les fonctionnalités de base. Ils n’évaluent pas le comportement de reprise. Il est donc nécessaire d’inclure des scénarios de latence contrôlée, d’interruption, de rattrapage, de validation et de limites de reprise.

Utiliser uniquement des arrêts propres: les arrêts propres peuvent ne pas révéler le même état de redémarrage, les mêmes transactions, les mêmes diagnostics ou les mêmes comportements de nouvelle tentative que les interruptions brutales. Tester les conditions de défaillance prises en charge qui reflètent un risque réaliste en production.

Accepter des étiquettes sans définition: des termes tels que « une seule fois », « zéro perte de données », « auto-réparation », « récupération automatique », « rattrapement transparent » et « validation intégrée » peuvent décrire des comportements différents selon les plateformes. Il est nécessaire d’exiger une définition liée à la configuration testée et au scénario de défaillance.

L'état d'avancement d'un processus est interprété comme une preuve de sa reprise: « En cours d'exécution » ne signifie pas « à jour ». « À jour » ne signifie pas « validé ». La validation dans un contexte donné ne garantit pas l'exactitude de tous les aspects du processus.

Ne pas inclure les anomalies connues: si chaque test commence et se termine avec des données correctes, la preuve de concept ne permet pas d’établir la capacité de la plateforme à détecter les problèmes. Incluez les données manquantes, inattendues, supprimées, obsolètes ou dupliquées lorsque cela est possible.

Ignorer les comportements en aval: la récupération ne s’arrête pas à la table cible. Les modifications retardées et rejouées peuvent déclencher des applications, des événements, des notifications, des paiements, des flux de travail ou des décisions en aval.

Ne pas documenter ce qui n'a pas été démontré: une question restée sans réponse ne doit pas être tacitement considérée comme une capacité présumée. Consignez-la comme suit:

Mettez les affirmations de recouvrement à l'épreuve

Une preuve de concept (POC) pour un CDC doit démontrer bien plus qu'une réplication réussie dans des conditions normales. Elle doit montrer ce que les opérateurs voient lorsque le pipeline prend du retard, l'état de récupération après une panne, où le traitement peut reprendre, les éléments dont dépend la récupération historique, comment la progression du rattrapage est mesurée, quelles preuves de diagnostic sont conservées, comment la cible est validée, ce que la relecture implique pour les consommateurs en aval et où s'arrête le chemin de récupération pris en charge.

Appliquez les mêmes tests à chaque plateforme, y compris celle déjà en service dans votre environnement. La capacité de récupération ne doit pas être présumée à partir du nom d'une fonctionnalité ou d'une démonstration soignée. Elle doit être établie par un comportement observable et des preuves documentées.

Montrez-nous ce qui se passe lorsque la voie est interrompue. Puis, montrez-nous comment nous pourrions savoir que le rétablissement a réussi.
 

AWS Well-Architected: Testez la résilience grâce à l’ingénierie du chaos (novembre 2024)