【実録 第16話】朝起きたら、自動化が止まっていた話

第15話まで、このメディアの記事生成・アクセスログ解析・トレンド調査を、深夜に自動で動かす仕組みを整えてきました。設定が終わったあとは、毎朝「昨夜何が起きたか」をNavに確認するだけ。そんな運用が軌道に乗りはじめた頃のことです。

4月から5月にかけて、3回止まりました。。。

毎回同じエラーコードが出ましたが、原因は毎回違いました。今回は、自動化が「動いている」と「動き続ける」は別の話だと気づくまでの3ヶ月を書きます。

Macをアップデートしたら、翌朝から止まっていました

4月13日、Macのシステムアップデートを実行しました。よくある定期更新で、特に気にしていませんでした。

翌朝、いつも通り朝のブリーフィングを確認しようとして、おかしいことに気づきます。深夜5時に動いているはずの記事生成が、動いていません。6時のトレンド調査も、7時半のログ解析も、何も動いていませんでした。

Navに確認を頼みました。

ログのタイムスタンプを照合すると、4月1日から13日まではきちんと自動実行されていて、14日以降は手動実行の記録しかありませんでした。止まったのは間違いなくアップデートのタイミングでした。

コマンドを1行実行して、設定ファイルの所有者を変更しました。動作確認を終えて、翌朝の自動実行が再開したのを確認しました。

エラーコードは同じ。でも原因は違いました

このとき表示されていたエラーコードは「78番」でした。「設定に問題がある」という意味のコードで、Macの自動実行の仕組みが「この設定ファイルは読み込めない」と判断したときに返ってくる番号です。

原因がわかって直した、と思っていました。

この78番が、5月にもう2回出ることになります。同じ番号ですが、原因はまったく別のことでした。

再起動したら、また止まっていました

5月18日、別の作業のためにMacを再起動しました。特に問題はないはずでした。

翌朝のブリーフィングで、また気づきます。記事生成・トレンド調査・ログ解析、3つのジョブが前日から動いていませんでした。エラーコードは4月と同じ78番です。

手動で実行すると問題なく動くのに、自動実行だけ失敗する。4月と同じ症状で、原因だけが違いました。全件修正して再起動し、動作確認を取りました。解決しました。…と思いました。

直そうとした操作が、別の場所を壊していました

翌5月21日、朝のブリーフィングでNavが報告を持ってきました。

設定ファイルの所有者を全6件まとめて修正して、再ロードしました。翌朝5時から、ようやく全ジョブが正常に動き始めました。

無人で動かすことと、無人で壊れることは、セットでした

3回の停止を振り返ると、共通していることがあります。

止まっていても、気づくのは翌朝のブリーフィングのタイミングだということです。深夜に無人で動かしているということは、深夜に無人で止まっても誰も気づかないということでした。

自動化を「組んで終わり」にはできないということも、改めて実感しました。OSのアップデート・Macの再起動・修正作業の副作用——どれも「まさかこれで止まるとは」という出来事でした。

自動化は「作れば終わり」ではなく、「動き続けることを確認し続ける」ものでした。朝の確認がなくなったわけではありません。ただ、確認する内容が「作業」から「チェック」に変わりました。それで十分だと、今は思っています。

まとめ

• 自動化が止まっても気づくのは翌朝。深夜に無人で動かすことと、無人で壊れることはセットだった
• 同じエラーコードでも、原因は毎回違った。前回の直し方がそのまま通じるとは限らない
• 直す操作が別の場所に影響することがある。修正後は影響範囲を確認する習慣が必要だった
• 自動化は「組んで終わり」ではなく「動き続けることを確認し続けるもの」だった