在现代软件那广阔且互联的世界中，一次点击就能触发银行、旅游和通信系统的一系列连锁反应，这使得质量问题不仅仅关乎发现错误。它关乎理解当这些错误未被修复时，它们意味着什么。每个大型软件组织都维护着一份冗长的已知问题清单，这些问题通常被称为缺陷或漏洞（bugs），并被记录、分类并分配给相应的团队进行修复。几十年来，管理这些清单的标准方法一直依赖于两个简单的标签：严重程度（severity），描述问题的严重程度；以及优先级（priority），规定修复的快慢。这套系统在组织工作方面表现良好，但往往无法回答公司在发布新版本前面临的最关键问题：带着这些特定的问题，向公众发布此软件是否安全？难点在于，一个在屏幕上看起来微不足道的问题，可能会在现实世界中引发一场无声且灾难性的故障，而一个显眼的错误可能很容易被人类操作员绕过。当单个客户旅程跨越数十个不同的计算机系统时，未解决问题的风险就不再仅仅是一个技术问题，而变成了一个复杂的组织决策，即谁被允许接受这种风险，以及在何种条件下接受。

研究人员杰斯米特·洛佩斯（Jesmith Lopes）在美国一家大型电信公司内部调查了这一确切的困境，在该环境下，每年都会发生数千次软件变更。该组织已经拥有了追踪每一个缺陷的先进工具，却仍难以将这些记录转化为关于发布就绪状态的清晰、一致的决策。这项研究借鉴了该公司的内部记录及其从业者的经验，揭示了在追踪问题与治理其所带来的风险之间存在的差距，正是许多大型组织失足之处。研究人员发现，将未解决的缺陷仅仅视为待关闭的简单工作项是不够的。相反，这些问题必须被视为需要特定治理流程的运营风险单元。这一过程涉及超越初始严重程度标签，去追问一系列更深层的问题：实际受影响的是谁？如果问题发生，是否有可靠的修复方法？该故障能否被快速检测到，还是会隐藏起来并在下游造成破坏？最重要的是，谁有权决定该风险是否可以接受，从而继续进行发布？

为了解决这个问题，该研究提出了一个名为“缺陷运营风险框架”（Defruct Operational Risk Framework）的结构化框架。该方法通过一个新的决策层来补充传统的追踪系统，该层会对未解决的缺陷从八个特定维度进行评估。这些维度包括对客户的影响、涉及交易的关键性、可用变通方案（workarounds）的有效性、在现实条件下发生的可能性，以及软件上线后检测故障的能力。它还考虑了缺陷开放了多久、是否以前发生过，以及负责修复、协调修复以及接受风险的人员是否身份明确。通过应用这些问题，组织可以从对未解决缺陷的模糊担忧，转向对残余风险的精确理解。该框架将问题区分为三个关注级别：可以由标准工程团队处理的常规问题；需要跨团队审查和记录缓解措施的提升级问题；以及要求在任何发布前必须由指定的风险所有者做出明确决定的关键级问题。

研究强调了技术所有权与风险所有权之间的关键区别。在许多大型公司中，一个团队可能负责编写修复漏洞的代码，但他们并没有权力决定是否可以在没有该修复的情况下发布软件。相反，业务领导可能拥有接受发布风险的权力，但缺乏理解其影响的技术知识。拟议的治理模型将这些角色分离，确保技术所有者负责诊断和修复代码，协调所有者负责推动跨团队的流程，而风险所有者则对剩余危险是否可以接受做出最终裁定。这种分离防止了常见的情景，即由于没有人知道最终由谁负责决策，导致缺陷一直悬而未决。研究还重新定义了公司如何升级问题。升级不再是仅仅通过增加会议来提高可见性，而是成为一种强制执行特定决策的机制，例如加速修复、批准变通方案、从发布版本中移除某项功能，或完全延迟发布。

该方法的实际价值通过这家电信企业的绩效记录得到了验证。在这些结构化治理实践成熟期间，该组织的运营稳定性显著提升。报告显示，泄露到生产环境中的缺陷数量从83个降至20个。与生产问题相关的支持工单量从71件下降到31件，关键或阻断性缺陷的数量下降了约82%。团队还在保持严格遵守服务水平协议的同时，高质量地解决了超过4,500个追踪系统中的问题，并处理了超过42,000个支持工单。这些数字表明，该治理模型不仅仅是增加了文书工作，它从根本上改变了组织理解和管理风险的方式。数据支持了这样一个观点：当一个组织将未解决的缺陷视为明确的风险决策而非仅仅是开放的工单时，它可以实现更高水平的可靠性，而不必非要在发布前消除每一个错误。

研究通过两个对比鲜明的场景阐述了这一转变。在第一种情况下，一个缺陷看起来程度中等，因为它并未阻碍主用户界面的运行。然而，治理流程揭示了该错误会导致后台发生无声失败，影响关键交易并为支持团队带来隐形负担。由于该故障难以检测且没有可靠的变通方案，因此风险被提升，需要做出特定决策，即是修复它、增加监控，还是在发布前正式接受该风险。在第二个案例中，一个缺陷最初因明显破坏了某项交易而被标记为高严重度。然而，治理审查发现，该问题易于察觉，具有可靠的手动变通方案，且影响的用户数量在可控范围内。在这种情况下，只要变通方案到位且风险所有者批准了决策，该风险被视为对于发布是可接受的。这些例子表明，仅凭严重程度标签往往无法准确预测现实世界的危险；真正的风险取决于故障的上下文以及组织管理它的能力。

最终，论文认为，大规模软件交付中的缺陷管理不仅是一个技术工作流，更是一个治理问题。工具可以记录漏洞的存在，但它们无法自动解决是否存在该漏洞是否安全的歧义。解决方案在于建立一个纪律严明的决策层，迫使组织面对其未解决问题的现实。通过对风险进行明确分类、分配清晰的所有权，并要求对每一个未解决的缺陷做出记录在案的决策，公司可以将发布过程从一场赌博转变为一次经过计算的决策。研究表明，对于系统复杂且相互关联、且失败成本远超单一应用程序的大型企业来说，这种方法尤为至关重要。虽然这项研究并不声称已经彻底解决了软件缺陷问题，但它提供了一种经过验证的、可重复的方法来治理残余风险，将发布就绪状态的不确定性转变为一个清晰、可控的过程。