2-5 夜間の障害では対話型のトラブルシューティングは不要
夜間や無人時間帯に発生する障害に対して、すべてを即時に人手で調査・復旧する運用は現実的ではない。
重要なのは、事前に「既知事象」を整理し、夜間は情報収集と状態確認に留めることで、不要な介入を減らすことである。
既知事象とは、過去の障害履歴、検証環境で確認された挙動やログ、製品ベンダーが公開している不具合情報（Known Issues）、および過去に取得したコアダンプ解析結果などから、あらかじめ把握できている事象を指す。
これらを整理しておくことで、夜間に発生したアラートが想定内なのか、即時対応が必要なのかを迅速に切り分けられる。
アラームトリガーによってログやコアダンプが自動収集される前提であれば、夜間に実施する作業は主に以下に限定できる。
・リアルタイムログの確認
・サービスやプロセスの稼働状態チェック
・CPU／メモリ／ディスク使用率や I/O 遅延状態の確認
・必要に応じたコアダンプ取得状況の確認
プロセス再起動やサービスリスタートは一定の判断を伴うため、既知事象として定義されていない限り、夜間は実施せず、ログやコアダンプなどの情報収集のみに留める運用が望ましい。
取得されたログやコアダンプは日中帯に詳細解析を行い、原因究明および恒久対策へつなげる。
1. 具体的な指標による監視
夜間監視では抽象的な「メトリクス異常」ではなく、以下のような具体的指標を用いる。
・CPU使用率（全体およびコア単位）
・メモリ使用率と available メモリ
・ディスク使用率
・ディスクI/O遅延（await など）
・ネットワーク遅延やパケットロス
・アプリケーションエラーログ
これらを単独ではなく組み合わせて評価することで、誤検知を抑えつつ本質的な障害を見極められる。
2. CPU使用率に関する補足
CPU使用率については、バッチ処理やガベージコレクション（Garbage Collection：不要になったメモリを自動回収する処理）、バックアップ処理などにより、瞬間的なスパイクが発生することは正常動作の範囲で起こり得る。
そのため単発のピーク値のみで異常と判断せず、
・高負荷が一定時間以上継続しているか
・I/O遅延やメモリ逼迫を伴っているか
・アプリケーションエラーやコアダンプ発生と相関しているか
といった継続性と相関を基準に判定する必要がある。
夜間対応では特に、瞬間的なCPUスパイクを理由とした即時再起動は避け、ログおよびコアダンプの収集と状態観測に留めることが望ましい。
3. Linuxのメモリ挙動を理解しておく
Linuxでは空いているメモリをファイルキャッシュとして積極的に利用する設計になっている。
そのためアプリケーションが使用を終えたメモリであっても、システムから新たなメモリ要求が発生しない限り、すぐには解放されない。
結果として、
・メモリ使用率が高く表示される
・free メモリが少なく見える
といった状態になるが、available メモリが十分に確保されていれば直ちに異常とは限らない。
夜間監視では、
・available メモリ
・スワップ発生有無
・CPU負荷
・I/O遅延
・アプリケーションログ
・コアダンプ取得有無
を組み合わせて総合的に判断することが重要である。
4. 様子見ルールのサンプル
夜間対応では「異常値＝即対応」ではなく、事前に定義した条件に基づいて“様子見”と“即対応”を切り分ける。
[CPU使用率]
様子見
・80〜90%程度の一時的上昇で5分以内に回復
・GCやバッチ処理によるスパイクと判断できる
・I/O遅延やアプリケーションエラーを伴わない
即対応／エスカレーション
・90%以上が10分以上継続
・I/O遅延やサービス応答低下を伴う
・アプリケーションエラーが同時に増加
[メモリ使用状況]
様子見
・メモリ使用率は高いが available メモリが十分
・スワップアウトが発生していない
・ファイルキャッシュ増加による見かけ上の使用率上昇と判断できる
即対応／エスカレーション
・available メモリが枯渇傾向
・スワップが継続的に発生
・OOM Killer(メモリリソースを多く消費しているプロセスを強制的に停止) のログを検知
[ディスク使用率]
様子見
・使用率60〜85%程度で安定
・急激な増加が見られない
即対応／エスカレーション
・使用率90%以上
・ログ肥大などで短時間に増加
[ディスクI/O遅延]
様子見
・一時的な遅延上昇のみ
・数分以内に正常値へ復帰
即対応／エスカレーション
・await が継続的に悪化
・アプリケーションレスポンス低下を伴う
[アプリケーションログ]
様子見
・既知事象として登録済みの警告ログのみ
・単発の例外で再発していない
即対応／エスカレーション
・未知のエラー
・同一エラーが短時間に多発
・サービス停止につながるログ
まとめ
夜間の障害対応に対話型トラブルシューティングを持ち込むと、属人化や判断ミスの温床となる。
そのため設計段階から、
・自動ログおよびコアダンプ収集
・CPU／メモリ／ディスク使用率や I/O 遅延状態の取得
・ガベージコレクションによるCPUスパイクやLinuxのメモリキャッシュ挙動といった既知事象の定義
・未知事象はログとコアダンプの情報収集のみに留める
という方針を組み込んでおくことが重要である。
夜間は人が考える時間ではなく、システムが淡々とログとコアダンプを集める時間として扱う。
これが、無人・遠隔環境における安定したインフラ運用の基本となる。
本記事の内容は、次項目に対応します。
Link:IT infrastructure system operation for remote areas（遠隔地向け IT インフラ運用）
2-5 Night-time failures do not require interactive troubleshooting
(夜間の障害では対話型のトラブルシューティングは不要)
