手順書のないインフラは二度と作れない

譲渡資料の技術欄に、こう書かれていることがあります。「本番環境の構築手順は担当者が把握しており、引き継ぎ時に共有します」。あるいは、コードの置き場所であるリポジトリのREADMEに「本番セットアップ」という見出しで、五、六行の箇条書きが添えられている。売り手に悪意はなく、むしろ誠実に「手順はある」と示したつもりです。ところが買い手は、この一文や箇条書きを見たら、身構えるべきです。手順が「文章として存在する」ことと、その事業を「もう一度作れる」ことの間には、想像よりずっと深い溝があるからです。

買収とは、動いている事業を今の持ち主の手元から自分の手元へ移す作業です。サーバーを移し、環境を作り直し、いざとなれば壊れた状態から復旧する。その全部が、「同じものを作れる」ことを暗黙の前提にしています。作れないインフラは、動いている間だけ資産で、何かを変えようとした瞬間、あるいは壊れた瞬間に負債へ変わります。そして手作業で積み上げられたインフラは、本人の記憶と本番サーバーの中にしか正解が存在しないため、原理的に二度と同じものを作れません。

「手順書はあります」が安心にならない ── 文書は動かない、コードは動く

まず、手順書とIaCを区別する必要があります。IaC(コードによるインフラ定義。Infrastructure as Code)とは、サーバーに何を入れ、どう設定し、どんな構成で動かすかを、人間が読む文章ではなく、機械が実行できるコードとして書き残す方法です。代表的な道具にTerraform(サーバーやネットワークの構成そのものを宣言する)やAnsible(サーバーの中で何をどう設定するかの手順を定義する)があります。定義を実行すれば、書いてある通りの環境が毎回そのまま生まれます。

手順書とIaCの決定的な違いは、「誰が実行するか」です。手順書は人間が読んで実行します。人間は行間を判断で埋め、書かれていない前提を経験で補い、順序を間違えれば直感で気づきます。だから手順書は、書いた本人が読めば動きますが、それは文書が正確だからではなく、読み手が不足を補っているからです。一方コードは、書いてあることしかやりませんし、書いてあることは必ずやります。行間もなければ、経験による補正もありません。この「補正の余地がない」ことが、逆説的に再現性を保証します。

つまり「手順書があります」という言葉は、「この手順を私が実行すれば動きます」という意味にとどまることがあり、「この手順があれば誰でも同じものを作れます」とは限りません。前者の能力は、引き渡しの瞬間に売り手とともに事業から抜けていきます。買い手が受け取るのは、書かれた文章と、それを補える人間がもう居ないという現実です。

手順書は書いた瞬間から古くなる ── 実行されない文書は検証されない

手順書のもう一つの弱点は、書かれた瞬間から現実とずれ始めることです。文書は実行されません。ということは、その内容が今も正しいかを、誰も確かめていません。三年動いてきた事業では、手順書が最初に書かれた後にも、障害対応や機能追加のたびに数え切れない小さな変更が本番サーバーへ直接加えられていることがあります。その一つひとつは文書に反映されず、本番の中にだけ沈んでいきます。売買のために慌てて書き起こされた手順書なら、なおさら現状との乖離が大きくなります。

これはバックアップの話とまったく同じ構造です。戻せないバックアップは無いのと同じで書いたとおり、復元を一度も試したことのないバックアップは、資産として数えられません。手順書も同じで、その通りにやって実際に環境が立ち上がることを一度も確かめていないなら、それは「存在する」だけで「動く」ことは誰も知りません。存在するが古い手順書は、無いよりたちが悪いことすらあります。書いてある通りに進めて途中で詰まり、しかしどこがずれているのか分からない、という時間を買い手に強いるからです。

IaCがこの問題を免れているのは、それが日常的に実行されるからです。新しい検証環境を立てるたび、構成を変えるたびにコードが実行され、書いてある通りに動くことがそのつど確かめられます。実行され続ける定義は現実とずれようがなく、ずれれば実行が失敗して即座に露見します。「文書」と「実行されるコード」の差は、正確さの差ではなく、検証され続けているかどうかの差です。だから手順書の分量や見た目の丁寧さは、再現できる保証にはなりません。

手作業の総量は、サーバーの痕跡から掘り出せる ── DDでの実測

手順書の言葉を信じる代わりに、買い手は本番サーバーそのものに残った手作業の痕跡を数えるべきです。手で育てられたサーバーには、その履歴が意外なほど正直に記録されているからです。まず見るのがパッケージ導入の履歴です。Debian系のOSなら /var/log/apt/history.log と /var/log/dpkg.log に、いつ何を入れたかが時系列で残っています。これを眺めるだけで、初期構築が一度で終わったのか、三年かけて断続的に手を入れ続けたのかが分かります。断続的な追加が延々と続いていれば、それは記録されていない試行錯誤の連続だったという意味です。導入済みパッケージの一覧(dpkg --get-selections)を、同じOSをまっさらに入れ直した素の状態と突き合わせれば、この三年で手を伸ばした差分がそのまま浮かび上がります。手順書に書かれたパッケージと実物の一覧が食い違うなら、その食い違いこそ記録から漏れた手作業です。

次に、配布時から改変された設定ファイルを洗い出します。debsums -c は、パッケージとして入った設定ファイルが導入後に書き換えられていないかを照合し、手で編集されたファイルの一覧を出します。改変されたファイルが多いほど、手作業の総量が大きく、再現の難易度が高いと読めます。理想は、変更されるべき設定がすべて構成管理下に置かれ、設定ファイルの集まる場所である /etc の変更がetckeeper(/etcの変更を自動でバージョン管理する道具)のような仕組みで追跡されていることですが、手作業の事業では導入されていないことがあります。導入されていないこと自体が、変更を記録する習慣が無かったことの証拠になります。

さらに、定期実行と常駐サービスを棚卸しします。全ユーザーの crontab -l、/etc/cron.d、systemd(サービスの起動と定期実行を管理する仕組み)のタイマーを一つずつ確認し、どのリポジトリにも記録のない定期処理を探します。日次バックアップや集計バッチが crontab -e で手登録されていることがあり、サーバーが消えればこの処理の存在ごと消えます。加えて /usr/local/bin や /opt に置かれた出所不明のスクリプト、systemctl list-unit-files で見える手作りのサービス定義、運用ユーザーの .bash_history に残る操作の痕跡。これらは資料には決して現れず、本番サーバーの中を実際に歩いて初めて見えてきます。掘り出された痕跡の量が、そのまま「手順書に書かれていない手作業」の量です。

一度固まったインフラは、怖くて誰も触れなくなる ── 塩漬けと積み上がる脆弱性

IaCが無いことの本当の代償は、移設のときだけに現れるのではありません。買った後、日々の運用のなかでずっと重くのしかかります。何がどう設定されているか誰も把握しておらず、しかも同じものを作り直せないサーバーでは、一行の設定変更ですら賭けになります。触って壊れたとき、元に戻せる保証がないからです。すると買い手が採る合理的な判断は「動いているものには触らない」となり、インフラは塩漬けになります。

塩漬けが恐ろしいのは、時間が味方をしないことです。OSやミドルウェアには次々とセキュリティ更新が出ますが、更新は環境を作り直せる事業ほど気軽に当てられ、作り直せない事業ほど当てるのが怖くなります。結果として、二度と作れないインフラには、当てられなかった更新が静かに積み上がっていきます。土台の言語やランタイムがサポート終了(EOL。提供元の保守が打ち切られること)を迎える構造はサポート終了言語で書かれた事業の時限でも扱いましたが、IaCの欠如はその時限を「作り直して逃げる」という最後の選択肢ごと奪います。逃げ場を失った塩漬けインフラは、買収後に牙を剥く負債の典型です。

規模を広げる場面でも同じ壁にぶつかります。アクセスが増えてサーバーを増やそうにも、同じ環境をもう一台作れないなら、増設は「動いているサーバーを丸ごと複製して祈る」作業になります。事業を伸ばすための一番前向きな投資が、再現性の欠如のせいで最もリスクの高い作業に変わる。買った事業を安全に成長させられないという意味で、これは将来の収益力そのもの、ひいては査定額に響きます。

「なぜこの設定なのか」が失われた事業は、改良もできない

手作業で積み上げられた設定の一つひとつは、「動かなかったから直した」痕跡という場合があります。カーネルの調整値(sysctl)を一行足してようやく同時接続を捌けるようになった、同時に開けるファイル数の上限(ulimit)を上げてやっとエラーが止まった、特定のバージョンでないと動かないのでライブラリを固定した。当時その人が半日かけて見つけた答えが、理由の説明なしに本番へ刻まれています。書き残されていなければ、次に触る人はまた半日かけて同じ答えにたどり着くしかありません。

問題は、この「なぜ」が失われると、どの一行が要で、どの一行が消しても平気かが誰にも分からなくなることです。結果、迂闊に触れば壊れるが触らなければ動く、という手を出せない状態が生まれます。設定の理由が失われる構造は選定理由が失われたアーキテクチャの罠で設計選定の側から扱いましたが、同じことが最も低い層のOS設定でも起きています。改良も最適化も、まず「なぜ今こうなっているか」の解読から始めなければならず、その解読コストが改善の芽を摘みます。

IaCがあれば、少なくとも「何がどう設定されているか」はコードとして残ります。なぜそうしたかまでは残らないにしても、変更を試し、壊れたら定義を戻し、また試すという安全な反復が可能になります。作り直せる事業だけが、安心して壊しながら良くしていけます。再現性は、移設のためだけでなく、事業を継続的に改良していくための前提でもあるのです。手を出せないインフラを抱えた事業は、買った瞬間から成長の天井が決まってしまいます。

スナップショットを渡されても、それは中身の分からない箱の複製にすぎない

「同じ環境を作れないなら、今のサーバーをまるごとコピーして渡します」という提案が売り手から出ることがあります。クラウドのスナップショットやAMI(サーバーの状態をまるごと保存した複製イメージ)を引き渡すという話です。移設そのものは、これで一見片づきます。中身をいじらずそっくり動かせるからです。しかしこれは、問題を解いたのではなく先送りしたにすぎません。

複製されるのは「動いている状態」であって、「なぜその状態なのかの理解」ではないからです。コピーした瞬間から、買い手はOSのバージョンを上げることも、ライブラリを入れ替えることも、設定を一行変えることも怖くてできない箱を抱えます。前節までに述べた塩漬けと解読不能が、そっくりそのまま引き継がれるわけです。スナップショットは移設という一回きりの壁を越えさせてくれますが、その先にある「変え続けられるか」という長い壁の前に、買い手を素手で立たせます。再現とは、同じ結果を生む手順を手に入れることであって、結果だけをコピーすることではありません。箱を受け取ることと、箱の作り方を受け取ることは、まったく別の取引です。

ディスクが死んだ日、数時間で戻せるか数週間かかるか

IaCの有無がもっとも残酷な形で表れるのは、障害復旧の場面です。サーバーのディスクが物理的に壊れた、クラウドの仮想マシンが復旧不能になった——このとき問われるのは、まっさらな状態から本番と同じ環境を何時間で立て直せるか、です。IaCがあれば、定義を実行して数時間で戻せます。無ければ、記憶とわずかなメモを頼りに、本番の残骸を読み解きながら数週間かけて組み直すことになります。復旧に要する時間の下限は、結局のところ環境をどれだけ速く再現できるかで決まります。

ここで、復旧の話を「腕のいい人が一人いれば大丈夫」と片づけないことが大切です。復旧手順が1人の頭にしかない事業では、復旧能力が特定の人間に張り付く危うさを扱いましたが、IaCの欠如はそのさらに手前にあります。たとえ腕のいいその一人が居続けたとしても、作り直せる定義が無ければ、復旧速度はその人の記憶を掘り起こす速度に縛られます。人の技量の問題である前に、事業そのものが自分を再生する手段を持っていないという、構造の問題です。

そして復旧に数週間かかる事業は、その数週間ずっと売上が止まり、利用者が離れ、信用が削れます。復旧速度は事業継続性そのものであり、再現できないインフラは、その継続性を運任せにしているのと変わりません。平常時にどれだけ安定して見えても、それは単に、まだ誰も再現能力を試していないだけの状態でもあります。

買い手が背負うのは「書き起こし直す時間」── 精査の締めくくり方

手作業で育ったインフラを引き継ぐとき、見積もりに必ず入れるべきなのが「書き起こし直す時間」です。本番サーバーに何が入り、どう設定され、どの一行が要なのかを、買い手側のエンジニアが実物を読んで把握し、それをコードとして書き起こす時間。これは新しい機能を一つも生まない、ただ現状を再現可能な形に翻訳するためだけの作業で、手作業の事業ほど長くかかります。この時間は資料に一切現れませんが、買った後に確実に発生する原価です。

だから精査の締めくくりでは、今のインフラをそのまま維持できる前提では工数を積みません。IaCで書き直して初めて安全に運用・改良・復旧できる状態になる、という前提で見積もります。売り手が誇る「三年間の安定稼働」は、裏を返せば「三年ぶんの手作業が記録されないまま堆積している」ことでもあり、その堆積を掘り起こして翻訳する費用が、そのまま買い手の側に回ってきます。逆に売り手の側から見れば、売ると決める前にこの書き起こしを自分の手で済ませておくことが、値引きの口実を一つ消す最も確実な備えになります。

手順書の言葉ではなく、本番サーバーの実態から、そのインフラが「もう一度作れるか」「壊れたとき戻せるか」を確かめておきたいときは、AI技術デューデリジェンスで構成管理の状態や手作業の痕跡といった技術面の兆候を確認できます(登録不要)。