監視設定の確認シート

監視の目的は、異常を全部拾うことではなく、「対応が必要なときだけ気づける」状態を作ることです。鳴りすぎる通知は、鳴らないのと同じになります。

1. 止まって困る機能を先に決める

すべてを同じ重さで監視することはできません。まず、止まると事業に影響する機能を3つほど挙げます。申込みが完了しない、ログインできない、決済が通らない、といった「そこが止まると売上か信用が傷む」機能です。監視の設計は、この3つから逆算します。

監視には段階があります。外から見て動いているかを確認する層、システム内部のエラーを拾う層、資源の消費を見る層、そして事業の数字が普段と違わないかを見る層です。小さなチームでは、上の二つだけでも大きな効果があります。下の二つは、余力ができてから足します。

最も単純で、効果が大きいのが外形監視です。外部のサービスから定期的に自社の画面へアクセスし、正しく表示されるかを確認します。全体が落ちたときに確実に気づけるうえ、設定も簡単です。まだ入っていなければ、ここから始めてください。

外形監視は全体の停止に気づけますが、一部の機能だけが壊れている状態は拾えません。システム内部で発生したエラーを集める仕組みを入れ、発生した場所と内容が分かるようにします。エラーの内容に個人情報が含まれないよう、記録する項目には注意してください。

通知先が「全員宛のメール」だと、誰も自分の担当だと思わず放置されます。誰が受け取り、誰が対応するかを決めます。時間帯によって扱いを変えることも検討します。夜間に鳴っても対応できないのであれば、夜間に鳴らす通知は本当に必要なものだけに絞ります。

監視が失敗する最も多い形は、止まることではなく、鳴りすぎて誰も見なくなることです。1週間の通知件数を数え、そのうち実際に対応が必要だったものの割合を見ます。対応不要の通知が大半を占めるなら、しきい値を見直すか、その通知を止めます。通知は減らしても構いません。

気づけても、その後どうするかが決まっていなければ意味がありません。通知の種類ごとに、最初に確認する場所と、次に取る行動を書いておきます。ここは運用手順書の障害対応の章とつながるので、同じ場所にまとめておくと探しやすくなります。

この内容で相談したい

チェックした内容をそのままフォームに貼り付けていただければ、そこから具体的な進め方と概算をお伝えします。