要約

  • 9月15日はMyAPNICの一部コンポーネントへの設定変更が想定以上に他機能へ波及した。17日はデータベース問題により、チケットシステム宛てメールが遅れ、一部機能が利用不能になった。
  • 同じ28分という長さと時間的近さは、共通原因の証拠ではない。必要なのは、依存経路を比較し、関連を発見したのか、除外したのか、未確定なのかを示す公開記録だ。

APNICの9月15日の告知によると、MyAPNIC会員ポータルの障害はUTC+10で13時58分から14時26分まで続いた。説明されているのは、あるコンポーネントの設定変更が、他のMyAPNIC機能へ予想より広く影響したという事実である。APNICは同種の変更による再発を防ぐ修正に取り組むとしている。

9月17日の告知は、14時50分から15時18分までの別の28分を記録する。直接要因はデータベース問題で、チケットシステムに送られたメールが遅延し、MyAPNICの一部機能が利用できなくなった。対策はデータベース監視の改善である。

二つの説明は混同してはならない。一方は設定変更の影響範囲、もう一方はデータベース問題を扱う。最初の障害が次を引き起こした、同じコンポーネントやデータベースを共有した、データ損失やセキュリティ侵害、経路制御への影響があった、とする記述はない。

開始時刻の差は48時間52分である。等しい所要時間は、検知やエスカレーション、復旧の共通した運用周期を反映する可能性がある。一方で偶然でもあり得る。照合を始める理由にはなるが、因果関係の結論にはならない。

公表資料からは、認証、キュー、データストア、設定基盤、展開経路、監視の死角、担当者間の引き継ぎを横断確認したかが分からない。確認した結果、共通要因を見つけたのか、除外したのか、なお不明なのかも分からない。

内部構成を明かさずに、この空白は埋められる。プライバシーに配慮した相関確認票には、二つの障害ID、影響を受けた機能分類、証拠期間、調査した依存領域を記せばよい。結論は「発見」「除外」「未確定」の三状態で足りる。是正措置の責任者、封じ込め状況、次回確認日も、ホスト名、認証情報、会員データ、チケット本文、個人名を出さずに示せる。

二つの局所対策は代替関係にない。設定変更の波及を抑えてもデータベース検知は改善しない。監視を増やしても変更の影響範囲は自動的に小さくならない。独立性を確認済みなら公表が両方の対策を補強する。共通面があれば横断措置が必要だ。判断できないなら、未確定と残すこと自体が重要である。

情報源