Avant de redémarrer, savez-vous ce que la panne a affecté ?

Lorsqu'un pipeline CDC tombe en panne, l'objectif est de rétablir la réplication au plus vite. Mais avant de choisir une stratégie de reprise, l'équipe doit comprendre ce qui a changé pendant l'indisponibilité du pipeline.

Le traitement des données source peut se poursuivre. Les données cibles peuvent devenir obsolètes. Les applications en aval peuvent avoir continué à fonctionner, s'être complètement arrêtées ou avoir pris des mesures compensatoires. L'historique source requis peut encore être disponible, ou le processus de récupération normal peut déjà être en cours de modification.

La question n'est pas seulement: Comment redémarrer ?

La question est la suivante: quels ont été les effets de cette défaillance et quelles sont les conséquences pour le rétablissement ?

Les directives de continuité de la FEMA décrivent l'analyse des processus métier comme la cartographie des flux de travail, des activités, des compétences du personnel, des systèmes, des données et des installations nécessaires à l'exécution d'une fonction essentielle. Cette même approche fondée sur les dépendances est utile pour évaluer les répercussions en aval d'une interruption des activités du CDC.*

Une évaluation de l'impact d'un incident réalisée par le CDC permet d'établir:

• La période et l'état de traitement affectés
• Les données qui n'ont pas atteint la cible
• Les systèmes et processus métier en aval exposés
• Les conditions qui limitent les options de récupération disponibles
• Les questions en suspens qui doivent être résolues ou gérées explicitement

L'objectif n'est pas de retarder la reprise, mais d'éviter de choisir une voie de reprise en se basant sur une vision incomplète de la situation.

Que dois-je faire immédiatement après l'arrêt d'une tâche de réplication CDC ?

Avant de décider de la stratégie de rétablissement, il convient d'identifier les éléments affectés. Une évaluation d'impact d'incident réalisée par le CDC permet de déterminer la période de rétablissement concernée, les données et les utilisateurs finaux exposés, l'ampleur et la gravité de la perte de données qui en résulte, les conditions limitant les options de rétablissement possibles, ainsi que les questions ou les risques à résoudre avant d'aller plus loin.

Ce n'est qu'à ce moment-là que l'équipe pourra choisir une voie de rétablissement fondée sur des preuves plutôt que sur des suppositions.

Réponse rapide: Que doit inclure une évaluation d’impact d’un incident réalisée par le CDC ?

Une évaluation pratique de l'impact d'un incident du CDC devrait répondre à cinq questions:

1. Quelle est la période de récupération concernée ?
2. Quelles données et quels consommateurs en aval ont été exposés ?
3. Quelle est l'ampleur et la signification de l'écart de données qui en résulte ?
4. Quelles sont les conditions qui limitent les voies de récupération disponibles ?
5. Quelles questions sans réponse ou quels risques doivent être résolus ou gérés avant que le recouvrement puisse commencer ?

Les sections suivantes décrivent la démarche employée pour répondre à ces questions. L’objectif n’est pas de cocher une liste d’activités, mais de recueillir suffisamment de données probantes pour choisir une voie de rétablissement appropriée et établir les bases de la validation post-rétablissement.

L'étendue de l'évaluation doit être proportionnelle à la portée et au risque de l'incident. Une interruption circonscrite peut ne nécessiter qu'un examen rapide, tandis qu'une panne complexe impliquant des données critiques, des interventions manuelles ou une exposition importante en aval exigera une investigation plus approfondie.

Définir la fenêtre d'incident

Une fois le dernier point de traitement fiable identifié, définissez la période à couvrir par l'évaluation. La fenêtre d'incident s'étend généralement du dernier point de traitement fiable connu jusqu'à l'état cible ou de rétablissement actuel, en passant par l'interruption. Selon l'incident, cette fenêtre peut inclure:

• La période précédant la détection du problème
• La réplication temporelle a été interrompue ou dégradée.
• Activité de la source poursuivie pendant l'interruption
• Traitement partiel ou tentatives de nouvelle tentative
• Modifications ou interventions du côté cible
• Activité de redémarrage initial ou de rattrapage

Ne présumez pas que le moment où quelqu'un a constaté la défaillance correspond au moment où celle-ci a commencé.

Demander:

• Quand la réplication a-t-elle fonctionné comme prévu pour la dernière fois ?
• À quel moment le traitement a-t-il commencé à ralentir, à dysfonctionner ou à s'arrêter ?
• Quand le problème a-t-il été détecté ?
• La source a-t-elle continué à traiter les transactions ?
• Les opérations de capture, de transport ou de ciblage se sont-elles poursuivies partiellement ?
• Quelqu'un a-t-il tenté de redémarrer ou d'effectuer des modifications de configuration ?
• La personne visée a-t-elle reçu des informations directes ou compensatoires ?
• Quel point représente l'état actuel évalué ?

Pourquoi c'est important

Une interruption de cinq minutes détectée immédiatement diffère d'une interruption de cinq minutes découverte des heures plus tard, lorsque les systèmes en aval continuent d'utiliser des données obsolètes. La durée de l'incident détermine l'objet de l'investigation. Elle sert également de référence pour choisir une stratégie de reprise et valider les données ultérieurement.

Cartographier les données affectées

Tous les tableaux, fichiers, jeux de données ou domaines de données d'un flux de réplication ne présentent pas le même niveau de risque. Commencez par identifier les éléments concernés lorsque la réplication a ralenti ou s'est arrêtée. Déterminez ensuite les modifications réelles survenues pendant l'incident. Pour chaque objet ou domaine de données affecté, tenez compte des points suivants:

Activité de changement

• Des insertions, des mises à jour ou des suppressions ont-elles eu lieu ?
• Quel volume d'activité de changement a été accumulé ?
• Des modifications de schéma prises en charge ont-elles été apportées ?
• Les mêmes enregistrements ont-ils été modifiés plusieurs fois ?
• Des transactions à forte valeur ajoutée ou essentielles à l'activité de l'entreprise étaient-elles en jeu ?

Importance commerciale

• Ces données permettent-elles d'établir des rapports, de réaliser des règlements, de traiter des réclamations, d'effectuer des paiements, de gérer les stocks, le service client, de détecter les fraudes ou tout autre processus critique ?
• Les données sont-elles soumises à des exigences de gouvernance, d'audit ou de réglementation ?
• Quel niveau de détail la cible doit-elle avoir pour une utilisation en aval ?

relations de données

• Plusieurs tables ou fichiers doivent-ils rester synchronisés ?
• La relation en-tête-détail, parent-enfant ou autre dépendance a-t-elle une importance ?
• La récupération d'une partie seulement des données affectées créerait-elle un état incohérent ?

Activité du côté cible

• Un processus a-t-il écrit directement sur la cible ?
• Les enregistrements ont-ils été corrigés manuellement ?
• Les données ont-elles été chargées à partir d'une autre source ?
• Une équipe en aval a-t-elle tenté une solution de contournement ?

Lorsque la cohérence des objets liés est essentielle, regroupez-les en fonction de leurs dépendances. La récupération et la validation doivent refléter les relations importantes pour l'application ou le processus métier, et non un simple ordre alphabétique ou le nombre de lignes.

La question pratique à se poser dans chaque situation: « Quelles sont les données les plus importantes dans cet incident, et quelles relations doivent être préservées pendant la phase de rétablissement ? »

Appliquer la même réponse à chaque tableau peut entraîner une perte de temps sur des données à faible risque, tout en négligeant un petit nombre de dépendances critiques.

Évaluer l'exposition en aval

Une panne du CDC n'affecte pas uniquement le processus de réplication. Si la source continue de fonctionner, les applications en aval peuvent rester disponibles, même si leurs données deviennent de plus en plus obsolètes. D'autres consommateurs peuvent cesser complètement de fonctionner. Certains peuvent continuer à traiter des informations partielles ou incohérentes. Pour chaque consommateur en aval, documentez:

Ce que le consommateur a vécu

• L'application a-t-elle cessé de recevoir des données ?
• A-t-il continué à fonctionner avec des données obsolètes ?
• N'a-t-elle reçu qu'une partie des informations attendues ?
• Les utilisateurs ont-ils constaté une erreur ou le problème est-il resté caché ?
• Un événement ou une mise à jour attendue n'a-t-elle pas eu lieu ?

Si des mesures compensatoires ont été prises. Lors d'une interruption prolongée, les équipes peuvent:

• Correcteur manuel des données cibles
• Charger les données à partir d'une sauvegarde ou d'une source alternative
• Interroger temporairement le système d'enregistrement
• Suspendre un processus métier
• Retraiter les transactions en dehors du flux de travail normal
• Passer outre une décision automatisée

Ces actions sont importantes car elles peuvent modifier la cible ou créer des conflits avec les modifications apportées ultérieurement par réplication.

Quel replay ou rattrapage peut déclencher

Certains systèmes en aval peuvent accepter des modifications différées sans effets secondaires. D'autres déclenchent la logique métier lorsqu'un événement survient.

Selon l'application, la relecture des modifications accumulées pourrait déclencher:

• Notifications
• Paiements
• Ajustements d'inventaire
• transitions de flux de travail
• Demandes de service
• Intégrations en aval
• Actions en double

Dans de nombreux contextes, il s'agit fondamentalement d'une question d'idempotence: le consommateur peut-il traiter en toute sécurité un événement rejoué sans créer de conséquences commerciales imprévues ?

Pourquoi c'est important

Même si un pipeline est techniquement récupérable, il peut engendrer un problème métier plus vaste. La source peut être saine et la cible disponible, mais les utilisateurs en aval risquent de prendre des décisions à partir de données obsolètes ou incomplètes, et les opérations de récupération peuvent avoir des conséquences en dehors de la plateforme de réplication.

Quantifier le déficit de données

Une fois la période d'incident et le périmètre affecté compris, décrivez l'écart en des termes utiles aux parties prenantes techniques et commerciales.

Les mesures techniques peuvent inclure:

• Temps écoulé depuis le dernier point de traitement fiable
• Délai de réplication actuel
• Retard de changement ou de transaction
• Insertions, mises à jour et suppressions générées pendant l'intervalle
• Position source comparée à la position de traitement actuelle
• Débit de traitement ou d'application à la cible
• Capacité de rattrapage disponible
• Disponibilité de l'historique des sources pertinentes
• Temps de rattrapage estimé en fonction des performances observées

Il ne faut pas considérer le temps de récupération estimé comme une garantie. Les performances réelles de rattrapage peuvent varier en fonction de l'activité source, de la capacité du réseau, de la pression sur la cible, de la contention de l'infrastructure, du volume de modifications et des charges de travail concurrentes.

Les mesures commerciales peuvent inclure:

• Transactions non encore visibles pour un système en aval
• Des rapports ou des tableaux de bord basés sur des informations obsolètes
• Processus métier retardés ou interrompus
• Décisions ou actions prises sur la base de données obsolètes
• Échéances clients ou réglementaires approchant
• Interventions manuelles réalisées pendant l'intervalle
• Consommateurs nécessitant une prise en charge spéciale pendant la relecture
• Exposition financière, opérationnelle, de service ou de conformité

Les indicateurs techniques bruts aident l'équipe opérationnelle à définir le périmètre de la reprise. Les mesures d'impact sur l'activité permettent aux parties prenantes de comprendre l'importance de l'incident et comment prioriser la reprise.

Pourquoi c'est important

Un arriéré de 100 000 modifications peut être considéré comme routinier dans un environnement et critique pour l’activité dans un autre. L’ampleur de cet écart est importante, tout comme son contenu et les personnes qui en dépendent.

Confirmez en quoi dépend la récupération

Un écart peut être mesurable, même si la méthode de récupération appropriée reste incertaine. Avant d'opter pour un redémarrage, une mise à jour, une resynchronisation ciblée ou une réinitialisation complète, documentez les conditions qui déterminent les options disponibles.

Disponibilité de l'historique source: Déterminez les informations source dont dépend le chemin de récupération pris en charge. Ces informations peuvent inclure:

• Journaux de transactions actifs
• Journaux archivés
• Revues
• Historique des modifications conservé
• État de redémarrage ou de processus
• Positions de journalisation spécifiques à la source
• Informations de récupération gérées par la plateforme

Si l'historique source requis n'est plus immédiatement disponible, vérifiez si les journaux archivés ou d'autres données historiques conservées peuvent être récupérés et traités via une procédure de récupération prise en charge. Si l'historique nécessaire est indisponible, les options de récupération peuvent être plus limitées.

La présence de journaux d'archivage ne signifie pas automatiquement qu'une méthode de récupération particulière est prise en charge. Vérifiez comment la plateforme utilise cet historique pour la source, la cible et la configuration spécifiques.

État cible

Déterminer si la cible demeure dans un état permettant une reprise ultérieure.

Demander:

• La cible était-elle toujours disponible ?
• Des écrits directs ont-ils été effectués ?
• Les enregistrements ont-ils été corrigés manuellement ?
• Les structures ou schémas cibles ont-ils changé ?
• Un processus a-t-il partiellement rechargé ou resynchronisé des données ?
• La cible peut-elle être protégée contre des modifications supplémentaires pendant la récupération, si nécessaire ?

Comportement de relecture du consommateur: pour les consommateurs qui initient une action à la réception des données, déterminer si les événements retardés ou répétés peuvent être traités en toute sécurité.

Demander:

• Le consommateur peut-il reconnaître les événements déjà traités ?
• La relecture peut-elle déclencher des actions en double ?
• Des identifiants de transaction ou des clés métier sont-ils disponibles ?
• Est-il possible de suspendre temporairement les notifications, les paiements ou les flux de travail ?
• L'équipe en charge des consommateurs doit-elle coordonner le processus de recouvrement ?

Objectifs de rétablissement: comparer le temps de rattrapage ou de rétablissement estimé avec les objectifs établis pour les systèmes affectés.

Demander:

• Combien de temps les utilisateurs en aval peuvent-ils tolérer des données obsolètes ?
• Une échéance commerciale, de reporting, de règlement ou client approche-t-elle ?
• Le rattrapage estimé s'inscrit-il dans la fenêtre de reprise prévue ?
• Sinon, quelle autre action ou décision des parties prenantes est nécessaire ?
• S’il n’existe pas d’objectif de reprise formel, documentez le niveau de tolérance de l’entreprise face à l’incident actuel au lieu d’inventer un seuil générique.

Pourquoi c'est important

Connaître l'ampleur de l'écart ne suffit pas à indiquer à l'équipe comment procéder. Elle doit également comprendre les exigences du plan de reprise, vérifier si ces conditions sont toujours réunies et identifier les risques que la reprise elle-même peut engendrer.

Documenter les questions ouvertes et les contraintes de décision

Une évaluation d’impact doit rendre l’incertitude visible, et non la dissimuler. Documentez des questions telles que:

• La position de redémarrage est-elle fiable ?
• L'historique complet des sources requises est-il disponible ?
• La cible a-t-elle reçu des écritures directes ?
• Existe-t-il des correctifs manuels en conflit avec des modifications du code source ?
• Les événements accumulés peuvent-ils être rejoués en toute sécurité ?
• Quelles données nécessitent une validation plus approfondie ?
• Quelles équipes en aval doivent approuver la reprise ?
• Des exceptions sont-elles acceptables dans le cadre d'une récupération contrôlée ?

Les questions ouvertes doivent être attribuées et évaluées en fonction du risque qu'elles présentent. Certaines peuvent entraver le rétablissement du système. D'autres peuvent être gérées comme des exceptions explicites, avec des responsables, des contrôles et des actions de suivi clairement définis.

L'objectif n'est pas de créer une certitude artificielle, mais de s'assurer que la décision de reprise tienne compte des connaissances actuelles, des inconnues persistantes et des hypothèses formulées par l'équipe.

Produire le résumé de l'impact de l'incident du CDC

L’évaluation doit se conclure par un résumé écrit concis qui servira de base à la décision de rétablissement et de référence pour la validation post-rétablissement. Inclure:

Fenêtre d'incident

• Dernier point de traitement fiable connu
• Début de l'incident confirmé ou estimé
• Heure à laquelle le problème a été détecté
• Limite d'évaluation actuelle
• Durée totale écoulée

Données concernées

• Sources et cibles impliquées
• Tables, fichiers, ensembles de données ou domaines de données affectés
• Le volume varie pendant l'intervalle.
• Dépendances pertinentes
• Toute écriture directe sur la cible ou modification manuelle

exposition en aval

• Applications, rapports, API, analyses ou processus affectés
• Que les consommateurs aient cessé de consulter des données, aient continué à utiliser des données obsolètes ou aient reçu des informations partielles
• Toute mesure compensatoire prise
• Risques liés au replay ou au rattrapage

Évaluation des lacunes en matière de données

• Retard actuel ou arriéré
• Effort de rattrapage estimé
• Transactions ou événements commerciaux non encore reflétés en aval
• Délais commerciaux ou conséquences opérationnelles

Contraintes de récupération

• disponibilité de l'historique des sources
• Disponibilité du redémarrage ou de l'état du processus
• Condition cible
• Considérations relatives à la relecture par le consommateur
• fenêtre de récupération prévue
• limitations de la plateforme ou de la configuration

Questions ouvertes

• Que reste-t-il inconnu ?
• Quelles questions influencent la décision de rétablissement ?
• À qui appartient chaque question ?
• Quelles questions entravent la guérison ?
• Lesquelles peuvent être gérées comme des exceptions documentées ?

Décision suivante recommandée

L’évaluation d’impact ne doit pas imposer automatiquement une stratégie de rétablissement spécifique. Elle doit fournir suffisamment d’informations à l’équipe pour déterminer s’il convient de:

• Reprise à partir de l'état enregistré
• Le processus a conservé les modifications historiques
• Poursuivre le rattrapage surveillé
• Comparer les données sources et cibles
• Resynchroniser les données sélectionnées
• Effectuez une resynchronisation ou un rechargement plus large
• Reporter toute action jusqu'à ce qu'une question cruciale soit résolue.
• Transmettre la décision à d'autres responsables techniques ou commerciaux.

Voici à quoi ressemble une évaluation complétée

L'exemple ci-dessous est donné à titre illustratif. Les noms, les valeurs, la charge de travail et les considérations relatives à la récupération sont fictifs et ne constituent en aucun cas un seuil, une architecture ou une procédure de récupération recommandés.

Résumé de l'incident

Pipeline: Flux de réplication des commandes vers l’entrepôt
Dernier point de traitement fiable: Point de contrôle cible confirmé correspondant à 2 h 14
Défaillance détectée: 2 h 17
Évaluation terminée à 4h00 du matin
Écart actuel: environ 1 heure et 46 minutes

Données concernées

exposition en aval

Contraintes de récupération

• L'historique source requis reste disponible.
• La cible contient des mises à jour manuelles d'inventaire effectuées pendant l'interruption.
• Les événements retardés peuvent déclencher des notifications clients pendant la période de rattrapage.
• Les données d'en-tête et de détail de la commande doivent être récupérées et validées ensemble.
• Les propriétaires situés en aval ont besoin d'un plan de communication et de reprise clair.

Questions ouvertes

• Comment concilier les mises à jour manuelles des cibles avec les modifications sources apportées lors de la phase de rattrapage ?
• Les notifications clients retardées doivent-elles être diffusées, supprimées ou traitées séparément ?
• Quelle comparaison permettra de confirmer la cohérence entre l'en-tête et le détail de la commande après récupération ?

Conclusion de l'évaluation

L'état de redémarrage disponible et l'historique source conservé permettent d'évaluer plus en détail une stratégie de récupération. Avant de procéder à la récupération, l'équipe doit s'accorder sur la manière de gérer les mises à jour manuelles des cibles et les notifications différées.

L'évaluation d'impact ne prouve pas que la reprise sera couronnée de succès. Elle établit les conditions que la décision de reprise doit prendre en compte.

Erreurs courantes dans l'évaluation d'impact du CDC

Considérer l'état du pipeline comme le périmètre de l'incident: un processus défaillant ou dégradé peut signaler un état opérationnel ne correspondant pas à la dernière modification correctement enregistrée au niveau de la cible. Utiliser les données les plus fiables disponibles concernant la source, la plateforme et la cible pour définir le périmètre d'évaluation.

Mesurer uniquement le temps d'indisponibilité écoulé ne permet pas de comprendre l'ampleur des modifications apportées à la cible par rapport à la source, les données affectées ni les systèmes en aval qui ont continué de fonctionner. Il est donc essentiel de mesurer à la fois le délai technique et l'exposition des systèmes en aval.

En supposant que le volume de modifications soit égal au temps de récupération: le volume de modifications n’est qu’un facteur parmi d’autres. Le débit observé, la taille des enregistrements, l’activité de la source, la latence de la cible, la pression sur l’infrastructure, la complexité de la transformation et les charges de travail concurrentes influent également sur la durée de rattrapage.

S’arrêter à la couche technique: une évaluation qui documente le backlog et l’état des tâches, mais ignore les utilisateurs finaux, est incomplète. Les conséquences pour l’entreprise déterminent l’urgence, le séquencement, la communication et le niveau de risque acceptable.

Ignorer les actions compensatoires: les correctifs manuels, les chargements alternatifs, les solutions de contournement et les écritures directes sur la cible peuvent modifier les hypothèses de récupération. Documentez-les avant que la réplication ne commence à diffuser les modifications accumulées.

Masquer l'incertitude: les questions sans réponse ne disparaissent pas avec le début du processus de rétablissement. Documentez ce qui demeure inconnu, identifiez les incertitudes qui bloquent l'action et gérez le reste comme des exceptions explicites.

Comment l'évaluation d'impact s'intègre au processus de rétablissement

L'évaluation de l'impact des incidents du CDC se situe entre la détection et la mise en œuvre du rétablissement.

Il prend en charge:

Décision de redémarrage: L’évaluation établit l’étendue de la panne, l’état de traitement disponible, les dépendances de l’historique source, l’état cible et les considérations en aval nécessaires pour choisir un chemin de récupération pris en charge.

Lire la suite: L’erreur la plus dangereuse du CDC en matière de reprise après incident survient après la défaillance

Suivi du rattrapage: L'arriéré prévu, l'activité source, la tolérance en aval et les conditions de rattrapage documentées dans l'évaluation aident l'équipe à interpréter les progrès de la récupération.

Lire la suite: Votre réseau de transmission des données du CDC n’est pas en panne. Êtes-vous sûr qu’il est en bonne santé ?

Validation post-récupération: La période d’incident, les données affectées, les dépendances et les actions compensatoires identifiées dans l’évaluation définissent ce qui doit être validé après la mise à jour.

Lire la suite: Le pipeline fonctionne à nouveau. Peut-on se fier aux données ?

Communication en aval: La cartographie des consommateurs et le résumé d’impact précisent qui a besoin d’informations, quelles données restent confidentielles et quelles preuves justifieront la levée de l’alerte. L’évaluation transforme une défaillance indéfinie en un incident circonscrit, avec un périmètre connu, des contraintes explicites et une voie de rétablissement plus claire.

Utilisez l'évaluation après l'incident.

L'analyse d'impact ne doit pas être abandonnée dès le début de la reprise. Une fois la cible validée et remise en service, il convient de réexaminer l'analyse afin d'identifier les points à modifier avant la prochaine interruption.

• Quelles informations ont été trop longues à trouver ?
• Quelles dépendances étaient manquantes ou mal documentées ?
• Quelles équipes en aval ont pris connaissance du problème trop tard ?
• Quelles décisions dépendaient d'un seul spécialiste ?
• Quelles interventions manuelles ont créé un risque de rapprochement ?
• L'environnement de surveillance a-t-il permis de visualiser les données réelles et leur impact sur l'activité ?
• La plateforme a-t-elle fourni suffisamment d'informations pour le redémarrage, le diagnostic, la mise à jour et la validation ?
• Les processus de conservation ou de récupération de l'historique des sources doivent-ils être modifiés ?
• Quels seuils, manuels d'exploitation, attributions de responsabilité ou procédures de communication doivent être mis à jour ?
• La même défaillance pourrait-elle engendrer à nouveau la même incertitude ?

Un incident isolé peut révéler une faille dans les processus. Des incidents répétés peuvent indiquer un problème plus important lié à la surveillance, au modèle opérationnel, à la formation ou aux capacités de la plateforme.

L'objectif n'est pas seulement de se remettre de cette interruption. Il s'agit de rendre la prochaine réponse plus rapide, plus claire et plus facile à défendre.

Liste de contrôle d'évaluation de l'impact des incidents du CDC

Avant de choisir une voie de récupération, assurez-vous que l'équipe a établi:

• Le dernier point de traitement fiable connu
• La fenêtre d'incident
• Les sources et cibles concernées
• Les données ont évolué pendant l'intervalle.
• Relations et dépendances importantes
• Les systèmes et processus métier en aval exposés
• Que des données obsolètes ou partielles aient été utilisées
• Mesures manuelles ou compensatoires prises
• Retard actuel et arriérés
• Disponibilité de l'historique des sources requise
• Modifications ou contraintes côté cible
• Risques de réutilisation ou de duplication des actions par le consommateur
• Besoins prévus en matière de reprise et de rattrapage
• Questions ouvertes et propriétaires désignés
• Les questions qui bloquent la guérison
• Les exceptions sont gérées explicitement
• Les preuves que la validation post-récupération nécessitera

L’évaluation est prête à éclairer la décision de rétablissement lorsque l’équipe peut expliquer ce qui s’est passé, ce qui a été affecté, ce dont dépend le rétablissement, ce qui reste incertain et ce qui doit être vrai avant que toute action ne soit entreprise.

En résumé

Une panne de CDC ne se définit pas uniquement par la durée d'indisponibilité de la réplication. Elle se définit par les modifications intervenues pendant cette interruption, les personnes affectées, les options de récupération disponibles et les risques que la récupération elle-même peut engendrer.

La question cruciale n'est pas simplement: comment relancer la réplication ?

La question est la suivante: comprenons-nous suffisamment l'impact pour choisir la bonne voie de relance ?

Une bonne évaluation d'impact permet à l'équipe de partager une compréhension commune de:

• Où commence l'incident
• Ce que l'incident a affecté
• Quelles conditions limitent la récupération ?
• Quelles questions restent sans réponse ?
• Quelles preuves seront nécessaires par la suite ?

C’est là toute la différence entre redémarrer sur la base de suppositions et se remettre d’un problème que l’équipe comprend réellement.

FEMA: Analyse des processus métier et analyse d'impact sur l'activité