概要
developers summit 2020に参加してNew Relicの大谷さんのお話を聞いてきました。
漠然とやってみたいな〜と思っていたことのちゃんとしたフレームを教えてもらえた気がします。
「これ、入門監視で見たことある！」となっていたけどｗｗ
目次
セッション情報
- 14-B-2 02/14 11:05 ～ 11:50 守りのモニタリングから攻めのモニタリングへ 🔗
- デブサミ2020【14-B-2】守りのモニタリングから攻めのモニタリングへ #devsumiB #devsumi - Togetter 🔗
- 参加者レポート：【デブサミ2020】セッションレポート：14-B-2 守りのモニタリングから攻めのモニタリングへ｜dora_e_m｜note 🔗
発表資料
- スライド公開無いっぽい
トピック
オブザーバビリティ成熟モデル
5段階で成熟させていく。
- 計測開始
- 受動的対応
- 積極的対応
- 予測的対応
- データ駆動
効果が劇的に現れるわけではないけど、いいフレームですよと…
会場で、弊社はこの5段階で現すとどこだろうと考えてた
オブザーバビリティ成熟モデル：計測開始
まず、何を計測するか。
- レイテンシー
- トラフィック
- エラー
- サチュレーション（リソースの使用率）
SRE本ではこれを計測すべきと言っていると…
じゃあ、何をもって「正しく動いている」とするか 色々な角度から見た時に色々な正しく動いているの定義がありますよと…
従来の監視の「動いているか動いていないか」じゃ足りない。
オブザーバビリティは「どう動いているか」を計測することらしい。
どうやってオブザーバビリティを始めるか（？）
前述のどう動いているかを監視するための、4本柱があるらしい。
- メトリック
- イベント
- ログ
- トレース
noteでもあった、健康診断的な監視からカイゼンのためのデータ収集ですね。
オブザーバビリティ成熟モデル：受動的対応
計測を開始して初めて行動ができると。
事が起きてから対応
ex.アラートが上がって対応
オブザーバビリティ成熟モデル：積極的対応
アラートじゃないけれども…をカイゼンしていく。
これこそ、計測がきちんと出来ていないと難しいよな〜と思った。
スライド撮影が間に合わなかったんだけど、アクセスログの小さなポコ山とかもちゃんと潰してて「はぇ〜」ってなった。
オブザーバビリティ成熟モデル：予測的対応
前段のステップをちゃんとこなして、安定稼働を実現してカイゼンを進めて
ベースライン（計測値の基準、システムが安定していると言う基準）が出来て初めて予測ができるよと。
データ大事。
これができるとコスト削減とかができるようになってくる。
ex.リソース過剰じゃない？が見えてくる。
オブザーバビリティ成熟モデル：データ駆動
noteの時とまんま同じこと言ってて笑った。
データをもとに分析/判断/仮説/検証をしてUXをカイゼンしていくと。
やりてええええ。
まとめ
- オブザーバビリティ成熟モデルは良いぞ。
- データ計測にNew RelicのAPMどうっすか？
雑感
弊社もAPM入れたい！となったけど、その前にまともなアプリをインフラに載せて欲しい！ともなりました。