理解DevOps
2021-09-03 13:21:17 2 举报AI智能生成
登录查看完整内容
这个思维导图是帮助大家更深理解DevOps的，大部分人对DevOps的了解可能是片面的，希望对大家有所帮助
作者其他创作
大纲/内容
引导听众思考，他们了解的DevOps究竟是什么
引导听众思考，为什么业界这么推崇DevOps，它给我们带来了哪些好处
吞吐量
变更部署次数（频繁30倍）
变更前置时间（快200倍）
可靠性指标
生产环境部署成功率（快200倍）
平均服务恢复时间（快168倍）
组织性能指标
市值增长（3年内高出50%）
高绩效者的交付周期是以分钟或者小时来计算的，低绩效者的交付则以周，或者月甚至是季度来计量的。
DevOps业务价值，下面的指标远远超过低绩效同行
借用State of DevOps Report 2017 中的数据，展示DevOps为行业带来的巨大改变
暗示听众继续思考，他们是否为行业DevOps的实践效果而震惊：为什么DevOps能为行业带来这么大改变
主题引导
开发部门通常负责对市场变化作出响应，以最快的速度将新功能完成并且上线，
我司不允许引入新中间件
IT运维部门要保证客户环境的稳定，尽量避免引入可能导致危害环境的变更，最终运维
公司高层制定了他们认为最为合适最为科学的制度，然而正是这种制度，阻碍了公司全局目标的实现。
高德拉特称这种部门之间冲突为“根本的长期的冲突”，
开发，运维，质量（QA）部门独立，各自为政，更重要的是：他们的工作往往是对立的，公司对不同部门的考核和激励不同，阻碍了公司全局目标的实现
混乱之墙
集成失败，例如无法编译
测试工作庞大，测出来问题后，开发者往往需要在很短时间内修复完成
开发环境与部署环境没有经常同步，部署失败
app
kafka，autoindex
错误的中间件使用方式
数据库使用方式
性能
监控指标
配置变更与管理
开发者开发时没有考虑运维，导致运维困难
开发者在进行大量开发工作后，才进行集成，测试，部署，运维
开发周期长，反馈慢
指的是我们当前作出的决定会导致一些问题，而这些问题会随着时间的推移越来越难解决。
什么是技术债务
上面两个因素导致技术债务（ward cunningham）堆积的主要原因
状况
Google
Netflix
Etsy
例子
例子中提到的三家公司／产品都曾经因为遵循老旧的模式开发而遭遇危机
传统软件开发和交付方式及其弊端
https://www.jianshu.com/p/f40209023006
精益制造运动中最有影响力的图书：《目标》，《凤凰项目》借鉴了《目标》的表现手法，同时借鉴了工业生产的想法。
价值流映射，看板，全面生产维护这些实践起源于丰田生产系统。
处理时间是任务实际被处理的时间，不包含在队列中等待的时间，以及因为故障停止处理的时间。
坚信前置时间（Lead Time，也就是总的制造时间，包括加工时间和停滞时间）是提升质量，客户满意度和员工幸福感的最佳度量指标之一。
小批量任务交付是缩短前置时间的一个关键因素。
两个主要原则
建立持久的目标
拥抱科学的思维
创造流和拉动（而非推送）的协作模式
提倡从源头保障质量（工厂第一个工作站如果一直接收任务，后续的工作站就会忙的不可开交，甚至出问题）
尊重流程中的所有个体
系统性思考的范围涉及
它聚焦于如何通过系统性思考来创造价值。
精益制造
频繁的交付和工作的软件，交付周期可以是数月，数星期，推荐更短的周期
强调小批量的任务进行增量发布，而不是大规模的作业和瀑布流程的发布。
强调建立自组织的小团队，让成员在高度信任的环境中愉悦的工作。
敏捷宣言
每日十次部署：Dev和Ops在Flickr的协作
Patrick Debois 发起第一次DevOpsDays活动，DevOps 术语诞生
DevOps的诞生
基于精益理论，约束理论，丰田生产系统，柔性工程，学习型组织，安全文化，人员优化因素等知识体系
参考了高信任管理文化，服务型领导，组织变动管理等方法论。
它贯彻于整个技术价值流中，涉及产品管理，开发，QA，IT运维和信息安全专员等不同角色
在更低的成本和努力下，保障产品的高质量，可靠性，稳定性和安全性。
DevOps被成为是精益原则，约束理论和丰田套路运动的衍生物，也被视为敏捷运动的延续。
DevOps 理论
https://devopstech.com/learn/blogs/traditional-it-vs-devops/
代码部署是日常的工作，不是选在周五的午夜开始，鏖战一个周末才能完成，它是在每个人都在办公室的工作日执行，而且通常不会引起客户的注意。
在流程中的每个步骤创建快速反馈，只要代码提交到版本控制系统，就会在测试环境中运行快速的自动化测试，这持续地保证了代码和环境都符合设计预期，并且总是处于安全的可部署状态。
自动化测试可以帮助开发人员快速的发现错误，实现更快速的修复，如果错误是在6个月后的集成测试中发现的，那相关记忆早都消退了，修复时就要提取记忆，这往往需要更长的时间，而且更加容易因为遗漏而犯错。自动化测试使技术债务不再积累。
这种方式，使即使很复杂的发布工作变得稀松平常了。
新功能发布更加顺利，压力更小，而且可逆。
修复已知问题成本也更低，更加可控。
DevOps打破根本的，长期的冲突。
增加开发人员的数量时，由于沟通，集成以及测试开销，单个开发人员的生产力通常会显著下降。《人月神话》。当项目延迟时，增加更多的开发人力，不仅降低了单个开发人员的生产力，而且也降低了整体的生产力。
瀑布模式无法完工时会添加人手，预算不足的时候又想尽一切办法缩减开销。
DevOps与传统方式（瀑布模式）的不同
流程始于研发部门接受任务，加入待完成列表，然后用敏捷的开发流程把想法转换为用户故事或功能说明，然后用程序代码实现。代码在生产环境中正常的运行并为客户提供服务，所有的工作才产生价值。
DevOps中将技术价值流定义为把业务构想转化为向客户交付价值的，由技术驱动的服务所需要的流程。
前置时间是客户能够体验到服务的时间
处理时间与前置时间的比值是十分重要的效率指标，为了实现快速的流动，必须缩短前置时间，即缩短工作在队列中的等待时间。
部署的前置时间和处理时间
与制造业不同的是：设计和开发阶段拥有高度的变化和不确定性，导致无法确定总体处理时间；
所以只能在测试（包括客户阶段性测试）和运维阶段努力将可变性降到最低，比如短的（自动化）和可预测的前置时间，接近零缺陷。它力求可预测性，将可变性降到最低。
不提倡在设计开发中串行地完成大批量工作后，再转入测试，运维阶段，相反，我们的目标是采用测试和运维与设计和开发同步的模式，从而产生更快的价值流和更高的质量。
只有工作任务是小批量的，并且将质量内建到价值流的每一个部分时，这种同步的模式才能实现。
等待数月才部署，项目结束后，所有变更合并到一起后，才发现整个系统不能工作，甚至无法编译。
每个问题可能几天甚至几周的时间来定位和恢复
常见的场景：为期数月的部署前置时间
向版本库中持续的交付代码
交付的代码持续地进行自动化测试和其他的进一步的测试
开发者持续的提前得到反馈，并快速进行修复。
我们的目标：分钟级别的部署前置时间
完成时间和精确的总花费时间的百分比，反映了价值流中每个步骤的输出质量
想获得返工指标，就问一问下游客户他们有百分之多少的时间收到了“真正有用的东西”
返工指标
指标
技术价值流
相关的实践包括：持续集成，持续测试，持续部署，按需进行环境搭建
缩短代码变更到上线的时间， 实现从开发到运维再到客户的工作快速地从左向右移动，目的是快速并且持续的发现问题，（接收反馈），解决问题。
目的
确保一致性，减少了繁琐容易出错的手动操作
避免ssh到远程服务器手动修改，所有人都通过版本控制系统中脚本进行变更
所有配置，所有变更都纳入版本控制系统
为了保证工作能够快速的从开发流向运维，各类环境必须能够自动化创建，不依赖运维团队的手动操作
没有自动化测试，代码越多，测试花费的代价就越多，渐渐的就忽略了测试
没有自动化测试，持续集成可能产生不能正常使用的垃圾
实现快速可靠的自动化测试
不是在开发流程结束时才进行产品安全性检查／测试，而是要把其融入日常过哦你工作的一部分。
小批量低风险发布：对代码，环境做持续的构建，测试和集成
部署是指在特定的环境中安装制定版本的软件，具体的说，部署可能与特性发布相关，也可能无关。
发布是把特定提供给所有客户，或者部分客户。特性发布不需要变更代码。
部署和发布分离
具体方法／实践
相对于制造业的生产过程而言，技术行业的价值流中很难发现工作的阻塞点，例如那个环境产生了积压。
技术工作流的流转过于简单，鼠标操作太过容易，轻易的就可以将工单转到其他团队，工作容易被踢来踢去，直到无法按时向客户交付产品，或者程序在生产环境中出现问题。
为了识别工作在哪里流动，排队或者停滞，需要尽可能的将工作可视化。
就绪-审查-开发中-开发完成-集成-集成完成-部署-部署完成-已经上线／交付
看板，从一个工作中心，拉取到下一个工作中心，最终达到最后一个中心（完成，已上线）
可视化方式
使工作可视化
生产中断在制造业里面很显眼，代价特别高，正在进行的工作戛然而止，所有的半成品可能报废，然后再启动新一批作业。这种高昂的代价让人们不希望中断的发生。
技术工作很容易被打断，工单系统，报警，邮件，电话，即时通信工具等。
控制队列长度是一个非常强大的管理工具，因为这是影响前置时间的重要因素之一，对于大多数工作任务而言，在他们完成之前，并没有办法预测到底需要多长时间。
使用看板工作时，可以限制多任务的出现。
限制在制品（WIP）数量
大批量／大规模生产的一个缺点是导致在制品数量增多，最后导致前置时间长，产品质量差的后果----如果发现一个车身板有问题，整个批次都要报废。
相较于大批量生产，用户能提前很长时间看到阶段性产品，进而提供更加及时的反馈。（前置时间更短，错误检测更快，返工量更少）
大批量的副作用，将一整年的成果一次性发布，这种大批量的发布会造成大量的突发的在制品，导致所有下游工作站大规模混乱，质量下降。因为生产环境变更越大，问题的定位就月困难，开发者debug和回忆的时间也更长，进而修复时间也越长。
精益理论，为了缩短前置时间和提高交付物质量，应该持续不断的追求小批量模式。#936
减少批量大小
代码在价值流流转过程中，经过的部门／节点越多，在队列中等待的几率就越多，前置时间就会越长（请求，委派，通知，会议，协调，优先级，调度，测试验证等），进而导致延期。
减少交接次数
为了缩短前置条件，需要不断识别并改善约束点
高德拉特：任何价值流中，总有一个流动方向，一个约束点，任何不针对约束点而做的优化都是假象。如果我们在约束点之前进行优化，那么工作必将在这个约束点上更快的积压起来。反之，如果在约束点之后优化，被约束的节点可能处于饥饿状态，因为一直在等待约束点工作的结束。
持续识别和改善约束点
精益中对浪费的定义：使用了超出客户需求和他们愿意支付范围对任何材料和资源的行为。
精益中七种浪费的类型：库存，过量生产，过度加工，运输，等待，移动，缺陷。
现代精益的理念：消除一切浪费
浪费
逆境
制造业
需求文档
尚未审核的变更单
队列中的工作
没有彻底完成的工作
部分完成的工作会逐渐地过期，随着时间的推移最终失去价值
半成品
下游工作中心从没使用过的文档
不必要的评审，审批
交付过程中的额外工作
额外工序
增加开发时间
增加测试和管理的复杂度
客户完全不需要的镀金功能
额外功能
任务切换
等待被处理
不在一起办公，人员的移动，额外的沟通产生的时间浪费
移动
需要额外的工作量确认，解决，在客户环境上修正
缺陷
不能自动化反复重建的服务器，测试环境和配置
理想情况下，任何需要依赖运维团队手动完成的操作都必须自动化
非标准或者手动操作
某些人不停的救火，影响他正常的工作
填坑侠
技术业的浪费和困境
消除价值流中的困境和浪费
注意事项
第一步-构建从左到右的工作流
各个组建紧紧的耦合在一起
相同的事情做两次，结果未必相同
管理复杂的工作，从中识别出设计和操作的问题
群策群力解决问题，从而快速构建新知识
在整个组织中，将区域性的新知识应用到全局范围
领导者要持续培养有以上才能的人
没有办法设计出绝对安全可靠的系统，但可以采取下面的措施让复杂系统更安全的工作
复杂系统的本质
现代系统往往非常复杂，通常只有在发生重大故障的时候，才能发现问题所在，例如遇到大规模用户服务中端，或者安全漏洞导致客户数据泄漏。建立快速，频繁的反馈，就可以在规模较小，修复成本较低的情况下发现并修复问题。我们应该在灾难发生之前消除问题。
整个价值流里存在着快速频繁和高质量的信息流，每个工序的操作都被度量和监控，任何缺陷或者严重偏差都能被快速的发现和处理。这些是保障质量，安全和持续学习与改进的基础。
技术流中，包括产品管理，开发，QA，信息安全，运维，缺少快速的反馈，及时的反馈
业务层，应用程序，环境层收集数据
可视化，趋势，告警，异常检测
建立大规模的监测系统
认证，授权的结果
系统数据的访问
系统和程序的变更
数据的变更
无效输入（恶意输入等）
启动／关闭
故障和错误
延迟
备份成功／失败
日志分析
遥测系统
使用遥测系统指导解决问题
将建立遥测系统融入日常工作
建立服务指标，为了服务指标对系统进行持续性提升
业务级别
应用程序级别
数据库，操作系统，网络，存储
基础架构
发现和填补遥测的盲区
通过遥测数据进行必要的检测和报警
实践
及时发现并控制这些问题，直到拥有对策，这是所有现代流程优化方法的一个核心原则，能够创造出学习型组织和改进型组织。
技术价值流中，我们通过运维而设计来为下游工作中心做耦合，包括运维的非功能性需求（架构，性能，稳定性，可测试性，可配置性，安全性），与用户功能同样重要。
时刻为下游工作优化，精益原则认为我们最重要的客户是我们的下游
第二步-从右到左的持续反馈
持续的缩短和放大反馈环，创造更安全的系统，也能承担更多的风险，并进行试验，帮助自己比竞争对手改进的更快，进而在市场竞争中战胜他们。
持续的经验积累，组织内部可以相互借鉴彼此的经验和智慧。
Netflix捣蛋猴
故障注入的方式增加环境的可靠性
犯错不指责，鼓励分享，
预留时间开展组织的改进和学习活动
尽可能广泛公开错误和事后分析结果
检查健康状况
维护模式屏蔽告警
部署失败时调出冒烟测试的日志
源代码库接收到代码
环境部署流水线中的变动
接收消息
等等等等
运维和聊天室集成，有助于记录和分享我们观察和解决问题的过程
加强了透明协作的文化
github的聊天机器人
将局部知识分享给所有人
精确的预测出复杂系统中的问题是不现实的，意外总会发生
这样的事故处理会阻碍安全调查，让工作者感到恐惧，整个组织更加官僚，信息闭塞，责任逃避，滋生自我保护意识。
不点名，不责备，不羞辱
如果团队没有能力或者意愿去改进现有流程，那么就会持续饱受眼前问题的困扰和折磨，而且痛苦指数还会与日俱增。
偿还技术债
修复缺陷
重构代码
优化性能能
预留时间改善日常工作，所有人都可以在可控的时间内发现问题和解决问题。
持续改进模式替代应急救火模式
比日常工作更重要的，是对日常工作的持续改进
把日常工作的改进制度化
第三步，创造持续学习和实验的实践
如何实践DevOps - 三步工作法
它决定了转型的难度
也决定了转型时参与者
绿地和棕地项目
记录型系统和交互型系统
合适的价值流作为切入点
找到创新者和早期采用者
赢得沉默的大多数
识别钉子户
扩大范围
强化共同目标
提高工作的可视化
测试运维加入每日站会和回顾会议
将测试，运维和信息安全融入日常工作
如何推进DevOps
各个部门精诚合作，共同解决问题。
缩短代码上线时间。
构建持续交付和持续集成系统。
构建监控系统，监测生产环境，处理报警报警。
过程
持续开发，持续集成，持续测试，持续部署，持续反馈
开发，测试，质量／安全保障并行
持续发现问题，解决问题：确保信息是流动的
主动发现并解决流程中的瓶颈，加速工作流，逐步缩短周期
持续优化信息流：确保信息流动越来越快
基本目标
如主动优化SLA
逐步提高业务指标
如捣蛋猴
主动发现新问题，提升系统健壮性
主动发现并解决问题
不责备
主动分享
全局分享
预留时间进行分享与持续学习
终极目标
很多资料（尤其是国内资料）上都错误的认为企业中有上面的设施和要求就做到了DevOps了，实际上我们的目标（重点）应该是在建立了基础设施后：
结语 - 错觉：不要把DevOps过程当作目标
理解DevOps
0 条评论
回复 删除
下一页
