Résumé

  • Le 23 décembre 2019, une panne matérielle associée à une erreur de configuration a fait échouer le basculement des machines virtuelles d’ARIN. Le site public et ARIN Online ont été rétablis par deux voies et à deux heures différentes.
  • Le conseil d’administration a ensuite demandé des rapports d’infrastructure, un plan de correction et une meilleure visibilité sur les services. Le dossier montre un suivi plus structuré, mais ne certifie pas que chaque risque a disparu ni qu’un objectif de reprise a été vérifié.

Une redondance qui n’a pas suffi

Le 23 décembre, à 12 h 35, les systèmes de surveillance d’ARIN ont signalé plusieurs machines virtuelles utilisées par des services destinés aux clients. L’équipe a tenté de les basculer manuellement sur du matériel de secours. Cette opération a échoué. À 12 h 55, le site d’ARIN et l’application client ARIN Online étaient hors service. Le compte rendu public cite ces deux surfaces; il ne décrit pas l’état de chaque autre service du registre.[4]

L’équipe a alors examiné les machines virtuelles et travaillé avec les fournisseurs. Le stockage partagé du cluster est apparu comme la cause probable. Dans son analyse après incident, ARIN a décrit une défaillance matérielle combinée à une mauvaise configuration de l’équipement de stockage, qui avait empêché le moteur de virtualisation de fonctionner. Le composant défaillant a été remplacé, la configuration corrigée a été validée avec le fournisseur et le cluster est revenu en service.[4]

Cette combinaison est plus instructive qu’une explication réduite à une « panne matérielle » ou à une faute du fournisseur. Le système avait des composants redondants, mais le chemin de basculement dépendait d’un stockage partagé. La défaillance d’un élément commun a donc pu neutraliser les machines principales et la tentative de transfert vers le matériel de secours. La redondance ne protège que contre les pannes que l’architecture sépare réellement.

Le compte rendu ne permet pas d’affirmer que toutes les fonctions d’ARIN étaient indisponibles. Il cite le site web et ARIN Online; il ne précise pas si Whois, RDAP, l’IRR, RPKI, DNS ou les données d’enregistrement étaient touchés ou restaient accessibles. Le silence sur un service n’est ni une preuve de panne ni une preuve de disponibilité.[4]

Deux incidents, deux questions distinctes

En janvier 2019, le conseil avait déjà examiné une interruption du domaine ARIN.NET pour des parties qui validaient DNSSEC. John Curran avait présenté le post-mortem et annoncé qu’il rencontrerait le directeur technique afin d’aligner les systèmes jugés essentiels à la mission. La présidence du conseil avait demandé un rapport une fois ce travail terminé. Le procès-verbal ne donne ni la durée de l’incident, ni sa cause, ni le résultat de ce suivi.[3]

Cet épisode ne doit pas être confondu avec la panne de stockage de décembre. Le dossier ne montre pas de cause commune. Il illustre plutôt deux frontières de service: un problème de validation DNS et, plus tard, la perte d’un cluster hébergeant le site et l’application client. Le fait que Curran ait informé le conseil dans les deux cas ne transforme pas ces incidents en une seule histoire technique.

Le rétablissement s’est fait par étapes

À 15 h 30, alors que la réparation se prolongeait et que son échéance restait incertaine, l’équipe a décidé de transférer le site web vers le site de reprise après sinistre. Le site a été rétabli à 16 h; ARIN Online l’a été à 17 h 10. Cette différence de 70 minutes est importante: une page publique disponible ne signifiait pas que l’application utilisée par les clients l’était aussi.[4]

Le composant défaillant a été remplacé le 2 janvier et le cluster a repris son fonctionnement. Le retour du site dans le centre de données principal aurait exigé une nouvelle interruption; ARIN l’a donc associé à une fenêtre de maintenance déjà prévue le 25 janvier. Il faut distinguer ces jalons: la reprise du service, le remplacement du composant, le retour au site principal et la clôture de toutes les mesures correctives ne sont pas synonymes.[4]

Le choix du site de reprise a limité l’attente d’une réparation dont la durée ne pouvait plus être estimée. Le compte rendu indique que ce site était maintenu et testé, mais ne publie ni objectif chiffré de reprise ni calcul du seuil ayant déclenché le basculement. La preuve disponible est donc précise sur les heures et les décisions, mais incomplète sur les objectifs de service.

Ce que le rôle de Curran permet de lui attribuer

ARIN distingue les responsabilités institutionnelles. Le conseil fixe le périmètre et la mission de l’organisation et participe, avec la direction, à son orientation stratégique et à sa surveillance financière. Le président-directeur général conduit les opérations avec le personnel. Il nomme et supervise les équipes opérationnelles, siège au conseil et fait le lien avec le Conseil consultatif.[1][2]

La biographie de Curran mentionne son expérience de CTO dans plusieurs entreprises Internet et son rôle au conseil fondateur d’ARIN à partir de 1997. Il a présidé le conseil jusqu’en 2009, année où il est devenu président-directeur général.[1] Cette expérience éclaire son rapport aux systèmes, mais elle ne prouve pas qu’il ait diagnostiqué la panne de stockage ou manipulé les équipements. Le récit technique de décembre est signé par Richard Jimmerson, directeur des opérations, et attribue l’alerte, le dépannage, les relations avec les fournisseurs et la restauration aux équipes opérationnelles.[4]

Les procès-verbaux situent plutôt Curran à l’interface entre exploitation et contrôle. Il a complété les informations présentées au conseil en janvier 2020. Le conseil a demandé un rapport d’infrastructure, une accélération des mesures de long terme, le renforcement de la reprise après sinistre et une évaluation du risque d’indisponibilité.[5] Ce partage permet de parler de responsabilité exécutive sans transformer l’incident en récit d’un dirigeant qui aurait « sauvé » le système.

Du post-mortem aux rapports récurrents

Le 25 mars 2020, le directeur des opérations a indiqué qu’un compte rendu complet suivrait en avril, que les documents étaient en préparation et que la date visée pour les mesures correctives était la fin de l’année. Le travail était alors déclaré dans les délais.[6] En mai, les procès-verbaux signalent un rapport achevé sur les mesures correctives et un supplément consacré à l’infrastructure. Le conseil voulait que les systèmes soient reliés aux fonctions métier, que les actions comportent des dates de début et de fin et que le suivi devienne trimestriel.[7]

La demande va au-delà du récit d’une panne. Un conseil ne peut pas arbitrer correctement entre coût, risque et continuité s’il reçoit seulement une liste de matériel ou une formule générale de disponibilité. Il doit savoir quelle fonction dépend de quel système, qui porte la mesure corrective et comment un changement sera vérifié. Curran a indiqué qu’il préparait des principes et des échéances pour évaluer l’externalisation des solutions techniques.[7]

Ces minutes prouvent qu’un dispositif de suivi a été présenté et que la direction a annoncé une échéance. Elles ne reproduisent pas le dossier technique complet et ne permettent pas de vérifier chaque test de basculement. En février 2021, le conseil a demandé des mesures plus utiles sur la performance des systèmes et le service aux clients, évoqué des niveaux de service, un cadre portant sur disponibilité et fiabilité et une cartographie des dépendances. Les procès-verbaux ne donnent pas d’objectif public chiffré pour la panne de 2019.[8]

Un statut public n’est pas une preuve de reprise

En avril 2021, ARIN a lancé une page d’état des services couvrant notamment ARIN Online, les services de provisionnement, Whois, RDAP, RPKI, IRR, les listes de diffusion, les rapports et le site web. Les abonnés pouvaient recevoir des notifications par courriel, SMS, Slack ou d’autres canaux. L’annonce indique que cette page répondait à la proposition communautaire ACSP 2020.5 et porte la signature du CTO Mark Kosters.[9]

Une page d’état répond à la question « quel service l’opérateur dit-il touché? » Elle ne remplace pas un site de reprise, une mesure d’uptime ou un accord de niveau de service. La chronologie ne prouve pas non plus que la page ait été créée spécifiquement à cause de l’incident de décembre; ARIN la relie à une proposition communautaire. Elle améliore néanmoins la capacité des utilisateurs à distinguer les services et à suivre les mises à jour.

En 2022, le directeur des opérations a indiqué au conseil que des changements d’organisation et des améliorations d’infrastructure avaient réduit le risque auparavant associé à l’environnement NetApp, et qu’ARIN avait migré vers d’autres fournisseurs.[10] C’est une déclaration de gestion consignée dans un procès-verbal, pas un audit indépendant de tous les contrôles de 2019. Le rapport annuel 2025 maintient la qualité et la régularité des services parmi les objectifs d’ARIN, mais ne publie pas de mesure de reprise relative à cet incident.[1][11]

Ce que le dossier établit — et ce qu’il ne tranche pas

Le dossier public permet d’établir une séquence: le basculement des machines virtuelles a échoué; le site et l’application ont été indisponibles; un site de reprise distinct a rétabli le premier avant la seconde; le matériel et la configuration ont été corrigés; le conseil a demandé des rapports et une analyse de risque; des rapports récurrents et une page d’état ont ensuite rendu l’exploitation plus lisible.[4][5][6][7][8][9]

Il ne prouve pas que tous les services d’ARIN étaient touchés, qu’ils étaient tous disponibles, que chaque mesure demandée a été clôturée à la date prévue ou que le risque de répétition a été mesuré indépendamment. Cette limite n’est ni une accusation ni un certificat de bonne santé. Elle décrit simplement ce que les sources étudiées permettent de soutenir.

Pour un opérateur réseau, la distinction est concrète. Une page web, une application d’administration, un service de provisionnement, une publication RPKI et une base d’enregistrement n’ont pas les mêmes dépendances ni les mêmes solutions de repli. L’indisponibilité de l’un ne dit pas automatiquement ce qui arrive aux autres. Les équipes clientes doivent connaître la fraîcheur de leurs données en cache, savoir quand suspendre une opération et s’abonner aux alertes avant une panne.

Pour ARIN, l’étape suivante consiste à relier les rapports à des mesures par service: temps de rétablissement, couverture des tests de reprise, dépendances communes et clôture des actions après incident. Le registre public montre que le conseil a demandé des indicateurs et une carte des dépendances. Un nouveau matériel, un tableau de bord ou une mention « rétabli » ne prouve pas à lui seul qu’un chemin de reprise a été testé contre la panne qui a causé l’incident.

Curran doit donc être évalué à partir des mécanismes visibles: les dépendances deviennent-elles compréhensibles pour le conseil? Les mesures correctives ont-elles un responsable et une échéance? Les utilisateurs peuvent-ils distinguer l’état d’un service de celui d’un autre? Les sources montrent une amélioration du suivi et de la visibilité après 2019, mais pas un tableau de bord public qui clôt chaque point. La responsabilité du dirigeant est d’organiser ces preuves; le travail technique demeure celui des équipes qui exploitent les systèmes.[5][6][7][8][9]

Conclusion: une résilience mesurable service par service

La panne du 23 décembre 2019 a montré qu’une architecture qualifiée de redondante pouvait perdre son chemin de basculement lorsque des composants partageaient une dépendance de stockage. Le site web et ARIN Online ont été restaurés séparément. Le conseil a ensuite demandé une analyse d’infrastructure, un plan de reprise et une meilleure évaluation du temps d’indisponibilité.[4][5]

Le rôle documenté de Curran est exécutif et institutionnel: compléter les informations soumises au conseil, porter des documents dans le processus de suivi et faire évoluer la manière dont les performances et les dépendances sont présentées. Les équipes opérationnelles ont diagnostiqué et restauré les services. Les comptes rendus ultérieurs décrivent des améliorations d’infrastructure, de nouveaux rapports et une page publique d’état. Aucun de ces éléments ne doit être transformé en preuve d’une disponibilité garantie.[1][2][5][7][8][9][10]

La leçon dépasse ARIN: l’autorité d’un registre et sa fiabilité opérationnelle sont deux sujets différents. Pour évaluer la continuité, il faut nommer le service touché, la dépendance qui a échoué, le chemin de reprise, l’heure du retour et la preuve que le correctif a été testé. Le dossier ARIN rend plusieurs de ces éléments visibles; il laisse aussi des questions ouvertes. La conclusion la plus solide reste celle-là: une réputation, une architecture redondante ou une page d’état ne remplacent pas une preuve de reprise propre à chaque service.

Sources

  1. ARIN Board of Trustees and John Curran biography
  2. ARIN Organization Structure & Staff
  3. Board of Trustees Meeting Minutes — 16 January 2019
  4. Richard Jimmerson, “Operations at ARIN: New Blog Series and Recent Outage Information,” 19 March 2020
  5. Board of Trustees Meeting Minutes — 22–23 January 2020
  6. Board of Trustees Meeting Minutes — 25 March 2020
  7. Board of Trustees Meeting Minutes — 21 May 2020
  8. Meeting of the ARIN Board of Trustees — 3 February 2021
  9. ARIN, “New ARIN Service Status Page Available,” 5 April 2021
  10. Meeting of the ARIN Board of Trustees — 4 August 2022
  11. ARIN 2025 Annual Report
  12. Référence visuelle d’identité uniquement : photographie officielle de John Curran publiée par ARIN. Elle sert uniquement à ancrer le portrait éditorial généré par IA et ne constitue pas une preuve des faits opérationnels.