Un guide de survie technologique pour la résilience
Ce n’est pas un secret Dans des environnements commerciaux hautement compétitifs, la demande de croissance et d’augmentation des revenus et des bénéfices des organisations ne cesse d’augmenter. Tout en répondant à la demande et en restant à jour grâce à la numérisation, les organisations doivent rester attentives à l’efficacité, au maintien ou à la réduction des coûts et à la maîtrise des dépenses des employés.
Il est déjà difficile de progresser dans ces deux domaines, mais le fait d’avancer dans ces directions ajoute de la pression sur les systèmes technologiques de l’entreprise à travers la pile technologique, des données aux applications et à l’infrastructure du réseau. Les contraintes technologiques comprennent les limitations de capacité, le temps de disponibilité des systèmes, la qualité des données et la capacité à se remettre d’un événement technologique, physique ou cybernétique catastrophique.
Une technologie résiliente est essentielle pour maintenir des services ininterrompus pour les clients et les desservir pendant les périodes de pointe. Cela nécessite une infrastructure résiliente avec une visibilité et une transparence accrues dans l’ensemble de la pile technologique pour permettre à une organisation de continuer à fonctionner en cas de cyberattaque, de corruption de données, de défaillance catastrophique du système ou d’autres types d’incidents.
La technologie résiliente doit être agile, évolutive, flexible, récupérable et interopérable. En outre, la résilience doit exister non seulement dans l’architecture et la conception, mais aussi dans le déploiement et la surveillance continue.
Comprendre la criticité
Pour parvenir à la résilience, une organisation doit comprendre la criticité d’un processus donné, évaluer la technologie sous-jacente, reconnaître l’impact commercial correspondant et connaître la tolérance au risque de l’organisation et des parties prenantes externes. Pour y parvenir, une organisation doit comprendre où et comment se situe sa résilience aujourd’hui et être en mesure de répondre à la question suivante : « Pourrions-nous récupérer et reconstruire après un sinistre ? Pourrions-nous récupérer et reconstruire après un événement catastrophique ?
Dans une enquête McKinsey de 2022 sur la résilience technologique, qui a évalué le niveau de maturité en matière de cybersécurité de plus de 50 organisations de premier plan en Amérique du Nord, en Europe et sur d’autres marchés développés, 10 % des personnes interrogées ont indiqué qu’elles avaient été obligées de reconstruire à partir du métal nu (par exemple, en raison d’un événement catastrophique), et 2 % ont déclaré qu’elles avaient déjà tenté de reconstruire à partir du métal nu, mais sans succès (par exemple, en raison d’un test délibéré).
En outre, 20 % des personnes interrogées ont indiqué qu’elles avaient déjà tenté de récupérer à partir de bare metal et qu’elles avaient réussi, 8 % ont tenté de récupérer à partir de bare metal, 18 % ont indiqué qu’elles avaient l’intention de tenter de récupérer à partir de bare metal, tandis que 36 % ont indiqué qu’elles n’avaient pas l’intention de récupérer à partir de bare metal.
La résilience technologique est la somme des pratiques et des fondements nécessaires pour architecturer et déployer la technologie en toute sécurité dans l’ensemble de la pile technologique (voir l’encadré « Principes de résilience technologique de McKinsey »). La résilience technologique prépare les organisations à surmonter les défis lorsque leur pile technologique est compromise, réduisant ainsi la fréquence des événements catastrophiques et leur permettant de se rétablir plus rapidement en cas d’événement.
Dans l’enquête de McKinsey, lorsqu’on leur a demandé quel était l’objectif de temps de reprise pour leurs applications les plus critiques, 28 % des personnes interrogées ont répondu immédiatement, tandis que 34 % ont répondu moins d’une heure, 14 % moins de deux heures et 20 % moins de quatre heures. L’une des personnes interrogées dans le cadre de l’enquête a déclaré : « Les systèmes et applications critiques en panne pendant une période significative peuvent coûter des milliards de dollars aux institutions financières ».
Les capacités de résilience se situent sur un spectre de maturité allant de la simple redondance à la duplication des serveurs jusqu’aux capacités avancées avec résilience intégrée dans l’architecture dès la conception.
- Architecture et conception : Les organisations matures intègrent la résilience technologique dans la conception et l’architecture de l’entreprise. Les conceptions résilientes intègrent les enseignements tirés des opérations, des incidents et des tendances du secteur afin de réaliser des investissements technologiques tenant compte des risques.
- Déploiement et opérations : Les opérations résilientes doivent prendre en compte non seulement les imprévus opérationnels, tels que la reprise après sinistre ou les exigences de performance qui augmentent de manière exponentielle, mais aussi la cause profonde des incidents qui surviennent dans le cadre des activités habituelles afin d’améliorer les procédures, la formation et les solutions technologiques.
- Contrôle et validation : Il s’agit de mesures réactives ou rétrospectives aux niveaux de maturité inférieurs. À des niveaux de maturité plus élevés, les organisations passent à des mesures plus proactives (et finalement prédictives) pour tester les solutions avant leur déploiement ou pour élaborer des réponses et des plans d’urgence préétablis pour les éventualités les plus probables.
- Réponse et récupération : Les organisations dotées d’une grande résilience technologique ne se contentent pas de réagir en cas d’incident, elles tirent également en permanence les leçons de leurs propres opérations, des tendances du secteur et des événements catastrophiques pour les intégrer dans la conception, l’exploitation, la surveillance et la planification de leurs entreprises.
Comprendre les composantes du cycle de vie permet à une organisation de tracer son parcours de résilience technologique à travers quatre niveaux de maturité. Les niveaux un et deux sont des capacités fondamentales, tandis que les niveaux trois et quatre sont plus avancés (figure 1).
Le premier niveau consiste en des capacités de base où la résilience est laissée aux utilisateurs individuels et aux propriétaires de systèmes, et où la surveillance implique que les utilisateurs et les clients signalent les pannes du système.
Le niveau 2 consiste en des capacités passives où la résilience est assurée par des sauvegardes manuelles, des systèmes dupliqués et une réplication quotidienne des données. Il y a également une surveillance au niveau de la plateforme ou du centre de données pour les pannes de système.
Le niveau trois consiste en une résilience active par le biais d’un basculement. La résilience existe grâce à la synchronisation active des applications, des systèmes et des bases de données, et à la surveillance active au niveau de l’application pour les indicateurs précoces des problèmes de performance et de stabilité.
Le niveau quatre consiste en une résilience inhérente à la conception. La résilience est intégrée dès le départ dans la pile technologique grâce à la redondance inhérente et à la surveillance active au niveau des données, qui comprend la détection et l’atténuation des anomalies.
Du point de vue du cycle de vie, l’éventail de l’architecture et de la conception va d’une visibilité limitée des dépendances pour les applications critiques et non critiques au niveau 1, à des dépendances et des flux de données intégrés pour la résilience dès la conception initiale pour les applications critiques et non critiques au niveau 4.
Pour le déploiement et les opérations, les pannes régulières du système au niveau 1 remplacent les tests de résilience, et au niveau 4, des tests aléatoires de basculement en production valident la résilience.
En ce qui concerne la surveillance et la validation, au niveau 1, les utilisateurs surveillent leurs propres systèmes pour détecter les pannes, tandis qu’au niveau 4, la surveillance et l’alerte sont intégrées dès la conception, ce qui permet une réponse proactive.
En ce qui concerne la réponse et la récupération, les réponses aux incidents au niveau 1 sont ad hoc et basées sur le meilleur jugement, tandis qu’au niveau 4, des procédures détaillées et diversifiées de « bris de glace » sont intégrées dès la conception.
Spectre de résilience
Au niveau le plus élémentaire, la résilience est laissée aux propriétaires et utilisateurs individuels du système. L’administrateur de la base de données est responsable des sauvegardes des données de l’organisation et chaque employé doit sauvegarder ses propres données. En progressant sur l’échelle de maturité, les organisations s’appuient sur des capacités de résilience centralisées gérées par les services informatiques ou par une fonction de résilience. Une telle organisation prévoit des solutions de sauvegarde centralisées, maintient des systèmes centraux redondants et surveille les pannes de système et les défaillances d’application.
La résilience peut être obtenue de manière passive en effectuant des sauvegardes manuelles quotidiennes. Le passage à une approche active implique la surveillance d’indicateurs précoces de corruption de données ou de comportement anormal du système et la prise de mesures préventives. Ces indicateurs comprennent un volume croissant de données corrompues, un nombre anormalement élevé de brèves pannes de réseau et un nombre plus élevé que d’habitude de serveurs nécessitant un redémarrage. La résilience active se manifeste également par la synchronisation continue des applications, des systèmes et des bases de données de manière à ce que la redondance soit toujours maintenue. Des tests périodiques de basculement sont également effectués pour valider la résilience.
Le niveau le plus avancé de résilience est la résilience inhérente. La principale différence réside dans le fait que la résilience est intégrée dès la conception dans la pile technologique. La résilience inhérente comprend des capacités telles que le traitement en double entre les systèmes, la redondance modulaire et la tolérance automatique aux pannes au sein des systèmes. Une véritable redondance inhérente permet d’effectuer des tests aléatoires de basculement en production pour valider la résilience. Seule la technologie qui permet de mettre en œuvre les processus métier les plus critiques d’une organisation doit être intrinsèquement résiliente de par sa conception. La plupart des organisations se situent dans le spectre des capacités de résilience passive à active, tout en évoluant continuellement vers une résilience active.
Comment devenir résilient
C’est une chose de poser les bases et de souligner les enjeux de la résilience, mais comment y parvenir ? Il existe trois clés pour établir et développer un environnement technologique plus résilient :
- Une culture sans reproche : Lorsque des problèmes surviennent, les équipes et les responsables ne cherchent pas à savoir qui doit être blâmé. Ils se concentrent sur la résolution du problème et la prévention des récidives. Les équipes célèbrent les membres qui exposent les vulnérabilités et les faiblesses comme nécessaire pour construire une technologie plus résiliente.
- Approche axée sur les mesures : Les équipes mesurent sans relâche leurs propres performances et se concentrent sur les incidents qu’elles ont créés (par exemple, à partir de versions ou de correctifs) ou sur les incidents répétés qui ont la même cause première.
- Répéter la panne : Les équipes anticipent les problèmes et s’entraînent de manière itérative à répondre à des pannes de système complètes. Elles vont des applications individuelles aux systèmes, en passant par les produits (systèmes de systèmes) et les services entiers.
Lorsqu’on leur a demandé, dans le cadre de l’enquête McKinsey, à quelle fréquence ils testaient les applications critiques, un peu plus de 60 % des personnes interrogées ont répondu qu’elles les testaient au moins une fois par trimestre. Parmi eux, 14 % ont déclaré effectuer des tests hebdomadaires, 26 % des tests mensuels et 26 % des tests trimestriels. Dans l’ensemble, 28 % des répondants ont déclaré effectuer des tests tous les six mois, tandis que 6 % ont indiqué qu’ils effectuaient des tests annuels. Une personne interrogée a déclaré : « Il y a des tests trimestriels. Les systèmes les plus critiques sont testés à chaque fois, les systèmes moins critiques sont testés tous les deux cycles ou au moins une fois par an.
Résilience basée sur le risque
Les entreprises s’orientent vers une résilience technologique basée sur le risque (voir l’encadré « Une banque européenne travaille à la résilience technologique »). Cette approche reconnaît que tous les actifs ne sont pas créés égaux et qu’ils ne peuvent pas être protégés de la même manière dans l’environnement numérique global d’aujourd’hui.
Certaines capacités et certains actifs sous-jacents sont plus essentiels que d’autres pour une entreprise et ses activités. Dans le cas d’une grande compagnie d’électricité, par exemple, il s’agit des systèmes technologiques qui permettent de fournir de l’électricité et du gaz naturel aux clients. Dans le cas d’une institution mondiale de services financiers, ce sont les plateformes de négociation et celles qui soutiennent les transactions des clients qui sont les plus critiques. Le modèle d’entreprise numérique dépend en fait entièrement de la confiance et de la capacité à fournir en permanence des services en contact avec la clientèle. Garantir la résilience de ces actifs est au cœur d’une stratégie efficace de protection contre les événements catastrophiques.
Trois leviers pour renforcer la résilience technologique
Pour atteindre des niveaux de maturité élevés en matière de résilience technologique, il faut mettre en place les capacités et les processus nécessaires, en s’appuyant sur trois leviers.
-
Donner la priorité aux services : Tous les services et systèmes de l’entreprise ne doivent pas être traités de la même manière lors du déploiement des capacités de résilience technologique. Les organisations devraient plutôt définir leurs services les plus critiques. Il s’agit des services cruciaux nécessaires pour remplir les obligations envers les clients, les partenaires commerciaux, les régulateurs et la société.
Après avoir identifié et obtenu un accord interprofessionnel sur ces services, il est essentiel de comprendre le paysage technologique sous-jacent, notamment les applications et les systèmes qui permettent de fournir les services les plus critiques, leurs dépendances et la manière dont ils sont interconnectés.
La visibilité et la transparence des services les plus critiques et des applications, systèmes et dépendances sous-jacents permettent d’évaluer le niveau de résilience actuel et de hiérarchiser la résilience cible, application par application et système par système.
Dans l’étude McKinsey sur la résilience, la question suivante a été posée aux personnes interrogées : « Combien de temps vous a-t-il fallu pour aligner toutes vos applications les plus critiques sur les objectifs de temps de reprise ? ». 26 % des personnes interrogées ont répondu moins d’un an, 28 % moins de deux ans et 26 % moins de trois ans.
L’une des personnes interrogées a déclaré : « Déterminer clairement quels sont les systèmes les plus critiques est un défi permanent ». Un autre a déclaré : « C’est pendant la tempête Sandy que la banque a commencé à s’inquiéter de sa robustesse, ou de son manque de robustesse, et cette question a été mise au premier plan immédiatement après. »
-
Évaluer le niveau actuel de résilience et passer en revue les crises passées : L’étape suivante consiste à évaluer la résilience technologique existante. Les organisations doivent évaluer leur maturité selon la même courbe en S de la résilience technologique, qu’elles disposent d’une architecture et de capacités résilientes, de capacités de résilience passive, d’une résilience active avec des capacités de basculement, ou qu’elles soient intrinsèquement résilientes de par leur conception.
En règle générale, les organisations doivent évaluer leurs capacités actuelles dans les quatre dimensions du cycle de vie de la résilience technologique. Les organisations les plus matures intègrent la résilience technologique dans l’architecture des applications et des systèmes dès la conception. Lors du déploiement et de l’exploitation, les opérations résilientes devraient tenir compte non seulement des imprévus opérationnels, mais aussi de la cause profonde des incidents qui surviennent dans le cadre des activités habituelles, afin d’améliorer les procédures, la formation et les solutions technologiques. Le contrôle et la validation impliquent des mesures réactives ou rétrospectives aux niveaux de maturité inférieurs. À des niveaux de maturité plus élevés, les organisations passent à des mesures proactives pour rechercher des indicateurs précoces de problèmes de résilience et tester les réponses et les plans d’urgence pour les éventualités les plus probables. En ce qui concerne la réaction et la reprise, les organisations dotées d’une résilience technologique élevée ne se contentent pas de réagir en cas d’incident, mais tirent continuellement des enseignements de leurs propres opérations, des tendances du secteur et des événements catastrophiques, qu’elles réinvestissent ensuite dans la conception, l’exploitation, la surveillance et la planification de la technologie.
Les organisations devraient également évaluer les incidents technologiques passés afin d’identifier et de découvrir les facteurs contributifs communs qui peuvent être pris en compte pour accroître la résilience technologique. En règle générale, il s’agit de sélectionner un large éventail d’incidents récents, de durée et d’impact variables, dans l’ensemble des fonctions de l’entreprise, afin de les évaluer. Il peut également s’agir d’examiner les journaux de réponse aux incidents antérieurs, les rapports d’incidents et d’autres documents afin d’identifier les facteurs contributifs, les schémas et les idées susceptibles d’éclairer les causes des incidents. Les réunions avec les ingénieurs, les propriétaires de produits ou de systèmes, les responsables des versions et les autres personnes impliquées dans l’incident et la réponse peuvent permettre de découvrir ce qui s’est passé, ce qui aurait pu être fait pour éviter l’incident et les initiatives qui sont déjà en cours.
Une fois cette étape franchie, il est possible d’identifier les facteurs communs à l’origine de ces incidents et d’y remédier, notamment l’environnement technologique lui-même, l’architecture des applications, les interfaces entre les systèmes et les tiers, et la manière dont la résilience a été intégrée dans les applications et les systèmes individuels.
-
Combler les lacunes grâce à une approche interfonctionnelle : Pour parvenir à la résilience technologique, il faut remédier aux lacunes identifiées lors de l’évaluation de la technologie de l’organisation et du diagnostic des incidents passés. En plus de remédier directement aux lacunes identifiées, les organisations devraient prendre les mesures spécifiques suivantes :
Déterminer la propriété et la responsabilité des activités de résilience technologique. Les systèmes distribués peuvent avoir plusieurs propriétaires, et les développeurs ne sont pas toujours incités à concevoir des systèmes résilients. Les applications et les systèmes doivent avoir une propriété claire, les développeurs ont besoin d’incitations avec des objectifs de performance liés à la résilience des applications qu’ils construisent, et les contrats de tiers doivent inclure des exigences et des clauses de résilience. L’absence de propriété claire du système et de responsabilité pour remédier aux lacunes aura un impact négatif sur la résilience des systèmes et des processus d’entreprise.
Améliorer la gouvernance vers les niveaux de résilience. Le contrôle de la résilience doit être mis en œuvre à partir du niveau exécutif. La direction doit communiquer ses intentions et ses priorités en matière de résilience à tous les niveaux de l’organisation, au moyen de messages continus et cohérents. Les réunions publiques, les bulletins d’information trimestriels et les webinaires sont autant de moyens potentiels. De même, des récompenses et d’autres formes d’incitations monétaires et non monétaires peuvent être envisagées.
Augmenter la résilience des applications individuelles et des groupes d’applications. La résilience des applications et des systèmes individuels doit également être examinée et corrigée. Les applications et systèmes qui connaissent le plus grand nombre d’incidents et qui soutiennent les processus d’entreprise les plus critiques doivent être traités en priorité.
Renforcer la structure d’hébergement, qu’il s’agisse de locaux ou de nuages. Les plateformes sous-jacentes sur lesquelles résident les applications doivent également être conçues et architecturées pour la résilience. Les organisations devraient s’efforcer d’accroître la résilience de leurs plateformes sur site et en nuage en remédiant aux lacunes connues et en s’attaquant aux facteurs contribuant aux incidents passés.
Travailler avec des tiers pour accroître la résilience des plateformes tierces dont dépendent les processus et les services critiques des entreprises. Les tiers pourraient être incités à intégrer la résilience dans leurs systèmes, et les contrats doivent contenir un libellé clair sur les exigences de performance en matière de résilience.
Mettre en œuvre des tests réguliers, en mettant l’accent sur les capacités de basculement automatique pour les environnements à grande échelle et sur des exercices sélectifs pour tester la reprise à partir des sauvegardes. La résilience est un processus continu, et les systèmes doivent être régulièrement testés et validés pour s’assurer qu’ils répondent aux exigences de résilience. Les tests mensuels de basculement des applications critiques sont essentiels, tant au niveau de l’application que de la plateforme. Les tests de basculement doivent être conçus de manière à tester non seulement ce qui est prévu, mais aussi ce qui est inattendu, par exemple en procédant à des arrêts d’urgence ou en introduisant des surcharges de capacité qui reflètent des scénarios réels. Lorsque la résilience est intégrée dès la conception, les applications doivent être mises hors service de manière aléatoire en production afin de vérifier si la résilience inhérente est réellement architecturée et intégrée dans l’application ou le système.
Dans l’enquête McKinsey, lorsqu’on leur a demandé quels scénarios de basculement les répondants avaient planifié ou testé, 92 % ont répondu qu’ils avaient testé la défaillance d’un seul centre de données et l’impact non physique, tandis que 52 % ont répondu la défaillance de deux centres de données, et 83 % l’impact physique (figure 2).
À la question « Effectuez-vous des tests de basculement non planifiés » (c’est-à-dire que vous arrêtez les systèmes au hasard et testez la capacité de l’organisation à réagir/reprendre), 54 % des personnes interrogées ont répondu qu’elles n’en effectuaient aucun, 26 % ont répondu qu’elles testaient uniquement les applications les plus critiques, et 20 % ont répondu qu’elles testaient toutes les applications (figure 3).
Le voyage vers la résilience technologique en trois étapes
En comprenant les trois leviers de la résilience technologique, une organisation peut s’engager sur la voie de la résilience technologique en trois étapes.
Diagnostic de résilience technologique
Identifier deux ou trois processus métier critiques et cartographier les ensembles de données, les applications et les systèmes technologiques sous-jacents qui permettent de réaliser ces processus. Évaluer la résilience de chaque composant de la chaîne de valeur. Cela permettra de découvrir la résilience technologique des données, des applications et des systèmes qui sous-tendent les processus métier critiques, ainsi que les mesures d’atténuation des risques.
Effectuer une rétrospective des incidents
Effectuer une rétrospective des incidents technologiques récents afin d’identifier les facteurs contributifs communs et d’élaborer des mesures correctives visant à réduire le taux d’incidents et à accroître la résilience de l’environnement technologique. Interroger les développeurs, les ingénieurs de mise en production et les autres personnes impliquées dans les incidents pour découvrir les facteurs contributifs et ce qui aurait pu être fait pour les éviter. Les résultats permettront de mieux comprendre les facteurs qui ont conduit aux incidents et les mesures qui peuvent être prises pour réduire le taux d’incidents et accroître la résilience de la technologie.
Développer une capacité technologique redondante
Concevoir une architecture résiliente pour un ou plusieurs composants de la pile technologique et une architecture technologique de l’état futur pour répondre au diagnostic précédent et à la rétrospective des incidents. Ces capacités devraient inclure un plan de transition et de mise en œuvre ainsi que des exigences en matière de surveillance, de maintenance et de validation continues. Le résultat devrait être une architecture technologique résiliente, un plan de transition et de mise en œuvre ainsi que des exigences en matière de surveillance et de validation.
La résilience n’est pas une activité ponctuelle ; il s’agit plutôt d’un processus et d’une capacité continus qui prendront du temps pour évoluer vers un mécanisme de défense solide.
Comme pour tous les types de protection, il ne s’agit pas d’obtenir ce que l’on paie, mais plutôt de se préparer à ce que l’on obtient. Il serait facile de consacrer de l’argent à toutes les formes de résilience, mais comprendre ce que l’on possède, puis avoir de la visibilité et de la transparence sur ce que l’on possède permet de se concentrer, ce qui permet à toute organisation de rester résiliente et de rester opérationnelle ou de revenir à un état stable le plus rapidement possible.
Source de l’article