DevOps企业实践与架构

DevOps企业实践与架构什么是DevOps及其误区DevOps概念从2009年提出已有8个年头。可是在8年前的那个时候，为什么DevOps没 有迅速走红呢？即便是在2006年Amazon发布了 ECS，微软在2008年和2010年提出和发布了 Azure，DevOps的重要性似乎都没有那么强烈。我分析其原因主要有：第一个很重要的原因是因为那时候云计算还是小众产品，更多的与虚拟化、虚拟机相 关，它们还是重量级的IT基础设施。第二个很重要的原因是容器相关技术（Docker为代表）还没有横空出世，直到2013年7 月。第三个很重要的原因是，Martin Fowler在2014年3月提出了 Micro Service，这为 DevOps的推广也打了兴奋剂。可以看出，当前DevOps概念的深入人心，离不开云计算、容器/Docker、微服务、敏捷 等相关概念和实施的成熟发展。另外，随着互联网对传统企业的冲击，需要更快的业务试错与业务创新，其背后本质是 企业IT的精益运营，让软件的生产、交付、获取、升级、遥测变得自动与自助，近两年， DevOps在传统企业也开始备受关注与各种尝试。悠I通集成DevOps职责开发运缉协作自动化、基础设施即代码制成成倒试拮绩交忖角暗对DevOps的理解，可能千人千面。先来看下对DevOps的狭义理解。DevQg是一组过程、方法与澈 的觥，（应用朝 欧件工程）、技术运营和赎量保 （QA）部口之间的淘通、协作 与整合它的出现是由于软件行业 日益清晰地认识到：为了按的交付 软件产品和服努，开发和运蓉工作 必筷紧密合作.维基百科对DevOps的定义比较拗口。其实往简化里讲DevOps是提倡开发和IT运维之间 的高度协同，从而在完成高频率部署的同时，提高生产环境的可靠性、稳定性、弹性和安全 性。从另外一个维度，广义上来说，DevOps不仅需要打通开发运维之间的部门墙，我们认为 DevOps更多的需要从应用的全生命周期考虑，实现全生命周期的工具全链路打通与自动化、 跨团队的线上协作能力。XXX一XJi8隅瓣毗日曜配置 漏(Prod)(Stage)(T崩 t)(Test)第一，纵向集成，打通应用全生命周期（需求、设计、开发、编译、构建、测试、打 包、发布、配置、监控等）的工具集成。纵向集成中DevOps强调的重点是跨工具链的自动 化，最终实现全部人员的自助化。举个例子，项目组的开发人员可以通过DevOps的平 台上，自主申请开通需要的各种服务，比如开通开发环境、代码库等。第二，横向集成，打通架构、开发、管理、运维等部门墙。横向集成中DevOps强调的重 点是跨团队的线上协作，也即是通过IT系统，实现信息的精确传递。举个例子，传统的系统上线部署方式，可能是一个冗长的说明文档，上百页都有可能， 但在DevOps的平台下，就应该是通过标准运行环境的选择、环境配置的设置、部署流程的编 排，实现数字化的部署手册，并且这样的手册，不仅操作人员可以理解，机器也能够执 行，过程可以被追踪和审计。DevOps是通过工具链与持续集成、交付、反馈与优化进行端到端整合，完成无缝的跨团 队、跨系统协作。在团队使用DevOps时，存在误区是必然的。在我们同大量的客户交流中，大致有这几种 误区认知：Myth云上产品微服务架构it用一组工具、技术在奂瓣口 Ops之间增加一个新部门不就是自动化D取与O ps团队必须本地化Rea云上、云微服务架构、传缢msm交付、伽打破部门墙,而不自动化是：D改。| 瞄、持续、协作、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企业实践实施DevOps的核心目标是加速团队、企业的IT精益运行，从根本上提升IT的生产效 率，加速部门、企业的业务创新能力。让团队从IT支撑部门，转向为IT创新部门。实施DevOps过程中，需要从组织、技术、流程三个维度进行持续的优化与改进。实施DevOps，可以参考总结的“DevOps实践模型”，从组织、技术、流程三个维度中选 择关键的活动项进行最佳实践活动。加速企业【T精益运营曲动化一切（所有资源变粗通过富动化融跋布） 惭VP交村Everything h wde （配置.脚本.数据,测试代码.星础设施均田全橘团队前i轮捱m治町叭充分授权的自组织的团阻全栈团队而不是全拔工程师特竺团队球跆嗟曜回湾博粘做工务叩骅音工程冲一 T*4t13 1-地雄-l at试萸距我布-荷签n瓯持菊漏社r构装盲幼化-取试肓蜘r茴布自鲂R-nd可用而强1I-插壁金忖 I余坟族没布一既携律.澜瓦 发有Joint Mestanigs 嗷席会面I酒过空动开发J汗幕 EHIft 麝5U?I可以梳理出目前团队中欠缺但又容易改进的点，逐步将更多的实践活动纳入团队当中。团队实施DevOps的目的在于，将重复、价值低的事情交由DevOps平台实现，让团队成员做 更有创新、更有价值的事情。根据我们的实施经验，在传统企业中，技术方面的实践最容易在团队中实现、流程次 之、组织的优化与变革最为艰难；大家尝试的时候，可以由易入难。组织方面全栈团队：按照RDT（需求、开发、测试）模式组建交付小团队（团队中以虚拟的方式 将交互设计、运维、DBA包含进来），团队大小按照两个披萨原则进行组建。全栈团队负 责整个项目从需求、开发到上线运维的全生命周期管理，打破部门的篱笆；特性团队：基于特性的交付意味着工程团队将构建最终产品的特性；让团队关注价值交 付，减少团队依赖，打破职能团队；技术方面集成工具链：打通应用应用开发工具链：需求、项目、代码、构建、测试、打包、发 布、配置、监控；基础设施即编码：将基础环境服务化、可编程化，基础设施让项目团队可以自助获取； 让基础设施从物理机、虚拟机、走向容器；一键编译、测试、部署：开发人员可以从代码开始，一键获得可访问的环境，根据需要 可以推送开发、测试、预发、生产环境；ChatOps：开发以及运营人员在内的团队成员将沟通、工具和过程整合在一起的协作模 型。基于对话驱动开发，将工具植入对话中，保障团队能够自动执行任务与协作。最近比较 流行的hubot可以认为是ChatOps的探路者。流程方面看板：在DevOps中不能仅仅把看板当做任务协调沟通的机制；把看板作为在制品管制平 台，量化组织生产能力的工具；MVP：采用MVP （最小可行产品）原则，快速拥抱变化。最短时间内快速交付产品原型， 然后通过测试并收集用户的反馈，快速迭代，不断修正产品，最终适应市场的需求。发布：建立持续发布机制，形成自动化、自助化两种能力，支持常见的灰度发布、金丝 雀、蓝绿、回滚、A/B测试等；软件度量：通过软件度量（包括过程度量、质量度量、用户度量、成本度量），推算出 组织的各种有效指标；一则掌控组织的生产力水平，二则通过度量数据，反向优化组织瓶颈 点.八、；一切皆代码：文档（用户故事、用户场景、功能特性等）、配置（应用配置、环境配 置、脚本等）、环境（基础设施、中间件环境等）、发布包（二方库、三方库、部署包）需 要统一看待成代码，纳入版本管理，同时建立5者间的关系，提供全视角的链路追踪。举个 例子，每个发布的版本，可以追溯其对应的配置，代码、文档，发布的功能点。组织、技术、流程三个维度中，技术、流程可以通过平台或者工具进行最佳实践的固 化。基于此，我们规划了 DevOps平台，支持广义的DevOps，帮助客户快速实现DevOps建 设。的概念嗅期，实现代码.虢置、运行环境的分皖!角|础|开澄|却试|运一;Hi I平台建设第一步，梳理出DevOps的整体概念模型。从角色、规划设计、开发交付、运营 反馈四个维度进行梳理。以产品为核心，将代码、配置、环境进行严格分离，同时覆盖产品全生命周期。这里面概念看似简单，其实很多：比如：部署包=介质包+配置，这和传统的CI和CD体 系就有点不一样；再比如：环境分开发、测试、预发、生产，我们觉得即使公有云上，也应该给客户将这 些做物理或逻辑隔离，因为大家的配额需求不一样，容器replication需求也可能不一样；再比如：运营反馈，既然要做DevOps，那整个过程导出都应该可以有检查点插入，为运 营提供有效数据，我们把检查点至少分成了四类，包括过程的、安全的、性能的、业务的。DevOps架构支撑日网 MJI9*HFC5E1 傅1批W9泗I CMJ SMlo# ! N4HMM ! I TER J I FWW ： C1MM i+B i i m 11 Ha ii iu 11 eu i VW .t LI LJ I J Is I面台角色童或第基于领域模型梳理DevOps平台业务架构，目前共建设18个领域系统来支撑，比如：软 件产品的管理、软件各阶段环境的管理、质量的管理、部署包、二进制包的管理、资源管 理、监控中心、认证中心等。每个领域系统严格按照AKF扩展立方体的Y轴进行拆分，采用微服务架构模式进行平台 建设。“DevOps业务架构”，是我们基于对企业IT管理的理解，所进行的平台化设想。从图 里还可以看到，红色字部分，是我们对现有DevOps的落地实现。1. Portal（DevOps门户），自研，提供给用户使用的统一操作门户，包括用户管理、产 品看板、产品全生命周期（设计、开发、测试、预发、生产、监控、故障处理）管理等；2.IAM（身份识别与访问管理），自研，提供用户身份识别和访问控制的能力，包括用户 管理、Token管理和用户授权等功能；3.SPM （软件产品管理），自研，提供产品、组件的基准定义和管理能力，包括产品类 型、产品管理、组件管理、依赖产品管理及产品投放市场等功能；4.SCM （软件配置管理），自研，提供产品、组件配置管理能力，包括配置项的定义和在 各个不同环境下的配置信息的管理维护能力；5.SRM （软件资源管理），自研，提供产品和组件自动编译、打包和部署的能力，提供部 署模板管理，支持编译和部署流程编排，编译和部署进度跟踪以及日志查看；SEM （软件环境管理），自研，提供租户和产品环境资源配额、负载均衡，以及运行容器 的管理能力，包括租户可用资源的配额，以及基于租户资源的产品和组件在各种环境下的资源配额（如开发环境、测试环境、生产环境等等）和负载均衡；同时，还提供运行容器的创 建、销毁、调度、复制以及持久化卷管理等能力；6. QAF （质量保证反馈），自研，提供产品的质量管理和监控能力，包括测试用例管理、 缺陷管理、质量监控等；7. UMC （统一运维中心），开源集成、借鉴自研相结合，提供统一的监控、预警、故障处 理等能力，包括系统日志和业务日志的监控，产品的资源使用情况和运行情况监控，故障定 位等。8. VCS （版本控制系统），开源集成，主要以GitLab为核心，不直接提供GitLab的原 生界面，所有功能在统一的DevOps 上提供；提供源代码库管理的能力，包括代码库的创建、 维护，分支的管理和用户权限控制等；9. CI （持续集成），主要以Jenkins为核心，使之成为以API为主要使用方式的服务， 提供持续集成任务调度和执行的能力，包括集成任务管理、编译、打包等；10. BPR （二进制介质仓库），开源集成，主要以nexus为核心；提供二进制包仓库的管 理能力，包括二进制包、文档等编译产物的上传、下载和存储访问等；11. DPR （可部署介质仓库），自研，主要存储可部署的介质，其主要区别是注入了与环 境相关的配置（这种部署模型是很适合没有上Docker或者容器，以虚机为主的IT基础设施 或者物理机）；12. PM （项目管理），自研，可以与常见的PM管理工具对接与集成，提供产品的开发过 程的管理和协作的能力，主要包括：任务计划、人员分工和过程跟踪、看板等；13. MOC （API模拟），开源集成，为REST API调用提供模拟能力，以便产品或组件在开 发调试期间可以脱离依赖、减少阻塞、单独运行，支持根据Swagger和Mock数据发布Mock Rest Service，支持用户私有的MOCK数据；14. DOC （API文档），开源集成，提供REST API/SPI文档的自动生成能力；15. TM （租户管理），自研，提供租户管理的能力，包括租户管理、邀请码管理和租户配 额等功能；16.IM （即时沟通），开源集成，提供产品设计、开发、测试、运维等相关人员间的协作 沟通能力，支持群组聊天、离线消息推送、聊天记录查询和导出；啰啰嗦嗦，罗列了 18个核心的领域系统。应ma坝范Kfl、施一一.用rDevOps艘发布Hi1“ 实日恚蝙排n台.MBH i 1济曲酒卵如巷说度睛计算阈|1逻辑架构整个DevOps平台分为三层：1. 基础设施层：包括IaaS, CaaS,我们分别是基于OpenStack和Kubernetes、Docker 的，上层有一层不同环境的适配；2. 基础服务层：包括服务管理与调度的基础能力，如注册中心，编排，伸缩漂移；还有 一堆具体的企业级或互联网式的云服务；3. DevOps层：更多的是工作流程（需求、设计、开发、测试、发布等）的串接，看板等 文化的体现；在整个平台研发过程中，采用了是自己开发自己的模式，即使用上一个发布的平台作为 生产线，支撑下一个版本的产品研发工作。自己交付自己可以带来两点好处：1. 平台交付客户前，自己先把可能的坑趟掉；2. 当前生产线所有不能满足的功能，视作下一版本的需求（实际操作过程中，我们仅允 许使用wiki作为辅助工具来支撑生产线未满足的需求）；所以可以拿一些数字估算一下当前的规模。在研发过程中，把DevOps视为一套业务平 台，目前规划的领域有18个，如果每个领域中再有多个以微服务架构落地的系统进行支撑， 预计总共支撑DevOps的系统，就会超过50个。同时提供Mock、开发、测试、预发、生产5 类环境（每类环境中可能还会有多套，比如集成测试、性能测试、全链路测试）。当前版本的DevOps，整体的部署规模将超过200个集群，部署的进程实例总数也会轻松 超过500个。需要注意的是，500这个数字，还没包含技术平台中的一些分布式中间件，比如 缓存、消息队列等等集群。