[公開版]社内バッチ処理ガイドライン - Qiita
このガイドラインについて こちらのガイドラインは社内のバッチ処理スクリプト開発にあたっての、安定運用等に関わるガイドラインを公開用に書きなおしたものになります。 バッチサーバ規則 基礎項目 以下の要項を満たすことを確認する その他の用途で動作しているサーバ上での動作は行っていないこと 運用期間中に想定しうるデータ量にてOOMキラーに殺されないこと 想定の時間で終了すること データの読み込みは極力Read Replicaを見ていること データの書き込みによる本番サーバへの影響が見積もれていること 冪等性が担保されており、何度実行しても処理上の不具合は発生しないこと 多重実行時に不整合が発生しないこと エラー時の社内への通知が用意されていること エラー時の通知には再処理のための手順が揃っていること、もしくはそのドキュメントの場所が示されていること 個人ユーザー下にログや成果物を絶対に書き込んで
![[公開版]社内バッチ処理ガイドライン - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/9d4ab6774ca44153c822fc2e97e27f4891af08c5/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Fadvent-calendar-ogp-background-f625e957b80c4bd8dd47b724be996090.jpg%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTkxNiZoPTMzNiZ0eHQ9JTVCJUU1JTg1JUFDJUU5JTk2JThCJUU3JTg5JTg4JTVEJUU3JUE0JUJFJUU1JTg2JTg1JUUzJTgzJTkwJUUzJTgzJTgzJUUzJTgzJTgxJUU1JTg3JUE2JUU3JTkwJTg2JUUzJTgyJUFDJUUzJTgyJUE0JUUzJTgzJTg5JUUzJTgzJUE5JUUzJTgyJUE0JUUzJTgzJUIzJnR4dC1jb2xvcj0lMjMzQTNDM0MmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmdHh0LWNsaXA9ZWxsaXBzaXMmdHh0LWFsaWduPWxlZnQlMkNtaWRkbGUmcz05OWIxNDcwMDNlNTVmZjU5MjI4YmU0Y2IxOGM1YmIyNg%26mark-x%3D142%26mark-y%3D151%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTYxNiZ0eHQ9JTQweV9tYXRzdXdpdHRlciZ0eHQtY29sb3I9JTIzM0EzQzNDJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTM2JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnM9YTE4MGQ3Yjg3NTQyMTE5M2RkMmNlMWZhZTIyNzdmMjc%26blend-x%3D142%26blend-y%3D491%26blend-mode%3Dnormal%26s%3Df972b16a98c6230f6ba5f90a9702aef8)
crontab ではパーセント記号をエスケープする - はったりエンジニアの備忘録
タイトルのままですが、ハマったので忘れないようにメモ。 スクリプトの実行結果を日付つきのファイルに保存するために date コマンドでフォーマットを指定しましたが、なぜか構文エラーになります。同じコマンドを手動で実行すれば期待通りの動作をします。
cron で > /dev/null して椅子を投げられないための3つの方法 - 酒日記 はてな支店
(タイトルは釣りです) いい加減、>/dev/null 2>&1と書くのをやめたらどうか - DQNEO起業日記 この記事のタイトルが twitter で流れてきたのを見て、「そうだ！出力を /dev/null に捨てるなんてとんでもないよね！」と思ってよく読んだら /dev/null に間違いなく捨てる方法だったのでつい crontabに > /dev/null 書いたら椅子投げる 2012-06-13 00:01:17 via YoruFukurou とつぶやいてしまったのですが、では出力を捨てないためにはどうすればいいのか。現時点での個人的ベストプラクティスを書き留めておきます。 デフォルト : メールで送る (MAILTO) せっかく cron daemon がログを捨てないためにわざわざメールで送ってくれるのに、それを > /dev/null で踏みにじるとはひどい。 とはいえ、
多重起動を防ぐシェルスクリプト - zenpouの日記
cron等でシェルを複数回実行した時、多重起動するとまずいので、それを回避するスクリプト。 業務上必要だったので作ってみた。 #!/bin/sh SCRIPT_PID="/home/takase/work/run_script.pid" if [ -f $SCRIPT_PID ]; then PID=`cat $SCRIPT_PID ` if (ps -e | awk '{print $1}' | grep $PID >/dev/null); then exit fi fi echo $$ > $SCRIPT_PID (この辺にバッチの処理) rm $SCRIPT_PIDpidでプロセスの有無を確認しているので起動中は２重に実行されないし、 何か理由があって落ちてた場合は再実行される。 後はcrontabにこのシェルを設定してやればOK
cron 設定ファイル (crontab ファイル) の置き場所と書式について - ひだまりソケットは壊れない
cron周りのベストプラクティス読んだ - $shibayu36->blog; 上の記事を読んで興味を惹かれたので、『WEB+DB PRESS Vol.79』 の 「cron 周りのベストプラクティス」 を読んだ。 Web 上でも公開されている。 (2014-06-23 追記。) 第25回 cron周りのベストプラクティス（1）：Perl Hackers Hub｜gihyo.jp … 技術評論社 そこでは cron 設定 (crontab) ファイルの記述方法として crontab コマンドを使用する方法が書かれていた *1。 で、記事を見てるうちに、以前 crontab コマンドやら /etc/cron.d やらの違いがよくわからずに調べて社内日記に書き残しておいたことを思いだしたのでブログで公開しておこうと思う。 ちなみに man の内容などは Debian 7 で見てるので、別ディス
crontab -r を安全にする - Kentaro Kuribayashi's blog
間違えて crontab -r してしまい、crontab をふっとばしてしまったので、以下のような zsh 関数を書いて、確認を出すようにした。つか、隣同士にある -e と -r で編集と削除とか、酷いよ＞＜。。。 #### crontab -r で死なないために functions crontab () { if [ $1 = -r ]; then echo -n "ほんとに消しちゃっていいの？ [yes/no]" read ANSWER case "$ANSWER" in y | yes ) command crontab "$1" && echo "消した" ;; * ) echo "typoったの？ぷっくすｗｗｗ" ;; esac else command crontab "$1" fi }↑この書き方だと、たとえば crontab -u username -eとかが使えなくなる
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Is the following cron expression means every 45 minutes?