要約

  • APNICは10月15日にブリスベンで3時間のネットワーク安全保守を予定し、対象サービスには最大5分の中断があり得ると告知した。
  • 現在の状態履歴にはDASHの2時間56分、RPKI Repositoryの1分2秒の保守記録があるが、各サービスが実際に利用できなかった時間は示されていない。

公開記録は、可用性の割合だけよりも作業時間帯を詳しく伝えるようになったが、影響報告には届いていない。APNICは10月15日、ブリスベンのデータセンターでネットワーク機器の安全更新を06:00から09:00（UTC+10）まで実施する予定だった。UTCでは10月14日の20:00から23:00に当たる。告知は、列挙したサービスに最大5分の中断が起きる可能性を示していた。

APNICの状態履歴は、関連する二つの保守記録を完了済みとしている。DASHの記録は10月14日20:03:29 UTCから23:00:00までで、表示時間は2時間56分。別のRPKI Repositoryの記録は21:51:30から21:52:32まで、1分2秒だ。どちらの進行中アップデートも10月15日の告知にリンクしている。

この時間は「Network maintenance」と表示された記録の長さである。DASHやリポジトリがその全時間、アクセス不能だったことを意味しない。告知の5分も、起きた中断の実測値ではなく可能性の説明だ。状態履歴には、失敗した監視チェック、影響を受けた利用者の操作、取引結果、コンポーネントごとの復旧テストは併記されていない。

確認した時点にも意味がある。以前の09:16（UTC+10）の確認では、イベントは「Upcoming Maintenance」と表示され、稼働率は100%だった。現在の履歴には、コンポーネント別の完了済み保守記録が載っている。追加された記録は保守状態の時系列を補うが、可用性を遡って計算したものではない。DASHの記録がなぜ告知時間のほぼ全体を占めるのか、利用者に中断があったのかは説明されていない。

告知は会員向け、API、Web、RPKIなどのサービス群を挙げていた。運用者に必要なのは、保守の記録時間とサービス障害・復旧の時間を区別することだ。この二つの記録から、RPKIの公開停止、経路への影響、会員の損失、あるいはいずれかのコンポーネントの停止を確認することはできない。

出典：APNICの10月15日サービス告知、APNIC Services Status、APNICの公開稼働率計算を扱ったTheo Marchの前稿。