『入門 監視』 - はじめて監視する全員が読む本

はじめての監視

ある日、Webアプリケーションの監視にまつわる仕事がふってきた。

しかし自分はログ？メトリクス？状態。
何から手を付けたらいいかも分からず、とりあえず全体感をつかむため名著と名高い『入門 監視』を手にとってみた。

本記事では主に「5章 ビジネスを監視する」を取り上げて所感等を書いてるので、監視原則や具体的な方法にはあまり触れてません。

ちなみに、最後のオマケが一番ボリューム多いです。

本の特徴

※本著HPより引用です。

前半で監視のベストプラクティス、デザインパターン／アンチパターンを示して、監視の基本原則を詳しく説明し、後半でフロントエンド、アプリケーション、サーバ、ネットワーク、セキュリティの各テーマで強力な監視の基盤を設計して実装するための方法を示します

本の目次（大項目のみ）

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

「ビジネスを監視する」を読んで全体感をつかむ

1~4章では基本原則、6章からは各分野での監視方法、その中間にあるのが「5章 ビジネスを監視する」。

ページロード時間やAPI応答時間、そもそも正常に動作しているか等、各分野の監視はもちろん大事だが、アプリケーションは極論どれだけ雑に作られていようが、ユーザーが喜んで使っていれば問題ない。

この「喜んで使ってくれてるか」を監視するための指標・方法を本章では提示してくれる。

たとえば本章では、経営層の視点として以下のような項目がある。

• ビジネスKPI
  • 経営層の視点
    • 顧客はアプリケーションあるいはサービスを使えているか
    • 儲かっているか
    • 成長しているか、縮小しているか、停滞しているか
    • どのくらい利益が出ているか。収益性は改善しているか、悪化しているか、停滞しているか
    • 顧客は喜んでいるか

じゃあこれらのKPIに答えるためには何が必要なのか、メトリクスとログはどうする？などが書かれいる。

これらは細部のメトリクスやログの設計よりも考える価値のあることだと思う。

具体的な監視方法というより、もっと上流の話なのであんまり興味ない人もいるかもしれないが、
ビジネス監視設計をすることで、アプリケーションへの理解も深まり、より細部の監視設計にも役立つのでは？と思う。（本書の各所にもアプリケーションへの理解の重要性を書いてるし。ビジネス大事）

さいごに

文章もわかりやすく、全くの監視ド素人の自分でも理解しながら読みすすめることができた。
翻訳本は文体が独特で読みづらかったり、そもそも技術本だと文章に起伏なくてつまらんことが多いので、その点だけでもいい本だと思う。

特に前半よかった。後半の監視方法については、実際に設計をする前に読んでも頭に入ってこなくて、初読はサラーっと流し読んでもいいな。

オマケ： 読書メモ

はじめに

• 監視とは？
  • 監視とは、あるシステムやそのシステムのコンポーネントの振る舞いや出力を観察し続ける行為である (ⅶ)

第Ⅰ部 監視の原則

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

• アンチパターンとは、一見よいアイディアだが実装すると手痛いしっぺ返しを食らうものをいう。 —Jim Coplien (pp. 3)
• ❌ ツール依存
  • 監視の問題は複雑で、一つのツールで解決できるものではない
  • 各ツールが別々の役割を担っているのなら、ツールが多すぎるということはない
    • ただし、ツール同士の連携が不十分だと問題になる
• ❌ 役割としての監視
  • 監視は役割ではなくスキル
  • プロダクトへの理解があってこそ監視は活きる
  • チーム全員が一定以上の監視スキルを持つことが理想
  • 環境構築では監視を最重要項目にする
    • 監視するまで本番環境とは言えない
• ❌ チェックボックス監視
  • 準備されたチェック項目を追うだけの監視は意味がない
  • OSのメトリクスをアラートに使わない
  • メトリクスは高頻度で取得する
    • 最低でも60秒に1回

2章 監視のデザインパターン

• ⭕ 組み合わせ可能な監視
  • 専門化したツールを組み合わせて使う
  • 監視サービスの5要素
    • データ収集
    • データストレージ
    • 可視化
    • 分析とレポート
    • アラート
• ⭕ ユーザ視点での監視
  • できるだけユーザに近いところから監視を始める
    • HTTPレスポンスは正常か
    • レイテンシに問題はないか
• ⭕ 作るのではなく買う
  • 作るより安い
    • 開発コストの問題
    • セキュリティの問題
  • あなたは（おそらく）監視ツールを設計する専門家ではない

• ⭕ 継続的改善

  • 作って終わりではなく改善し続ける

  3章 アラート、オンコール、インシデント管理

  • ❓ どうしたらアラートをよくできるか
    • よく使われるアラートの2つの定義
      • 誰かを叩き起こすためのアラート（本書ではこちらに焦点をあてる）
      • 参考情報としてのアラート
    • アラートにメールを使わない
      • すぐアクションが必要 → SMSやPagerDutyに送る
      • アクション不要、要注意 → 社内チャットに送る
      • 履歴や診断のための情報 → ログファイルに送る
    • 手順書を書く
      • これは何のサービスで、何をするものか
      • 誰が責任者か
      • どんな依存性を持っているか
      • インフラの構成はどのようなものか
      • どんなメトリクスやログを送っていて、それらはどういう意味なのか
      • どんなアラートが設定されていて、その理由は何なのか
    • アラートはなるべく減らす
      • 減らしすぎには注意
    • 自動復旧できるならアラートは不要
    • 監視はなにも修復しない。システムを修復せよ
  • 🔥 インシデント管理
    • インシデントとは、「予定していないITサービスの中断、またはITサービス品質の低下。 —ITIL2011（pp. 47）」
    • インシデント発生時の対応方法を決めておく
      1. インシデントの認識（監視が問題を認識）
      2. インシデントの記録（インシデントに対して監視の仕組みが自動でチケットを作成）
      3. インシデントの診断、分類、解決、クローズ（オンコール担当がトラブルシュートし、問題を修正し、チケットにコメントや情報を添えて解決済みとする）
      4. 必要に応じて問題発生中にコミュニケーションを取る
      5. インシデント解決後、回復力を高めるための改善策を考える
    • 対応時の役割を決めておく
      • 現場指揮官（監督）、スクライブ（書紀）、コミュニケーション調整役（社内外の対応）、SME（インシデント対応）
      • 2つ以上の兼務は避ける

  4章 統計入門

  • 監視で得たメトリクスを捨てず、統計に役立てる
  • mean（= average）
    • 平均のこと
    • 平滑化することで全体感を把握しやすいグラフになる（正確さは犠牲になる）
  • 中央値（median）
    • データセットの「真ん中」
    • 一方向に大きな偏りのあるデータセットの場合、平均より中央値を使ってみる
    • (n+1)/2 = 中央値（nはデータセットのエントリ数）
    • 「0、１、１、２、３、５、８、１３、２１」の中央値は「３」
  • 周期性（seasonality）
    • データポイントがパターンを繰り返すこと
    • Webサーバのリクエスト数の周期性を知っていれば、異常値の判断が付きやすい
  • 分位数（quantile）
    • データセットのある点を表す統計的手法
    • 最もよく使われるのはパーセンタイル
      • データの大部分がどうなっているかを理解する
      • 極端なデータは無視する
  • 標準偏差（standard deviation）
    • 平均からどの程度離れているか
    • 正規分布しているデータセットに対してのみ、期待する結果が得られる
  • 統計手法を使うときの判断
    • データの偏りはあるか？
    • 極端な外れ値はよく発生する？
    • データポイントに上限、下限はあるか？

第Ⅱ部 監視戦略

5章 ビジネスを監視する

• ビジネスKPI
  • 経営層の視点
    • 顧客はアプリケーションあるいはサービスを使えているか
    • 儲かっているか
    • 成長しているか、縮小しているか、停滞しているか
    • どのくらい利益が出ているか。収益性は改善しているか、悪化しているか、停滞しているか
    • 顧客は喜んでいるか
  • 大事なとこなので書籍をよく読む
• 成功率も記録できるが、失敗率のほうがゴールに直結している
  • レイテンシは今後の問題に対する指標

• 会社のビジネスKPIを見つける

  • 見つける方法は、人と話すこと
    • まずはプロダクトマネージャ
    • 次にエンジニアリングチームのマネージャ
  • 聞くべき質問
    • アプリケーションが動いてることをどうやって知ったらよいか？　何をチェックしているか？　正常動作は？
    • アプリケーションのKPIは？　KPIの理由は？　KPIの意義は？

  6章 フロントエンド監視

  • SPAの台頭等により、JavaScript起因のエラーが増えた
    • バックエンドでは検知しづらい
  • フロントエンドのパフォーマンス監視のゴールは、「素早くロードされること」
  • 遅いアプリケーションのコスト
    • ページロード時間が1秒遅くなると、平均でページビューが11%、コンバージョンが6%、顧客満足度が16%下がる（http://bit.ly/2y66Glp）
      • 逆に1秒ほど早くなって各要素が10%増したという報告もある
    • 最適な速度は？
      • amazonは莫大なトラフィックのあるプライムデー期間（2017年）でも 2.4秒 以下を保った
  • フロントエンド監視の2つのアプローチ
    • リアルユーザ監視（real user monitoring、RUM）とシンセティック監視（synthetic monitoring）
      • RUMはGoogle Analytics
    • RUM
      • フロントエンドパフォーマンスのメトリクス
        • Navigation Timing API
          • navigationStart:ブラウザによってページリクエストが開始されたタイミング
          • domLoading:DOMがコンパイルされロードが始まったタイミング
          • domInteractive:ページが使用可能になったと考えられるタイミング。ロードが終わっているとは限らない
          • domContentLoaded:すべてのスクリプトが実行されたタイミング
          • domComplete
            • ページがすべて（HTML,CSS,JavaScript）のロードを終えたタイミング
        • Google Analyticsへメトリクスを送ることができる
          • https://developers.google.com/analytics/devguides/collection/analyticsjs/user-timings?hl=ja
    • シンセティック監視
      • 対策を打たないと、Webアプリケーションは時間の経過とともに悪化していく
      • WebpageTest.org
        • プルリクエストごとにパフォーマンスの影響を監視できる

  7章 アプリケーション監視

  • メトリクスでアプリケーションを計測する
    • クエリの実行にかかった時間やAPIの応答時間、1日のログイン数などを計測してみる
    • StatsD
      • コードの中にメトリクスを追加するためのツール
      • モダンな監視スタックには不可欠な存在
      • メトリクスをUDP経由でStatsサーバに送信するためパフォーマンスに大きな影響を与えない
  • healthエンドポイントパターン
    • アプリケーションの健全性を伝えるアプリケーション内のHTTPエンドポイントであり、アプリケーションについての基本的な情報を含む場合もある
  • メトリクスにすべきか、ログにすべきか
    • チームにとってメトリクスで考えるほうが楽か、ログで考えるほうが楽か？
    • その問題について、メトリクスとログのどちらがより効果的か？
  • 何のログを取るべきか
    • 何でもかんでも取るのは得策じゃない
    • 最も必要な情報を考えてログを取る
      • なにかがおかしくなった時に、最初にする質問は？ トラブルシューティングあるいは単なる仕組みの説明時に便利な情報は？

  ８章

  • ここからメモ不在。どこに書いたっけ。