接到一个老客户的求助：业务员说昨天下午有三张订单莫名其妙不见了。打开系统日志想查，里面只有一行行的启动信息和几条看不懂的报错，关键时间段什么都没有。三个小时过去，问题定位不了，最后只能数据库里翻。后端系统开发的日志就像飞机的黑匣子，平时没人看，出事的时候才知道没它寸步难行。
该记的四类东西
- 关键业务动作：下单、支付、退款、改价、删数据，每条带上用户ID和业务单号，谁在什么时候动了哪张单，一眼可查；
- 异常和报错：完整堆栈加请求参数，只有一句空指针没有入参的日志，排查时等于没写；
- 外部接口调用：支付、短信、物流这些第三方调用的请求和响应都留痕，掉单、丢消息全靠它定位；
- 慢操作：超过一秒的数据库查询和接口，标出来，性能恶化能提前发现。
那位客户后来补齐了日志规范，半年后再出类似问题，十分钟就查到是某次批量导入把三张单的状态改错了，操作人和时间都在日志里，清清楚楚。
分级和纪律
日志要分级别：error是必须处理的问题，warn是异常但没影响主流程，info是正常的关键动作。最怕的是全打成info，真出事时海量信息里捞不到重点；也怕反过来全是error，狼来了喊多了，真警报也没人看。还有两条纪律：密码、验证码、身份证号这类敏感信息严禁进日志，日志库泄露就是二次事故；日志要有保留期限，按天滚动清理，见过服务器被日志写满导致整站瘫痪的，比业务故障还冤。
记日志的终极检验标准是能不能按单号检索。输入一个订单号，从创建、支付到发货的完整链路全查得出来，这才叫可用。做不到这一点的日志，记录得再多也是死数据。小系统用文件加简单检索就够，量大一点的把日志集中收进ELK这类平台，查询效率完全不是一个量级。
验收时就该查日志
别等出事才检验日志。验收系统时做三个动作：随便挑一张订单，按单号能不能查出全链路；让开发方现场制造一个报错，看日志里堆栈和参数全不全；翻一眼日志文件里有没有明文密码。三件事十分钟，价值却在上线的每一次排障里，日志质量也因此成了后端系统开发验收里性价比最高的检查项。
两条建议：把日志规范写进开发合同的技术要求，明确关键动作必须带单号；系统上线满三个月，安排一次日志健康检查，比格网络做巡检时日志可检索性是硬指标，黑匣子装没装好，要在起飞前确认，而不是坠机之后。
