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
(無人期間中の許容可能なサービス低下が定義されている)