【随時更新】もし本嫌いなシステムエンジニアが Mike Julian の「入門 監視」を読んだら

やっと読み始める

実は半年前にこの本を同僚から薦められて買っていたのだが、体系的に学ぶことに対してなかなか興味がわかず、積読状態が続いていた。

しかし最近、システム障害のポストモーテムを実施する際に、今後に活かせるような具体的なネクストアクションを導き出すことができず、自分に監視に関する体系的な知識が不足していることを痛感した。この経験がきっかけとなり、ようやく重い腰を上げてこの本を読み始めることにした。

ここからは、章ごとに読み進めている感想や気づきを共有する。
なお、「入門 監視」に登場する文の引用については、書籍名を省略し、ページ数のみの記載とする。

はじめに

冒頭で監視について次のように定義されている。

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

この定義を読んで、私はシステムと人間の根本的な違いについて考えさせられた。

システムのコンポーネントの振る舞いや出力は、人間でいえば体や臓器の状態に相当する。しかし決定的な違いがある。人間は体調不良を感じたとき、自ら「調子が悪い」と訴えることができ、必要に応じて医師の診察を受けられる。一方、システムにはその能力がない。

物理サーバーは突然過熱し、気がつけば無言で停止していることもある。CPUの使用率が異常に高まっても、メモリが枯渇しても、システム自身が「助けて」と声を上げることはできない。

だからこそ監視が重要なのだ。人間がシステムの「代弁者」として、その異変をいち早く検知し、適切な対応を取る必要がある。サービスの安定稼働は、この「代弁者」としての役割をどれだけ的確に果たせるかにかかっている。

第Ⅰ部　監視の原則

1章　監視のアンチパターン

1.1　アンチパターン1：ツール依存

「ツール依存」とは、監視の目的よりもツール選択の判断基準を優先してしまうことだと理解した。これには特定のツールへの過度なこだわりだけでなく、価格の安さや導入の手軽さといった外的要因による安易な判断も含まれる。

実際の現場でもよく見かける光景だ。「AWSを使っているから監視は CloudWatch で」「予算が限られているから無料の Zabbix を使おう」「今まで Zabbix を使ってきたから、新しいシステムでも絶対に Zabbix を使い続けよう」—これらの判断基準は一見合理的に思えるが、実は危険な落とし穴がある。

ツール選択の際に、価格や利便性、過去の経験といった要因を重視しすぎると、監視本来の目的である「システムの健全性を保つ」ことを見失ってしまう。結果として、ツールのための監視になってしまい、サービス運用の妨げになりかねない。

この状況を身近な例で考えてみよう。母がかつて飲食店を経営していた経験から、タピオカミルクティー店を例に挙げてみる。

「タピオカの食感が大好き！ずっとタピオカを売り続けたい！みんなでタピオカを飲んで幸せになりたい！」

この想いは素晴らしい。しかし、タピオカへのこだわりだけで5年後、10年後も同じ店を続けられるだろうか？ブームが去った後でも「幸せな生活を送る」という本来の目標を達成できるだろうか？

おそらく答えは「No」だ。本当に大切なのは「お客様に喜んでもらい、継続的に事業を成功させる」ことであり、タピオカは手段の一つに過ぎない。

監視も同じだ。ツールは手段であり、目的はサービスの安定稼働である。この視点を忘れずにいたい。

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

ここでは簡単に言えば「監視専門の人」を立てるのはアンチパターンだ、と言っている。

「だとしたらそれって何なのか」 （余談だが、文献を読んでしっくりこないときに私はこう問いかけている。）

人間がシステムの「代弁者」となってシステムの異変を検知するという冒頭の記述は、言ってみればシステムに対して人間味を感じ、サービスを作り上げる開発者の一員としてお互いに協力し、面倒を見るという考えを暗に示唆しているのだと思う。

チーム開発をしていて、「○○さんのことはあなたが責任もって面倒みてね。私たちは知らないから。」と言われたら、さすがに嫌な気持ちになるだろう。

監視も同じで、システムに関わる全員が責任を持つべき活動なのだろう。専門の人に丸投げしてしまっては、システムとの「つながり」が希薄になってしまう。

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

これは本当によくある話だ。「このコピペみたいな書類はなんで管理してるの？」と聞いたら「監査がこれを見に来るから」という返答が来るパターン。会社でよく聞く。

言われたからやる、という状況は緊急時には仕方ない場合もあるかもしれない。本来はあらゆるシステムを能動的に導入したいところだが、世間に対する見せ方なども考慮する必要があるだろうし、一定程度は仕方のないことなのだろう。

本にはアンチパターンの兆候が載っているが、チェックボックス監視に限らず、目的を見失った時には起きやすいことなのだと思う。別にこれで「監査は悪」などと極論を言うつもりはない。現在そのような兆候があるなら改善していこう、というだけの話である。

現職でも監視ツールの管理をインフラチームから引き継いでおり、監視ツールの細かい設定まで把握するのは正直大変だ。

特に驚いたのが、メトリクスを30秒や10秒ごとといった高頻度で取得するという考え方だった。今まで考えたこともなかった。私自身、OSの中身を中途半端に勉強しているせいか、crontabを皮切りに「定期実行は最短1分でしょ、そういうもんでしょ」という固定観念がついていたのだから無理もない。

「動いている」かどうかの監視が重要だということもこの節で触れられているが、自分の経験を振り返ると、言語化するのが難しくなると「ちゃんと動いている」という曖昧な言葉に逃げがちだ。

具体的に説明できないという問題は、開発者が思考に集中するための自動化やAIの導入において大きな課題になる。監視技術がどれだけ進歩しても、自分たちのサービス仕様を把握し、解釈のゆれのない言葉で説明できるスキルは、この先とても重要になってくると思う。

私がこの本をただ読み流さず、こうして感想を書いているのは、そういった理由からである。