2018年度的DevOps最新研究现状姗姗来迟，但最终还是来了，让我们来看一下这份 告今年会给我们带来那些启示。

研究人员

铁打的营盘，流水的Dora（DevOps Research and Assessment）。参与其中Jez Humble和Gene Kim一直是这份 告最大的看点，他们的离去虽然是一种遗憾，新的加入也会从其他角度带给我们不同的思考。2018年度的 告的作成主要由splunk和puppet引导给出。

加上台湾地区，在这份 告中中国的数据比例占到整体的亚洲部分的4%（大陆地区3%），日本和弹丸小国新加坡各占亚洲数据的37%，印度18%。

作为欧洲经济三大强国的英/德/法，三家数据占到整个欧洲的3/4.

DevOps团队

随着DevOps理念和实践的不断推广，与DevOps团队相关的工作人员也开始逐年递增。

解读：
在看这个结果的时候，先预设一个问题：如果我所在的组织要推行DevOps，我们应该以什么样的组织结构去面对它br> 前文中当前使用的结构就是现在的DevOps实践所给出的答案，除了DevOps团队之外，可以看出目前比例最高的仍然是现在的组织构成，开发中心方式明显就是各种GDC，特定应用服务的跨职能团队方式就是大型项目目前的现状，所以实践给出的答案就是：除了DevOps团队之外就是继续使用原有的结构。
为什么SRE方式是目前大家尝试意愿最多的一种呢，从另外一个角度来看，已经有人尝试的方案在备选答案中仅此一家别无分店，自然大家会希望使用google尝试过的方式。这样看来之后，SRE目前选择的最少但是后续希望尝试的最多这个结论也没有太多意外了。
希望后续的 告能够在使用什么样变革型的组织结构以及实践的效果方面有一些数据的支持，不然个人认为这份 告具有的导向性会越来越低。

Five Stages

这是整份 告的重中之重，Five Stages，并给出了各个Stage建议做的事情。

C：Culture：文化维度

单一部门的多个团队以及单一团队方式为目前主要的实施方式。

M： Measurement：指标维度

随着成熟度的提高，自动化程度会逐渐提高，手工方式会逐渐降低，这是一个整体的结论，系统级别的指标收集和展示在这个方面体现地非常清楚。
而业务指标数据的收集和展示自动化程度会逐渐提高，但和系统指标相比，复杂性和共通性较低，收集分析统计与展示也较为复杂，无论是自动化还是手工作业，相关的程度还有待于进一步地提升，是一个标准化仍在继续的过程。所以在业务指标的自动化程度会随着成熟度提高的时候明显提高，但是手工的收集和展示方面也呈整体上升的状态，随着标准化的完善和进一步的提升，整体下降的趋势应该会在后续出现，这一点可以在明年及以后的数据中可以进一步的确认。

不同角色的不同结论

• 开发者自己对自己的代码部署和运行负责
• 开发者和运维人员一起提供相关的非功能性要素保证部署和交付
• DevOps团队作为一个紧密结合的整体定义监控细节
• 由运维专家组成的团队监控开发人员所交付的应用
• …

部署模式是可重用的: 23x

可重用的部署模式对于打破开发和运维之间的那堵墙（wall of confusion）非常重要，High级别和Low级别之间有高达23倍的差距。

解读：不得不说这是一个去年没有确认的重要部分，持续测试是DevOps中的一个重要环节，但是目前整体的状况推广的并不是很好，占到整体大多数的Medium级别的组织只有10%左右的比例，Low级别更是几乎没有实践，这将是接下来一个重要的实践要点。

工具链可用并且团队持续进行改进：44x

保持工具链可用并且持续进行改进，此项的差距也达到了44倍。

总结：
作为五项基础的实践，在实施中如下三项应该作为重点内容：

• 监控和警告是可以配置使用的
• 部署模式是可重用的
• 配置使用配置管理工具进行管理

而在此基础之上，余下的两项建议推行，则是这份 告对于基础实践的五项所给予的结论

• 构建应用和服务的测试是可以重用的
• 工具链可用并且团队持续进行改进

Stage 1: 规范化技术栈

很多组织都使用了很多技术，而且引入了很多的依赖，使得复杂性大为增加，而这些往往会拖慢整体的步伐。在这个阶段，降低复杂性则是当务之急。

解读：
就像 告所指出的那样，很多人认为自动化应该是最初的切入点。而实际上如果事前的准备工作没有做好，直接切入进行自动化，很多时候这种急功近利的朴实的需求并不一定能够收到很好的效果。
在一个技术栈非常复杂的情况下，自动化本身就将会变成一个不可控的需求，而如果不对这种复杂性进行控制，后续的投入很有可能会大幅增加。所以规范化整体的技术栈更多的是为了简化，降低过多的依赖，所谓磨刀不误砍柴工。
我们做很多DevOps落地的项目中也是如此，虽然会讲自动化作为一个很重要的点进行推行，但是在此之前对整体的流程/可改善的环节/改善的计划和重点/技术架构进行讨论，目的就是为了明确和降低整体的复杂性，以期能够持续稳定的投入收到持续稳定的回 。

实践内容

此阶段主要从如下两点来进行推进：

• 应用开发团队使用版本管理

解读：
版本管理是整体实践的基础，这一点应该不会有所异议。在实际的项目中，目前的阶段没有使用版本管理的项目可能更为罕见。但是是否所需要进行管理的内容纳入了管理，管理是否规范，是否高效，这些问题实际上才是版本管理在实践中不断进行改善的细节。

• 团队在标准的操作系统上进行部署

解读：
应用和服务在复杂的操作系统中才得以运行这是非常普遍的一个现状，在 告中所举例的那样，可能有在Windows 2012/Windows 2012RT/Windows 2016上运行的不同应用，而这些应用一起提供最终的服务，简化这些能使得整体的复杂性大幅的降低。
在实际的项目中，往往比 告中所提到的例子更加复杂，你有可能还在使用一些大型机，使用已经不再更新版本了的Unix系统，使用Motif来画页面，使用CGI来写 页，因为大型的项目不是那么理想可以一步替换的。但是简化整体的技术栈确实是一个重要方向，哪怕技术本身不是一个问题，在DevOps Handbook 中就举过一些公司在此方面的实践，因为技术本身就非常复杂，每个人都很难在所有的方面做到全部精通，简化技术栈可以使得在整体之间的沟通更为的高效和快速。

关键因素

为了保证此阶段获得成功，有四项对于结果影响最为重要的关键因素如下所示：

• 构建标准的技术栈
• 应用配置纳入配置管理
• 在部署至生产环境之前测试基础框架变更
• 源码对其他团队可见

构建标准的技术栈

构建标准的技术栈非常重要，它是Stage 1的关键因素，同时是Stage 2中的实践内容，也是Stage 3的关键因素，可以看出这是一项需要持续实施的实践要素。标准化技术栈对简化依赖和降低复杂度有很好的效果，而在业务层面也会在诸如license的成本上有所降低。

解读：
对技术栈进行规范和标准化，从长远来看会收到很好的效果。但是对于拥有复杂度很好的老旧系统，如何进行实施才是关键所在，影响太大，改动成本过高往往是现实世界中的阻碍所在。构建标准化的技术栈，势在必行，但是如何推动，以什么样的规划进行才是更应该考虑的。
另外，构建规范的技术栈，不应该局限于某一个应用或者服务，应该着眼全局，从整体角度进行考虑，也是这份 告所给出的一个建议。

应用配置纳入配置管理

应用开发应该进行版本管理，这包括代码的版本管理以及应用配置信息的版本管理。

解读：
应用配置进行版本管理，可以从如下几个方面进行理解：

• 应用部署的环境不同并且复杂，导致应用配置可能会有所不同
• 不同的应用配置，相同的应用代码，代码和配置数据进行分离是一种常见的对应方式
• 应用配置不仅仅着眼于快速的部署和灵活应对各种环境，可回滚也是进行版本管理的一个主要着眼点

在部署至生产环境之前测试基础框架变更

这项实践内容在这个阶段和Stage 3均有出现，不同的是实施的程度有所不同。在此阶段对于测试基础框架变更所涉及到的内容仅仅为不需要手工的批准，主要目标在于团队的自制，获得权限和责任是这个阶段需要注意的。
这些实践往往都是贯穿于各个阶段的，不同的阶段所侧重的角度不同，这也是在实践的不断深入所应该考虑的问题。

源码对其他团队可见

源码对于其他团队可以见，可以使得不同团队更好的进行参考和借鉴，也是分享文化的一种具体体现，在这个阶段中这是一种将局部的成功经验进行复制扩展的有效方法。

Stage 2: 推进标准化&降低不一致性因素

标准化的推进是一个持续的过程，而那些不同的特性或者说不一致的因素往往会成为实践过程中的阻碍，而这些不一致的要素往往是由于多种原因导致的，比如：

• 新的技术不断实践，但是旧有的技术栈也不进行移除，导致很多非标准的不一致因素的存在
• 土生土长的架构没有考虑到行业共同的标准和规范，自成一派
• 企业合并与收购导致的不一致性
• …

实践内容

此阶段主要从如下两点来进行推进：

• 构建标准的技术栈

团队需要使用可重用的部署模式，标准的技术栈所解决的问题就是降低依赖行和复杂度。可以简单地使用诸如如下的问题进行自检：

• 是否所有的服务都是在相同的架构上进行构建/li>
• 是否这些服务使用相同的消息队列/li>
• 他们是否使用相同的组建和模式br> 当你的答案中出现No的时候，这些非标准化的不一致性会给系统带来更高的复杂度和更多的维护成本负担。

解读：团队对技术栈进行标准化和简化意味着很多，而且能够带来很多收益比如：

• 更快的交付速度
• 降低安全脆弱性的简单的共通性问题
• 学习曲线更加平滑，维护和升级更加容易…

• 在标准的单一操作系统上进行部署

操作系统及其版本的不同往往对运行于其上的应用程序有较大的影响，这里的影响并不是业务层次上的影响，而是在NFR角度的考量，而当组织使用单一操作系统或者范围可控的操作系统级是，部署的效率更得到很好的提升。同时能够降低在系统安全补丁/调优/升级/故障排查等方面所消耗的时间。
整体来说，在操作系统的规范层面相关建议如下：

• 即使无法保证在单一操作系统上运行服务，减少到最低限度总是好的
• 在单一的操作系统上也尽可能地降低不一致性的存在

解读：
活用目前所拥有的技术栈是一个很好的建议。技术本身往往没有好坏之分，只有合适和不合适，即使是那些看起来很合适的技术，也需要考虑到引入之后带来的成本考量，比如根据数据库特性不同导入了MongoDB/Mysql/Oracle/Postgresql同时在一个系统之中明显不是一个好主意，这极大地增加了运维的复杂度，同时使得系统正常运行起来说需要的基础知识范围大幅度的扩宽，沟通的成本和时间也往往会大幅提升，而简化往往能够使得这些都不在是问题。
放弃的技术并不一定是不好的技术，规范和简化技术栈以提高效率是非常重要的一环。

关键因素

为了保证此阶段获得成功，对于结果影响最为重要的关键因素如下所示：

• 重用构建和部署应用和服务的模式
• 基于业务需求对应用进行架构重构
• 将系统配置纳入版本管理之中

重用构建和部署应用和服务的模式

在这个阶段的重用其实还是非常的简单的，而没有考虑到过过多复杂的因素，简单程度上的重用是这个阶段的。而关于详细的展开，在Stage 3中还会有进一步的陈述。

基于业务需求对应用进行架构重构

标注化技术栈带来的结果往往是需要对既有的应用进行重构，在这个过程中可能是使用开源的组件或者商业的产品来代替以往项目中愈加难以维护和更新的自由行开发的旧有组件。

解读：这是一个说起来更加容易的实践，目的是希望有更快的速度和更好的可维护性。技术债务需要不断偿还，而且好的状态需要不断的维护。

将系统配置纳入版本管理之中

在这个阶段中，对系统级别的配置管理进行版本管理会给基础框架的开发和维护提供一个非常良好的基础，这也是“基础框架即代码”的基础实践所要求的范畴。
系统配置纳入版本管理会带来很多好处，比如：

• 可以变更相关的详细信息，不同时间的变更和发起者等都能够被追踪
• 任何具有对版本控制系统具有权限的人员都能对变更进行确认
• 关键的备至管理文件能够得到备份，从而具有可回滚的基础

Stage 3: 扩展DevOps实践

在前面的两个Stage的基础之上，整体程度上技术栈的复杂度和不一致性得到了有效的降低，为这个阶段的DevOps实践提供了很好的前提条件。
随着各个团队合作的深入，聚焦于各个部分的改进使得团队开始在技术应用之外进行了更深入的协作，分享工具的改进，应用/服务/以及知识等等，这些推动了DevOps实践在组织中的扩展。

实践内容

此阶段主要从如下三点来进行推进：

• 团队成员工作无需团队外部的人工批准

解读：
这点主要的目的是为了赋能团队，降低组织官僚化的冗长流程对效率造成重大损害。在实际实施的过程中达到目的即可，流程的审批需要的时候，可以考虑责任下放，使得团队中的Leader有审批有权利和责任即可。
另外根据前几年的调查 告显示：这些外部的人工审批对于系统的安定性有着几乎可以忽略的影响，换句话说，额外的人工审批不会使系统更加安全，可能只会使审批者心理上更加放心而已。

• 重用构建和部署应用和服务的模式

解读：
相比较于前一个阶段的同样的实践，这里的要求就严格的多。简单来说，哪怕你只有两个软件项目要进行发布，需要使用相同的方式，而不论是发不到开发/测试/准生产还是生产环境。
在这个阶段很多具体的实践都会根据组织技术栈和流程进行标准化的重用，比如：

• 使用标准的方式去指定所要部署的对象环境
• 与CI的持续集成进行结合
• 部署的步骤可以进行标准化或者定制化
• 部署的方式可能是蓝绿或者其他方式
• 可以重用一条流水线对不同的应用进行发布
• …

• 在部署至生产环境之前测试基础框架变更

解读：
在这个阶段，对于基础框架并不需要集成到CI中进行全自动，而是要把重点放到对基础框架功能的验证上，而手工完全可以保持。
因为基础框架的变更范围非常广泛，对其进行自动化，引入infrastructure-as-code的方式进行管理也是需要成本的，而在很多时候，对绝大多数情况来说，这些并没有那么的频繁（当然对于那些云服务器的服务商来说完全不同了），所以结合手动作业，主要对基础框架的变更进行验证的方式是这个阶段推行的重要方式。

关键因素

为了保证此阶段获得成功，对于结果影响最为重要的关键因素如下所示：

• 团队成员可以进行变更对应而不会有过多的等待时间
• 服务变更可以在业务时间内对应
• 进行事后检查和评审并分享相关结果
• 团队在标准的技术栈上进行构建
• 团队进行持续集成实践
• 基础框架团队使用版本管理

团队成员可以进行变更对应而不会有过多的等待时间

解读：
虽然这期所给出的CAMS模型里面没有L（Lean），但是这就是典型的精益实践之一，消除等待的浪费。是对整体过程的一个简化，当然实际实施时需要考虑到很多因素，比如：

• 在整体不会出现很多问题的情况下进行实践，比如部署成功率已经很高，很少出现问题和意外
• 消除等待时间应该与实际业务需求相结合，确认是必要还是可选

服务变更可以在业务时间内对应

解读：
在业务时间进行服务变更，保证服务不中断，建议从如下角度进行实践：

• 流程：等待时间大幅度降低情况下进行
• 架构：考虑蓝绿部署等方式降低影响
• 时机：定义出业务时间结合业务影响度，即使是24小时无终止的服务，业务影响度也会有所不同，选择影响程度最低的时间段
• 预演：在准生产环境上进行验证能力
• 回滚：事前准备回滚方案并进行验证
• 试点：先选择影响度小的项目作为试点

进行事后检查和评审并分享相关结果

解读：
时候检查仍然是CAMS中S（分享）相关的具体实践，实施时需要注意如下几个要点：

• 免责方式进行：去年的gitlab给出了一个很好的案例，看一下他们把关键数据丢失的员工的进行了什么样的惩罚就知道了。
  其实也很好理解，出现的问题往往只是冰山的一角，对于可能出现的问题，大部分人在自身安全不能得到保证的情况下，免责还是不免责可能就是出现问题有可能会藏起来不说还是说的区别，这是人的本性，无可厚非。
  有些组织在构建企业文化时，一边拿着鞭子抽打，另一方面期待员工能够为公司殚精竭虑，所有问题都能畅所欲言，不太现实。
• 相关干系人参与并将结果进行公示，一方面可以增进信任，公开比隐藏个能获取相关干系人的信任。另外一方面，对于其他没有直接关联的成员，这些公布的内容也是值得学习和借鉴的内容。

团队在标准的技术栈上进行构建

解读：
构建标准的技术栈，这个实践要点也是一个持续性的行为，在不同阶段都需要进行考虑，自然在扩展的阶段也不能避免。好不容易打下的基础，简化的技术栈，在扩展的时候重新变成复杂度和不一致性都很高的高技术负债的状况，就说明扩展的方式出现了问题。

团队进行持续集成实践

解读：
持续集成已经成为版本管理之后，最需要进行实践的内容之一。但是需要注意的是，持续集成本身也需要维护和优化，也是一个长期的过程。

基础框架团队使用版本管理

基础框架团队使用版本管理在这个阶段和后续的阶段都是非常重要的，将基础框架的变更和管理也纳入版本管理的范畴也会对整体实践的推进有非常正向的影响，详细会在后续阶段进行说明。

Stage 4: 自动化基础框架交付

自动化基础框架的交付并非是到了这个阶段才能去实施的阶段，在经过前面阶段的规范化/标准化/简化以及扩展之后，这个阶段可以进行更为全面的基础框架相关的自动化了。

实践内容

此阶段主要从如下四点来进行推进：

• 自动化系统配置
• 自动化设定
• 应用配置纳入版本管理之中
• 基础框架团队使用版本管理

自动化系统配置

解读：
自动化系统配置一般意味着系统的构建不是通过手工，而是通过得到版本管理的设定文件和脚本，整体通过一个自动化的框架（比如Puppet/Ansible，虽然 告中没有写出来，但是已经非常明显了，有整整一个Stage来进行自动化基础框架，而前面几个Stage都是用来铺垫和准备）
整体来说，系统配置自动化能带来很多收益，比如：

• 更加快速应对变更
• 更快的整体交付速度
• 环境一致性得到保证
  …

另外，关于对那些系统配置项进行自动化，自然需要考虑到ROI，使用频度高的并且实现简单的自然应该有限考虑，同时也需要可简化或优化流程结合起来以达到更好的效果。

自动化设定

解读：
与自动化系统配置相结合，自动化设定实践能够使得项目成员通过自服务功能来对基础框架进行操控。当然，使用频度最高的项目应该是优先考虑的，同时自动化设定在后续阶段中也是重要的实践内容。

应用配置纳入版本管理之中

解读：
应用程序源码在版本管理控制之中，但是应用程序配置信息同样应该纳入管理，那些使用了诸如12-facotr的应用，相关的配置信息的管理也源码一样同等重要。

根据业务需要进行应用架构重构

解读：
在Stage 2的时候此项实践同样出现，不同的是前面的阶段中架构的重构所引起的原因是因为标准化技术栈所引起的，往往是很大程度的对应，比如数据库种类的变化以及操作系统有多个变成了一个。
而这个阶段则是整体的改善，比如12-factor规范的实践等等，不同的阶段考量的因素不同，架构的改善应该贯穿与整个过程。

安全团队融入技术设计和部署阶段

早在2016年的 告中，就发现了高效的组织在安全相关的问题上所花的时间只有抵消组织的50%，这是因为安全相关的因素已经在交付的过程中被考虑进去了。整体来说，安全需要更早的被引入到交付的流程之中，包括：

• 在保证不会拖慢开发进度的情况之下，对所有主要特性都进行安全评审的流程
• 集成信息安全机制到每日的工作之中
• 将对安全需求的检证作为自动测试过程的一部分
• …

组织不同角色对自动化的认识一致性较高

不同的角色在DevOps实践中对同一问题的看法往往存在gap，而对于自动化相关的看法，调查的结果显示，分歧非常之小。

关键因素

为了保证此阶段获得成功，对于结果影响最为重要的关键因素如下所示：

• 安全策略配置是自动化的
• 应用开发者自己部署应用到测试环境
• 项目的成功指标是可视化的
• 自动化设定

安全策略配置是自动化的

解读：
安全策略的自动化自所以在比较靠后的Stage进行，主要的原因是这是一块难啃的骨头，相比较于安全问题一旦出现所需要的成本，这一切都是值得。在如下的文章中对可以看到安全问题所需要付出的成本：（https://blog.csdn.net/liumiaocn/article/details/77646024）

应用开发者自己部署应用到测试环境

开发团队成员能够按需将开发的应用部署到测试环境时，由于无需进行环境的等待等，应用交付的流程将会更快，而运维团队由于从大量的环境配置的重复性劳动中解放出来了，则可将精力投入到系统性能的优化上。但是前提是需要这种自服务的功能的提供不是从天而降的，需要投入一定的人力和成本的。

项目的成功指标是可视化的

关心什么，你就会得到什么。KPI指标的可视化非常重要，但是更加重要的是明确地定义以及对参与者可以随时获得信息分享的途径。

总结

今年的 告给出的最为重要的内容就是5-stages的推进方式，对于那些初步进行了一些实践但是仍然觉得在扩展方面有问题的组织来说应该有一定的借鉴意义。

附录1: 2017年DevOps 告解读

https://blog.csdn.net/liumiaocn/article/details/72899528

附录2：Take Away：5 Stages具体内容

阶段	实践内容	关键因素
Stage 0	监控和警告是可以配置使用的（重点）	–
	部署模式是可重用的（重点）	–
	构建应用和服务的测试是可以重用的	–
	工具链可用并且团队持续进行改进	–
	配置使用配置管理工具进行管理（重点）	–
Stage 1	应用开发团队使用版本管理（重点）	构建标准的技术栈
	团队在标准的操作系统上进行部署（重点）	应用配置纳入配置管理
		在部署至生产环境之前测试基础框架变更
		源码对其他团队可见
Stage 2	构建标准的技术栈（重点）	重用构建和部署应用和服务的模式
	在标准的单一操作系统上进行部署（重点）	基于业务需求对应用进行架构重构
		将系统配置纳入版本管理之中
Stage 3	团队成员工作无需团队外部的手工批准（重点）	团队成员可以进行变更对应而不会有过多的等待时间
	重用构建和部署应用和服务的模式（重点）	服务变更可以在业务时间内对应
	在部署至生产环境之前测试基础框架变更	进行事后检查和评审并分享相关结果
		团队在一套标准的技术栈上进行构建
		团队进行持续集成实践
		基础框架团队使用版本管理
Stage 4	自动化系统配置	自动化安全策略配置
	自动化设定	资源可以通过自服务获取
	应用配置纳入版本管理之中
	基础框架团队使用版本管理
Stage 5	自动进行事件响应	安全策略配置是自动化的
	资源可以通过自服务获取	应用开发者自己部署应用到测试环境
	根据业务需要进行应用架构重构	项目的成功指标是可视化的
	安全团队融入技术设计和部署阶段	自动化设定

参考内容

https://puppet.com/company/press-room/releases/puppet-delivers-2018-state-devops-report-reveals-stages-devops
https://www.alienvault.com/blogs/security-essentials/automated-incident-response-in-action-7-killer-use-cases

声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！