《2018全球DevOps现状调查报告》解读

一、该报告关键发现如下:

SDO效能解锁竞争优势

提升盈利能力、生产力、市场份额、客户满意度，以及实现组织目标和使命的能力

如何实施云基础设施很关键

云提高了软件交付的效能。具备云计算所有核心特征的团队，其属于高效能组织的可能性要高出23倍

开源软件可以提高效能

高效能组织广泛应用开源软件的频率比其他组织要高1.75倍，并且在未来扩展开源软件使用范围的可能性是其他团队的1.5倍

精英效能团队几乎不采用职能外包，因为这会有损于效能

通常外包可以节省成本并提供灵活的人力资源池，然而低效能组织将测试或运维等职能全部外包的比例，至少是高效能组织的4倍

关键技术实践驱动高效能

这些实践包括监控与可观察性、持续测试、数据库变更管理，以及尽早在软件开发过程中集成安全性

实现软件交付的高效能与行业无关

我们发现在强监管行业和弱监管行业中，都存在着在软件交付方面实现了高效能的组织

 

二、组织效能

1，以前采用“IT效能”的说法

“IT效能”除了“软件交付效能”外，还包括IT服务台和其他支持职能工作。

2，现在采用“软件交付效能”的说法

包括"吞吐量throughput”和“稳定性stability”

吞吐量理解为发布快慢问题，稳定性理解为质量问题

1. 部署频率：部署代码的频率
2. 变更前置时间：从代码提交到代码成功运行在生产环境需要的时间）
3. 服务恢复时间：发生服务故障时（例如：计划外中断，服务受损），恢复服务通常需要的时间
4. 变更失败率：有多大比例的变更会导致服务降级或需要事后补救？（例如：需要热修复、回滚、前向恢复、补丁等）

 

3.本次又增加了“可用性”度量

从较高层面来说，可用性代表着技术团队和组织信守承诺并确保软件产品或服务可用的能力。对于最终用户而言，这意味着软件产品或服务是否能被访问和使用。我们的可用性度量范围包括：团队如何定义可用性目标，如何从服务中断中学习，如何确保反馈环的闭环性。

 

4.不要被“保守策略组织”误导

这些组织向我们及其利益相关方保证，低频次地发布代码是一个有效的策略。因为这样在各次部署之间就有更多的时间用于测试和质量检验，从而将失败/故障的可能性降到最低。

 

实际上，在日益复杂的系统中开展软件开发困难重重，失败/故障在所难免。然而，大体量的低频变更会给部署环节带来风险。一旦出现了失败/故障，找到问题的根源并恢复服务将非常困难。更糟糕的是，部署还可能会在整个系统里引发一连串其它的失败/故障。

5.SDO效能的定义：软件交付和运维效能

SDO中的S理解为软件（software）或者服务（service）均可。

 

 

6.转型的痛苦（图示第三阶段和第四阶段）

7.如何提升

（1）最初就把控质量

将时间和精力投入到开发新特性和支持基础设施的工作中，以有条理、有成效的方式，设计、构建和处理特性、测试和基础设施，为组织创造价值

 

（2）之后修补质量

花大量的时间修复缺陷、补救问题、回应缺陷和提供客户支持

 

我们应该多花时间在（1）上。

三、如何改进提高组织效能

1.云计算

在一些组织的云实施方案中，用户仍然需要先提交申请表才能访问一些关键资源并完成工作，或者不能从其设备轻松访问云系统。从消费方的角度看，这与使用传统的数据中心也没什么差别。这个巨大障碍会阻碍团队实现交付流程效率的提升，并从而成为更高效能的团队。

（1）云基础设施建设

云计算的五个核心特征

• 按需的自助服务

消费方可以根据需要自动预配计算资源，无需任何人为干预。

• 低门槛的网络接入

功能门槛低，可通过多种多样的平台（例如手机、平板电脑、笔记本电脑和工作站）接入并使用。

• 池化的资源

来自供给方的资源是多租户模式的资源池，按需动态分配和重新分配物理和虚拟资源。客户通常无法直接控制其所用资源的实际位置，但可以指定更高抽象级别的位置（例如：国家、州或数据中心）。

• 快速的弹性

弹性地供给和释放资源的能力，通过快速扩缩来动态地匹配需求。对于消费方而言：可用的容量看似是无限的，并且可以随时获得所需数量的资源。

• 可度量的服务

云系统在不同服务类型（例如存储、处理、带宽和活跃用户帐号）对应的各种抽象级别上，利用计量能力来自动化地控制和优化资源的使用情况。你可以监控、控制和报告资源的使用情况，以此确保透明度。

（2）PaaS 平台即服务

“消费方不用管理或控制底层的云基础设施，包括网络、服务器、操作系统或存储空间，而是控制所部署的应用，及使用托管环境所提供的配置和设置”

（3）基础设施即代码 IaC

在这个范式中，以自动化的方式从版本控制库里提取用来重建和变更环境状态的代码，而不是人工配置基础设施。

（4）云原生

根据云系统的固有限制而专门设计的应用程序被称为云原生。云中的系统假定运行在不可靠的底层基础设施上，并且必须进行容错设计。云原生应用必须具有复原能力，能够动态地响应工作负载的变化（即弹性），并且易于部署和按需管理。

（5）开源

开源是一个必然趋势

2.外包

（1）外包的好处

我们在传统上视“外包”为一种快速获取能力和资源的途径。除了能够解决短期项目或难以招聘到合适人员的项目的需求，外包还有助于降低成本；它减少了对内部员工的需求，并提供了技术劳动力的弹性。将某个独立的职能(例如：应用程序开发、测试和质量保证、服务运营）委托给外部供应商是一种流行的外包模式。

（2）外包的坏处

1. 增加了职能部门之间额外的交接需求和潜在的协作阻力。职能部门的职责划分可能会有损于敏捷性：一旦签订了合同，就很难再变更与外部实体（筒仓）之间的细节要求。
2. 往往会导致批量化地处理工作，从而造成过长的前置时间。因为在外包组织中，从开发到测试再到运维的事务处理成本相当高。当工作按项目或版本分为不同批次时，高价值和低价值的特性会混合在每次发布中，这意味着所有工作——无论是高价值的或是低价值的——都是以相同的速度交付。

（3）特例：“嵌入式”承包商的外包模式

承包和咨询公司所提供的额外员工的运转和行事方式都等同于主体组织内部的跨职能产品或技术团队，如果能保持软件开发和交付的节奏，其结果也很可能得到保障。

 

3. 精益和敏捷实践

（1）跨职能团队的重要性

Scrum团队由产品负责人、开发团队和Scrum Master组成。Scrum团队是自组织和跨职能的……跨职能团队拥有完成工作所需的所有能力，而不需要依赖团队之外的其他人

----摘自《scrum指南》

 

（2）精益产品管理

精益产品管理能力对软件交付效能、组织文化和绩效有积极影响。外包对软件交付效能有生负面影响，精益产品管理方式对可用性有正面影响。

现状（传统模式）：

• 在开始工作之前花费数月的时间来做预算、分析和收集需求；
• 将工作批量打包成大项目并集中地发布；
• 软件交付团队在如何完成其工作方面缺乏必要的指导；
• 客户反馈不能真正融入开发流程。

精益产品开发三个特点（好的实践）

• 团队将产品和功能分解成可在一周内完成的较小批量并做到频繁发布，其中包括最小可行产品（MVP）实践
• 积极和定期地寻求客户反馈，并运用反馈来指导产品设计。
• 作为开发流程的一部分，开发团队可以被授权在无需额外审批的情况下新增和变更产品要求。

4. 持续交付技术实践

（1）定义

那些在部署和交付中能够降低发布风险和成本的技术实践，我们统称其为持续交付技术实践。

内容包括：版本控制、部署自动化、持续集成、主干开发、松耦合架构，以及监控和可观察性解决方案、持续测试、将数据库变更集成到软件交付流程中，以及安全检查左移等实践

（2）如何衡量持续交付

• 在整个软件交付生命周期中，团队能够按需将软件部署到生产环境或交到最终用户手中。
• 团队中的每个人都可以获得有关系统质量和可部署性的快速反馈，并且根据这些反馈采取行动是团队成员的最首要任务。

（3）监控与可观察性

主动监控应用程序和基础架构并利用所得信息作出业务决策

（4）持续测试

• 由开发人员创建和维护快速、可靠的自动化测试套件；
• 开发人员可以轻松重现自动化测试并在测试失败时使用自己的开发环境进行修复
• 技术专业人员可以轻松使用测试数据来进行测试。
• 持续验证和优化测试套件，以更好地发现缺陷并管控复杂度和成本
• 允许测试人员在整个软件开发和交付过程中与开发人员一起工作
• 在整个交付过程中开展探索性测试、可用性测试和验收测试等人工测试活动
• 让开发人员在对代码库做任何变更时，先写单元测试再写生产代码，以实现测试驱动型开发
• 无论是在本地工作站还是CI服务器端，都可以在十分钟之内得到自动化测试的反馈结果

（5）管理数据库变更

现状：

在执行部署时，数据库的变更经常是风险和延期问题的主要根源。

好的实践：

• 良好的沟通，确保工程团队可以看到目标数据库的变更进度
• 把数据库包含在内的全面配置管理
• 把数据库的变更做成脚本存储在版本控制系统中
• 在管理数据库变更时采用与管理生产应用变更相同的方式。

（6）安全性和安全效能

现状：

• 信息安全团队往往人员配备不足
• 信息安全人员通常只在软件交付生命周期的最后阶段才参与进来，这时候再实施信息安全方面的改进，往往是痛苦而代价昂贵的。

好的实践：

• 信息安全人员应该在整个开发过程中与团队合作，并参与应用的设计（包括对所有主要功能进行安全性评审）
• 团队应在整个软件开发过程中执行测试来发现安全问题，使团队可以轻松用上已通过安全评估的库、软件包和工具链，并为团队提供可以参考的安全流程模板。

 

5. 文化

文化是DevOps和技术转型的重要组成部分。技术和管理实践塑造了文化，而文化反过来又有助于提高效能产出。

（1）三种文化类型的组织

 

（2）DevOps文化特点

协作、揭露问题（训练信使给我们带来坏消息，以便我们能够发现并修正问题）、打破孤岛（鼓励交流），事后回顾（失败时追根溯源），并通过坚持不懈的尝试来促成改进（接纳新想法）。

（3）如何塑造文化

• 通过领导力和自主权影响文化：领导者在工作中给予团队自主权时，信任感和发言权随之而来。
  1. 树立并传达目标，但是让团队自己决定该如何完成工作
  2. 通过简化规则消除障碍
  3. 如果规则阻碍了目标的实现，允许团队更改规则
  4. 允许团队按给客户带去的价值来安排工作优先级，即使这意味着要在一定程度上违背规则

• 通过学习影响文化

在DevOps和工程领域，这往往是通过回顾（也称为复盘）来完成的。在运维领域，经常在突发事件结束后进行复盘，以便了解如何改进系统以防止类似事件再次发生。这种做法有时被称为“事后回顾”。强调“不要指责”，利用回顾总结来实现对工具、过程或流程的改进，成效最为显著。

• 培养学习氛围

具有学习氛围的组织会把学习看做是一种投资，而不会把学习看成苦差。随着需求的不断改变，我们的工作环境变得越来越复杂，一个积极迎接改变并且不放过任何一个机会来学习新知识的组织文化，最终会取得领先地位。

如何营造学习氛围：

• 尽可能提供各种学习机会和资源。例如为参加培训和研讨会提供正式的预算，
• 组织骇客日、员工聚会、午餐研讨会等

 

参考原文下载：http://cn.mikecrm.com/LIm33ne