最近、O'Reillyの『入門 監視』を読みました。
私はこれまで監視基盤の構築や運用を本格的に経験したことがありませんでした。現在の業務でシステム運用に関わる機会が増えており、監視について知識を深めたいと思い本書を手にとりました。
読む前は「どのツールをどう設定するか」という手順書のような内容を想像していたのですが、この本が教えてくれたのは、ツールの使い方というより「監視という仕事に対する考え方」でした。
この記事では、私がハッとさせられた、監視に対する「勘違い」を紹介します。
勘違い1：「監視＝インフラ担当者の仕事」だと思っていた
【読む前の思い込み】
監視といえば、インフラエンジニアや専門の運用チームが担当するものだと思い込んでいました。アプリケーション開発者はコードを書くまでが仕事であり、サーバーにデプロイした後のことは別チームに引き継ぎ、役割が分かれているものだと考えていたのです。
【本からの気づき】
本書では、監視を特定の誰かの「役割」にするのではなく、チーム全員が持つべき「スキル」だと断言しています。
特定の担当者に丸投げしてしまうと、システムの内部仕様を理解していないまま監視が設定され、無意味なアラート（ノイズ）が増えてしまいます。開発者自身が「自分が書いたコードが本番環境でどう動くか」に責任を持ち、自らアラートを考える文化が必要だという考え方に非常に納得しました。
勘違い2：「CPUやメモリのグラフを見張るのが監視」だと思っていた
【読む前の思い込み】
「監視とは何か？」と聞かれたら、「サーバーのCPU使用率やメモリをグラフにして、80%を超えたらアラートを鳴らす仕組み」だと答えていたと思います。とりあえず基礎的な数値を記録しておけば安心だと考えていました。
【本からの気づき】
本書では、そうした表面的な監視を「チェックボックス監視」（監視しているという事実を作るだけの監視）と呼び、警告しています。
大切なのは、OSの数値ではなく「ユーザー視点でシステムが動いているか」です。たとえば、サーバーのCPU使用率が低くても、Webサイトがフリーズしてユーザーが使えなければ意味がありません。
CPUなどの数値はアラートに使うのではなく、問題が起きた際の原因調査のために使うものだという明確な切り分けを知ることができました。
勘違い3：「スゴい監視ツールを入れれば解決する」と思っていた
【読む前の思い込み】
世の中で有名な高機能な監視ツールをドカンと1つ導入すれば、すべてをいい感じに監視してくれる「魔法の杖」になると思っていました。
【本からの気づき】
これも「ツール依存」というアンチパターンでした。目的がないまま知名度の高いツールを入れても、結局使いこなせずノイズが増えるだけです。
監視は単一のツールで解決できるものではなく「複雑な問題の塊」であるため、用途に合わせて複数のツールを組み合わせる（疎結合にする）のが正解だと学びました。ツールありきで考えるのではなく、「自分たちが何を達成したいのか」から逆算することが重要視されています。
これから監視に携わる自分への教訓
今後、実際に業務で監視基盤を構築したりすることもあると思いますが、本書の教訓を胸に、以下の3つを意識して取り組みたいと思います。
-
「ユーザーは今システムを使えているか？」を一番の基準にする
（ただOSの数値を眺めるだけの監視にならないようにする） -
ツールから入らず、「知りたいことは何か」から設計する
（手段と目的をはき違えない） -
コードを書くときは「これ、本番でどう監視する？」をセットで考える
（運用を人任せにしない）
おわりに
『入門 監視』は、これから監視や運用に関わる入門者にとって、最初に読んでおくべき本だと感じました。
システムが複雑になっても変わらない、普遍的な「運用の基礎」が詰まっています。私と同じようにこれから運用に関わる方や、「とりあえず監視ツールを入れたけれど上手く回っていない」と感じている方は、ぜひ読んでみてください！