【瞎扯】从维护角度看日志的重要性——请做一个靠谱的开发

至上次离职转战维护已经快要一年，从机器到货至机器安装、上架、加电、系统安装、网络配置、业务部署、调试、安全加固、试运行、正式运行、日常脚本添加、紧急故障处理、问题排查、甲方使用培训、服保工作......就这样我从一个坑跳入了另一个坑，平日无事时工作枯燥且重复，巡检，巡检，巡检；产品问题解答，产品问题解答，产品问题解答......当把一堆机器安装部署产品熟记于心后，日常巡检因为shell的存在变得简单地取出报告阅读。产品完善性、稳定性、健壮性的问题就摆在了维护人员的面前。

对于商业的生产环境来说，即使原始一些，为了保障服务的正常运行和硬件、基础软件的可靠性来说，至少也会有双电源主备、双机主备的存在。如此，往往故障的发生点就落在了业务产品上。事实上，的确如此。只是聪明的维护攻城狮常常会让基建设备、系统来背宕机中断业务的锅。当故障发生之时最首要的工作就是按照紧急预案迅速恢复业务，恢复之时请别忘了留下现场证据，迅速进行排查，因为故障报告可不能少。那么业务挂了，机器挂了，这个时候我们还能够做什么，依靠什么来进行排查呢？当然这里要除去平日脚本的回写报告了，否则就是工作不力了。因而这个时候最重要的东西就是——日志。

日志，通常会涉及到两种存储方式：

一、数据库专用业务日志表存储；

二、文件方式（Linux、Unix，当然还有蛋疼的Windows下的文件存储）

对于，数据库存储的日志，往往记录的是业务运行时一些综合的业务处理数据，这个会按照需求定位来做存储，对于故障的解决，维护也只能观察正常业务运行时的数据和业务故障点的数据（前提故障时有数据的情况，若无即可忽略），做一个分析统计、对比作为故障排查的参考。

正常情况下真正使用到的是业务、系统（这里不谈系统方面的东西），那么业务日志的好坏，记录的详细程度、日志数据的有效性就显得尤为重要了。对于业务日志，根据日常工作得出的经验分以下：

一、日志记录的刷新时间不能太短，通常2-3天做一次刷新会比较好；

二、单个日志文件不要过大，否则影响查找效率以及取日志时网络时间上消耗过多影响反馈和处理的效率；

三、日志文件应该以小文件为主，且日志有效性很重要，不要计入过多的冗余数据，最好精简，或者以文件离散的方式进行存储，日志节点信息即可方便查找。

四、日志文件名请带上创建文件时的时间戳，排查时ls -ltr（或ll）即可根据故障点快速定位查找的日志；

五、业务运行开始，无论模块，请留下痕迹，缺斤少两的事请别做。找不到痕迹，为难维护，研发会挨骂。

六、业务日志内容按一定逻辑来记录才是工整的日志。

七、开辟模块，统一存储日志，如果条件允许，来个远程日志也是极好的。

八、【此条纯属瞎掰】用什么双机啊，什么年代了，用集群吧。

售后维护，也许无聊，但是作为一个多维度的系统管理员，合格到优秀要求是极多的，为了大家工作轻松与和睦的相处，作为研发的合作伙伴们，软件运行了请留痕迹，深切简明扼要的日志才是right log。