影响了多少人，这个数有三种算法

结论先行：故障通报里那句「影响约若干用户」，背后至少有三种不同的算法：失败的请求数、实际受影响的独立用户数、受影响的业务笔数。三者口径不同，同一场故障算出来的结论能差出好几倍。这不是谁在夸大，而是三个数本来就回答三个不同的问题。可行的做法是把口径提前定下来，规定对外只说其中一个，其余两个作为内部参考——否则每一次通报都要重新解释一遍数字为什么对不上。

本文只谈「影响面」这个数怎么算、对谁说哪个数，不谈故障怎么定位根因，也不谈告警怎么收敛与分级。

三种口径各自回答什么

先把三个数摆清楚，它们不是同一个东西的不同精度，而是三个不同的问题。

三行的差别在于计量单位：次、人、笔。用哪一个，取决于这句话是讲给谁听的。

对技术团队，请求数是合适的，因为它直接对应排查对象。对业务负责人，笔数是合适的，因为它对应结算与考核。对外部，通常只有「用户数」讲得通，但恰恰是这个最容易被算错。

为什么「用户数」最容易算错

独立用户数看起来是最中性的一个数，实际上它有三处结构性的坑。

坑一：同一个人的多个标识。一个用户可能在应用、小程序、网页三处都登录过，三处的标识不同。故障时三处都失败，按标识去重会算成三个人。要不要合并成一个人，取决于是否有统一的账号体系——很多单位没有。

坑二：故障边界不是一条直线。故障往往不是「全停」，而是某个渠道、某个地区、某个版本的用户受影响。此时的分母不是全部用户，而是「这段时间内本来会访问的用户」。用全量用户做分母，会得出一个看起来很小的比例；用实际访问量做分母，比例可能高得离谱。

坑三：重试把人数和次数拉偏。用户点不开会再点。一次故障里同一个人可能产生十次失败，而十个用户各失败一次，在请求数上看起来差不多。所以请求数不能直接除出一个「人均失败次数」再反推人数，这个除法在故障场景里不成立。

三处坑都不是工具能自动绕开的，它们是口径问题，必须在通报之前定。

先把口径写进制度，再让它出门

一个可用的做法是：在故障分级与通报制度里写死一句话——对外通报只说「受影响用户数」，并明确它的定义（独立账号、按统一账号去重、统计窗口与故障时段一致）。另外两个数不进对外通报，只出现在内部复盘。

这条规矩的价值不在于哪个数更准确，而在于「每次说的都是同一个数」。同一场故障，头一次通报说几百人、复盘时变成几千人，无论哪个是对的，对外都会变成一个信任问题。

配套要有一条补充规则：如果通报时口径还没算准，就写区间并说明这是估算，不要写一个精确的整数。一个「约若干」的区间比一个精确到个位的数字更可信，因为后者暗示了一种并不存在的确信。

影响面要落到业务上，不能停在设备上

另一个常见问题不是算错，而是算得太浅。

很多通报写的是「影响若干台主机、若干条链路」。这些是拓扑信息，不是影响面。业务负责人看到这句话，无法回答「我的业务受不受影响、影响多久」。

可行的要求是：影响面结论必须落在业务名称与量级上，格式大致是「这套故障影响到哪几个业务、每个业务受影响的时间窗口、窗口内未成功的量级」。三样东西都不在告警系统里，而在资产与业务的对应关系里。

这也是为什么有些平台的影响面评估没人信——它只能给出设备清单，给不出业务名称。做到这一步需要先把资产业务关系建起来，这是台账工作，不是监测工具的能力问题。

一个容易被忽略的时间因素

影响面的三个数都带时间。同一场故障，持续十分钟和持续两小时，结论完全不同，而故障时段的起止往往有争议。

争议通常出在起点。从「最早那条错误记录」算，还是从「告警触发」算，还是从「客户开始投诉」算？三个起点能差出十几分钟，而这十几分钟在高峰时段可能占受影响量的一大半。

可行的做法是统一以「最早的一条失败记录」作为起点，并把这个规则写进通报模板。理由是它是客观的、可复核的，不依赖任何人当时是否在场。

终点同理，用「最后一条失败记录之后恢复到稳定成功的时间点」，而不是「有人宣布恢复的时间点」。两者之间往往还差一段观察期。

事后自证也靠这三个数

影响面不只用于对当下的说明，它还是事后自证的依据。

当客户或监管方要求说明「这次故障到底影响了什么」，能拿出来的东西通常有三样：故障时段、受影响范围的业务清单、以及未成功动作的处理去向（补发、重试成功、人工处理、确认放弃）。

第三样最容易被漏掉，也最有用。它把「影响」变成了一个已闭环的账：哪些已经补回来了、哪些确实损失了。没有这一项，影响面只是一个数字，无法结案。

落地清单

• 在制度里定死三个口径的定义：请求数、独立用户数、业务笔数。
• 对外只说「独立用户数」，并写明去重规则与统计窗口；另两个只进内部复盘。
• 口径未算准时写区间并说明是估算，不写精确整数。
• 影响面结论必须落到业务名称与时间窗口，不能只给设备清单。
• 先把资产与业务的对应关系建起来，否则影响面只能算到设备层。
• 故障时段统一起点与终点：最早一条失败记录，到最后一条失败记录之后的稳定成功点。
• 事后自证备三样：时段、业务清单、未成功动作的处理去向。

边界与前提

三点说明。其一，文中所述三种口径属可观测性建设中的一般性梳理，具体定义须结合所接数据源、账号体系与业务计量方式确定。其二，用户去重与业务笔数的统计能力取决于现有采集与建模范围，落地前应以实际数据验证为准。其三，涉及对外通报与监管报送的口径与措辞，须按内部制度与合同约定执行，本文不构成对具体事件通报的建议。

深圳市奇摩计算机有限公司是一家 IT 解决方案服务商，在监测类项目里会把影响面的三个口径在建设阶段就写进交付文档，避免上线后再解释数字对不上。预约咨询，可以先从现有通报模板里的口径问起。