DevOps

DevOps（Development和Operations的组合词）是一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。

瀑布模式 -> 敏捷模式 -> DevOps模式

20221123859DevOps知识图谱

DevOps 的价值：

  1. 改善企业的软件交付过程，实现高质量和高效率的交付
  2. 改善企业内部的工程师文化，激发活力与创造

人、流程、平台

价值流分析

关键要素：

  1. 前置时间（Lead Time，简称 LT）。指一个需求从提出（典型的就是创建一个需求任务）的时间点开始，一直到最终上线交付给用户为止的时间周期。这部分时间直接体现了软件开发团队的交付速率，并且可以用来计算交付吞吐量。DevOps 的核心使命之一就是优化这段时长。
  2. 增值活动时间和不增值活动时间（Value Added Time/Non-Value Added Time，简称 VAT/NVAT）。在精益思想中，最重要的就是消除浪费，也就是说最大化流程中那些增值活动的时长，降低不增值活动的时长。
  3. 完成度和准确度（% Complete/Accurate，简称 %C/A）。这个指标用来表明工作的质量，也就是有多少工作因为质量不符合要求而被下游打回。

转型路径

企业实施 DevOps：

  1. 自底向上路径：

DevOps 实践通常从企业中的小团队或部门开始，目的是解决团队内部及与上下游团队协作中的问题。由于团队规模较小，资源调动相对简单，因此能在局部取得初步效果。为了扩大影响，这些实践者需要逐步向高层汇报并赢得管理层的认可，最终推动 DevOps 在整个企业中横向扩展。

  1. 自顶向下路径：

在这种模式下，企业高层基于对行业趋势的把握，通过行政命令推动 DevOps 转型。这种方式有明确的目标和资源支持，但容易出现“表面成功”的现象，即为了满足上级要求，团队可能会选择性地展示数据，未真正解决业务问题。因此，建立客观有效的度量标准至关重要。

无论选择哪种路径，管理层的支持都是关键。

业务敏捷

DevOps 最终的目标是促进交付能力的提升，以提升对业务的价值，但如果业务需求不明确，交付能力再高也难以提升整体业务价值

需求管理与优先级：

采用卡诺模型将需求划分为五类：兴奋型、期望型、必备型、无差别型和反向型

用户价值：

通过用户故事（代入用户场景描述需求）增强团队对需求价值的共识，使产品、研发和测试团队统一理解目标和用户价值

持续快速验证：

采用精益创业思想，通过最小可行产品（MVP）进行市场试验，获取真实反馈，从而持续迭代产品

软件开发的困难

软件发展的三个阶段

个体软件过程（PSP）

典型的用户期望

质量策略

基本流程

基本原理

过程度量

为什么要度量

体现决策者对要实现目标的关切程度高质量的开发是计划出来的

质量路径

评审手段消除缺陷比测试消除效率更高

有效的评审

敏捷软件开发

精益思想

精益看板

加快价值流动是精益看板的核心，以拉动式生产为典型特征，约束制品数量为实践，灵活响应业务变化，快速交付价值

第一步：可视化流程；

梳理价值交付流程，通过对现有流程的建模，让流程变得可视化，看板是一种方式

第二步：定义清晰的规则；

在流程可视化之后，需要定义规则以减少沟通成本，确保团队对看板操作的理解一致

第三步：限制在制品数量；

看板的核心环节，重点是限制需求流入和需求流出节点的在制品数量。通过减少并行任务，暴露团队的潜在问题，逐步优化交付效率

第四步：管理工作流程；

通过管理工作流程确保看板顺畅运转，常见的管理流程包括每日站会、队列填充会议和发布规划会议。重点关注任务的状态，尤其是阻塞、优先级高或长期停留的任务，确保价值流动的顺畅

第五步：建立反馈和持续改进；

精益看板的最终目标是通过反馈持续优化流程、工具和规则。通过不断的反馈和改进，提升团队的效率和交付质量，确保看板方法适应业务和团队的实际需求

DevOps成熟度模型

内建质量

将质量控制融入到整个生产或开发流程的各个环节中，而不是依赖于最终的检验来确保产品质量。这种方法的核心思想是尽早发现和修复问题，避免带有缺陷的产品进入后续流程，从而降低修复成本并提高整体质量

度量

目标：服务于持续、快速和高质量的交付。它们的目标是证明团队通过改进提高了交付速度和质量

指标特性：

指标原则：

一些核心指标类别：

软件架构演化

单体架构

全部功能被集成在一起作为一个单一的单元

分层架构

每一层有特定的职责，上层只能直接访问下层

面向服务架构

消息总线与服务编排引擎

微服务架构

围绕业务能力构建的可独立开发部署的小型单元，使用远程调用进行通信

挑战：

XaaS

什么 即 服务

SaaS 中心化的软件的分发方式，通过网络使用软件IaaS 虚拟化硬件资源给用户PaaS 提供给开发者使用

批注 2020-05-08 195722

IT服务标准

工具链

持续交付

批注 2020-05-08 202538

团队拓扑

  1. 业务流团队（Stream-aligned Team） 工作可能是一个产品或服务，也可能是一组特性、一个用户旅程或一个用户画像
  2. 赋能团队（Enabling Team） 由特定技术领域或产品领域的专家组成，对于技术问题开展调研，尝试不同的方案，寻找最佳实践
  3. 复杂子系统团队（Complicated-Subsystem Team） 业务逻辑十分复杂或者需要十分专业的领域知识，由该领域的专家组成一个固定的团队，来维护这个复杂的模块
  4. 平台团队（Platform Team）负责解决底层问题，让业务流团队可以更专注于业务开发

团队交互模式

  1. 协作（Collaboration）是指一个团队与另一个团队紧密合作
  2. 服务（X-as-a-Service）是指使用或提供某种服务，而尽量减少协作
  3. 促进（Facilitating）是指帮助其他团队清除障碍，赋能团队主要干的

持续改进

  1. 正向回溯和总结：在故障或问题发生后，进行详细分析，挖掘根本原因，提出具体改进措施，而不是仅仅确定责任。
  2. 预留固定改进时间：在日常工作中预留时间用于技术改进，保证持续改进的文化能在团队中生根发芽。
  3. 内部共享业务和技术指标：团队成员应对业务指标和 DevOps 度量数据保持透明，以此提高责任感和自驱力。
  4. 激发创造力并最大化价值：鼓励团队创新，并通过制度保障好的想法转化为有实际价值的工具或流程优化。

DevOps 平台建设

从无到有阶段：

这是企业 DevOps 平台的起步阶段，工具链体系不完善，仍有大量手工操作。主要任务是快速引入开源工具和商业工具，补齐能力短板，提升单点效率。选择主流、成熟的工具可以有效提升工作效率，解决团队最紧迫的需求。

从小到大阶段：

工具齐全后，企业面临的是工具稳定性、性能和规模化使用的问题。这一阶段的建议是采用半自建工具或定制商业工具，通过二次开发或封装满足业务需求。设计时需考虑未来扩展空间，并注重元数据治理，为后期的平台扩展和平台间的数据互通奠定基础。

从繁到简阶段：

平台逐步完善，但随着工具数量和复杂度增加，简化操作、统一平台成为关键。通过整合工具，统一界面，简化操作，实现一站式服务，并有效度量平台的价值。最终目标是实现自服务化，让用户能自主操作，简化使用流程

GitOps

DevOps 文化中的工程实践

sequenceDiagram  用户 ->> 代码仓库: 提交变更  其他用户 ->> 代码仓库: 变更审查  代码仓库 ->> 代码仓库: 合并变更  代码仓库 ->> 集群编排系统: 触发编排

FinOps

Finance + DevOps，FinOps 是一种文化实践，它为企业组织提供了一种管理云成本的理论和方法

FinOps 框架