DevOps一直不断发展。自从2009年有了这个概念以来,DevOps的发展状态就以每年指数级的速度增长。在2019年飞速发展的过程中,各种规模的组织(从企业到初创企业)都对DevOps充满热情。每个组织都有自己的DevOps实践经历。其中一些DevOps实践经历尚未开始,一些实践还在起步阶段,有些实践已经成熟,有些实践已经达到极致。与其他实践不同,DevOps实践永无止境,因为它涉及持续改进。
随着企业逐渐数字化和软件驱动,人们对DevOps本质和发展潜力有了更大的认识。不仅工程师、技术领导者,还有商业领导者都对DevOps的概念,实践和应用感兴趣。人们越来越需要DevOps取得商业效益。《DevOps2019年状况报告》,可以了解DevOps如何塑造跨行业的软件交付的。这份报告总结了软件交付的趋势和挑战。它可以帮助团队用于改善软件交付性能,并最终实现卓越性能。在本报告中,IT性能称为软件交付性能,以区分软件交付工作与IT服务台和其他支持功能。这是一个期待已久、受欢迎的变化。我还喜欢的一项重要更改,是它增加了完成软件交付周期的操作指标。该报告重点介绍了关于“ 软件交付和运维(SDO)性能 指标 ”的5项指标,它们侧重于系统级效果。这有助于避免软件度量标准的常见陷阱,后者常常使不同的功能相互冲突,并导致以总体效果为代价的局部优化。
图1:5个SDO性能指标该报告重点介绍了软件交付性能的四个方面,如下所示:
- 部署频率–你从事的主要应用程序或服务,你的组织多久部署一次代码?
- 服务变更的交付时间–对于你正在工作的主应用程序或服务,你的变更的交付时间是多少(即,从代码提交到成功在生产中运行的代码需要多长时间)?
- 恢复服务的时间–对于你正在使用的主应用程序或服务,发生服务故障(例如,计划外的服务中断,服务障碍)时,恢复服务通常需要多长时间?
- 服务修改的失败率–对于你使用的主应用程序或服务,多少百分比的修改,会导致服务质量下降或需要立即补救(例如服务故障或服务中断,需要热修复,回滚,打补丁)?
对如上四个方面的衡量,会有四个性能:卓越,高,中和低。下表(引用上文的报告)说明了各个方面的详细信息。
图2:软件交付性能的各个方面另一个方面,我强烈建议添加到此列表中的是“ 团队参与度指数 ”,即团队的快乐程度和参与度。我认为团队性能与团队敬业度成正比。团队参与度越高,即团队越快乐和参与度越高,他们产生的结果就越好。报告中的另一个主题是“ J曲线转换”。下图突出显示了,自动化如何帮助低性能升到中等性能水平,以及测试要求,技术债务和复杂性的增加变得手动控制,从而导致进度变慢。这是一个有趣且“ 值得注意 ”的观察。它强调了自动化并非总是最好的办法。如果你使错误的流程自动化,那么你得到的只是错误的结果,而且更快。
图3:转换的J曲线持续改进,学习和共享以及利用专业知识,可以使你达到高性能或卓越性能水平- 将团队提升为卓越性能的过程需要的不仅仅是工具。在各个级别(即团队级别,领导级别和赞助者级别)的坚持和毅力是至关重要,会帮助你从中低性能级别突破,以发挥团队最大潜力。 如果我们开始走上实现卓越性能的道路,你会发现自动化,技术实践和持续改进计划是你旅途的催化剂。而测试需求,技术债务和增加的复杂性将成为你的阻碍。我发现锚定和引擎(SailBoat Retrospective)格式提供了一种快速有趣的方法,帮助我们在一幅图片中形象化看到催化剂(engines) 和阻滞剂 (anchors)的关系 (如下所示)。
图4:卓越性能之旅
行业看到了更多的卓越性能
报告证实,卓越性能的比例几乎增加到原来的三倍,低性能的比例下降了,中等性能的比例上升了。要注意的一项主要观察结果是,从低性能到中性能再到高性能的移动不是一个方向。当面对复杂性增加时,团队(正如J曲线中突出显示)可以从高位降为中级,也可以从中级降为低级。总体而言,很高兴看到向上增长的趋势。
图5:不同性能集群
未来的方向
软件交付性能可以通过多种方式决定业务成果。组织推动软件交付性能的能力包括文化,技术实践,清晰的变更过程,持续交付以及有价值的成果。这些功能并不是一蹴而就的,需要对组织DNA进行根本性的改变。根据我在不同行业和公司中工作的经验,我可以确认这些软件交付性能不是静态的。上面列出的任何功能的变化都会影响软件交付性能,你可能会发现集群性能来回从一个级别波动到另一个级别。关键是保持专注,并通过将其嵌入组织的工作方式,定期来维持它。译者:王延飞原文:https://dzone.com/articles/good-to-great-with-devops
END
本站仅提供存储服务,所有内容均由用户发布,如发现有害或侵权内容,请
点击举报。