この記事は、 「ネットワーク上級編｜要件定義・設計・クラウド・自動化へ進む」 の第66回です。
第7章では、基本設計・詳細設計で決めた内容を、 実際のプロジェクトでレビュー・移行・提案へつなげる方法を学びます。 今回は、ネットワーク変更や移行が予定どおり進まなかったときに 安全に変更前の状態へ戻すための「切り戻し計画」を扱います。
NETWORK ADVANCED｜CHAPTER 7 DESIGN & CASE STUDY
切り戻し計画の作り方｜判断条件・復旧手順・確認項目を実務例で解説
ネットワーク変更では、正常に切り替わることだけを考えてはいけません。 障害が発生した場合に、いつ切り戻すのか、誰が判断するのか、 どの手順で元へ戻し、何を確認して復旧完了とするのかまで 作業前に決めておく必要があります。 この記事では、実務で使える切り戻し計画の作り方を順番に解説します。
「問題が起きたら元に戻します」という一文だけでは、 切り戻し計画とはいえません。
実際の作業では、 切り戻すかどうかを迷っている時間にもサービス停止時間は増えていきます。 そのため、作業前に判断条件と判断期限を決め、 戻す作業自体も通常の変更作業と同じレベルで具体化しておくことが重要です。
この記事を読み終えるとできること
- 切り戻し計画の役割を説明できる
- 切り戻し条件を具体的に設定できる
- Go／No-Goの判断ポイントを整理できる
- 判断者・判断期限を明確にできる
- 切り戻し手順と確認項目を作成できる
- 実務用の切り戻し計画書を作成できる
切り戻し計画とは何か
切り戻し計画とは、変更・移行作業で問題が発生した場合に、 変更前の正常な状態へ安全に戻すための条件・判断・手順・確認方法を 事前に定めた計画です。
英語では、一般に Rollback Planや Backout Plan と表現されます。
たとえば、既存ルーターから新しいルーターへ切り替える作業を考えます。 新ルーターへ接続したあと、業務システムへ通信できなくなったとします。
このとき、その場で 「原因調査を続けるのか」 「旧ルーターへ戻すのか」 を考え始めると、サービス停止時間が長くなる可能性があります。
切り戻し計画の目的は、「失敗したときの言い訳」を用意することではありません。
問題発生時の判断を早くし、 影響時間を限定して業務を復旧させることが目的です。
「元に戻す」だけでは不十分
切り戻し計画では、最低でも次の内容を具体化します。
- どの状態になったら切り戻すのか
- 誰が切り戻しを判断するのか
- 何時までに判断するのか
- どの手順で戻すのか
- 戻したあと何を確認するのか
- どこまで確認できれば復旧完了とするのか
なぜ切り戻し計画が必要なのか
停止時間を制御できる
原因調査を無制限に続けず、 決められた時刻で切り戻すことで、 業務影響が長期化することを防ぎます。
現場の判断迷いを減らせる
作業当日に「戻すべきか」を議論するのではなく、 あらかじめ合意した条件を基準に判断できます。
復旧手順の事故を防げる
緊急時にも手順書どおりに作業できるため、 焦って別の設定を壊すリスクを抑えられます。
関係者と事前合意できる
顧客、作業責任者、運用担当者などと、 「どこまで失敗を許容するか」を共有できます。
作業終了時刻を守りやすい
切り戻しに必要な時間から逆算して、 新環境で調査できる時間を決められます。
変更リスクを説明できる
「問題時は旧構成へ戻せる」という具体的な復旧策を示すことで、 変更作業のリスクを関係者へ説明しやすくなります。
移行計画と切り戻し計画の関係
切り戻し計画は、 ネットワーク移行計画 と別々に考えるものではありません。
移行作業の各チェックポイントに、 継続する条件と切り戻す条件を組み込みます。
移行作業と切り戻し判断の流れ
構成確認
正常性確認
設定変更
経路変更
経路確認
業務通信確認
切り戻すか
または旧環境へ復旧
切り戻しは「移行に失敗したあとに考える工程」ではありません。
移行計画を作る段階で、 「この工程で失敗したら、どこまで戻すか」をセットで考えます。
切り戻し計画で決める5つの重要項目
切り戻し条件
どのような状態になった場合に、 新環境を諦めて旧環境へ戻すかを決めます。
判断者
切り戻し開始を最終決定できる人物を明確にします。 現場担当者だけで判断できない案件では特に重要です。
判断期限
何時まで新環境で原因調査を行い、 何時になったら切り戻しを開始するか決めます。
切り戻し手順
配線・設定・経路・サービスなどを、 どの順番で変更前へ戻すかを具体化します。
正常性確認
旧環境へ戻したあと、 何を確認すれば復旧完了と判断できるかを定義します。
切り戻し条件の決め方
切り戻し条件は、 誰が読んでも同じ判断になる表現にします。
悪い切り戻し条件
「重大な問題が発生した場合は切り戻す」
「重大」の意味が明確ではないため、 作業当日に判断が分かれる可能性があります。
良い切り戻し条件
- 主要業務システムへの通信が10分以内に復旧しない場合
- 新ルーターでBGPセッションが確立しない場合
- 主要拠点3拠点のうち1拠点以上で通信不能が継続する場合
- 疎通試験の必須項目にNGが発生し、予定時間内に解消できない場合
- 切り戻し判断期限の2時00分に未解決障害が残っている場合
切り戻し条件の例
| 分類 | 確認内容 | 切り戻し条件例 |
|---|---|---|
| 物理 | リンク・光レベル・ポート状態 | 予定時間内に必要ポートがLink Upしない |
| Layer 2 | VLAN・STP・LAG | 主要VLANの通信が成立しない |
| Layer 3 | ルーティング・隣接状態 | 必須ルートがルーティングテーブルへ登録されない |
| セキュリティ | FW・ACL・VPN | 必要業務通信がポリシーにより継続して遮断される |
| サービス | DNS・DHCP・NTP等 | 業務に必要な基盤サービスが正常利用できない |
| 業務 | 実際のアプリケーション通信 | 必須業務システムへ接続できない |
| 時間 | 作業ウィンドウ | 切り戻し開始期限までに正常化できない |
技術的には一部通信できていても、 利用者が必要とする主要業務が利用できなければ 移行成功とはいえません。
Pingだけでなく、業務レベルの確認項目を 切り戻し判断へ含めることが重要です。
切り戻し判断期限を決める
切り戻し計画で特に重要なのが、 「何時になったら諦めるか」を決めることです。
たとえば、メンテナンス時間が 0時00分から5時00分までだとします。
切り戻しに2時間必要なら、 4時30分まで新環境を調査する計画にはできません。
判断期限は「終了時刻－切り戻し時間－余裕時間」で考える
作業時間いっぱいまで新環境を直そうとすると、 切り戻す時間がなくなる可能性があります。
「切り戻し時間を最後に残しておく」 という逆算が重要です。
判断期限を決めるときに確認すること
- メンテナンス可能時間
- 切り戻し作業に必要な時間
- 切り戻し後の試験時間
- 利用者への連絡時間
- 予備時間
- 翌営業日の業務開始時刻
切り戻し手順の作り方
切り戻し手順は、 「移行手順を逆から実行すればよい」とは限りません。
変更内容によっては、 旧設定の再投入、配線復旧、経路収束、サービス再起動など、 切り戻し専用の操作が必要です。
- 変更前の状態を記録する 構成図、配線、ポート、コンフィグ、ルーティングテーブル、 VLAN、FWポリシーなど、変更前の正常状態を保存します。
- 設定バックアップを取得する 機器設定、クラウド設定、コントローラー設定など、 復旧に必要な情報を作業前に取得します。
- 切り戻す対象を明確にする ルーターだけ戻すのか、FW、回線、DNS、ルーティングなども 同時に戻す必要があるのかを整理します。
- 作業順序を決める 物理配線、設定、ルーティング、サービスなど、 依存関係を考えて順番を決めます。
- 各手順の実行者を決める 誰が機器操作し、誰が疎通確認し、 誰が顧客へ報告するのかを整理します。
- 1工程ごとの確認を入れる 大量の手順を一気に実施するのではなく、 重要なポイントで状態確認を行います。
- 旧環境の正常性確認を行う 変更前と同じ経路・サービスが利用できることを確認します。
- 復旧完了を宣言する 技術確認だけでなく、必要に応じて利用者側の業務確認を行い、 責任者が復旧完了を判断します。
バックアップがある＝切り戻せる、ではありません。
バックアップから本当に復元できるか、 どの手順で適用するか、どの程度時間がかかるかまで 確認しておく必要があります。
切り戻し後の確認項目
旧構成へ戻しただけで、 切り戻し作業は完了ではありません。
変更前と同等の正常状態へ戻ったことを確認します。
機器・物理
- 電源状態
- インターフェース状態
- エラーカウンター
- リンク速度・Duplex
- LAG状態
Layer 2
- VLAN状態
- STP状態
- MACアドレス学習
- トランク状態
Layer 3
- IPアドレス
- ルーティングテーブル
- OSPF/BGP等の隣接状態
- デフォルトルート
- Ping・Traceroute
サービス・業務
- DNS名前解決
- DHCP払い出し
- VPN通信
- インターネット接続
- 主要業務システム
作業前の正常性確認結果を「基準値」として残しておくと、 切り戻し後に比較できます。
ルーティングテーブル、隣接状態、疎通結果などを Before／Afterで比較できるようにしておくと判断しやすくなります。
実務例：ルーター更改の切り戻し計画
次のネットワーク更改を例に考えてみましょう。
既存ルーターを新ルーターへ更改する
作業概要
- 既存ルーターを停止
- 回線とLANケーブルを新ルーターへ接続
- 新ルーターを起動
- ルーティング隣接を確認
- 拠点間・クラウド・インターネット疎通試験
切り戻し条件
| No. | 条件 | 判定 |
|---|---|---|
| 1 | WAN側リンクが確立しない | 切り戻し候補 |
| 2 | 必要なルーティング隣接が確立しない | 切り戻し候補 |
| 3 | 主要拠点への疎通NGが10分以上継続 | 切り戻し |
| 4 | 主要業務システムが利用できない | 切り戻し |
| 5 | 02:30時点で未解決障害が存在する | 原則切り戻し |
切り戻し手順例
作業責任者が切り戻しを宣言し、 顧客・監視担当・関連チームへ共有します。
必要に応じて最新状態を取得したあと、 新ルーターを安全に停止します。
作業前の配線図・ポート一覧に従い、 WAN・LANケーブルを旧機器へ戻します。
インターフェース、ルーティング、 必要なプロトコルの状態を確認します。
拠点、クラウド、インターネットなど、 作業前に正常だった通信を確認します。
利用者またはシステム担当者に、 主要業務が正常利用できることを確認してもらいます。
作業責任者が復旧状態を確認し、 切り戻し完了を関係者へ通知します。
切り戻し計画書テンプレート
実務では、次の項目を1枚に整理しておくと 作業当日の判断に使いやすくなります。
切り戻し計画書
大規模案件では、切り戻し計画を1枚だけにまとめるのではなく、 切り戻し手順書・試験項目書・連絡体制表・タイムチャート と分けて管理することもあります。
切り戻し計画をレビューするときのチェックポイント
判断に関する確認
- 条件が曖昧ではないか
- 判断者が決まっているか
- 判断者と連絡が取れるか
- 判断期限が決まっているか
- 技術条件と業務条件の両方があるか
復旧に関する確認
- 旧機器をすぐ利用できる状態か
- バックアップを取得しているか
- 配線を元へ戻せるか
- 必要なライセンスや設定が残っているか
- 復旧手順が検証されているか
時間に関する確認
- 切り戻し所要時間を見積もっているか
- 確認試験の時間を含んでいるか
- 予備時間があるか
- 業務開始時刻に間に合うか
連絡に関する確認
- 顧客責任者が明確か
- 運用監視チームへ連絡するか
- アプリ担当者との連携が必要か
- 障害時の連絡先が最新か
「完全には元へ戻せない変更」に注意する
すべての変更が、 単純なコンフィグ復元だけで元に戻るとは限りません。
たとえば、次のような作業は事前確認が必要です。
- OS・ファームウェアのアップグレード
- 機器交換後のライセンス移行
- 証明書・秘密鍵の変更
- クラウド上のネットワーク設定変更
- コントローラー配下機器の一括変更
- DNSレコードの変更
- 外部サービス側と連動する変更
- ネットワーク以外のシステム変更を伴う移行
「切り戻せる」という前提自体を確認することが重要です。
ネットワークを旧状態へ戻しても、 アプリケーションやデータ側の変更まで自動的に元へ戻るとは限りません。 他システムを含む変更では、各担当チームとの切り戻し順序を合わせます。
切り戻し計画でよくある失敗
失敗1：条件が「問題発生時」だけ
何を問題とするか判断できません。 通信・時間・業務影響などを具体化します。
失敗2：判断者が決まっていない
技術担当、PM、顧客の誰が最終判断するのか分からず、 判断が遅れます。
失敗3：判断期限がない
原因調査を続けすぎて、 旧環境へ戻す時間がなくなる可能性があります。
失敗4：コンフィグしか考えていない
実際には配線、経路、回線、FW、DNSなど、 複数の要素を戻す必要がある場合があります。
失敗5：旧機器を撤去してしまう
切り戻し可能時間が終了するまでは、 旧環境を復旧可能な状態で保持することを検討します。
失敗6：戻したあとの試験がない
配線や設定を戻しただけでは、 本当に業務通信が復旧したか分かりません。
最も危険なのは、 「切り戻し手順は簡単だから当日考えればよい」 という状態です。
障害発生中は通常時より判断が難しくなります。 だからこそ、正常な状態で事前に手順を作っておきます。
顧客・上司への説明方法
切り戻し計画を説明するときは、 技術手順だけでなく 業務影響を限定するための計画 として説明します。
説明例
今回の切り替え後、主要業務通信が正常化しない場合に備えて、 旧環境への切り戻し手順を準備しています。
切り戻しには約90分を見込んでいるため、 メンテナンス終了時刻から逆算し、 2時30分を最終判断時刻としています。
2時30分時点で主要業務に影響する問題が残っている場合は、 原因調査を継続せず旧環境へ戻し、 作業前と同じ通信が復旧したことを確認します。
説明するときのポイント
- 何を失敗と判定するか
- 業務影響をどこまで許容するか
- いつまで新環境で調査するか
- 何分で旧環境へ戻せるか
- 誰が最終判断するか
「問題が起きても戻せます」ではなく、 「何が起きたら、何時に、誰が判断し、何分で戻す」 まで説明できる状態を目指します。
切り戻し計画で使う英語表現
海外ベンダーの手順書や変更計画では、 次のような表現を見かけます。
| 英語 | 意味 | 使用例 |
|---|---|---|
| Rollback plan | 切り戻し計画 | Prepare a rollback plan before the change. |
| Backout plan | 変更を元へ戻す計画 | The backout plan must be reviewed before implementation. |
| Rollback criteria | 切り戻し条件 | Define clear rollback criteria. |
| Go / No-Go decision | 継続／中止判断 | A Go/No-Go decision will be made at 2:30 AM. |
| Restore the previous configuration | 以前の設定へ復元する | Restore the previous configuration if the test fails. |
| Validation | 正常性確認・検証 | Perform validation after the rollback. |
| Fallback | 代替策・退避策 | We have a fallback option if the migration fails. |
製品や組織によって rollback、 backout、 fallback などの用語が使われます。 プロジェクト内では用語を統一しておくと認識違いを減らせます。
理解度チェック
切り戻し計画のポイントを確認しましょう。
問題1．切り戻し計画として最も適切な説明はどれですか。
- 作業が成功した場合の確認手順だけをまとめたもの
- 問題発生後に現場担当者がその場で考える復旧方法
- 問題発生時に変更前へ戻す条件・判断・手順・確認方法を事前に決めたもの
- 障害原因を特定するための調査手順だけをまとめたもの
解答を見る
切り戻し計画では、 戻す手順だけでなく、条件・判断者・判断期限・正常性確認まで 事前に整理します。
問題2．次のうち、より適切な切り戻し条件はどれですか。
- 問題が発生した場合
- 通信がおかしい場合
- 重大な障害が発生した場合
- 主要業務システムへの通信NGが10分以上継続した場合
解答を見る
時間と対象が具体的なため、 関係者間で同じ判断をしやすくなります。
問題3．作業終了が5時00分、切り戻しに90分、 切り戻し後の確認に30分必要です。 最低限、何時までに切り戻し判断を行う必要がありますか。
解答を見る
90分＋30分で合計2時間必要なため、 5時00分から逆算すると3時00分になります。 実際の計画では、さらに予備時間を確保して もっと早い判断期限を設定するのが安全です。
問題4．コンフィグのバックアップがあれば、 切り戻し計画は十分でしょうか。
解答を見る
設定の復元方法、物理配線、経路、サービス、 所要時間、正常性確認なども必要です。 バックアップが存在していても、 復元できることが確認されていなければ十分とはいえません。
問題5．切り戻し後にPingが成功しました。 これだけで復旧完了としてよいでしょうか。
解答を見る
対象ネットワークに応じて、 ルーティング、DNS、VPN、FW、 実際の業務アプリケーションなども確認します。
実践演習：切り戻し計画を作ってみよう
次の条件から、切り戻し計画を作成してください。
案件条件
- 本社ファイアウォールを新機器へ更改する
- メンテナンス時間は0:00〜5:00
- 新機器への切り替え予定は1:00
- 旧機器へ戻す作業には約60分必要
- 切り戻し後の試験には約30分必要
- 業務開始は7:00
- インターネット接続が必須
- 拠点間VPNが必須
- クラウド業務システムへのHTTPS通信が必須
課題1．切り戻し条件を3つ作る
解答例を見る
- インターネット通信が10分以上復旧しない場合
- 必須拠点とのVPNが確立しない場合
- クラウド業務システムへのHTTPS通信が正常化しない場合
課題2．切り戻し判断期限を考える
理由：＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
解答例を見る
たとえば、3時00分より前に 判断期限を設定します。
切り戻し60分＋試験30分で最低90分必要です。 5時00分終了から逆算すると3時30分が理論上の限界ですが、 連絡や想定外の遅延を考えると、 3時00分など早めの判断期限を設定する方が余裕を確保できます。
課題3．切り戻し手順を書いてみる
2．＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
3．＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
4．＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
5．＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
解答例を見る
- 切り戻し開始を関係者へ連絡する
- 新ファイアウォールを通信経路から外す
- 配線を旧ファイアウォールへ戻す
- 旧ファイアウォールの状態・セッション・ルーティング等を確認する
- インターネット、VPN、クラウド業務通信を確認する
- 顧客側の業務確認を行う
- 復旧完了を報告する
課題4．正常性確認項目を考える
業務確認：
解答例を見る
技術確認
- インターフェース状態
- ルーティングテーブル
- VPN状態
- Ping
- DNS名前解決
- FWログ
業務確認
- インターネット閲覧
- 各拠点から本社への業務通信
- クラウド業務システムへのログイン
自分の言葉で説明する課題
顧客から 「なぜ切り戻し判断の時刻を事前に決める必要があるのですか？」 と質問されました。 30秒程度で説明してください。
説明例を見る
問題発生後に原因調査を長く続けすぎると、 旧環境へ戻す時間までなくなってしまうためです。 切り戻しに必要な時間と確認時間をあらかじめ計算し、 そこから逆算して判断期限を決めることで、 万一新環境が正常化しなくても業務開始までに 旧環境へ復旧できるようにします。
まとめ
- 切り戻し計画は、変更失敗時に変更前の正常状態へ戻すための計画
- 「戻す手順」だけでなく、 切り戻し条件・判断者・判断期限・確認方法まで決める
- 切り戻し条件は「問題発生時」ではなく、 誰が読んでも同じ判断になる具体的な条件にする
- 判断期限は、作業終了時刻から 切り戻し時間・確認時間・予備時間を逆算して決める
- コンフィグのバックアップだけでなく、 配線・ルーティング・サービス・外部システムまで考える
- 旧環境へ戻したあと、 ネットワークだけでなく主要業務が正常か確認する
- 移行計画と切り戻し計画はセットで作成する
良い切り戻し計画とは、 「失敗したら戻す」計画ではなく、 「どの状態なら、誰が、いつ、どの手順で戻し、 何を確認すれば復旧完了なのか」を迷わず実行できる計画です。
上級編では、要件定義から基本設計、BGP、クラウド、 セキュリティ、自動化、設計レビュー・移行・顧客提案までを 順番に学びます。
コメント