2-2 夜間システム障害時の行動について定義されていること

本節では、遠隔地・無人運用を前提としたインフラ環境において、夜間にシステム障害が発生した場合の「人とシステムの行動」をあらかじめ定義しておく重要性について整理します。

1-5 では「夜間に許容するサービス状態」を扱いましたが、本項ではそれとは異なり、その状態に達した際に誰が・いつ・何を行うのかという運用行動そのものに焦点を当てます。

1. なぜ夜間の行動定義が必要なのか

夜間の障害対応では、以下の制約が前提となります。

================================
・オンサイト要員が存在しない
・即時の人間判断が困難
・対応はオンコールまたは翌営業日になる
================================

このような環境では、「障害が起きたら対応する」という曖昧な運用は成立しません。
行動が定義されていない場合、

================================
・誰が判断するのか分からない
・軽微な障害でも毎回起こされる
・重大障害なのに朝まで放置される
================================

といった状況が発生しやすくなります。

そのため夜間運用では、障害そのものよりも、障害発生後の行動を事前に設計しておくことが重要になります。

2. 夜間障害時に定義すべき行動要素

夜間システム障害時の行動定義には、最低限以下の要素を含める必要があります。

2-1. 初動対応の責任範囲

================================
・まず、最初にアラートを受け取るのは誰か
・その人は判断者なのか、連絡係なのか
================================

を明確にします。
例として、

================================
・監視 → オンコール一次対応
・判断 → インフラ責任者
・実作業 → 翌営業日の運用チーム
================================

といったように役割を分離しておくことで、夜間の混乱を防げます。

2-2. 夜間に「起こす条件」の定義

すべての障害で人を起こす設計は現実的ではありません。
そのため、

================================
・どの条件なら即時対応
・どの条件なら翌営業日対応
================================

を事前に定義します。

重要なのは、判断を人の感覚に委ねず、条件ベースで機械的に決まるようにすることです。

2-3. 自動処理と人間介入の境界

夜間は基本的に自動復旧が中心となります。
そのため、
================================
・自動再起動の回数
・リトライ間隔
・自動処理を打ち切る条件
================================

を明確にします。
同時に、

================================
・どの時点で人間判断に切り替えるのか
・その際の通知先
================================

も定義しておく必要があります。
これにより、無限再起動ループや意味のないリトライ継続を防ぐことができます。

2-4. エスカレーションルート

夜間対応では段階的なエスカレーションが重要になります。
例：
================================
・自動復旧
・オンコール一次対応
・インフラ責任者
・ビジネス側判断
================================

この順序と連絡手段（電話／チャット／メール）を明文化しておきます。

3. 実運用から見える夜間判断の考え方（経験則）

実際の運用経験上、すべてのアラームが夜間の即時対応を必要とするわけではありません。

多くのインフラ構成ではハードウェアは冗長化を前提として設計されており、ディスク障害や電源系アラームなどのハードウェア系イベントはフェイルオーバーによりサービス継続が可能なケースが大半です。
この場合、夜間の即時対応は不要で、翌営業日の対応で十分であることがほとんどです。

一方で注意すべきなのはソフトウェア側の異常です。

通信系・Web系を問わず共通して利用できる代表的な判断材料は 200 OK の成功確率 です。

================================
・通信系では SIP トランザクションにおける 200 OK 応答率
・Web 系では HTTPS リクエストに対する 200 OK 応答率
================================

これらはネットワークからアプリケーションまでを横断した、実サービス品質を表す指標になります。

これらの成功応答率、トラフィック量、レイテンシ、エラー率といった
Key Performance Indicator（KPI:主要業績評価指標） を用いて夜間判断を行うことで、単なるアラームベースではなく、実サービスに基づいた対応が可能になります。

また、電話システムのようなリアルタイム系サービスでは、最低限保証すべきサービスラインを明確にしておく必要があります。

================================
・通話が成立すること
・特に緊急呼が可能であること
================================

これらが維持されている場合、

================================
・付加サービス
・管理系機能
================================

は翌営業日対応としても許容できるケースが多くなります。
同様に、

================================
・課金系システム
・プロビジョニングサービス
================================

といったバックエンド系機能についても、通話が成立している限り夜間対応の優先度は相対的に低く設定されます。

重要なのは、

どこが最低サービスラインなのか
どこからが付帯サービスなのか

を整理し、それぞれに対応優先度を割り当てることです。

これらを Key Performance Indicator（主要業績評価指標）と結び付けて定義することで、

「どの指標が、どの値を下回ったら、誰を起こすのか」

を機械的に判断できるようになります。

4. まとめ

夜間システム障害時の行動定義は、無人運用インフラにおける中核要素です。
1-5 が「許容状態」を定義する項目であるのに対し、本項は

================================
・誰が
・いつ
・何をするか
================================

という運用行動そのものを定義します。

この行動設計が明確になることで、不要な夜間対応を減らし
本当に重要な障害に集中でき、安定した遠隔運用が可能になります。

本記事の内容は、次項目に対応します。
Link:IT infrastructure system operation for remote areas（遠隔地向け IT インフラ運用）
2-2 Behavior during night-time system failures is defined
(夜間システム障害時の行動について定義されていること)