《Devops实践指南》学习总结(全干货)

Devops基于精益原则，约束理论，和丰田套路运动，并拓展了”基础设施即代码“的实践，被人们视作敏捷运动的延续
基础设施即代码 包括 持续集成，持续交付，和持续部署

技术价值流：把业务构想转化为向客户交付价值的，由技术驱动的服务所需要的流程
前置时间：从工单创建到工作完成需要的时间
处理时间：从开始处理到完成需要的时间

Devops的基础原则，三步工作法

第一步：流动原则

实现开发到运维的工作快速的从左向右流动

• 将工作可视化
• 限制在制品数
• 减少批量大小
• 减少交接次数
• 持续识别和改进约束点，环境搭建，代码部署，测试，架构等环节中改进
• 消除日常工作中的浪费

第二步：反馈原则
使得从左到右每个阶段都够快速、持续地获得工作反馈

• 及时发现问题，建立监控系统
• 群策群力解决问题
• 在源头保障质量
• 不断地为下游工作重心做优化，

第三步：持续学习与实验原则
要建立持续学习与实验的文化

• 建立学习型组织和安全文化
• 将日常工作的改进制度化
• 把局部发现转化为全局优化
• 在入场工作中注入弹性模式
• 领导层强化学习文化

从何处开始

5选择合适的价值流作为切入点

绿地项目，绿地项目指全新的软件项目，Devops绿地项目指一些试点项目
棕地项目，devops棕地项目指那些已经服务客户几年几十年的产品或服务，这些项目一般背负大量的技术债务(Technical debt)，无自动化测试，运行在无人维护的平台等

兼顾记录型系统和交互型系统：兼顾”做的正确“和“做的快速”，兼顾质量和速度

从最乐于创新的团队作为切入点，并在此基础上扩大范围

• 发现创新者和早期采用者
• 赢得沉默的大多数
• 识别钉子户：那些有影响力的反对者，只有在获得大多数人的支持，建立起最够的群众基础之后，在考虑这一群体

6理解，可视化和运用价值

确定创造客户价值所需团队**

确定客户价值流团队所需成员：产品负责人，开发团队，QA团队，运维团队，信息安全团队，发布经理，技术主管或价值流经理

针对团队工作绘制价值流图

组件专门的转型团队

• 拥有共同的目标
• 保持小跨度的改进计划，如创业团队一样，在数周内要奴鲁获得可度量的改进成果或者可用的数据
• 为非功能性需求预留20%的开发时间，减少技术债务,确保20%开发时间用于重构，自动化工作，否则应付老问题已经让自己不堪重负，根本无法开展新工作，这就在偿还技术债务的利息
• 提高工作的可视化程度

用工具强化预期行为

比如聊天室

参考康威定律设计组织架构

康威定律：软件的架构反映了软件团队的结构
换句话说，软件开发团队的结构对软件产品的架构和成果有着巨大的影响

组织原型**

职能型：注重提高专业技能，优化分工和降低成本
矩阵型：结合职能型和市场型，组织结构负责，一名员工可能要向多个经理汇报
市场型：注重快速响应客户需求

过度职能导向的危害（成本优化）

根据专业领域组织团队，对于无需进行频繁交付的软件来说肯能没问题，但对于复杂交付工作，一项工作开多个工单，协调复杂，导致交付周期延长，

组建以市场为导向的团队（速度优化）

将工程师及其专业技能嵌入每个服务团队，使每个服务团队都能独立的向客户交付价值，而不必提交工单给IT运维，QA和信息安全部门

使职能导向有效

职能导向也可以成就高效运转的组织，要求组织文化上高度信任，工作优先级透明，系统预留了足够的容量能够迅速的完成高优先级的工作。

将测试、运维和信息安全融入到日常工作中

使团队成员都成为通才

给工程师提供学习必要技能的机会并各职位轮岗，全栈工程师。

投资于服务和项目，而非产品

组建稳定的服务团队，持续提供资金，不因为项目的完成而解散团队。

根据康威定律设置团队边界

理想状况下，软件的架构应该保证小团队能够独立运作，彼此充分解耦，从而避免过多的不必要的沟通和协调

创建松耦合架构，提高生产力和安全性

在紧耦合的架构中，即使是小范围的变更也会导致大规模的故障，相反，如果架构能够支持小团队独立，安全、快速的进行开发测试和部署，就可以提高和维持开发人员的生产力，**面向服务架构(SOA)**就有这种特征，微服务就是基于这种架构。

将运维融入日常开发工作

三个通用策略：

• 构建自服务能力，帮助开发人员提高生产力
• 将运维工程师融入服务团队
• 如果运维工程师人数紧张，则可以采用运维联络人模式

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

运维部门要想取得以市场为导向的成果，一种做法是创建一套集中式全自动化平台与工具及服务(例如流水线，自动化测试平台)，并且是按需提供，不用提交工单等待手动处理。

将运维工程师融入服务团队

另一种做法：将运维工程师融入团队，使团队自给自足。参与开发团队的相关讨论，计划会议，每日站会等

为每个团队分派运维联络人

与融入运维工程师的模式相同，运维联络人也要参加团队的站会，把团队的需求纳入整体的运维计划，并且在必要的时候执行相关任务，在发生资源竞争或优先级冲突时，团队依赖运维联络人推进问题的解决。

邀请运维工程师参加开发团队的会议 包括每日站会、计划会议、回顾会议

• 更好的了解开发团队的文化
• 更好的为产品团队植入运维能力

流动的技术实践

重点讨论以下内容：

• 为部署流水线奠定基础
• 实现快速可靠的自动化测试
• 实现并实践持续集成和持续测试
• 通过自动化、架构解耦等方式实现低风险发布

为部署流水线奠定基础

如何搭建环境，
如何使用版本控制系统的使用范围包含价值流中的每个成员，
如何使基础设施更容易重复搭建，

按需搭建开发环境、测试环境和生产环境

自动化的搭建环境

应用统一的代码仓库

版本控制系统应该应用到价值流中的每一个环节，我们能够重复和可靠地重新生成软件系统的所有组件，必须把下列资源纳入版本控制系统，要求能重现各个环境，包括预生产环境和构建环境

• 应用的所有代码和依赖项
• 任何用于创建数据库模式的脚本、应用的参考数据等
• 所有用于搭建环境的工具和工件 puppet或chef配置模块等
• 任何构建容器所使用的文件
• 所有支持自动化测试和手动测试的脚本
• 任何支持代码打包、部署、数据库迁移和环境置备的脚本
• 所有项目工件(需求文档、部署过程、发布说明等)
• 所有云平台配置文件
• 创建支持多种基础设施服务(企业服务总线、数据库管理系统、DNS区域文件、防火墙配置规则和其他网络设备)所需的任何脚本和其他配置信息

为什么要对环境进行版本控制更能预测IT效能和组织绩效呢？
实际上，几乎在所有情况下，环境的可配置参数都要比代码的可配置参数多好几个数量级，所以，环境最需要使用版本控制

使基础设施的重建更容易

就算生产环境只有一台服务器，也要采取按需快速重建环境的方法
通过重复创建环境，更快的水平扩容，避免当不可再现的基础设施发生灾难性故障后必须修复的痛苦。
要确保所有变更都能自动地复制到所有环境并被版本控制系统记录，而不需要手动登陆服务器
要频繁的更新环境，这样在能在开发周期的最早阶段找出问题(整个应用栈和环境都可以固化到容器中，这也可以简化整个部署流水线)

运行在类生产环境(类似生产环境)里才算完成

构建从开发到运维的快速工作流，需要确保任何人都能按需获得类生产环境，通过让开发人员在最初就用类生产环境，可以显著降低生产环境出现问题的风险

实现快速可靠的自动化测试

来自谷歌的统计数据：

• 每天4万次代码提交
• 每天五万次代码构建
• 拥有12万个自动化测试套件
• 每天运行7500万个测试用例
• 拥有100多名专门执行测试用例、持续集成和发布工具的工程师，他们负责提升开发人员的生产效率

对代码和环境做持续构建、测试和集成

让开发人员在日常工作中创建自动化测试套件，建立快速的反馈回路，尽早发现问题
通过创建部署流水线，当新的变更进入版本控制系统时，就会触发一系列自动化测试
部署流水线确保所有检入版本控制系统的代码都是自动化构建的，并在类生产环境中测试过。当开发人员提交代码变更之后，立即就能获得关于构建、测试和集成错误的反馈，从而使开发人员能够立即修复这些错误。正确的持续集成实践总是可以确保代码处于可部署和可交付状态。
为了实现这点，必须在专用环境中创建自动化构建和测试流程，原因如下：

• 在任何时候，构建和测试流程都能够运行，无论工程师的个人习惯如何
• 独立的构建和测试流程确保工程师能理解构建、打包、运行和测试代码所需的全部依赖(消除在开发人员电脑上可以运行，在生产环境不行的问题)
• 将应用的可执行文件和配置打包，并可以在环境中重复安装
• 将应用打包到可部署的容器中
• 以一致、可重复的方式进行类生产环境配置

构建快速可靠的自动化测试套件

强调执行持续集成和持续测试的必要性？如果只夜间构建，将会发生什么？
假设团队10名开发人员，每人每天检入一次，而某个开发人员的代码导致夜间构建和测试失败，则第二天才能发现，可能要花几个小时才能解决问题，更糟的是如果问题不是代码变更，而是测试环境(例如某个错误的环境配置)，那么开发团队很可能认为问题已经解决，因为所有的单元测试都通过了。可是在夜间构建的过程中，集成测试仍会失败，如果新的一天又检入10个变更，而每个变更都可能引入错误，进一步增加了解决问题的难度

这样就要求当有新的变更检入控制系统时，需要在构建和测试环境中运行快速的自动化测试，立即发现问题，
通常自动化测试从快到慢分为以下几类：

• 单元测试：确保每个方法，类函数正确，
• 验收测试：整体测试应用，确保各个功能模块按照正常设计正常工作，并且没有引入回归错误（没有破坏以前正常的功能）
• 集成测试：保证应用和生产环境中的其他应用和服务正确交互