技术分享会丨DevOps概述及核心原则讲解

姚冬老师的分享内容非常精彩：

一．DevOps 的发展历史。DevOps与精益、敏捷和其他的管理运动的关系。

DevOps本身的方法以及它的技术、架构、文化实践都参考了这些优秀的管理方法、管理运动、管理哲学，DevOps是以上这些方法的集大成者。

二．凤凰项目的三步工作法：

《凤凰项目：一个IT运维的传奇故事》是一本小说。用小说的形式讲述一位IT经理临危受命，在未来董事的帮助和自己“三步工作法”理念的支撑下，最终挽救了一家具有悠久历史的无极限零件有限公司的故事。

第一工作法 是关于从开发到IT运维再到客户的整个自左向右的工作流。为了使流量最大化，我们需要小的批量规模和工作间隔，绝不让缺陷流向下游工作中心，并且不断为了整体目标（相对于开发功能完成率、测试发现/修复比率或运维有效性指标等局部目标）进行优化。

第二工作法 是关于价值流各阶段自右向左的快速持续反馈流，放大其效益以确保防止问题再次发生，或者更快地发现和修复问题。这样，我们就能在所需之处获取或嵌入知识，从源头上保证质量。

第三工作法 是关于创造公司文化，该文化可带动两种风气的形成：不断尝试，这需要承担风险并从成功和失败中吸取经验教训；理解重复和练习是熟练掌握的前提。”

三．三步工作法在DEVOPS流程中的具体实践：

3.1第一部分是Flow，让价值快速流动，其中有六个实践，分别是：可视化、限制在制品、减少规模、减少交接数量、持续识别和拓展约束，以及在价值流中消除浪费。

建立基于稳定的自动化部署流水线的持续交付，团队能够使用自动化测试持续验证代码，确保代码始终处于可部署的状态，开发人员要保证每天都向主干提交代码，以及构建有利于实施低风险发布的环境和软件架构。重点的内容如下：

* 为部署流水线奠定基础

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

* 实现并实践持续集成和持续测试

* 通过自动化、架构解耦等方式实现低风险发布

这些实践能有效缩短创建类生产环境的前置时间。同时，持续测试可以为所有团队成员提供快速的反馈，使小型团队能够安全、独立地开发、测试和向生产环境部署代码，从而将生产环境的部署和发布作为日常工作的一部分。

此外，通过将QA人员和运维人员的任务集成到DevOps实施团队的日常工作中，能够减少救火、困境以及繁琐的重复劳动的发生，使团队成员的工作高效且充满乐趣。这不仅能提升团队的工作质量，还能提高组织的竞争力。

Tips 1:关于识别价值流和约束理论：

在实践运用流动原则的相关技术实践实施以上价值流的过程中，可以使用Goldratt博士给出的方法，随时识别并解决价值流中的约束点，这个五步法如下：

* 识别系统的约束点。

* 决定如何利用这个系统约束点。

* 基于上述决定，考虑全局工作。

* 改善系统的约束点。

* 如果约束点已经突破了，请回到第一步，但要杜绝惯性导致的系统约束。

以上五步法是DevOps实施项目组日常工作的必备流程优化工具。

传统企业或者团队里最容易发生的约束点有一定的共性，一般可能会按照以下顺序逐个攻克和优化：

1. 环境搭建

2. 代码部署

3. 测试的准备和执行

4. 紧密耦合的架构

Tips2: 关于消除浪费

在DevOps工作团队里需要尽可能地避免以下浪费现象的发生：

* 半成品

* 额外/多余工序

* 额外/多余功能

* 任务切换

* 等待

* 移动

* 缺陷

* 非标准或手工操作

* 填坑侠

3.2第二部分“反馈”的四个实践：

·       第一是在出现问题时及时发现

·       第二是密集解决问题、构建新的知识

·       第三是将质量向源头推进

·       第四是为下游工作进行优化。

“必要的做法包括：在部署管道中的构建和测试失败时“停止生产线”；日复一日地持续改进日常工作；创建快速的自动化测试套装软件，以确保代码总是处于可部署的状态；在开发和IT运维之间建立共同的目标和共同解决问题的机制；建立普遍的产品遥测技术，让每个人都能知道，代码和环境是否在按照设定的运行，以及是否达到了客户的目标。

3.3 三步工作法最后一步是持续学习和实验原则。这里面提了四个实践：

·       第一是开启组织学习和安全文化

·       第二是让日常工作的改进做到制度化

·       第三是将局部发现转为组织全局改进

·       第四是在日常工作中注入恢复模式。

“尝试和承担风险让我们能够不懈地改进工作系统，这经常要求我们去做一些与几十年来的做法大不相同的事。一旦出了问题，不断重复的日常操练赋予我们的技能和经验，令我们可以撤回至安全区域并恢复正常运作。

必要的做法包括营造一种勇于创新、敢于冒险（相对于畏惧或盲目服从命令）以及高信任度（相对于低信任度和命令控制）的文化，把至少20%的开发和IT运维周期划拨给非功能性需求，并且不断鼓励进行改进。”

一．由技术中心规划，研发管理中心牵头的开发测试云项目已经启动

目前已经实现各个模板编译解耦，大大减少编译打包的时间。另外本周会完成第一个模块的自动化部署。

开发测试云项目，基于我们现有的项目，构建持续交付流水线：

二．许多优秀的DevOps实践，我们已经开始实践：

我们PMO除了各自团队的JIRA电子看板，最近还建立了基于OES大型软件交付的物理看板，该看板为高层级业务看板，旨在可视化整个大型项目进展，同步各团队进度和状况，提前暴露问题和风险：

智慧财务与系统平台看板：

供应链看板

人力与绩效&成本看板

研发管理中心的敏捷教练带领大家，以基于迭代的软件开发模式，形成固定的发版节奏，约定每周一配管可以向各团队提供标准版本的四级版本包，确保用户可以以可预期的节奏，拿到经过测试的稳定的包。尽量减少紧急发版，紧急修改导致发版错误的情况出现。同时规范各模块的数据库增量脚本，确保新版本的数据库脚本对上一版本的增量部分可以用来支持单模块升级，实现版本与数据库管理同步，并且任何给出去的程序和脚本可记录，可查询。

三．建立持续改进，和学习型组织的文化

研发管理中心组织Sonar代码检查，建立性能问题分享Confluence 空间，BUG问题分析，都是为了总结各团队出现的问题，建立团队共同学习的氛围。

比如性能知识共享空间：

各团队可以创建性能问题的解决方法，如何下次避免该问题重复出现的办法：