加快软件缺陷解决速度的十大技巧

“在软件质量和可靠性方面,预防总是胜于治疗。”数据管理资源门户网站编辑Roberto V. Zicari教授这样说 ODBMS.org 法兰克福歌德大学数据库和信息系统教授。

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

在此前提下,他与软件故障重播公司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

预防胜于治疗

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

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

法律:人类真的很擅长编写软件。工程总是要权衡取舍。您可以多早发现错误?您在那方面投资了多少?与游戏或应用程序的投入相比,飞机上的虫子造成的损失是灾难性的(可能会挽救数百人的生命,甚至可能使公司蒙受损失)。

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

自动化测试:它们有效吗?

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

指标:您如何在实践中使用它们?

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

拉马尚德拉:这些指标与生产中发生东西时我们如何处理事情有关。

  • 弄清楚正在发生什么事–这是产生根本原因的时间。从我们承认问题到发现问题的根源,我们一直在找出问题所在。
  • 我们什么时候修复–那是解决的时间。
  • 在此之前,我们还有时间承认:这是我的问题还是您的问题?有时,团队需要很长时间才能意识到这是某人的问题。

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

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

自动化测试的问题

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

法律:如果所有人在离开时都忽略了这些易碎的测试,就好像烟雾报警器一直在鸣响,人们开始无视一切。但是您确实需要与他们打交道的策略。这是一个烟雾警报器:“我在代码库中闻到了烟雾”。容易解雇,但代价高昂。我们看到客户做得非常有效的一件事是隔离那些不稳定的测试,然后一次又一次地运行它们,以获取导致根本原因所需的信息–无论是正在使用软件故障重播进行记录还是以任何方式使您运行有空。您需要将其移出管道,但不要忽略它。

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

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

现实与实验室测试

齐卡里:我们在实验室中进行了所有测试,并且都可以运行,并且生产中的相同软件可能无法按照我的想法运行。我们当中任何一个要去医院就诊的病人’在医院中用于做严重事情的软件。如果我听说他们发布了该软件,但可能无法按预期运行,我会感觉如何?您对像我这样认为“天哪,这太可怕了!”的人有何反应?

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

坎德卡:如果您正在查看医院软件或飞机软件与游戏应用软件之间的故障,则错误的成本会大不相同。如果我是飞机软件编写者,我将进行更多的保护和检查;另一方面,也许我不会那么多。

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

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

的确。

整整一个小时的小组讨论可以是 在这里查看.

电子书, 加快解决软件缺陷的10条技巧, 在这里访问.


相关内容:

要获得更多嵌入式产品, 订阅嵌入式’的每周电子邮件通讯.

发表评论

该网站使用Akismet减少垃圾邮件。 了解如何处理您的评论数据.