世間で話題のコチラの書籍。ITエンジニアの皆様はご覧になりました？
ポチップ
もしご覧になっていないなら、ぜひ読んで欲しい！と思う良書です。
この記事では、こんな匠を想い改めさせてくれた箇所について紹介します。
書籍「入門 監視」とは？
表紙で分かる通り、「O'Reilly Japan」の書籍です。概要はこちら。
前半で監視のベストプラクティス、デザインパターン／アンチパターンを示して、監視の基本原則を詳しく説明し、後半でフロントエンド、アプリケーション、サーバ、ネットワーク、セキュリティの各テーマで強力な監視の基盤を設計して実装するための方法を示します。
監視対象が変化し、システムアーキテクチャが進化する中で、従来から変わらない監視の基本を示しながら、時代に合った監視の実践を解説する本書は、監視についての理解を深めたいエンジニア必携の一冊です。日本語版では、松木雅幸（@songmu）氏による監視SaaSの導入や活用方法を付録として収録しています。
要は、入門と言いながら、システム監視の考え方、システム監視に関するベストプラクティスが詰まった一冊です。
初心者はもちろん、上級者にも読むべき素晴らしい一冊になっていました。
PDF / EPUB / mobi 形式で欲しいなら、こちらから購入しましょう。
紙面が欲しいならコチラ。
ポチップ
書籍「入門 監視」の概要
目次はこちら。
第Ⅰ部 監視の原則
1章 監視のアンチパターン
1.2 アンチパターン2：役割としての監視
1.3 アンチパターン3：チェックボックス監視
1.4 アンチパターン4：監視を支えにする
1.5 アンチパターン5：手動設定
1.6 まとめ
2章 監視のデザインパターン
2.1 デザインパターン1：組み合わせ可能な監視
2.2 デザインパターン2：ユーザ視点での監視
2.3 デザインパターン3：作るのではなく買う
2.4 デザインパターン4：継続的改善
2.5 まとめ
3章 アラート、オンコール、インシデント管理
3.1 どうしたらアラートをよくできるか
3.2 オンコール
3.3 インシデント管理
3.4 振り返り
3.5 まとめ
4章 統計入門
4.1 システム運用における統計を学ぶ前に
4.2 計算が救いの手を差し伸べる
4.3 統計は魔法ではない
4.4 meanとaverage
4.5 中央値
4.6 周期性
4.7 分位数
4.8 標準偏差
4.9 まとめ
第Ⅱ部 監視戦略
5章 ビジネスを監視する
5.1 ビジネスKPI
5.2 2つの事例
5.3 ビジネスKPIを技術指標に結び付ける
5.4 自分のアプリケーションにそんなメトリクスはないという時は
5.5 会社のビジネスKPIを見つける
5.6 まとめ
6章 フロントエンド監視
6.1 遅いアプリケーションのコスト
6.2 フロントエンド監視の2つのアプローチ
6.3 DOM
6.4 ロギング
6.5 シンセティック監視
6.6 まとめ
7章 アプリケーション監視
7.1 メトリクスでアプリケーションを計測する
7.2 ビルドとリリースのパイプラインの監視
7.3 healthエンドポイントパターン
7.4 アプリケーションロギング
7.5 サーバレスまたはFunction-as-a-Service
7.6 マイクロサービスアーキテクチャを監視する
7.7 まとめ
8章 サーバ監視
8.1 OSの標準的なメトリクス
8.2 SSL証明書
8.3 SNMP
8.4 Webサーバ
8.5 データベースサーバ
8.6 ロードバランサ
8.7 メッセージキュー
8.8 キャッシュ
8.9 DNS
8.10 NTP
8.11 それ以外の企業インフラにおける監視
8.12 スケジュールジョブの監視
8.13 ロギング
8.14 まとめ
9章 ネットワーク監視
9.1 SNMPのつらさ
9.2 構成管理
9.3 音声と映像
9.4 ルーティング
9.5 スパニングツリープロトコル（STP）
9.6 シャーシ
9.7 フロー監視
9.8 キャパシティプランニング
9.9 まとめ
10章 セキュリティ監視
10.1 監視とコンプライアンス
10.2 ユーザ、コマンド、ファイルシステムの監査
10.3 ホスト型侵入検知システム（HIDS）
10.4 rkhunter
10.5 ネットワーク侵入検知システム（NIDS）
10.6 まとめ
11章 監視アセスメントの実行
11.1 ビジネスKPI
11.2 フロントエンド監視
11.3 アプリケーションとサーバの監視
11.4 セキュリティ監視
11.5 アラート
11.6 まとめ
付録A 手順書の例：Demo.App
付録B 可用性表
付録C 実践.監視SaaS
このうちに共感が持てて面白いのは「1章 監視のアンチパターン」なんです。
しかし、考え方を覚えるには「2章 監視のデザインパターン」が役立ちます。経験者であっても、見直してみるのが良いかと思います。
3章以降は実践的な内容になっています。
ビジネス的な内容もあって、「5章 ビジネスを監視する」です。仕事に直結しますね。
書籍「入門 監視」の注目ポイント
個人的に、面白しろかった箇所、参考になった箇所、ポイントだった箇所をご紹介します。
「1章 監視のアンチパターン」より
ツール駆動なチームは、ミッション駆動なチームより効率的になることはない。動かしているソフトウェアによってミッションが決まってしまうと、アナリストたちはそのツールの機能や制限事項にとらわれてしまう。
よくあることです。新しい監視ツールを検討するときに、ついツールを前提に考えてしまって、目的と手段が入れ替わってしまうことがたくさんあります。（反省）
1.1.3 自分でツールを作らなければならない時もある
1.1.4 「一目で分かる」は迷信
標題がホントに示唆に富んでいます。監視をしたことがわかる人にはあるある過ぎて痛感します。
● 監視は全員がやるべき仕事であり、チームや部署内での役割ではありません。
（略）
● 監視するだけでは壊れたものは直せません。
● 自動化が足りていないということは、何か重要なことを見落としている可能
性を知るよい方法です。
思い当たることが多数あって、ちょっと頭が痛くなります。。。
「２章 監視のデザインパターン」より
まず監視を追加すべきなのは、ユーザがあなたのアプリケーションとやり取りをす
るところです。 （略）とにかくユーザ視点を優先した可視化が必要です。
インフラばかりに目が行きがちですが、一番何が大切かを思い出させてくれています。ユーザー体験が損なわれないなら、最悪はなんとかなるわけです。
常に改善し続けましょう。
現状維持バイアスは、監視の世界でも厳禁。
「3 章 アラート、オンコール、インシデント管理」より
どうしてそういう問題はいつも午前 3 時に起きるのでしょうか。どうして障害が起こるのは火曜日の午後 2 時ではないのでしょうか。
常々そう思います。しかも、警戒しているときこそ起きない。
よいアラートの仕組みを作る、私の考える 6 つの方法を挙げます。
● アラートにメールを使うのをやめよう。
● 手順書を書こう。
● 固定の閾値を決めることだけが方法ではない。
● アラートを削除し、チューニングしよう。
● メンテナンス期間を使おう。
● まずは自動復旧を試そう。
監視設計を主業務にしてたときに知りたかったベストプラクティスです。そうですよね、こうなりますよね。
「5 章 ビジネスを監視する」より
自動車メーカーのフォードが、燃料タンクにガソリンがどのくらい入っているか計
測する方法がない車を作ったとしたらどうでしょうか。あるいは速度を測れないとし
たらどうでしょうか。これらは、車が完成してから単に取り付ければよいというもの
ではありません。ごく最初の段階から車にデザインされているものです。
監視の設計を後回しにすることが如何に不自然かを示唆しています。現場では後回しにされがちなんですが、非常に重要なことを例え話としてドンドン提唱したいです。
ビジネス KPI は、非常に重要なメトリクスであり、アプリケーションやインフラの調子やパフォーマンスを示す先行指標です。
システム監視は、会社のビジネスKPIに連動させると尚重要な指標になります。WEBサービスを提供する会社であれば尚更です。決して、システム単体で動いているだけでは済まないことを改めて考えなければなりません。
「6 章 フロントエンド監視」より
この章以降では、非常にテクニカルな内容が多くなってきます。それほど実用的です。
多くの会社では、フロントエンドの監視を見て見ぬ振りをしています。
ECサイトやWEBサービスでは死活問題のハズのフロントエンド、つまりはWEBサイトの動作状態について監視をないがしろにしているケースが散見されることを示唆しています。
大事なのは、ユーザー体験であることを暗に示唆しています。
フロントエンドのパフォーマンス監視のゴールは、 動き続けることではなく、 素早くロードされることです。
監視の質の違いに気づかせてくれます。継続性ではなく、即時性が必要です。
「7 章 アプリケーション監視」より
7.3 health エンドポイントパターン
アプリケーションの健全性をヘルスチェックができるアクセスポイントを用意しよう！と提唱しています。たしかに。なぜ今まで用意しなかったんだろう。。。
「8 章 サーバ監視」より
この章でも、サーバのインフラ周りの監視について非常に実践的な内容が記載されています。その中でも、メモリについては匠は理解を誤っていました。
freeコマンドについて。
システムにメモリを追加すべきかどうかを判断する時には、 1 行目ではなく 2 行目を確認しましょう。
すいません、今まで見方を間違ってました。。。
メモリに関する重大な問題を監視するもう 1 つの方法は、ログに出力されるOOMKillerの呼び出しを監視することです。 OOMKiller は、メモリ使用が増えてきた時、システムで使用可能なメモリを増やすためにプロセスを停止する役割を担っています。システムログを killed process で grep すれば、これを発見できます。
今まで監視したことがありませんでした。まだまだだな、と思い知らされました。。。
「10 章 セキュリティ監視」より
セキュリティの話になると、インフラやアプリケーションがセキュリティのことを念頭において作られていないことに気づく人が多いのです。
これはホントに多いです。セキュリティインシデントが増えた昨今でさえ、よくあります。これは開発者側の理解不足に由来することが多々あります。
この章では、Linux環境における基本的なセキュリティ監視が紹介されていて、とても参考になります。
書籍「入門 監視」を読むべきはどんな人？
はじめにも書きましたが、監視に関しての初心者はもちろん読む価値があります。
しかし、それ以上に上級者が読み、改めて見直すのに最適な素晴らしい一冊でもあります。
もう一つ言えば、アプリケーションの開発者など、これまで監視に疎かった人にも是非読んで欲しいと願ってやみません。
書籍「入門 監視」のレビューまとめ
これぞ良書！
そんな気にさせてくれる一冊でした。ホントにオライリー社は良い仕事しますね。
ポチップ
IT業界に携わって長い匠ですが、それでもたくさんの学びを得ることができました。
こんな良書に出会わせてくれたオライリー社と、他サイトのレビューに感謝です。
ぜひ読んで、また感想を書きたいと思います。
