GitHub合并超时的3%、不足1%和约1%能相加吗

先分清每次数字回答的范围

北京时间11月14日00:12，GitHub说明已采取缓解措施：问题起初影响约3%的请求，当时已经降到不足1%。00:52的后续进展则表示，仍在调查和监控约1%的合并请求超时。两条说明是在不同恢复阶段发布，不能合并为同一时刻的三个测量结果。

“约”保留了数字的近似含义，“不足”则表达上限关系。把不足1%写成精确的0.99%，或者把约1%写成恰好1.000%，都会增加官方没有给出的精度。

这些数值不能推算哪些数量

请求不是用户。一名用户可能发出多次请求，一个仓库也可能有多个协作者同时操作。只有请求层面的比例，不能直接换算受影响用户数、仓库数或PR总数；也不能据此判断某个团队的一百次操作恰好有一次失败。

两条进展没有披露统计分母、完整观测窗口和各租户分布。因此，不能用它们计算全程失败请求的绝对数量，也不能把这场事故的影响比例当成GitHub日常服务水平。

为什么不能把3%和1%相加

它们描述的是恢复过程中不同阶段的情况，而不是已经证明互不重叠的三组请求。相加会把时间变化错误地当成多个独立样本，得到没有官方依据的累计影响比例。

同样，不足1%和约1%之间的表述变化，也不足以单独证明事故再次显著恶化。若没有同口径、同一统计窗口及更精确的原始数据，不能把近似措辞强行转成增长率。

数字改善为何还需要监控

比例下降说明缓解工作有进展，并不等于所有合并请求都已正常。GitHub在北京时间01:28将降级标记为已缓解并进入监控；01:46继续观察合并请求稳定性，02:29才标记事故已解决。

这个顺序说明，缓解、监控与解决是不同的沟通状态。不能把早期比例下降的那条消息提前改成完全恢复，也不能在已经解决后仍把旧比例描述为当前持续故障。

比例和某次合并结果仍要分开

总体请求影响比例不能告诉调用方某一次超时操作是否已发生合并。超时也不能直接当成“确定未合并”的回执。平台事件恢复、具体PR状态及下游检查结果，各自回答不同的问题。

此外，这次合并超时的详细根因分析仍待后续公布。另一场GitHub事故的Actions漏触发比例，不能与这里的合并请求超时比例拼接使用，更不能据此要求所有工作流统一补跑。