6.2バックアップ運用と自動化・運用手順

運用の品質は「人が手で操作する回数」を減らすほど安定します。サービスマネージャには、定型で頻度の高い作業を自動化して人的ミスと工数を減らし、判断や例外対応が必要な作業は手順書（Runbook）で標準化し、それでも人が触る危険な操作には二重確認などの誤操作防止策を設計する判断が求められます。加えて、本番構成を変更する作業は変更管理と連携し、失敗時に元へ戻せる切り戻し手順をセットで用意しておくことが不可欠です。

6.2.1運用自動化とRunbook

• 運用自動化＝バックアップ取得・ログ収集・ジョブ起動・ヘルスチェックといった定型で反復的な作業をスクリプトやツールに委ねること。人的ミスの排除・工数削減・実行時刻の正確化という効果がある一方、判断や例外対応が絡む作業まで無理に自動化すると、想定外の入力で誤動作しかえって危険になる。自動化に向くのは「入力と手順が定まっている定型作業」で、判断を要する例外は人が担うのが原則。
• Runbook（運用手順書）＝ある作業を誰が実施しても同じ結果になるよう手順・前提・確認事項・異常時対応を明文化した文書。属人化を防ぎ、担当交代や夜間の一次対応でも品質を保つ土台になる。良いRunbookは「正常手順」だけでなく異常時の切り戻し・エスカレーション先まで含む。手順が陳腐化すると事故の元になるため、構成変更のたびに更新（保守）することが前提。

6.2.2オペミス防止と構成変更の反映

• オペミス（誤操作）防止＝人が本番に触る危険な操作に対する予防策。作業前に対象を宣言して第三者が確認する二重確認（ダブルチェック）、コマンド投入前の指差呼称・チェックリスト、削除など不可逆操作の対象限定と確認プロンプト、可能なら本番と同等の検証環境での事前リハーサルが有効。「熟練者だから確認は省く」は最も危険な運用文化。
• 構成変更の反映＝本番システムの設定・機器・ソフトウェアを変更する作業は、思いつきで行わず変更管理プロセスと連携させる。CABの承認（通常変更）や標準変更の事前承認手順に乗せ、実施前に切り戻し手順（ロールバック）と失敗判定基準を用意し、実施後は構成管理（CMDB/CI）を更新して現物と台帳の乖離を防ぐ。切り戻せない変更は原則避け、段階適用やメンテナンスウィンドウの利用で影響を局所化する。

6.2.3自動化と手順・切り戻しの設計判断

あるサービスマネージャが、これまで運用担当者が毎晩手作業で行っていた「バックアップ取得→旧世代の削除→取得成功のログ確認」という定型作業を見直すとします。この作業は毎日決まった手順で、入力（対象ボリューム・保持世代数）も固定であり、判断の余地がほとんどありません。そこでまずバックアップ取得と成功判定のログ確認を運用自動化の対象とし、スケジューラで定刻起動、失敗時のみ運用者へアラート通知する設計に切り替えます——これで毎晩の手作業と、削除対象を取り違えるオペミスの温床を減らせます。ただし「旧世代の削除」は不可逆で、万一パラメータを誤ると必要な世代まで消えるため、削除は保持ポリシー（例：世代数と最終取得の成功）を満たしたときだけ自動実行し、判定に迷うケースは自動では消さず運用者の確認に回すように、判断の要る例外を人へ切り出します。次に、ごくまれに発生する「本番ストレージ機器の交換」のような判断と例外対応を伴う非定型作業は自動化に無理に載せず、Runbookとして手順・前提・確認事項・そして失敗時の切り戻しとエスカレーション先まで明文化します。この機器交換は本番構成を変える作業なので、変更管理プロセスと連携させCABの承認を得たうえで、実施前に切り戻し手順（旧機器へ戻す条件と手順）を用意し、危険な取り外し操作には二重確認（対象機器の宣言→第三者の確認）を課します。実施後は構成管理（CMDB）を新機器の情報に更新し、台帳と現物の乖離を防ぎます。このように「定型・反復は自動化、判断/例外はRunbook＋人、構成変更は変更管理と切り戻しをセット」で切り分けるのが運用設計の判断です。

6.2.4この節のまとめ

• 運用自動化は定型・反復・入力固定の作業に限り、判断/例外は人が担う（無理な自動化は想定外入力で誤動作）
• Runbookは正常手順＋異常時の切り戻し/エスカレーションまで明文化し構成変更ごとに保守、危険操作は二重確認で誤操作防止
• 構成変更の反映は変更管理と連携し、切り戻し手順とCMDB更新をセットで用意して失敗時の復旧と台帳整合を保つ