インフラ作業において手順書は必須ですが、作業手順書の重要性がいまひとつ認識されていないのではないかと日頃わたしは感じています。
そこで、作業ミスを防ぐための手順書作りについて解説します。
タップできる目次
確認基準が明確でない手順書は作業ミスを誘発する
次のような確認基準は作業ミスを誘発します。
- CPU使用率が高くない事
作業者がサーバーやネットワーク機器でCPU使用率を表示させるコマンドを実行した際に「CPU使用率が高くない事」と書かれている作業手順書を見たらどう思うでしょうか？
誰が実行しても同じ結果となるように作業手順を作成する必要があります。
「CPU使用率が高くない事」では作業者によって判断基準が異なります。ですから、例えば80%以上を高いと判断するのであれば次のようにします。
- CPU使用率が0%～79%である事
- CPU使用率が80%～100%ではない事
「以上」「以下」「超過」「未満」の意味を作業者が正しく理解しない可能性を慮する必要があります。
特に「以上」「以下」という言葉は使わないようにするか、使う場合は必ず補足する事をおすすめします。バカみたいな話だと思うかもしれませんが重要です。
作業手順書に出てくる危険なワード
「以上」「以下」に並んで危険だと感じるワードがあります。
「応答がある事」
「応答がある事」はとても危険なワードですから手順書にこのワードが出てきたら要注意です。
わたしの周りで発生した作業ミスの例を紹介します。
実例１：どこからの応答？
curlコマンドでWEBサーバーへアクセスし、応答がある事。
これはFWで穴あけした後の動作確認でしたが、作業者はcurlコマンドを実行して「200 OK」が表示されたので問題なしと判断しました。
確かにFWで穴をあけた後にcurlコマンドを実行して「200 OK」が表示されれば問題ないように見えます。しかし、この時「200 OK」を返したのは許可した接続先のWEBサーバーではなくてFWのブロック機能でした。
応答内容を見れば「Blocked」と書いてありFWのブロック機能が動作している事が一目瞭然なのですが、手順書には「応答がある事」としか書いていなかったのでFW設定の間違いに気付く事ができませんでした。
それ以来、curlを実行した応答内容に「Blocked」と表示されていない事を確認するように手順書が修正されました。
実例２：それって無応答では？
Nmapを実行し、応答がある事。
これもFWで穴あけした後の動作確認でしたが、作業者はNmapで特定のポートに対してTCPスキャンを実行し「filtered」と表示されたので応答ありと判断しました。
Nmapとネットワークについて知識があれば「filtered」という事は対向先から応答がない状態ですから次の原因を推測できます。
- FWでフィルタしている
- ルーティングが間違っている
- 対向先が存在しない（起動していない）
- 経路上の障害
この時は起動しているべき対向先のサーバーがダウンしていた事が原因でした。
それ以来、Nmapを使用する際は想定されるステータス（「OPEN」「CLOSE」）を明記するように手順書が修正されました。
手順を無駄に分岐させない、判断させない
「もしも〇〇だったら手順△番を実行、そうでなければ手順△番を飛ばす」
このような手順書は作業者にストレスを与える上に作業ミスを誘発します。
コマンドを実行しても影響ないものであれば、状況に関わらず実行する方がミスもストレスも減ります。
実例として次のような手順がありました。
- HAを組んでいる1号機のステータスがActiveである事
- HAを組んでいる2号機のステータスがStandbyである事
- もしも1号機がStandbyだったらActiveにフェイルバックする
- HAを組んでいる1号機のステータスがActiveである事
- HAを組んでいる2号機のステータスがStandbyである事
この手順をわたしは次のように変更しました。
- 2号機をStandbyに遷移させるコマンドを実行する（元々Standbyであれば何も起きない）
- HAを組んでいる1号機のステータスがActiveである事
- HAを組んでいる2号機のステータスがStandbyである事
どちらが楽ですか？
作業手順書において「もしも～だったら」は可能な限り避けるべきです。
どうしても「もしも～だったら」を使うのであれば「もしも～だったら『作業手順書〇〇』で作業を進める」といった感じで作業手順書そのものを分けます。
作業手順書を分ける必要がない程度の分岐であれば本当に分岐する必要があるのか検討する必要があります。
ターミナル画面はひとつだけ
Tera Termを複数起動して手順書の中で行き来させる場合がありますが、これはおすすめできません。
たとえばサーバーAとサーバーBにそれぞれログインしておき交互にコマンドを実行させる手順を目にする事がありますが、画面を行ったり来たりしなくてはならず作業者にストレスを与える上に作業ミスを誘発します。
サーバーAとサーバーBで交互にコマンドを実行しなければならないのであれば、次のようにすれば良いでしょう。
- ssh サーバーA ‘コマンド’
- ssh サーバーB ‘コマンド’
- ssh サーバーA ‘コマンド’
- ssh サーバーB ‘コマンド’
このようにSSHの機能をうまく利用してください。
作業しないときはログインしない、これが鉄則です。また、Linuxでコマンドを実行するのであればシェルの機能を大いに利用してください。
知っていると役に立つLinuxコマンド・シェルテクニック 
インフラ作業で使えるLinuxコマンドテクニック
ちょっとした機能を知っているか否かで作業効率もミス発生率も大きく変わります。
まとめ
作業手順書を作成する際は以下の点に注意する必要があります。
- 誤解を招く表現は避ける（「以上」「以下」には要注意）
- 状況によって手順を飛ばしたり分岐させない
また、作業手順書を使えば誰でも同じ作業を実行し同じ結果を得られるようにしなければなりません。
そのためには次の点を考慮する必要があります。
- 作業内容を適切な単位に分割し、分類する
- 作業の順番は適切か？本当にその順番で実行する必要があるのか？検討する
- サーバーやネットワーク機器の便利な機能を最大限利用する
- 作業者にストレスを与えない
仕事でいかにミスを防ぐか、そして失敗から学ぶ良書をご紹介します。どれもおすすめです。
