利用者が困る状態から、見るものを選ぶ
ページが開けない、送信した内容が届かない、処理が終わらないなど、利用者の行動に沿って影響を挙げます。その状態を見分けるために必要な応答、処理結果、記録を選びます。
CPUや実行回数だけを見ても、業務の完了までは分からない場合があります。基盤の状態と、利用者が目的を達成できたかを分けて確認する構成を検討します。
値・記録・動作確認を使い分ける
| 値・記録・動作確認を使い分ける | メトリクス | ログ | 利用者の操作に沿う確認 |
|---|---|---|---|
| 確かめたいこと | 量や割合、時間の変化 | 個別の処理で何が起きたか | 画面や一連の処理が使えるか |
| 合わせて決めること | 集計単位、期間、通知する条件 | 必要な識別子、保存期間、閲覧範囲 | 検証用入力、実データへの影響、実行頻度 |
| 単独では分からないこと | 個別の失敗の詳細 | 全体の傾向や利用者の成功 | 内部原因の特定 |
通知を受けた人が、迷わず調べられるようにする
- 影響する機能を確認する
通知に関連する機能と確認先を結び付けます。通知本文へ機密情報を詰め込まず、必要な記録へ安全にたどれる方法を考えます。
- 同じ処理の記録をたどる
時刻、依頼の識別子、直前の変更を照合します。対象外の情報まで収集しないよう、記録する項目を決めます。
- 復旧と次の確認を残す
対処後に利用者の操作が戻ったかを確認し、経過と担当を残します。通知が止まったことだけを復旧の根拠にしないようにします。
値が届かないときの扱いも決める
- 欠測の意味
- 定期的に届く値が止まったのか、出来事があるときだけ届く値なのかで意味が変わります。欠測を一律に正常や異常へ置き換えないようにします。
- 通知の設計
- 対象メトリクスに合う欠測時の判定、継続時間、担当への伝え方を確認します。
- 見直す条件
- 新しい機能、記録方法、運用時間帯の変更で前提が変わったとき、監視条件と手順も更新します。
通知を増やす前に確認すること
すべてのエラーを通知すれば見逃しを防げますか。
対処が必要な状態を区別できないほど通知が増えると、判断が難しくなります。利用者への影響、継続、調べるための記録を整理し、通知する条件と対応を対応付けます。
グラフが正常なら、サービスも正常ですか。
選んだ値で分かる範囲に限られます。フォーム送信など利用者の一連の動作と、裏側の処理結果を確認する方法も必要に応じて組み合わせます。