DevOps实战笔记
2023-09-15 17:41:41 0 举报AI智能生成
DevOps实战笔记
作者其他创作
大纲/内容
为什么是DevOps
一定会有一种更好的软件开发方式，在这种方式下，团队间沟通和协作的重要性一点也不亚于写代码、写文档、做测试之类的常规工作
如何快速地持续交付高质量的软件，满足用户的多样化需求，并借此提升企业的利润和市场占有率，已经成为企业必须要面对的现实问题
软件开发过程的改进，除了依赖于技术进步，还依赖于流程、理念、文化等全方位的改进，而这正是 DevOps 带给软件开发方式的一场革命
个人认为，DevOps 已经成为了所有 IT 从业人员应知应会的必备技能
如何学习DevOps
如何梳理出一套清晰的 DevOps 理念和完整的知识体系？
如何获得一线大厂的实践经验，让 DevOps 真正落地？
如何获得一条渐进式的 DevOps 学习曲线，让自己在正确的方向上不断增值？
四个板块
基础理论篇
落地实践篇
平台工具篇
转型案例篇
基础理论篇
DevOps究竟要解决什么问题？
维基百科对于DevOps的定义
DevOps（开发 Development 与运维 Operations 的组合词）是一种文化、一场运动或实践，强调在自动化软件交付流程及基础设施变更过程中，软件开发人员与其他信息技术（IT）专业人员彼此之间的协作与沟通。它旨在建立一种文化与环境，使构建、测试、软件发布得以快速、频繁以及更加稳定地进行。
回顾一下软件工程的三个阶段
瀑布式开发模式
敏捷式开发模式
DevOps
自己的定义
DevOps 是通过平台（Platform）、流程（Process）和人（People）的有机整合，以 C（协作）A（自动化）L（精益）M（度量）S（共享）文化为指引，旨在建立一种可以快速交付价值并且具有持续改进能力的现代化 IT 组织。
DevOps有什么样的价值？
为什么软件如此重要？
软件慢慢从企业内部的支撑系统和成本中心，变成了企业服务的直接载体和利润中心
软件交付的效率和质量成了当今企业的核心价值和核心竞争力
高效的软件交付方式
DevOps的4个结果指标
部署频率：指应用和服务向生产环境部署代码的频率。
变更前置时间：指代码从提交到成功运行在生产环境的时长。
服务恢复时间：指线上应用和服务出现故障到恢复运行的时长。
变更失败率：指应用和服务在生产环境部署失败或者部署后导致服务降级的比例。
体系化的研发实践导入、软件架构的整体革新、组织管理理念、企业文化
激发团队的创造力
可以通过种种流程优化和自动化能力，改善软件开发团队的工作节奏
可以让大家关注同一个目标，彼此信任，高效协作，调动员工的积极性和创新能力
DevOps的实施：到底是工具先行还是文化先行？
DevOps 工具
高效率和高质量是 DevOps 的核心价值，而工具和自动化就是提升效率最直接的手段，让一切都自动化可以说是 DevOps 的行为准则。
DevOps三个支柱
人 + 流程 = 文化
在具体的流程之下，人会形成一套行为准则，而这套行为准则会潜移默化地影响软件交付效率和质量的方方面面。这些行为准则组合到一起，就构成了企业内部的文化。
流程 + 平台 = 工具
而平台的最大意义，就是承载企业内部的标准化流程
平台上固化的每一种流程，其实都是可以用来解决实际问题的工具
平台的显著特征
吸附效应：平台会不断地吸收中小型的工具，逐渐成为一个能力集合体。
规模效应：平台的成本不会随着使用方的扩展而线性增加，能够实现规模化。
积木效应：平台具备基础通用共享能力，能够快速搭建新的业务实现。
平台 + 人 = 培训赋能
DevOps的衡量：你是否找到了DevOps的实施路线图？
CMMI 模型（软件能力成熟度模型）
CMM是一种用于评价软件承包能力并帮助其改善软件质量的方法，侧重于软件开发过程的管理及工程能力的提高与评估。CMM分为五个等级：一级为初始级，二级为可重复级，三级为已定义级，四级为已管理级，五级为优化级。
初始级(initial)
工作无序，项目进行过程中常放弃当初的计划。管理无章法，缺乏健全的管理制度。开发项目成效不稳定，项目成功主要依靠项目负责人的经验和能力，他一旦离去，工作秩序面目全非
可重复级(Repeatable)
管理制度化，建立了基本的管理制度和规程，管理工作有章可循。 初步实现标准化，开发工作比较好地按标准实施。 变更依法进行，做到基线化，稳定可跟踪，新项目的计划和管理基于过去的实践经验，具有复现以前成功项目的环境和条件
已定义级(Defined)
开发过程，包括技术工作和管理工作，均已实现标准化、文档化。建立了完善的培训制度和专家评审制度，全部技术活动和管理活动均可控制，对项目进行中的过程、岗位和职责均有共同的理解
已管理级(Managed)
产品和过程已建立了定量的质量目标。开发活动中的生产率和质量是可量度的。已建立过程数据库。已实现项目产品和过程的控制。可预测过程和产品质量趋势，如预测偏差，及时纠正
优化级(Optimizing)
通过采用新技术、新方法，集中精力改进过程。具备防缺陷、识别薄弱环节以及改进的手段。可取得过程有效性的统计数据，并可据此进行分析，从而得出最佳方法
DevOps 框架、模型
Atlassian
文化 (Culture)、自动化 (Automation)、精益 (Lean)、衡量 (Measurement) 和分享 (Sharing)
CloudBees
CA
参考
步骤与原则
每家企业所处的行业现状、竞争压力、市场竞争态势都不尽相同，组织架构、战略目标、研发能力、资源投入等方面也千差万别，很难有一条标准的路径，让大家齐步走
1.识别差距
通过和模型、框架进行对标，可以快速识别出企业当前存在的短板和差距，并建立企业当前的能力状态基线，用于对比改进后所取得的效果
2.锚定目标
3.关注能力
4.持续改进
关注价值、关注现状、交互式流程和反馈、协作和可视化、自动化和持续优化、极简原则和关注实践。
落地实践篇
价值流分析：关于DevOps转型，我们应该从何处入手？
DevOps 三步工作法
第一步：流动。通过工作可视化，限制在制品数量，并注入一系列的工程实践，从而加速从开发到运营的流动过程，实现低风险的发布
第二步：反馈。通过注入流动各个过程的反馈能力，使缺陷在第一时间被发现，用户和运营数据第一时间展示，从而提升组织的响应能力
第三步：持续学习和试验。没有任何文化和流程是天生完美的，通过团队激励学习分享，将持续改进注入日常工作，使组织不断进步
VSM 究竟是个啥玩意儿呢？
VSM 是 Value Stream Mapping 的缩写，也就是我们常说的价值流图
价值就是那些带给企业生存发展的核心资源，比如生产力、盈利能力、市场份额、用户满意度等
VSM 中有哪些关键要素和概念
前置时间（LT）
它是指一个需求从提出的时间点开始，一直到最终上线交付给用户为止的时间周期
需求前置时间
从需求提出（创建任务），到完成开发、测试、上线，最终验收通过的时间周期，考查的是团队整体的交付能力，也是用户核心感知的周期。
开发前置时间
从需求开始开发（进入开发中状态），到完成开发、测试、上线，最终验收通过的时间周期，考查的是团队的开发能力和工程能力。
增值活动时间和不增值活动时间（VAT/NVAT）
典型的不增值活动有很多，比如无意义的会议、需求的反复变更、开发的缺陷流向下游带来的返工等
完成度和准确度（%C/A）
这个指标用来表明工作的质量，也就是有多少工作因为质量不符合要求而被下游打回
VSM价值
看见全貌
DevOps 追求的是价值流动效率最大化
对于全局交付的建模，最终也会体现到软件持续交付流水线的建设上
识别问题
促进沟通
驱动度量
价值展现
转型之路：企业实施DevOps的常见路径和问题
自底而上
寻求管理层的认可和支持都是一个必选项
通用路径
第 1 步：寻找合适的试点项目
贴近核心业务
倾向敏捷业务
改进意愿优先
第 2 步：寻找团队痛点
第 3 步：快速建立初期成功
第 4 步：快速展示和持续改进
业务敏捷：帮助DevOps快速落地的源动力
Devops落地的业务价值
交付能力的提升，可以帮助业务以最小的成本进行试错，将新功能快速交付给用户。同时，用户和市场的情况又能够快速地反馈给业务方，从而帮助业务校准方向。而业务的敏捷能力高低，恰恰体现在对功能的设计和需求的把握上，如果不能灵活地调整需求，专注于最有价值的事情，同样会拖累交付能力，导致整体效率的下降
所以，开发更少的功能，聚焦用户价值，持续快速验证，就成了产品需求管理的核心思想
需求分析-影响地图
Why 代表目标，它可以是一个核心的业务目标，也可以是一个实际的用户需求
Who 代表影响对象，也就是通过影响谁来实现这个目标
How 代表影响，也就是怎样影响用户以实现我们的目标
What 代表需要交付什么样的功能，可以带来期望的影响
卡诺模型（Kano Model）
是日本大师授野纪昭博士提出的一套需求分析方法，它对理解用户需求，对其进行分类和排序方面有着很深刻的洞察
兴奋型
指超乎用户想象的需求，是可遇不可求的功能。比如用户想要一个更好的功能手机，乔布斯带来了 iPhone，这会给用户带来极大的满足感
期望型
用户的满意度会随着这类需求数量的增多而线性增长，做得越多，效果越好，但难以有质的突破。
必备型
这些是产品必须要有的功能，如果没有的话，会带来非常大的影响。不过有这些功能的话，也没人会夸你做得有多好，比如安全机制和风控机制等
无差别型
做了跟没做一样，这就是典型的无用功。比如你花了好大力气做了一个需求，但是几乎没有用户使用，这个需求就属于无差别型
反向型
无中生有类需求，实际上根本不具备使用条件，或者用户压根不这么想。这类需求做出来以后，通常会给用户带来很大的困扰，成为被吐槽的对象
识别优先级
优先规划期望型和必备型需求，将其纳入日常的交付迭代中，保持一定的交付节奏
识别无差别型和反向型需求，这些对于用户来说并没有产生价值。如果团队对需求的分类有争议，可以进一步开展用户调研和分析
追求兴奋型需求
让数据说话，为需求的价值建立反馈机制，而这里提到的价值，就是用户价值
用户故事（User Story）
用户故事则是以用户的价值为核心，圈定一种角色，表明通过什么样的活动，最终达到什么样的价值。团队在讨论需求的时候，采用一种讲故事的形式，代入到设定的用户场景之中，跟随用户的操作路径，从而达成用户的目标，解决用户的实际问题。这样做的好处在于，经过团队的共同讨论和沟通，产品、研发和测试对需求目标可以达成共识，尤其是对想要带给用户的价值达成共识
INVEST 原则
Independent（独立的）
减少用户故事之间的依赖，可以让用户故事更加灵活地验证和交付，而避免大批量交付对于业务敏捷性而言至关重要
Negotiable（可协商的）
用户故事不应该是滴水不漏、行政命令式的，而是要抛出一个场景描述，并在需求沟通阶段不断细化完成
Valuable（有价值的）
用户故事是以用户价值为核心的，所以每个故事都是在对用户交付价值，所以要站在用户的视角思考问题，避免像最近特别火的那句话一样：“我不要你觉得，我要我觉得。
Estimatable（可评估的）
用户故事应该可以粗略评估工作量，无论是故事点数还是时间，都可以。如果是一个预研性质的故事，则需要进一步深挖可行性，避免不知道为什么做而做
Small（小的）
用户故事应该是最小的交付颗粒度，所以按照敏捷开发方式，无论迭代还是看板，都需要在一个交付周期内完成
Testable（可测试的）
也就是验收条件，如果没有办法证明需求已经完成，也就没有办法进行验收和交付
MVP原则
BizDevOps 的核心理念
对齐业务和开发目标、指标
把握安全、合规指标
及时对齐需求，减少无用开发
体现 DevOps 的价值
让开发团队开始接触业务，不单单是执行，调动积极性
精益驱动的敏捷开发方法
利特尔法则
平均吞吐率 = 在制品数量 / 平均前置时间
精益看板的实践方法
第一步：可视化流程
第二步：定义清晰的规则
第三步：限制在制品数量
第四步：管理工作流程
第五步：建立反馈和持续改进
配置管理：最容易被忽视的DevOps工程实践基础
配置管理是DevOps工程实践的基础
版本变更标准化
提交概要信息
简明扼要地用一句话说明这个改动实现了哪些功能，修复了哪些问题
提交详细信息
详细说明改动的细节和改动方式，是否有潜在的风险和遗留问题等
提交关联需求
是哪次变更导致的这次提交修改，还需要添加上游系统编号以关联提交和原始变更
一套标准化的规则和行为习惯，可以降低协作过程中的沟通成本，一次性把事情做对，这也是标准和规范的重要意义
可以说，标准化是自动化的前提，自动化又是 DevOps 最核心的实践
将一切纳入版本控制
软件源代码、配置文件、测试编译脚本、流水线配置、环境配置、数据库变更等等，你能想到的一切，皆有版本，皆要被纳入管控
全程版本控制赋予了我们全流程追溯的能力
如果这个产物可以通过其他产物来重现，那么就可以作为制品管理，而无需纳入版本控制
全流程可追溯
把握源头，建立主线
所有的变更都来源于需求
单一可信数据源
分支策略：让研发高效协作的关键要素
主干开发，分支发布
以发布为目的
这条分支存在的意义不是开发新功能，而是对现有功能进行验收，并在达到一定的质量标准后对外发布
短分支
这条发布分支一般不会存在太长时间，只要经过回归验证，满足发布标准后，就可以直接对外发布
优势
对于研发团队来说，只有一条主线分支，不需要在多条分支间切换
在发布分支拉出之后，主干分支依然处于可集成状态，研发节奏可以保持在一个相对平稳的状态
发布分支一般以版本号命名，清晰易懂，线上哪个版本出了问题，就在哪个分支上修复
缺点和挑战
它对主线分支的质量要求很高
它对团队协作的节奏要求很高
在主线和发布分支并存期间，有可能会导致两边提交不同步的情况
分支开发，主干发布
前置条件
特性拆分得足够小
有强大的测试环境作支撑
要有一套自动化的特性管理工具
优势
分支开发相对比较独立，不会因为并行导致互相干扰
一个特性所关联的所有代码可以保存在一条特性分支上
缺点和挑战
特性的粒度和分支存活的周期是关键要素。根据经验来看，分支存活的周期一般不要超过一周
对特性分支的命名规范要求很高
特性分支的原子性和完整性
主干开发，主干发布
持续集成：你说的CI和我说的CI是一回事吗？
CI（Continuous Integration）
持续集成
自己所在的项目和团队在践行 CI
每一次代码提交，是否都会触发一次完整的流水线？
每次流水线是否会触发自动化的测试环节？
如果流水线出现了问题，是否能够在 10 分钟之内修复？
CI 涵盖了三个阶段
第一阶段：每次提交触发完整的流水线
打通版本控制系统和持续集成系统
GitLab 和 Jenkins 的集成
统一的分支策略
清晰的集成规则
标准化的资源池
足够快的反馈周期
第二阶段：每次流水线触发自动化测试
匹配合适的测试活动
树立测试结果的公信度
提升测试活动的有效性
第三阶段：出了问题可以在第一时间修复
自动化测试：DevOps的阿克琉斯之踵
测试误报率是体现自动化测试稳定性的一个核心指标
自动化测试误报率 = 非开发变更引入的问题用例数量 / 测试失败的用例数量
内建质量：丰田和亚马逊给我们的启示
为什么内建质量这么重要？
内建质量扭转了看待产品质量的根本视角，也就是说，团队所做的一切不是为了验证产品存在问题，而是为了确保产品没有问题。
内建质量有两个核心原则
问题发现得越早，修复成本就越低
质量是每个人的责任，而不是质量团队的责任
内建质量的实施思路
第一步：选择适合的检查类型
单元测试
代码风格检查
代码缺陷和漏洞检查
安全检查
第二步：定义指标并达成一致
质量门禁
第三步：建立自动化执行和检查能力
第四步：定义问题处理方式
第五步：持续优化和改进
技术债务：那些不可忽视的潜在问题
技术债务分类
不能均匀分布的复杂性
重复代码
不合适的注释
违反代码规范
缺乏单元测试
缺陷和潜在缺陷
设计和系统架构
不合理的架构
过时的技术
冷门的语言
为什么要重视技术债务？
额外的研发成本
不稳定的产品质量
难以维护的产品
如何量化技术债务？
SonarQube
技术债是基于 SQALE 方法计算出来的
技术债务比例 = 修复已有技术债务的时间 / 完全重写全部代码的时间
环境管理：一切皆代码是一种什么样的体验？
环境管理的挑战
环境种类繁多
环境复杂性上升
环境一致性难以保证
环境交付速度慢
环境变更难以追溯
基础设施即代码
CAPS 为代表的自动化环境配置管理工具
部署管理：低风险的部署发布策略
低风险的发布手段
蓝绿部署
一套是蓝环境，一套是绿环境，每次只有一套环境提供线上服务
灰度发布
暗部署
线上测试和监控
采用灰度发布、用户众测等方式，逐步观察用户行为并收集用户数据，以验证新版本的可用性是否符合预期
用户反馈
使用线上流量测
混沌工程：软件领域的反脆弱
服务可用性实践
正向度量：如何建立完整的DevOps度量体系？
如何定义指标？
明确受众
指标不能脱离受众而单独存在，在定义指标的同时，要定义它所关联的对象，也就是这个指标是给谁看
直指问题
你一看到这个指标，就能意识到问题所在，并自然而然地进行改进
量化趋势
按照 SMART 原则，好的指标应该是可以衡量的，而且是可以通过客观数据来自证的
充满张力
好的指标应该具有一定的张力，向上可以归并到业务结果，向下可以层层分解到具体细节
定义指标有哪些原则？
全局指标优于局部指标
过度的局部优化可能对整体产出并无意义，从而偏离了度量的核心，也就是提升交付速度和交付质量
综合指标优于单一指标
单一维度入手会陷入只见树木不见森林的困境，综合指标更加客观。所以，要解决一个问题，就需要一组指标来客观指引
结果指标优于过程指标
首先要有结果指标，以结果为导向，以过程为途径，一切过程指标都应该归结到结果指标
团队指标优于个人指标
优先考核团队指标而非个人指标，团队共享指标有助于形成内部合力，减少内部的割裂
灵活指标优于固化指标
指标的设立是为了有针对性地实施改进，需要考虑业务自身的差异性和改进方向，而非简单粗暴的“一刀切”，并且随着团队能力的上升，指标也需要适当的调整，从而不断挑战团队的能力
哪些指标最重要？
交付效率
需求前置时间
从需求提出到完成整个研发交付过程，并最终上线发布的时间
开发前置时间
从需求进入排期、研发真正动工的时间点开始，一直到最终上线发布的时长
交付能力
发布频率
单位时间内的系统发布次数
发布前置时间
指研发提交一行代码到最终上线发布的时间
交付吞吐量
单位时间内交付的需求点数
交付质量
线上缺陷密度
单位时间内需求缺陷比例
线上缺陷分布
所有缺陷中的严重致命等级缺陷所占的比例
故障修复时长
从有效缺陷提出到修复完成并上线发布的时间
持续改进
平台工具篇
开源还是自研：企业DevOps平台建设的三个阶段
阶段一：从无到有
建议是：引入开源工具和商业工具，快速补齐现有的能力短板
如何选择工具
需求管理工具 Jira
知识管理工具 Confluence
版本控制系统 GitLab
持续集成工具 Jenkins
代码质量工具 SonarQube
构建工具 Maven/Gradle
制品管理 Artifactory/Harbor
配置管理工具 Ansible
配置中心 Apollo
测试工具 RF/Selenium/Appium/Jmeter/TestNG
安全合规工具 BlackDuck/Fortify
...
阶段二：从小到大
阶段三：从繁到简
持续交付平台：现代流水线必备的十大特征
十大特征
特性一：打造平台而非能力中心
流水线平台有一个非常典型的特征，那就是，它是唯一一个贯穿软件交付端到端完整流程的平台
正确的做法是，将持续交付流水线平台和垂直业务平台分开，并定义彼此的边界
流水线平台仅作为任务的调度者、执行者和记录者，并不需要侵入垂直业务平台内部。
特性二：可编排和可视化
所谓的流程可编排能力，就是指用户可以自行定义软件交付过程的每一个步骤，以及各个步骤之间的先后执行顺序
特性三：流水线即代码
借助版本控制系统的强大功能，流水线代码和业务代码一样纳入版本控制系统，可以简单追溯每次流水线的变更记录
特性四：流水线实例化
流水线需要支持参数化执行
流水线的每一次执行，都可以理解为是一个实例化的过程
流水线需要支持并发执行能力
特性五：有限支持原则
流水线的设计目标，应该是满足大多数、常见场景下的快速使用，并提供一定程度的定制化可扩展能力，而不是满足所有需求
特性六：流程可控
流水线的主要作用是驱动软件交付过程的效率提升和状态可视化
特性七：动静分离配置化
动静分离就是一种配置化的实现方式
特性八：快速接入
在建设流水线平台的时候，能否快速地实现外部平台能力的接入，就成了一个必须要解决的问题
特性九：内建质量门禁
特性十：数据聚合采集
0 条评论
下一页
