業務が最後まで進んだかを監視する

判断の意味を明確にする

サーバーが正常でも顧客の仕事は止まることがあります。技術的なエラーとともに、アプリが実現すべき結果を監視します。重要な流れごとに開始イベント、永続的な中間状態、完了の証拠を決めます。状態間の滞留は、エラー数に現れない問題を説明してくれます。

役割と選択肢

対応できる少数の信号から始めます。稼働と応答時間はアプリを、最古の未処理、完了失敗、来るはずのイベントの不在は業務を表します。Google SREの監視章も症状と原因を区別しています。利用者に見える症状で緊急度を決め、技術情報で調査します。ログ一件ごとに呼び出す必要はありません。

変更を追ってみる

架空の見積フォームが依頼を保存し、通知をキューに積む例です。Webは成功してもメール処理が止まれば、最古の未送信時間を見なければ分かりません。通知にはキューの場所、安全な確認手順、再試行条件を付けます。復旧は、依頼を失ったり重複させたりせず滞留分を届けたことで確認します。

失敗する経路を確かめる

静かな画面は需要なし、収集機能の故障、入口停止のいずれかかもしれません。区別し、担当も対応手段もないアラートを避けます。通知本文に個人的な相談内容を含めないでください。ローカルのワーカー停止や依存先障害の模擬で、警告と復旧表示の両方を確かめます。

各アラートに実行できる対応を付ける

通知例ではプロセス名だけでなく、遅れている顧客作業を伝えます。キュー、最古の滞留時間、観測時刻、権限のある担当者の確認手順を含め、個人の本文は入れません。初動でワーカー停止とメール依存先障害を区別できる情報が必要です。

安全にできる操作を決めます。手順には稼働確認、加工した最近のエラー、予約中か完了済みかの確認を置きます。再試行、期限切れ占有の回収、停止して上位へ相談する条件を説明します。応答だけ失われて外部処理は完了している場合、全件再実行は重複を起こします。分からない場合は不確実性を記録して照合し、きれいな成功を作らないでください。

制御した環境で全経路を試します。ワーカーを止め、架空依頼を作って滞留を観察し、ローカル受信先への警告を確認します。再開後は完了と復旧状態も見ます。収集機能も止めて試し、観測が来ないグラフを健全な空キューに見せないようにします。事後は重複通知、担当、最初の診断を改善しますが、慣れた症状だからと隠しません。適切な仕事へ適切な対応をすることが目的です。

運用レビューの確認

合意しておくルール

何をもって成功とするか。どれほど待ったら介入するか。誰に通知し、安全に何ができるか。ソフトウェアの運用検討では、誰も見ない指標の壁ではなく短い運用地図を作ります。