《DevOps实践指南》——阅读笔记(长文告警)
DevOps实践指南
- 《DevOps实践指南》简介
- Part 1——DevOps介绍
- 简史
- 第1章 敏捷、持续交付和三步法
- 第2章 第一步：流动原则
- 第3章 第二步：反馈原则
- 第4章 第三步：持续学习与实验原则
- Part 2——从何处开始
- 第5章 选择合适的价值流作为切入点
- 第6章 理解、可视化和运用价值流
- 第8章 将运维融入到日常开发工作
- Part 3——第一步：流动的技术实践
- 第10章 实现快速可靠的自动化测试
- 第11章 应用和实践持续集成
- 第12章 自动化和低风险发布
- 第13章 降低发布风险的架构
- Part 4——第二步：反馈和技术实现
- 第18章 建立评审和协作流程以提升当前工作质量
- Part 5——第三步：持续学习与实验的技术实践
- 第19章 将学习融入日常工作
- 第20章 预留组织学习和改进的时间
《DevOps实践指南》简介
- 本书共分为6个部分：
- 第一部分概述DevOps的历史和三个基本原则，即“三步工作法”；
- 第二部分介绍开启DevOps转型的过程；
- 第三到五部分深入探讨“三步工作法”的各个要素；
- 第六部分关注如何将安全性和合规性正确集成到日常工作中。
- 全书涵盖40余个DevOps案例，以谷歌、亚马逊、Facebook等全球知名企业和组织的实际调查结果为依据，展示如何通过现代化的运维管理提升管理效率，进而为企业赢得更大市场、创造更多利润。
反馈原则的核心思想是：虽然复杂的系统不可避免地存在错误，但是可以通过采取安全措施确保在质量问题出现之前，快速发现和处理错误。 ——曾朝京
敏捷通常是DevOps效率的保障。DevOps不只是自动化，就像天文学不只是望远镜一样。
Part 1——DevOps介绍
- DevOps三步工作法：
- 流动原则：它加速了从开发、运维到交付给客户的正向流程；
- 反馈原则：它使组织构建安全、可靠的工作体系，并获得反馈
- 持续学习与实验原则：它打造出一种高度信任的文化，并将改进和创新融入日常工作中；
简史
DevOps基于精益、约束理论、丰田生产系统、柔性工程、学习型组织、安全文化、人员优化因素等知识体系，并参考了高信任管理文化、服务型领导、组织变动管理等方法论。把所有这些最可信的原则综合地应用到IT价值流中，就产生出DevOps这样的成果。将它贯彻于整个技术价值流中，涉及产品管理、开发、QA、IT运维和信息安全专员等不同角色，在更低成本和努力下，保障产品的高质量、可靠性、稳定性和安全性。
第1章 敏捷、持续交付和三步法
- 聚焦于部署前置时间
- 前置时间 是在工单创建后开始计时，到工作完成时结束；而 处理时间 则从实际开始处理这个工作才开始计时，它不包含这个工作在队列中排队等待的时间。
- 我们应该吧重点放在 缩短前置时间 ，而不是处理时间上。不过，处理时间与前置时间的比率是十分重要的效率指标，所以我们必须 缩短工作在队列中等待的时间。
- 关注 返工指标 ：该指标反映了价值流中的每个步骤的 输出质量 。关注真正有用的工作。
- 三步工作法：DevOps的基础原则
- 第一步：实现开发到运维的工作快速地从左向右流动
- 工作可视化；
- 减小每批次大小和等待时间；
- 通过内建质量杜绝向下游传递缺陷；
- 第二步：应用持续、快速的工作反馈机制
- 缩短反馈周期；
- 放大反馈环防止问题复发；
- 第三步：建立具有创意和高可信度的企业文化
- 通过主动承担风险，不但能从成功中学习，也能从失败中学习；
- 第一步：实现开发到运维的工作快速地从左向右流动
第2章 第一步：流动原则
- 使工作可见
核心，因为所有的优化和分析首先需要有准确的、可见的数据- 避免不同的团队/人可能因为信息的不完整而将工作“踢来踢去”，存在的问题也会被传递到下游；
- 限制在制品数量
- 将一个工程师同时分配到多个项目里，他不得不在多个任务、认知规则和目标之间来回切换，付出重新进入角色的成本；
- 对于大多数的工作条目而言，在它完成前，其实并无法预测到底需要多长时间；
- 减少单个批量大小
- 最小的批量是单件流
- 减少交接次数
- 信息或者知识不可避免的在交接中丢失；
- 努力 减少交接次数 或 用 自动化 方式执行大部分操作 或 调整组织架构；
- 持续识别和改善约束点
- 如果我们优化约束点之前的那个工作中心，那么工作必将在这个约束点上更快的积压起来；
- 如果优化约束点之后的工作中心，那么它们还会处于饥饿状态；
第3章 第二步：反馈原则
- 在复杂的系统中安全的工作
- 管理复杂的工作，从中识别出设计和操作的问题；
- 群策群力解决问题，从而快速地构建新知识；
- 在整个组织中，将区域性的新知识应用到全局范围；
- 领导者要持续培养有以上才能的人；
- 及时发现问题
- 目标是更早、更快、以尽可能低的成本、从尽可能多的维度增加系统的信息流，并尽可能清晰的确定问题的前因后果。
- 群策群力，战胜问题获取新知识
- 这样做可以让所有参与者都得到更深入的知识，理解如何管理系统，把无法避免的、早期的无知阶段变成学习的过程；
丰田的 “安灯绳” 便是一个非常成功的案例- 安灯绳系统 ：安灯系统百度百科介绍
- 防止把问题带入下游的处理环节，否则不但修复的成本和工作量会呈指数级增加，而且还会欠下 技术债；
- 防止工作中心启动新的工作，那样可能会在系统中引入新的错误；
- 如果问题短时间内没有得到解决，那么在下一次操作中可能还会遇到相同的问题，需要更高的修复成本；
- 发现问题时拉动“安灯绳这个行为不应当有惩罚，甚至这个行为是受鼓励的。
- 这样做可以让所有参与者都得到更深入的知识，理解如何管理系统，把无法避免的、早期的无知阶段变成学习的过程；
- 在源头保障质量
- 质量控制无效的案例：
- 需要其他团队帮忙完成一系列乏味、易出错和手动执行的任务，这些任务本该由需求方自己采用自动化方式完成；
- 需要那些远离实际工作场所且公务繁忙的人批准，迫使他们在不了解工作情况和潜在影响的情况下做出决策，或者仅仅例行公事地盖章批准；
- 编写大量含有可疑细节，且在写后不久就过时的文档；
- 将大量的工作推给运维团队和专家委员去评审和处理，然后等待回复；
- 质量控制无效的案例：
- 不断地为下游工作中心做优化
这句话是工作优化的经典- 当你不知道需要优化什么东西时，不妨去问问下游。
第4章 第三步：持续学习与实验原则
- 建立学习型组织和安全文化
- 正义文化
- 不公正的事故和意外处理会阻碍安全调查，让安全工作者感到恐惧(而不是专注)，让整个组织更加官僚(而非更加细致)，甚至还会导致信息封闭、责任逃避和滋生自我保全意识；
- 管理者对事故责任人进行惩罚不但会引起恐惧感，还会导致问题和故障的隐瞒不报，直到下一次的灾难性事故发生；
- 如果不指责，员工就没有恐惧，没有恐惧，就能做到坦诚，而坦诚能够有效预防事故；
- 正义文化
- 将日常工作的改进制度化
- 比日常工作更重要的，是对日常工作的持续改进；
- 通过明确预留时间来改善日常工作，包括预留时间来偿还技术债、修复缺陷、重构和优化代码和环境。
- 开发周期的间歇中预留一段时间；
- 闪电改善战；
- 周期内预留20%的时间让工程师来解决他们感兴趣的问题；
- 把局部发现转化为全局优化
- 一旦在局部范围内取得了成果，就应当把它分享给组织的其他人
- 把所有的事故报告转化成可搜索的知识库
- 领导层强化学习文化
-更卓越的领导力其实是为团队创造条件，让团队能在日常工作中感受到这种卓越。
Ron Westrum的组织类型学模型：组织如何处理信息
| 病态型组织 | 官僚型组织 | 生机型组织 |
|---|---|---|
| 隐瞒信息 | 忽略信息 | 积极探索信息 |
| 消灭信使 | 不重视信使 | 训练信使 |
| 逃避责任 | 各自担责 | 共担责任 |
| 阻碍团队的互动 | 容忍团队的互动 | 鼓励团队间结盟 |
| 隐瞒事故 | 组织是公道和宽容的 | 调查事故根因 |
| 压制新想法 | 认为新想法会造成麻烦 | 接纳新想法 |
Part 2——从何处开始
如何在组织中迈开DevOps转型第一步？谁需要参与？如何组织团队？如何保障团队成员投入精力并在最大程度上获得成功的机会？
第5章 选择合适的价值流作为切入点
- 从最乐于创新的团队开始
- 第一步应该将精力集中于少数几个试点领域，确保他们取得成功，然后再逐步扩展；
自上而下的大爆炸式转型也不是不可能，但是这个模式需要得到最高层的支持
- 第一步应该将精力集中于少数几个试点领域，确保他们取得成功，然后再逐步扩展；
- 扩大DevOps的范围
- 尽早展示成果，并积极宣传。将大的改进目标分解成渐进式的小步骤
- 首先发现创新者和早期采用者
- 然后赢得从众者
- 最后解决“钉子户”
第6章 理解、可视化和运用价值流
- 拥有共同的目标
- 对于每次迭代，团队应该定制出一组能够产生价值的小目标，并朝着长期目标靠近。在每次迭代结束时，团队应该检查进度，并为下一次迭代设定新的目标
- 保持小跨度的改进计划
- 为非功能性需求预留20%的开发时间，减少技术债务
- 把20%的开发和运维时间投入到重构、自动化工作、架构优化以及非功能需求上。
- Marty Cagan
eBay产品与设计高级副总裁指出，如果组织不愿意支付这“20%的税”，那么技术债务将会最终恶化到耗尽所有可用资源的程度。终有一天，服务会变得不堪一击，需求交付将停滞不前，所有工程师都在解决可靠性问题或者寻求临时方案。许多一线公司早期经历过这个场景，最后总结出来的精华
- 提高工作的可视化程度
第8章 将运维融入到日常开发工作
- 创建共享服务，提高开发生产力
- 搭建类生产服务
- 部署流水线
- 自动化测试工具
- 生产环境监控控制台
- 将运维工程师融入服务团队
- 服务团队拥有固定的 运维联络人 ；
- 参加开发团队会议；
- 运维工作加入看版图展示；
Part 3——第一步：流动的技术实践
第10章 实现快速可靠的自动化测试
如果没有自动化测试，那么我们编写的代码越多，测试代码所花费的时间和金钱也就越多。在大多数情况下，这种商业模式对于任何技术组织而言都是无法扩展的。
- 尽量将手动测试自动化
- 自动化测试的目的是尽可能多的发现代码错误，并且减少对手动测试的依赖；
- 执行少量可靠的自动化测试，往往优于执行大量手动测试或不可靠的自动化测试。如果在放弃某个手动测试改为自动化之后，生产环境出现缺陷，那么应该将这个测试重新加入手动测试套件，但最终还是应该将它自动化；
- 当团队已经重视自动化测试之后，可以开始引入度量测试覆盖率，还要把度量的结果可视化，一般可以定义覆盖率为80%；
- 一旦某个开发人员提交的代码变更导致构建或自动化测试失败，需要立即解决这个问题。如果有人在解决问题时需要帮助，他们能获取任何所需资源；
- 我们认为团队目标高于个人目标——在帮助他人推进工作的同时，也帮助了整个团队；
- 每个人都应该知道工作不只是“编写代码”，更是“运行服务”；
第11章 应用和实践持续集成
开发人员在自己的分支上独立工作的时间越长，就越难将这些变更并入主干。事实上，当分支个数和每个分支上的变更数同时增加时，合并难度会骤增。
- 采用持续集成和基于主干的开发方式
- 开发人员提交得越频繁，每次的提交量就越小，他们离理想的 单件流 状态也就越近
- 拒绝接受任何使系统偏离可部署状态的提交，这种方式称为门控提交
- 每日提交代码也迫使开发人员进一步分解工作
- 基于主干的开发方式能带来更高的生产力、更好的稳定性，甚至更高的工作满意度和更低的职业倦怠率。
第12章 自动化和低风险发布
- 自动化部署流程
- 用相同的方式处理所有环境的部署
- 对部署执行冒烟测试
- 维持环境的一致性
- 将部署与发布解耦
- 蓝绿部署
- 金丝雀发布
- 集群免疫系统
- 黑启动技术
第13章 降低发布风险的架构
绞杀者应用模式尤其适用于将单体应用或紧耦合服务的部分功能迁移至松耦合架构。
Part 4——第二步：反馈和技术实现
每个人都能获得工作反馈，信息可见以便于大家学习，能快速测试产品假设，帮助我们判断目前开发的特性是否有助于实现组织的业务目标。
第18章 建立评审和协作流程以提升当前工作质量
- 杜绝反事实思维
- 出现事故，我们应该关注：为什么会出现这个问题？当时我们为什么会这么做？以后我们应该如何避免同类问题？ 而不是去指责，去问为什么当时没有这样/那样做?
- 同行评审
代码评审- 同行评审的目标是通过工程师同事的仔细核查来减少变更错误。这种形式的评审不仅提高了变更的质量，还相当于进行了交叉培训。
- 合理的时间是将代码向版本控制系统中的主干提交时。
- 请程序员来看10行代码他能找出10个问题。请他审查500行代码，他会说看起来都不错。
- 代码评审的形式
- 结对编程
- 开发 + 开发
- 开发 + 测试
- 老同事 + 新同事
- 每天固定一个小时间段为结对编程时间
- 电子邮件送审
- 工具辅助评审
- 集中评审：有一个或多个工程师一起去评审一段或多段代码
- 结对编程
Part 5——第三步：持续学习与实验的技术实践
将团队或个人在某个领域里学到的经验迅速地应用和推广到整个组织里
第19章 将学习融入日常工作
- 建立公正和学习文化
- 将故障和缺陷视为学习的机遇，而不是惩罚的机会。
- 如果对待事件和事故的反应被认为是不公正的，就可能阻碍安全调查，从而在从事安全关键性工作的人员中引发恐惧，使组织更加官僚而不是更加小心谨慎，并且诱发职业性保密、逃避和自我保护。
- 坏苹果理论：人为的错误并不是问题的原因；恰恰相反，人为的错误是我们提供的工具存在设计问题而造成的后果。如果事故并不是“坏苹果”引起的，而是由我们所建立的复杂系统中存在着不可避免的设计问题而导致的，那就不应该对造成故障的人进行“点名、责备和羞辱”。我们的目标应该总是最大限度地抓住组织学习的机会，持续强调我们重视广泛地揭示和交流日常工作中的问题。这样才能提高我们所在系统的质量和安全性，并强化系统内所有人之间的关系。
- 举行不指责的事后分析会议
- 我们要在事故发生之后，记忆消退、因果关系变模糊、环境改变之前，就尽快的安排事后分析会议。
- 我们需要做：
- 构建时间表，从多个角度收集关于故障的所有细节，保证不会惩罚犯错误的人；
- 通过让所有工程师详细说明自己如何导致故障，使他们能够提高安全性；
- 允许并鼓励那些犯错误的人成为教育他人以后不会犯同样错误的专家；
- 营造一个自由决策的空间，让人们决定是否采取行动，并且把对所做决定的评判放在事后；
- 制定预防对应事故的对策，并确保记录这些对策、目标日期和负责人，以便进行跟踪；
- 需要哪些人参与会议：
- 参与相关问题决策的人；
- 识别问题的人；
- 响应问题的人；
- 诊断出问题的人；
- 受问题影响的人；
- 任何有兴趣参加回忆的人；
- 会议中严禁使用“原来应该”或“原本可以”等词语，因为他们是反事实的陈述。
- 尽可能广泛地公开事后分析会议结果
- 广泛地公开这些事后分析文档并鼓励组织中的其他人阅读，能增进组织学习。
- 降低事故容忍度，寻找更弱的故障信号
- 每个人都应该坦然面对失败，承担责任，并从失败中学习。事实上，当事故数量大幅降低时，容忍度同时也下降了，从而让我们能够持续学习。
第20章 预留组织学习和改进的时间
- 改善闪电战
- 是丰田生产系统的重要组成部分，指的是在一个专门集中的时间段里解决特定的问题，通常长达几天。
- 改善闪电战经常采取的形式是，一个小组聚在一起，专注探究一个存在的问题的流程，目标是优化流程，方法则是集中地让 流程之外的人 给通常在流程里的人提建议。
- 让所有人教学相长
- 不论是通过传统的说教方式（上课、培训），还是通过更具实验性或开放式的方法（会议、探讨、工作仿、指导），动态的学习文化都不仅能为每个人创造学习条件，还能创造叫教学机会。我们可以投入专门的组织时间来促进这种教和学。
你的点赞就是我创作的最大动力，如果写的不错，来个三连行不行
《DevOps实践指南》——阅读笔记(长文告警)相关推荐
- 《DevOps实践指南》笔记：第3章
<DevOps实践指南>笔记:第3章 第3章 第二步:反馈原则 在复杂系统中安全地工作 复杂系统特征:1)无法将系统视为一个整体,去理解各个部分是如何组合在一起的.2)复杂系统的组件之间通 ...
- 读《DevOps实践指南》笔记一
第一部分 DevOps介绍 第1章 敏捷.持续交付和三步法 4 1.1 制造业价值流 4 1.2 技术价值流 4 我们通常将技术价值流定义为"把业务构想转化为向客户交付价值的.由技术驱动的服 ...
- 读《DevOps实践指南》笔记三
第五部分 第三步:持续学习与实验的技术实践 第19章 将学习融入日常工作 180 前言 他们有一个特别的设计目标,那就是即使 AWS 的整个可用区域都发生了故障,就像这次美国东部区的事故,也要确保 N ...
- 读《DevOps实践指南》笔记二
第三部分 第一步:流动的技术实践 第9章 为部署流水线奠定基础 70 9.1 按需搭建开发环境.测试环境和生产环境 71 不再需要运维团队手动构建和配置环境,而是可以使用自动化的方式完成以下操作: ...
- python最佳实践指南试题_Python最佳实践指南 阅读笔记
创建将0到19连接起来的字符串1 2 3 4 5 6 7 8nums = [] for n in range(20): nums.append(str(n)) print "".j ...
- 阿里智能运维实践｜阿里巴巴DevOps实践指南
编者按:本文源自阿里云云效团队出品的<阿里巴巴DevOps实践指南>前往:https://developer.aliyun.com/topic/devops,下载完整版电子书,了解阿里十年 ...
- 5种阿里常用代码检测推荐 | 阿里巴巴DevOps实践指南
简介: 随着业务演进和团队扩张,软件规模和调用链路越来越复杂.如若没有良好的代码检测机制,只依靠功能性验证,团队技术债会越累越高,开发团队往往要花费大量的时间和精力发现并修改代码缺陷,最终拖垮迭代进度 ...
- DevOps实践指南 记录
DevOps实践指南 Gene Kim Jez Humble Patrick Debois John Willis◆ 导言:展望DevOps新世界>> 技术债务是指我们当前所做出的决定会导 ...
- 阿里巴巴DevOps实践指南 | 数字化转型下，DevOps的根本目标是什么？
简介:数字化转型是信息技术与产业的结合.需要转型的不仅仅是各个传统的产业,也包含信息产业本身,如互联网公司.DevOps 是数字化转型的重要组成部分,DevOps 的体系和实践也必须服务于数字化转型的 ...
最新文章
- git 切换成远程分支
- 如何快速分辨一个男人是不是程序员
- 第十六周 个人项目开发流程
- 2021-01-10 Halcon初学者知识 【10】形状匹配 【二】模板的形状匹配
- jzoj3171-[GDOI2013模拟4]重心【真·物理,二分】
- 【牛客 - 185A】无序组数 （思维，数学，因子个数）
- step-by-step: 夕小瑶版神经网络调参指南（上）
- JEECG整合finereport快速搭建与开发
- 清华学霸被Facebook开除了
- http get post java_Java发送http的get、post请求 - 穿梭于偶然
- HashMap遍历方式
- 【Centos】【Python】【Flask】阿里云上部署一个 flask 项目
- 深度学习之语义分割（SegNet）
- java基础标识符，关键字，常量
- 共享文件问题 -- 无法访问 您可能没有权限使用网络资源
- TZOJ5855: 数据结构实验：最短路（SPFA）
- 用python的tkinter做游戏（八）—— 实现图片在tkinter中自适应大小（自动匹配窗口）
- lsr: Cannot access .: No such file or directory. 解决办法
- 个人网站搭建,个人网站需要什么软件
- 金庸--王重阳谈学习、旅游、谈交友等等