业务应用的可观测性、日志与错误处理：赶在顾客之前发现问题

一家网店在周六晚上订单突然骤减。团队直到顾客通过社交媒体发来消息才知道：支付按钮从下午起就点不动了。数个小时里，应用从外部看起来一切正常，但内部有一个支付服务一直在返回错误。没有人察觉，因为根本没有任何机制让人察觉。

这样的故事在应用增长速度超过监控习惯的企业中非常常见。一个应用可以平稳运行多年，然后一次小改动、一个供应商出了故障，或者一波访问高峰，就会以无人看得见的方式让它出问题。没有清晰的记录和信号，团队只能靠猜。

本文讨论可观测性，也就是从应用自身发出的信号中理解其内部状态的能力。我们将介绍它的三大支柱（日志、指标与链路追踪）、如何健康地处理错误、如何设置不会让团队麻木的告警，以及适合中小企业的务实步骤。

摘要

• 可观测性帮助团队在顾客反馈之前就发现问题
• 日志、指标与链路追踪相辅相成，单靠任何一个都不够
• 错误应当被归类并划分优先级，而不是简单堆积
• 好的告警很少、清晰，并且总是指向可以采取的行动
• 从最重要的业务流程开始，而不是一次覆盖所有组件

监控不等于理解

传统监控回答的是事先已知的问题：服务器是否在线、内存占用是否正常、首页能否打开。这类问题很重要，但它们只能捕捉人们已经想到过的故障。许多真实问题来自意想不到的组合，例如某一类商品、某一种支付方式和某一种浏览器同时触发了错误。

可观测性增加了一种能力：无需先修改代码，就能向系统提出新问题。为什么某个地区的顾客结账很慢？为什么某个分店的发票无法同步？如果应用发出的信号足够丰富，这类问题几分钟就能得到答案，而不是在冗长的会议上以猜测收场。

对企业主而言，实际价值很简单：恢复时间更短、损失更小、修复决策有据可依。您不必是工程师也可以向团队或供应商提出这个要求，只需问一句：如果今晚出了问题，我们如何得知，多快能知道？

三大支柱：日志、指标与链路追踪

日志是应用写下的事件记录，例如订单已创建、支付被拒绝、用户登录失败。好的日志是结构化的，也就是每一行都带有一致的字段，如时间、事件类型、订单标识和严重程度。自由格式的句子难以搜索，当数量达到数百万条时几乎无法分析。

指标是随时间测量的数字：每分钟订单数、平均响应时间、失败请求的百分比，或队列中等待的任务数。指标存储成本低，非常适合观察趋势并触发告警。但它只能告诉您出了问题，无法说明原因。

链路追踪跟随单个请求穿过多个服务的完整旅程：从浏览器到应用，到数据库，到支付服务商，再返回。追踪能显示时间耗费在哪里、错误出现在哪一环。对于由许多组件构成的系统，追踪往往是找出真正原因最快的工具。

确定哪些值得监控

常见的错误是什么都收集，最后淹没在数据里。应从业务问题出发：哪个流程一旦中断就会立刻造成损失？对网店来说，答案通常是商品搜索、购物车、结账和支付。对 ERP 系统来说，可能是开具发票、库存同步和期末结账。

围绕这些流程，设定几个反映用户体验的指标：结账尝试的成功率是多少、关键页面加载需要多久、有多少发票卡住了。这类以结果为导向的指标比原始技术数字更有用，因为它们直接关联到金钱和顾客满意度。

之后再为经常出问题的组件补充辅助信号。凡有第三方集成的地方，要单独监控其成功率和响应时间，因为当供应商出问题时，您的团队需要清晰的证据来证明原因在自身系统之外。

健康地处理错误

错误无法避免，能够掌控的是处理方式。好的应用会捕获错误，附带足够的上下文记录下来，并向用户展示清晰的提示，而不是空白屏幕或技术代码。看到友好提示并可以重试的用户往往会留下，而看到崩溃页面的用户通常会离开。

错误的归类同样重要。同一原因造成的一千个相同错误，应当显示为一个计数为一千的问题，而不是一千条零散的记录。现代错误追踪工具会自动完成这件事，并显示受影响的用户数、最早引入问题的应用版本，以及修复后是否再次出现。

最后，要区分需要立即处理的错误和只需知晓的错误。用户打错字引起的校验错误属于正常现象，而让订单无声无息消失的错误则是紧急情况。设定恰当的严重程度，才能让团队专注于真正重要的事。

不让团队麻木的告警

过于频繁的告警会让人不再关注。每天收到几十条通知的团队会本能地过滤它们，而当真正的告警到来时，也会被一并忽略。一条简单的规则：每条告警都应该值得把人叫醒，否则它就不该是告警。

好的告警基于用户能感受到的症状，而不是可能的技术原因。成功订单的急剧下降或响应时间的飙升就是明确的症状；处理器使用率偏高则不一定是问题。先从症状出发，再借助辅助数据进行诊断。

每条告警都应附带简短的指引：它意味着什么、有多紧急、下一步去哪里查看、由谁负责。一份描述初步处置步骤的简单文档，通常称为运行手册，能节省宝贵的时间，尤其是当值班人员并非系统的构建者时。

从事故到经验

每一次故障都是学习的机会，前提是复盘时不去寻找替罪羊。问题解决后，写一份简短的总结：发生了什么、何时发现、如何恢复、根本原因是什么、将做哪些改变。不追究个人责任的事后复盘，会让人们愿意尽早报告错误。

同时跟踪一些简单的度量，例如问题平均多久被发现、多久被恢复。逐月改善的数字说明在可观测性上的投入见效了，而停滞的数字则告诉您下一步应把注意力放在哪里。

把发现与产品决策联系起来。如果某个模块不断产生错误，也许是时候重构了；如果某个集成经常很慢，可能需要替代服务商或队列机制。日常运行的数据是确定开发优先级的宝贵输入。

后台任务与集成：悄无声息的问题源头

许多代价最高的故障并不发生在用户的屏幕上，而是在屏幕背后：某个定时任务停止了运行、消息队列不断增长，或与电商平台的同步从昨天起就在悄悄失败。此刻没有顾客投诉，所以问题要等到库存对不上或财务报表出现异常时才浮出水面。

对于这类任务，要关注两件事：它是否按计划运行，以及结果是否合理。心跳信号，即任务每次完成时发出的小消息，可以让系统在心跳不再到达时发出告警。还要关注队列大小和最旧消息的存留时间；持续增长的队列是处理端落后的早期信号。

对于第三方集成，记录每一次外发调用的耗时和结果，并让应用通过受控的重试来容忍临时故障。这样，供应商的短暂中断不会变成数据丢失，团队在与服务商沟通时也有条理清晰的证据。

监控数据的成本、保留期与隐私

监控数据增长得非常快，如果不加管理，监控服务的账单可能会让人意外。要确定每类数据需要保存多久。详细日志也许只需保存几周，而轻量的汇总指标可以保存得久得多，用来观察季节性趋势并做同比。

对于高流量的追踪数据，也可以考虑采样。您不需要存储每一个顺利完成的请求，保留一小部分有代表性的样本，再加上所有失败或缓慢的请求就足够了。这种做法在降低成本的同时，不会牺牲追踪问题的能力。

在隐私方面，要像对待其他业务数据一样对待监控数据。限制谁可以查看日志，按保留期删除数据，并确保服务商满足适用于您客户的数据保护要求。这一习惯也契合许多国家日益严格的个人数据保护义务。

团队文化：可观测性不只是技术问题

再好的工具，如果没有使用它的习惯也毫无用处。健康的团队会把仪表盘纳入每周例会，而不仅仅是应急工具。当结账成功率与产品和销售团队一起讨论时，所有人都会明白技术质量与业务成果直接相关。

建立公平且有文档记录的值班轮换，并设定合理的负荷上限。因虚假告警而不断被吵醒的人会做出糟糕的决定。在告警质量上的投入，就是对守护系统的团队健康的投入。

最后，把监控纳入每个新功能的完成标准。评审时问一个简单的问题，即我们如何知道这个功能在生产环境中运行良好，就能避免应用的某些部分完全没有信号、直到为时已晚才被发现。

选择工具，不被复杂性绊倒

监控工具的市场十分拥挤，很容易被诱惑去购买对小团队来说过于复杂的一体化平台。应优先选择易于安装、界面清晰、支持您所用编程语言和框架，并且价格会随数据增长而保持可预测的工具。

还要问一问以后更换服务商有多容易。遥测方面的开放标准有助于避免被单一供应商绑定，这样您可以更换工具而无需重写全部埋点。对于中型企业，托管服务通常比自己运行全部系统更划算。

决定之前先用真实场景测试：模拟一次事故，看看团队借助该工具能多快找到原因。最好的工具是团队在压力之下真正会用的工具，而不是功能最多的那个。

务实的分阶段计划

1. 01挑选三到五个最重要的业务流程，写下对每个流程而言“健康”意味着什么
2. 02确保应用输出带有严重程度和交易标识的结构化日志
3. 03安装错误追踪工具，对问题归类并显示受影响的用户数
4. 04添加以业务结果为导向的指标，如结账成功率和响应时间
5. 05设置若干基于症状的告警，并指定负责人和处置指南
6. 06安排每月一次对事故与趋势的复盘，然后修复根本原因

这个计划借助现成广泛可用的工具，几周内即可启动，其中包括能减轻运维负担的托管服务。您无需自己搭建监控平台。更重要的是明确衡量什么，以及信号出现时由谁采取行动的纪律。

常见错误

• 没有业务问题就收集所有数据，成本上升而洞察并未增加
• 告警过多，团队习惯了忽略它们
• 日志没有结构、没有交易标识，难以追踪
• 非工作时间没有明确的负责人来响应告警
• 在日志中记录敏感数据却不做脱敏
• 从不复盘事故，导致同样的问题反复出现

示例：几分钟内发现支付问题

回到开头的网店。安装监控之后，结账成功率成为主要指标。在下一次事故中，数值急剧下降后五分钟内就出现了告警，请求追踪立刻显示对支付服务商的调用超时。

团队启用了备用支付通道，并带着清晰的证据联系了服务商。总中断时间不到半小时，而此前是数小时。这项投入很简单，但仅一个晚上的差别就已抵消了搭建它的成本。

结语

可观测性并不是大型科技公司才有的奢侈项目。它是让企业不对自身系统状况两眼一抹黑的务实方法。有了合适的信号，问题能更早被发现，顾客受影响的次数更少，团队也因知道系统正在发生什么而更加从容。

从小处开始：一个重要流程、几个指标和一条有意义的告警。随着系统成长再逐步增加。时常问一句应用内部发生了什么，并用数据来回答，是守护顾客信任成本最低的投资之一。