使用DevOps从优秀到卓越

DevOps一直不断发展。自从2009年有了这个此概念以来，DevOps的发展状态就以每年指数级的速度增长。在2019年飞速发展的过程中，各种规模的组织（从企业到初创企业）都对DevOps充满热情。每个组织都有自己的DevOps实践经历。其中一些DevOps实践经历尚未开始，一些实践还在起步阶段，有些实践已经成熟，有些实践已经达到极致。与其他实践不同，DevOps实践永无止境，因为它涉及持续改进。

随着企业逐渐数字化和软件驱动，人们对DevOps本质和发展潜力有了更大的认识。不仅工程师、技术领导者，还有商业领导者都对DevOps的概念，实践和应用感兴趣。人们对越来越需要DevOps取得商业效益。

《DevOps2019年状况报告》，可以了解DevOps如何塑造跨行业的软件交付的。这份报告总结了软件交付的趋势和挑战。它可以帮助团队可用于改善软件交付性能，并最终实现卓越性能。

在本报告中，IT性能称为软件交付性能，以区分软件交付工作与IT服务台和其他支持功能。这是一个期待已久、受欢迎的变化。我还喜欢的一项重要更改，是它增加了完成软件交付周期的操作指标。该报告重点介绍了关于“ 软件交付和运维（SDO）性能 指标 ”的5项指标，它们侧重于系统级效果。这有助于避免软件度量标准的常见陷阱，后者常常使不同的功能相互冲突，并导致以总体效果为代价的局部优化。

图1：5个SDO性能指标

该报告重点介绍了软件交付性能的四个方面，如下所示：

1. 部署频率–对于你从事的主要应用程序或服务，你的组织多久部署一次代码？
2. 服务变更的交付时间–对于你正在工作的主应用程序或服务，你的变更的交付时间是多少（即，从代码提交到成功在生产中运行的代码需要多长时间）？
3. 恢复服务的时间–对于你正在使用的主应用程序或服务，发生服务故障（例如，计划外的服务中断，服务障碍）时，恢复服务通常需要多长时间？
4. 服务修改的失败率–对于你使用的主应用程序或服务，多少百分比的修改，会导致服务质量下降或需要立即补救（例如服务故障或服务中断，需要热修复，回滚，打补丁）？

对如上四个方面的衡量，会有四个性能：卓越，高，中和低。下表（引用上文的报告）说明了各个方面的详细信息。

图2：软件交付性能的各个方面

另一个方面，我强烈建议添加到此列表中的是“ 团队参与度指数 ”，即团队的快乐程度和参与度。我认为团队性能与团队敬业度成正比。团队参与度越高，即团队越快乐和参与度越高，他们产生的结果就越好。

报告中的另一个主题是“ J曲线转换”。下图突出显示了，自动化如何帮助低性能升到中等性能水平，以及测试要求，技术债务和复杂性的增加变得手动控制，从而导致进度变慢。这是一个有趣且“ 值得注意 ”的观察。它强调了自动化并非总是最好的办法。如果你使错误的流程自动化，那么你得到的只是错误的结果，而且更快。

图3：转换的J曲线

持续改进，学习和共享以及利用专业知识，可以使你达到高性能或卓越性能水平- 将团队提升为卓越性能的过程需要的不仅仅是工具。在各个级别（即团队级别，领导级别和赞助者级别）的坚持和毅力是至关重要，会帮助你从中低性能级别突破，以发挥团队最大潜力。 如果我们开始走上实现卓越性能的道路，你会发现自动化，技术实践和持续改进计划是你旅途的催化剂。而测试需求，技术债务和增加的复杂性将成为你的阻碍。我发现锚定和引擎（SailBoat Retrospective）格式提供了一种快速有趣的方法，帮助我们在一幅图片中形象化看到催化剂(engines) 和阻滞剂 (anchors)的关系 （如下所示）。

图4：卓越性能之旅

行业看到了更多的卓越性能

报告证实，卓越性能的比例几乎增加到原来的三倍，低性能的比例下降了，中等性能的比例上升了。要注意的一项主要观察结果是，从低性能到中性能再到高性能的移动不是一个方向。当面对复杂性增加时，团队（正如J曲线中突出显示）可以从高位降为中级，也可以从中级降为低级。总体而言，很高兴看到向上增长的趋势。

图5：不同性能集群

未来的方向

软件交付性能可以通过多种方式决定业务成果。组织推动软件交付性能的能力包括文化，技术实践，清晰的变更过程，持续交付以及有价值的成果。这些功能并不是一蹴而就的，需要对组织DNA进行根本性的改变。

根据我在不同行业和公司中工作的经验，我可以确认这些软件交付性能不是静态的。上面列出的任何功能的变化都会影响软件交付性能，你可能会发现集群性能来回从一个级别波动到另一个级别。关键是保持专注，并通过将其嵌入组织的工作方式，定期来维持它。

本文译自：https://dzone.com/articles/good-to-great-with-devops