1-5 無人期間中の許容可能なサービス低下を定義
本節では、前節までで整理した 運用体制・復旧手段・手動対応の限界 を前提に、
「無人期間（夜間・休日・長期休暇など）に、どこまでのサービス低下を許容するのか」 を明確に定義する重要性について整理する。
本記事でいう無人期間とは、即時の有人対応や判断が行えない時間帯 を指す。
1.背景と位置づけ
これまでの記事では、以下の点を段階的に整理してきた。
================================
・遠隔地・少人数体制では 即時復旧が常に可能とは限らない
・自動復旧が機能しないケースでは 手動復旧に依存する場面が残る
・無人期間中は、対応開始そのものが遅延するリスクがある
================================
このような制約条件がある以上、
「無人期間でも常に通常品質を維持する」ことを前提に設計・運用するのは現実的ではない。
そのため、あらかじめ 許容可能なサービス低下（Acceptable Service Degradation）を定義しておく必要がある。
2.許容可能なサービス低下とは何か
許容可能なサービス低下とは、以下を明確にすることを指す。================================
・無人期間中に発生してよい障害の範囲
・サービス品質がどこまで低下しても「緊急対応不要」と判断できるライン
・復旧が有人時間帯まで遅延しても許容される状態
================================
重要なのは、「障害を起こさないこと」ではなく「起きた場合の扱いを決めること」 である。
3.具体的な定義例
以下は、無人期間中における許容範囲の定義例である。
================================
・冗長構成の片系停止は許容（サービス継続が前提）
・性能劣化（レスポンス遅延・処理能力低下）は許容
・一部の非クリティカル機能停止は許容
・監視アラートは記録のみで即時対応不要
================================
一方で、以下は 許容不可 と明確に線引きする。
・データ消失・整合性破壊
・サービス完全停止
・セキュリティインシデント
4.仮想化（物理サーバー（ベアメタル）から仮想マシン（VM）への移行）におけるサービス低下の見落としポイント
物理サーバー（ベアメタル）から仮想マシン（VM）へ切り替える設計においても、
無人期間中の許容可能なサービス低下を考えるうえで注意すべき点が存在する。
一般的に、移行設計時には以下のような考え方が取られることが多い。================================
・物理サーバー（ベアメタル）の処理性能をベースラインとして算出する
・仮想マシン（VM）環境では1台あたりの処理性能低下を見込む
・台数を増やすことでスループットを同等、もしくは拡大する
================================
しかし実際のバーチャル環境では、
「台数を増やせば単純に処理能力も比例して増える」わけではない 点に注意が必要である。
特に以下のような要因が重なった場合、
期待していたスループットに達しない、あるいは想定外のサービス低下が発生することがある。================================
・サーバー台数増加に伴うネットワークスループットの上限
・サーバー間同期処理の増加による内部トラフィックの増大
・分散構成による DNS / NTP トラフィックの増加
・対向サーバー（DB・外部システム等）の処理負荷増加
================================
これらの影響により、
ネイティブハード時代の期待スループットを単純に足し算で適用すると、
ネットワークや周辺システムが先に限界を迎える ケースがある。
この状態で障害や切り替えが発生すると、本来は許容範囲と考えていた性能劣化が、================================
・レイテンシ急増
・タイムアウト多発
・二次障害の誘発
================================
といった形で顕在化し、結果的に 全体サービス停止へと波及する 可能性がある。
無人期間中の運用を前提とする場合には、
================================
・仮想化後の実効スループット
・ネットワークを含めたボトルネック
・障害・切り替え時に発生する付加トラフィック
================================
を含めて、
「性能劣化が起きた状態」をあらかじめ許容可能なサービス低下として定義できているか を確認しておくことが重要である。
5.冗長構成において特に注意すべき点
冗長構成を採用している場合でも、両系が同時に稼働し、片側の余力を待機系相当として見なしている運用 では注意が必要である。
平常時に両系でトラフィックや処理を分散している場合、切り替え発生時には以下のような事象が起こりやすい。================================
・フェイルオーバー時に一時的な処理スパイクが発生する
・セッション再確立や再試行が集中する
・バッチ処理や再同期処理が重なる
================================
これらを考慮せず、待機系の余力を過信した設計・運用 を行っていると、
切り替えを契機に待機側まで処理オーバーとなり、
結果として 冗長構成でありながら全停止に至る 可能性がある。
無人期間中にこの状態に陥ると、
本来は「許容可能なサービス低下」として扱えるはずの障害が、
即時対応が必要な重大障害へと転化する 点に注意が必要である。
このため、無人期間における許容範囲を定義する際には、
================================
・フェイルオーバー時の瞬間最大負荷
・処理スパイクを含めた性能余力
・無人期間中は切り替え自体を抑制する判断
================================
といった観点を含めて整理しておくことが重要となる。
6.定義しない場合に起こる問題
無人期間中の許容範囲が定義されていない場合、次のような問題が発生しやすい。
================================
・軽微な障害でも深夜・休日に呼び出しが発生する
・担当者ごとに判断が異なり、対応品質がばらつく
・結果として運用負荷が慢性的に高くなる
================================
これは、これまで整理してきた 「人に依存しない運用設計」 という流れとも矛盾する。
### SLO / SLA・運用ルールとの関係
許容可能なサービス低下は、以下と整合して定義する必要がある。================================
・SLA（Service Level Agreement）
・SLO（Service Level Objective）
・監視ルール・アラート閾値
・エスカレーション基準
================================
特に、「無人期間中はSLOを一時的に緩和する」 という考え方は、現実的な運用設計として有効である。
SLO は単なる品質目標ではなく、「無人期間中にどこまで我慢するか」を判断するための運用基準 として機能する。
まとめ
無人期間中の運用を安定させるためには、
================================
・無人期間の制約を前提として受け入れる
・許容可能なサービス低下を事前に定義する
・復旧タイミングと責任範囲を明確にする
================================
ことが重要である。
これはサービス品質を下げるための考え方ではなく、
「守るべき品質を確実に守るための線引き」 と言える。
本記事の内容は、次項目に対応します。
Link:IT infrastructure system operation for remote areas（遠隔地向け IT インフラ運用）
1-5 Acceptable service degradation during unattended periods is defined
(無人期間中の許容可能なサービス低下が定義されている)
