入門監視を読んだ#
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 を測るのではなく、毎日の酒の量を計測しよう！！