西门子医疗如何同步提高软件交付的速度和稳定性

作者 | Vladyslav Ukis

译者 | 冬雨

策划 | 丁晓昀

在本文中，我们关注的是西门子医疗数字健康的软件交付过程。这一过程需要遵循医疗行业的严格规定。我们展示了我们将这一过程向速度和稳定转型的历程。这两项指标在转型过程中同时得到改善，证实了《加速》一书中的研究成果。

领域

西门子医疗是一家医疗技术公司，致力于推动创新，帮助人类活得更加健康长寿。在西门子医疗内部，团队协作的数字健康平台是医疗机构数字化转型的促成者，目标是将数据转化为成本节约和更好的护理。

该平台为操作、临床和共享决策支持提供了易于操作的解决方案。它为将数字解决方案集成到临床常规提供了一个安全且符合法规的环境，促进了跨部门和跨机构的互操作性。此外，该平台还提供了用于数据驱动决策支持的途径和人工智能应用程序，它们出自于西门子医疗和策展合作伙伴。

迄今为止，已有来自 75 个国家的 6,500 多家机构和 32,000 个系统连接到该平台。这使得可以在各个机构访问超过 3000 万的患者记录。该平台对 SaaS 和 PaaS 合作伙伴都是开放的。SaaS 合作伙伴通过团队合作数字市场提供他们现有的应用程序。PaaS 合作伙伴利用团队协作 API 开发新的应用程序和服务。

这个团队合作平台是基于云的。它构建在微软 Azure 之上，在设计和默认情况下都具有隐私性和安全性。软件交付的速度和稳定性是团队协作的核心。2015 年，速度和稳定性都不够。有了这一认识，在同一年开始了软件交付过程的转型。转型的目标是使软件交付更快、更稳定。为了实现这一目标，多年来实施了大量的人员、流程、技术和法规变革。

转型路线图

作为转型过程的一部分，引入了大量的新方法：HDD、BDD、TDD、用户故事映射、结对编程、独立的部署管道、测试 DSL、SRE 和看板。在 InfoQ 之前的一篇文章“西门子医疗在团队协作中采用持续交付”中对此进行了详细描述。方法的采用和“粘性”因团队而异。下图描绘了转型随着时间推移的主要里程碑。

2015 年，改革的必要性已经变得显而易见。作为企业中的一个新兴平台，我们基于全企业范围的硬件和软件产品的法规性质量管理体系 (QMS) 交付，我们面临着无法满足的产品速度和稳定性需求的挑战。

当时，产品所有者正在打入数字服务市场，这对公司来说是全新的。对于哪些服务会与用户产生共鸣，用户愿意为哪些服务付费，以及哪些功能集最有价值，我们一无所知。

因此，将想法转化为软件的快速实验需求很高。每两周或每个月发布一次软件，并立即按需进行热修复，将受到产品所有者的欢迎。这与我们所要做的软件交付相去甚远。很明显，质量管理体系的变化需要监管部门的大量专业知识。我们开始了一项使质量管理体系更加精简的长期计划。在研发内部，我们更加重视自动化测试了。

2016 年，我们发起了 BDD 运动。在自动化测试改进时将它作为一部分完成了。它对需求规范、自动化测试、测试实现、测试报告和所有角色测试结果的可理解性都有广泛的影响。

在过去，每个需求都很大，BDD 的引入迫使产品所有者将需求分解成很小的用户故事。每个用户故事开始被整个团队进一步分解为一组小型 BDD 场景 (使用 Given / When / Then 语句的示例说明)。

团队欢迎这些更改，因为它们解决了长期开发人员的担忧，即需求太大、太庞大，无法在短时间内实现。较小的需求促成较小的自动化测试。较小的自动化测试带来更稳定的自动化。尽管有这些重大和必要的改进，但总体上的转型速度相当缓慢。在 QMS 变更方面，我们做了一个分析，即在仍然保持所需的法规遵从性的同时，如何减少角色、可交付物、活动和工作流中断的数量。

2017 年，我们引进了持续交付顾问，加快转型。来自 Continuous Delivery Ltd. 的 Dave Farley 为管理人员、产品所有者、架构师和开发人员提供战略咨询以及培训。来自 Equal Experts Ltd. 的许多顾问与我们在各地的产品所有者、建筑师和开发人员一起工作，使用许多新方法和新技术共同交付功能。

具体来说，咨询活动期间重点应用了 BDD、TDD、用户故事映射和结对编程。通过与我们的团队合作，顾问向我们的开发人员、架构师和产品所有者展示了如何以新的方式工作，实现独立的部署管道，将可观察性落实到位，等等。此外，我们还邀请了 Johner Institute GmbH 的医疗 QMS 顾问，讨论了我们的 QMS 调整分析，确认可以在保持法规遵从性的同时进行这些调整。

2018 年，我们继续与顾问们合作，更深入地采用持续交付的工作方式。这一次不是要引入新的方法，而是要在可持续的基础上，将之前引入的方法嵌入到团队和团队成员的日常生活中。日本武术的精神概念守 - 破 - 离描述三个阶段的学习道路上掌握 (守，跟随大师，破，学习其他大师和优化实践，离，想出自己的技术)，我们的转型是从守到破的学习阶段。

我们的目标是嵌入新的工作方式，这样就不再需要顾问的参与来支持新的实践。我们达成了一个阶段，持续交付成为所有新的数字健康产品的标准。在转型的监管方面，我们将基于 BDD 的需求工程正式引入了监管的 QMS。

2019 年，我们发布了第一个 QMS 版本，该版本使团队能够以持续交付的方式工作。同时发布了质量管理体系的工具。对于需求工程，我们使用验证计划和相关测试，以正式的方式验证了产品“Azure DevOps 的现代需求”。它简化了需求基线、需求评审过程和需求的可追溯性。

出于监管报告的目的，我们实现了自己的工具，称为“QTracer”。此外，使用验证计划和相关测试以正式的方式对该工具进行验证。新的 QMS 和相关工具的组合使团队能够更有效地制作符合法规的发布，同时减少法规性开销。

交付的稳定性是我们观察到的转型的整体影响的第一个迹象。与前一年相比，今年所有部署的生产部署失败率下降了一半。

2020 年，转型的突破成为可能。与前一年相比，今年所有部署的生产部署前置时间减少了 3/5。与此同时，与前一年相比，今年所有部署的生产部署失败率下降了一半。更多细节和相应的图表可以在后面的“速度和稳定性一起提高”小节中找到。

在 2021 年，软件交付的速度和稳定性的联同改进仍在继续。到目前为止，今年完成的所有部署的生产部署前置时间与前一年相比减少了 1/2。与此同时，与前一年相比，今年迄今为止所有部署的生产部署失败率下降了 2/5。更多细节和相应的图表可以在后面的“速度和稳定性一起提高”小节中找到。

转型易胜点

尽管转型是一个漫长而艰苦的过程，但在过程中也有点可以轻松取得胜利，详见下表：

变革的主要挑战

在转型期间，我们遇到、减轻或解决了一些主要的挑战，详见下表：

总的来说，从定义上讲，涉及人员、过程、技术、组织和法规变化的长期过程调整将具有挑战性。一个有远见有勇气的领导是成长和保持势头的必要条件。在这个过程中，要不吝于展示和庆祝一次次的成功，这能极大地帮助人们保持旺盛的积极性，经受住新出现的挑战。

由于转型的各个方面有大量的选项可供选择，因此几乎不可能对这个过程进行特别严密的计划。一个可行的替代方案是，陈述转型的高层次业务目标，并进行适当地量化。然后让团队定义中间里程碑来探索他们实现目标的路径。

大变革的机会

尽管转型是一个漫长而艰巨的过程，但它抓住了重大机遇的关键，详见下表。

速度和稳定性相辅相成

如前一章所示，在转型过程中，速度和稳定性都得到了提高。在下面的图片中可以看到速度和稳定性指标细节。

从转型多年的生产发布提前期趋势来看，在很长一段时间内，2016 年至 2019 年，提前期没有减少。相反，在 2019 年，尽管所有转型都在做出努力，交付时间却有所增加。然而，自 2020 年以来，交付提前期大幅下降：从 2019 年到 2020 年的交付提前期下降了超过 3/5，除此之外，从 2020 年到 2021 年的交货期下降了 1/2。也就是说，自 2019 年以来，生产前置时间减少到了 1/5！

下图显示了经过多年改造后的生产部署失败率趋势。结果表明，在 2016 年至 2018 年的很长一段时间内，故障率并没有下降。相反，在 2018 年，尽管所有的转型都在进行努力，但它达到了历史峰值。然而，自 2019 年以来，生产部署失败率稳步下降：2018 年至 2019 年为 1/2，2019 年至 2020 年为 1/5，2020 年至 2021 年为 2/5。也就是说，自 2018 年以来，生产部署失败减少到了 1/4！

上面的两张图片表明，自 2020 年以来，软件交付的速度和稳定性一直在同步提高。同时，生产部署前置时间和故障率也呈下降趋势。也就是说，软件交付速度越来越快，也越来越稳定。

由于以下原因，只有在经过几年的改造之后，速度和稳定性才得到提高:

• 当转型开始时，组织对持续交付方法还缺乏了解。为了建立知识体系并得到一套适合组织并被组织接受的方法，需要恶补大量的知识、进行大量的实验。

• “一边做事一边转型”: 转型的同时，还在同步实现着使用新技术的面向客户的新特性。这是商业上的需要。特性实现占用了开发很大一部分精力，留给转型活动的并不多。

• 由于转型和特性开发活动之间都占用开发的精力，诸如架构分离、创建每个团队独立部署的管道和测试重构等技术变革需要很长时间才能到位。

印证《加速》一书中的研究成果

由 Nicole Forsgren、Jez Humble 和 Gene Kim 撰写的《加速——精益软件和 DevOps 的科学：如何构建和扩展高效能的技术组织》一书介绍了基于对全球 400 多家公司的软件交付的调查研究。Randy Shoup 在他的演讲“大规模快速发展”中用下面的两张图片简要总结了这本书中的研究。

作为研究的一部分，研究人员分析了两类公司：高绩效公司和低绩效公司。在软件交付速度方面，高绩效的每天部署大约 10 次，交付时间不到一个小时。低绩效的大约每月部署一次，准备时间大约为 6 个月。

有趣的是，在这两类之间并没有很多公司。也就是说，接受调查的公司往往要么表现出色，要么表现欠佳。更有趣的是，根据上图所示的交付速度，绩效相同的公司在交付的稳定性方面也是相同的，如下图所示：

高绩效的生产部署几乎从不失败。即便是失败了，不到一个小时就能恢复。另一方面，低绩效的会有将近一半的生产部署失败。生产部署失败后恢复时间超过一天。

由于大多数公司在速度和稳定性方面是相同的，因此可以得出结论，在软件交付中，速度和稳定性是密不可分的。事实上，软件交付的速度越快，它就变得越稳定。

这听起来可能违反直觉。然而，《加速》一书中严谨的研究结果证明了这一点。在我们的软件交付转型过程中，我们可以直接看到交付的速度和稳定性是如何同时得到提高的。也就是说，我们的转型确实可以印证《加速》的研究成果。

转型回顾

对这次转型进行回顾，可以加深以下经验教训。

1.这次转型从一开始就不是以数据驱动的方式驱动的。只有在随后的过程中，才在组织和团队层面制定了持续交付的速度和稳定性指标。我们建议从转型一开始就制定这些指标。这可以根据 Steve Smith 的《测量持续交付》一书来完成，该书详细描述了部署管道所有阶段的速度和稳定性指标的定义和实现。速度指标结构为生产部署、提前时间和生产部署频率。稳定性指标结构为生产部署失败和生产部署恢复时间。

拥有组织和团队层面的指标，可以使组织中的人就转型所要实现的目标更快更深入地达成一致。此外，它使团队能够以数据驱动的方式设定自己的速度和稳定性中间目标。最重要的是，这些指标允许在整个组织中适当地应用 改进型 工具，将持续改进作为推动转变的一般方式:

2.SRE 的引入和总体的可操作性是在后期的改造中完成的。我们建议在转型过程的早期迂回完成这些方面。这满足了在转型过程中“构建，运行”的态度、过程和工具的成长，而不是在建立了持续交付之后被视为另一个大的转型步骤。此外，可靠性 SRE 指标可以定期用于改进型工具。

例如，可以针对服务可用性占比和时间建立可用性指示器，以便在不可用时重新建立可用性。可以在可用性指标下定义长期和中期目标，并不断迭代。

3. 在以新方式工作方面，我们学到了，既向人们提供新方法的知识，又由熟练使用这些方法的人进行指导，是一种强有力的组合。也就是说，在为人们分配学习时间时，仅仅提供学习材料或培训是不足以改变习惯的。出于同样的原因，仅仅提供接触到教练的机会是不够的，大家无法充分理解为什么要接受指导。所以，单靠指导也不能改变习惯。

相比之下，往往在有经验的教练的指导下，将最初的学习和长时间的应用相结合，才会改变个人和团队的习惯。最初的学习理解了应用新方法的潜在原因、好处和背景。随后，与一位经验丰富的教练一起应用新方法，通过一个频繁而有力的反馈环，在小范围内调整过程，将新方法融入到日常工作中。

4. 通过在架构、测试、部署、法规遵从性、发布和运维方面分离服务，可以减少生产部署的前置时间。随着独立服务数量的增加，需要一个轻量级的治理，以便集中维护组织范围的最佳实践、协议和规则，同时尽可能让团队保持独立性。

建立治理可以受益，例如使用一个严格的平台，将最重要的控制节点编成法典。这些活动应该是转型的一部分，而不是在转型显露出成功迹象之后再做安排。通过这种方式，可以有机地开展必要的治理，从非常小的步骤开始，比如服务和环境的命名。

我们在转型的后期开始了治理活动，建议在构建第一个独立服务时推广该实践。

总  结

加速软件交付是一个长期的转型过程。可以使用速度和稳定性目标有效地引导该过程，并使用相应的指标进行测量。畅销书《加速》中的研究表明，速度和稳定性是相辅相成的。在此之后，这两项措施应该同时改善。西门子医疗团队数字健康平台的软件交付转型印证了这本书中的研究。在转型过程中，速度和稳定性都得到了提高。

致  谢

他们在推动西门子医疗团队数字健康平台软件交付转型中发挥了重要作用，我们表示感谢：Thomas Friese、Carsten Spies、David Schottlander、Fabio Giorgi、Frank Schneider、Frank Stanischewski、Philipp Guendisch 等。

此外，我们还要感谢以下持续交付顾问，他们在转型过程中提供了无价的帮助：持续交付有限公司 的 Dave Farley，以及来自 Equal Experts 有限公司 的 Neha Datt, Ryan Bayly, Marcel Britsch, Keerthana Jayaram, Louis Abel 和其他许多人。

最后，感谢 Akshith Rai 维护了团队中的持续交付指标。

作者简介：

Vladyslav Ukis 博士毕业于德国埃尔兰根 - 纽伦堡大学计算机科学专业，之后又毕业于英国曼彻斯特大学。毕业后加入西门子医疗，在软件架构、企业架构、创新管理、公私云计算、团队管理、工程管理和数字化转型领域工作。自 2018 年以来，他一直担任西门子医疗团队数字健康平台和应用的软件开发经理，推动持续交付和 SRE 转型。自 2021 年以来，他还担任所有西门子医疗数字健康产品的可靠性经理职务。

译者简介： 冬雨，小小技术宅一枚，从事研发过程改进及质量改进方面的工作，关注编程、软件工程、敏捷、DevOps、云计算等领域，非常乐意将国外新鲜的 IT 资讯和深度技术文章翻译分享给大家，已翻译出版《深入敏捷测试》、《持续交付实战》。

原文链接：

https://www.infoq.com/articles/improving-speed-stability/

---

你也「在看」吗？👇