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