Comment Resolve transforme l’automatisation de la reprise après sinistre en exécution gouvernée

Coordonnez la reprise entre les systèmes d’entreprise grâce à des flux de travail approuvés, des décisions assistées par l’IA, une vérification et une supervision humaine.

Resolve Partner Spotlight 38470
Perspectives des partenaires

Ceci est un contenu sponsorisé de la part de Resolve. Découvrez ici notre approche éditoriale transparente.

En bref :

  • L’automatisation de la reprise après sinistre transforme un plan de reprise documenté en un processus exécutable et répétable.
  • Resolve coordonne les opérations de reprise entre le cloud, le réseau, les identités, l’infrastructure, l’observabilité, l’ITSM et les autres systèmes d’entreprise.
  • Resolve peut interpréter les signaux et le contexte opérationnel afin d’exécuter les procédures de reprise approuvées. Sa piste d’audit offre une visibilité sur l’activité des flux de travail.
  • Le jugement humain reste disponible pour les décisions à haut risque, les exceptions aux politiques et les situations dans lesquelles les éléments disponibles ne justifient pas une réponse automatisée.

Les défis de la reprise après sinistre

La plupart des entreprises disposent de plans de reprise après sinistre. La question la plus difficile est de savoir si ces plans peuvent être exécutés rapidement, de manière cohérente et en toute sécurité lors d’une véritable interruption.

Un plan de reprise peut documenter les dépendances des applications, les emplacements des sauvegardes, les procédures de basculement, les propriétaires des systèmes, les canaux de communication, les objectifs de délai de reprise et les objectifs de point de reprise. Mais un document n’effectue pas la reprise.

Lorsqu’une panne survient, les équipes doivent parfois encore recueillir les diagnostics, déterminer l’étendue de l’interruption, coordonner les responsables de l’infrastructure et des applications, activer les environnements de secours, mettre à jour les configurations réseau, vérifier les services d’identité, restaurer les dépendances, tester l’état de fonctionnement des applications, communiquer la situation et consigner chaque action.

Lorsque ces étapes reposent sur une coordination manuelle, la reprise peut ralentir précisément au moment où le temps et la clarté sont les plus importants.

Resolve transforme un plan de reprise après sinistre en un processus d’exécution gouverné. Il coordonne les actions approuvées dans l’ensemble de l’environnement informatique, préserve le contrôle des modifications apportées à la production, valide les résultats et fait intervenir les collaborateurs lorsque la situation nécessite un jugement.

Comment Resolve gère l’automatisation de la reprise après sinistre 

Exigence de repriseInterpréter les alertes et le contexte de l’incidentApproche manuelle ou déconnectéeLes ingénieurs examinent les informations dans plusieurs outilsResolveInterprète le contexte mis à la disposition du processus
Exigence de repriseSélectionner le chemin de reprise appropriéApproche manuelle ou déconnectéeLes intervenants recherchent la documentation et décident de ce qui doit être exécutéResolveIdentifie le flux de travail approuvé approprié
Exigence de repriseCoordonner les actions entre les systèmesApproche manuelle ou déconnectéeLes équipes passent d’un outil, script ou terminal à l’autre et assurent les transmissionsResolveOrchestre la séquence entre les systèmes connectés
Exigence de repriseContrôler les actions sensiblesApproche manuelle ou déconnectéeLes autorisations et approbations varient selon les outilsResolveLes flux de travail appliquent les autorisations, approbations et contrôles de politique définis
Exigence de repriseGérer les échecs prévisiblesApproche manuelle ou déconnectéeLes intervenants analysent manuellement chaque étape ayant échouéResolveLes flux de travail suivent les chemins définis de gestion des erreurs et d’escalade
Exigence de repriseVérifier la repriseApproche manuelle ou déconnectéeLes équipes effectuent des contrôles distincts après l’exécutionResolveLa validation est intégrée au flux de travail de reprise
Exigence de reprisePréserver la visibilité de l’exécutionApproche manuelle ou déconnectéeLes éléments de preuve sont répartis entre les tickets, les journaux et les messagesResolveLa piste d’audit offre une visibilité sur l’activité des flux de travail

L’approche de Resolve contribue à éliminer la coordination manuelle évitable afin que les spécialistes puissent se concentrer sur les décisions et les exceptions qui nécessitent réellement leur expertise.

Reprise d’une panne d’application critique avec Resolve

Supposons que la surveillance détecte qu’une application essentielle à l’activité est indisponible. L’application dépend d’une infrastructure cloud, d’une base de données, de services d’identité, d’une connectivité réseau et de plusieurs services en aval.

Un outil de reprise ponctuelle peut être capable de restaurer une ressource spécifique. Il peut ne pas coordonner l’ensemble du processus nécessaire pour remettre le service dans un état utilisable.

le concepteur de flux de travail dans Resolve
Exemple de flux de travail conçu dans le concepteur de flux de travail de Resolve.

Resolve fournit la couche d’exécution pour cette reprise de bout en bout.

1. Resolve reçoit le signal d’interruption

Le processus peut commencer par un événement provenant d’une plateforme d’observabilité, une alerte d’infrastructure ou un incident créé dans l’ITSM.

Resolve lance le flux de travail de diagnostic approprié sans attendre qu’un ingénieur copie manuellement les informations entre les systèmes. La piste d’audit offre une visibilité sur l’activité du flux de travail dès le début de la réponse.

2. Le module de résolution assemble le contexte pertinent

La plateforme interprète le signal et le contexte opérationnel fiable disponible pour le processus. Ce contexte peut inclure le service affecté, les modifications récentes, l’état de l’infrastructure, l’état des dépendances, les alertes associées et les informations relatives aux incidents précédents.

Si les éléments disponibles sont incomplets ou contradictoires, le processus peut recueillir davantage d’informations ou demander un examen humain avant d’effectuer une action sensible.

3. Le module de résolution identifie le parcours de reprise approuvé

Le module de résolution aide à déterminer quel flux de travail de reprise approuvé correspond aux éléments disponibles.

Il n’invente pas de procédure de reprise de production pendant la panne. Le concepteur de flux de travail contient la logique de reprise que l’organisation a déjà examinée, notamment les entrées requises, les autorisations, les approbations, les étapes de validation et les conditions d’escalade.

4. Le module de résolution coordonne la reprise

Le module de résolution exécute la séquence de reprise sur les systèmes concernés.

Selon le plan approuvé, le flux de travail peut recueillir des diagnostics supplémentaires, isoler un composant affecté, activer des ressources de secours, restaurer une configuration, coordonner un basculement, mettre à jour le routage, redémarrer les services dépendants ou avertir les équipes appropriées.

Le flux de travail effectue ces actions dans un ordre défini. Il peut se mettre en pause pour demander une approbation avant une modification à haut risque, suivre différentes branches selon des conditions connues et s’arrêter lorsqu’une mesure de protection requise échoue.

5. Le module de résolution vérifie la reprise du service

La fin de la séquence de basculement ne prouve pas que le service a été rétabli.

Le module de résolution exécute les contrôles de réussite définis par l’organisation. Ces contrôles peuvent confirmer que l’infrastructure est disponible, que les dépendances répondent, que l’authentification fonctionne, que l’application réussit un test d’état et que la surveillance ne détecte plus la condition initiale.

Cette validation aide l’équipe à faire la distinction entre une action de reprise terminée et un service métier vérifié.

6. La piste d’audit permet la clôture ou l’escalade

Si les contrôles sont concluants, le module de résolution peut mettre à jour l’enregistrement ITSM, communiquer le résultat et continuer à surveiller le service.

Si la validation échoue, il suit le parcours d’escalade ou le parcours compensatoire approuvé. Les intervenants reçoivent le contexte recueilli, les actions exécutées par le flux de travail et les résultats disponibles.

La piste d’audit offre une visibilité sur l’activité du flux de travail, permettant aux intervenants d’examiner l’exception sans répéter l’ensemble du processus de reprise.

La reprise après sinistre nécessite plus qu’une automatisation ponctuelle

La plupart des grandes entreprises disposent déjà d’outils prenant en charge certaines parties de la reprise après sinistre. Les plateformes de sauvegarde protègent les données. Les plateformes cloud fournissent de la redondance. Les outils d’observabilité détectent les problèmes de service. Les plateformes ITSM gèrent les incidents. Les outils de réseau, d’identité et d’infrastructure contrôlent leurs domaines respectifs.

Chaque outil peut remplir efficacement sa propre fonction. Le défi de l’orchestration apparaît lorsque la reprise exige qu’ils agissent tous comme un processus coordonné unique.

Sans couche d’orchestration, les équipes peuvent devoir relier manuellement des scripts, gérer une logique d’automatisation dupliquée, passer d’une console à l’autre et coordonner les transferts au moyen de tickets ou d’outils de collaboration. À mesure que les environnements se développent, ces dépendances peuvent rendre les procédures de reprise plus difficiles à maintenir et à exécuter de manière cohérente.

Le module de résolution fournit une couche d’orchestration indépendante des plateformes entre les différents domaines informatiques. Les équipes peuvent coordonner les flux de travail, réutiliser l’automatisation, appliquer une gouvernance cohérente et relier les actions de reprise à l’ensemble de la pile technologique.

L’IA rend la reprise gouvernée encore plus importante

L’IA peut aider les équipes à interpréter des alertes incomplètes, à analyser le contexte opérationnel et à identifier la réponse approuvée la plus appropriée. Cependant, les actions de reprise après sinistre peuvent affecter l’infrastructure de production, les données métier, les systèmes d’identité et les services critiques.

Ces actions ne devraient pas dépendre entièrement d’une IA non déterministe.

Le module de résolution sépare le raisonnement de l’exécution en appliquant l’IA là où le contexte et l’interprétation sont utiles, tout en confiant les actions de production à des flux de travail déterministes dotés de contrôles définis. 

Cette approche permet aux équipes d’utiliser l’IA pendant la reprise sans donner à un modèle probabiliste une autorité incontrôlée sur les systèmes critiques.

Le module de résolution transforme les plans de reprise en actions gouvernées

Un plan de reprise après sinistre n’est efficace que dans la mesure où l’organisation est capable de l’exécuter, et les procédures de reprise après sinistre dépendent souvent d’ingénieurs expérimentés qui comprennent les dépendances entre les systèmes, les chemins d’exception et l’ordre dans lequel les actions doivent être effectuées.

Lorsque ces connaissances restent consignées dans des documents, des scripts ou l’expérience d’une personne, la reprise dépend fortement des personnes disponibles pendant la perturbation.

Resolve permet aux équipes de formaliser cette expertise opérationnelle sous forme de logique d’exécution réutilisable afin de créer un modèle de reprise plus facile à reproduire, gouverner, examiner et améliorer.

Cela transforme les procédures documentées en flux de travail gouvernés qui coordonnent les systèmes, appliquent des contrôles, vérifient la reprise et font intervenir les personnes lorsqu’un jugement est nécessaire.

Questions fréquemment posées

Qu’est-ce que l’automatisation de la reprise après sinistre ?

L’automatisation de la reprise après sinistre utilise des flux de travail approuvés pour coordonner les actions nécessaires à la restauration de l’infrastructure, des applications, de l’accès aux données et des services dépendants après une perturbation. Elle réduit la coordination manuelle tout en préservant les contrôles, la validation et la supervision humaine.

Resolve remplace-t-il les plateformes de sauvegarde ou de reprise après sinistre ?

Non. Les outils de sauvegarde, de réplication, de reprise dans le cloud et les autres outils spécifiques à un domaine continuent d’assurer leurs fonctions spécialisées. Resolve orchestre ces outils dans le cadre d’un processus de reprise plus large et de bout en bout.

Comment Resolve utilise-t-il l’intelligence artificielle (AI) dans la reprise après sinistre ?

Resolve peut utiliser le raisonnement de l’intelligence artificielle (AI) pour interpréter les alertes et le contexte opérationnel, puis identifier l’action approuvée appropriée à effectuer. Il gère ensuite l’exécution au moyen de flux de travail gouvernés et déterministes.

Quels travaux de reprise après sinistre Resolve peut-il automatiser ?

Resolve peut coordonner les diagnostics, la sélection des flux de travail de reprise, les actions intersystèmes, les approbations, les séquences de basculement, la validation des services, les mises à jour de l’ITSM et les transferts d’escalade. La portée exacte dépend des systèmes connectés et des procédures de reprise approuvées par l’organisation.

Comment l’automatisation contribue-t-elle aux objectifs de reprise ?

L’automatisation réduit les retards causés par les transferts manuels et une exécution incohérente. Les flux de travail peuvent être conçus autour des objectifs de délai de reprise et des objectifs de point de reprise, mais le résultat atteignable dépend toujours de l’architecture sous-jacente, des sauvegardes, des dépendances et de la stratégie de reprise.

Zack Austin
Zack Austin is Director of Product Marketing at Resolve. With a decade of experience in enterprise IT and security, his career spans malware analysis, sales engineering, GTM leadership, and co-founding a cybersecurity startup. He also co-authored NIST SP 1800-35 on Zero Trust Architecture.