Résumé

  • APNIC avait prévu trois heures de maintenance de sécurité à Brisbane le 15 octobre et prévenu que les services concernés pourraient subir jusqu’à cinq minutes d’interruption.
  • Son historique indique maintenant 2 h 56 de maintenance pour DASH et 1 min 2 s pour le dépôt RPKI, sans mesurer la durée d’une éventuelle perte d’accès.

Le registre public en dit maintenant davantage sur la fenêtre de travaux qu’un simple indicateur de disponibilité, mais moins qu’un bilan d’impact. APNIC avait programmé des mises à jour de sécurité de ses équipements réseau dans ses centres de données de Brisbane, de 06:00 à 09:00 UTC+10 le 15 octobre, soit de 20:00 à 23:00 UTC le 14 octobre. L’avis évoquait des interruptions possibles pouvant durer jusqu’à cinq minutes.

L’historique des services d’APNIC marque désormais deux entrées de maintenance comme terminées. Celle de DASH va de 20:03:29 à 23:00:00 UTC; la durée affichée est de 2 h 56. Une entrée distincte pour le dépôt RPKI court de 21:51:30 à 21:52:32, soit 1 min 2 s. Les deux mises à jour « en cours » renvoient à l’avis du 15 octobre.

Ces durées correspondent à des lignes intitulées « Network maintenance ». Elles ne mesurent pas le temps pendant lequel DASH ou le dépôt aurait été inaccessible. Les cinq minutes de l’avis sont une interruption possible, pas une durée constatée de perte de service. L’historique ne fournit pas, à côté de ces lignes, les échecs de sondes, les opérations d’utilisateurs touchées, les résultats de transactions ni un test de rétablissement pour chaque composant.

Le moment de la consultation compte aussi. Lors d’une vérification antérieure à 09:16 UTC+10, l’événement apparaissait toujours comme à venir et les valeurs de disponibilité indiquaient 100 %; l’historique actuel affiche désormais des entrées de maintenance achevées pour certains composants. Ces nouvelles lignes précisent la chronologie de l’état de maintenance, mais ne constituent pas un calcul rétrospectif de disponibilité. APNIC n’explique ni pourquoi l’entrée DASH couvre presque toute la fenêtre annoncée, ni si ses utilisateurs ont subi une interruption.

L’avis citait des services membres, API, Web, RPKI et d’autres. Les opérateurs doivent donc distinguer l’enregistrement de la maintenance d’une panne ou d’un rétablissement de service. Ces lignes ne prouvent ni interruption de publication RPKI, ni effet sur le routage, ni préjudice pour les membres, ni indisponibilité de l’un des deux composants.

Sources : l’avis de service APNIC du 15 octobre, APNIC Services Status et le précédent article de Theo March sur le calcul de disponibilité public d’APNIC.