運用手順書の作り方｜正常確認・中止条件・引き継ぎまで書く

運用手順書は、操作を順番に並べるだけでは完成しません。何を確認できたら次へ進み、どの状態なら止めるかまで書くと、担当者が判断に迷う場所を具体的に点検できます。

この記事では、社内システムの定型作業を引き継ぐ企業の運用担当者に向けて、手順書の項目と確認方法を整理します。実際の機器で使えるコマンド集ではなく、既存の作業を文書にするための設計例です。

最初に「この手順で終える作業」を一つ決める

AWSはrunbookを、特定の結果を得るための手順を文書化したものと説明しています。必要な道具や権限、問題が起きた場合の対処も含める考え方です。AWSのrunbookガイド

「サーバー運用全般」のような大きい単位で始めると、対象と完了条件を決めにくくなります。たとえば「定期ジョブの実行結果を確認し、異常時に担当へ連絡する」のように、開始から終了までを追える作業を選びます。

次の三つを冒頭に置いてください。

• 目的：作業後に何が確認できていればよいか
• 対象：環境、システム、対象一覧の参照先
• 対象外：この手順では変更・復旧してよい範囲に含めないもの

運用手順書で扱うのは、決めた作業の実施方法です。どの通知を出し誰が受けるかを先に整理したい場合は、監視アラートの設計と分けて考えましょう。

操作と期待結果を一対にする

以下は手順書を作るための記入例です。項目の名称や区切りは自社の作業に合わせて調整してください。

「正常であることを確認」とだけ書く代わりに、正常の根拠を一つ指定します。想定と違う表示が出たときは、同じ操作を再実行するのか、処理状況を調べるのかも区別します。具体的な待ち時間や再実行条件は、対象システムの仕様・運用条件を確認して決めます。

パスワードや秘密鍵そのものを手順書へ貼る必要はありません。承認された保管先と取得方法、利用できる担当範囲を参照できる形にします。

中止条件と復旧判断を分ける

中止条件は「この手順を続けない条件」、復旧判断は「今の状態をどう扱うか」です。止めたら必ず元へ戻せる、とは限りません。

Microsoftの安全な展開に関するガイドは、異常時の展開停止と復旧の判断を扱い、データベースや状態を持つ変更のロールバックは複雑になり得ると説明しています。安全な展開の考え方

手順書では、少なくとも次を別々に記入すると判断を渡しやすくなります。

1. 作業者がその場で停止する条件
2. 作業者に認められた確認操作
3. 復旧や再実行を判断する担当者
4. 判断のために残す対象名・時刻・結果・ログの参照先

たとえば、完了表示が出ないまま処理が切れた場合、再実行で同じデータを二重登録する可能性があるかを確認する必要があります。仕様が分からない段階で「失敗したらもう一度実行」と書かず、処理済みかを調べる担当と確認方法を先に決めましょう。

仮例：日次データ取り込みの結果確認

次は説明用の架空例であり、特定企業で実施した記録ではありません。

作業の目的を「日次取り込みの終了状態と対象日付を確認し、業務担当へ結果を渡す」とします。取り込み処理の修正や手動再実行は対象外です。

ここでは「正常という文字が見えた」ことと、「予定した業務の結果が揃った」ことを分けています。この表だけで本番作業は開始せず、実際の画面・権限・連絡先・判定値を埋めてください。

別の担当者が使えるか確認して版を固定する

AWSのガイドでは、作成者以外のチームメンバーに手順を実行してもらい、不足や曖昧さを直すことも示しています。まず影響を抑えられる検証環境や確認作業で試し、実施条件に合う方法を選びましょう。

確認では、作成者が口頭で補足した箇所を記録します。「その画面は別URL」「この値は担当者だけが知っている」といった補足が必要なら、手順書の参照先や前提条件を追加する余地があります。

公開する版には、管理担当、更新日、対象システムの版、関連手順を記載します。手順を変えた場合は、変更内容と再確認した範囲を残します。文書の更新日だけを新しくして、未確認の手順を検証済みにしないことが大切です。

まず一つの手順を引き継げる状態にする

最初から運用全体を作り直す必要はありません。頻繁に行う定型作業を一つ選び、操作・期待結果・中止条件を一行ずつ対応させてください。次に、別の担当者が迷った箇所を直します。

対象環境や運用の担当範囲から整理する必要がある場合は、インフラ支援の相談に向けて、現在の手順書と未確定の確認項目をまとめておくと、相談したい範囲を説明しやすくなります。