devops理论梳理

devops理论梳理

是什么

维基百科解释：

DevOps（开发 Development 与运维 Operations 的组合词）是一种文化、
一场运动或实践，强调在自动化软件交付流程及基础设施变更过程中，软件
开发人员与其他信息技术（IT）专业人员彼此之间的协作与沟通。它旨在建
立一种文化与环境，使构建、测试、软件发布得以快速、频繁以及更加稳定
地进行

解决什么问题？

1. DevOps 最开始想要打破的就是开发和运维之间的对立和隔阂
2. 从一开始想要促进开发和运维的协作，团队慢慢发现，其实在整个软件交付过程中，不仅只有开发和运维，业务也是重要的一环。
   比方说，如果业务制定了一个不靠谱的需求，那么无论开发和运维怎样协作，得到的终究是一个不靠谱的结果，以及对人力的浪费。可是业务并不清楚用户的真实情况，于是运维团队慢慢转向运营团队，他们需要持续不断地把线上的真实数据和用户行为及时地反馈给需求团队，来帮助需求团队客观评估需求的价值，并及时作出有利于产品发展的调整，这样一来，业务也被引入到了 DevOps 之中
3. 如何快速地持续交付高质量的软件，满足用户的多样化需求，并借此提升企业的利润和市场占有率

概括的说devops定义：

DevOps 是通过平台（Platform）、流程（Process）和人（People）的有机整合，以C（协作）A（自动化）L（精益）M（度量）S（共享）文化为指引，旨在建立一种可以快速交付价值并且具有持续改进能力的现代化 IT 组织。

对比着CMMI、ITIL理解：

CMMI（Capability Maturity Model Integration）、ITIL（Information Technology Infrastructure Library）和 DevOps 是三种不同的 IT 管理和改进方法。它们之间有一定的关系，但各自侧重点不同：

1. CMMI 是一个过程改进方法和模型，主要关注软件开发和服务提供过程的成熟度，帮助组织实现可持续的性能改进。CMMI 包含多个成熟度级别，指导企业不断提高过程和产品质量。

2. ITIL 是一套 IT 服务管理（ITSM）最佳实践，关注 IT 组织如何有效地管理和提供业务所需的 IT 服务。ITIL 提供了一套全面的 ITSM 框架，涵盖了从服务战略、服务设计、服务过渡、服务运行到持续服务改进的整个生命周期。

3. DevOps 是一种文化和实践，旨在实现开发（Dev）和运维（Ops）团队之间的紧密协作。通过强调自动化、持续集成和持续交付，DevOps 有助于缩短产品上市时间、提高软件质量和提高业务敏捷性。

企业在实际应用中，可以根据自身的需求和目标，灵活地将这些模型框架结合起来，实现优势互补。以下是一些建议：

1. 根据业务需求和目标，分析不同框架的优势，明确各自在组织中的定位。例如，将 CMMI 用于改进开发和维护过程，将 ITIL 用于提升 IT 服务管理水平，将 DevOps 用于加速产品迭代和交付。

2. 逐步推进，逐个突破。企业可以先从一个框架开始，例如先引入 CMMI 提升开发过程的成熟度，然后逐步引入 ITIL 和 DevOps，以适应复杂多变的业务环境。

3. 保持沟通与协作。在实施多个框架时，保持各团队之间的交流和协作非常重要。通过定期的审查、沟通和培训，确保团队成员对各种框架的理解和应用都能达到预期。

4. 制定整合计划。在引入多个框架时，制定一个明确的整合计划，确保各个框架能够有序地进行协同和整合，实现组织的战略目标。

5. 持续改进。在实施多个框架的过程中，应不断监控和评估实施效果，根据实际情况进行调整和优化，确保持续改进和提升。

实践中，CMMI、ITIL 和 DevOps 可以相互补充，共同助力企业提高 IT 服务质量、提升业务敏捷性和实现持续改进。企业应根据自身实际情况，灵活运用多种框架，实现最佳业务效果。

软件观念革命—交互设计精髓》，该书提到软件开发领域的三次革命：

1. 高级语言 20世纪50年代，使软件开发从机器语言的束缚中解放出来。
2. 软件工程 20世纪70年代，使软件开发的注意力从语言拓展到开发过程。
3. 人机交互 20世纪90年代，人机交互理论改变了一般商用软件的设计开发流程和方式

devops价值

数字化转型下，软件慢慢从企业内部的支撑系统和成本中心，变成了企业服务的直接载体和利润中心。企业通过软件降低运营成本，提升服务水平，而用户在获得便利的同时，也加强了同企业之间的联系。

软件交付的效率和质量成了当今企业的核心价值和核心竞争力，所以，任何一家企业，无论是行业巨头还是初创公司，无论是互联网行业还是传统行业，无论是领先者还是颠覆者，都有强烈的意愿去改善自身的软件交付能力，而这恰恰和 DevOps 的理念和诞生背景不谋而合。

DevOps 的 4 个结果指标：

1. 部署频率：指应用和服务向生产环境部署代码的频率。
2. 变更前置时间：指代码从提交到成功运行在生产环境的时长。
3. 服务恢复时间：指线上应用和服务出现故障到恢复运行的时长。
4. 变更失败率：指应用和服务在生产环境部署失败或者部署后导致服务降级的比例。

DevOps 状态报告中提到的四项结果指标，分别代表了软件交付的两个最重要
的方面，也就是交付效率和交付质量。而且，从数据结果中，我们还能得到一个惊人的发现，那就是高效能的组织不仅做到了高效率，还实现了高质量

实施 DevOps，一方面可以通过种种流程优化和自动化能力，改善软件开发团
队的工作节奏，另一方面，也可以让大家关注同一个目标，彼此信任，高效协作，调动员工的积极性和创新能力，从而让整个团队进入一种积极创造价值的状态

devops实施

当一家企业好不容易接纳了 DevOps 的思想，并下定决心开始实施的时候，总会面临这样一个两难的选择：工具和文化，到底应该哪个先行？

需要先改变行为，再通过行为来改变文化。而改变行为最关键的，就是要建立一种有效的机制。就像我一直强调的那样，机制就是人们愿意做，而且做了有好处的事情。
某金融公司的案例，如果他们的老板只是喊了句口号“我们要在年底完成
DevOps 试点落地”，那么年底即便项目成功，本质上也不会有什么改变。相反，他们在内部建立了一种机制，包括 OKR 指标的设定、关键指标达成后的激励、成立专项的工作小组、引入外部的咨询顾问，以及一套客观的评判标准，这一切都保证了团队走在正确的道路上。而承载这套客观标准的就是一套通用的度量平台，说到底，还是需要将规则内建于工具之中，并通过工具来指导实践。
这样一来，当团队通过 DevOps 获得了实实在在的改变，那么 DevOps 所倡导的职责共担、持续改进的文化自然也会生根发芽。
所以你看，DevOps 中的文化和工具，本身就是一体两面，我们既不能盲目地奉行工具决定论，上来就大干快干地采购和建设工具，也不能盲目地空谈文化，在内部形成一种脱离实际的风气。

DevOps 的 3 个支柱

对工具和文化的体系化认知，可以归纳到devops的3个支柱中，即人、流程和平台。3个支柱两两组合，构成我们实施devops的正确方式：

• 人 + 流程 = 文化
  在具体的流程之下，人会形成一套行为准则，而这套行为准则会潜移默化地影响软件交付效率和质量的方方面面。这些行为准则组合到一起，就构成了企业内部的文化。
  指导 DevOps 落地发展的思想，就是 DevOps 的文化

举个例子，在谷歌 SRE 的实践中，研发交付的应用需要自运维一段时间，并且要在达到一定的质量指标之后才会交接给 SRE 进行运维。但是，为了避免出现“研发一走，运维背锅”的情况，他们还建立了“打回”的流程，也就是当 SRE 运维一段时间后，如果发现应用稳定性不达标，就会重新交还给开发自己负责维护，这样一来，研发就会主动地保障线上应用的质量。而且在这个过程，SRE 也会给予技术和平台方面的支持，从而形成了责任共担和质量导向的文化。

• 流程 + 平台 = 工具
  企业内部流程的标准化，是构成自动化的前提。试想一下，如果没有一套标准的规则，每一项工作都需要人介入进行判断和分析，那么结果势必会受到人的因素的影响，这样的话，又如何做到自动化呢？
  平台的最大意义，就是承载企业内部的标准化流程。
  平台上固化的每一种流程，其实都是可以用来解决实际问题的工具

区分工具和平台：平台除了有用户量、认可度、老板加持等因素之外，还会有 3 个显著特征。

1. 吸附效应：平台会不断地吸收中小型的工具，逐渐成为一个能力集合体。
2. 规模效应：平台的成本不会随着使用方的扩展而线性增加，能够实现规模化。
3. 积木效应：平台具备基础通用共享能力，能够快速搭建新的业务实现

• 平台 + 人 = 培训赋能

平台是标准化流程的载体，一方面可以规范和约束员工的行为，另一方面，通过平台赋能，所有人都能以相同的操作，获得相同的结果。这样一来，跨领域之间的交接和专家就被平台所取代，当一件事情不再依赖于个人的时候，等待的浪费就会大大降低，平台就成了组织内部的能力集合体

我们定义了期望达到的目标，并提供了平台工具，那么对人的培训就变得至
关重要，因为只有这样，才能让工具平台发挥最大的效用。更加重要的是，通过最终的用户使用验证，可以发现大量的可改进空间，进一步推动平台能力的提升，从而带动组织整体的飞轮效应，加速组织的进化。
所以你看，文化、工具和培训作为 DevOps 建设的 3 个重心，折射出来的是对组织流程、平台和人的关注，三位一体，缺一不可。

只有通过人、流程和平台的有机结合，在文化、工具和人员培训赋能领域共同推进，才能实现 DevOps 的真正落地实施

devops的衡量：实施路线图

任何技术的成熟，都是以模型和框架的稳定为标志的

DevOps 能力成熟度模型:

这套模型覆盖了软件交付的方方面面，包括敏捷开发管理、持续交付和技术运营三大部分，同时，也有与应用架构设计、安全和组织结构对应的内容。

步骤与原则

业界有这么多模型和框架，是不是随便找一个，直接照着做就行了呢？当然不是。

1. 识别差距:通过和模型、框架进行对标，可以快速识别出企业当前存在的短板和差距，并建立企业当前的能力状态基线，用于对比改进后所取得的效果
2. 锚定目标

• 数字化转型的核心在于优化软件交付效率
• 通过现状分析，企业可以把有限的资源聚焦在那些高优先级的任务上，识别出改进目标和改进后要达到的预期效果。这些效果需要尽量客观和可量化，比如缩短 50% 的环境准备时长

1. 关注能力:根据锚定目标识别所需的能力，再导入与能力相匹配的实践，不断强化实践，使能力本身得到提升。
2. 持续改进

DevOps作为一个系统性工程，同样需要与之配套的立体化实施方法，只有将方法、实践和工具结合起来，全方位推进，才有可能获得成效

附：
能力成熟度模型，并基于模型对企业现有的能力水平进行了一次全盘梳理

摘录自极客时间《DevOps 实战笔记》