这次趁着在家的机会，整理了过去大半年了解到的理论知识，此篇为整理的DevOps的部分。
目录
1 软件交付的问题
产品汪：“这里稍微修改下，要加个小功能”。
程序猿：“又改？这都加了多少功能了？改了多少次了？”。
测试小姐姐：“怎么回事？刚才这个功能是好的，开发你改啥了，把这个功能弄坏了”。
实施小哥：“你🐎，这什么烂系统，每次部署都有问题”。
是不是很熟悉？嗯，很熟悉，每每回忆如此，都会情不自禁照照镜子，叹息下自己上扬的发际线。
要是需求定义、设计、开发、测试、部署发布能高效可靠该多好！
2 DevOps介绍
“DevOps和它所产生的技术、架构及文化实践，体现了哲学和管理学的原则的融合”，
“DevOps基于制造业实践了数十年的管理经验，它是将可靠性组织、信任度管理与DevOps实践相结合的产物”，
“DevOps基于精益、约束理论、丰田生产系统、柔性工程、学习型组织、安全文化、人员优化等知识体系，并参考了高度信任管理文化、服务型领导、组织变动管理等方法论。把所有最可信的原则综合地应用到IT价值流中，就产生出DevOps这样的成果。将它贯彻于整个技术价值流中，涉及产品管理、开发、QA等不同角色，在更低的成本和努力下，保障产品的高质量、高可靠性、稳定性和安全性。”，
“DevOps也被许多人视为始于2001年的敏捷运动的延续”。
精益运动：价值流映射、看板和全面生产维护起源于丰田生产系统。
精益的两个主要原则：坚信前置时间（把原材料转换为成品所需的时间）是提升质量、客户满意度和员工幸福感的最佳度量指标之一；小批量任务的交付是缩短前置时间的一个关键因素。
敏捷宣言中一个重要的原则“频繁地交付可工作的软件，交付周期可以是数星期也可以是数月，推荐更短的周期”，并强调使用小批量任务进行增量发布，而非大规模的作业和瀑布流程的发布。同时，强调建立自组织的小团队，让成员在高度信任的环境中愉悦地工作。
持续交付：基于持续构建、测试和集成的开发原则。在持续交付中，“部署流水线”确保代码和基础设置始终处于可部署状态，所有提交到主干的代码可以安全地部署到生产环境。
3 敏捷、持续交付和三步法
精益中的一个基本概念叫价值流。
制造业价值流：一个组织基于客户的需求所执行的一系列有序的交付活动。
技术价值流：把业务构想转化为向客户交付价值的、由技术驱动的服务所需要的流程。
聚焦于部署前置时间：部署的前置时间是价值流的一个子集，始于工程师向版本控制系统中提交一个变更，止于变更成功地在生产环境中运行，为客户提供价值，并生成有效的反馈和监控信息。
在第一阶段中，工作主要包括设计和开发，具有高度的变化性和不确定性，不仅需要创意，某些工作还可能无法重来，这导致无法确定总体处理时间；在第二阶段中，工作主要包括测试和运维，它需要创造性和专业技能，力求可预见性和自动化，将可变性降到最低，并满足业务目标。
不提倡在设计、开发中串行地完成大批量工作后，在转入测试、运维阶段。目标是采用测试和运维与设计和开发同步的模式，从而产生更快的价值流和更高的质量，只有当工作任务是小批量的，并将质量内建到价值流的每个部分时，这种同步模式才能实现。
前置时间和处理时间是度量价值流性能的两个常用指标。
前置时间：在工单创建后开始计时，到工作完成时结束；
处理时间：从实际开始处理这个工作时才开始计时，不包含这个工作在队列等待的时间
重点在缩短前置时间而不是处理时间上，处理时间与前置时间的比率是十分重要的效率指标，为了实现快速的流动并缩短前置时间，必须缩短工作在队列中的等待时间。
在DevOps的理想情况下，开发人员能快速、持续地获得工作反馈，能快速和独立地开发、集成和验证代码，并能将代码部署到生产环境中。为了达到这个目标：向版本控制系统中持续不断地提交小批量的代码变更，并对代码做自动化测试和探索测试，然后再将它部署到生产环境中。这样就能对代码变更在生产环境中的成功运行保持高度自信，同时还能快速地发现并修复bug，还需要通过模块化、高内聚、低耦合的方式优化架构设计，帮助小型团队自治地工作。
返工指标：除了前置时间和处理时间，技术价值流中的第三个关键指标是完成时间和精确的总花费时间的百分比（%C/A），该指标反映了价值流中的每个步骤的输出质量，要获取%C/A，可以询问下游客户他们有百分之多少的时间收到了‘真正有用的工作’，即他们可以专心做有用的工作，而不必修复错误信息、补充信息、或者澄清那些本该确定的信息。
三步工作法原则：
第一步，实现开发到运维的工作快速地从左向右流动。
第二步，在从右向左的每个阶段中，应用持续、快速的工作反馈机制。
第三步，建立具有创意和高可信度的企业文化，支持动态、严格的、科学的实验。
4 流动原则
建立从开发到运维之间快速的、平滑的、能向客户交付价值的工作流，要为这个全局目标进行优化，而非围绕一系列局部目标，如功能开发的完成度、测试中问题的发现率和修正率、运维维护的可用性等。通过持续加强工作内容的可视化，减小每批次大小和等待间隔，内建质量以防止缺陷向下游传递，从而增强流动性。通过加快流动，缩短前置时间，进一步提高质量。
使工作可见：为了能识别工作在哪里流动、排队或停滞，就需要将工作尽可能地可视化，可视化工作板（看板或Sprint计划板），工作通常从左侧发起 （从待办事项中拉取），然后从一个工作中心拉取到下一个工作中心，最后到达工作板的最右边，而这一列也通常被标记为“完成”或“已上线”。
理想情况下，看板应该覆盖整个价值流；仅当工作到达看板最右侧时，才能算是已完成，开发完成某个功能不能算是“已完成”，只有应用程序在生产环境里成功地运行起来，并开始为客户提供价值的时候，才能算是“已完成”。
限制在制品数：使用看板限制多任务的出现，避免多任务导致更长的处理时间。
减小批量大小：小批量生产的制品更少，前置时间更短，错误检测更快，返工量更少。
减少交接次数：代码在价值流流转过程中，需要各个不同部门的协同才能完成相关任务，一项工作在团队之间交接时，需要大量沟通，交接工作的成本会很高。为了减少这类问题的出现，要么努力减少交接次数，要么用自动化方式执行大部分操作，要么重新调整组织结构，让团队不必依赖其他人就可以独立为客户提供价值。
持续识别和改善约束点：为了缩短前置时间、提高吞吐量，需要不断识别系统中的约束点，提高工作产能。在devOps的转型过程中，一般需要依次优化下面的约束点：环境搭建、代码部署、测试的准备和执行、紧密耦合的架构。DevOps转型中使用价值流映射和度量的方法，来识别约束点。
消除价值流中的困境和浪费：精益中对浪费的常用定义是“使用来超出客户需求和他们意愿支付范围的任何材料或资源的行为”，浪费和困境是软件开发过程中导致交付延迟的主要因素。浪费和困境的部分类型：半成品、额外工序、额外功能、任务切换、等待、移动、缺陷、非标准或手动操作、填坑侠。
流动原则使得工作能够在价值流中从左向右快速地流动。
5 反馈原则
反馈原则使得在从右向左的每个阶段中能够快速、持续地获得工作反馈，目标是建立安全和可靠的工作系统。
通过在整个价值流和组织中建立快速、频繁、高质量的信息流，包括反馈和前馈回路，可以让系统更安全。这样就可以在规模较小、修复成本较低的情况下发布并修复问题，在灾难发生前消除问题，并创造出组织性学习氛围。
在复杂系统中安全地工作：复杂系统中的故障是存在且不可避免的，必须设计出一个安全的工作系统，能够无所畏惧的工作，确保早在灾难性后果发生前，能快速检测出错误。措施：1，管理复杂的工作，从中识别出设计和操作问题；2，群策群力解决问题，从而快速地构建新知识；3，在整个组织中，将区域性的新知识应用到全局范围；4，领导者要持续培养有以上才能的人。
及时发现问题：不断地对设计和假设进行验证，以便更早、更快、成本更低、尽可能多的维度增加系统的信息流，尽可能清晰地确定问题的前因后果。在所有工作执行的过程中，建立快速的反馈和前馈回路，包括创建自动化的构建、集成和测试过程，以便更早检测出bug。还可以建立全方位的监控系统，监控服务组件在生产环境中的运行状态，以便快速探测到服务的意外情况，监控系统还可以帮助我们度量是否偏离流预期目标，并将监控结果辐射到整个价值流中，这样就能看到我们的行为是如何影响系统里的其他部分的。
群策群力，战胜问题获取新知：群策群力的目的是遏制住问题，防止蔓延，然后定位和处理问题，避免复发，防止记忆模糊的情况导致关键信息遗失。
在源头保障质量：价值流中的每个人在自己控制领域里发现并解决问题，可以把质量控制、安全责任和决策制定都置于开展工作的场景里，而不是依赖于外围高层管理者的审批。根据同行评审来评定所提出的变更，确保这些变更按设计运行，尽可能多用自动化方式执行通常由QA和信息安全人员来进行的质量检测，按需执行自动化测试，而无需开发人员向测试团队请求或发起测试工作，这样开发人员能够快速地测试自己的代码，甚至把代码的变更部署到生产环境中。
为下游工作中心而优化：精益定义了两类客户，外部客户和内部客户，根据精益原则，我们最重要的客户是我们的下游，为他们而优化我们的工作，从而更好地识别出会阻碍快速和平滑流动的设计问题。在技术价值流中，我们通过为运维而设计来为下游工作中心做优化，包括运维的非功能性需求（如架构、性能、稳定性、可测试性、可配置性和安全性）。
6 持续学习与实验原则
技术价值流的核心是建立高度信任的文化，强调每个人都是持续学习者，必须在日常工作中承担风险，通过科学的方式改进流程和开发产品，从成功和失败中积累经验教训，从而识别有价值的想法，摈弃无用的想法，所有局部的经验都会快速转化为全局性的改进，从而帮助整个组织尝试和实践新技术。通过建立持续、动态的学习机制，帮助团队快速并自动地适应不断变化地环境，进而帮助企业在市场竞争中脱颖而出。
建立学习型组织和安全文化：在复杂系统中工作时，精确地预测出结果是不现实的，准备在充分也会出现故障。在技术价值流中，通过努力打造安全的工作系统，建立起生机文化基础，在意外故障发生时，关注如何重新设计系统，从而防止事故复发，而不是去追究人的问题。消除指责能够有效实现学习型组织，使“组织自我诊断和自我优化，并能熟练地定位和解决问题”。
企业文化类型：
病态型：病态型组织地特点是组织中存在大量恐惧和威胁。由于政治原因，个体为了保全自身利益，通常会隐藏真相或者歪曲事实。
官僚型：官僚型组织的特点是规则和流程僵化，所有部门通常都“自扫门前雪”。在这种组织中，通过评判系统处理事故，结果往往恩威并用。
生机型：生机型组织的特点是积极探索和分享信息，让组织更好地履行使命。在这种组织中，整个价值流中所有的员工共同承担责任，对事故进行积极反思，并进行真正的根因调查。
将日常工作的改进制度化：就算不去优化现状，流程也不会是一成不变的----由于混乱和无序，流程会随着时间的推移持续恶化。通过明确预留时间来改善日常工作，包括预留时间来偿还技术债、修复缺陷、重构和优化代码环境，可以在每个开发周期的间歇预留一段时间，或者安排改善闪电站时段，让工程师通过自组织团队的方式来解决他们感兴趣的问题。
把局部发现转化为全局优化：一旦在局部范围内取得了成果，就应当把它分享给组织里的其他人，让更多人从中获益，在技术价值流中，通过建立全局知识库，把个人专业知识转化为服务更多成员的集体智慧。
在日常工作中注入弹性模式：高绩效组织通过改善日常运营，持续地引入张力提高生产效率，同时在系统中注入更大的弹性，来实现或达到更佳的结果。在技术价值流中，通过缩短部署的前置时间、提高测试覆盖率、缩短测试执行时间，甚至在必要时解耦架构，都属于在系统中引入类似张力的做法，也都能够提高开发人员的生产效率及可靠性。另外还可以通过演习的方式来预演大规模故障。
领导层强化学习文化：卓越的领导力其实是为团队创造条件，让团队能在日常工作中感受到这种卓越，这需要领导者和员工共同努力，每个人都相互依存，缺一不可。领导者和一线工作者之间是互补的工作关系，必须互相尊重。领导者必须强调解决问题的能力和学习的价值。我们可以建立相互嵌套的迭代的短期目标，然后在价值流或工作中心级别设立目标条件，以实现这些目标。这些目标构成了科学实验的 框架：清晰地描述出要解决的问题，对解决方案所做的假设，验证假设的方法，对结果的解释，以及如何利用经验进行下一个迭代。
领导者可以使用下列问题来帮助和辅导试验者：
1，上一步做来什么？发生了什么？
2，你从中学到了什么？
3，现状如何？
4，下一个目标条件是什么？
5，当前工作有什么阻碍？
6，下一步做什么？
7，期望的结果是什么？
8，什么时候能进行复查？
在技术价值流中，这种实验和迭代改进的方法，帮助我们改进内部流程，也帮助我们改进产品。
参考资料：
《DevOps 实践指南》
4万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
