SEP 3 -- Crontab脚本运行规范

Head

对crontab脚本的使用方面，提出一些基本的规范。

我们线上的crontab脚本有很多，有很多脚本是关键业务，如果出现问题会直接客户的系统使用体验。先前出现过几次crontab没起来的情况，造成大面积的投诉，所以这块的稳定性需要重视起来。

发布或者修改线上crontab脚本，改完后，必须亲自看到通过crontab本身执行过一次才算发布成功，也就是线上验证必须做。防止改错了，后续运行不起来还不知道。如果没有走过这个流程，认为这次发布没有完成。

由于crontab的执行和状态很难监控，出问题了我们很难立刻知道，如果实时业务依赖了crontab，一旦crontab没跑起来，会造成大面积的客户不可用。

Crontab的使用场景，通常只用于一些统计，或者可以延迟处理的业务场景，也就是说，如果crontab大半天没跑，也不会对实时业务造成太大的影响，这种场景可以用。其他情况下如果要用，必须经过慎重的考虑，必须能证明所有其他可能性都无法实现或者成本太高，才可以考虑。

任何脚本跑的时候，都不能对系统负载造成爆发式影响，比如突然让cpu跑到100%而且持续好几分钟，或者内存占用网络带宽等等。任何造成这种结果的脚本，都不允许跑。

建议：

脚本中处理数据的时候，如果数据量很大，不要在一个循环里一次处理完，这样要么本机会cpu和内存很高，要么会造成db那边的cpu内存过载。最好是分批次跑，比如一次处理100条，然后sleep个0.5秒，然后再继续。这样能平滑系统负载。
脚本跑的时间，尽量避开业务高峰期，避免出现与业务争抢系统资源的情况。
如果上述两个策略还是不能解决问题，有些脚本就是cpu密集型或者内存消耗型，可以考虑把这个脚本独立到非实时业务机器上。
所有的脚本要跟线上接口一样，输出处理日志，以备后续排查问题。