監視とオブザーバビリティの違い — 「全部チェック」が成り立たなくなった理由

前回、オブザーバビリティは監視の強化版ではなく、問いの立て方を入れ替える考え方だと述べた。本稿ではその違いを掘り下げ、かつて当たり前だった全部チェックするという発想が、なぜ通用しなくなったのかを扱う。これは抽象論ではなく、運用の現場で前提が崩れていく過程の話だ。

「全部チェック」はどこから来たか

システムを作ったら、起こりうる障害のパターンを洗い出し、その一つひとつに対して検証する。リリース前のテストも、本番での監視も、根は同じ発想に立っている。起こりうる事象を列挙し、列挙したものを全部チェックする、という考え方だ。

この発想は、長いあいだ正しく機能していた。アプリケーションが単一の塊で、限られた台数のサーバ上で動き、構成が静的だった時代には、起こりうる事象が有限で、列挙しきれたからだ。系が閉じていて、境界の内側を自分が把握できる。

構成図にすると分かりやすい。PCからアプリ、データベースまでが一つの管理境界の中に収まり、経路は決まっていて、台数も数えられる。すべてが自分から見える。だから列挙すれば、現実に網羅へ近づけた。全部チェックしましたという言葉が、誇張ではなく成立していた。

裏を返すと、この発想には暗黙の前提があった。系が閉じていて有限であること。状態が静的で、検証した瞬間と本番の瞬間が同じであること。境界の内側がすべて自分から見えること。この三つが揃って初めて、列挙は網羅になる。

組み合わせ爆発：クラウドとSASEで前提が崩れる

ここ数年で進んだクラウドとマイクロサービスへの移行、そしてSASEのようなネットワークのクラウド化は、この三つの前提を一つずつ外していった。同じ構成を現代の形で描くと、別の絵になる。

二枚を並べると、何が変わったかが見える。第一に、管理境界が一つから複数に分かれ、自分が見えるのは右端のごく一部になった。利用者からアプリまでの経路の大半は、ISPやSASE、クラウド事業者の内部という持たない網を通り、その中は見えない。第二に、アプリ側も単一の塊ではなく、多数のサービスに分かれ、コンテナは生成と破棄を繰り返し、台数が自動で変わる。検証した瞬間の構成と、障害が起きた瞬間の構成が一致しない。

つまり、列挙すべき対象が、第一に多すぎて数えきれず、第二に絶えず変わり続け、第三に一部はそもそも見えない。従来の構成図では成立していた三つの前提が、現代の構成図では三つとも崩れている。事前に作ったダッシュボードには、想定していなかった組み合わせを見る軸が用意されていない。

列挙して防ぐ vs 観測して説明する

ここで発想を入れ替える必要が出てくる。全部のケースを先回りして潰すのではなく、潰しきれないと認めたうえで、別の戦略に切り替える。

オブザーバビリティは、無限の組み合わせを全部カバーするものではない。むしろ逆で、全部はカバーできないと認めたうえで、起きた一個について後から掘り下げられる状態を用意しておく。事前の網羅性を捨てる代わりに、事後の追跡可能性を手に入れる、という交換になる。

網羅から回復力へ

この交換は、技術の話にとどまらない。発注や契約で何を約束するか、という話にも及ぶ。

全部テストしましたと言い切るほうが、いまのシステムの作りでは正確さを欠く。無限で一部が見えない母数に対して網羅を約束するのは、誰にも守れない約束をするのと同じだからだ。専門性は、網羅できないことを正直に認めたうえで、起きたときに最短で説明し復旧できる仕組みを設計することに移る。評価の物差しも、想定した障害をどれだけ防いだかではなく、起きてから原因に辿り着くまでの速さ、すなわち平均復旧時間に変わる。

長く運用の現場にいた立場から見ると、網羅を求められて人手で押し返そうとすると、疲弊だけが残る。出口を押さえる設計に切り替えることは、人を増やす方向ではなく、見える化と相関で少人数でも回せる方向への転換でもある。

テスト側でも起きている同じ移行

同じ理屈は、運用だけでなくテストの側でも進んでいる。事前に全ケースを書ききれないので、本番に近い環境で実際の挙動を観測しながら確かめる方向、いわゆるカオスエンジニアリングや本番環境でのテストが広がっている。あえて障害を注入し、系がどう振る舞うかを観測して学ぶ。列挙して防ぐから、観測して説明するへの移行という一本の筋が、運用とテストの両方を貫いている。

まとめ

監視とオブザーバビリティの違いは、見る量ではなく問いの立て方にある。閉じて有限だった系が、開いて動的な系に変わったことで、列挙して防ぐモデルが限界を迎えた。約束する対象を入口の網羅から出口の回復力へ移すこと、それがオブザーバビリティの実務上の意味だ。総論はo11y（オブザーバビリティ）とは何かに、そして企業がこれに何を投資すべきかはオブザーバビリティ導入の判断基準で扱う。

よくある質問

監視とオブザーバビリティの最大の違いは何ですか

見る量ではなく問いの立て方です。監視は事前に用意した画面を見ます。オブザーバビリティは保持したデータに事後から新しい問いを投げます。

「全部チェック」はなぜ成り立たなくなったのですか

系が閉じて有限という前提が崩れたためです。列挙すべき対象が多すぎて数えきれず、絶えず変わり続け、一部はそもそも自分から見えません。

網羅の代わりに何を約束すべきですか

出口の回復力です。どんな障害でも規定時間内に検知し、原因を特定し、復旧する力を約束し、平均復旧時間（MTTR）で測ります。