『自動テストを 頑張って書こう』という話ではないLT

cronの設定うっかりミスをちょっとだけ防げるテストを書きました

起点となったcronの記述ミス(イメージ)

× ： * 19 * * * php hoge.php ○： 0 19 * * * php hoge.php

19時に一度だけ起動して欲しいスクリプトが、19時台に毎分動いてしまった

http://masartz.hatenablog.jp/

entry/2015/01/23/120113

対象ユーザー・phpを使ってる ・cron.txt的なものがリポジトリにある ・cronをめっちゃたくさん設定してる

<Before> * 19 * * * php hoge.php

<After> * 19 * * * php hoge.php ###prev 2014-12-31 19:00:00 ###next 2015-01-01 19:00:00

cron-expression の機能・cron設定文字列(* 19 * * *)を引数にオブジェクト生成 ・そのオブジェクトは2つのメソッドを持ち、 それぞれ指定時刻から見て以下が算出できる 　getPreviousRunDate = 「直前の実行時間」 　getNextRunDate = 「直後の実行時間」 テストで比較するもの・実行値：cron設定行のcron-expression読み取り結果 ・期待値：おまじない(prev/next)の2行の記述

* 19 * * * php hoge.php ###prev 2014-12-31 19:00:00 ###next 2015-01-01 19:00:00

これだと、テスト落ちる

0 19 * * * php hoge.php ###prev 2014-12-31 19:00:00 ###next 2015-01-01 19:00:00

これだと、テスト通る

大事なこと

「自動テストを頑張って書こう」

大事なこと

「自動テストを頑張って書こう」

障害の捉え方 ・再発の影響度合い(頻度x深刻度) ・・今後もすぐ or 何度も発生しうるか ・・発生した時の影響範囲が広い or 損失が大きいか ・・システムで解決できることか or 仕方がないことか

再発防止策の優先順位 ・根本解決する ・自動検知 or 自動復旧する ・影響範囲を局所化する ・現実的に考えて、仕方ないと判断する

良くない対応 ・cron設定をダブルチェックします ・PHPでwhenever的なものを実装する ・wheneverを使うためについでにプロダクトをRubyにする etc…

まぁまぁな対応 ・cronを簡単にparseして、少しチェックしてみる　<- 今回の対応 ・cron設定部分だけ切り出してwheneverで動かす環境を作る etc…

良い対応 ・cronで動いているscriptを減らす etc…

大事なこと

『テストを書くのは大原則』 　その上で、　適切なリソースで、適度な再発防止を！ 　　　　　　　　↓ 障害報告と再発防止策のさわりのネタでした