【ITニュース解説】The Rehearsal Layer — Or, an Escrow You Have Never Opened Is Indistinguishable from No Escrow

システム開発において、万が一の事態に備えて、システムのソースコードや構築手順、必要な設定情報などを一式まとめて保管しておくことを「エスクロー」と呼ぶ場合がある。これは、例えば開発ベンダーが事業を継続できなくなった際や、システムに重大な問題が発生したときに、顧客が自力でシステムを復旧・運用できるようにするための重要な備えである。しかし、このエスクローが実際に機能するかどうかを確認しないまま放置されているケースが少なくない。

記事は、開けたことのないエスクローは、存在しないのと同じであるという核心を突いている。これは、エスクローがあるという事実と、それが実際に使えるという事実が全く異なることを意味する。例えば、二つの会社を比較してみよう。一方の会社Aは、ソースコード、構築環境、資格情報の更新手順、核となるシステムドキュメントなど、必要なものが完璧に揃ったエスクローを2年前に作成し、一度も開けていない。もう一方の会社Bは、「エスクロー2024」というフォルダに、すでに内容が二度も書き換えられた古いコードのアーカイブと、使われていないベンダーに関する三つのPDFファイルが保存されている。

外部から見ると、どちらの会社も「エスクローがあります」と答えるため、区別はつかない。しかし、実際にシステムに問題が発生し、このエスクローが必要になったその日に、両者の違いは決定的なものとなる。会社Aは、その日初めてエスクローの中身を検証し、何が使えるか、何が更新されていないかを発見するのに数時間かかるだろう。対して会社Bは、そのエスクローが全く役に立たないことをその瞬間に思い知る。この決定的な違いを、顧客や事業を失うような緊急事態ではなく、平穏な時に事前に発見し、修正するための活動こそが「リハーサル」なのだ。

では、なぜ多くの組織がこの重要なリハーサルを実施しないのだろうか。その理由は経済的要因が大きいと指摘されている。リハーサルには、エンジニアの人件費や検証環境の準備費用など、確実なコストが今すぐに発生する。しかし、そのリハーサルによって得られる利益、つまり将来起こるかもしれないインシデントの被害を最小限に抑えるという効果は、不確実で遠い将来に訪れるものだ。さらに、リハーサルが成功してインシデントが回避されたとしても、「起きなかったインシデント」に対して誰も評価を受けることはない。これが、リハーサルが後回しにされがちな大きな理由である。

この「評価されない」という課題を解決する方法として、記事は「ドキュメントと現実の差分（doc-reality diff）」を成果物として残すことを提案する。リハーサルによって、ドキュメントに書かれている内容と、実際のシステムの状態や手順との間にどのような違いがあるかを明確にし、それを文書化するのだ。この差分は、インシデントが発生するかどうかに関わらず、常に価値を持つ具体的な成果物となる。

具体的なリハーサルの種類として、四つのドリルが紹介されている。これらは難易度が低いものから順に進めることが推奨される。

まず、「Drill 0 — 開いて読むだけ」である。これは最も簡単なドリルで、エスクローを実際に開いて、中身が何であるかを確認し、ドキュメントに記載されているはずのものが揃っているか、古い情報が含まれていないかをチェックする。通常、ソースコードはあっても、構築環境に関する記述が曖昧だったり、手順書が大幅に古かったりすることが発覚する。

次に、「Drill 1 — スクラッチ環境への復元」だ。本番環境とは完全に分離された、使い捨ての環境にエスクローからシステムを復元し、ビルドし、起動する。このドリルの重要な点は、「人間が何かを記憶していなければ成功しない手順」を失敗とみなすことである。手順書に書かれていない、担当者しか知らないような情報に依存するようでは、エスクローが真に機能しているとは言えない。

三つ目は、「Drill 2 — 資格情報の一時的な更新」である。ドキュメントに記載された手順に従って、システムが使用する資格情報（パスワードやAPIキーなど）を実際に更新してみる。これにより、手順書通りに作業できるか、必要な承認者が不在でも実行できるか、古い情報が残っていないか、などの現実的な課題が明らかになる。例えば、承認者が休暇中で更新ができなかったり、手順書に記載されていないシステムが古い資格情報を使い続けていたりするケースがよくある。

最後に、「Drill 3 — システムを構築していない担当者による復元」だ。これは最も重要なドリルかもしれない。システムを開発した本人ではない、別のエンジニアが、エスクローと「システムを復元する」という一言の指示だけを与えられて、復元作業を試みる。このドリルは、システム構築者のスキルではなく、エスクロー自体（つまり成果物）がどれだけ機能するかをテストする。チームから担当者がいなくなった時に何が起こるかを予測する、最も価値のある失敗を発見できる機会となる。

リハーサルが「合格」したとみなされるのは、エラーが出なかった時ではない。重要なのは、以下の三つの「証拠」が生成されることだ。一つ目は、何を、どのような順番で実行し、途中で何を即興で対応したのかを記録する「タイムスタンプ付きの作業ログ」。二つ目は、チームや役割ではなく、具体的な個人名を記録する「実行した担当者の名前」。これにより、誰がリハーサルを実施したかが明確になり、次回の計画に繋がる。そして三つ目は、手順書と実際のシステム状態が食い違っていた箇所を全て記録し、どちらが間違っていたかを明記する「ドキュメントと現実の差分（doc-reality diff）」である。この差分こそが、通常業務においてもシステムの継続性に関する価値ある情報となる。ドキュメントは、ある時点でのシステムに関する「信念」の記録であり、常に現実と乖離していくものだからだ。

多くのチームがリハーサルを実施しないのは、大規模で高コストなものを想像しがちだからである。しかし、もっと現実的で「安価なバージョン」も存在する。例えば、年間二回、それぞれ半日程度を費やす計画だ。第一四半期にDrill 0とDrill 1を実施し、エスクローの中身を確認し、使い捨ての環境に復元を試みる。二人で半日程度で完了するだろう。第三四半期にはDrill 2とDrill 3を実施し、営業時間外にオンコール担当者が手順書に従って資格情報を更新し、その後、新しい担当者がエスクローから単独でシステムを復元してみる。三人で半日程度で可能である。

これらのリハーサルで得られた「差分」は、必ずバージョン管理システムに記録された手順書の隣に、日付付きで保存する。次回のドリルは、前回の差分を確認するところから始める。これにより、未修正の課題がそのままリスクとして受け入れられたのか、あるいは修正されたのかが明確になる。未修正で忘れ去られた課題は、将来のサプライズ、つまり重大なインシデントの引き金となりかねない。年間八時間のリハーサルを行うコストは、一度の重大なインシデント対応にかかるコストと比較すれば、非常に小さいものだ。しかも、リハーサルであれば、その「大変な午後」を自分たちで選ぶことができる。

リハーサルはエスクローという「ある時点のスナップショット」をテストするものだ。リハーサルが終わった瞬間から、システムは変化し続け、現実との乖離が再び始まる。新しい機能が追加され、資格情報が変更され、依存するサービスが更新されるなど、常にシステムは動き続けている。だからこそ、一度のリハーサルで全てが解決するわけではない。重要なのは、リハーサルで得られた「差分」を継続的に記録し、システムの継続性がどれくらいの速さで劣化しているのかを把握し続けることである。

実際にこのテストに合格する組織は、特別なドキュメントを持っていたわけではない。彼らは皆、平穏な時に、意図的に自分たちの復旧経路を破壊しようと試み、何が壊れたのかを詳細に記録していたという共通点がある。エスクローは、単なる「こうなるといいな」という仮説に過ぎない。リハーサルこそが、その仮説を具体的な「計画」へと昇華させ、その計画が今も有効であるかどうかを教えてくれる唯一の手段なのだ。