要約

  • RIPE NCCは10月7日09:46 CEST、RIPE DatabaseのWebアプリへの一部リクエストが502エラーになったと発表。09:47に修正を反映して監視中とし、10月8日10:21 CESTに解決とした。
  • 24時間34分は「監視中」から「解決」までの公開ステータス間隔だ。エラーがその間ずっと続いたこと、失敗件数、別の照会経路の稼働状況は示していない。

状態の経過時間は、障害の継続時間ではない

公開記録にあるのは、最初の告知、1分後の監視入り、翌朝の解決という三つの節目だ。RIPE NCCが示した範囲は「一部リクエスト」にとどまり、対象エンドポイント、操作、原因は書かれていない。告知間の1分は投稿時刻の差であり、問題を発見してから修正するまでの時間を示すものではない。

10月7日09:47 CESTから10月8日10:21 CESTまでは24時間34分。この時間が表すのは、公開ページが「監視中」から「解決」に移るまでだ。最初に失敗したリクエスト、最後に失敗したリクエスト、修正後にエラーが続いたかどうかは記録されていないため、実際の影響時間とは言えない。

RIPE Databaseの文書では、Web検索フォームはWebupdatesも含むWebインターフェースの一部とされている。今回どのリクエストや機能が対象だったかは告知にないので、検索や更新のどちらかが失敗したとは断定できない。RESTクエリは別に説明されているが、文書上の区分だけで、今回RESTやコマンドラインが利用できたとは確認できない。

運用者に必要なのは、どの経路がどの結果を返したかだ。ブラウザーのリクエスト失敗だけで、登録レコードの変更、消失、破損を示すわけではない。逆に、一部Webリクエストの告知からデータベース全体の停止を推論することもできない。公開記録はデータ損失や侵害を報告していないが、クライアント側の影響も数値化していない。

根拠から言えるのは、Webアプリへの一部リクエストで502が報告され、修正後に監視され、のちに解決扱いとなったことだ。現在のステータス画面がRIPE Databaseを稼働中と表示していても、それは確認時点の状態であり、10月7日の再現ではない。利用者は公開状態を追える一方、実際にエラーが出た時間幅と規模は分からない。

出典