企业网站与应用的监控和可用性:在顾客抱怨之前就知道出了问题

许多企业主是从顾客那里才得知自己的网站或应用出了问题。一条消息进来,问为什么付款页面打不开,或者员工报告收银系统从早上起就一直很慢。到那时损失已经在发生:订单流失,队伍变长,信任变薄。问题不在于系统会不会出问题,而在于你多快得知,以及你为应对做了多少准备。

监控是持续观察系统健康状况的做法,以便在顾客抱怨之前发现问题。许多人以为监控只属于拥有完整技术团队的大公司。实际上,中小企业也能以合理的成本搭建基础监控,而且往往受益更明显,因为没有大团队值守。

本文介绍如何为企业网站和应用设计切实可行的监控。我们讨论需要监控什么、检查类型、不会造成疲劳的告警、状态页、错误跟踪、事件处理,以及让系统保持健康的习惯。我们不使用杜撰的可用率百分比;提供的是适用于各种规模系统的原则和检查清单。

摘要

• 从用户的角度监控:登录、搜索和付款等重要流程是否真的能跑通
• 从几项最怕出故障的事情开始做简单检查,而不是什么都监控
• 让告警少而有意义,并有明确的接收人和处置动作
• 记录错误和事件轨迹,使原因可以追查而不是猜测
• 准备简单的事件处理流程,并从每次事件中学习以避免重演

为什么监控不是奢侈品

任何依赖服务器、网络、第三方服务和不断变化的代码的系统,都难免偶尔出现故障。安全证书过期,存储空间已满,支付服务商出了问题,或者最新的更新带有漏过测试的错误。这些都很正常。不正常的是几个小时后才发现。

故障的影响很难精确衡量,因为它取决于发生的时段、业务类型和持续时间。但逻辑很简单:网店每有一分钟不能接单,就是一笔可能丢失的销售;内部应用每宕机一分钟,就是浪费的员工时间。监控缩短事件与响应之间的间隔,而这个间隔决定了损失的大小。

其他好处不那么显眼,但很真实。监控数据能显示规律:每个月底变慢的页面,每隔几天内存耗尽的服务器,或经常失败的第三方服务。这样的规律使得永久修复成为可能,而不是一次又一次地扑灭同样的火。

究竟需要监控什么

最大的诱惑是一次监控所有东西,结果淹没在没人看的图表和告警里。从一个简单的问题开始:什么东西一旦宕机损失最大?对网店来说,答案通常是首页、商品页、购物车和付款。对内部应用来说,可能是登录、交易记录和每日报表。

由此出发,在几个层面进行监控。第一层是可用性:服务是否可访问并正确响应。第二层是速度:页面和重要流程完成得有多快,因为极慢的系统和宕机的系统一样糟糕。第三层是基础设施健康:处理器使用率、内存、存储空间和数据库连接。第四层是应用错误:真实用户遇到的异常和故障。

1. 01可用性:主要页面和服务端点以正确的状态响应
2. 02速度:页面加载时间和重要流程的处理时间
3. 03基础设施:处理器、内存、存储空间和数据库连接
4. 04应用错误:用户遇到的故障和失败的定时任务
5. 05依赖项:付款、邮件发送及系统使用的其他第三方服务
6. 06基础安全:证书有效期、域名和可疑的登录尝试

第三方监控常被遗忘。许多事件来自你并不拥有的服务,比如支付服务商、地图服务或消息发送服务。你无法修复它们,但可以检测并准备应对,例如向顾客显示诚实的提示,或提供备用的付款方式。

来自外部和内部的检查

看待系统有两种方式。外部检查模仿用户:某项服务定期从不同位置访问你的页面,确认结果正确。它的优点是能看到用户所见,包括从服务器内部看不到的网络、DNS 和证书问题。缺点是它不知道原因。

内部检查观察系统自身的状态:服务器负载、任务队列、数据库大小和日志。它帮助解释事情为什么发生,甚至能在发生之前预测,例如当存储空间不断缩小时。两者结合最强大:外部检查告诉你出了问题,内部检查帮助找出原因。

检查流程,而不仅是页面

首页能打开并不能证明店铺能卖货。系统常常在更深处出故障:搜索没有结果,加入购物车按钮失效,或付款拒绝所有交易。流程检查,也叫合成检查,会运行登录、搜索商品、加入购物车等简单场景,并确认每一步都成功。凡涉及资金的部分,使用支付服务商的测试模式,这样不会产生真实交易。

以合理的间隔运行流程检查,例如最重要的流程每隔几分钟一次,其他的低频一些。太频繁会给系统增加负担并产生不需要的数据,太稀疏则使发现太迟。确保检查不会污染真实数据,例如使用明确标记的测试账户。

不会造成疲劳的告警

告警是监控与人相遇的地方,也是许多系统失败的地方。告警太多会让人忽略它们,于是真正重要的被漏掉。原则很简单:每条告警都应该值得叫醒某个人,并有明确的处置动作。

• 仅对影响用户或即将影响用户的情况发出告警
• 设置合理的阈值和持续时间条件,例如连续多次失败,避免瞬时波动触发警报
• 区分严重程度:必须立即处理的、明早再看即可的,以及仅记录的
• 发送到真正有人看的渠道,并确定主要接收人和备用人
• 在消息中带上背景:什么失败了、从什么时候开始,以及处理指南的链接
• 定期检查告警,删除或修正经常触发却无需行动的告警

还要准备升级机制。如果第一接收人在规定时间内没有响应,告警就转交给下一个人。对于不能全天候值守的小团队,要诚实地确定自己能承诺的服务时段,并告知相关方。现实的承诺胜过一份从未真正执行的值班表。

记录错误与事件轨迹

知道有东西坏了只是一半的工作,另一半是知道为什么。这需要记录:捕捉重要事件的应用日志,以及连同上下文一起收集异常的错误跟踪,上下文包括打开的页面、应用版本以及用户出错前的操作步骤。

以结构化且一致的方式记录。杂乱文本行形式的日志难以搜索,而带有时间、严重程度、模块和请求编号等明确字段的日志,可以快速筛选。贯穿每一层的同一个请求编号,有助于把一笔交易从用户屏幕一直追踪到数据库。

保护隐私。不要在日志中记录密码、银行卡号或不必要的个人数据,因为日志常被许多人阅读并长期保存。设定合理的日志保留期,并限制可以访问的人。请核查当前适用的个人数据保护规定,确保你的日志做法合规。

从用户一侧监控速度

服务器健康并不保证体验快。手机上网络慢、图片过大或第三方脚本过重的用户,即使服务器没有问题,也可能觉得页面难以忍受。所以除了服务器指标,还要关注真实的用户体验:主要内容出现得多快,页面多快可用,以及布局有多稳定。

尽可能从真实用户收集数据,因为真实环境千差万别。按设备类型、网络和页面分组,看出哪部分有问题。更新之后突然出现变化,是新改动造成变慢的有力线索,这些数据使回滚的决定更容易。

状态页与故障期间的沟通

故障发生时,你如何沟通决定了还剩多少信任。顾客对正在修复并不断更新进展的系统,比对沉默而不解释的系统宽容得多。一个简单的状态页,托管在与主系统分开的地方,这样主系统宕机时仍能打开,显示当前状态和故障历史。

用诚实而不过分技术化的语言撰写更新:什么受到了影响,正在做什么,下一次更新何时到来。不要承诺你无法确定的恢复时间。恢复之后,分享简短总结,说明发生了什么,以及做了哪些改动以避免重演。

也为受影响的部分在应用或网站中准备临时提示。看到关于付款出现问题及可用替代方案的清晰提示的顾客,比遇到失败却没有任何解释的顾客更有耐心。在需要之前先练习撰写这类消息,可以在压力之下节省大量时间。

冷静处理事件

系统出问题时,恐慌是敌人。简单且事先商定的事件流程,让团队有序行动。它归结为几件事:谁牵头处置,谁与顾客沟通,如何做出决定,以及事件记录保存在哪里。

1. 01确认问题并评估影响:谁和什么受到了影响
2. 02指定一人牵头,一人负责沟通
3. 03先恢复服务,例如回滚最近一次更新,再去找根本原因
4. 04趁记忆犹新,记录时间线:时间、行动和结果
5. 05向受影响的各方定期提供更新
6. 06恢复之后,不追究个人责任地复盘,并制定具体的改进措施

事后复盘是最有价值的习惯之一。其目的不是责怪人,而是理解系统和流程是如何允许错误发生的。成果是一份具体的改进清单,比如补上缺失的检查、改进指南,或改变部署更新的方式。没有它,同样的事件还会再来。

安全的更新与维护

大多数故障并非来自外部,而是来自我们自己做出的改动。代码更新、配置变更和数据库迁移是非常常见的原因。因此监控必须与部署流程相连:在图表上标记更新的时间,使错误激增能立即与某次改动关联起来。

尽可能逐步推出更新,例如先面向一部分用户,健康的话再扩大范围。准备一种快速且经过测试的回滚方法。避免在最忙的时段或周末前无人值守时部署大的改动。把维护安排在清闲时段,并提前公告。

也要与备份策略联系起来。好的监控还会检查备份是否在运行,更重要的是,备份结果是否真的能恢复。从未测试过的备份只是一个假设,而不是保证。定期测试恢复,并记录所需时间。

按规模选择工具

没有一套工具适合所有人。对小企业来说,简单的组合往往就够了:外部可用性检查服务、应用的错误跟踪,以及托管服务商提供的基础服务器指标。随着增长,再添加集中式日志、应用性能监控和更完整的流程检查。

• 选择团队真正能运行和读懂的工具,而不是功能最多的
• 留意可能随数据量膨胀的成本,尤其是日志和指标
• 确保告警能发送到团队日常使用的渠道
• 检查监控数据存放在哪里,以及谁可以访问
• 避免单点依赖:监控服务不应运行在被监控的同一基础设施上
• 把监控配置文档化,不要依赖某一个人的记忆

如果你的企业使用供应商来构建和维护系统,请问清楚监控了什么、告警如何发送,以及非工作时间由谁响应。这些应当写进维护协议,包括承诺的响应时间,而不只是口头说说。

设定切合实际的目标

许多企业想要永不宕机的系统,但这种要求代价高昂,而且很少必要。更有用的是设定与业务影响相称的目标。每天营业的店铺收银系统可能需要高可用性,以及断网时的备用工作方式,而内部报表门户可能可以容忍非工作时间的短暂中断。

用所有人都能理解的语言陈述目标:系统宕机多久会影响业务,以及可以丢失多少数据。这两个问题决定了监控、备份和架构策略。目标越严格,成本和复杂度越高,所以每次提升都必须与所保护的价值相称。

应避免的常见错误

• 只检查首页,导致付款或搜索的故障未被发现
• 发送太多告警,以至于全部被忽略
• 把状态页托管在被监控的同一个系统上
• 在没有访问限制和保留期的情况下记录敏感数据
• 从不测试备份恢复
• 跳过事后复盘,导致根本原因从未被修复

本周就能开始的第一步

1. 01列出三到五个一旦宕机损失最大的流程,例如登录、搜索、购物车和付款
2. 02为这些流程设置外部可用性检查,并监控证书和域名到期时间
3. 03在应用上安装错误跟踪,并确定谁接收其告警
4. 04写一页事件流程:谁牵头,谁沟通,以及最初的恢复步骤
5. 05安排一次备份恢复测试并记录结果

结语

监控不是为了避免所有故障,而是为了更早知道、更好理解、更从容地恢复。从用户视角出发的检查、有意义的告警、整齐的记录、诚实的沟通,以及从每次事件中学习的习惯,让系统随着时间越来越稳固。

从一旦宕机损失最大的部分开始做小,再随业务增长而扩展。这样你就不必再依赖顾客来告诉你出了问题。