はじめに
入門監視を読んだので自分のアウトプットのために「監視の原則」の部分を要約しようと思います
入門監視はどんな本か？
本書は、システムのどの部分をどのように監視すべきか、また監視をどのように改善していくべきかを解説してくれています。
前半で監視のベストプラクティス、デザインパターン／アンチパターンを示して、監視の基本原則を詳しく説明し、後半でフロントエンド、アプリケーション、サーバ、ネットワーク、セキュリティの各テーマで強力な監視の基盤を設計して実装するための方法を示してくれています
1章：監視のアンチパターン
監視のアンチパターンとは、一見すると合理的に見えるが、実際には監視の品質や運用効率を損なう行動や考え方のことです。本章では、よくある5つのアンチパターンについて記載し、それぞれの問題点と改善の方向性を記載しています
1.ツール依存
概要:
監視の目的や要件を考える前に、特定のツールありきで設計を進めてしまうこと
問題点：
- ツールの機能に制約され、本来必要な監視ができなくなる
- 「カーゴ・カルト(形だけ真似る)」的な導入になることがある
改善に向けて：
- 目的や要件を明確にして、それにあったツールの選定を行う
- 必要であればツールの自作をして、それを使い監視する
2.役割としての監視
概要:
監視を特定の担当者やチームだけに行わさせること
問題点：
- 他の開発者や運用者が監視に無関心になる
- システム全体の可観測性が低下する
改善に向けて：
- チーム全体で監視を設計・改善する文化を育てる
- 監視を「全員の責任」として共有する
3.チェックボックス監視
概要:
「監視していること」が目的化し、実際の有効性を考慮しないこと
問題点：
- 「動いてるか」だけを確認する表面的な監視になる
- 無意味なアラートが多発し、アラートの確認をしなくなる
改善に向けて：
- アラートは「行動を促すもの」に限定する
- メトリクスの取得頻度や粒度を見直し、実用的な情報を得る
4.監視を支えにする
概要:
監視に頼りすぎて、設計や運用の問題を放置すること
問題点：
- 監視を支えにして。根本的な問題解決を怠る
改善に向けて：
- 監視は問題の検出手段であり、問題の解決は別途、行うべきである
- システム設計、そのものを見直すことも必要である
5.手動設定
概要:
監視設定を手作業で行い、属人化・ミスを招くこと
問題点：
- 設計ミスや更新漏れが発生しやすい
- 運用負荷が高い
改善に向けて：
- 設定の自動化・コード化(Infrastructure as Code)を推進
1章まとめ
1章では、監視の設計や運用における「やってはいけないこと」を明確にしています。これらのアンチパターンを避けることで、監視に関してよい状態になります
2章：監視のデザインパターン
本章では、監視をより効果的に行うための「良い設計の型」について記載しています。これらは、システム運用において信頼性と柔軟性を高めるための参考になります
1.組み合わせ可能な監視
概要:
1つのツールに全てを任せると、できることが限られたり、変更が難しくなる。このパターンでは1つの万能ツールに頼るのでなく、目的に応じて複数のツールを使い分けて連携させることで、柔軟で拡張性のある監視体制を実現する
実践例：
- ログ収集には「Fluentd」、グラフ表示には「Grafana」、アラートには「prometheus」などツールを使い分ける
利点：
- 必要に応じてツールを入れ替えられること
- それぞれのツールの得意分野を活かせること
2.ユーザ視点での監視
概要:
システムが「動いている」のように見えても、ユーザが「使えていない」ことがある。このパターンでは、ユーザの体験を意識して監視を行い、実際の利用状況に近い視点で問題を検出する
実践例：
- 実際のユーザ操作を自動で再現して、ページの表示速度やエラーの有無をチェックする
利点：
- ユーザに影響が出る前に問題を発見できる
- サービス品質の向上につながる
3.作るのではなく買う
概要:
監視ツールを自作すると、開発や保守に多くの時間と労力がかかり、本来の業務に集中できなくなる。このパターンでは、信頼できる既存の監視サービスを活用することで、効率的に監視体制を整える
実践例：
- Datadog、New Relic、Pingdomなどのクラウド型監視サービスを利用する
利点：
- すぐに使い始められる
- 専門家が設計したツールを活用する
4.継続的監視
概要:
時間が経つと古くなった設定や不要なアラートが放置されがちである。このパターンでは、定期的に見直しと改善を行うことで、監視の質とチームの関与を高める
実践例：
- 毎月、アラートの内容を見直す
- チーム内でダッシュボードの使いやすさを話しあう
利点：
- 監視の質の向上
- チーム全体での監視に関わる意識が高まる
2章まとめ
2章では、現場でよくある監視の課題のを解決するための実践的な方法を記載しています。これらを取り入れることで、チーム全体で使いやすく、信頼性の高い監視体制を作ることができます
3章：アラート、オンコール、インシデント管理
本章では、監視の中でも重要な「アラートの設計」、「オンコール体制の構築」、「インシデント対応の方法」について記載しています。これらは、障害発生時に迅速かつ効果的に対応するための基本になります
1.アラート
概要:
アラートは、システムに異常が発生したときに人が対応すべきかどうかを判断するための重要な手段である。
しかし、意味のないアラートや過剰な通知は、担当者の疲弊や無視につながる。ここでは行動につながるアラートの設計と運用の工夫について記載している
実践例：
- 急ぎのアラートはSMSやPagerDutyで通知し、それ以外はチャットに送る
- アラートに対応手順や関連情報へのリンクを含める
- 固定のしきい値ではなく、移動平均や変化率などの統計的手法を使って、異常を検知する
- メンテナンス期間中はアラートを抑制する
- 対応が定型化しているアラートは、自動復旧の仕組みを導入する
利点：
- 本当に重要なアラートだけが届くようになり、対応の質が向上する
2.オンコール
概要:
オンコールとは、障害発生時に対応する当番制の体制である。
特定の人に負担が集中すると、不公平感や疲労がたまり、チームの士気が下がる。ここでは持続可能で公平なオンコール体制の作り方について記載している
実践例：
- オンコールのローテーションを公平に設計する
- タイムゾーンに応じて担当を交代する「Follow-the-sun」方式を導入する
- ソフトウェアエンジニアもオンコールに参加し、アラートの質改善に関心を持たせる
- 誤報や不要なアラートを減らすためのフィードバックループを設ける
利点：
- チーム全体で責任を分担できる
- オンコールの負担が軽減され、対応の質が向上する
3.インシデント管理
概要:
重大な障害が発生したとき、誰が何をするかが曖昧だと混乱が起き、対応が遅れる。ここでは、インシデント対応の役割分担と対応後の振り返りの重要度について記載している
実践例：
- インシデント対応時に、「調査担当」、「連絡担当」、「記録担当」などの役割を明確にする
- 経営層と現場の間に「コミュニケーション調整役」を置き、現場の妨げを防ぐ
- インシデント終了後に振り返りを行い、再発防止策をチームで共有する
利点：
- 混乱を防ぎ、迅速かつ的確な対応が可能になる
- 経験がチームの知識として蓄積され、次回以降の対応が改善される
3章まとめ
3章では、アラートの設計、オンコール体制の構築、インシデント対応の方法について、現場で役立つ実践的な考え方と工夫が記載されています。
これらを取り入れることで、障害対応のスピードと質を高め、チーム全体の信頼性と持続可能性を向上させることができます
まとめ
「入門監視」では、監視の基本的な考え方がとても丁寧に解説されています。前半の「監視の原則」は2〜3時間ほどで読めるので、興味がある方はぜひ読んでみてください～