作業ログの取り方

このブログをご覧のみなさんは、おそらく何らかの形で開発作業、あるいは設定作業の経験をお持ちだと思います。みなさんは、日々の作業の記録をどのように取られているでしょうか?もし、作業ログを取る習慣がない、あるいは忙しすぎて作業ログをとることに気が回っていないのであれば、作業ログを確実に取る習慣をつけることをお奨めします。この習慣は、きっとあなたの作業の信頼性を上げ、作業効率向上に貢献するはずです。

●作業ログがなぜ必要か

まず最初に、なぜ正確な作業ログをとる必要があるのでしょうか? その答えは簡単です。再現性を確保するためです。自分が不具合報告を受ける立場で考えてみてください。もし、部下やユーザから「動きません」や「バグです」という報告を受けた場合、すぐに問題があると判断するでしょうか? ほとんどの人は、まず報告されている状況を正確に理解したうえで判断したいと考えるのではないでしょうか?

●作業ログに求められるもの

では、報告を受ける人が求めている情報とはどのようなものでしょうか?私は、以下の 4 点を記録・報告することを心掛けています。

1. どのような環境で起ったのか
2. どのような操作が行ったのか
3. どのような結果になったのか
4. いつ発現したのか

ここで一つ注意があります。それは不具合報告だけでなく、問題が起らなかったという報告をする際にもこれらの情報が必要だということです。成功しているように見えて実は失敗なんて経験、いままでありませんか :-)

●なにを使って作業ログをとるか

最近は wiki や blog などのツールが充実してきました。これらのツールを使って作業記録をとっている人も多いと思います。これらのツールで記録しておけば、情報共有も簡単にできます。いいことづくめのようですが、私は再現性の確保という点については疑問を持っています。よく、コンパイル手順などを wiki に掲載しているページを見掛けますがどのように利用されているでしょうか? ほとんどの場合は、操作の部分をコピーして、自分が作業している端末にペーストしていると思います。うまく動いているときはいいのですが、何かが原因でうまく動かなかったとき、なぜ失敗したのかがはっきりしないことがあります。「ほんとにこの操作でうまくいったの?」という疑問を持った経験はないでしょうか? 私はこのようなことを引き起こさないために、シェルスクリプトと script コマンド使っています。

●正確な作業ログの取り方

• 作業手順はシェルスクリプト

私は、作業手順を予めシェルスクリプトにまとめることで、作業手順の再現性を確保します。私の経験では、作業が一度で済むことはまずありません。何らかの原因でもやり直しが必要になることがほとんどです。この方法は、シェルスクリプトを実行することで同じ手順を再現するので、人間がコマンドライン操作をするよりも正確に作業を再現できます。また、環境変数の設定など作業の前提条件もまとめて記述しておけばさらに再現性は高くなります。

○Tips

作業をシェルスクリプトにまとめる際、忘れてはいけないおまじないがあります。

1. 各コマンドの終了ステータス($?)の確認および表示する
2. シェルスクリプトの最初と最後に date コマンドを実行する
3. 影響を与えそうな情報は処理を始める前に表示する
4. set -u

1.は、プログラムを書く上での基本です。終了ステータスを確認し、異常があればエラーメッセージを出してプログラムを停止させます。問題が発生したとき、どの処理の実行中にどのようなエラーが起ったのかを把握することができます。シェルは、シェルスクリプトの内容を読んで実行するだけなので、エラー処理を明示的に書かないと処理が先に進んでしまいます。エラー処理を怠ると思わぬ結果を引き起こします。

foo; ret=$?
if [ $ret -ne 0 ]; then
    echo "foo failed: exit status = $ret" >&2
    exit 1;
fi

2.は作業の開始時刻と終了時刻を記録することで、作業にどのくらい時間ががかかったのかが分かります。あまりにも早く処理が終わっていたり、時間がかかりすぎたりしていれば、なにか異常がないかを確認できます。また、一回当りの作業時間がわかれば、今後の作業時間の見積もりに使えます。

#! /bin/sh
date;
:
:
:
date;

3.は作業に関連する情報を表示しておくことで、実行時の環境を確実に記録します。たとえば、設定ファイルの内容が重要な場合であれば、cat コマンドで表示しておきます。

#! /bin/sh
date;
:
echo "### /etc/hosts ###"
cat /etc/hosts
:
:

4.は未定義の環境変数を参照したときに処理を停止するための指定です。これを指定しておかないと思わぬ副作業を引き起こしますので要注意です。以下の処理で、もし WORKDIR を WORKIDR のように typo したとき、どのようなことが起るでしょうか? 考えてみてください :-p

rm -rf ~/${WORKIDR}/*

○作業ログは script コマンド

作業ログは script コマンドを使ってとります。script コマンドはオプションでログファイル名を指定することができます(man script 参照)。なにもオプションを指定しないと typescript というファイル名にログが記録されます。複数回、script を実行するとログはtypescript ファイルに追記されてしまいます。これではせっかくログをとってもログの世代管理ができていませんので、イマイチ役に立ちません。script を実行する際には、日付、時間を含んだものログファイル名を指定することでいつのログなのかを分かるようにしておくと良いでしょう。

$ script `date +%Y%m%d-%T`.log

date コマンドはよく使うので、以下のようなシェルスクリプトを ~/bin に持っておくと便利です。

$ cat ~/bin/timestamp
#! /bin/sh
date +%Y%m%d-%T

さきほどの script との組み合わせは以下の通り。

$ script `~/bin/timestamp`.log

○ コラボレーション

わざわざ作業手順をシェルスクリプトにしたのは理由があります。それは、script コマンドと連携させるためです。scriptコマンドには、環境変数SHELL に指定されたコマンドを実行してログをとるという機能あります。作成した作業手順シェルスクリプトを環境変数 SHELL に設定して script を実行することで、実行する度に日付入りのログファイル名に作業内容を記録することができます。

$ env SHELL=./prog-build.sh script prog-buiild-`~/bin/timestamp`.log

●まとめ

以上の方法で、「作業ログに求められるもの」で書いた 4 点をすべて間違いなく記録することができます。一度失われた情報は二度と取り戻すことはできません。記憶に頼った作業では作業成果の信頼性を上げることはできません。

私はプロフェッショナルと素人との違いは、常に確実な作業ができるかどうかだと考えています。今回の作業ログについてもその一つです。些細な TIPS ですが、お役に立てれば幸いです。

Comments

[投稿： hyoshiok]

参考になりました～
これからもどしどしTIPSを掲載してくださいまし。
ちなみに、わたしはxemacsのshellモードで作業をしていて、一日の作業が終わったときに、それをファイルに保存しています。

[投稿： jun]

前の会社にいたときに客先に出向いてログ取るときは、tcsh で prealias に date を指定して各コマンド発行での時刻採取をしていました。
bash とかでもできるのかどうかは…、知りません。

[投稿： fumiyas]

sh 系のシェルのプロンプトは PS1, PS2, ... です。こんな風にやればできます。

$ PS1='`date` $ '
2006年 8月 22日 火曜日 10:42:01 JST $

ちなみに、私の PS1 は
PS1="\[\e[36m\]\u@\h:\w\$ \[\e[m\]\[\e]2;\$PWD - \$LOGNAME@\$`hostname`:`tty`\007\]"
です。(実際は端末の種類など環境の違いにより切り替えてますが)