Topotalの宮里です。
だいぶ遅れましたが….2025年12月に開催したオンラインイベントのレポートをブログにまとめました。
今回は、SREの知識地図の著者・小林良太郎さん（@ryota_hnk）をゲストにお招きし、書籍第3章「システムの状態を観測する」についてのオンラインイベントを開催しました。
「監視とオブザーバビリティって結局何が違うの？」「オブザーバビリティツールを導入したのに全然使いこなせてない…」という声をよく耳にしますが、今回のトークはそのモヤモヤを解消するヒントがたくさんありました。そのオンラインイベントの内容の一部をお届けします！
監視とオブザーバビリティ、何が違うの？
まず、この2つの概念の違いです。似たようなデータ（CPU使用率・ログ・トレースなど）を使うのに、何が異なるのか？
- 監視（モニタリング） は、「今、システムがおかしくないかをチェックし続ける行為」です。エラーレートが上がってないか、スループットが跳ね上がってないかなど、状態変化を継続的に見ていくものですね。
- オブザーバビリティ はその一歩先で、障害が起きたときに、どのAPIが原因なのか・どのコードでバグが起きたのかまで調べられる組織の能力です。
「ベテランが深夜に気合いでログをgrepするんじゃなくて、最近入ったメンバーでも適切なツールを使えばどこまでたどり着けるか、そこを目指してほしいんです」
さらに書籍では書ききれなかったと言っていたのが、どのユーザーへの影響だったかまで追えることの重要性。障害が起きたとき、どのユーザーやB2B企業に影響が及んだのかを、気合いや経験値ではなくツールで把握できる状態が、オブザーバビリティの到達点の一つ、とのことです。
シグナルはバラバラに見るのではなくつなげて見る
書籍でも紹介されているUSEメソッド・REDメソッド・4 Golden Signalsの話もありましたが、強調していたのは「シグナルを関連付けて見ること」でした。
たとえばこのようなイメージです。
- メトリクスにAWSのリージョンやアベラビリティゾーンをタグとして付けておく
- その上で動いているアプリケーション名もメタデータとして紐付ける
- トレースにユーザーIDを含めておく
- そのトレースからログに飛んで、最終的な原因を特定する
これができると「ユーザーからの問い合わせ→関連トレースを確認→ログで原因特定」という流れがUI上でできるようになります。以前だとリクエストIDでgrepして…という作業が、クリックのみで終わる世界です。
「どのシグナルを見るかよりも、シグナル同士をつなげて見られる土台があるかどうかが大事。OpenTelemetryのセマンティック規約に沿ってメタデータを付けていくと、自然とつながりやすくなりますよ」
やりがちな失敗 - アンチパターン TOP3
ここが今回のトークで一番盛り上がったところで、小林さんがベンダー目線・現場目線の両方から「これは本当によく見る」という失敗パターンを3つ教えてくれました。
❌ その1：インフラチームだけで突き進む
SREやインフラチームが「オブザーバビリティやるぞ！」と旗を立てて、アプリチームを巻き込まずに進めてしまうパターンです。
DatadogやNew RelicのAPMを入れようとすると、アプリ側にトレース取得のコードを書いてもらう必要があります。でもアプリの人からすると「仕事が増える」。
コスト負担の話でもめることも多く結果として、全然進まないというのはよくある話だそうです。
そのため、 早い段階でアプリチームを巻き込み、「こんだけ見えるようになりますよ」を実際にデモして見せること。百聞は一見にしかずです。
❌ その2：ツールは変えたけど運用スタイルは変わってない
クラウド移行や監視ツールの乗り換えをしたのに、以前と全く同じ監視・運用をしているパターン。
「オープンソースツールでやってた時と同じことをやるだけなら、投資に見合った効果が得られない」
特に「全メトリクスに閾値を設定してアラートを全部入れる」設計は要注意。アラートが鳴りすぎて現場が疲弊するだけです。まず、ユーザーがどんなエラーに直面しているか？を優先的に見る運用スタイルへの転換が必要です。
❌ その3：ツールを導入することをゴールにしてしまう
これはベンダーの人が言うのは変かもしれないけど….と前置きして小林さんが仰っていたことは
「ツールを入れたから、はいオブザーバビリティ完了！ではないんです。エンドユーザーに何が起きているかを説明できる運用スタイルになっているか、それが問われる」
高機能なツールを導入しても、使い方や文化が変わらなければ宝の持ち腐れ。ツールはあくまで手段であって、目的は「組織の観測能力を上げること」です。
まとめ
今回のトークを通じて、小林さんが一貫して伝えていたことはシンプルでした。
オブザーバビリティはツールではなく、組織の能力。
その能力を高めていく方向は「開発者が楽になること」と「ユーザーが幸せになること」の2つ。ツールを入れたその先に、どんな運用の変化を起こすかが本当の勝負どころなんだと、改めて感じさせられたオンラインイベントでした。
終わりに
次回は、SREの知識地図の第4章「障害を学びにつなげる」、第5章「障害対応のプロセスや体制を作る」についてのオンラインイベントの内容をブログにします！ SREの知識地図 第3章のアーカイブ動画は以下よりご確認ください〜
