Cronの構文は、「祝日を除く平日の午前9時ごと」や「8時から18時の間、15分ごと」を、どういうわけか表現しなければならない、数字と記号からなる5つのフィールドです。フィールドは分、時、日、月、曜日の順ですが、最初の挑戦で正しく覚えている人はほとんどおらず、アスタリスク、カンマ、ハイフン、スラッシュはすべて、位置によって異なる意味を持ちます。
0 9 * * 1-5は妥当に見えますが、それは午前9時なのか午後9時なのか、そして1-5は月曜から金曜を意味するのか、それとも使っているcronの実装が日曜を0とするか7とするかによってまったく別のものを意味するのか。デプロイパイプライン、バックアップジョブ、スケジュールされたレポートでこれを間違えると、静かな失敗か、都合の悪い時間にジョブが実行されることになります——時には誰かが気づくまで数週間かかることもあります。
すべてのcron実装には独自の癖がある
標準的なUnixのcron、KubernetesのCronJob、AWS EventBridge、さまざまなCIプラットフォームは、いずれもほぼ同じ5フィールドの構文を使っていますが、秒がサポートされているか、曜日の番号付けがどう機能するか、@dailyのような特定の省略記法が有効かどうかなど、細かい点で異なります。最初のデプロイで正しく動作するスケジュールを書くには、対象としているcronの種類を正確に理解する必要があります。
式を平易な言葉に変換
Bellowsには、スケジュール文字列を受け取り、それが実際に何を意味するかを平易な言葉で説明するcron式ヘルパーが含まれており、スケジュールされたジョブをどこかにデプロイする前に意図を確認できます。
デプロイ前の確認
間違った時刻に発火するスケジュールされたジョブは、しばしば静かな失敗です——何もクラッシュせず、単に意図しないときに実行され、時にはメンテナンスウィンドウと重なったり、ピーク時のトラフィックでデータベースに負荷をかけたりします。デプロイ設定をマージする前にcron文字列の平易な意味を確認することで、これが午前2時のアラートになる前に発見できます。
他人のスケジュールを読む
十数個の既存のcronジョブがあるコードベースを引き継ぐということは、それらを安全に変更できるようになる前に、それぞれが何をしているかを把握する必要があるということです。各式を素早く翻訳する方が、1つのジョブごとに5つの不可解なフィールドを頭の中で解析するよりも速く済みます。