2017年10月20日晚，光环学友会DevOps在线讲座和1600+光环学友和DevOps爱好者如期相约线上，本次我们的分享主题是《平安DevOps演进历程与实践—拉动端到端价值交付》。特邀的主讲嘉宾是瞿老师，瞿老师是平安科技高级敏捷教练，EXIN DevOps Master、MBA、CSM、KMP、SAFe Agilist。曾主导平安大型金融产品线、腾讯多款知名手游产品改进，深度参与华为大规模敏捷变革，辅导多个团队成功实施DevOps转型。他是研发效率提升的践行者，关注DevOps、精益、敏捷、设计思维、精益创业等领域。
瞿老师的分享从3层面展开：
一、什么是DevOps？为什么要做DevOps？
二、平安科技DevOps演进历程
三、互联网金融产品DevOps案例分享
一、什么是DevOps？为什么要做DevOps？
1、为什么要做DevOps?
开发和运营之间存在一堵高墙’。用一个有趣的词来描述开发与测试之间的状态，那就是“同床异梦”。因为在产品的变与不变、系统的稳定性等方面，两者关注点不同，存在分歧和差异：运营人员要求更好的可靠性和安全性,开发人员则希望基础设施响应更快，而业务用户的需求则是更快地将更多的特性发布给最终用户使用，造成“信息鸿沟”。而在部署文档、代码等方面，开发人员经常不考虑自己写的代码会对运营造成什么影响。在交付代码之前，运营人员也不参与架构决策或代码评审。开发人员对配置或环境进行修改之后，经常没有及时与运营人员沟通，导致新的代码不能运行，双方似乎“隔墙相望”。这些问题给企业实现业务连续性、实现持续集成、持续交付的要求，最终实现提升业务产量的目标造成极大的阻力。
2、什么是DevOps?
DevOps提出，是基于传统产品开发过程中，部门间存在的 “部门墙”现象。这一现象，反映在传统工作模式下，开发与运营部门各管一段、相互隔离，分别面对测试环境与正式环境。开发部门对新版本的发布，与来自运营部门的产品缺陷修复需求，要求不断的穿透这种隔离。这导致很多问题，效率低下。
DevOps来自于Development和Operations的组合，突出重视软件开发人员和运维人员的沟通合作，通过自动化流程来使得软件构建、测试、发布更加快捷、频繁和可靠。DevOps是为了填补开发端和运维端之间的信息鸿沟，改善团队之间的协作关系，通过打通软件产品交付过程中的IT工具链，使得各个团队减少时间损耗，更加高效地协同工作。DevOps的理想作用是显而易见的，当前我国绝大多数互联网企业也着力于通过DevOps实现产品的敏捷快速开发运维，但是DevOps实践也需要方法和手段。
二、平安科技DevOps演进历程经历了四个阶段：
1、第一阶段：2004年-2010年，一是整个过程协作，逐步开发运营渗透，改善可用性协作。例如：根据交付的要求，开发和运行最初是有一个严格的分解点；而随着客户需求的演进，运营向上游研发渗透，而研发也不断介入运营，变成一个协作过程。
对于某一事件（例如灯灭了），传统流程第一是问题分析，找出原因提出解决方案；第二采购请求等等；而一旦发生重大事件（如整个教室的灯灭了），则需要更长的解决过程。
二是环境搭建上的协作，在项目经理和研发团队之间，设立打包经理，他既了解软件工程师的工作，也明白项目经理的诉求，更快的交流和沟通，提高协作效率。
2、第二阶段：2011年-2013年：开发敏捷转型+运维自动化。
理解一个问题：为什么要做？其根源是基于内外压力。平安的压力大，但不是来自于银行和客户压力，而是来自数字化、互联网行业、BAT的压力。当时所面临的压力之大，企业要么掉入深渊全军覆没，要么跳上气球实现腾飞，所谓挑战与机遇并存。
2010年保险、银行等业务开始切入，平安的策略之一就是建立试点团队，成就之一就是将原来电话直销，转型为保险网上直销。
作为改进策略，采用成熟度雷达图来进行分析。
测试与运维前置——产品中心制
跨模式迭代——变成小瀑布，测试与开发隔离，变成测试与研发一个团队。更频繁的发布、每次发布包含的变化更少。由于部署经常进行，因此每次部署不会对生产系统造成巨大影响，应用程序会以平滑的速率逐渐生长。加强发布协调靠强有力的发布协调人来弥合开发与运营之间的技能鸿沟和沟通鸿沟；自动化强大的部署自动化手段确保部署任务的可重复性、减少部署出错的可能性。
3、第三阶段：2014年-2015年，价值阻碍，工程师文化
平稳的文化过渡是让DevOps获得长期成功应用和增强发布软件产品的综合能力的关键。全流程价值流优化，消除浪费和瓶颈，打造精益研发企业，基于互联网思维的产品创造，一站式研发，敏捷领导力。
梳理构架：代码管理策略优化，树冲突，文化冲突。工程师文化与技术卓越，多维度培训，案例分析分享，课程培训，能力建设，成立平安大学。
4、第四阶段：2016年开始，端到端持续交付流水线，神兵Wizard，智能化监控。
黑暗时代：70%的人力投入需要控制；例如：上海、深圳的需求理解不一致；软件版本配套混乱，不敢升级；代码分支蔓延，成本持续增长；团队过载，疲于应付。
5、小结：在开发运维一体化过程中，需要进行系统化思考。
（1）需求：采取源头引导的策略。银行、客户的需求很多，但要分析哪些是有价值的，主要的方法有：需求分类、建立统一需求池、需求可扩展
（2）流程协作——标准产品，归档制品库
（3）持续交付——制品库管理模式，流水化作业
（4）研发协作——共同目标，稳定的节奏，健康迭代，系系统隔离，整体统一化。只验收是否满足需求，不验收功能。
三、互联网金融产品DevOps案例分享
1. 项目背景：
本产品服务对象为中小型银行，供其搭建服务产品组合，为客户提供服务。
2. 产品开发中遇到的问题：需求都是定制化的，标准化严重不足；版本配套混乱，不敢轻易升级；代码分支蔓延，成本持续增长；团队过载，无以为继；
3. 采用DevOps，系统化思考：需求、流程、协作、交付
(1)需求管理：
源头引导：识别目标中小型银行的价值，支持目标一致、收益较高的产品
标准产品倾斜：将需求分类（标准/定制/运营类）；统一需求池（可视化）；可扩展（组件化/配置）
(2)流程协作：
标准产品：将标准产品，进入归档制品库；
实施产品：
由银行方案设计、交付版本计划、需求/组件配套建立、标准产品开发、联调(3)定制配置、测试验证、UAT验证、发布；
项目组合分层管理
(3)持续交付：
配置结构化梳理：标准组件规范、银行实施配置规范、数据库规范
代码分支收编
自动化测试
制品库管理模式
制品库管理应用
银行实施模式
一体化流水线应用
运维自动化
(4)研发协作
包含共同目标、完整团队、相互承诺、稳定的节奏、透明化、赋权赋能
需求定制降至10%；团队效率提升1倍；一天多发，按需交付；质量跨越式提升；银行监管；研发模式影响；开放平台建设；
通过以上DevOps实践，实现 “自运转团队”。希望后续能够把devops更好的应用到企业系统实施当中去，在技术落地的过程中更好的提升企业系统实施效率，推进流程的改进。
