本番の変更作業は、技術より「段取り」で事故が決まります。8年で身についた、安全に変更を通すための手順書と切り戻しの考え方をまとめます。
障害の多くは「変更」がきっかけ
新規構築より、既存への変更（設定変更・パッチ・リリース）の方が障害を生みます。動いているものを触るからです。だからこそ、変更作業には準備が要ります。
手順書に必ず書くこと
- 目的と対象: 何のために、どのサーバ/機器を触るか
- 事前確認: 作業前の正常状態（例: このサービスが応答している、この値が0）
- 作業手順: コマンド単位で、コピペで実行できるレベルに
- 確認手順: 各ステップ後に「何を見て成功と判断するか」
- 切り戻し手順: うまくいかない時に、元へ戻す具体的な手順
- 切り戻し判断基準: いつ戻すか（例: 10分待って回復しなければ戻す）
特に確認手順と切り戻しが抜けている手順書は危険です。
切り戻しは「戻せること」を先に確認
変更前に、戻すための材料（設定のバックアップ、スナップショット、旧バイナリ）を確保します。
! 変更前に必ず現行configを保存
show running-config > backup_20260815.txt
「戻せない変更」は、原則やらない。戻せる状態を作ってから前に進みます。
作業中のルール
- 1ステップ実行 → 確認 → 次へ（まとめて流さない）
- 想定外が出たら、いったん止めて判断（勢いで進めない）
- 作業ログ（時刻とコマンド）を残す
メンテナンス枠と告知
影響のある作業は、利用の少ない時間帯（メンテナンス枠）に、事前告知して行います。「いつ・何を・影響は・戻せるか」を関係者と合意しておくと、いざという時の判断が速くなります。
まとめ
安全な変更＝「確認手順」と「切り戻し」がある手順書＋戻せる状態の確保。派手なテクニックより、この段取りが本番を守ります。慣れた作業ほど手順書を省きがちですが、事故はそこで起きる、というのが実感です。