cron で朝の定型作業を手放す:続く自動化の設計メモ

執筆者:

カテゴリ:

朝の作業は「同じ手順の繰り返し」でできている

毎朝パソコンを開いて、まず同じことをしている人は多いと思います。ログの確認、バックアップ先の空き容量のチェック、前日分のファイルの整理、決まったフォルダへのレポートの書き出しなどです。一つひとつは数分で終わりますが、毎日続くと意外に集中力を削られます。

Linux には、こうした作業を決まった時刻に実行してくれる cron という仕組みがあります。この記事では、コマンドの細かい書き方よりも、どんな作業を cron に任せ、どう設計すれば長く動き続けるかという考え方を中心にまとめます。

まず「任せてよい作業」を見極める

何でも自動化すればよいわけではありません。cron に向いているのは、次のような性質を持つ作業です。

  • 手順が毎回同じで、途中で人が判断する必要がない
  • 実行する時刻が決まっている、または決まっていても困らない
  • 失敗したときに、やり直しても被害が出にくい
  • 結果が「見ればわかる」形で残せる

逆に、実行のたびに内容を確認したい作業や、失敗すると取り返しがつかない作業は、いきなり自動化しないほうが安全です。まずは「確認して通知するだけ」の作業から始めると、失敗しても困りません。

手作業をそのまま書き写さない

自動化の第一歩は、手順をスクリプトにまとめることです。cron の設定そのものには、長いコマンドを直接書かず、スクリプトを一つ呼び出すだけにしておくのがおすすめです。理由は三つあります。

  • スクリプトは手で実行して動作を確かめられる
  • cron の設定行が短く読みやすいまま保てる
  • スクリプトをバージョン管理に入れて変更履歴を残せる

cron に登録する前に、必ず端末から手で実行して、期待どおりに動くことを確認しましょう。「手では動くのに cron からだと動かない」という問題は、次に述べる環境の違いが原因であることがほとんどです。

cron は「いつもの環境」ではない

cron から起動されるプログラムは、ログインシェルとは違う、最小限の環境で動きます。特に次の点でつまずきやすいです。

  • PATH が短く、普段使っているコマンドが見つからないことがある
  • カレントディレクトリが想定と違うことがある
  • シェルの設定ファイルで定義した変数やエイリアスは読み込まれない
  • 端末がないので、対話的な入力や画面表示は使えない

対策は単純です。スクリプトの中で使うコマンドはフルパスで書くか、冒頭で PATH を明示します。作業ディレクトリも先頭で明示的に移動します。必要な設定値は、スクリプト内か専用の設定ファイルから読み込むようにします。「環境に頼らない」ことが、cron で安定して動かすための基本です。

時刻の指定は「ずらす」「重ねない」

cron の時刻指定は、分、時、日、月、曜日の五つの欄で書きます。毎朝実行したい場合は、日・月・曜日の欄を * にして、分と時だけを指定します。

設計上のポイントは二つあります。一つ目は、きりのよい時刻に集中させないことです。たとえば 6 時ちょうどに多くの処理を走らせると、互いに重くなります。数分ずつずらしておくと、負荷が分散されます。二つ目は、前回の実行がまだ終わっていないのに次の実行が始まる事態を避けることです。実行時間が延びる可能性のある処理には、flock などによる排他制御を入れておくと安心です。

また、パソコンが起動していない時刻の分は、cron では実行されません。ノート PC など常時稼働でない環境では、この点を前提に考える必要があります。そうした環境向けには、取りこぼしを後から実行する anacron のような仕組みもあります。自分の環境がどちらに当たるかを先に確認しておきましょう。

何が起きたかを必ず残す

自動化で最も怖いのは、止まっているのに誰も気づかないことです。そのため、実行結果は必ず記録します。

  • 標準出力と標準エラー出力をログファイルにリダイレクトする
  • 各実行の開始と終了の時刻をログに書く
  • 失敗時は終了コードが 0 以外になるようにスクリプトを作る
  • ログが増え続けないよう、ローテーションや削除の仕組みを用意する

cron は、設定によっては出力をメールで送る機能も持っていますが、メール環境が整っていないと届かないまま捨てられることもあります。そのため、メールだけに頼らず、ログファイルを残すのが確実です。さらに、失敗したときだけチャットやメールに通知する仕組みを足すと、「静かなら正常」と判断できるようになります。

失敗しても安全な作りにする

朝の作業を任せる以上、いつか必ず失敗する日が来ます。そのときの被害を小さくするために、次のことを意識します。

  • 同じ処理を二回実行しても結果が変わらないようにする(冪等にする)
  • ファイルを消す処理は、対象を厳密に絞り、最初は一覧表示だけで試す
  • 変数が空のまま削除コマンドに渡されないよう、スクリプトの先頭でエラー時に止まる設定を入れる
  • 書き込みは一時ファイルに行ってから置き換え、中途半端なファイルを残さない

とくに削除を伴う処理は、変数の誤りが大事故につながります。最初の数日は実際に消さず、「消す予定の一覧」をログに出すだけにして、結果を目で確認してから本番に切り替えると安全です。

小さく始めて、見直しながら育てる

最初から完璧な仕組みを作ろうとすると、手が止まってしまいます。おすすめの進め方は次のとおりです。

  • 毎朝の作業のうち、最も単純なものを一つだけ選ぶ
  • 手で実行できるスクリプトにする
  • cron に登録し、数日間はログを毎朝確認する
  • 問題がなければ、次の作業を一つ追加する

数週間たったら、ログを見返して、不要になった処理や、頻繁に失敗している処理を整理しましょう。自動化は作って終わりではなく、環境や仕事の変化に合わせて手入れしていくものです。

まとめ

cron で朝の作業を自動化するときに大切なのは、書き方のテクニックよりも、設計の姿勢です。任せてよい作業を選び、スクリプトに切り出し、環境に依存せず、結果を記録し、失敗しても安全にしておく。この積み重ねで、朝の数分間が確実に手元に戻ってきます。まずは「確認して記録するだけ」の小さな作業から、始めてみてはいかがでしょうか。

コメント

コメントを残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です