幡ヶ谷亭直吉ブログ

娘のここねと格闘するエンジニア。

『入門 監視』を読んで ~ 監視の門にたどりつく

読書メモ。2025年31冊目。
『入門 監視 ―モダンなモニタリングのためのデザインパターン』を読んでの感想となります。(2025/5/4記載)

本の概要

あなたのシステムはきちんと動いていると言えますか? 本書は、システムのどの部分をどのように監視すべきか、また監視をどのように改善していくべきかについて解説する書籍です。
前半で監視のベストプラクティス、デザインパターンアンチパターンを示して、監視の基本原則を詳しく説明し、後半でフロントエンド、アプリケーション、サーバ、ネットワーク、セキュリティの各テーマで強力な監視の基盤を設計して実装するための方法を示します。
監視対象が変化し、システムアーキテクチャが進化する中で、従来から変わらない監視の基本を示しながら、時代に合った監視の実践を解説する本書は、監視についての理解を深めたいエンジニア必携の一冊です。日本語版では、松木雅幸(@songmu)氏による監視SaaSの導入や活用方法を付録として収録しています。

引用:

www.oreilly.co.jp

動機

  • 今まで既に出来上がった運用監視手順をなぞることしかやってこなかった。
  • 今はじめて運用監視を主体的に考えるプロダクトに携わっている。
  • 本書の噂を色々なところで聞き、ゼロから考えるための足場にできればと着手!

感想

監視という業務に対して今まで自分が身を置いてきた環境での知識に依存していることを実感しました。
むしろ、自分が監視として意識できていたのはほんの一部(アプリケーション監視、ログとイベント、セキュリティの監視)であり、監視として意識せず行っていたことや、そもそも意識もできていなかったことも。

そのうえで、いったん自分が携わるシステムに求められる監視を改めて考え、また今手順書ベースで実施している監視の目的を改めて整理し、目的ベースで手順を理解できる状態を作る必要があると感じました。
かつ、手順に過不足があるかどうかを、もう一度本書と照らし合わせたり他ソースに当たって考えていく必要もあると思っています。
また、それと並行してSaaSについても導入の可能性を確かめたい。

本書を読むことで大きな学びがあった、というよりは、前よりも学ぶ機会に近づいたという印象があります。
それだけ、監視について分からないことが多く、専門的な知識が自分に不足しています。
ただ、アンチパターンデザインパターンを通した前提であったり、考えるべき枠を理解できたことは大きな一歩と思っています。

今後、実務を通してさらに理解を深めていきたいと思います。

忘れたくないメモ

アンチパターンが修正されない理由

凝り固まったやり方や文化、レガシーなインフラ、あるいは単なる古典的なFUD(恐れ [fear]、不安 [uncertainty]、不信[doubt] の頭文字)といったさまざまな理由から、これらのアンチパターンを修正するのは難しいことが多い

運用監視に限らずチームで何かを実現できないとき、ここで表現される内容を振り返りたい。

■ツール駆動とミッション駆動

ツール駆動なチームは、ミッション駆動なチームより効率的になることはない。動かしているソフトウェアによってミッションが決まってしまうと、アナリストたちはそのツールの機能や制限事項にとらわれてしまう。ミッションを遂行するために何が必要かという観点で考えるアナリストは、要求に見合うツールを探し、要求を満たすものがあるまで探し続ける。自分でツールを作ってしまおうと考えることもある。

ツールに対して盲目的だとツール前提での手順しか浮かばず、目的を見失う、といった話と理解しました。
ただ、個人的には目的から考えていくことも、そもそもの知識が無いと難しく、そうした意味では、ツールから習うことも重要なのかも知れないと思っています。

■チームが成功したことによってツールや手順が作られる

年を追うにつれて、科学の世界でのこの現象は、ソフトウェアエンジニアリングシステム管理でも見られるようになってきました。成功したチームや会社は、ツールや手順によって成功したのだという間違った考え方によって、そういったチームや会社が使っているツールや手順を採用して、同じ方法で自分たちのチームを成功させまうとしてしまうのです。残念なことに、これは原因と結果が逆になっています。チームが成功したことによってツールや手順が作られたのであって、その逆ではありません。

運用監視に限定せず注意したいこと。
どこでも通用する銀の弾丸は無いし、自分たちの目的とコンテキストと適合するかどうかで選択する必要があると思います。

■ユーザ視点を優先した可視化

計測する必要がありそうな箇所はたくさんありますが、手をつけるのに最適な場所があります。それはユーザです。

ユーザが気にするのは、アプリケーションが動いているかどうかです。とにかくユーザ視点を優先した可視化が必要です

必要なだけ深く広く対象を増やしつつも、「このメトリクスはユーザへの影響をどう教えてくれるだろうか」と常に自問自答して下さい。

運用監視について考慮できていなかったことでした。
システムに対する定期健診のようなイメージでいたけど、【ユーザーが利用するシステム】に対する定期健診と意識しないといけない。

■監視自体は何も修復してはくれない

何かが壊れたら、あなたがそれを直す必要があります。場当たり的対応をやめるには、その基礎にあるシステムを改善するのに時間を使わなくてはなりません。システムに回復力があれば、その分だけ大きな問題は少なくなりますが、基礎にあるシステムに手間をかけなければその状態にはたどり着けません。

監視の結果、問題があれば随時何か対処するのではなく、そもそも問題が発生しない状態を作らなければいけない。
何のために監視を行うかと同じ領域の過大な気がしています。
新しい機能を作っていくために、固定費を減らす意識をしていく必要があると思います。

■共感の気持ち

ソフトウェアエンジニアもオンコールのローテーションに入れることを強くおすすめします。この背景には、ソフトウェアエンジニアリングにおける「丸投げ」を避けるという意図があります。オンコールの最中に発生する問題にソフトウェアエンジニアが気づき、かつ自身がローテーションに組み込まれていれば、よりよいソフトウェアを作ろうというインセンティブが生まれます。もう少し繊細な問題として、共感の気持ちが生まれるという点もあります。ソフトウェアエンジニアと運用エンジニアを一緒にすることで、お互いの共感が強まります。本当に理解し気が合う人を困らせるようなことはしにくいものです。

DevOpsの思想。Devがオンコールに入ることで自分の作るものにオーナーシップを持つことができることが重要と思っています。
プラットフォームチームが居てもオンコールはストリームアラインドチームが実施した方が良い気がします。

 

■監視SaaSを使うことのメリット

本書では、監視SaaSを使うことのメリットとして、結果としてコストメリットがあり、難易度の高い監視ツールの運用を専門家であるSaaS提供者に任せることができ、利用者は本来のプロダクト開発にフォーカスできることが挙げられています。

プラットフォームチームの思想。
プロダクト開発にフォーカスできる状態とできない状態を比較して導入を検討できるようにしたい。

 

■監視の民主化

実際、監視SaaSを利用することで、監視に対する敷居と難易度が下がり、簡単に監視を実施できるようになります。それは、結果としてさらに大きな、あるメリットをもたらすと筆者は感じています。

それは「監視の民主化」とも言うべきものです。チームの全員が監視システムにアクセスでき、それらを扱うスキルを持つ理想的な状態です。

監視は開発者自身が自主的に行うべきもので、属人的な権威があってはいけません。構築や設定が複雑なツールでは、ついつい専任者が属人性を作り込んでしまい。権威が発生しがちです。

SaaS監視を使うことで「監視の民主化」を実現しやすくなります。それが、より効果的な監視につながるでしょう。

最近、監視対応の煩雑さとそれが開発に与えるノイズを考えると、属人化した作業にしても良いのかと悩んでいました。
ただ、無くすべきは対応の煩雑さであって、民主化ではないと気付きました。

■自分たちの運用をサービスに合わせる

SaaSを使うとなったら自分たちの運用にこだわりすぎず、SaaSが示すプラクティスに合わせて運用を見直す機会と捉えるとよいでしょう。SaaSのプラクティスに沿った使い方をしていると、それらのノウハウを自分たちの運用に取り込みやすくもなります。

ツールから学ぶことの重要性。

 

■シンセティック監視のすすめ

シンセティック監視は Web サイトが正常に動作しているか外側から定期的に監視するものです。

2章の「2.2 パターン2: ユーザ視点での監視」で、できるだけユーザに近い所がら監視を始めることが推奨されていますが、シンセティック監視はまさしくそれを現するものです。Webシステムの場合、ユーザがみる画面やAPI、つまりシステムのいちばん外側さえちゃんとしていれば、内部に多少問題があってもビジネスには直ちに影響はありません

ユーザー視点で監視を整理したいと思います。
そのうえで、今見ている部分で悪い結果があった場合に、ユーザーにどうした影響があるかも明瞭化してタスクの価値を共有できる状態にしたいです。

 

■システムの監視に自覚的であるべき

ソフトウェア開発とテストがセットで語られるように、システム運用と監視はセットで語られるべきです。監視もよりコード化され自動化される必要があります。

そして、開発者は運用されるシステムの監視に自覚的であるべきです。監視も慣れて来ると作ることが楽しくなります。

システムを作る時は監視も一緒に考えることです。「ガソリン残量を計測できなような燃料タンク」を作らないようにしましょう。

監視の楽しみを得られるように考える。

その他の教材

今回、『入門 監視』について以下も参考に学習しています。

youtu.be