本文整理自聊聊架构微信群直播内容

DevOps企业实践和价值（Talk：刘相  普元 - 技术经理）

演讲介绍：

如何实施DevOps成为众多企业迫切面临的问题。分享人结合自身企业实施DevOps的经验，梳理出DevOps在企业的组织、技术、流程等方面的最佳实践与价值，以及如何搭建DevOps平台来支撑DevOps的落地工作。

1、什么是DevOps及误区

2、DevOps企业实践

3、DevOps架构支撑

4、实施DevOps价值

个人资历浅薄，算是抛砖引玉，大家来一起讨论，共同推进DevOps在国内的发展。

DevOps概念从2009年提出已有8个年头。可是在8年前的那个时候，为什么DevOps没有迅速走红呢？即便是在2006年Amazon发布了ECS, 微软在2008年和2010年提出和发布了Azure，DevOps的重要性似乎都没有没那么强烈。

第一个很重要的原因是因为那时候云计算还是小众产品，更多的与虚拟化、虚拟机相关，它们还是重量级的IT基础设施。

第二个很重要的原因是容器相关技术（Docker为代表）还没有横空出世，直到2013年7月。

第三个很重要的原因是，Martin Fowler在2014年3月提出了微服务，这为DevOps的推广也打了兴奋剂。

可以看出，当前DevOps概念的深入人心，离不开云计算、容器/Docker、微服务、敏捷等相关概念和实施的成熟发展。

另外，随着互联网对传统企业的冲击，需要更快的业务试错与业务创新，其背后本质是企业IT的精益运营，让软件的生产、交付、获取、升级、遥测变得自动与自助，近两年，DevOps在传统企业也开始备受关注与各种尝试。

对DevOps的理解，可能千人千面。先来看下对DevOps的狭义理解。

维基百科对DevOps的定义比较拗口。其实往简化里讲DevOps是提倡开发和IT运维之间的高度协同，从而在完成高频率部署的同事，提高生产环境的可靠性、稳定性、弹性和安全性。

从另外一个维度，广义上来说，DevOps不仅是需要打通开发运维之间的部门墙，我们认为DevOps更多的需要从应用的全生命周期考虑，实现全生命周期的工具全链路打通与自动化、跨团队的线上协作能力。

第一：纵向集成，打通应用全生命周期（需求、设计、开发、编译、构建、测试、打包、发布、配置、监控等）的工具集成。纵向集成中DevOps强调的重点是夸工具链的「自动化」，最终实现全部人员的「自助化」。

举个例子，项目组的开发人员可以通过DevOps的平台上，自主申请开通需要的各种服务，比如开通开发环境、代码库等。

第二：横向集成，打通架构、开发、管理、运维等部门墙。横向集成中DevOps强调的重点是跨团队的「线上协作」，也即是通过IT系统，实现信息的「精确传递」。

举个例子，传统的系统上线部署方式，可能是一个冗长的说明文档，上百页都有可能，但在DevOps的平台下，就应该是通过标准运行环境的选择、环境配置的设置、部署流程的编排，实现数字化的「部署手册」，并且这样的手册，不仅操作人员可以理解，机器也能够执行，过程可以被追踪和审计。

DevOps是通过工具链与持续集成、交付、反馈与优化进行端到端整合，完成无缝的跨团队、跨系统协作。

在团队使用DevOps时，存在误区是必然的。在我们同大量的客户交流中，大致有这几种误区认知：

1、         没有使用云相关产品（IaaS、PaaS），组织很难开展DevOps；

2、         微服务架构开发的应用适合DevOps，传统SOA应用不适合；实施DevOps和应用架构无关，无论是微服务架构，还是SOA类型应用，都可以开展DevOps工作；

3、         认为将一组自动化工具的运用等同于DevOps的成功，那就太小瞧DevOps了。采用自动化工具本身不是DevOps，只有将这些工具与持续集成、持续交付、持续的反馈与优化进行端到端的整合时，这些工具才成为DevOps的一部分；

4、         设立独立的DevOps团队是很多组织开启DevOps之旅的另外一个误区。事实上，如果这么做，将会导致更多的竖井。在责任没有清晰定义的情况下，成立这些团队，会创造更多的混乱，不要试图把；

5、         DevOps不仅仅是自动化。毫无疑问，自动化是DevOps非常重要的一部分，但不是唯一的部分，一定程度的部署自动化往往会与DevOps混为一谈，实施DevOps需要从敏捷、持续、协作、系统性、自动化五个维度进行建设与改进。

在DevOps实施过程中，团队经过总结积累，制定了团队的DevOps宣言；支撑团队从敏捷型组织转向DevOps（企业敏捷）。

实施DevOps的核心目标是加速团队、企业的IT精益运行，从根本上提升IT的生产效率，加速部门、企业的业务创新能力。让团队从IT支撑部门，转向为IT创新部门；

实施DevOps过程中，需要从组织、技术、流程三个维度进行持续的优化与改进。

实施DevOps，可以参考总结的“DevOps实践模型”，从组织、技术、流程三个维度中选择关键的活动项进行最佳实践活动。

可以梳理出目前团队中欠缺但又容易改进的点开始，逐步将更多的实践活动纳入团队当中。团队实施DevOps的目的在于，将重复、价值低的事情交由DevOps平台实现，让团队成员做更有创新、更有价值的事情。

根据我们的实施经验，在传统企业中，技术方面的实践最容易在团队中实现、流程次之、组织的优化与变革最为艰难；大家尝试的时候，可以由易入难。

在组织方面：

       全栈团队：按照RDT（需求、开发、测试）模式组建交付小团队（团队中以虚拟的方式将交互设计、运维、DBA包含进来），团队大小按照「两个披萨原则」进行组建。全栈团队负责整个项目从需求、开发到上线运维的全生命周期管理，打破部门的篱笆；

       特性团队：基于特性的交付意味着工程团队将构建最终产品的特性；让团队关注价值交付，减少团队依赖，打破职能团队；

在技术方面：

       集成工具链：打通应用应用开发工具链：需求、项目、代码、构建、测试、打包、发布、配置、监控；

       基础设施即编码：将基础环境服务化、可编程化，基础设施让项目团队可以自助获取；让基础设施从物理机、虚拟机、走向容器；

       一键编译、测试、部署：开发人员可以从代码开始，一键获得可访问的环境，根据需要可以推送开发、测试、预发、生产环境；

       ChatOps：开发以及运营人员在内的团队成员将沟通、工具和过程整合在一起的协作模型。基于对话驱动开发，将工具植入对话中，保障团队能够自动执行任务与协作。最近比较流行的hubot可以认为是ChatOps的探路者。

在流程方面：

       看板：在DevOps中不能仅仅把看板当做任务协调沟通的机制；把看板作为在制品管制平台，量化组织生产能力的工具；

       MVP：采用MVP（最小可行产品）原则，快速拥抱变化。最短时间内快速交付产品原型，然后通过测试并收集用户的反馈，快速迭代，不断修正产品，最终适应市场的需求。

       发布：建立持续发布机制，形成自动化、自助化两种能力，支持常见的灰度发布、金丝雀、蓝绿、回滚、A/B测试等；

       软件度量：通过软件度量（包括过程度量、质量度量、用户度量、成本度量），推算出组织的各种有效指标；一则掌控组织的生产力水平，二则通过度量数据，反向优化组织瓶颈点；

       一切皆代码：文档（用户故事、用户场景、功能特性等）、配置（应用配置、环境配置、脚本等）、环境（基础设施、中间件环境等）、发布包（二方库、三方库、部署包）需要统一看待成代码，纳入版本管理，同时建立5者间的关系，提供全视角的链路追踪。举个例子，每个发布的版本，可以追溯其对应的配置，代码、文档，发布的功能点。

组织、技术、流程三个维度中，技术、流程可以通过平台或者工具进行最佳实践的固化

基于此，我们规划了DevOps平台，支持广义的DevOps；帮助客户快速实现DevOps建设。

平台建设第一步，梳理出DevOps的整体概念模型。从角色、规划设计、开发交付、运营反馈四个维度进行梳理。

以产品为核心，将代码、配置、环境进行严格分离，同时覆盖产品全生命周期。

这里面概念看似简单，其实很多：比如：部署包=介质包+配置，这和传统的CI和CD体系就有点不一样；

再比如：环境分开发、测试、预发、生产，我们觉得即使公有云上，也应该给客户将这些做物理或逻辑隔离，因为大家的配额需求不一样，容器replication需求也可能不一样；

再比如：运营反馈，既然要做devops，那整个过程导出都应该可以有检查点插入，为运营提供有效数据，我们把检查点至少分成了四类，包括过程的、安全的、性能的、业务的。

基于领域模型梳理DevOps平台业务架构，目前共建设18个领域系统来支撑，比如：软件产品的管理，软件各阶段环境的管理，质量的管理，部署包、二进制包的管理，资源管理，监控中心，认证中心等。

每个领域系统严格按照AKF扩展立方体的Y轴进行拆分，采用微服务架构模式进行平台建设。

“DevOps业务架构”，是我们基于对企业IT管理的理解，所进行的平台化设想。从图里还可以看到，红色字部分，是我们对现有DevOps的落地实现。

Portal（DevOps门户），自研，提供给用户使用的统一操作门户，包括用户管理、产品看板、产品全生命周期（设计、开发、测试、预发、生产、监控、故障处理）管理等；

IAM（身份识别与访问管理），自研，提供用户身份识别和访问控制的能力，包括用户管理、Token管理和用户授权等功能；

SPM(软件产品管理)，自研，提供产品、组件的基准定义和管理能力，包括产品类型、产品管理、组件管理、依赖产品管理及产品投放市场等功能；

SCM（软件配置管理），自研，提供产品、组件配置管理能力，包括配置项的定义和在各个不同环境下的配置信息的管理维护能力；

SRM(软件资源管理)，自研，提供产品和组件自动编译、打包和部署的能力，提供部署模板管理，支持编译和部署流程编排，编译和部署进度跟踪以及日志查看；

SEM(软件环境管理)，自研，提供租户和产品环境资源配额、负载均衡，以及运行容器的管理能力，包括租户可用资源的配额，以及基于租户资源的产品和组件在各种环境下的资源配额（如开发环境、测试环境、生产环境等等）和负载均衡；

同时，还提供运行容器的创建、销毁、调度、复制以及持久化卷管理等能力；

QAF（质量保证反馈），自研，提供产品的质量管理和监控能力，包括测试用例管理、缺陷管理、质量监控等；

UMC(统一运维中心)，开源集成、借鉴自研相结合，提供统一的监控、预警、故障处理等能力，包括系统日志和业务日志的监控，产品的资源使用情况和运行情况监控，故障定位等。

VCS(版本控制系统)，开源集成 ，主要以gitlab为核心，不直接提供gitlab的原生界面，所有功能在统一的devops上提供；提供源代码库管理的能力，包括代码库的创建、维护，分支的管理和用户权限控制等；

CI(持续集成)，主要以Jenkins为核心，使之成为以API为主要使用方式的服务，提供持续集成任务调度和执行的能力，包括集成任务管理、编译、打包等；

BPR(二进制介质仓库) ，开源集成，主要以nexus为核心；提供二进制包仓库的管理能力，包括二进制包、文档等编译产物的上传、下载和存储访问等；

DPR(可部署介质仓库)，自研，主要存储可部署的介质，其主要区别是注入了与环境相关的配置（这种部署模型是很适合没有上docker或者容器，以虚机为主的It基础设施或者物理机）；

PM（项目管理），自研，可以与常见的PM管理工具对接与集成，提供产品的开发过程的管理和协作的能力，主要包括：任务计划、人员分工和过程跟踪、看板等；

MOC（API模拟），开源集成，为REST API调用提供模拟能力，以便产品或组件在开发调试期间可以脱离依赖、减少阻塞、单独运行，支持根据Swagger和Mock数据发布Mock Rest Service，支持用户私有的MOCK数据；

DOC（API文档），开源集成，提供REST API/SPI文档的自动生成能力；

TM（租户管理），自研，提供租户管理的能力，包括租户管理、邀请码管理和租户配额等功能；

IM（即时沟通），开源集成，提供产品设计、开发、测试、运维等相关人员间的协作沟通能力，支持群组聊天、离线消息推送、聊天记录查询和导出；

以上共18个领域。

逻辑架构整个DevOps平台分为三层：

基础设施层：包括IaaS，CaaS，我们分别是基于Openstack和Kubernetes、Docker的，上层有一层不同环境的适配；

基础服务层：包括服务管理与调度的基础能力，如注册中心，编排，伸缩漂移；还有一堆具体的企业级或互联网式的云服务；

DevOps层：更多的是工作流程（需求、设计、开发、测试、发布等）的串接，看板等文化的体现；

在整个平台研发过程中，采用了是自己开发自己的模式，即使用上一个发布的平台作为生产线，支撑下一个版本的产品研发工作。自己交付自己可以带来两点好处：

1、         平台交付客户前，自己先把可能的坑趟掉；

2、         当前生产线所有不能满足的功能，视作下一版本的需求（实际操作过程中，我们仅允许使用wiki作为辅助工具来支撑生产线未满足的需求）；

所以可以拿一些数字估算一下当前的规模。在研发过程中，把DevOps视为一套业务平台，目前规划的领域有18个，如果每个领域中再有多个以微服务架构落地的系统进行支撑，预计总共支撑DevOps的系统，就会超过50个。同时提供Mock、开发、测试、预发、生产5类环境（每类环境中可能还会有多套，比如集成测试、性能测试、全链路测试）。

当前版本的DevOps，整体的部署规模将超过200个集群，部署的进程实例总数也会轻松超过500个。需要注意的是，500这个数字，还没包含技术平台中的一些分布式中间件，比如缓存、消息队列等等集群。

不过，500映射到企业内IT人员自己用的平台，这个数字，对于不同的企业，可能是个天文数字，也可能只是九牛一毛。

在部门实施DevOps之后，我们团队有显著改变：

1、         在团队组织上，每个团队小而自治且是全栈团队，沟通、技能互补，每个团队负责独立的领域系统，目标感非常明确，团队在走向使命型组织；

2、         项目的从原先线下协作、沟通，统一到统一的DevOps平台上协作、沟通；团队成员可以随时了解项目进展全貌，利用平台可以做到各种过程数据的实时收集(举例，比如需求变更、任务延期等)；

3、         资源管理由原来专职人员，过渡到开发人员实现自助化服务，可以按需实现各类环境申请与开通，基础设施即服务提供来技术的支撑；

4、         从原来的邮件文化，到DevOps平台统一沟通，同时DevOps打通多个工具链路端，任务分发、沟通、提醒可以实时推送；

最后给大家奉上DevOps成熟度评判指标，在践行DevOps时，可以从运营效率、IT服务水平、组织效能、客户价值、经营业绩五个维度进行评判，持续优化与改进。

提问环节

Q：怎么监控系统异常，如何预防和恢复？

A：我们通过QAF，提供对系统的监控，包括健康检查，心跳检查等级制监控应用的存活，对于业务的异常通过统一的日志分析提供定位能力。业务不可用情况下通过应用的漂移或者提供服务的熔断及升降级来解决，当然需要根据具体的业务场景和等级来选择具体的实现策略。

Q：传统行业如何进行实施？

A：传统行业在实施DevOps的时候，不建议上大而全的DevOps平台，建议从CI/CD入手（部署是传统企业最头痛的问题，比如在金融业，有的一次部署上线时长可达2个月），首先找到最痛苦的瓶颈点，从点开始实施。另外企业在多年的IT建设过程中，已经有大量的存量工具支撑，实施DevOps更多的是在企业内部打通工具链，实现全栈的协作。

Q：CI中的自动化测试和发布是如何进行的，能否详细阐述

A：对于自动化测试，我们从09年开始建立自动化测试体系，平台自身的自动化测试在我们建设的时候后端服务需要实现100%的自动化测试能力，在我们内部有专门的自动化测试平台UTP来支撑。

Q：DevOps和Full Stack工程师的区别是什么？

A：DevOps里面强调的是全栈团队，而不是全栈工程师的概念。当然对于一些非常牛的互联网企业可能存在Full Stack工程师的可能，对于传统企业或者一般企业，可以使用全栈团队来支撑IT应用建设。在我们部门内部项目中，通过RDT的模式组建小规模作战团队，团队可以看做是一个垂直团队，包括需求、设计、开发、测试、DBA、运维、交互设计，当然对于DBA、交互设计不可能每个小团队都有的情况，我们内部采用虚拟团队的方式支撑。

Q：目前有很多工具如Jenkins，那么DevOps的主要工作是二次开发吗？一个资深的DevOps在能力和工作内容上跟刚入行的DevOps相比有什么区别？

A：对于Jenkins，DevOps平台是做了二次开发；无论自身还是刚入行的DevOps团队，最主要的目的，是为了快速交付。因此需要将重复的、价值不大的事情，交给平台去做，让团队去做真正有价值的事情。对于资深的DevOps，大家可能会说使用命令更能高效的做运维、分析；但DevOps最大的价值就是提供给IT部门的全部角色（项目经理、开发、测试、运维等）提供统一的协作门户，实现自助、自动化的服务，提升IT部门的整体协作效率。