チーム全員が知っておくべき監視の原則 / 『入門監視』読了

『入門監視』を読み終えたので、簡単に感想とか印象に残ったところをまとめておきます。ちなみにこの本は『Practical Monitoring: Effective Strategies for the Real World (English Edition)』の邦訳本です。

目次とかは O'Reilly のページを参照してください。

本の概要

本は大きく二部にわかれていまして、前半はアンチパターンやデザインパターンを中心とした監視の原則について、後半はもう少し具体的にビジネス、フロントエンド、アプリケーション、サーバ、ネットワーク、セキュリティといったそれぞれの領域における監視戦略について書かれています。

監視とはなにか一つを監視すればいいという問題ではなく、ハードウェア、OS、ソフトウェア、ネットワークなどなど、非常に幅広い問題です。銀の弾丸はなく、これらを 1 つのツールで解決することは難しいことが書かれています。

監視したいメトリクスに応じて適切な選択ができるように、常に選択肢はいろいろ持っておきたいです。

アンチパターンの 1 つとして、監視を専門家の役割としてしまうことが挙げられています。開発と監視を役割として分けてしまうと、開発側は監視しやすさを意識せずに作ってしまいますし、監視側は知らないものを監視することになるので的はずれなメトリクスを監視してしまう可能性があります。

DevOps 運動の流れと同様に、監視もチーム全体で責任を持つようにしていきたいです。

監視はあくまでも問題の通知だけで、問題の改善自体を忘れてはいけないということが書かれています。

当たり前の話ですが、テストしても品質は上がらないという話と同様に、常にトラブルが少ないアーキテクチャやソフトウェアを作っていくことを目的に考え、そのための支えとして監視を使っていくということを忘れずにいたいです。

監視ツールを自分たちで作ったりメンテしたりするよりは SaaS を利用したりしたほうが総合的に安く、専門家のノウハウに乗っかることができ、本質的なところにフォーカスできるとのことです。

これは、監視に限らず当てはまることが多い話で、まずは既存サービスで手早く始めることを選ぶようにしていきたいです。

世界的な大企業でも素晴らしい監視の仕組みをつくるには長い年月を重ねており、継続的な改善から生まれているということが書かれています。

これも監視に限らず大抵のことに当てはまる話ですが、大事なことなので忘れずにいたいです。

アラートが多すぎると信頼されなくなるため、本当にアクションが必要でなければ削除する、閾値や監視の内容を見直す、アラートを削除するための仕組みを考えるといったことが推奨されています。

アラートはやはり精神的にも体力的にも消耗するので、本当に必要なものだけになるように改善し続けていきたいです。

アラート発生時のアクションがドキュメント通りの手順を行うだけならば、アラートを発生させる前に自動でその手順を実行させたほうがいいと書かれています。自動復旧で解決できなければアラートを送るようにします。

上で書いたアラートの削除と関連した話だと思うので、意識していきたいです。

前半の原則部分が特に頷ける部分が多く、チームメンバー全員が理解しておくことをおすすめします。後半部分については興味がある部分だけ拾い読みでもいいと思いますが、それぞれの領域でどういった監視ができるのかを理解しておくためにざっとでも目を通しておくといいのではないでしょうか。

本書全体として特定のツールの使い方についてはほとんど書かれておらず、汎用的に使える原理原則を中心に書かれています。この本は監視を始めるための地図として使って、各チームで具体的にどのようなツールと戦略で監視を行っていくか話し合っていくことが本当の監視の始まりになると思います。

本のページ数もあまり多くないので、チーム全体で監視について共通認識を作っていきたいときとかに輪講したりするのにいい本ではと思いました。