入門監視を読んだ

1,2 章

• 「監視は運用がやるもの」とは限らない！
• OS のメトリクスだけとって満足？結局サーバ落ちた原因は不明じゃ意味ない
• 取得間隔が 5 分ごとじゃ何もわからない。大切な情報が抜け落ちてるかも
• 「システムが正常に動いてる」の定義は？？
• ユーザ目線で監視を始めよう(上の定義にも繋がる)
• SaaS の監視サービスを使っちゃおう！楽だし！
• 監視の見直しや改善って運用サービスメニューにありますか？

---

3 章アラート、オンコール、インシデント対応

アラート

• 1.即時で判断/対応が必要なこと
• 2.参考情報としてのアラート(判断/対応は翌日朝で良い)
• 1,2 はそれぞれ適切な通知先がどこか考えよう
• ポイントとしては、アラートは「人の判断が必要なため」行う
• アラートには対応手順へのリンクを書こう
• 決まった手順になるなら自動化できるのでは？と考える
• 固定の閾値だけでなく、変化量を使うなどもある。統計を勉強しよう！

オンコール

• オンコール担当への配慮を忘れずに
• 時間的、精神的な配慮

インシデント対応

• 部署やサービスにあったフローを考えよう
• 振り返りは忘れずに

---

4 章統計入門

平均値について

• 平均を取ると識別しやすいパターンを持ったグラフになり、グラフは見やすくなる
• ただし。極端な値も見えるので、重要かもしれないデータを失う

パーセンタイルについて

• 帯域幅やレイテンシに使われる

• 注意点として、平均は取れない

  • 1 時間ごとのパーセンタイル ×24 時間分の平均は、1 日のパーセンタイルとは異なる！！
  • 一部のデータが切り捨てられていることを忘れずに。レイテンシに使うなら最大値の計測も別途行おう

---

5 章ビジネスを監視する

• ビジネス上の KPI から  落としていって監視項目を決めよう

  • 例えば CPU 使用率、なぜその項目を監視するのか
  • ユーザー影響があるのか？
  • これはユーザ目線の失敗率、レイテンシも計測して、影響の有無を判断。ないなら問題なし これはさらに突き詰めるとビジネス KPI が何かに遡る
• サーバ内部のレイテンシの比較
• ユーザ目線は、ネットワーク JS のパース、描画
• ユーザ目線の監視は GA などを使おう

---

6 章フロントエンド監視

• 監視は Ops がやること！！とは限らない！！
• JS の動きや仕組みを理解しよう
• ユーザの体感している時間を監視しよう
• JS が吐く例外の監視
• statsd,graphite,GoogleAnalytics などツールはある！

---

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

• アプリケーションパフォーマンス監視 APM ツール
• StatsD が推されてる！
• ビルドパイプラインの監視もしよう！！
• どのデプロイからパフォーマンスが落ちたかわかる！！

---

8 章サーバ監視

9 章ネットワーク

10 章セキュリティ

---

11 章

ビジネス視点から決めてく

---

付録

• 手順書の例
• 運用をサービスにあわせる

• OS メトリクスは結果

  • γGTP を測るのではなく、毎日の酒の量を計測しよう！！