「入門 監視」を読んだ

入門 監視を読みました。当方、監視もするアプリケーションエンジニアです。

第Ⅰ部　監視の原則
1章　監視のアンチパターン
2章　監視のデザインパターン
3章　アラート、オンコール、インシデント管理
4章　統計入門

第Ⅱ部　監視戦略
5章　ビジネスを監視する
6章　フロントエンド監視
7章　アプリケーション監視
8章　サーバ監視
9章　ネットワーク監視
10章　セキュリティ監視
11章　監視アセスメントの実行

付録A　手順書の例：Demo.App
付録B　可用性表
付録C　実践.監視SaaS

この本の対象読者

監視に関わる人、もっと言うと監視の基本的な理解を深めたい人向けの本と冒頭に書かれていますので入門書です。
原題は「practical Monitoring」なので「実践 監視」となりそうですが「入門 監視」と翻訳したのはしっくり来ました。

監視の定義　〜はじめにより〜

監視とは、あるシステムやそのシステムのコンポーネントの振る舞いや出力を観察しチェックし続ける行為である。

監視とは問題に気づくことだと思っていましたが、観察しチェックし続けることだと言っています。 すでに発生してしまっている問題に気づくのはもちろん重要ですが、普段からシステムを観察することで、問題の予兆に気づいて防げたらその方が尊いですよね。自分の場合、問題が起きてから監視ツールを開く場合がほとんどで、正常時のメトリクスを見るのは意識しないと難しいなと思いました。

監視のアンチパターン

まずアンチパターンとして5つが挙げられています。

アンチパターン１：ツール依存

私たちが監視しているものは、アプリケーション、データベース、OS、ネットワークなど多岐に渡るのに単一のツールで監視しようとするのはアンチパターンです。それぞれに合った監視ツールの導入を検討した方が良いと書かれています。ツールを増やすことを怖がる必要はないが、人づてに評判を確かめるなど慎重に選択する必要はあるとのこと。監視の目的がはっきりしていないけどオールインワンのツールを選択して監視することに満足してしまうよりかは、ちゃんと監視する対象と何を監視したいのかを明確にしてそれに合ったツールを選択するのが良いんでしょうが、そもそも監視に力を入れてないとそこまでできないだろうなと思いました。

アンチパターン２：役割としての監視

監視は役割にしてはいけない。チーム全員がある程度の監視スキルを持つべきと書かれています。 DevOpsの重要な要素として、インフラチームだけでなく全員が本番環境の責任をもつ必要があります。 うちのチームの場合、監視はローテーション制にしていますが特定の人だけで回しているので監視スキルが偏っていてアンチパターンに陥っていました。 まあ理想はそうだとは思いつつ、新人や派遣社員がいる状況でこれを満たすのはかなり難しいと思いました。 ではどうすれば良いのかは本の中では触れられてないですが、重要性を主張して少しずつやっていってもらうしかないんでしょうね。

アンチパターン３：チェックボックス監視

「これを監視しています」と言いたいがためだけの、いわばチェック項目を満たすために意味のない監視をしてしまうアンチパターン。外圧によりやらされているようなチェックもあるでしょう。 うちのサービスもこの本で散々名前が出てくるNagiosから大量のアラートメールが飛んできますが、正直全然見ていないのでもろにアンチパターンですね。不要なものは精査して減らしていきたいです。

アンチパターン４：監視を支えにする　＆　アンチパターン５：手動設定

当たり前ですが監視だけしていても壊れてしまったものが直る訳ではない。自動で回復させる取り組みにも時間を割くべきと書かれています。うちでは復旧は手動なものばかりなので、これもアンチパターンでした。

なんと、ショックなことに5つのアンチパターンすべてに当てはまっていました。

監視のデザインパターン

アンチパターンに対する解決策として4つのデザインパターンが挙げられています。

デザインパターン１：組み合わせ可能な監視

アンチパターン１のツール依存に対する解決方法。UNIXの哲学は監視の世界でも有用で、1つのことをうまくやるツールの組み合わせることが大事。

デザインパターン２：ユーザ視点での監視

結局、ユーザがシステムを「使えているか」が重要なので監視もそれに合わせて行うべき。OSのメトリクスなどばかり気にしても無意味なのでユーザから見た世界、ロードバランサーの外側からちゃんと使えているかの監視が重要。

デザインパターン３：作るのではなく買う

オンプレミスに監視の仕組みを構築するよりSaaSを使った方が結局安いしたくさんメリットがある。バージョンアップへの追随など考えてもホントそうだよなと思いました。監視ツールはSaasに任せて本来の仕事に集中しましょう。

デザインパターン４：継続的改善　

良い監視の仕組みは一朝一夕には出来ないので継続的な改善を続けていく必要がある。

アラートの管理

アラートにメールを使うのをやめよう

すぐ応答かアクションが必要ならばSMSやPagerDutyなどでしっかり通知した方が良い。 注意が必要だがすぐにアクションが必要ないものはチャットに送るぐらいで良いと書かれています。 現在、アラートメールを送っているもののうち、1つ1つ見なくて良くてトレンドだけ見れれば良いものもあるよなと思いました。

オンコールの管理

誤報を減らすのとローテーションするの、めちゃくちゃ分かります。自分も1人で対応していた時は正直心が病みそうになりました。 特に障害が多いような状況だと確実に精神を病みますね。 精神をすり減らさないために無駄な誤報を減らすのとローテーションにするのは必須だと感じています。

インシデント管理

障害の調査をしながら、関係部署へ報告をするのは正直無理ゲーだと思いつつ今まで泣きながらやっていました。本書では、現場指揮官(IC, incident commander)、スクライブ(scribe)、コミュニケーション調整役(communication liaison)、SME(subject matter expert)の４つ役割を分けると書かれていて納得しました。兼務は2つまで良いと著者は書かれています。これは早速チームに取り入れようと思っています。

まとめ

• 監視は難しいけど、クラウドネイティブまで行かなくても現代の開発ではアプリケーションエンジニアにも必須で求められる知識。
• テストコードで自分たちを守るように、監視＋自動復旧の仕組みでも自分たちを守っていきたい。
• 頑張って監視していく。
• 本編を読む時間がないなら（ボリュームないですけどね）付録Cは素晴らしいので読みましょう。