本番障害は“設定ミス”ではなく、現実と記録のズレから始まる

Apr 29, 2026

1 min read

4 views

73%

いちばん怖いのは、壊れたことではない

インフラ運用で本当に怖いのは、システムが壊れることよりも、**「壊れているのに壊れていないように見えること」**です。見た目は正常、でも記録と実態が少しずつ食い違っている。ある日、更新した瞬間にその食い違いが表面化し、これまで隠れていた違和感が一気に障害になる。

この構図は、設定管理の話に見えて、実はもっと普遍的です。組織でも、コードでも、クラウドでも、真実が一箇所にまとまっていない状態は、短期的には自由に見えても、長期的には不安定さを増幅します。逆に言えば、安定したシステムとは「強いシステム」ではなく、現実と記録のズレがすぐ検出できるシステムです。

そしてこの問題は、単なる理想論ではありません。東京の特定のAZのように、名前は同じでも実態が違う場所がある。あるいは、あるリソースを外部から直接いじった結果、テンプレートと現実が乖離する。どちらも表面上は動いていますが、世界の見え方を一つに保てていないという点で同じです。

運用の本質は、システムを動かすことではなく、システムについての「説明」を壊さないことにある。

変更はできる。だが、どこから変更するかが本質だ

クラウド運用では、リソースを後から更新すること自体は珍しくありません。むしろ当然です。問題は、どの経路で変更するかです。テンプレート外から個別に直すと、その瞬間は便利でも、後から「何が本当の状態なのか」が分からなくなります。

これを人間の組織に置き換えると分かりやすいです。たとえば、会議で合意したルールがあるのに、現場の都合でこっそり例外運用が増えていく。最初の一件は効率的に見えるでしょう。ところが例外が積み重なると、ルールは残っていても、実際には誰もそのルールを信じていない状態になる。ここで起きているのは、単なるルール違反ではなく、記録された世界と実運用の世界が分裂することです。

CloudFormationの文脈で言えば、テンプレートは単なるメモではありません。期待される状態そのものです。だからテンプレート外で変更すると、いまの実態は一時的に便利になっても、次の更新でその変更は上書きされる可能性がある。これは意地悪な仕様ではなく、設計の帰結です。宣言的な管理とは、毎回「あるべき状態」を再適用する思想であり、そこでは裏口から加えた変更は本質的に居場所を持てません。

この思想の面白さは、自由を奪うことではありません。むしろ逆で、未来の変更可能性を守るために、今の自由を制限するのです。個別最適の修正を許してしまうと、後で誰も安全に触れなくなる。だからこそ、変更は必ず一つの正史を通す必要がある。

名前が同じでも、場所は同じではない

もう一つの重要な示唆は、インフラにおける「名前」と「実体」はしばしば一致しないということです。東京リージョンのあるAZは、見た目には同じ文字列で表されても、内部の割り当てやキャパシティは人やアカウントごとに異なることがあります。あるAZでは新しいインスタンスが起動しづらい、あるいは実質的に枯渇している、という事態も起こりえます。

これは私たちの直感に反します。AZというと、均質な区画がきれいに並んでいるように思いがちです。しかし実際には、名前は抽象、実体は局所です。同じラベルでも、そこにあるものは同じではない。ここにクラウドの難しさがあります。

この事実は、ドリフトの話と深くつながっています。なぜなら、両者ともに「見えているものをそのまま信じてはいけない」からです。テンプレートに書かれた状態と、実際のリソース状態はずれる。AZ名もまた、同じ名前だから同じ安全性や同じ余裕があるとは限らない。つまり、クラウドで起きる事故の多くは、抽象化を現実そのものと誤認することから始まります。

たとえば、負荷分散のつもりで複数AZにまたがって配置したのに、片方のAZが実際には余力不足で、新しい起動先としては機能しない。設計図の上では分散しているのに、実際には集中している。これと同じことが、設定管理でも起きます。テンプレートの上では安全でも、実態はずれていて、更新時に一気に破綻する。

クラウドの落とし穴は、見た目がシンプルであるほど深い。名前があるから理解した気になるが、名前は実体ではない。

一つの正史を持つということは、現実を疑うことではない

ここで誤解してはいけないのは、テンプレート中心の運用が「現実を無視する」ことではないという点です。むしろその逆で、現実を扱うために、現実の記述を一箇所に固定するのです。人は現場で起きた微調整を正当化したくなります。今だけ、これだけ、急ぎだから。だが、そのたびに正史が増殖すると、修正した本人でさえ後から説明できなくなる。

この状態は、コンピュータだけでなく認知の問題でもあります。私たちは一度何かを直すと、「もう反映された」と感じてしまう。しかし、変更には常に二つの層があります。実世界の変更と、記録の変更です。この二つが一致して初めて、変更は完了します。

だから、優れた運用とは「変更を減らすこと」ではありません。変更の入口を一つに揃えることです。たとえば、すべての構成変更はテンプレートから行う。自動化されたCIで差分を確認する。実環境の状態を定期的に検査して、意図しない差異がないかを検出する。こうした仕組みは、面倒な儀式ではなく、現実を言語化し続けるための技術です。

この視点に立つと、AZのばらつきも同じ文脈で見えてきます。リージョンやAZは、クラウドが提供する抽象ですが、その中身は均一ではありません。だからこそ、「この名前だから大丈夫」という思考を捨てることが重要です。実際のキャパシティ、障害ドメイン、起動制限、割り当ての偏りを観測しなければならない。抽象を信じるのではなく、抽象の裏側にある現実を測る必要があるのです。

安定性とは、硬さではなく、ズレに鈍感でないこと

多くの人は安定性を、変化しにくさだと考えます。けれど本当の安定性は、変化が起きたときに、それを正しく吸収できることです。CloudFormation的な一元管理はそのための仕組みですし、AZの実体を前提に設計することも同じです。

ここで有効なのが、運用を次の三層に分けて考えることです。

宣言層: どうあるべきかを記述する層。テンプレートや設計書がここに当たる。
実体層: 現在どうなっているかを示す層。実際のリソース、実際のキャパシティ、実際の配置。
検証層: 両者の差分を見つける層。ドリフト検出、ヘルスチェック、容量監視、配置監査。

この三層が揃うと、運用はただの作業ではなく、認知の再同期になります。問題が起きても、どこが壊れたかではなく、どの層がずれたかで考えられるようになる。すると、障害対応は「場当たり的な修復」から「ズレの再統一」に変わります。

たとえば、あるタスク定義を手で直してしまった結果、次のデプロイで元に戻るケースがあります。これは厄介ですが、見方を変えれば教訓でもあります。つまり、システムは「最後に誰が触ったか」ではなく、どの正史を唯一の真実として扱うかで動いている。そこを曖昧にした瞬間、運用は説明不能になるのです。

Key Takeaways

変更の経路を一つに決める。便利だからといって、テンプレート外から直接直さない。
名前を実体と混同しない。AZ名や設定名はラベルであって、容量や安全性の保証ではない。
ドリフトを「異常」ではなく「予兆」として扱う。ズレは障害の前段階である。
宣言層、実体層、検証層を分けて考える。どこがずれているかを切り分けると、対応が速くなる。
一時的な例外運用を恒久化しない。緊急対応は例外であって、正史に昇格させる前に戻す仕組みを持つ。

結論: 本番を守るのは、現実を支配する力ではなく、現実を一つの記述に戻す力だ

クラウド運用は、しばしば「どう安全に動かすか」の技術だと思われています。けれど本質はもっと深いところにあります。システムとは、現実そのものではなく、現実についての約束です。約束が増えすぎたり、裏から書き換えられたり、名前だけが先行したりすると、システムは静かに壊れ始める。

だから本当に重要なのは、強く作ることより、ずれを許さない構造を作ることです。テンプレートに戻すこと、実体を測ること、名前を疑うこと。これらは地味ですが、クラウド時代の最も洗練された運用哲学です。

次に「ちょっとだけ手で直すか」と思ったら、こう問い直してみてください。これは現実を改善しているのか、それとも現実と記録の距離を広げているのか。多くの障害は、壊れた瞬間ではなく、その前の小さなズレから始まります。だからこそ、優れた運用者は壊れたものを直す人ではなく、ズレが真実になる前に正史へ戻す人なのです。