《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章 预留组织学习和改进的时间

本书共分为6个部分：

第一部分概述DevOps的历史和三个基本原则，即“三步工作法”；第二部分介绍开启DevOps转型的过程；第三到五部分深入探讨“三步工作法”的各个要素；第六部分关注如何将安全性和合规性正确集成到日常工作中。 全书涵盖40余个DevOps案例，以谷歌、亚马逊、Facebook等全球知名企业和组织的实际调查结果为依据，展示如何通过现代化的运维管理提升管理效率，进而为企业赢得更大市场、创造更多利润。

反馈原则的核心思想是：虽然复杂的系统不可避免地存在错误，但是可以通过采取安全措施确保在质量问题出现之前，快速发现和处理错误。 ——曾朝京

敏捷通常是DevOps效率的保障。DevOps不只是自动化，就像天文学不只是望远镜一样。

DevOps三步工作法：

流动原则：它加速了从开发、运维到交付给客户的正向流程；反馈原则：它使组织构建安全、可靠的工作体系，并获得反馈持续学习与实验原则：它打造出一种高度信任的文化，并将改进和创新融入日常工作中； 简史

DevOps基于精益、约束理论、丰田生产系统、柔性工程、学习型组织、安全文化、人员优化因素等知识体系，并参考了高信任管理文化、服务型领导、组织变动管理等方法论。把所有这些最可信的原则综合地应用到IT价值流中，就产生出DevOps这样的成果。将它贯彻于整个技术价值流中，涉及产品管理、开发、QA、IT运维和信息安全专员等不同角色，在更低成本和努力下，保障产品的高质量、可靠性、稳定性和安全性。

聚焦于部署前置时间

前置时间 是在工单创建后开始计时，到工作完成时结束；而 处理时间 则从实际开始处理这个工作才开始计时，它不包含这个工作在队列中排队等待的时间。我们应该吧重点放在 缩短前置时间 ，而不是处理时间上。不过，处理时间与前置时间的比率是十分重要的效率指标，所以我们必须 缩短工作在队列中等待的时间。关注 返工指标 ：该指标反映了价值流中的每个步骤的 输出质量 。关注真正有用的工作。 三步工作法：DevOps的基础原则

第一步：实现开发到运维的工作快速地从左向右流动

工作可视化；减小每批次大小和等待时间；通过内建质量杜绝向下游传递缺陷； 第二步：应用持续、快速的工作反馈机制

缩短反馈周期；放大反馈环防止问题复发； 第三步：建立具有创意和高可信度的企业文化

通过主动承担风险，不但能从成功中学习，也能从失败中学习； 第2章 第一步：流动原则

使工作可见核心，因为所有的优化和分析首先需要有准确的、可见的数据

避免不同的团队/人可能因为信息的不完整而将工作“踢来踢去”，存在的问题也会被传递到下游； 限制在制品数量

将一个工程师同时分配到多个项目里，他不得不在多个任务、认知规则和目标之间来回切换，付出重新进入角色的成本；对于大多数的工作条目而言，在它完成前，其实并无法预测到底需要多长时间； 减少单个批量大小

最小的批量是单件流 减少交接次数

信息或者知识不可避免的在交接中丢失；努力 减少交接次数 或 用 自动化 方式执行大部分操作 或 调整组织架构； 持续识别和改善约束点

如果我们优化约束点之前的那个工作中心，那么工作必将在这个约束点上更快的积压起来；如果优化约束点之后的工作中心，那么它们还会处于饥饿状态； 第3章 第二步：反馈原则

在复杂的系统中安全的工作

管理复杂的工作，从中识别出设计和操作的问题；群策群力解决问题，从而快速地构建新知识；在整个组织中，将区域性的新知识应用到全局范围；领导者要持续培养有以上才能的人； 及时发现问题

目标是更早、更快、以尽可能低的成本、从尽可能多的维度增加系统的信息流，并尽可能清晰的确定问题的前因后果。 群策群力，战胜问题获取新知识

这样做可以让所有参与者都得到更深入的知识，理解如何管理系统，把无法避免的、早期的无知阶段变成学习的过程；丰田的 “安灯绳” 便是一个非常成功的案例

安灯绳系统 ：安灯系统百度百科介绍 防止把问题带入下游的处理环节，否则不但修复的成本和工作量会呈指数级增加，而且还会欠下 技术债；防止工作中心启动新的工作，那样可能会在系统中引入新的错误；如果问题短时间内没有得到解决，那么在下一次操作中可能还会遇到相同的问题，需要更高的修复成本；发现问题时拉动“安灯绳这个行为不应当有惩罚，甚至这个行为是受鼓励的。 在源头保障质量

质量控制无效的案例：

需要其他团队帮忙完成一系列乏味、易出错和手动执行的任务，这些任务本该由需求方自己采用自动化方式完成；需要那些远离实际工作场所且公务繁忙的人批准，迫使他们在不了解工作情况和潜在影响的情况下做出决策，或者仅仅例行公事地盖章批准；编写大量含有可疑细节，且在写后不久就过时的文档；将大量的工作推给运维团队和专家委员去评审和处理，然后等待回复； 不断地为下游工作中心做优化这句话是工作优化的经典

当你不知道需要优化什么东西时，不妨去问问下游。 第4章 第三步：持续学习与实验原则

建立学习型组织和安全文化

正义文化

不公正的事故和意外处理会阻碍安全调查，让安全工作者感到恐惧(而不是专注)，让整个组织更加官僚(而非更加细致)，甚至还会导致信息封闭、责任逃避和滋生自我保全意识；管理者对事故责任人进行惩罚不但会引起恐惧感，还会导致问题和故障的隐瞒不报，直到下一次的灾难性事故发生； 如果不指责，员工就没有恐惧，没有恐惧，就能做到坦诚，而坦诚能够有效预防事故； 将日常工作的改进制度化

比日常工作更重要的，是对日常工作的持续改进；通过明确预留时间来改善日常工作，包括预留时间来偿还技术债、修复缺陷、重构和优化代码和环境。

开发周期的间歇中预留一段时间；闪电改善战；周期内预留20%的时间让工程师来解决他们感兴趣的问题； 把局部发现转化为全局优化

一旦在局部范围内取得了成果，就应当把它分享给组织的其他人把所有的事故报告转化成可搜索的知识库 领导层强化学习文化
-更卓越的领导力其实是为团队创造条件，让团队能在日常工作中感受到这种卓越。

Ron Westrum的组织类型学模型：组织如何处理信息

如何在组织中迈开DevOps转型第一步？谁需要参与？如何组织团队？如何保障团队成员投入精力并在最大程度上获得成功的机会？

从最乐于创新的团队开始

第一步应该将精力集中于少数几个试点领域，确保他们取得成功，然后再逐步扩展；自上而下的大爆炸式转型也不是不可能，但是这个模式需要得到最高层的支持 扩大DevOps的范围

尽早展示成果，并积极宣传。将大的改进目标分解成渐进式的小步骤首先发现创新者和早期采用者然后赢得从众者最后解决“钉子户”
第6章 理解、可视化和运用价值流

拥有共同的目标

对于每次迭代，团队应该定制出一组能够产生价值的小目标，并朝着长期目标靠近。在每次迭代结束时，团队应该检查进度，并为下一次迭代设定新的目标 保持小跨度的改进计划为非功能性需求预留20%的开发时间，减少技术债务

把20%的开发和运维时间投入到重构、自动化工作、架构优化以及非功能需求上。Marty CaganeBay产品与设计高级副总裁指出，如果组织不愿意支付这“20%的税”，那么技术债务将会最终恶化到耗尽所有可用资源的程度。终有一天，服务会变得不堪一击，需求交付将停滞不前，所有工程师都在解决可靠性问题或者寻求临时方案。许多一线公司早期经历过这个场景，最后总结出来的精华 提高工作的可视化程度 第8章 将运维融入到日常开发工作

创建共享服务，提高开发生产力

搭建类生产服务部署流水线自动化测试工具生产环境监控控制台 将运维工程师融入服务团队

服务团队拥有固定的 运维联络人 ；参加开发团队会议；运维工作加入看版图展示； Part 3——第一步：流动的技术实践 第10章 实现快速可靠的自动化测试

如果没有自动化测试，那么我们编写的代码越多，测试代码所花费的时间和金钱也就越多。在大多数情况下，这种商业模式对于任何技术组织而言都是无法扩展的。

尽量将手动测试自动化

自动化测试的目的是尽可能多的发现代码错误，并且减少对手动测试的依赖；执行少量可靠的自动化测试，往往优于执行大量手动测试或不可靠的自动化测试。如果在放弃某个手动测试改为自动化之后，生产环境出现缺陷，那么应该将这个测试重新加入手动测试套件，但最终还是应该将它自动化；当团队已经重视自动化测试之后，可以开始引入度量测试覆盖率，还要把度量的结果可视化，一般可以定义覆盖率为80%；一旦某个开发人员提交的代码变更导致构建或自动化测试失败，需要立即解决这个问题。如果有人在解决问题时需要帮助，他们能获取任何所需资源；我们认为团队目标高于个人目标——在帮助他人推进工作的同时，也帮助了整个团队；每个人都应该知道工作不只是“编写代码”，更是“运行服务”； 第11章 应用和实践持续集成

开发人员在自己的分支上独立工作的时间越长，就越难将这些变更并入主干。事实上，当分支个数和每个分支上的变更数同时增加时，合并难度会骤增。

采用持续集成和基于主干的开发方式

开发人员提交得越频繁，每次的提交量就越小，他们离理想的 单件流 状态也就越近拒绝接受任何使系统偏离可部署状态的提交，这种方式称为门控提交每日提交代码也迫使开发人员进一步分解工作基于主干的开发方式能带来更高的生产力、更好的稳定性，甚至更高的工作满意度和更低的职业倦怠率。 第12章 自动化和低风险发布

自动化部署流程

用相同的方式处理所有环境的部署对部署执行冒烟测试维持环境的一致性 将部署与发布解耦

蓝绿部署金丝雀发布集群免疫系统黑启动技术 第13章 降低发布风险的架构

绞杀者应用模式尤其适用于将单体应用或紧耦合服务的部分功能迁移至松耦合架构。

每个人都能获得工作反馈，信息可见以便于大家学习，能快速测试产品假设，帮助我们判断目前开发的特性是否有助于实现组织的业务目标。

杜绝反事实思维

出现事故，我们应该关注：为什么会出现这个问题？当时我们为什么会这么做？以后我们应该如何避免同类问题？ 而不是去指责，去问为什么当时没有这样/那样做? 同行评审代码评审

同行评审的目标是通过工程师同事的仔细核查来减少变更错误。这种形式的评审不仅提高了变更的质量，还相当于进行了交叉培训。合理的时间是将代码向版本控制系统中的主干提交时。请程序员来看10行代码他能找出10个问题。请他审查500行代码，他会说看起来都不错。代码评审的形式

结对编程

开发 + 开发开发 + 测试老同事 + 新同事每天固定一个小时间段为结对编程时间 电子邮件送审工具辅助评审集中评审：有一个或多个工程师一起去评审一段或多段代码 Part 5——第三步：持续学习与实验的技术实践

将团队或个人在某个领域里学到的经验迅速地应用和推广到整个组织里

建立公正和学习文化

将故障和缺陷视为学习的机遇，而不是惩罚的机会。如果对待事件和事故的反应被认为是不公正的，就可能阻碍安全调查，从而在从事安全关键性工作的人员中引发恐惧，使组织更加官僚而不是更加小心谨慎，并且诱发职业性保密、逃避和自我保护。坏苹果理论：人为的错误并不是问题的原因；恰恰相反，人为的错误是我们提供的工具存在设计问题而造成的后果。如果事故并不是“坏苹果”引起的，而是由我们所建立的复杂系统中存在着不可避免的设计问题而导致的，那就不应该对造成故障的人进行“点名、责备和羞辱”。我们的目标应该总是最大限度地抓住组织学习的机会，持续强调我们重视广泛地揭示和交流日常工作中的问题。这样才能提高我们所在系统的质量和安全性，并强化系统内所有人之间的关系。 举行不指责的事后分析会议

我们要在事故发生之后，记忆消退、因果关系变模糊、环境改变之前，就尽快的安排事后分析会议。我们需要做：

构建时间表，从多个角度收集关于故障的所有细节，保证不会惩罚犯错误的人；通过让所有工程师详细说明自己如何导致故障，使他们能够提高安全性；允许并鼓励那些犯错误的人成为教育他人以后不会犯同样错误的专家；营造一个自由决策的空间，让人们决定是否采取行动，并且把对所做决定的评判放在事后；制定预防对应事故的对策，并确保记录这些对策、目标日期和负责人，以便进行跟踪； 需要哪些人参与会议：

参与相关问题决策的人；识别问题的人；响应问题的人；诊断出问题的人；受问题影响的人；任何有兴趣参加回忆的人； 会议中严禁使用“原来应该”或“原本可以”等词语，因为他们是反事实的陈述。 尽可能广泛地公开事后分析会议结果

广泛地公开这些事后分析文档并鼓励组织中的其他人阅读，能增进组织学习。 降低事故容忍度，寻找更弱的故障信号

每个人都应该坦然面对失败，承担责任，并从失败中学习。事实上，当事故数量大幅降低时，容忍度同时也下降了，从而让我们能够持续学习。 第20章 预留组织学习和改进的时间

改善闪电战

是丰田生产系统的重要组成部分，指的是在一个专门集中的时间段里解决特定的问题，通常长达几天。改善闪电战经常采取的形式是，一个小组聚在一起，专注探究一个存在的问题的流程，目标是优化流程，方法则是集中地让 流程之外的人 给通常在流程里的人提建议。 让所有人教学相长

不论是通过传统的说教方式（上课、培训），还是通过更具实验性或开放式的方法（会议、探讨、工作仿、指导），动态的学习文化都不仅能为每个人创造学习条件，还能创造叫教学机会。我们可以投入专门的组织时间来促进这种教和学。

你的点赞就是我创作的最大动力，如果写的不错，来个三连行不行