2020DevOps状态报告

这是Puppet报告的走过的第九个年头，本次报告基于对2400名IT、开发、信息安全行业的技术人员的调研，着重勾画了DevOps状态的两大趋势：平台模型、需求变动的管理。
多年来，咱们已经证实了DevOps实践会带来更好的绩效和组织成果，也学习并分享了组织的发展，以及如何更快地发布更好的软件。
看到显著进展的同时，咱们也看到大多数组织都在努力超越他们进阶的中间阶段。这些团队多是较难扩展DevOps工做方式的开发团队、运维团队和安全团队。

然而，有些组织确实取得了成功。他们扩展了DevOps超出最初早期采用团队的实践，继续在整个组织内不断发展和改进。是什么形成了这种区别？成功的组织实施的更深层次结构的变化。今年的DevOps调查显示能够产生优异结果的结构变化：将DevOps原则应用于软件交付和变动管理。

当组织成功地创建了一个平台用于支持应用程序开发的模型时，就能够提升他们的变动管理效率，并实现DevOps计划的目标：更快、更高效、更容易地交付质量更好、更安全的软件。

为什么是研究平台模型和需求变动管理这两个方向呢？

平台模型是至关有效地赋能应用团队的新方法。一旦正确实施，它就会起做用，结果就是更快、更有效地交付高质量的软件、知足组织的业务需求——大规模应用也一样如此。
需求变动的管理是常见的拖慢软件发布速度、阻止企业实现目标的因素，高效的需求变动管理提升了组织在业务所需级别上按时、保质、安全地发布软件的能力。
报告中，咱们在调查中讨论了发现的各类变革管理各类方法，并展现如何应用DevOps原则把变动管理从阻碍变成更快、更安全的软件交付的方法。

将DevOps扩展到Dev和Ops以外

在任何组织中，经过软件创造价值不只仅依赖于开发人员和运维人员之间的良好协做。几乎全部相邻的业务功能最终都是软件过程的一部分，这些功能须要与技术交付团队一块儿发展。
敏捷曾经是工程师的专属财产，但如今已经不是了。这些年来，从软件团队扩展到财务、人力资源、执行领导团队等等。咱们但愿DevOps原则和实践除了最初开始与他们合做的开发和运维团队，在其余领域也会继续传播，好比DevSecOps、FinOps，可能还要其余咱们没见过的新的表现形式。
也许再过几年，“DevOps”这个词已是老生常谈——甚至逐渐消失——由于有那么多的人和组织彻底采用了DevOps的协做原则：沟通、小批量迭代、反馈循环、持续学习和改进。

运用内部平台团队扩展DevOps实践

DevOps从根本上讲就是让人们可以彼此合做，为了共同的商业目标而奋斗。这必然包括团队使用的过程和工具，可是还须要常常进行对话来解决组织内部阻碍良好发展的结构性问题，让工做可以自由流动和持续改进。
尽管DevOps的实践已经被很好地理解和采用了十年。在这场运动中，咱们仍然看到大多数组织都在努力将DevOps扩展到少数成功领域以外。DevOps每每没法进一步扩张的一个缘由是，大多数企业的结构形成了激励不一致和缺少责任感，这使得合做没法推动。

DevOps演化模型

单独采用一组实践的团队不能进一步推动DevOps 的进阶，必须进行相应的结构更改，以优化团队的工做方式。 DevOps演化模型代表，在没有团队外部的人工批准的状况下，在第4和第5阶段以前，组织不会在自助服务和安全集成方面取得进展（第三阶段）。

第三阶段是一个关键的趋同点——信任已经在第一阶段和第二阶段创建了；团队得到了更多的自主权；部署再也不是一场灾难。 在这一点上，团队能够扩展他们的新合做方式，跨越更多的功能边界，超越Dev和Ops。

在第3至第5阶段，咱们看到了一刀切的规则和流程的松动，其基本重点是自动化。在这些阶段，自动化已经超越了为单个个体或团队解决局部问题的范围，扩展到了更独特、更高的目标：为企业创造价值。

这就是扩大DevOps实践的含义： 经过受权我的和团队，依靠他们的知识和经验以及自动化，能够在整个组织实现大规模优化。如今您能够集中精力消除多个交付流中的浪费，并帮助企业实现其目标。