IT システムの監視についての入門書。
2 部構成で、第 1 部では監視の考え方や原則が示され、第 2 部では監視対象やレイヤーごとのテクニカルな話題を扱っている。
「問題が起きていることが分かるようにする」と「問題の原因を調査できるようにする」を明確に分けていることが印象に残った。
それらは何が悪いのかを教えてくれるとは限りませんが、何かがおかしいことを示す優れた指標です。 p12
このどちらも何が問題なのかは教えてくれませんが、何かが問題で、それがユーザに影響を与えていることは分かります。 p29
これらのメトリクスは何が悪いのかは教えてくれませんが、ビジネスの全体的な調子を示す素晴らしいものです。 p70
これらのメトリクスを使うことで、前に設定したメトリクスより細かいレベルで、アプリケーションが動作しているかどうかという質問に答えられるようになります。何が問題かはわかりませんが、何かがあることのヒントになるという、まさに必要としているメトリクスです。 p72
そして監視すべき「問題」というのは、「サービスが動いていない」ということ。これこそが知りたいことであり、まずはこれを監視すべきと本書では繰り返し強調している。
では、どうすればサービスが動いていないことを監視できるのか。「動いていない」ことを監視するためには、「動いている」とは何か、どうやって「動いている」かどうかを判断するのか、が分かっていないといけない。
この本は監視について書いているのに、なぜこんなにJavaScript について話すのか不思議に思うかもしれません。私は、監視しようとする対象の元になっている仕組みを理解するのは有益だと考えているので、フロントエンド監視のこととなれば、JavaScript が引き起こしがちな混乱について話す必要があります。 pp79-80
「フロントエンド監視」の章からの引用なので JavaScript について述べているが、これはもちろん一例に過ぎない。フロントエンドに限らず、対象のことを理解しないといけない。サーバを監視したければ、サーバを理解する必要がある。
本書の冒頭でカーゴ・カルト的な態度がアンチパターンのひとつとして紹介されているように、「この指標さえ見ておけばよい」「このツールを使ってこの内容のダッシュボードさえ用意すればよい」といったものは存在しない。
想像力を働かせて取り組まなければならない。
ログやメトリクスから、何が起きているのかを考える。監視したい事象が発生したとき、どのメトリクスがどのように変化するのか、どのような情報をロギングするとよさそうか、考える。そして検証し確かめる。それを繰り返してこそ、自分たちが知りたいことを知ることのできる、有益で効果的な監視を実現できる。
そして、想像する対象のことを理解しているからこそ、想像できる。とにかく理解から始まる。
これは監視に限らない。何かを創ったり何か問題を解決したりすること。それを上手くやるためには、対象を理解している必要がある。理解していればしているほど、上手くやれる可能性が高まる。
全てを理解することは不可能であり、詳細は都度調べればよい。だが仕組みや構造や全体像がわかっていないと、何を調べればいいかわからない。何を調べるとよさそうなのか、見当がつかない。
自分がインフラやシステムプログラミングに関心があり学習しているのも、そのためである。もっと理解することで、プログラミングやエンジニアリングをもっと上手くやれる可能性が高まる。
ウェブサービスやウェブアプリケーションの監視の場合、技術的な理解だけでは不十分で、対象のサービスの仕組みや要件や目的などを理解する必要がある。
そしてそれを一番上手くやれるのは、対象のサービスの開発者。作っている当事者が一番理解しているはずだから。
ソフトウェアエンジニアはアプリケーションについて誰よりも詳しいので、素晴らしいアプリケーション監視の仕組みをデザインするには最高の場所にいるのです。 p10
「運用チーム」に運用を丸投げするのではなく開発者が自分たちで運用するようにしよう、といった DevOps のような考えが生まれてきたのはそのためだと理解している。
しかしアプリケーション開発者が「やるべき」「やったほうがよい」とされることは狭義の開発や運用以外にも増え続けており（ディスカバリー、デザイン、ユーザーインタビュー、チーミング、対外的な発信 etc）、負荷は増大する一方になっている。
そのような課題に対応し、アプリケーション開発者だからこそできること、アプリケーション開発者だからこそ大きな価値を発揮できること、といったものに集中して取り組めるようにするためのアプローチとして Platform Engineering などが生まれてきている。
