导图社区 DevOps实践精要(DevOps Master认证讲义知识精解)
DevOps是什么?DevOps是如何产生的,DevOps的理论基础是什么,与敏捷和精益的关系是怎样的?DevOps的应用和实践,可视化看板、流水线、在制品限制、持续迭代等。DevOps Master认证考试讲义精解
编辑于2022-09-23 16:17:43 北京市社区模板帮助中心,点此进入>>
DevOps 实践精要
什么是DevOps
IT管理的转变
IT管理方法不是一成不变的。信息系统开发和运维所使用的方法与几十年前明显有别
IT管理从聚焦于IT系统,转变为聚焦于管理IT服务
IT实践的发展
新涌现出来的实践,被打上了“DevOps”(开发+运维)的标签
DevOps的内涵,已经大大超出其原始的含义
如同ITIL 超出 “ 库 的概念、 COBIT 超出受控对象的含义一样,
DevOps的起源
DevOps的出现源于两个因素
敏捷软件方法的广泛采用
IT 基础设施即程序代码的管理方式
瀑布软件开发模型
每个阶段所涉及的人员职能 被专业化分工
当开发的是功能可预先定义、对快速产品交付没要求的大型信息系统时 这个模型能够确保我们创建高质量产品,并进行有效与精细的成本控制
有效应对市场机会而不延误截止日期、不降低产品质量,极为困难
瀑布模型示意图
经典的项目管理约束金字塔
基线编程(XP)
只关注在软件开发周期的其中一个阶段上
—— 即实际开发阶段
敏捷软件开发方法
优点
端到端的软件开发周期进行了简化加速
极大地加速与促进软件的开发和重构
更重视左项的价值
敏捷宣言
个体和交互 胜于 流程和工具 可工作的软件 胜于 面面俱到的文档 客户协作 胜于 合同谈判 响应变化 胜于 遵循计划
敏捷原则
通过持续不断地及早交付有价值的软件使客户满意
欣然面对需求变化,为了客户的竞争优势,敏捷过程掌控变化
经常地交付可工作的软件,倾向于采取较短的周期
业务人员和开发人员必须相互合作
激发个体的斗志,以他们为核心搭建项目
提供所需的环境和支援,辅以信任,从而达成目标
传递信息效果最好效率也最高的方式是面对面的交流
可工作的软件是进度的首要度量
敏捷过程倡导可持续开发
坚持不懈地追求技术卓越和良好设计
极力减少不必要工作量的艺术
最好的架构、需求和设计出自自组织团队
团队定期地反思如何能提高成效
敏捷开发的关键要素
客户与开发者之间更紧密的交互
批量大小的降低
以短间隔(周期)交付的产品
团队的有限规模
使用敏捷方法
软件开发团队每隔2到4周发布一个新的可行产品
最终用户可以更近距离地参与到开发过程当中
快速的反馈,并由此激发更快速的变更
使用敏捷的误区
敏捷收益缺失,通常与瀑布的优势或者敏捷的劣势无关
在开发之前还有不少的环节,要关注项目的全价值链
在开发之后应用需要快速部署到生产环境 以便客户能接收到向他/她们承诺的所有收益
获取IT预算是一件十分困难的事情,新采购的预算流程过长
触碰IT基础设施相当不安全,变更对IT运维部门来说很困难
先进的软件开发方法由于IT运维侧的阻碍而停滞不前
管理基础 设施即代码
两种技术的涌现
虚拟化
虚拟化使有效地使用硬件成为可能
在系统软件之间引入了额外的抽象层
云计算
按需的自服务
宽泛的网络接入。
资源的池化。
快速的伸缩性
可度量的服务。
DevOps定义
DevOps是敏捷软件开发与精益生产思想的一种演进
应用到IT端到端的价值链中,使得业务基于现代信息技术,通过文化、组织与技术变革而获得更大的成功
DevOps的4大要点
DevOps并没有取代敏捷及精益实践
DevOps本质是IT部门与业务部门所考虑不仅是软件开发,而是整个价值链
应用DevOps所获得的预期价值也很重要
关注3大基本要素:文化、组织和技术手段
DevOps关注的3个基本要素
DevOps的价值体现
加速新产品及产品补丁面向市场
更快响应客户需求
改善IT系统可用性与可持续性
更高效使用有限资源
DevOps内涵
a. 敏捷软件开发与精益生产思想的一种演进,
b. 应用到IT端到端的价值链中,
c. 使得业务基于现代信息技术,
d. 通过文化、组织与技术变革而获得更大的成功
为什么要实施DevOps
背景:时间跨度包含的环节
针对一种或若干种业务想法构建、起草方案,并进行论证;
评估和选择一个业务想法来实施;
规划实施所需要的行动,并获取资金;
准备人员和业务流程;
与此同时:规范化需求、开发原型、初始化测试、开发完整特性的IT系统、 全面的测试、发布和部署;
与此同时:进行市场活动、准备市场营销、准备销售渠道和工具
发布新的产品或服务
好处一:缩短市场响应时间
DevOps的相关技术
降低批量大小
减少移交次数
持续识别
消除损耗
DevOps组织遵循 “ 为速度而优化(Optimize for speed) 的模式
IT部门被视为一个真正的业务伙伴而非成本中心
好处二:减少技术债务
当程序员选择一个非最优的方式来解决问题以缩短开发时间时,技术债务就产生了
Martin Fowler的技术债务矩阵
DevOps密切关注如何减少技术债务,或者说是管理技术债务
如何实现
持续重构程序代码,将运维中获得的经验吸纳进来
规划相应的工作来消除之前出现的瓶颈
DevOps强烈推荐应用“尽可能频繁地直面问题”的实践
好处三:消除脆弱性
现状
大多数组织的IT基础设施处在非常脆弱的状态
混乱其实就是这个时代下公司信息技术领域日常的真实写照
在传统范式里,新代码在测试证明它可工作之前,是不可运维的
脆弱的原因
• 技术解决方案是多年以来逐步地、基于不同组件基础之上构建的;
• 使用大型的第三方系统,针对公司目标进行了大量的定制;
• 使用内部开发的遗留系统,而关键的程序员和团队已经不在公司了;
• 大量的系统以非常繁杂的方式相互耦合在一起, 并且与外部数据源及消费者集成;
• 由于需要快速实施的需要以及预算的限制,解决方案的质量经常不是最优的;
• 维护与支持工作增加了许多临时变通方案(“拐杖”), 仅考虑让系统能运行下去;
• 程序代码、架构、基础设施、技术解决方案乃至合同责任的文档,非常不尽如人意。
如何做到
DevOps提出以最激进的方式改变IT系统的脆弱性,即完全消除它
DevOps中代码与系统作为一个整体,在任何时间都是完全可运行的
反脆弱系统可以从功能障碍和混乱中持续演进
反脆弱实践
弹性系统的设计,是基于它们固有的复杂性和脆弱性
设计容忍失败和灾难恢复的机制,这样就不用太 担心失败可能造成的负面影响
在生产环境有意引入混乱与不稳定性
DevOps着力处理的三个任务
缩短市场响应时间
减少技术债务
消除脆弱性
关于DevOps的一些误解
DevOps是敏捷的一部分
目标很简单:更频繁地交付价值
DevOps把“敏捷开发”的想法延展到了整体的敏捷IT交付、 整个组织、整个流程以及整个价值链
从DevOps 中获得回报,通常需要更大的公司文化变革
DevOps的目标集,并不仅限于加速交付,还包括减少技术债务和消除脆弱性
DevOps是工具和自动化
DevOps确实依赖于某种自动化工具的可用性与有效性
但是没有也不可能有一个放之四海而皆准的DevOps必选软件列表
DevOps具体实施可以独立于工具软件
DevOps是一个新的职业
具备实施软件交付流水线的能力,也不能保证取得成功
实施DevOps的实践,也不太会节省成本
DevOps理论基础
精益生产
含义
精益生产可以被缩小为识别与消除浪费
浪费的三个层面(3M)
Muri (超负载)
价值存疑的工作
Mura (不均衡)
不均衡的需求水平, 这些需求分散着、波动着
Muda (浪费)
工作期间发生的浪费
浪费类型的对比
工作中的浪费
管理成本(基本上是由管理者而非员工完成的任何事情);
不满足客户期望或需求的产品或服务(与品质的经典定义一致);
未发挥员工的潜在创造性和智力;
未能调动员工的资源来改进流程和技术;
不充足的员工培训;
使用不正确的度量,或根本没有使用度量;
对信息系统的低效使用(低质量的自动化及对信息技术的无效应用产生的浪费,如工作期间的游戏与社交聊天)
精益生产思想的实际应用
使用专门工具来识别浪费;
应用其他的专门工具来消除或减少浪费;
利润!!!
敏捷
事实
组建小的独立且自给的团队(最多10~12人)
聚焦于有限的范围
通过基于冲刺(Sprint)的迭代过程,创建并测试程序代码
每个迭代交付出一个可行的产品
维护一个功能与非功能需求的列表(backlog),作为下个迭代计划的输入
把大的任务分解为小的部分(故事),以约定的工作负载单位进行评估并排序
客户代表积极参与到过程中
团队定期召开短时间的站立会议,讨论任务计划、进展与当前困难
进行定期的回顾,以帮助团队自我学习及改善其工作
挑战
敏捷仅覆盖到价值链的一部分,这也导致了总 体效果的差强人意
敏捷开发方法并未考虑到信息技术运维工作的特点与复杂性
对于运维来说方法的可应用性有所下降
团队的工作就会被限定为固定重复的工作迭代,精神上的满足感越来越少
敏捷带来的问题
许多检视失败的发起人处在直接的商业利益当中
假装敏捷不是一项业务
掩盖困难与负面案例
没有说清楚有些实践可行或不可行的上下文,不断回归教条化
价值主张模糊且未经证明
想当然地进行规模化
增加及累积技术债务
相关框架
Scrum
LeSS、SAFe
如何解决敏捷框架中的问题
去应用实际知识与技能
促进敏捷实践进一步演进到DevOps中
DevOps原则
价值流
部署流水线
实施部署流水线带来的挑战
忽视理念(流程、人与文化)的对自动化的过度热情
没有足够的已开发的测试来确保流水线的稳定运行
实施后期,测试运行过多,导致一个变更流经流水线花费时间过长
一切都应存储在版本控制系统中
自动化配置管理
任何环境的任何变更,只能通过存储在版本控制系统里的脚本来实施
所有的变更都需要受控,系统可以被快速地重置到稳定状态
完成的定义
要等到客户接收到或者开始接收其所预期的价值才算完成
意味着整个价值流已经被完整地流经,一直到生产环境
有助于团队将工作聚焦在结果即客户价值上
消除掉对具体领域工作的有限的责任
取而代之的是对团队整体结果的共有责任
DevOps关键实践
和传统实践的关键区别
发布是日常活动
文档化一切变更
计划专门的措施,以及开发按步骤操作指南以便恢复系统
根据确认过的变更时间排期来进行发布计划
发布是业务决定
蓝绿部署
在生产环境中有两套拷贝:“绿”和“蓝”。
金丝雀发布技术
即新功能首先针对一小部分用户可用,
A/B测试验证业务假设
即一部分用户(参考组)使用老的版本
另一部分(试验组)采用新的版本
测试并验证业务想法,并在系统后续的开发中进行调整
一切都是自动化的
自动化操作包括
● 创建环境(测试环境、中间环境等);
● 配置基础设施组件;
● 执行测试;
● 部署和分发,包括监控工具的配置
对DevOps而言,提升管控级别至关重要
应该自动化一切手工操作
事件是立即被解决的
当某些事情“破坏”了基础设施时,此时的决策是断开失败的组件
DevOps意味着最大化地将物理硬件进行虚拟化
缺陷是立即被修复的
系统必须总是可工作状态 ,为了控制技术债务,绝大多数缺陷将被设置优先级以便尽快修复
立即修复缺陷需要对计划、排序以及运维进行大规模的优化调整
流程是持续更新的
传统项目管理流程优化严重滞后
DevOps理念中识别出来的流程短板都应该立刻消除
DevOps建议尽可能地重复执行可能存在问题的步骤, 有助于更好理解应该如何改进,并对工作进行调整
像初创公司一样行动
非同寻常的团队
DevOps团队是一个令人吃惊的作战单元
DevOps团队负责一个小的但是清晰定义的IT系统或是IT基础设施
一个DevOps团队不是临时的项目团队;而是为长期存在而组建的
团队的存续周期不是预先设定,也不是固定的
DevOps团队是跨职能的
意味着团队有能力完成所负责的领域价值流上的所有工作
团队的大小非常重要
团队不能太小,太小的团队无法形成跨职能
超过二十人的团队很难协调,或是需要管理层级,或是逐渐拆分成子团队
大型团队要承受额外的沟通成本、以及团队成员之间不可避免的信息丢失
自管理的团队
团队应该有能力独立地解决浮现出来的所有管理问题,并且在遇到困难时积极寻求专家或是导师的支持
Scrum Master不是一个特定的人员,而是一个角色
面对面沟通
整个团队坐在同一个房间,让每天的每个人之间的接触无可避免
低质量的工作、缺陷、事故将不只是被发现并登记在某些信息系统中,它们会立即得到更正
DevOps团队的关键特性
工作可视化
看板
从看板可以观察出有哪些地方不正确地采用了DevOps 方法
如果优先级排序是错误的,进入价值流的待办事项马上就会超载
将看板和精益原则的推动式系统相结合
若有大量的任务需要显示并追踪,看板将变得不可读
可视化的好处
可以构建拉动系统
改善工作流;
减少停滞时间;
减少协调的需要
改善正在进行中任务的透明度;
改善对剩余工作以及当前状态的了解;
改善优先级排序;
降低交接次数;
有助于识别效率低下的环节;
限制在制品(WIP)
长待办清单会造成
需要频繁地评审任务优先级的混乱产生
频繁地在任务间切换
频繁地由于外部因素 而变更优先级
任务切换需要增加额外的时间重新排列优先级,以及切换内容上下文
多任务模式极大地增加了任务的持续时间
在价值流的每个阶段基于已接受任务的总数来进行人为限制,被称为WIP限制
工作中的浪费
去做没有客户要的工作,是一种浪费
在空闲时间捡起一个任务,稍后再搁置,也是一种浪费
HiPPO(Highest Paid Person’s Opinion)
工资最高那个人的意见
工具
累积统计团队速率
累积流图
管理WIP
减小批次大小
大的批次很少是同样大小的,甚至小到所谓的单件流。
由于小的批次降低了价值流中的等待时间,首次交付的时间以及总体的前置时间都会得以缩短
小的批次减少了进行中任务的总数
小的批次降低了缺陷数量
批次越小,返工引起的浪费也就越少
留意运维需求
常见的非功能性需求集合
尽早检测并修正缺陷
当测试尽可能多地被自动化时,会收获最大的收益
测试环境应该尽可能准确地与生产环境保持一致,以快速发现缺陷
测试“左移”
更有效的组织测试,以最大化地在早期阶 段发现最常见的错误
管理的而不是受控的改善和创新
为什么需要持续改善
流程有自我恶化的趋势
员工不只是在技术方案上抄捷径,也会在工作方式上这样做
外部因素变化频 繁
信息技术自身也在快速进化
技术债务需要被消减,工作需要被改进,新的技术需要被掌握
改善闪电战(Kaizen Blitz)
用于改善的时间未必是事先规划的,而是按需分配
引入外部参与者,外部的视角能够帮助将问题挪出死角
专注于消除识别出来的不足与瓶颈
“黑客马拉松”
分配一段特定的时间,专门用来探索新的技术,并尝试创造出新的产品和工具
对内部采用的技术进行大量优化,简化架构并消除日益累积的依赖
两个重要的观点
这一实践需要被管理,而不是听之任之;
你公司的实践,很可能与其他的组织不同;
为创新提供资金
及时且充足的资金是任何举措的前提
传统的决策,是基于预算周期的中长期计划做出的
传统预算模式意味着在部门和团队之间激烈的竞争
不受限的资金以及期限,不足以产生有竞争力的让消费者趋之若鹜的产品
任务优先级
传统的方式
分析任务
评估
比较并排序
获取审批或允许
传统方式的弊端
导致严重的延期
任务的信息会随着时间演进而趋于过时(决策耗时越长,它基于的数据就越不可靠)
这些步骤的重要性被严重夸大
一个长时间的初始评估阶段,催化了一种混合模式,被称为Water-Scrum-Fall
问题产生的原因
收益的评估并不容易
需要预估任务需要多少资源也很困难,特别是首次做的那些任务
把急迫性从考虑范围移除会非常危险
排序最基本的原则
鼓励降低批次大小,保留价值
加速产品交付
确保更均衡的工作负载
延期成本(CoD,Cost of Delay)
对做出决策的重要性进行经济评估
可以用财务回报进行预测
要考虑到价值随时间的动态变化
得到了CoD指标的数值,就很容易在不同任务之间进行比较
拥有较高CoD的任务应该进入队列
CoD除以持续时长(CD3,Cost of Delay Divided by Duration)
CoD方法的优势
对一个正处在价值流最初始阶段的任务进行计算很容易
经济化的决策对所有人都保持透明
持续识别、发掘并评估约束
限制价值流上的任务,从而不要让瓶颈过载
我们需要发现消除瓶颈的办法,摆脱它
当消除了识别出来的约束,就可以取消先前建立的短期规则,开始寻找下一个最显著的瓶颈
DevOps实践应用
DevOps适用性及限制
不适宜使用DevOps的情况
DevOps不是特别适合那些自己没有软件开发团队的组织
组织使用它们自己的软件,而开发者并非自有员工
单体的、紧耦合的IT架构
制约采纳DevOps的因素
COTS现成商业软件
“最小化自主软件开发并且尽可能多的采购现成软件”的原则
COTS的使用会成为采纳DevOps的严重阻碍
DevOps与COTS的“兼容性”
不要在战略地位的业务线上使用COTS
在你重要的业务领域中消除COTS,迁移到自主软件开发
针对相关的应用以及它们的管理策略
开放式应用
平台式应用
减少手工和复杂的安装与配置,使用可控的脚本自动化部署
DevOps指标度量
关键指标
前置时间
工作负载
产品质量
架构演进
单体架构
IT系统的任何文档很快就变得过时
众多的开发人员并行工作在系统功能上,在各自的部分都需要资源来进行协同
IT系统的开发和运维以自然的方式切割 运维以及支持的员工无法介入复杂的系统架构细节
很难识别小的自主团队能负责的领域,因而敏捷开发最主要的好处也被抹杀
由于大量的强关联,改变和发展架构变得异常困难
面向服务的架构(SOA)
存在很高的复杂性,而这让它们很难适用于DevOps实施中
微服务架构
服务之间完全通过指定的程序接口或消息队列进行通信
任何服务都不应该知道其他服务的内部实现或是对其有任何的依赖
遵循“ 无共享 的原则
修改任意的服务都可以独立于其它的服务进行
让遵循DevOps的基本原则成为可能,如:价值流、部署流水线、自动化配置管理
容器化的引入对近些年微服务架构的扩展产生了巨大的贡献
DevOps与ITSM
误区: DevOps与ITIL不兼容
DevOps 实践可以与 ITIL 流程相互兼容。
ITIL 流程中的许多⽅⾯可以完全通过⾃动化实现
IT服务管理的关键原则
由IT以服务的方式来交付业务价值
极致情况下,IT与业务之间的边界完全消失
BizDevOps
货物崇拜
盲目注重形式而非目标的意义及原则的行为,被称为货物崇拜
团队寻求去掌握一种新的管理实践,却没有把足够的精力放置在“管理”上
以价值流为核心
了解并发现了需要改进的领域,就有可能演化出价值流的理想版本
工作改进不应该被视为是一次性的事件,而是永久可持续的工作
为移除限制并最小化浪费,可以选取那些最适合的工具。
结论与总结
DevOps并非包治百病的良药
DevOps主要解决三个急迫并且复杂的问题
缩短市场响应时间
减少技术债务
消除信息科技的脆弱性
DevOps已然是初创IT公司企业文化的一部分
“不断去接受新的挑战——即便是你不确定是否完全准备就绪。”