OVH 2017: indépendance de la redondance en question

Résumé

Le périmètre de l’événement est étroit:cet article ne traite que de la panne du réseau optique de Roubaix du 9 novembre 2017. La panne électrique simultanée de Strasbourg était un incident distinct, avec un mécanisme et une chaîne de contrôle différents.
La défaillance visible était large mais pas universelle:les récits contemporains décrivaient une perte de connectivité de Roubaix vers six des points de présence du réseau d’OVH. Cela ne prouve pas que chaque route, client ou charge de travail d’OVH ait échoué de la même manière.
La diversité nominale n’a pas apporté d’indépendance opérationnelle:OVH décrivait une connectivité optique redondante, mais les liaisons de Roubaix ont été indisponibles ensemble après une perte de configuration et ont dû être restaurées à partir d’une configuration sauvegardée.
La cause profonde publique comporte deux niveaux:OVH a attribué l’événement immédiat à un défaut logiciel et à la perte de configuration des équipements optiques. La perte corrélée a également révélé un domaine de défaillance partagé au niveau de la configuration ou de la supervision, que la diversité physique des chemins n’avait pas supprimé.
Une configuration sauvegardée n’est pas un système de restauration indépendant:une configuration sauvegardée a permis la restauration, mais son existence n’a pas maintenu le système optique en fonctionnement. La disponibilité des sauvegardes, l’autorité de restauration et la capacité de restauration testée doivent être mesurées séparément.
La responsabilité suit le contrôle:OVH contrôlait l’architecture, le déploiement, la protection de la configuration, la surveillance, la restauration et la communication aux clients. Le fabricant de l’équipement contrôlait l’enquête sur le défaut du produit et la correction logicielle. Les pairs, les réseaux de transit et les clients contrôlaient leur propre diversité externe, mais pas l’état optique interne d’OVH.
La réparation annoncée a correctement séparé deux problèmes:OVH prévoyait une mise à niveau logicielle avec le fabricant de l’équipement et une répartition du système de multiplexage optique sur deux systèmes. Le premier visait un défaut; le second devait limiter le rayon d’impact en cas de récidive.
Une réparation n’est pas prouvée par une annonce:une clôture crédible exige des preuves de topologie et de configuration, des tests d’injection de panne, des mesures de joignabilité indépendantes et la preuve qu’une seule défaillance de contrôle ne peut plus supprimer tous les chemins externes de Roubaix.

Figer l’événement de Roubaix avant d’attribuer les responsabilités

OVH a connu deux pannes graves le même jour. Une panne électrique a touché son site de Strasbourg, tandis qu’une panne du réseau optique a touché Roubaix. La déclaration ultérieure d’OVH décrivait explicitement les incidents comme simultanés mais sans lien. Cette distinction est le point de départ de la responsabilité, et non un détail à fondre dans un récit plus large. [1]

Combiner les incidents produirait une chaîne causale inexacte. Strasbourg impliquait l’alimentation électrique, les équipements de transfert, les groupes électrogènes et le redémarrage des services. Roubaix impliquait le transport optique, la perte de configuration et la connectivité vers des emplacements réseau externes. Les systèmes responsables, les opérateurs, les fournisseurs, les signaux de détection, les actions de restauration et les tests de prévention étaient différents.

Cet article commence donc à la panne optique de Roubaix et se termine lorsque les liaisons concernées et la connectivité du site d’hébergement ont été restaurées, suivi des mesures correctives propres à Roubaix annoncées par OVH. Il exclut la panne électrique de Strasbourg, un incident de stockage de juillet 2017, un incident réseau ultérieur de décembre 2017, l’incendie de Strasbourg de 2021 et un événement de routage distinct de 2021. Ces événements peuvent éclairer une histoire plus large d’OVH, mais ils ne peuvent pas servir de preuve de la cause ou de la réparation de la panne optique de Roubaix.

La chronologie publique comporte deux niveaux utiles. La déclaration officielle d’OVH indiquait que le site de Roubaix était revenu en fonctionnement en moins de deux heures et demie. Un fournisseur de services affecté a enregistré séparément une indisponibilité visible par les clients au cours de la même matinée et a décrit la restauration après la récupération de la configuration optique. [1][4]

Ces récits décrivent la fenêtre de restauration optique à des niveaux différents. Ils n’établissent pas que chaque service client s’est rétabli à un instant précis. Un site d’hébergement est un empilement: les liaisons de transport reviennent, les sessions de routage se rétablissent, les chemins convergent, les équilibreurs de charge et les dépendances applicatives récupèrent, les files de messagerie se vident, la surveillance redevient normale et les clients réessaient. Les preuves publiques ne fournissent pas de tableau complet de restauration service par service.

La même discipline s’applique au début de l’incident. Un fournisseur de services affecté a décrit une accessibilité depuis certains réseaux mais pas d’autres pendant la perturbation matinale, tandis qu’OVH décrivait la panne optique côté fournisseur puis la restauration. Ces points de vue ne sont pas nécessairement contradictoires. L’un enregistre l’effet observé par un client externe; l’autre enregistre un événement dans le système optique du fournisseur. Des observateurs, des horloges et des chemins réseau différents peuvent voir des frontières différentes. [4]

La responsabilité exige de préserver ces distinctions au lieu d’imposer une heure parfaite. Un dossier d’incident solide alignerait les sondes externes, les alarmes optiques, les transitions d’interface, les journaux des contrôleurs, les changements de sessions de routage et les signalements des clients sur une horloge commune. Le matériel public ne fournit pas cet alignement complet; cet article ne l’invente donc pas.

Ce que le réseau en fonctionnement a révélé

Le site de Roubaix dépendait du transport optique le reliant vers six des points de présence du réseau d’OVH, selon le récit du fournisseur de services affecté. Le dossier public décrit plusieurs chemins optiques et une large perte de connectivité externe, mais il ne fournit pas de topologie complète vérifiée pour chaque circuit, chemin client ou dépendance. [4]

Ces détails importent, car ils montrent que l’événement n’a pas été présenté comme une simple coupure de fibre unique. OVH et les récits contemporains décrivaient plutôt une défaillance logicielle et de configuration affectant le système optique, suivie d’un travail de récupération avec le fabricant de l’équipement. Les sources disponibles n’exposent pas la séquence de diagnostic complète ni l’état interne du plan de gestion. [1][4]

La description publique de la cause profonde identifiait une perte de configuration dans l’équipement optique. OVH a récupéré la configuration sauvegardée et restauré la connectivité concernée. L’entreprise a attribué l’événement immédiat à un défaut logiciel, tandis que la perte de chemin corrélée a soulevé une question plus large sur les dépendances partagées de configuration et de supervision. [1][4]

C’est un récit significatif, mais ce n’est pas un rapport d’enquête complet. Il ne divulgue pas la version exacte du logiciel, le changement d’état initiateur, le plantage de processus, la séquence de stockage, la sémantique de réplication, l’élection du plan de contrôle, la commande humaine, la chronologie des alarmes ou le dossier d’incident interne. Il ne prouve pas si la perte de configuration était la seule cause initiale ou une conséquence visible d’une défaillance de contrôle plus profonde.

L’affirmation défendable la plus solide est plus étroite: l’équipement optique d’OVH est entré dans un état où les liaisons externes de Roubaix étaient indisponibles; OVH a attribué cet état à un défaut logiciel et à une configuration manquante; la restauration de la configuration sauvegardée a rétabli la connectivité; et OVH a ensuite proposé à la fois une correction logicielle et une séparation architecturale.

Le réseau en fonctionnement est la preuve principale. Les inventaires peuvent dire que des fibres, des chemins, des cartes et des sauvegardes existent. Les documents de conception peuvent dire que les liaisons sont redondantes. Ce qui comptait pendant l’incident, c’est que le système optique a cessé de fournir la connectivité externe nécessaire à la joignabilité de Roubaix. L’état opérationnel a pris le pas sur le schéma nominal.

C’est la question centrale de responsabilité en matière d’infrastructure réseau. La redondance ne doit pas être comptée par les seuls composants. Elle doit être évaluée par les domaines de défaillance susceptibles de supprimer le service.

La diversité physique n’est pas l’indépendance des domaines de contrôle

Le modèle visuel courant d’un transport résilient est deux lignes entre deux emplacements. Si une fibre est coupée, le trafic utilise l’autre. Ce modèle est utile pour un risque physique étroit. Il est incomplet lorsque les deux chemins partagent un logiciel, une autorité de configuration, un matériel de supervision, une synchronisation, une alimentation, un accès de gestion, une logique d’activation ou une procédure de récupération commune.

Deux chemins optiques géographiquement distincts peuvent toujours occuper un seul domaine de défaillance opérationnel. Ils peuvent aboutir sur des cartes régies par la même base de données. Ils peuvent dépendre du même contrôleur ou de la même paire de supervision. Ils peuvent recevoir la même image logicielle défectueuse. Ils peuvent hériter d’une seule transaction de configuration. Ils peuvent nécessiter un seul réseau de gestion pour le diagnostic. Ils peuvent se fermer en sécurité lorsqu’un état de sécurité commun est atteint.

Le récit d’OVH est un exemple concret de cette distinction. Le fournisseur décrivait une connectivité optique redondante, mais les liaisons de Roubaix ont été indisponibles ensemble lorsque la configuration a été perdue. Les contrôles censés préserver la connectivité n’ont pas contenu la défaillance d’état de configuration partagé qui s’est réellement produite. [1][4]

Cela ne signifie pas que la diversité physique était inutile. Cela signifie qu’elle traitait un risque différent. Les allégations de résilience devraient nommer la classe de risque qu’elles contiennent:

une coupure de fibre unique;
une défaillance de conduit ou d’itinéraire géographique;
la perte d’un amplificateur optique ou d’un nœud;
la perte d’une carte de ligne ou d’un châssis;
la défaillance d’un contrôleur ou d’une carte de surveillance;
une configuration corrompue ou manquante;
un défaut logiciel commun;
la perte de connectivité de gestion;
une erreur d’opérateur propagée à travers des systèmes redondants;
un échec de restauration dans les conditions de l’incident.

Une conception peut réussir les trois premières et échouer à la sixième ou à la septième. Qualifier le résultat de « redondant » sans nommer la classe de défaillance protégée dissimule la question la plus importante.

La RFC 3439 met en garde, en termes architecturaux généraux, sur le fait que la complexité a des coûts réels et que les systèmes échouent souvent dans des interactions inattendues. Elle n’a pas été écrite au sujet de l’incident d’OVH et ne prouve pas la conception interne du fournisseur. Elle offre une discipline analytique utile: ajouter des composants, des copies et de l’automatisation peut créer un état partagé et des modes de défaillance supplémentaires, sauf si leur comportement est borné et observable. [14]

Les orientations du NIST sur les systèmes cyber-résilients traitent également la résilience comme une capacité d’ingénierie à anticiper, résister, récupérer et s’adapter. Il s’agit d’un cadre plus tardif, et non d’une preuve de ce qu’OVH a déployé en 2017. Appliqué avec soin, il suggère qu’un réseau doit être jugé non seulement sur les allégations de prévention, mais aussi sur les limites de dégradation, l’autorité de récupération, la préservation des preuves et l’adaptation après une panne. [17]

L’architecture de transport optique décrite par les recommandations de l’UIT fournit un vocabulaire pour les couches, les relations de chemin optique et la protection. Elle ne peut pas reconstituer la topologie privée d’OVH à partir de faits publics. Sa valeur ici est de renforcer un point général: le transport optique est un réseau géré avec des fonctions de contrôle, de supervision et de récupération, et non de simples fibres passives. [18]

Le test de responsabilité est donc l’indépendance, et non la duplication. Un opérateur devrait pouvoir identifier quels éléments sont indépendants, lesquels sont intentionnellement partagés et ce qui se passe lorsque chaque élément partagé tombe en panne.

Une configuration sauvegardée n’équivalait pas à une disponibilité opérationnelle

Le récit d’OVH indique que la configuration sauvegardée a été restaurée. Ce détail illustre un problème récurrent de l’assurance des infrastructures: la présence d’une sauvegarde est souvent traitée comme équivalente à la capacité de récupération.

Une sauvegarde peut exister et ne pas préserver le service. Elle peut être stockée dans le même domaine de défaillance. Ses répliques peuvent être soumises au même logiciel défectueux. Elle peut contenir le même état corrompu. Le système peut ne pas être capable de la sélectionner ou de la charger automatiquement. L’accès de gestion peut être indisponible. Les opérateurs peuvent devoir intervenir physiquement. Les procédures de restauration peuvent être lentes, ambiguës ou non testées en cas de défaillance commune.

Le récit de Roubaix indique que les ingénieurs ont finalement récupéré la configuration sauvegardée. C’était une action de récupération réussie. Cela montre aussi que le système en fonctionnement n’a pas maintenu la disponibilité simplement parce qu’une configuration récupérable existait. [1][4]

Les contrôles pertinents sont donc plus précis que « une sauvegarde existait »:

Quel objet exact a été copié: une base de données complète, une configuration générée, un état de l’équipement ou un journal de transactions?
Quel processus a écrit chaque copie, et un seul défaut logiciel pouvait-il les corrompre toutes?
Les copies étaient-elles immuables ou versionnées de manière indépendante?
Étaient-elles stockées sur des systèmes physiquement et logiquement séparés?
Quelle règle de cohérence déterminait si une copie était utilisable?
Pouvait-on sélectionner une version connue comme bonne sans le composant de gestion en panne?
La restauration était-elle automatique, approuvée par un opérateur ou dépendante d’un accès local?
Combien de temps une restauration complète avait-elle pris lors du dernier test?
La restauration recréait-elle l’état prévu ou simplement le dernier état répliqué?
Quelles preuves confirmaient que chaque nœud optique et chaque liaison côté routeur étaient revenus correctement?

Le matériel public ne répond qu’à une partie de la liste. Il montre que la restauration de la configuration était possible. Il ne montre pas que la récupération était indépendante, préautorisée, régulièrement exercée ou mesurée par rapport à un objectif de service.

Cette distinction devrait influencer les rapports aux clients et au conseil. « La configuration était sauvegardée » est une déclaration d’inventaire. « Une configuration connue comme bonne peut être restaurée par un chemin de contrôle indépendant dans un délai testé, tout en préservant les preuves et en empêchant la réintroduction de l’état défectueux » est une déclaration de contrôle opérationnel.

Le transport optique faisait partie du service d’hébergement

La responsabilité de l’hébergement est souvent discutée au niveau du serveur ou du centre de données. La panne de Roubaix montre pourquoi cette frontière est trop étroite. Un serveur peut rester alimenté et sain tout en devenant injoignable parce que le transport optique reliant son site aux points d’interconnexion externes a échoué.

Les documents publics de peering d’OVH et les enregistrements actuels de PeeringDB et de RIPE identifient l’AS16276 et une empreinte d’interconnexion substantielle. Ces enregistrements sont utiles pour l’identité du réseau et l’attribution de l’opérateur. Ils aident un client ou un enquêteur à distinguer le réseau d’OVH d’un autre fournisseur et à identifier les emplacements où une interconnexion peut se produire. Ils ne prouvent pas l’état opérationnel d’un circuit de Roubaix en 2017, le chemin utilisé par un paquet particulier ni l’indépendance de deux services clients. [8][9][10][11]

C’est une distinction de niveau de réalité. Un registre ou un annuaire peut enregistrer qui exploite un système autonome. Une page de peering peut décrire une politique. Un collecteur de routes peut conserver des observations BGP sélectionnées. Aucun ne peut faire circuler le trafic sur un système optique en panne.

Inversement, la panne optique n’a pas effacé l’identité du réseau. Le numéro d’AS, les routes et les relations externes demeuraient des preuves utiles pour diagnostiquer quel réseau était censé produire et acheminer le trafic. Les enregistrements et l’infrastructure en fonctionnement remplissent des fonctions de responsabilité différentes: les enregistrements identifient et préservent l’autorité; les systèmes en fonctionnement déterminent si les paquets circulent.

Les clients qui achètent un hébergement « redondant » ou plusieurs services auprès d’un même fournisseur doivent demander si leurs dépendances convergent à l’intérieur du fournisseur. Deux machines virtuelles dans des grappes séparées peuvent partager le même transport de site. Deux services dans des bâtiments différents peuvent partager un système optique métropolitain. Deux chemins annoncés peuvent converger vers un même contrôleur ou une même base de données de configuration. Les noms de produits et les nombres de ressources ne révèlent pas ces dépendances.

Le rapport d’Actility fournit un point de vue externe instructif. Il indiquait que certains services étaient injoignables alors qu’une offre SaaS hébergée dans un autre centre de données n’était pas affectée. Il décrivait également une joignabilité depuis certains emplacements ou réseaux mais pas d’autres. [4] Ce schéma est cohérent avec des dépendances et une diversité de chemins, bien que les données publiques ne suffisent pas à cartographier chaque route ou service.

La leçon pour le client n’est pas simplement « utiliser deux fournisseurs ». Une conception multi-fournisseurs peut réduire la concentration, mais elle crée sa propre complexité en matière de DNS, de routage, de cohérence des données, de sécurité et d’exploitation. L’exigence la plus forte est de documenter les frontières de dépendance et de tester la panne qui importe.

L’impact doit rester rattaché à des preuves observables

OVH a reconnu des conséquences directes pour d’autres services et indiqué que la réception des e-mails des clients était particulièrement difficile. L’entreprise s’est excusée et a déclaré que ses équipes restaient mobilisées. [1] Les reportages contemporains décrivaient un impact client significatif dans l’environnement de Roubaix. [5][6][7]

Les sources publiques ne fournissent pas de décompte complet des clients affectés, de série temporelle de perte de paquets, d’analyse route par route, d’inventaire des services, d’impact sur les revenus ni de tableau final de SLA. Elles n’établissent pas que chaque charge de travail à Roubaix a été injoignable pendant toute la durée de la panne optique. Elles n’établissent pas non plus qu’un service était sain simplement parce qu’une sonde publique a réussi.

Des réseaux différents ont pu observer des comportements différents. Les politiques de routage, les réponses DNS en cache, les sessions existantes, les emplacements de service alternatifs et la logique de nouvelle tentative des applications peuvent tous influencer l’impact visible. Certains clients ont pu perdre tout accès. D’autres ont pu atteindre un service par un chemin restant ou un site séparé. Les e-mails peuvent être mis en file d’attente et arriver plus tard, rendant la panne de transport visible comme un retard plutôt qu’une perte permanente.

L’énoncé d’impact correct comporte trois niveaux:

Impact d’infrastructure signalé par le fournisseur:le site de Roubaix a perdu les liaisons optiques externes décrites dans le récit d’OVH.
Impact de service observé de l’extérieur:des clients et au moins un fournisseur hébergé ont signalé une injoignabilité partielle ou large et une perturbation spécifique des services.
Impact complet inconnu:le dossier public n’énumère pas tous les clients, flux, routes, services ou conséquences financières affectés.

Préserver ces niveaux évite à la fois la sous-estimation et l’exagération. Dire que l’impact complet est inconnu ne minimise pas l’événement. Perdre les principales liaisons optiques d’un site est intrinsèquement grave. Il est également inutile d’affirmer une panne universelle lorsque les preuves n’en étayent pas une.

Un rapport d’impact responsable publierait une joignabilité limitée dans le temps depuis des réseaux indépendants, l’état des sessions BGP, la disponibilité des liaisons, le trafic agrégé, l’arriéré de messagerie, la santé des principaux services, le volume de tickets clients et les distributions de restauration. Il décrirait les limites d’échantillonnage et les horloges. Il séparerait la récupération du transport de la récupération applicative.

Répartition des contrôles: une responsabilité distribuée n’est pas une responsabilité absente

L’infrastructure réseau traverse les frontières organisationnelles. Cela peut conduire à une conclusion vague selon laquelle la responsabilité était « partagée ». Une meilleure méthode répartit la responsabilité selon le contrôle.

OVH

OVH contrôlait l’architecture de son réseau optique de Roubaix, la relation entre les chemins physiques et les systèmes de contrôle, le déploiement logiciel dans son périmètre, la protection de la configuration, la surveillance, l’escalade des incidents, l’intervention locale, le séquençage de la restauration, la communication aux clients et la décision de modifier la conception.

Ce contrôle crée des obligations précises. OVH devait identifier les domaines de défaillance communs, déployer les logiciels en toute sécurité, préserver une configuration connue comme bonne, maintenir un chemin de diagnostic indépendant, tester la restauration, définir les attentes des clients et produire des preuves que la conception corrigée contenait la récurrence.

OVH n’a pas nécessairement créé le défaut logiciel de l’équipement. Cela ne supprime pas sa responsabilité architecturale. Les opérateurs choisissent comment un défaut de fournisseur peut affecter leur service. Ils décident si un défaut atteint tous les chemins redondants, si une restauration en arrière est possible et si un contrôleur défaillant peut être contourné.

Le fabricant de l’équipement

Le fabricant de l’équipement contrôlait l’ingénierie produit, l’analyse des défauts, le logiciel corrigé, les diagnostics du fournisseur et les informations communiquées à OVH. Le dossier public indique qu’OVH enquêtait avec le fabricant et prévoyait de mettre à niveau le logiciel concerné. [1][4]

En l’absence de rapport public du fournisseur, cet article ne peut pas attribuer l’erreur logicielle exacte ni affirmer si le défaut était connu auparavant. Le fabricant possédait néanmoins la tâche côté produit: identifier pourquoi la configuration a disparu ou est devenue inutilisable et démontrer que le code corrigé empêchait la panne.

Pairs et fournisseurs de transit

Les opérateurs de réseau externes contrôlaient leurs propres liaisons, sessions BGP, préférences de route, surveillance et escalade. Ils pouvaient observer la perte de joignabilité d’OVH et s’adapter là où une interconnexion alternative existait. Ils ne pouvaient pas restaurer la configuration optique interne d’OVH.

Les pratiques opérationnelles BGP telles que des politiques d’importation et d’exportation explicites sont essentielles aux frontières interdomaines. Les RFC 7454 et RFC 8212 fournissent des protections de routage générales ou ultérieures, et non un diagnostic de cet événement optique. Elles importent parce que la restauration de la lumière ne prouve pas à elle seule un échange de routes correct. Après le retour des interfaces, une politique de routage explicite aide à borner la récupération des chemins. [15][16]

Clients

Les clients contrôlaient le choix du fournisseur, le placement des services, la surveillance externe, le DNS et le basculement applicatif, la réplication des données et leur propre communication d’incident. Un client ayant acheté plusieurs produits à OVH pouvait demander des preuves que ces produits ne partageaient pas le domaine de défaillance optique de Roubaix.

Les clients ne contrôlaient pas l’état interne des équipements optiques d’OVH, le système de configuration ni la topologie optique. Il serait erroné de reporter la défaillance de transport interne du fournisseur sur les clients au motif qu’ils auraient pu acheter davantage de redondance. La résilience du client et la responsabilité du fournisseur sont complémentaires, et non substituables.

Régulateurs, annuaires et observateurs

Les enregistrements de registre, d’ASN et de peering soutiennent l’attribution et l’analyse historique. Les plateformes de mesure peuvent conserver des observations de routage sélectionnées. Les organismes de normalisation définissent des principes de conception et d’exploitation utiles. Aucun n’exploitait le système de Roubaix ni ne pouvait le restaurer.

Cette répartition évite deux erreurs. La première consiste à traiter un bogue de fournisseur comme une excuse complète pour la défaillance du fournisseur d’hébergement. La seconde consiste à attribuer toutes les conséquences à OVH sans reconnaître les contrôles clients et d’interconnexion en dehors de sa frontière. La responsabilité suit la capacité de prévenir, détecter, contenir, récupérer et prouver.

La détection et le diagnostic font partie de la surface de contrôle

Le dossier public ne divulgue pas la première alarme interne, son horodatage, sa gravité, son propriétaire ni la qualité du diagnostic. Nous savons que les clients ont constaté une injoignabilité et qu’OVH a mobilisé des équipes. Nous ne savons pas si la surveillance a d’abord identifié la perte de transport optique, la défaillance de gestion, la perte de sessions de routage, l’effondrement du trafic ou les symptômes clients.

Cette preuve manquante importe, car la conception de la détection influence la durée de la panne. Une alarme indiquant « hôte injoignable » est moins utile qu’un enregistrement corrélé montrant l’état du contrôleur optique, la santé de la base de données, le mode des cartes, la joignabilité de gestion, l’état des interfaces des routeurs et la perte des chemins externes.

Les défaillances de contrôle communes peuvent également compromettre la surveillance. Si la carte de surveillance, le réseau de gestion ou le service de configuration partage le même domaine de défaillance, le système peut perdre à la fois le service et la télémétrie explicative. Les ingénieurs sont alors confrontés à une panne opaque: symptômes larges, accès distant incomplet et pression pour redémarrer les équipements avant que les preuves volatiles soient préservées.

Un chemin de diagnostic indépendant ne devrait pas signifier seulement une seconde interface sur le même plan de contrôle. Il devrait disposer d’un accès alimenté et géré séparément, de dépendances minimales, d’une frontière de sécurité connue et de la capacité de capturer l’état lorsque le système principal est altéré.

La conception exige aussi une autorité opérationnelle. Qui peut réinitialiser la configuration? Quelles preuves doivent être capturées en premier? Quelle version connue comme bonne peut être chargée? Quand une intervention locale est-elle nécessaire? Comment le risque d’un redémarrage est-il pesé par rapport à la panne continue? Un plan de récupération qui existe mais ne peut pas être autorisé rapidement n’est pas un contrôle efficace.

Le récit de Roubaix montre que la restauration du système optique a exigé plus que constater qu’une sauvegarde existait. [4] Cela transforme le temps de récupération en paramètre architectural. Si la restauration dépend du redémarrage et du séquençage de plusieurs composants, ces dépendances devraient apparaître dans les tests de résilience et les objectifs de service.

La réparation annoncée séparait la correction du défaut du contrôle du rayon d’impact

Le plan d’action formel d’OVH pour Roubaix comportait deux volets. Il prévoyait d’enquêter sur le défaut logiciel et de le corriger avec le fabricant de l’équipement par une mise à niveau. Il accélérait également un projet visant à répartir le système de multiplexage optique sur deux systèmes distincts afin de limiter l’étendue de la défaillance. [1]

Cette séparation est techniquement importante. La correction logicielle traite un défaut connu. La séparation architecturale traite l’incertitude, y compris la possibilité d’un autre défaut ou d’une autre défaillance de contrôle commune.

Un correctif logiciel ne peut pas prouver qu’une classe entière de défaillance a disparu. Il peut corriger un chemin dans le code tout en laissant inchangées les dépendances partagées de configuration, de supervision ou de gestion. Inversement, diviser des systèmes sans corriger un défaut connu peut produire deux systèmes défaillant indépendamment si le même logiciel et le même état sont déployés à l’identique.

Un programme de remédiation solide testerait donc les deux dimensions.

Correction du défaut

Relier l’avis du fournisseur ou l’enregistrement du défaut à la version logicielle concernée.
Identifier la condition de défaillance exacte, les composants affectés et le comportement corrigé.
Déployer l’image corrigée sur un système représentatif.
Vérifier la migration de configuration, la restauration en arrière et la préservation de l’état.
Exercer la condition qui avait provoqué la perte de configuration.
Conserver des journaux montrant que la défaillance ne se produit plus.

Séparation des domaines de défaillance

Documenter quels chemins optiques aboutissent sur chaque système.
Séparer le contrôle, la surveillance, le stockage de configuration et l’accès de gestion lorsque c’est nécessaire.
Empêcher qu’une seule transaction de configuration ne désactive les deux systèmes.
Garantir qu’un déploiement logiciel puisse être testé en canary et arrêté avant d’atteindre chaque chemin.
Prouver que la perte d’un système laisse suffisamment de capacité externe et de joignabilité pour l’objectif de service défini.
Tester le déplacement du trafic et la convergence du routage dans la topologie réduite.

Preuves de récupération

Restaurer une configuration connue comme bonne sans dépendre du composant de contrôle en panne.
Mesurer les temps de détection, de décision, de restauration, de retour des liaisons et de convergence des routes.
Préserver les sommes de contrôle avant et après et l’état de la topologie.
Comparer l’état interne des liaisons avec des sondes externes indépendantes.
Enregistrer les erreurs résiduelles plutôt que de déclarer la fin de l’alerte au premier ping réussi.

La déclaration publique d’OVH documente une intention de réaliser la séparation. Les sources figées pour cet article ne fournissent pas de date d’achèvement, de schéma d’implémentation, de test indépendant ni d’exercice de récidive ultérieur. La conclusion responsable est que la direction annoncée traitait la bonne distinction de contrôle, tandis que son efficacité reste non prouvée dans ce dossier.

Comment tester l’indépendance de la redondance

Un opérateur peut transformer l’incident en audit reproductible en construisant une matrice de domaines de défaillance. Chaque chemin pertinent pour le client est cartographié selon l’itinéraire physique, les nœuds optiques, les cartes de ligne, les châssis, les systèmes de supervision, les magasins de configuration, la version logicielle, le réseau de gestion, l’alimentation, la synchronisation, le groupe d’opérateurs et l’autorité de restauration.

La matrice devrait répondre à une question simple pour chaque paire de chemins « redondants »: quels composants peuvent encore supprimer les deux?

Cette analyse révèle souvent des dépendances cachées par les schémas de topologie. Des fibres séparées peuvent entrer dans le même bâtiment. Des châssis séparés peuvent utiliser un même contrôleur. Des contrôleurs séparés peuvent partager un même cluster de base de données. Des instances logicielles séparées peuvent recevoir une même mauvaise configuration d’un pipeline d’automatisation commun. Des centres de données séparés peuvent dépendre d’un même DNS, d’une même identité ou d’un même service de contrôle réseau.

La matrice n’est qu’une hypothèse tant qu’elle n’est pas testée. Les tests utiles comprennent:

retirer une fibre physique et vérifier la protection optique automatique;
retirer un châssis et vérifier que la capacité reste dans l’objectif déclaré;
isoler un contrôleur et vérifier que l’autre système continue sans convergence d’état dangereuse;
corrompre ou retenir une réplique de configuration et vérifier la sélection sûre;
refuser le chemin de gestion principal et effectuer le diagnostic par le chemin indépendant;
déployer une image logicielle délibérément rejetée sur un canary et vérifier le confinement du déploiement;
restaurer une configuration connue comme bonne sous pression temporelle;
mesurer la convergence BGP et du plan de données depuis des réseaux indépendants;
vérifier que l’état visible par les clients reflète le service observé, et pas seulement la santé des équipements;
conserver des preuves suffisantes pour qu’un examinateur externe puisse reproduire la conclusion.

La condition de réussite doit être définie avant le test. « Le trafic est revenu » est trop vague. Une condition utile précise la capacité minimale, la perte de joignabilité maximale, la perte de paquets autorisée, le temps de convergence, les classes de service, les points d’observation externes et les exigences de conservation des preuves.

Les tests doivent également tenir compte de la maintenance. De nombreuses pannes courantes surviennent lors de mises à niveau ou de changements de configuration, lorsque les systèmes redondants sont intentionnellement alignés. Une conception qui survit à une perte de carte aléatoire peut échouer lorsqu’une tâche d’automatisation commune pousse le même mauvais état des deux côtés.

Un fonctionnement indépendant n’exige pas que chaque composant soit différent. Une hétérogénéité complète peut accroître la complexité et les erreurs. Il exige que les dépendances partagées soient explicites, bornées et assorties d’une récupération testée. Le but n’est pas un théâtre de diversité. C’est la preuve qu’une défaillance plausible ne peut pas silencieusement neutraliser chaque chemin présenté comme redondant.

Les contrôles contrefactuels clarifient les premières occasions manquées

L’analyse contrefactuelle ne doit pas prétendre qu’un contrôle aurait certainement empêché l’événement. Elle demande où des contrôles observables auraient pu modifier la séquence.

Si le défaut logiciel avait été détecté avant le déploiement

Un environnement de préproduction représentatif, un déploiement canary ou un test de défaut du fournisseur aurait pu exposer l’état défaillant avant qu’il n’atteigne le système de production. Les preuves publiques ne nous disent pas si le défaut exigeait une séquence rare impossible à reproduire en préproduction. Ce contrefactuel est donc possible, mais non prouvé.

Si les systèmes optiques avaient un état de contrôle indépendant

Si deux groupes de chemins avaient des autorités de configuration et des systèmes de supervision séparés, la perte d’une base de données de configuration aurait pu laisser l’autre groupe opérationnel. La séparation des systèmes annoncée par OVH suggère que l’entreprise voyait de la valeur à réduire le périmètre de défaillance commun. La topologie exacte avant l’incident n’étant pas publique, l’ampleur du contrefactuel ne peut pas être calculée.

Si la restauration de configuration disposait d’un chemin indépendant

Une configuration connue comme bonne, immuable, et un mécanisme de restauration hors bande auraient pu réduire le temps de diagnostic et de récupération. Le récit de l’incident indique que la configuration sauvegardée a finalement été restaurée. Il ne montre pas si un chemin de restauration indépendant existait, comment il était testé ni quelle part de la récupération dépendait de l’environnement de contrôle affecté.

Si les clients disposaient de chemins d’hébergement indépendants

Un client utilisant un autre centre de données ou fournisseur aurait pu éviter une partie de l’impact de service. Actility a signalé qu’une offre SaaS située dans un autre centre de données n’était pas affectée. [4] Cette observation soutient la diversification des dépendances, mais elle ne prouve pas que toute conception multi-sites aurait réussi.

Si les preuves de joignabilité externe avaient été intégrées

Des sondes indépendantes et des observations de routage auraient pu aider à distinguer la récupération locale des équipements de la joignabilité des clients. Elles n’auraient pas restauré les liaisons optiques. Leur valeur aurait été un diagnostic plus rapide, une communication mieux délimitée et une preuve de clôture plus solide.

La première occasion manquée ne peut pas être nommée de manière concluante à partir des preuves publiques. Il peut s’agir de l’assurance logicielle, de l’architecture, de la protection de l’état de configuration, de la surveillance, de la conception de la récupération ou d’une combinaison. Un dossier d’incident privé devrait identifier le contrôle le plus précoce qui avait à la fois l’autorité et la possibilité raisonnable d’agir.

Les preuves qui modifieraient la conclusion

La conclusion est délibérément réfutable. Elle devrait changer si des preuves plus solides deviennent disponibles.

Les journaux des équipements et des contrôleurs pourraient montrer que la perte de configuration était une conséquence plutôt qu’une cause. Un rapport de fournisseur pourrait identifier une condition matérielle ou logicielle spécifique. Les enregistrements de topologie pourraient montrer que les chemins optiques étaient plus indépendants que ne le laisse entendre le récit public, ou qu’un autre composant partagé les a supprimés. Les historiques de configuration pourraient montrer qu’un changement humain, une tâche d’automatisation ou une transition d’état a déclenché l’événement.

Les données des clients et des mesures pourraient réviser la frontière de l’impact. Une analyse de joignabilité complète pourrait montrer un isolement quasi universel de Roubaix, ou une connectivité restante substantielle. Les données des collecteurs BGP pourraient établir quelles sessions et quels chemins externes ont changé, mais il faudrait encore des mesures du plan de données pour soutenir les conclusions sur l’acheminement.

Les preuves de remédiation pourraient renforcer ou affaiblir la conclusion de responsabilité. Une séparation des systèmes achevée, testée indépendamment sous des pannes de contrôleur et de configuration, montrerait qu’OVH a transformé la leçon en confinement. Un test ultérieur montrant que les deux systèmes partageaient encore un seul domaine de défaillance montrerait que la duplication n’avait pas produit l’indépendance.

L’article n’exige pas ces enregistrements pour affirmer qu’une panne réseau grave s’est produite. Il les exige pour rendre complète l’allégation de réparation.

Conclusion

La panne de Roubaix d’OVH n’a pas été une leçon selon laquelle la redondance est vaine. Elle a été une leçon selon laquelle la redondance doit être décrite en fonction des pannes qu’elle peut contenir.

Le fournisseur disposait d’une connectivité optique redondante et d’une configuration sauvegardée. Ces contrôles traitaient des risques réels. Ils n’ont pas empêché une défaillance commune du contrôle optique de supprimer la connectivité de Roubaix, et la restauration dépendait encore de la récupération de la configuration.

Le plan d’action ultérieur d’OVH reconnaissait les deux niveaux du problème: corriger le défaut logiciel et diviser le système de multiplexage optique afin qu’une seule défaillance ait un périmètre plus réduit. C’était la bonne séparation conceptuelle. Les preuves publiques de cet ensemble de sources ne prouvent ni l’achèvement ni la résistance à la récidive.

Pour les opérateurs d’hébergement et de réseau, la norme de responsabilité est concrète. Nommer les classes de défaillance protégées. Cartographier les domaines de contrôle partagés. Préserver un diagnostic indépendant et une récupération connue comme bonne. Tester la perte d’un système pendant que l’autre transporte le trafic. Mesurer la joignabilité depuis l’extérieur du fournisseur. Publier suffisamment de preuves pour distinguer la duplication de composants de l’indépendance opérationnelle.

Les enregistrements d’identité réseau et les inventaires de topologie peuvent montrer qui exploite l’infrastructure et ce qui est censé exister. Seules les preuves du code en exécution, la joignabilité observée et la restauration testée montrent si l’infrastructure continue de fonctionner.

La panne du réseau optique d’OVH en 2017 a fait de l’indépendance de la redondance un test de responsabilité