前回のログに、傾向を見る目を足す
前回のS-02では、調査に耐える形として構造化ログを整えました。ログは、一件一件の出来事を残す、いわば点の記録です。しかし「先月より少し遅くなってきた気がする」といった、じわじわ進む変化は、点の記録をいくら並べて眺めても見えてきません。この講義では、その変化を数値の傾向として捉えるメトリクスを、運用の観測装置に加えます。
このスライドのポイント
- S-02: 調査に耐える形として構造化ログを整えた（＝一件ごとの点の記録）
- 点の記録では「じわじわ進む変化」は見えない
- この講義: その変化を数値の傾向として捉える観測装置を運用に加える
メトリクスの定義と基本3指標
メトリクスとは、システムの状態を時系列の数値として記録し、観測するものです。運用でまず見るべき基本の3指標があります。1つ目は応答時間で、C-10で学んだ遅延を実際の数値として測ったものです。2つ目はエラー率で、D-06で見た5xxのような失敗が全体のうちどれだけを占めるかの割合です。3つ目は資源の使用率で、B-01で学んだCPUやメモリがどれだけ使われているかを表します。ログが出来事の記録であるのに対し、メトリクスは傾向の数値であり、「増えている」「悪化している」という動きそのものが見えるのが特徴です。
このスライドのポイント
- メトリクス＝システムの状態を時系列の数値として記録・観測するもの
- 基本3指標
なぜ必要か——数値がないと「体感」でしか語れない
メトリクスがないと、「なんだか遅くなってきた」という体感でしか状態を語れません。いつから、どれくらい、どの指標が悪化したのかを、数字で示すことができないのです。これでは、M-06で数値として決めた非機能要件を、実際の測定で検証するすべがありません。目標を数値で立てたのなら、現実の状態も数値で測れなければ、達成できているかどうかを確かめようがないのです。
このスライドのポイント
- メトリクスがないと「なんだか遅くなってきた」という体感でしか状態を語れない
- いつから・どれくらい・どの指標が、を数字で示せない
- M-06で数値化した非機能要件を、実測で検証できなくなる
構造——ログとメトリクスの棲み分け
メトリクスとログの違いを構造で整理します。ログは1件ごとの詳しい出来事で、なぜ起きたのかを調べる調査向きです。メトリクスは全体の傾向を示す数値で、いつから悪化したのかを見張る監視向きです。この監視向きという性質は、次の講義以降で扱う仕組みへとつながっていきます。そして3つの指標を時系列のグラフとして並べると、一目では気づけないほど少しずつ進む悪化も、線の傾きとして姿を現します。
処理の流れ——経費アプリの月末に山ができる
公開済みの経費アプリで考えてみます。応答時間のグラフを何ヶ月かぶん眺めていると、毎月末に決まって山ができていることに気づきます。これは、月末に申請が集中し、M-06で想定した50人の利用が重なるためです。体感では「今日は少し重いかな」で終わってしまう変化も、グラフにすれば毎月末という規則として見えてきます。だからこそ、山が来る前に手を打つ、という先回りができるようになります。数字は、体感より先に教えてくれるのです。
このスライドのポイント
- 公開済みの経費アプリ（社内50人）の応答時間グラフを数ヶ月ぶん眺める
- 毎月末に決まって山ができている＝申請の集中（M-06で想定した50人の重なり）
- 体感なら「今日は重いかな」で終わる変化が、グラフでは「毎月末」という規則になる
- 山が来る前に手を打つ、という先回りができる
技術サンプル——3指標のグラフ概念図
スライドに、基本3指標を時系列で並べたグラフの概念図を載せました。目的は、正常なときの形をあらかじめ知っておくことです。異常というのは、正常な形との差としてしか分かりません。ふだんの応答時間が低いところで一定だと知っていれば、それが急に伸びたときに初めて「おかしい」と判断できます。逆に正常の形を知らなければ、その数字が高いのか低いのかすら分かりません。まず平常時のグラフの形を目に焼き付けておく、これが観測の出発点です。AIには「最低限観測すべきメトリクスと、その正常範囲の目安を、非機能要件から提案してください」と頼めます。
混同しやすい概念——ログとメトリクス
ここで、ログとメトリクスの役割を混同しないよう対比しておきます。ログは出来事の記録であり、なぜ起きたのかを掘り下げる道具です。メトリクスは数値の傾向であり、いつから、どれくらい悪化したのかを映す道具です。どちらが上ということはなく、実際の障害対応では、メトリクスで異常の兆しをつかみ、そこからログでその原因を追う、というように両方を行き来します。
バイブコーディングでの確認点——観測はもう始められる
うれしいことに、R-03で学んだPaaSのような公開サービスは、応答時間やエラー率といった基本メトリクスを、はじめから提供していることが多くあります。つまり、自分でゼロから作らなくても、すでに観測の材料はそろっているのです。まずはAIに「このアプリのメトリクスはどこで見られますか」と聞いてみてください。表示場所を教えてもらうだけで、その日から傾向の観測を始められます。
このスライドのポイント
- R-03のPaaSのような公開サービスは、応答時間・エラー率などの基本メトリクスを標準提供していることが多い
- 自分でゼロから作らなくても、観測の材料はすでにそろっている
- まずAIに「メトリクスはどこで見られますか」と聞くだけで、その日から傾向の観測を始められる
まとめと次回への橋渡し
最後に一問一答です。「じわじわ遅くなっている」という変化を捉えられるのは、ログとメトリクスのどちらでしょうか。……答えは、メトリクスです。時系列の数値だからこそ、少しずつ進む傾向を線として見られるのです。30秒のまとめです。メトリクスはシステムの状態を時系列の数値で観測するもので、基本は応答時間・エラー率・資源の使用率の3つ。ログが出来事なら、メトリクスは傾向であり、平常時の形を知っておくことが異常発見の土台になります。次回は、1つのリクエストがたどった経路を追いかけるトレースへ進みます。関連資料は「アプリ運用チェックリスト」と「AIアプリの品質評価シート」です。
このスライドのポイント
- 一問一答:「『じわじわ遅くなっている』を捉えられるのはログとメトリクスのどちら？」→ メトリクス
- 30秒まとめ: メトリクス＝時系列の数値。基本は応答時間・エラー率・資源の使用率の3つ。ログが出来事なら、メトリクスは傾向。平常時の形を知ることが異常発見の土台
- 次回: S-04 トレース（1つのリクエストがたどった経路を追う）
- 関連資料: 「アプリ運用チェックリスト」「AIアプリの品質評価シート」
