云计算京东金融以应用为中心的DevOps体系建设

Posted 2021-04-16 产业智能官

本文根据王超老师在〖2017 Gdevops全球敏捷运维峰会北京站〗现场演讲内容整理而成。

讲师介绍

王超，京东金融资深技术架构师、应用运维团队负责人（PE团队），也曾负责人人网PE团队。经历了京东金融运维体系从0到N的过程、数次618和双十一大促的考验。目前主要关注DevOps、运维与架构的融合、业务可用性保障、运维平台建设和团队管理。

大家好，我是京东金融负责PE团队的负责人王超，很多人可能还不太了解PE这个岗位，PE这个岗位在雅虎、阿里、Facebook等多个互联网公司都有，全称是Product Engineer（产品运维工程师），也有一些公司叫应用运维，可以简单定义为生产环境的产品的技术运营，在京东金融所有生产环境的业务运维、大数据及中间件的运维都是需要PE团队主导或主要参与。

我过往的经历是在人人网负责PE运维团队，再早的时候是在一家传统的大型央企里负责应用运维。从三个公司的职业发展路线来看，我经历了从传统行业到大型互联网公司，再到互联网金融的几次转变。不同的经历带给我不同的思考角度，这也是我希望跟大家分享的内容。

一、运维体系四象限

运维体系的关注点主要有这四项：速度、质量、成本、安全。

1速度

公司里最重要的是如何创造更大的业务价值，产品的发布要快，技术的瓶颈不能成为业务快速迭代、新产品上线推广的制约因素。

2质量

业务的快速交付，线上的质量仍然需要保证。

3安全

尤其对于金融行业来说，安全是非常重要的。支付行业有一个名词叫资损，代表资金受到损失。在交易过程中可能会存在重复发单、营销活动，比如说给用户多发了钱，而且用户提现了，这笔钱追不回来，就造成了资损。因为技术或业务上的问题可能导致的资金损失会达到上千万甚至更多，所以作为金融行业的运维人员，一定要重视安全问题。

4成本

人员成本和IT运行成本一直是互联网公司的两大项支出，对于大规模互联网公司，服务器规模几万几十万，对资源的优化，服务性能的提升，合理的评估容量水位线，以及预算制定，成本核算，这些也都是运维需要做的工作。

二、DevOps介绍

DevOps是继Agile、Scrum和XP之后衍生出来的，延展到运维领域中的新兴的运动。

1DevOps解决的问题

DevOps协调开发、QA测试和技术运维三种角色，加强了相互之间紧密的沟通协作。

从项目规划、代码开发、构建、测试，再到发布、部署、运营和监控，DevOp是一个闭合的环，保持着持续的不中断的迭代发布部署。而其中的最后几个环节，运营监控并反馈到需求方，往往是容易被忽视的环境，而DevOps强调了反馈（Feedback）的重要性，完成了部署以后一定要通知到需求的提出者，让业务方进行确认，保证结果得到验证。如果参加过DevOps Mster沙盘训练应该会对这一点深有体会，DevOps对业务最重要的作用就是保证业务战略快速推进和快速回馈。

开发与运维之间往往会存在部门墙，其中一个原因是，运维注重的是安全稳定，开发注重的上线发布的速度。思考问题的出发点不同，导致了相互之间理解的不同、沟通的不畅。

运维为了保证生产环境的稳定性，可能每周只设定一个上线窗口，在每周三晚上上线一次，可能开发会觉得等不到这么久，因为业务的需求很着急上线。这不仅仅是技术问题，也涉及到业务和组织结构管理的问题。让我们先从DevOps的思想分析一下问题。

1）DevOps认为更小、更频繁的变更意味着更少的风险

传统模式的公司IT可能一个月或一个季度才发一个版，可对于互联网公司来说这个周期就太长了。比如业务上提了一个紧急需求，要周末办一个推广活动，网站要上线新页面，但运维如果说下个月才能上线，业务上就已经没有价值了。所以技术上需要支持更快更频繁的变更。

如果把要需求切割成更小的粒度，每次变化的代码量更少的，意味着这部分的测试也更明确，代码审核起来也比较快，所以风险可以控制的更低，发现问题也可以马上回退解决。

2）让开发人员更多地控制生产环境

让开发人员更多地控制生产环境，但不是简单的把运维操作权限交给开发人员，因为操作的风险还是要控制。以京东金融为例，我们的做法是让开发人员参与生产和运维，但并不是直接登录到机器上操作，而是在运维平台上授权受限制的操作，如应用的创建，发布部署，启停等。我们也需要提供相应的监控系统、日志平台，可以让开发人员在平台上进行查看日志、检测服务状态等操作，不需要登录服务器。

3）以应用程序为中心理解基础设施

应用程序对底层环境有没有依赖，发布在物理机还是虚拟机上，根据业务的需求需要部署多大规模的服务节点，如果做多机房部署。这样类似的问题我们希望在上线前就跟研发同学做好沟通，制定好整体的技术架构和部署架构，研发同学对基础设施有更好的理解对整体架构的优化非常有帮助。

4）设计简洁明了的流程，尽可能自动化

人、流程和技术，这三者是技术管理中很重要的三个因素。人与人之间都存在差异性，思维角度不一样，而且互联网公司人员的流动性也很大，所以人其实是不太好控制的。而流程虽然重要，但是如果只是靠人的约定去执行的流程，得不到好的落地，效果一定不会好。因此我们的做法是依靠平台，把流程固化到平台里，在平台中规避有风险的操作。通过引导式的流程，完成应用立项，应用发布，扩容缩容等操作，因为每一步都有较好的提示，很少出现误操作的情况。

5）促成开发人员与运营人员的协作

DevOps的终极目标是建立流水线式的准时制（JIT）的业务流程，最大化业务产出。 业务产出最终的衡量应该以业务交付完成的指标来判断，也就是说是否准时上线了，以及上线后业务人员是否认可。

康威定律，设计系统的组织，其产生的设计和架构等价于组织间的沟通结构。反过来，如果你的系统设计或架构不支持，那就无法成功建立一个有效的组织。不同公司的组织架构不一样，往往导致服务架构也不一样。DevOps场景下如何设计合理的组织架构，也是我们需要思考的问题。

组织架构设计的时候，比较有意思的一点就是该如何去打造高效的开发和交付小团队，就像上图“双比萨团队”说的那样，如果你不能给一个团队提供两个比萨饼，那么这个团队就太大了。要想达成组织结构的高效，最底层的小团队在一块就需要多沟通、多碰撞，所以怎么设计你的更容易沟通的组织结构也很关键 。

如上图所示，上面是开发、产品、测试，下面对应的是SA、DBA、运维开发、安全、网络部门，PE的角色起到了相互衔接的作用。PE的角色也有点像特种部队，特种部队经常是三人为一组执行外勤任务，这三个人里可能还有一些分工，有的人偏战略指挥、有的人负责执行任务、有的人负责联络通信。而在这三个人后面，其实往往还有几百人在做大后方的支持。后勤人员通过特种部队的摄像头等设备，对回传信息做数据分析，指导特种部队行动路线，执行计划等。

作为参考，我觉得我们在运维工作中也需要小而灵活的团队来跟产品、开发的人进行更直接的沟通，了解需求，根据需求制定解决方案，解决遇到的问题。

所以我负责的PE团队也尽量来设定成三四个人一组跟进某些业务线，其中每个人都可以尽量多了解对应的业务，当需要运维的其他部门配合时，再把这些业务需求转换成运维的术语，传递给运维内部的其他部门 。

2DevOps的原则

DevOps官方的五大原则：

• 文化（Culture）

• 自动化（Automation）

• 精益（Lean）

• 数据度量（Measurement）

• 分享（Sharing）

重点提一下数据度量（Measurement）。

监控如果做得不到位，小的问题不容易发现，一出问题就是业务中断的大问题。大的互联网公司的监控工具一般都会对时延非常的敏感，如内部广泛使用的APM应用级性能监控工具，如果某个应用的服务接口性能从100毫秒变成120毫秒，很可能就会触发报警，报警就会驱动大家去查为什么接口性能慢了、是不是硬件问题、是不是网络问题，运维会配合开发进行细致的调查。这些细小的问题驱动了我们在技术上多去分析思考，也会促进我们开发更细粒度的监控和分析工具排查问题。

三、DevOps体系建设

1应用全生命周期管理

应用从立项到发布上线、不断的迭代变更、扩容、缩容、迁移以及生命周期结束后的下线，需要一个完整的生命周期的管理。

我们做应用的全生命周期的管理时，结合了内部的流程系统、应用信息管理系统、自动部署系统，并对外提供API接口。

应用中心类似CMDB，但CMDB偏底层基础设施一些，比如管理操作系统、物理机、网络、数据中心。但是应用生命周期更关心应用本身和周边关联的系统。

应用立项时需要做很多工作，确定所用资源的套餐，根据业务容量规划需要的节点数量、基础组件的版本、网络拓扑、网络申请、网络权限等，立项以后还会经过很多次的信息变更。如果仅依赖文档把每次变更做以记录，很容易在人员交接流转的过程中信息遗漏丢失，给后续接手的人操作带来风险。通过在系统间自动化流转的时候自动记录下应用信息，保证了应用信息和生产环境的一致。

这些信息也作为服务对外提供接口。举个例子，应用监控的配置如果脱离应用系统单独维护，每次应用扩容缩容都需要通知到监控系统进行修改，很容易造成应用扩容或者迁移后监控会有遗漏，造成潜在风险。但是监控系统以应用中心对外提供的接口数据作为基础信息，就保证了数据都是实时准确的，也避免了各个系统重新配置的工作。

2Infrastructure as Code——DevOps的基础

应用部署的工作对基础环境的依赖非常大，比如Python程序的部署，对Python版本的依赖，再底层的OpenSSL等文件库的依赖，以及对操作系统的依赖。

早期的运维很多都是通过脚本+配置文件的方式来实现批量执行的，判断需要的依赖环境，再进行依次安装，每次执行前可能还需要临时修改脚本或者配置文件的内容，比如要操作的IP列表文件。复杂的任务以及多人操作的时候这样的方式就存在了较大的风险。

Puppet、Ansible、Chef这些配置管理工具很好的解决了这个问题，这些工具指导我们更多的通过配置管理的方式，如把软件部署的依赖关系通过Ansible Playbook来定义，通过角色分组严格的控制执行的目标状态，操作可以重复执行，哪个环节出现问题也可以准确定位，结果得到了更好的保障。

而容器时期的到来，首先是更好的解决了环境的一致性的问题，通过镜像封装的方式将基础环境打包到了容器镜像中，保证了从开发、测试、到生产的环境一致性。Mesos、Kubernetes等流程编排工具更好的解决了部署的问题，只需要关注应用本身的信息以及部署的规模，平台已经解决掉了大部分的问题。

3熟悉技术架构

运维跟开发人员一样，需要多了解技术架构和业务架构。

多了解技术架构和业务架构，才能在生产遇到问题时更好的理解和处理问题，在理解研发提出的需求时更好地理解问题，甚至提出更好的解决方案。

4Platform as Code

业务架构中主要用的一些基础组件 ：

• GSLB

• 网关

• 服务化组件

• 消息中间件

• 缓存

• 配置管理平台

• 分布式调度

• APM

• 日志平台

四、未来展望

1数据化运维

运维行业也会细分，业务运维的角色会越来越像数据化的运营，从应用的整个生命周期持续的跟进和优化，关注更快的迭代、更高的访问质量、安全的威胁，关注成本的分析，这些问题也促进我们不断的深耕技术，为业务提供价值。

为了更好的质量，我们需要做好以下的数据监控：

• 基础服务监控（网络、OS、DNS等）

• 数据服务监控（DB、缓存、消息等）

• 应用性能监控

• 分布式调用跟踪和监控

• 日志监控

• 业务指标监控

2智能运维——AIOps

现在AIOps也是很热门的研究方向，分享几个主要思考点：

• 采集数据是基础，事件信息汇总、对数据需要打标签；

• 报警关联分析，找根本原因；

• 自动报警降级或升级；

• 容量水位线预估与自动扩容；

• 从人工规则向机器学习过渡。

---

多云是云计算发展的必然阶段！看完这篇就够了

一．云计算阶段性的发展及趋势

云计算历经十余年的发展，经历了最初的普及阶段后，目前仍处于高速发展期。在此期间，云计算历经以虚拟化为基础的第一阶段，以基础设施资源服务化为基础、引入软件定义网络（SDN）及软件定义存储（SDS）等相关技术的第二阶段，以基础设施即服务（IaaS）、平台即服务（PaaS）、数据即服务（DaaS）融合为代表，糅合公有云及私有云而形成混合云能力的第三阶段。目前正步入下一阶段：全面的多云阶段，即基于混合的、异构的多种公有云、私有云，形成全面云上的企业IT架构，并借助云管理平台（CMP）的能力，实现业务系统的全分布，利用云的能力做跨云的分析。

在云计算的第一阶段，更强调对资源的有效利用，通过计算虚拟化技术（软件定义计算，SDC）将物理服务器分割为互相隔离的多个虚拟机，承载企业IT应用。同时，通过虚拟化集群调度软件采用不同的资源调度策略，将企业应用部署在虚拟机上，提升资源的利用率。

而在第二阶段，管理平台和数据平台开始分离，SDN及SDS开始应用，容器等新兴技术崭露头角，而更多的时候，云的主要表现形态是基础设施即服务。云平台的发展使得企业管理员可以加强对基础设施资源的有效管理，通过多租户化的方式、审批配额等手段，快速的交付企业IT上层应用所需的IaaS环境。在此阶段，云服务的管理层面和数据层面开始解耦，软件定义数据中心（SDDC）更多的被采用，容器技术作为一种轻量级的虚拟化方案（将容器作为IaaS服务的方式消费，而非后面发展的轻量级PaaS方式）开始出现。这一阶段企业的基础设施资源被全面云化，缩短了资源的部署和供应时间，为之后的第三阶段打下了坚定的基础。

接下来的第三阶段，IaaS服务已经根深蒂固，PaaS和DaaS等作为更接近企业应用的云服务能力开始应运而生；另一维度，作为公有云和私有云的混合形态，混合云开始大行其道。基于成熟的IaaS，企业可以构建基础类的PaaS服务，如通用的数据库、中间件等服务，集成类的I-PaaS服务，与业务及数据流紧密相关的DaaS服务等，与之前相比，更能适应互联网化架构的发展，体现全分布式、轻量级、微服务等特征，IaaS、PaaS及DaaS服务全面覆盖企业的IT基础设施、平台架构。另一方面，因应公有云的爆发式增长，及大型企业自有的私有云服务能力限制，混合云开始大量运用。在这阶段的混合云需求中，并不是呈现为简单的“私有云+公有云”形态，而更多体现为“私有云+”——也即在构建完成私有云的基础上，借助公有云的能力形成混合云。借助混合云管理平台（CMP）的能力，实现公有云与私有云之间的连接、初步的跨云资源和服务编排等功能。

作为目前可见的最新阶段，多云正在快步大踏步前进。多云管理在2017年几乎一夜之间成为热点。有别于混合云，多云更强调“多”——即多个公有云或多个私有云（而非公有云加私有云）系统的统一管理。多云管理既需要能很好利用单个云的优势、某个云特有的云服务，又需要能很好的避免厂商锁定、把鸡蛋放在不同的篮子里，还能根据业务、技术及性能等需求动态调整多云部署的策略。此外，各种行业云、区域云的多云使用也将满足更多的细分市场需求。

二．多云的应用场景

根据云星数据合作伙伴RightScale每年一度的报告“RightScale 2018 State of the Cloud Report”显示，一共81%的受访企业采用多云，其中21%采用多个公有云，10%采用多个私有云（异地、多虚拟化、资源异构等），而混合云的比例高达51%：

通过构建多云，企业可以实现统一管理公有云和私有云、跨国跨区域的业务系统部署、关键数据的云灾备、应对短时的云爆发业务需求、全局的高可用性和性能需求、各云服务提供商的优势/高性价比服务选择、成本分摊及优化能力等。

1. 跨国跨地域业务部署：大型跨国企业构建全国乃至全球的IT支撑系统，自有的私有云无法覆盖所有地域、建设成本太高，需要借助多云能力，实现全局部署。例如，某大型公司在美国销售电子类产品，需要在美国连接该企业的销售系统，通过本地私有云加公有云实现；

2. 关键数据的云灾备：企业自己的私有云运营及运维管理能力与大型公有云有差距，考虑性价比将一部分系统或者数据定期备份到公有云上；

3. 全局的高可用性和性能需求：企业自己的私有云无法覆盖所有地域为客户提供高性能的服务，利用公有云的CDN、全局负载均衡等能力提供更好可用性和性能；

4. 采用优势的公有云服务：企业私有云无法满足所有IT需求，对于不同的应用场景，选择不同公有云优势服务。如对于人工智能应用采用A的服务，对于云存储采用B家的服务等等。

5. 性价比高的公有云服务：企业根据各大公有云提供的服务类型、功能性和非功能性因素，考虑折扣、公有云厂商的布局等情况，动态调度、采用高性价比的服务，需要在多云情况下实现调度。

6. 业务的爆发场景：对于某些企业，业务具有较强的波峰波谷特征，企业即需要考虑业务的支撑和快速的爆发场景，又要考虑企业的总体IT成本，考虑采用多云。一些互联网创新企业（如在线培训公司）需要短时的资源爆发（bursting），而在业务波谷期释放资源，满足业务需求同时节省成本。

三．多云管理解决方案

多云趋势明显、应用广泛，而云管理平台是多云管理的必然选择。

云管理平台的定义首先来自于国际权威的研究机构Gartner，“云管理平台（Cloud Management Platform，简称CMP）是提供对公有云，私有云和混合云统一集成管理的产品。云管理平台主要能力包含混合云、多云环境的统一管理和调度、提供系统映像、计量计费以及通过既定策略优化工作负载。更先进的产品还可以与外部企业管理系统集成，包括服务目录，支持存储和网络资源的配置，允许通过服务治理加强资源管理，并提供高级监控，提高性能和可用性。”

1. 云管理平台实现多云的统一管理

前文所述，在RightScale的调查中大量的企业客户采用了多云支撑企业IT。让企业的IT人员管理多个不同的云平台，让云服务的用户登录多个不同的云平台进行操作显然是件困难的事情。通过使用云管理平台，管理员可以设定跨云统一的管理策略、审批流程、资源配额以及镜像模板等，并统一管理和维护多云应用和基础架构模板，并通过管理门户管理整个环境。云服务消费者从自助服务门户中选择多云模板进行部署和使用。

2. 云管理平台实现跨云资源调度和编排需要

对于企业IT应用的不同需要，管理员和开发者需要根据具体需求调度和编排跨云资源，此时，云管理平台不可或缺。对于特点的应用，开发人员期望将基础架构和应用程序服务部署到多个平台，部署后配置这些服务，并通过工作流设计界面控制生命周期操作（启动，停止等）。如标准的Web、APP、DB三层架构应用部署时，借助公有云CDN的能力，把Web层部署在公有云上，把APP集群部署在私有云的容器或者虚拟机上，把DB部署在私有云物理机上。通过云管理平台跨云编排能力，将这些公有云服务、私有云的资源进行统一的编排，辅以流程引擎形成跨云服务。

3. 云管理平台实现多云治理

多云需要统一的治理能力。云管理平台提供的治理和控制功能使管理员能够定义角色和权限层次结构，与企业和公有云目录和身份验证服务（单点登录SSO等）集成，设置和执行成本和其它配额和限制，并使用标记的资源跟踪更改历史记录，以执行合规性策略。

4. 云管理平台实现多云的统一监控和运维

管理员和运维者都需要监控告警和利用率报告来优化正在进行的多云管理。在与企业级客户交流时经常会听到的抱怨就是，为了管理云数据中心、管理某个云环境都要登录多个系统分别进行：操作虚拟化、网络、存储、业务等的管理；对IT流程的管理；对监控告警系统的管理等等。云管理平台集成企业内部IT环境，是管理员和运维人员能在统一的portal完成对于云的管理和运维操作。

5. 云管理平台实现多云的统一的成本分析和优化

云系统的管理员、财务人员、云服务的消费者都需要考虑成本和服务/资源利用率报告来优化正在进行的多云管理。云管理平台提供的基于云环境、云服务和资源类型、服务消费实体构建的成本分摊模型，到期日期和性能/使用情况分析不仅有助于控制使用情况，还可以引导消费者使用最佳的云平台，优化整体成本。此外，云管理平台提供的成本优化能力，能帮助管理员分析存在的僵尸主机、资源利用率低、选择成本及性价比更好的服务，进行资源调度。而当某个公有云调整价格时，云管理平台的动态资源调度和优化能力可以灵活的在各云间调配高性价比的服务，节省企业云消费成本。

6. 云管理平台帮助开发人员实现基于API构建跨云的应用

IaaS、PaaS及DaaS服务为企业应用提供了良好的集成支撑，通过API控制应用程序和基础架构元素对云管理员和开发人员都很重要。云管理平台提供统一的API网关，抽象各云平台的API差异，提供了一系列的鉴权、API生命周期管理、API服务消费及管理能力，简化了对于各云平台的集成及企业内部IT服务管理工具和产品的使用。

综上所述，多云需求的快速增长，必然需要相应的管理能力，而云管理平台作为一个综合的双模IT管理实践，方便管理员构建和管理多云、便于开发人员构建和运行跨云的应用程序，并帮助 IT 经理交付、治理和优化多个云平台。

本文转载自《软件和集成电路》杂志

工业互联网操作系统

---

产业智能官  AI-CPS

用“人工智能赛博物理操作系统”（新一代技术+商业工业互联网操作系统“AI-CPS OS”：云计算+大数据+物联网+区块链+人工智能），在场景中构建状态感知-实时分析-自主决策-精准执行-学习提升的认知计算和机器智能；实现产业转型升级、DT驱动业务、价值创新创造的产业互联生态链。

---

---

---

---