IT 工程项目领导者最常见的假设之一，是报告的事故数量不断增加就意味着系统可靠性正在下降。然而，Great Circle 最近的一篇文章提出，实际情况往往恰恰相反：事故数量增加，反而可能意味着组织的事故管理文化正在改善。随着团队不断投入资源完善流程、工具、培训和运维规范，他们会更愿意正式地将那些过去大概只会被悄悄处理、甚至被隐瞒的事故报告上去。这样带来的结果就是组织对运营问题的可见性提高了，但却不一定意味着系统的健康状况恶化。
这篇文章对业内广泛采用事故数量作为关键绩效指标（KPI）的做法提出了质疑。文章认为，事故数量衡量的其实是组织发现并处理运营问题的意愿，而不是系统本身的可靠性。成熟的事故管理文化会鼓励工程师尽早报告事故，让适当的利益相关者参与进来，并开展结构化的事故复盘。虽然这通常会导致提交上去的事故数量在初期有所增加，但同时也创造了更多学习、改进流程以及预防未来更大规模中断的机会。
这一现象在其他工程领域也十分常见。加强漏洞管理后，组织往往会发现更多安全问题，但这并不意味着系统突然变得更不安全，而是因为组织检测安全弱点的能力提高了。同样，引入更好的可观测性通常会带来更多告警消息，而更完善的测试则会在软件进入生产环境之前发现更多缺陷。在这些情况下，更好的度量体系暴露的是原本不可见的既有问题，而不是制造了新的问题。
事故管理遵循着同样的规律。过去，工程师可能会默默解决那些难搞的 Bug，或悄悄处理服务降级问题；如今，他们可能会选择将事故正式报告，从而触发协同响应流程、文档记录和事后复盘。虽然仪表盘上的事故数量有所上涨，但组织实际上是通过让运营知识变得可见且可复用，从而提高了自身的韧性。
这一观点也与可靠性工程领域更广泛的发展方向一致。现代 SRE 实践正在逐步摆脱简单的运营指标，转而关注能够反映用户影响、恢复效率和组织学习能力的指标。与其问“发生了多少起事故”，不如进一步追问：“用户在事故发生多久后受到影响？”“服务的恢复有多快？”“是否找到了根因？”以及“类似故障发生的频率是否正在下降？”
Sygnia 近期发布的相关指导也提出，许多传统事故指标，包括原始事故数量、工单数量，甚至单独观察时的平均响应时间（MTTR），都可能营造出虚假的信心，因为这些指标衡量的是运营活动，而不是组织的应对准备程度。相较之下，该指导建议关注遏制措施的有效性、升级处理的质量、事故后的改进，以及事故响应流程的成熟度等指标。
同样，围绕 Service Level Objectives (SLOs) 构建的现代可靠性实践，也越来越强调以用户为中心的指标，例如错误预算消耗（error budget burn）、SLI 降级程度和用户影响，而不是以基础设施为中心的统计数据。可靠性平台认为，理解用户如何感知故障，比单纯统计事故数量或只衡量基础设施正常运行时间，更能准确反映服务健康状况。
Great Circle 最重要的观点或许并非技术层面的，而是文化层面的。组织不应该为了让看板上的指标更好看，就打压上报事故的行为。如果工程师认为自己会因为事故数量过高而受到批评，那他们可能会推迟事故的上报、试图独自解决问题，或者直到当前的问题严重恶化后才进一步上报。这些行为会降低组织的可见性，而恰恰是在这种最需要快速协作的时候，组织最不应该失去这种可见性。
相反，健康的 IT 工程组织会对提升透明度的行为予以奖励。这样的组织能认识到，事故的上报并不是承认失败，而是结构化学习过程的开始。通过鼓励尽早报告、无责协作和持续改进，组织可以让运营知识随着时间积累，而不是将这些知识局限在个别事故处理人员手中。
更为广泛的寓意是指标应该反映组织真正关心的结果。事故数量下降可能意味着可靠性提高，但同样可能意味着事故漏报、分类标准不一致，或者事故管理文化正在被削弱。反过来，事故报告数量暂时的增加，也可能代表运营实践更加健康，组织对自身问题的认知更加充分。
查看英文原文：More Incidents Don't Necessarily Mean Less Reliability
