“在软件质量和可靠性方面，预防总是胜于治疗。”法兰克福歌德大学的数据库和信息系统教授Roberto V. Zicari教授这样说。

但是，商业压力通常意味着软件开发团队必须在代码质量和压力之间进行权衡，以发布新功能。“无论我们做什么，错误总是最终会潜入并部署到现场。那么，当发生错误时您该怎么办？就像我们自己的健康一样，投资预防是正确的事。但是我们将永远需要医院。我们需要治愈，也需要预防。”

基于此前提，他与软件故障重播公司Undo的创始人Greg Law于今年初合着并发行了电子书，题为“加快解决软件缺陷的时间的10条技巧”。基于对构建企业软件系统的高级工程师的采访，以找出出现问题时的工作方式，该书探讨了当错误报告出现时如何测量和减少平均解决时间（MTTR），以及如何降低平均水平。解决错误所需的周期时间。

本文重点介绍了在最近的小组讨论中提出的一些关键点，以启动本书并了解所提出的问题。

但在此之前，这里是一些主要发现的样本：

• “我们总是至少有一个分支机构，也许是两个分支机构，随时可以发布。如果有什么事情发生，我们希望为此做好准备。我们基本上随时准备发布。”  Mentor工程总监Bryan Bowyer（西门子业务）
• “我们对缺陷采取零容忍政策。因此，我们永远不会因积压的问题而积压。这本身就节省了我们很多时间和精力。当缺陷蔓延进来时，我们可以肯定的是，这是我们之前从未见过的新错误，而不是我们之前未曾处理过的间歇性故障[...]。”  瑞萨电子欧洲工程总监Roisin McMahon
• “我们强大的持续交付渠道使我们能够开发解决方案[...]并最大程度地缩短解决问题的平均时间，这是我们用来跟踪DevOps旅程进度的关键指标。”  SAS企业质量副总裁Ken Dickinson。

面板

由Zicari教授主持的小组成员包括：

• Undo创始人/ CTO Greg Law
• Rubrik的前高级工程经理Snehal Khandkar（现为Facebook）
• Salesforce工程部高级总监Haricharan Ramachandra
• SAS企业质量副总裁Ken Dickinson

预防胜于治疗

预防总比治疗好吗？这个问题以两种方式引起了争论。

Dickinson：您假设您可以防止系统可能发生的所有降级。老实说，我不认为你可以。我认为您必须考虑熵，您必须考虑混乱。无论您的测试套件多么漂亮，总会有一些您无法解释的事情。您必须在以下两个方面进行投资：在交付管道中进行可靠的测试以及恢复能力。您能多快解决生产中发现的问题？这就是为什么解决时间很重要的原因。您无法预测所有事情，那么您能恢复多快？

法律：人类真的很擅长编写软件。工程总是要权衡取舍。您可以多早发现错误？您在那方面投资了多少？与游戏或应用程序的投入相比，飞机上的虫子造成的损失是灾难性的（造成数百人丧生，甚至可能使公司付出高昂的代价），而您在游戏或应用程序上的投入却不如预防那么多。

Ramachandra：“每个功能都是燕尾服中的错误”。我们添加的每一行代码都会增加形成新错误的可能性。因此，为失败而努力很重要。造成故障的原因很多，软件故障，网络故障，硬件故障。Google实际上率先提出了为失败而设计的概念。杰夫·迪恩（Jeff Dean）发表了一篇著名的论文，解释了他们假设硬件将出现故障时如何从头开始设计。工程学中的弹性是一个重要的概念。

自动化测试：它们有效吗？

Dickinson：测试自动化非常容易发现错误。但是，这确实可以很好地防止回归，并从我的一些有创造力的人身上腾出时间去发现这些错误，并思考那些自动化无法解决的问题。自动化测试仍然是脚本测试。他们不会发现您没有想到的东西。他们只能验证您已经想到的内容。如果您安装了足够的自动化测试层，它将为您的工作人员腾出一周的时间，以供您进行自动化无法轻松复制和尚未想到的操作。我看到自动化最大的价值在于，当人们将其作为工具使用时，他们会做什么。

指标：您如何在实践中使用它们？

平均鸣叫时间和平均解决时间等术语是什么意思？您如何在实践中使用它们？

Ramachandra：这些指标与生产中发生东西时我们如何处理事情有关。

• 弄清楚发生了什么事需要多长时间–这就是找出原因的时间。从我们承认的那一刻起，我们就找出了问题所在。
• 我们什么时候修复它-这是解决的时候了。
• 在此之前，我们还有时间承认：这是我的问题还是您的问题？有时，团队需要很长时间才能意识到这是某人的问题。

之所以以这种方式进行分解，是为了了解瓶颈所在，并帮助我们围绕这些措施建立流程。如果我们不测量它，我们将无法修复它。

法律：以上内容描述了最新的最佳做法。我的经验是，大多数软件组织，甚至是拥有更多资源的大型公司都还没有达到这个水平。在最基本的层面上（这总是让我有些畏缩）是人们将“开放式缺陷计数”作为他们工作方式的主要KPI。如果我进行了大量测试，并且发现了500个bug，并将它们放入bug跟踪系统中，则我的软件不会变得更糟。我只对丑陋的真相多一点了解。几年前，我什至看到对提交错误的抵制，因为这会使我的KPI变得更糟。如果要测量这种事情，那么测量“封闭率”和系统缺陷的年龄将更加有用。我在一次采访中浮出水面的观点之一是：

自动化测试的问题

Dickinson：我们对自动化测试有隔离政策。每个团队的情况都不尽相同，但是例如，如果一个测试在2周内失败了3次，那就是一个不稳定的测试。该测试被从部署管道中撤出，并且被连续执行-只是无论如何都无法执行-并且该测试必须证明其稳定性，然后才能将其重新引入管道。稳定性很重要。

法律：如果每个人在起飞时都忽略了这些易碎的测试，就好像烟雾报警器一直在鸣响，人们开始无视任何事情。但是您确实需要与他们打交道的策略。这是一个烟雾警报器：“我在代码库中闻到了烟雾”。容易解雇，但代价高昂。我们已经看到客户非常有效地做的一件事就是隔离那些不稳定的测试，然后一次又一次地运行它们，以获取根源原因所需的信息-无论是通过软件故障重播来运行它们，还是通过任何方式表明您有空。您需要将其移出管道，但不要忽略它。

Ramachandra：关于易碎测试-或瞬态故障-我们组织中大多数软件工程师在质量方面面临的挑战之一是将信号与噪声分离。噪音太大，对瞬态故障的检查不够。为什么这些测试会出现片状？这不仅仅是测试代码。可能是应用程序行为或测试环境。通常，我们的测试环境不同于生产环境。我们无法考虑生产中可能发生的所有情况。

Khandkar：自动化测试可保护您免受回归的困扰；他们正在针对您已经知道的错误进行测试。他们没有帮助您发现新的错误。在Rubrik，我们发现在我们的大型系统中引入混乱非常有价值。如果您有大规模的测试设置，请不要执行它来计划。给它添加一些混乱，一些意外的行为，并查看您的系统如何对此做出响应。这对于发现新的错误最有效。

现实与实验室测试

Zicari：我们在实验室中进行了所有测试，并且都可以运行，并且生产中的相同软件可能无法按照我的想法运行。我们中的任何人都是要去医院就诊的患者，并且医院中使用了一些软件来做一些严肃的事情。如果我听说他们发布了该软件，但可能无法正常运行，我会感觉如何？您对像我这样认为“天哪，这太可怕了！”的人有何反应？

狄金森（Dickinson）：故障的成本直接取决于我们从故障中恢复的速度。如果我们引入了一个错误，但是我们可以检测到并解决它（通常在客户未注意到它之前），那么失败的代价就在地下室。因此我们有能力在引入的更改中更具创新性和更具侵略性。如果我们在并非如此的市场中经营业务，那么我们就会回馈积极性。

Khandkar：如果您正在查看医院软件或飞机软件与游戏应用程序中的软件故障，则错误的成本会大不相同。如果我是飞机软件编写者，那么我将进行更多的保护和检查。另一方面，如果我不在这个范围内，也许就不那么多了。

法律：被吓到是对的。你应该害怕。在较早的软件漏洞杀人事件之一中，医院里有一台机器对癌症进行放射治疗。他们对其进行了测试，并且该软件运行良好。一旦投入生产，操作员便开始打孔以控制剂量，操作员变得越有经验就越快。他们开始做得太快了，有一些整数溢出，病人被炸死并被设备杀死，向病人发送了一百倍的辐射。事实证明，测试环境与实际情况有所不同。

“世界上绝大多数软件并没有真正被任何人理解。”