1-3 Temporary recovery actions do not assume on-site presence（暫定復旧手順が現地作業を前提としない）

Summary:
This article explains temporary recovery strategies and procedures for system failures in remote or hard-to-access locations without assuming on-site presence.
遠隔地やアクセス困難な場所でのシステム障害時に、現地作業を前提とせずに行える暫定復旧の考え方と手順を紹介します。

In this section, the English original text is presented first, followed by the Japanese translation for the entire section.
本章ではまず英語原文を記載し、その後に章ごとに日本語訳をまとめています。
—

Temporary recovery actions do not assume on-site presence

In remote or hard-to-access areas, **temporary recovery actions must be designed to work without assuming on-site presence**. When a failure occurs, the first priority is not a full repair, but service stabilization — buying time until permanent remediation becomes possible.

Typical temporary recovery actions include:
================================
* Restarting services or virtual machines remotely
* Switching traffic to a standby system or backup site
* Applying configuration rollbacks via automation tools
* Isolating faulty components to prevent cascading failures
================================
These actions rely heavily on **remote access, automation, and predefined runbooks**. If recovery procedures require an engineer to physically visit the site, the mean time to recovery (MTTR) becomes unpredictable, especially in regions affected by harsh weather, political restrictions, or limited transportation.

Therefore, system design should assume that:
================================
* Physical access may take days or weeks
* Local staff may not have advanced technical skills
* Emergency power or network conditions may be unstable
================================
By separating *temporary recovery* from *permanent repair*, operators can maintain acceptable service levels even under severe constraints.
—

暫定復旧手順が現地作業を前提としない

遠隔地やアクセス困難な場所では、一次復旧（暫定復旧）は現地作業を前提にしない設計が不可欠です。障害発生時の最優先事項は完全復旧ではなく、サービスの維持・安定化であり、恒久対応までの時間を確保することが目的です。

代表的な暫定復旧対応には、以下のようなものがあります。
================================
* リモートからのサービス／仮想マシン再起動
* 待機系やバックアップサイトへの切り替え
* 自動化ツールによる設定ロールバック
* 障害コンポーネントの切り離しによる被害拡大防止
================================
これらはすべて、**リモートアクセス・自動化・事前定義された手順（ランブック）**に依存しています。もし復旧手順が現地訪問を前提としている場合、天候、治安、交通事情などにより復旧時間（MTTR）は簡単に予測不能になります。

そのため、システム設計では以下を前提とすべきです。
================================
* 物理アクセスまで数日〜数週間かかる可能性がある
* 現地要員が高度なITスキルを持たない場合がある
* 非常用電源や通信が不安定な状況が起こり得る
================================
**暫定復旧と恒久対応を明確に分離すること**で、厳しい制約下でもサービスレベルを維持できます。

—
Example: Temporary recovery for NIC optical level degradation or link down / 具体例：NIC の光レベル低下・リンクダウン時の暫定復旧

For example, when optical level degradation or link down occurs on a server NIC, the root cause may include:
================================
* Dirty optical connectors (contaminants on the fiber end face that attenuate or block signal transmission)
* Cable deterioration or partial disconnection
* Issues at the patch panel
================================
Permanent recovery may require **physical cable replacement or cleaning**, which necessitates on-site work. However, prior to physical intervention, **temporary recovery measures** can be attempted remotely:
================================
* Performing Down/Up on the server NIC port
* Executing Shut/No Shut on the network device port
* Switching to an alternative NIC or port
================================
Such measures allow the service to continue temporarily, even if the physical issue is not fully resolved. Assumptions for this design include:
================================
* NIC is accessible via **multiple redundant paths**
* Both server-side and network-side remote operations are possible
* Runbooks include port operation procedures
================================
—
例えば、サーバーの NIC に接続された光ファイバーで **光レベル低下やリンクダウン** が発生した場合、根本原因としては以下のようなケースが考えられます。
================================
* 光コネクタの汚れ（光ファイバーの端面に付着した汚れが信号の伝送を減衰または遮断する）
* ケーブルの劣化や半抜け
* パッチパネル側の物理的問題
================================
恒久対応としては、**物理ケーブルの抜き差しやコネクタ清掃（クリーニング）** が必要となり、現地作業が不可欠です。しかし、その前段として以下の **暫定復旧対応** を行うことができます。
================================
* サーバー側 NIC ポートの Down / Up（無効化・有効化）
* ネットワーク機器側ポートの Shut / No Shut
* 代替 NIC や別ポートへの切り替え
================================
このような対応により、物理的な問題が完全に解消されなくても、サービスを一時的に継続できる場合があります。設計段階での前提条件は以下の通りです。
================================
* NIC へ **複数経路（冗長パス）でアクセス可能** な構成
* サーバー側・ネットワーク側双方からリモート操作が可能であること
* ポート操作を手順化したランブックが整備されていること
================================
—

Additional note: Cases where physical NIC replacement is required / 補足：物理 NIC 交換が必要となるケース

Even if temporary recovery actions are attempted, the link may remain unstable. In such situations, **a physical failure of the NIC itself** must be considered. On-site replacement work eventually becomes unavoidable.

Typical replacement targets include:
================================
* Server side: NIC boards (e.g., PCIe NICs)
* Network side: Optical transceivers such as SFP or QSFP (terminology may vary by vendor)
* Optical patch cables
================================
These issues cannot be resolved through software or configuration changes alone, and therefore require **planned on-site work as part of permanent recovery**.

For systems deployed in remote areas, it is important to consider the following in advance:
================================
* Availability of **spare parts**, such as replacement NICs and optical transceivers
* **Simplified and well-documented procedures** that local staff can execute
* **Predefined diagnostic steps** to determine whether the faulty component is on the server side or the network side
================================
By clearly separating **temporary recovery (remote actions)** from **permanent recovery involving physical replacement**, operators can achieve realistic and sustainable system operations even in remote locations.
—
暫定復旧を実施してもリンクが安定しない場合、**物理 NIC 自体の故障**が原因である可能性も考慮する必要があります。この場合、最終的には現地での部品交換が不可避となります。

想定される交換対象の例は以下のとおりです。
================================
* サーバー側：NIC ボード（PCIe NIC など）
* ネットワーク側：SFP / QSFP などの光トランシーバ（※ベンダーによって呼称は異なる）
* 光パッチケーブル
================================
これらはソフトウェアや設定変更では解決できないため、**恒久対応として計画的な現地作業**が必要になります。

そのため、遠隔地システムでは以下の点を事前に考慮しておくことが重要です。
================================
* 交換用 NIC や光トランシーバなどの **予備部品（spares）を確保** していること
* 現地要員でも交換可能なレベルまで **作業手順を単純化・文書化** しておくこと
* サーバー側・ネットワーク側のどちらが交換対象かを切り分けるための **事前診断手順** が整備されていること
================================
このように、**暫定復旧（リモート対応）と、物理交換を伴う恒久対応を明確に分けて設計・運用する**ことで、遠隔地においても現実的なシステム運用が可能になります。

Relation to the table of contents
（目次との対応）

This article corresponds to the below item:
本記事の内容は、次項目に対応します。
Link:IT infrastructure system operation for remote areas（遠隔地向け IT インフラ運用）
1-3 Temporary recovery actions do not assume on-site presence
（暫定復旧手順が現地作業を前提としない）