【現役エンジニアが教える】Linuxの手順書の基本的な作り方！作る際のコツ3選も紹介

サーバエンジニアをしていれば、必ず見ることになる作業の手順書。既存の作業手順書を見る機会が多いと思いますが、1から作成しないといけないこともあるでしょう。

しかし、実際に手順書を作ると言うのは、作業への深い理解も必要になるので、とても大変なことです。

この記事では、現役のインフラエンジニアが、手順書の作り方やコツについて紹介します。手順書作成に困っているインフラエンジニアの方は、ぜひ最後までお読みください。

手順書作成の基本

まずは、手順書作成の基本について紹介します。

というよりも一部の方は、ここさえ覚えてもらえばOKというレベルかもしれません。その基本と言うのは、下記のとおりです。

こちらが一番伝えたい内容です。「こんなこと？？」と思うかもしれませんが、この基本こそが手順書作成において一番重要なことです。また、どの作業においても必ず必要になります。

実際の手順の例

ここでは、先ほどの例を元に実際の手順の例を紹介します。今回は、/etc/rsyslog.confの修正をする想定で手順を紹介してみます。

サーバにログインする

ユーザ・日時・ホスト名を確認する
$ whoami;date;uname -n

ルートへスイッチする
$ su -

ルートにスイッチできたことを確認する
# whoami

編集するファイルの確認をする
# ls -l /etc/rsyslog.conf

バックアップ先に、バックアップ予定と同じ名前のファイルが無いことを確認する 
※この記事では、バックアップを/tmpに取る想定です
# ls -l /tmp/rsyslog*

バックアップを取得する
# cp -p /etc/rsyslog.conf /tmp/rsyslog.conf.bak_$(date +%Y%m%d)

バックアップが取れたことを確認する
# ls -l /etc/rsyslog.conf  /tmp/rsyslog*

対象ファイル内を確認する
# cat /etc/rsyslog.conf

ファイルの編集を行う
# vi /etc/rsyslog.conf

編集後のファイル内を確認する
# cat /etc/rsyslog.conf

差分確認を行い、想定通りの修正であることを確認する
# diff /tmp/rsyslog.conf.bak_$(date +%Y%m%d) /etc/rsyslog.conf

rsyslogのステータスの確認を行う
# systemctl status rsyslog.service

rsyslogの再起動を行う ※シスログはリスタートしないと設定内容が反映されない
# systemctl restart rsyslog.service

rsyslogのステータスの確認を行う ※エラーが出てないことを確認
# systemctl status rsyslog.service

エラーログが出てないことを確認する
# less /var/log/messages

詳細な確認項目は省きましたが、コマンドベースで行くとざっくり上記のような感じです。

ファイルの編集手順に関しては、人によって異なる部分もあると思います。基本の部分で記載している「確認-実行-確認」の手順で行っているかと思います。

手順書を作る際に意識したいこと3選

ここでは、実際に手順書を作る際に意識したいことを3つ紹介します。

• コマンドの先頭の$と#の区別をしっかりする
• 迷った場合は確認コマンドを必ずはさむ
• 確認作業は1つずつ行う

ここで紹介する内容を意識しながら、手順書の作成を行いましょう。

コマンドの先頭の$と#の区別をしっかりする

まずは、コマンドの先頭の記号の区別をしっかりしましょう。$と#は、コマンドを実行する際のユーザの違いです。下記はログの一部です。

[centos02@localhost ~]$ whoami
centos02
[centos02@localhost ~]$
[centos02@localhost ~]$ su -
パスワード:
最終ログイン: 2026/07/18 (土) 19:44:11 JST 端末:pts/0
[root@localhost ~]#
[root@localhost ~]# whoami
root
[root@localhost ~]#

rootにスイッチ後に$が#に切り替わっていることがわかるかと思います。ちょっとした違いですが、手順書の中では非常に重要な部分です。

先ほど紹介した手順の中でも、冒頭のみ$でrootスイッチ後は全て#になっていると思います。エンジニアが手順書を見る際に、記号とコマンドをセットで確認することが多いです。

そのため、記号が間違っていると「このコマンド一般ユーザで実行するの？」や「rootで実行なの？」と混乱してしまいます。

細かな部分ではありますが、記号の区別を正しく行いましょう。

迷った場合は確認コマンドを必ずはさむ

手順書内で迷う部分があれば、実行系のコマンドを叩く前後で必ず確認を入れましょう。

初心者の手順書にありがちなのは、確認コマンドを省くことです。私が今まで見てきた例は下記のとおりです。

バックアップを取得する
# cp -p /etc/rsyslog.conf /tmp/rsyslog.conf.bak_$(date +%Y%m%d)

バックアップが取れたことを確認する
# ls -l /etc/rsyslog.conf  /tmp/rsyslog*

例の場合だと、バックアップを/tmp配下に取る流れです。しかし、cpコマンド実行前に/tmp配下を確認していません。そのため、仮にバックアップ予定のファイル名と同名のファイルが存在していた場合、上書きされる可能性があります。

そのため、cpコマンドを実行する前に確認するコマンドを入れる方が安全です。例ではありますが、変化が発生するコマンドの前後は、必ず確認を挟むようにしましょう。

確認作業は1つずつ行う

確認コマンドは必ず1つずつ行いましょう。

レビューしている中で、実行と確認をまとめて行われている手順書を見かけることがありました。例としては下記のような手順です。

# systemctl start test.service
# systemctl start test2.service

# systemctl status test.service
# systemctl status test2.service

例の手順では、サービスの起動を一括で行った後に、一括で確認を行っています。行いたい内容という観点でいくと、上記の手順でコマンドを実行すれば、サービスの起動そのものはできるでしょう。

しかし、サーバ操作では、操作を加えたことでエラーが発生したり、想定外の挙動が起きてしまったりすることがあります。

極端な例ではありますが「test.servicce」を起動した時点ではエラーが出てなかったとします。しかし、場合によっては「test2.service」起動したことによって「test.servicce」にエラーが発生しているということもあります。

そのため、変化が加わるコマンドは1つずつ行い、1回ずつ確認するようにしましょう。