#初めに

　運用が始まったシステムに変更作業を行うのは怖いですよね。
ちょっと間違うと障害に直結、徹夜で復旧作業、復旧後はお詫びにお客様訪問。。。

かと言って「できるだけ何もしない」とうのも後ろ向き過ぎます。

　これまで変更作業で多くの失敗をしてきましたので、、、これらを教訓に心得・心構え的なことを共有できればと思います。

読んで下さった方が少しでも安心して作業ができるようになれば嬉しいです。

##目次
全般的な心得・心構え
1. 何があっても元に戻せるようにしておく。
2. 副作用がないかチェックする。
3. 何かあった場合のサービスへの影響範囲を洗い出す。

手順書・チェックリストに関する心得・心構え
4.「5W1H」を意識的に盛り込む。
5.「～かもしれない」という前提で事故を防ぐ。
6. 事前の状態・事後の状態を比較する。
7. 定型作業を個別に手順書化する。
8. 切り戻し手順書を作成する。
9. 手順書をレビューする。

リハーサル
10. リハーサルを実施する。

作業中の心得・心構え
11. 記録を付ける。
12. 作業全体の管理者を立てる。

忘れがち、でも大事なことへの心得・心構え
13. アナウンスを行う。
14. 体制・連絡先を明確にしておく。
15. 記録を保管する。

##全般的な心得・心構え
###1. 何があっても元に戻せるようにしておく。

　個人的にはこれが一番大事なことだと思っています。

　万一障害を起こしてしまっても最終的に元に戻せれば何とかなりますが、

　　・吹っ飛ばしたDBを元に戻せない。
　　・起動しなくなったソースコード管理サーバ内のソースコードを戻せない。
　　・起動しなくなったネットワーク機器のconfigを代替機に戻せない。

なんてことになると目も当てられないですよね。

　元に戻す手段として、

　　・作業直前にバックアップを取得する。
　　・作業直前にスナップショットを取っておく。
　　・冗長構成になっている場合は待機系をバックアップとして利用する。

などの方法があるかと思います。

　また、一回でもいいので事前に元に戻す手順を実際に試してみて手順書に纏めておくようにしましょう。

一回でも実際に経験しているとポイントを覚えているものです。
逆に一度も経験がない場合、いざというときに慌てることになります。

目次に戻る

###2. 副作用がないかチェックする。

　新規機能の追加といった変更作業の場合、どうしても追加・変更される部分にフォーカスが当たりますが、思ってもみなかった部分に問題（副作用）が発生することがあります。

　追加・変更部分から俯瞰して大きな視点で依存関係を探しましょう。
作業対象と依存関係にあるシステム、ネットワーク、機器を列挙して今回の変更作業で影響を受けないかを１つずつ確認します。影響がある場合はその対策も検討します。

　この時、データーの流れ、通信経路、時間の流れ（バッチ処理などの順序）などに着目すると依存関係を把握し易いと思います。

目次に戻る

###3. 何かあった場合のサービスへの影響範囲を洗い出す。

　何も起こらず作業完了して欲しいものですが、想定外の事象は起こるものです。
何も起こらないことを祈るよりも、障害が発生した場合のサービスへの影響範囲を洗い出して万一に備えましょう。

以下のメリットがあります。

　・変更作業のリスクの大きさを事前に把握できる。
　・事前アナウンスの際に万一問題が発生した場合の影響範囲を通達できる。
　・万一障害が発生した場合のアナウンス内容、アナウンス先を事前に把握できる。

目次に戻る

##手順書・チェックリストに関する心得・心構え
###4.「5W1H」を意識的に盛り込む。

　「5W1H」を意識して手順書・チェックリストを作りましょう。

手順書やチェックリストは何に対して（What）、どのように作業するか（How）のみになりがちですが、Why、When、Who、Whereも大事な要素です。

######Why：作業目的、手順の意味
　作業の目的や意味がはっきりしていれば、想定外の事象が発生した時にどのようにリカバリーすべきかの判断をし易くなります。

　　・大きくは作業全体の目的（なぜ今回の変更作業が必要か？）
　　・細かくは個々の変更作業の目的（なぜその手順なのか？など）

　を記載しましょう。

　特に手順書作成者と作業実施者が異なるような場合、Whyを共有しておくことは重要です。

######When：時刻、作業タイミング、チェックポイント
　通常、変更作業を実施できる時間は決まっています。時系列で実施する作業を記載しましょう。

　作業Bを実施するためには作業Aが完了していなければならないといった依存関係が存在するケースの作業タイミングを確認し易くなります。

　また、作業時間中にバッチなど自動実行処理が発生する場合、何らかの考慮が必要にならないか確認する必要があります。

　更に、想定通りに作業が進まなかった場合、切り戻しを行うかどうかの判断ポイント（チェックポイント）、切り戻しを行う場合のタイムリミットも検討し記載しましょう。

######Who：作業者、体制
　複数人で作業する場合、各作業者の作業対象や作業内容が不明確なり「その作業はAさんが担当だと思っていた。」など当日混乱することがあります。
　各作業ごとに担当者名を明記しましょう。

　一人で作業する場合でも万一何か問題が発生したときの連絡先などWhoを意識しましょう。

######Where：作業場所
　インフラ系の変更作業など物理作業を伴う場合や昨今のリモートワークなど自宅からの作業になる場合など、作業場所の考慮が必要になるケースがあります。

　例えば、

　・複数人が異なる場所で作業を行う場合、お互いの連絡手段の考慮が必要になる。
　・異なる場所を行き来する場合、その移動時間の考慮が必要なる。

といったことが考えられます。

　作業場所も手順書に記載することで考慮すべき点が明確になります。

######What：作業対象（対象システム、対象ホスト、対象ディレクトリ）
　作業対象については、大きくはシステム単位、小さくは作業ディレクトリといったように範囲に大きな差がありますが、「間違って無関係のものに対して変更作業を行わないようにする」という観点で記載しましょう。

　・本番系と検証系を間違えた。
　・対象ホストを間違えた。
　・作業ディレクトリを間違えた。

など、作業方法（How）は正しくても対象（What）を間違えると障害につながります。

######How：作業方法
　作業方法については、具体的な作業手順を記載することになります。
まずは大枠の流れを書き出してから、抜け漏れなく、重複なく、詳細な手順に落としましょう。

目次に戻る

###5.「～かもしれない」という前提で事故を防ぐ。
　車の運転に対してよく言われることですが、変更作業についても「～だろう」ではなく「～かもしれない」という意識で手順書を作成し事故を防ぎましょう。

　例えば、

　　cd /var/log/example
　　mv * /backup/example

という作業を行うときに、

　・カレントディレクトリが/var/log/exampleではないかもしれない。
　・/backup/sampleディレクトリが存在しないかもしれない。
　・間違えて mv * と打ってしまうかもしれない。

と考えれば、

　　cd /var/log/example
　　pwd　←　カレントディレクトリ確認
　　ls -l　←　移動対象ファイル確認
　　ls -l /backup/example　←　移動先ディレクトリ存在確認
　　mv -i * /backup/example　←　「-i」オプションで確認しながら移動

というように都度確認する手順になります。

　誰しも自分はそんな馬鹿なミスはしないと思うものですが、システム変更作業については自分を信じないで「○○してしまうかもしれない」と考えましょう。
　「注意１秒、ケガ一生」です。

目次に戻る

###6. 事前の状態・事後の状態を比較する。
　手順書には作業完了後の動作検証手順も記載することになります。

この時、
　「変更箇所が正常に稼働しているか？」
の検証手順は考え易いのですが、
　「副作用（変更箇所以外の部分に悪影響）が起きていないか？」
の確認手順を考えるのは難しいものです。

　副作用の有無を確認するには、作業後の確認だけではなく、作業直前の状態を変更箇所に限らず周辺の幅広い範囲について把握しておくことが非常に重要になります。

　作業直前の状態と、作業後の状態を比較することで副作用が発生していなかどうかを客観的に把握できるようになります。

　例えば、

　　・作業前に監視システムの画面キャプチャを取得し、作業後の画面と比較する。
　　・作業前にネットワーク機器のconfigを取得し、作業後のconfigと比較する。
　　・作業前にサーバーのLEDの状態をカメラで撮影し、作業後のLEDと比較する。

といった方法が考えられます。

目次に戻る

###7. 定型作業を個別に手順書化する。
　変更作業の際に必ず実施する定型作業があれば切り出して個別に手順書化し、使いまわせるようにしましょう。
　例えば、以下のような事前・事後作業などが定型作業に相当します。

　　・ロードバランサーからのサーバー切り離し・再接続
　　・ファイアウォールでの通信制限・制限解除

定型作業の手順書は（個別の変更作業手順書から独立させて）単独で管理すると、

　・メインの変更作業手順書と組み合わせることで使い回せる。
　・定型作業の手順を変更した際に手順書のメンテナンスがし易い。
　　また、その変更が以降の作業手順に確実に反映される。

といったメリットがあります。

目次に戻る

###8. 切り戻し手順書を作成する。
　作業がうまくいかず、やむを得ず切り戻しを行う場合の切り戻し手順書も作成しましょう。

　切り戻しは何らかの問題が発生した後の作業になるので、気分的に落ち込んでいたり、時間に追われたりしている状況下での対応になります。二次災害を起こしやすい状況とも言えます。

　実際に使われることは少ないですが、切り戻し手順書も作成し、切り戻し作業に伴う余計な不具合は回避しましょう。

目次に戻る

###9. 手順書をレビューする。
　ここに書いている心得・心構えを意識して手順書のレビューをしましょう。他人の目が入ることで気づかなかった問題点が見つかります。

目次に戻る

##リハーサル
###10. リハーサルを実施する。
　実際に手や体を動かさないと分からないことも多いですよね。できる限りリハーサルを実施しましょう。特に大規模な変更作業の場合はリハーサルは必須と思います。

リハーサルの中で

　・手順書の抜け漏れチェック
　・作業時間見積もり
　・他の作業者との連携チェック
　
などを行い、問題が見つかったら手順書に反映します。

　また、リハーサルを行わない場合でも手順書片手に流れを追うとよいと思います。

目次に戻る

##作業中の心得・心構え
###11. 記録を付ける。
　作業当日は記録を付けるようにしましょう。作業を実施したかどうかのチェック、手順書の各項目を実施した時刻などを残しておくのは大事です。

　例えば、

　　・バッチ処理を止め忘れて作業開始した場合、そこまでの作業記録から影響の有無を確認する。
　　・作業完了後に問題が見つかった場合、作業漏れによる問題かどうか確認する。

といった対応が可能になります。

　作業中に障害が発生した場合は手順書にない作業を行うことが多いと思います。
この場合もできる限り「5W1H」で記録を付けましょう。

とは言え、障害発生時は焦っていますし、時間も不足していますので、

　・「5W1H」が難しければ「いつ」「何をおこなったか」だけでも記録する。
　・複数人で作業しているのであれば記録係を立てて記録する。

といいです。

　また、障害発生時用の記録用紙を用意しておくと、問題発生時にすぐに記録を始められますし、記録の抜け漏れを減らせます。

目次に戻る

###12. 作業全体の管理者を立てる。
　作業の規模にもよりますが、作業全体を管理する人を作業者と別に立てましょう。

作業管理者は、

　　・作業進捗の管理
　　・依存関係がある作業の調整
　　・チェックポイントでの切り戻し要否判断
　　・障害発生時の対応内容判断

などを行うことになりますが、作業者が兼任する場合、これらも意識しながら作業を行うのはなかなか難しいですし、判断ミスをしやすくなります。

目次に戻る

##忘れがち、でも大事なことへの心得・心構え
###13. アナウンスを行う。
　変更作業によるサービス停止が発生する場合など、事前・事後のアナウンスが必要になると思います。

　　・社内向けアナウンス
　　・社外向け（お客様向け）アナウンス

を必要に応じて実施しましょう。

　また、「変更作業が無事に終わるとホッとして」、「障害が発生すると焦っていて」、事後のアナウンスを忘れてしまうことがあります。チェックリストには事後のアナウンスについても記載して抜けないようにしましょう。

目次に戻る

###14. 体制・連絡先を明確にしておく。
　作業当日の体制・連絡先も大事です。問題が発生した場合を考慮した体制、連絡フロー、連絡手段も作っておきましょう。

　・作業者
　・作業管理者
　・記録係
　・タイムキーパー
　・障害発生時に備えた自宅待機者

などの役割があると思いますが、通常時と障害時に分けて連絡フロー、連絡手段を記載しましょう。

　問題が発生した際に、自宅待機者の電話番号がわからないと無駄に障害を長引かせてしまいます。「何かあったら電話します。」と念押ししておくのも良い方法と思います。

目次に戻る

###15. 記録を保管する。
　変更作業の記録を保管しましょう。作業後の手順書には、手書きで項目ごとの完了時刻やメモが残っているかもしれませんが、そのままPDFなどにして保管しておくとよいです。

　作業直後の確認作業では見つからなかった問題が暫くたってから表面化することもあります。作業記録が保管してあれば、「作業に問題が無かったか？」、「作業に問題があった場合はどの部分に問題があったか？」の調査に使えます。

目次に戻る