運用手順書を作る側になって感じた大変さと楽しさ
とある作業の運用手順書の作成を月次作業として任されました。パスの変更だけでなく、コマンドの配置やそれに伴うパスの作成まで考える大変さと、学んできた Linux をフルに使える楽しさを書きました。
運用手順書の作成を任された
こんにちは、コマンド学習道場を運営しているこすけです。
今回は、ここ最近の仕事の話。
実は、とある作業の運用手順書の作成を、月次作業として任されることになりました。
今週から作り始めているのですが、これがかなり大変。
これまでのコラムでは、手順書を「読む側」「使う側」の話を書いてきました。
今回はその逆で、手順書を「作る側」に回ってみての話です。
前の現場での作業とは違う大変さ
前の現場でも、ちょっとしたパスの変更やパスワードの変更といった作業はやっていました。
なので、手順書を作ること自体がまったく初めて、というわけではありません。
ただ、今回はそれとは規模も中身も違っていて。
パスを変更するだけでなく、各コマンドをどこに配置するか、それに伴ってどんなパスを作るか、といったところまで考える必要があるんです。
1つ変えると、それに合わせてほかの部分も直さないといけない。
全体のつながりを意識しながら組み立てていくのが、今回いちばん大変だと感じているところです。
手順書は「誰が読んでも同じ作業ができる」もの
手順書は、作った本人だけが読むものではありません。
月次作業ということは、毎月だれかがこの手順書を見ながら作業をするということ。
そう考えると、一般的に手順書には次のようなことが求められます。
ひとつは、誰が読んでも同じ作業ができること。
書いた人の頭の中にしかない前提があると、読む人によって作業の結果が変わってしまいます。
もうひとつは、コマンドを実行したあとに、ちゃんとできたかを確認する手順があること。
たとえば、ディレクトリを作る手順なら、こんな形になります。
# 1. 作業用ディレクトリを作成する
$ mkdir -p /path/to/work
# 2. 作成されたことを確認する
$ ls -ld /path/to/workコマンドの順番、パス、確認方法。
どれか1つでもずれていると、読む人は途中で迷ってしまいます。
以前のコラム「手順書どおりなのにコマンドが弾かれたときの対応」で書いたように、パスが1つ違うだけでコマンドは弾かれてしまうもの。
作る側の小さなズレが、使う側のトラブルにつながるのだと、作る立場になって改めて実感しています。
力を入れてきた Linux をフルに使える楽しさ
大変だ、大変だと書いてきましたが、実はとても楽しいんです。
理由はシンプルで、Linux など、これまで力を入れて勉強してきた分野をフルに使えているから。
コマンドの意味、パスの考え方、ディレクトリの役割。
学んできたことが、そのまま手順書づくりに生きている。
以前のコラム「手順書どおりに打てるだけでは仕事にならない理由」で、手順書の意味を理解しておくことが大事だと書きました。
手順書を作る側になってみると、その大切さがよりはっきり見えてくるんです。
意味がわかっていないと、そもそも手順書は書けないのですから。
慣れるまでは大変、それでも
正直なところ、慣れるまではまだまだかかりそう。
1つひとつのコマンドやパスを確かめながら、少しずつ形にしているところです。
それでも、手順書を作る経験は、読む側・使う側だった頃には得られなかったものばかり。
大変さも含めて、今の自分の成長につながる仕事だと思って取り組んでいます。
これから手順書を書く機会がある方も、まずは使っているコマンドの意味をしっかり押さえておくのがおすすめ。
コマンドの確認にはLinuxコマンド一覧を、実際に動きを試したいときは練習用ターミナルを使ってみてくださいね。