要約

  • RIPE NCCは8月22日17時56分（CEST）、予定終了時刻より二時間以上早くAlfresco保守を完了とした。
  • 24日の障害では文書作成は稼働したまま、一部の表示・ダウンロードができなくなり、約一時間後に解決した。
  • 26日には別の障害記録で文書処理の遅延が報告され、27日の設定更新、監視を経て16時21分に解決した。
  • 公開記録が示すのは順序と同一システムであり、因果関係ではない。変更受入れ、操作別試験、再発評価、案件照合を結ぶ公開記録が欠けている。

保守の終了と利用者の完了は別物だ

22日の計画は、単なるバックオフィス作業ではなかった。RIPE NCCによれば、Alfrescoは会員関連文書を保存するシステムである。保守中はLIR PortalとAlfrescoが利用できず、会員申請、資源移転、資源申請、合併・買収手続、さらにチケット作成に依存する処理を完了できない。予定時間は08時から20時だった。

実際の終了通知は17時56分に出た。LIR Portalの公開コンポーネントは保守中から稼働中へ戻り、「計画保守は完了した」と記録された。これは作業の終了を示すうえで正しい。しかし、どの利用操作を試したのかまでは語らない。更新後に文書を作成したのか、既存文書を検索・表示・ダウンロードしたのか、権限の異なる担当者で既存チケットを取得したのかは分からない。

24日の通知は、その空白を逆方向から明らかにした。15時00分、新規文書の作成は正常だが、一部文書を表示またはダウンロードできないとRIPE NCCは説明した。資源移転、資源申請、合併・買収、チケット取得を伴うその他の処理が影響対象だった。16時00分には解決となった。

26日13時24分、同じ名称の障害がもう一度登録された。今回は、あらゆる申請種別に関係する文書処理、合併・買収、資源移転に遅れがあるという説明だった。27日10時55分、システム設定を更新して結果を監視していると発表し、16時21分に解決した。

保守完了、障害解決、コンポーネント稼働は、見た目には同じ緑でも意味が異なる。変更作業が終わったこと、観測された症状が止まったこと、コンポーネント全体の状態をそれぞれ表す。どれも単独では、業務上必要な全操作を検査したとも、止まった案件をすべて回収したとも証明しない。

原因を決めずに関係を記録する

更新の直後に二つの障害があれば、更新が原因だと考えたくなる。だが、公開資料はそこまで述べていない。

24日の障害には根本原因がない。後の障害には設定変更が登場するが、どの項目を変えたのか、22日の更新と結び付くのか、一度目と二度目が同じ仕組みで起きたのかは示されない。共通原因、別原因、偶然の近接という三つの可能性はいずれも残る。

運用記録は、この不確実性を消すのではなく状態として持つべきだ。変更との因果関係を「未確認」、再発判定を「調査中」とできる。利用機能の復旧時刻と、原因分析の終了時刻を分けることもできる。そうすれば、時系列を根拠のない非難に変えず、かといって調査すべきつながりを失わない。

一度目の障害が示した作成と取得の分離も重要である。文書管理には書込み、索引、検索、表示、ダウンロード、権限確認、案件への紐付けがある。Portalが開いていても、判断材料を取り出せなければ手続は進まない。受入れ試験はコンポーネント名ではなく、利用者が行う動詞で記述する必要がある。

「完了」が試した範囲を残す

公開記録に内部構成や文書名を載せる必要はない。ソフトウェアのビルドと設定の指紋を残し、作成、取得、表示、ダウンロード、代表的権限、既存チケット取得の各試験について、件数と通過時刻だけを示せばよい。詳細な証跡は保護領域に置き、公開側から識別子で参照できる。

直後の受入れと、その後の観察期間も区別すべきだ。週末は変更に向くが、平日の負荷、担当者、既存案件の組合せまでは再現しにくい。保守を完了させつつ、変更後監視を継続中とする二段階の状態なら、月曜日の障害を同じ記録に接続できる。接続は原因の断定ではない。

さらに必要なのが案件照合である。文書を再び取得できても、待っていた資源移転や申請が自動的に正しい工程へ戻るとは限らない。再試行で進む案件もあれば、手作業が要る案件もある。個人情報を出さずに、影響範囲、再実行、手動確認、未解決の件数を公表できる。

狭い台帳だからこそ、自らの履歴を狭く正確に

ここで求めるのは無停止の約束ではない。RIPE NCCのような組織が最も得意であるべき、状態の正確な保存である。

一つの継続記録に、保守ID、ビルド・設定指紋、操作別試験、受入れ時刻、観察期間、二つの障害ID、影響を受けた処理、因果・再発の判定状態、設定変更、滞留案件の照合結果を結べる。公開層は分類と集計だけでよく、会員文書、取引内容、内部構成を出す必要はない。

この方法はRIPE NCCにとっても防御になる。後の障害が起きても、以前の受入れを全否定する必要がなくなる。当時確認した範囲と、後で見つかった範囲を別々に説明できるからだ。完全性を演出するより、検証境界を示す方が信頼は長持ちする。

確認できる結論は限定的である。計画保守は完了し、翌週に一部文書の表示・ダウンロード障害と文書処理の遅延が相次いで記録され、どちらも解決した。特定の会員、文書、番号資源への損害も、共通原因も公表されていない。残る課題は、「完了」が検証した操作と、後の二件をどう関連付け、滞留した業務をどう照合したかを示す受領記録である。

情報源