导图社区 DevOps Foundation考试认证
讲devops基础认证资源全部记录,拿着即可考。DEVOPS是一种敏捷软件开发和精益制造想法的演变,应用到IT端到端的价值链,归功于文化、组织和技术的变革,时业务能够通过信息技术更多地达到预期。
编辑于2023-05-12 09:22:06 浙江省DevOps Foundation认证
基础知识
起源
1980年的ITSM、ITIL、COBIT、AGILE、ASCRUM到2018年的DEVOPS.
敏捷宣言弥合业务和软件开发人员的鸿沟
敏捷宣言和敏捷原则
虚拟化和云计算是DEVOPS的基础设施
虚拟化: 1.有效使用硬件 2.业务
云计算: 1.VPN通过共享信道发送私有数据包,提供安全隐私和高质量服务 2.大型供应商使虚拟化资源变得廉价和可靠
云计算特征
1.按需服务,使消费者可以是需要单方面配置计算能力 2,宽泛的网络接入 3.资源的池化 4.快速的伸缩性 5.可度量的服务
定义
DEVOPS是一种敏捷软件开发和精益制造想法的演变,应用到IT端到端的价值链,归功于文化、组织和技术的变革,时业务能够通过信息技术更多地达到预期。
DEVOPS如何对精益和敏捷思想延申
DEVOPS并没有取代敏捷或精益实践,而是友好的吸收了它们
DEVOPS的最本质是不仅仅思考软件开发,而是整个价值链
DEVOPS期待的价值是从IT获得更多的回报,三个基本要素:文化、组织、技术
为何需要价值流思考
了解关键指标的现状值(as-is)会对流程参与者产生清醒的影响
流程的可视化呈现有助于聚焦在制造价值,而不是在执行的动作
帮助识别和消除瓶颈,同时避免局部优化陷阱
有助于实现步骤间的平滑和统一的流,要连续、有节奏地输出,避免不必要的延迟和优化资源利用率
DEVOPS如何比之前IT实践更好
加速新产品及改良上市
更快地响应需求
提高IT系统的可用性和可持续性
更高效的使用有限资源
采用DEVOPS的原因
缩短市场响应时间
业务想法
假设评估
减少技术债务
持续重构程序代码,重视在运维中获得经验和构造新功能同等重要,同时规划相应的工作来消除之前出现的瓶颈
应用尽可能频繁地直面问题的实践,以便防止问题的停滞。
消除脆弱性
完全消除
代码于系统作为一个整体,在任何时间都是完全可以运行的
在生产环境中有意引入混乱与不确定性
对DEVOPS的误解
DEVOPS并不仅是敏捷的一部分 1.DEVOPS把敏捷开发的想法延展到整体的敏捷IT交付、整个组织、整个流程以及整个流水线 2.从DEVOPS中获得回报,通常需要更大的公司文化变革 3.DEVOPS的目标集,不仅限于交付,还有减少技术债务和消除脆弱性
DEVOPS不仅是工具和自动化 1.不可能有一个完整的DEVOPS的必备软件列表 2.依赖确定的自动化工具的可用性和有效性
DEVOPS并不是一个新职业 1.DEVOPS是IT部门从根本上发生深远的变革,不是通过招聘一些业内专家或大师能实现 2.具备实施软件交付流水线能力,也不能保证取得成功。实施DEVOPS实践也不节省成本
原则
价值流
价值流的概念 1.从创造价值以响应客户请求的角度来考虑组织中的工作 2.价值流是完成请求所需要实施的相关行动,可以按顺序排列起来 3.组织处理着多样化的不同需求
价值流映射的概念 1.把价值流可视化的工作 2.映射通过创建当前(as-is)图景到创建未来(to-be)图景 3.最有价值的信息是价值流中每个步骤度量(前置时间-处理时间-完整性与准确性占比)
创建未来图景的两个原因: 1.有助于避免局部优化 2.理解目标状态使得我们能够建立一个有清晰改进方向的现实改进机制
价值映射的活动 识别处理请求的关键步骤,记录每个步骤中实施发得工作,将这些步骤组织为一个创造预期结果的活动序列。
价值映射的活动困难点 1.过度进行细化, 2.是对到底哪些步骤、这些步骤是如何执行及由谁执行达成一致。
解决办法 1.限制图中区块的数量不超过15个,以使得基于这个图的进一步工作更容易开展。 2.在价值流图的区块中填充进一步的细节,负责人或人员名字、明确标出待处理队列出现堆积的步骤、或由于等待一个预先计划的事件而产生延迟的步骤。
价值流图的作用 1.价值流创建映射,了解关键度量指标的当前(as-is)数值,这使得流程参与者对此可以有清醒的认知; 2.过程的可视化呈现,有助于聚焦到被创造的价值上,而不是被实施的工作上; 3.价值流图有助于识别和消除瓶颈,并避免局部优化的陷阱:即把时间和精力花费在根本没有效果甚至带来负面效果的约束消除上。
对价值流的了解,有助于实现DEVOPS的关键思想:构建一个顺畅、一致流经各个关键的价值流,使得我们能够持续地、有节奏地、没有非必要的延迟、并以最优的资源使用方式来交互成果。
部署流水线
处理几个重要的DEVOPS任务 1.节约资源;在前序步骤没有完成之前不会启动后续步骤; 2.流水线确保产品质量;未按要求实施的变更不会抵达生产环境,系统总是处在可工作的状态中; 3.加速变更往生产环境的交付;流水线通过最大化各个步骤的自动化程度; 4.流水线时常留下审计记录;使得所有进行的变更都能够受监控,并且能准确地衡量度量流水线中的所有步骤,提供可用于优化的非常有价值的数据。
实施部署流水线的挑战 1.忽视理念(流程、人与文化)对自动化的过度热情,导致创建出数量可观的自动化流水线,但是没有人使用它们。解决方法:每个人应该意识到DEVOPS不仅仅是自动化; 2.在一开始,没有足够的已开发的测试来确保流水线的稳定运行。解决方法:增加测试代码覆盖率 3.在实施后期,有非常多的测试在运行,以至于一个变更流水线要花费过长的时间,并消耗庞大的计算资源,尤其当有大量的微小变更时。解决方法:测试系统使用专门的标记或人工智能工具,从大量的测试中选址出那些与本次发起变更相关的测试,而无需执行余下的测试
持续集成
1.开发人员可以做出最小的改变,将工作分解成小片,每个小片携带着一点风险,但可以立即启动集成过程; 2.每个程序员至少每日一次将其代码方法哦版本控制系统中,每次执行自动执行,并允许立即识别与更正错误,这意味着系统总是能保持在可工作状态。
持续交付
1.尚未被完整及成果测试的变更,不会被验收通过,并需要立即进行修正; 2.所有没有差错的变更,进入到对生产环境部署而言是完全就绪的状态
持续部署
1.意味着从“当所有变更就绪时,系统随时可以部署”的状态,转化到“任何变更都被立即部署到生产环境”的状态; 2.技术上,在部署与测试完成后,功能已经存在于生产环境上,但当业务例如市场部门需要时,可以通过额外的程序设置来激活它。这个实践被称为“影子发布”或“暗发布”。
版本控制
版本控制的理念
不仅仅要存储源代码,还要存储与IT系统相关的所有内容: 测试、用于构建和修改数据库的脚本、构建脚本、环境创建脚本(包括开发环境)、部署脚本、工件/制品、库,文档,配置文件、甚至开发工件,譬如编译器,IDE等
版本控制的作用
1.对运行中的系统各组成部分的空前级别的控制; 2.需要改变如何与信息及配置一起工作的文化; 3.有能力确定变更了什么内容、合时变更以及谁做的变更; 4.讲系统重置到过去任何一个时间点,包括以最小的代价回滚出错的系统到一个有保证的工作状态; 5.允许团队任何成员自由删除不再需要的文件和文档,而无需承担意外损失的重要信息或产品的风险。
配置管理的概念
1.DEVOPS完全重构了对生产环境(以及任何其他环境)的管理; 2.对于因为任何环境的任何变更都只能通过存储在版本控制系统里的脚本来实施; 3.当部署流水线运行时,环境的创建就自动完成了; 4.这个原则需要重组IT支持和运维的工作。这个时候管理员再也无法用其以往的方式挪动生产环境中的任何东西。
配置管理对DEVOPS的作用
1.DEVOPS配置管理提供的收益如同从全面本部控制中获得的收益,只不过主要受益者运维人员; 2.所有的变更都是可控的,系统可以被快速重置到稳定的状态。如果关键人员离开,知识也不会遗失。
完成的定义
明确完成定义对DEVOPS思维模式很重要
1.不是说当有人做完了他/她们那个部门的工作,就可以算“完成”,而是要等到客户接收到或者开始接收其所预期的价值; 2.整个价值流已经被完整的流经,一直到生产环境。
完成定义对DEVOPS收益
1.团队不是聚焦在完成的工作上(我做了什么),而是聚焦在结果即客户价值上(为什么我们要做它); 2.消除掉队具体领域工作的有限的责任,而是取而代之的是对团队整体结果共有责任
关键实践
和传统实践的区别
发布是日常活动,甚至会每周甚至每天进行
1.文档化一切变更; 2.确保做了备份; 3.计划专门的措施,以及开发按步骤操作指南以便恢复系统; 4.根据确认的变更时间排期进行发布计划; 5.通过相当大量的手工操作进行部署和发布,并且不会记录中间结果。
发布是业务决定
1.发布时宕机时间急剧下降,甚至为零; 2.让蓝绿部署成为可能; 3.拥有大量用户的公司采用金丝雀发布发布,即新功能首先针对一小部分用户可用,当技术和市场角度都确定一切正常后,再将所有其他用户切换到新版本上。
一切都是自动化
1.创建环境(测试环境、中间件等); 2.配置基础设施组件; 3.执行测试; 4.部署和分发,包括监控工具的配置。
事件是立即被解决
事故被回溯到最近的一次部署,流水线控制系统将自动地回滚到已知的最近一个稳定状态。
缺陷立即被修复
1.以对待新功能的同样方式来对待缺陷; 2.缺陷与用户故事进入到同一级别并且被平等对待。
流程持续更新
所有识别出来的流程短板都应该立刻消除。
DEVOPS实践
多元化团队的特点:搭配、对正在使用的工具负责、非临时构造、对一个小的区域负责、全职、跨职能、人员规模小、多样化的专家、自组织
可视化工作的重要性
IT中不可见性的关键问题
1.有多少已经接受的工作,是哪些? 2.那个步骤堆积了工作,形成的瓶颈阻止链条上其他环节有效展开? 3.哪个领域可能存在不足,并很快蔓延其他领域? 4.哪里的资源已经或即将耗尽? 5.哪些任务被阻塞,以至于无法在本迭代完成? 6.未完成任务还有哪些剩余工作? 7.如果我们没有时间完成本迭代接接受的所有工作,其中哪些值得尝试去做,以便达到最大化的结果?
可视化的好处
可视化工作的重要性
1.改善工作流; 2.减少停滞时间; 3.减少协调的需要
改善正在进行中任务的透明度; 改善对剩余工作以及当前状态的了解; 改善优先级排序; 降低交接次数;
有助于识别效率低下的环节
在制品数量批次规模限制 1.实现更短的前置时间; 2.降低了人力资源利用率
在制品数量批次应该被限制 1.拥有同样体量的小的批次改善了工作流的节奏; 2.小的批次降低了价值流中的等待时间; 3.小的批次减少了进行中的任务总数; 4.小的批次降低了缺陷的数量
使DEVOPS奏效的运维需求
产品负责人需要关注整个IT运维系统,包括功能的需求以及其他需求; 坚持抛弃“非功能性需求”整个名字,采用“运维需求”; 建议彻底改善IT系统的可用性和性能,主要关注点转移到可恢复性或反脆弱性
实际应用
可行性
DEVOPS不要开始的实践 企业只参与价值流有限的一部分,比如商业软件开发,系统集成,IT外包,以及面向项目的组织; 企业并不认为业务能通过IT获得最大产出; 企业希望大幅度减少累积的技术债务,或者消除IT基础设施的脆弱性
业务对DEVOPS进行采纳的条件
1.核心业务高度依赖信息科技; 2.组织采用信息技术高速变化; 3.核心业务要求快速变化,验证新的商业想法或猜想; 4.核心业务存在与IT相关的风险,这对于业务负责人或者高层是不可接受的; 5.其他提升效率的尝试与验证方法都不奏效
限制性
欠缺采纳DEVOPS的就绪条件
1.不自行研发软件的企业; 2.使用自己软件的企业,而开发者并非自有员工; 3.用友长期存在的工作模式,并且没有意愿进行重组的企业; 4.紧耦合、单体的IT架构企业
单体IT基础设施和架构是引入DEVOPS的一个限制
1.引入小团队需要有能力给他们分配不同的职责领域; 2.有问题的IT系统依然作为单一实体被几十或几百名员工进行开发和维护时,很难将工作拆分到独立的团队以异步并行工作,将会比较困难
采用商业软件
当组织面对DEVOPS与COTS的“兼容性”问题
1.不要在战略地位的业务线上使用COTS; 2.在你重要的业务领域中消除COTS,迁移到自主研发上
版本控制下,保持所有应用设置的完整拷贝
1,通过标准化的COTS配置工具; 2.应用的设置被导出为适合版本控制系统的格式; 3.最昂贵的方式是当COTS不支持配置导出但有一些导入能力的情况
COTS最佳使用场景,是定期、快速并且自动化地在生产环境中,从无到有完整地重建应用,它应该基于配置管理系统中的数据,并且不需要系统停机,做到对用户无感。
演进的架构和组织模型
单体架构可能引发的问题
1.即使是系统某一部分小小变化,也会引起对其他部分的父母的、经常是无法预料的影响; 2.众多的开发人员了解并行工作在系统功能上,在各自的部分都需要资源来进行协同; 3.只有少数的员工了解IT系统的整体概况以及所有依赖与约束;这种员工迅速地变得极有价值、无可替代,并且严重超负; 4.IT系统的任何文档很快变得过时; 5.IT系统的开发和运维以自然的方式切割:运维以及支持的员工无法介入复杂的系统架构细节,因而即使最简单的问题,也只能上升给开发人员; 6.很难识别小的自主团队能负责的领域,因而敏捷开发最主要的好处也被抹杀,我无法达到期望; 7.现有的架构无法满足当前的需要,创建之后就很快过时:不得不在没有足够信息、缺乏开发和使用系统经验时,做出关键的架构决策; 8.由于大量的失联,改变和发展架构变得异常困难
微服务架构
1.修改任意的服务都可以独立于其他的服务进行,并由一个专门的团队进行; 2.每一个服务彼此独立工作,同事又与IT系统作为一个整体工作。这让遵循DEVOPS的基本原则成为可能
演进式架构
1.持续遵循新的业务需求以及浮现的新兴技术; 2.独立于其他团队和领域地对单个服务进行重构,减少累积的技术债务
迭代前进
识别与其他系统松耦合连接的系统
把系统作为试点,采用基础DEVOPS元素
1.价值流; 2.部署流水线; 3.版本控制系统; 4.自动化配置管理
应用到其他系统
从简单的情况开始,你可以更有信心地继续前行,来扩展DEVOPS应用
DEVOPS与ITSM
DEVOPS实践可以与ITIL流程兼容。但为支持DEVOPS实践所倡导的更短的前置时间与更高的部署频率,ITIL流程的许多方面完全通过自动化实现,这样就解决了许多与配置和发布管理流程相关的问题。由于DEVOPS在服务发生要求快速检测和恢复,ITIL在服务设计、事件和问题管理方面的规程仍然一如既往地重要