#はじめに
日々感覚で行ってきた「監視」という業務を改めて見直すため、入門監視(O'Reilly Japan)を購入しました。
章ごとに要点をまとめます。
入門監視を読んで第1部監視の原則(1-4章)
入門監視を読んで第2部監視戦略 (5-11章)

#1-11章を読んで
・サクサク読めた
・監視というふわふわしたものをすごくきれいに言語化してくれている
・改めてできていないこと(今後目指していくべきこと)を認識することができた
・周りのメンバ・組織が本書を通して認識を統一できるとよいと感じた

#目次

第1部 監視の原則
 1章 監視のアンチパターン
 2章 監視のデザインパターン
 3章 アラート、オンコール、インシデント管理
 4章 統計入門
第2部 監視戦略
 5章 ビジネスを監視する
 6章 フロントエンド監視
 7章 アプリケーション監視
 8章 サーバ監視
 9章 ネットワーク監視
 10章 セキュリティ監視
 11章 監視アセスメントの実行
付録A 手順書の例：Demo App
付録B 可用性表
付録C 実践 監視 SaaS

##1章監視のアンチパターン
間違った監視例の提示

###1. ツール依存監視

監視とは、単純で単一の問題ではありません。実際は非常に大きな問題の塊なのです。

それ故、1つのツールだけですべての問題を解決しようとしてはいけない
「仕事ができる最低限の数」の監視ツールを導入すべき
ツールの選定は賢く慎重に、監視目的に応じたツールを採用する
深いツールの理解、また時には小規模でも自分でツールを作ることも念頭に置く

###2. 役割としての監視

監視とは役割ではなくスキルであり、チーム内の全員がある程度のレベルに至っておくべきです。
ソフトウェアエンジニアはアプリケーションについて誰よりも詳しいので、素晴らしいアプリケーション監視の仕組みをデザインするには最高の場所にいるのです。

###3. チェックボックス監視

「これを監視してます」というための監視システムのことです。組織の中で上位に位置する人が要求してくることもあるでしょう。

アンチパターンを治す方法
・サービスが「動いている」を理解し、サービスが「動いている」を監視しよう (ex. HTTP GETのレスポンス内容を監視する)
・OSのメトリクス監視はやめる (リソースの使用率が高くとも、そのサーバはやるべき処理をしているのであれば問題はない)
・高頻度のメトリクス取得

###4. 監視を支えにする

監視が杖であるかのように寄りかかってはいけません。監視とは、問題を通知することに長けているのであって、通知を受け取った次にするべきことである、問題の修正を忘れてはいけません。

###5. 手動設定

監視設定は100%自動化すべきです。

監視設定をテンプレート化し、ノードが追加された際はそのテンプレートに当てはめて監視をすればよいと理解した

##2章デザインパターン
よい監視例の提示

###1. 組み合わせ可能な監視

専門化されたツールを複数使い、それらを疎に結合させて、監視「プラットフォーム」を作ることです。
最高のダッシュボードは、1つのサービスあるいは1つのプロダクトのステータスを表示することに焦点を絞るものです。

監視サービスのコンポーネント
・データ収集(SNMP/Nagios/Consul/etcd/collectd)
　　pull型/push型メリデリからどちらを採用するかは判断
・データストレージ(RBD/Whisper)
・可視化 (Grafana/Smashing)
　　円グラフは過程やトレンドと行った情報が含まれていないため監視の場ではあまり使用しない
・分析とレポート
・アラート

###2. ユーザ視点での監視

まず監視を追加すべきなのは、ユーザがあなたのアプリケーションとやり取りをするところです。Apacheのノードが何台動いているか、ジョブに対していくつのワーカが使用可能かといったアプリケーションの実装の詳細をユーザは気にしません。ユーザが気にするのは、アプリケーションが動いているかどうかです。

例えば、HTTPのレスポンスコードやレイテンシの状況を監視する
そうすることで個別のノードを気にすることから開放される

###3. 作るではなく買う

監視の仕組みが十分に成熟していないなら、監視を始めるところからいきなり自社の監視プラットフォームの構築にジャンプするべきではないということです。

5年間は悩むことなくSaaSを監視に使うべき
理由は安くて・SaaSで十分に事がたり・自身が監視ツールを設計する専門家でないから

###4. 継続的改善

世界レベルの仕組みは1週間でできるものではなく、数ヶ月あるいは数年間に渡る継続した注意深さと改善から生まれるものです。あなたはこの長い道のりの道中にいるのです。

##3章アラート、オンコール、インシデント管理
アラート、オンコール、インシデント管理に対する
良い例と間違った例

###1. よいアラートの定義
####1-1. アラートにメールを使わない
・すぐに応答かアクションが必要なアラートはSMSやPagerDutyなどのページャへ通知 ⇒ とにかくすぐに通知する
・注意が必要だがすぐにアクションが必要ないアラートはチャット通知やWebページで管理
・履歴や診断のためのアラートはログファイルへ

####1-2. 手順書を作成する

手順書は、何らかの問題を解決するのに、人間の判断と診断が必要なときのためのものです

・これは何のサービスで、何をするものか
・誰が責任者か
・どんな依存性を持っているか
・インフラの構成はどのようなものか
・どんなメトリクスやログを送っていて、それらはどういう意味なのか
・どんなアラートが設定されていて、その理由は何なのか

####1-3. 無駄なアラートを削除する

「あっ、くそっ、問題発生だ」といったことが週に10回、1ヶ月間続いたら、長期間のアラート疲れを起こして、メンバーは燃え尽きてしまうでしょう。

・初心に戻り、そのアラートは誰かがアクションする必要があるか？を見直す
・定期的なアラートトレンドの振り返り
・自動化の検討

####1-4. 作業アラートはメンテナンス機能で削除する
ただし、アラートの止めすぎには注意

####1-5. まずは自動復旧を目指す

自動復旧によって問題が解決できないなら、アラートを送ればよいのです。

###2. よいオンコール
####2-1. 誤報を修正する
オンコール担当は日次で前日のアラートをリスト化し、改善方法を自問自答する

####2-2. システムの回復力を高め、無用の場当たり対応を減らす
システムの回復力を高める効果的な戦略。
・オンコール担当は、システムの回復力や安定性の改善を行う
・前週のオンコールの際に収集した情報をもとに、次週のスプリント計画やチーム会議の議題や計画とする

####2-3. オンコールのローテーション
・出勤日にローテションを始める
・バックアップのオンコール担当は必要ない
・ソフトウェアエンジニアもオンコールのローテーションに組み込むべき
・PagerDuty / VictorOps / OpsGenieといったツールを利用する

###3. インシデント管理
インシデント管理プロセス (簡易版)

インシデントの認識(監視が問題を認識)
インシデントの記録(インシデントに対して監視の仕組みが自動でチケットを作成)
インシデントの診断、分類、解決、クローズ
必要に応じて問題発生中にコミュニケーションを取る
インシデント解決後、回復力を高めるための改善策を考える

5について、常にインシデントに関する議論(何が起きたのか、なぜ起きたのかどうやって修正したのか等)の場を常に設けるべき

##4章統計入門
監視をする上で武器となる統計の基礎知識

統計は魔法ではない

・算術平均について
　　N個の要素の合算値をNで割った値
・中央値について
　　N個の要素を昇順に並べ N/2 番目の値
・パーセンタイルについて
　　要素を昇順に並べ替え、N%に位置する値を Nパーセンタイルと呼ぶ
・標準偏差について
　　平均からどの程度離れているか？を示す値
　　標準偏差はこの先扱うデータでは適用できないことが多いでしょう