返回上一页

【大咖分享】众安科技冯义勇：众安的云原生DevOps实践

2021/06/21作者：冯义勇

分享嘉宾介绍：

冯义勇，众安科技平台架构部专家。负责DevOps平台的产品设计和规划工作。曾供职于七牛云、中兴通讯。在Kubernetes、DevOps领域有丰富的经验，参与了《Kubernetes in Action》书籍的翻译工作。

分享文字实录：

主要是围绕三个环节展开：

1.从演进的角度来看，众安科技的平台给众安产生了什么样的价值；

2.深入到具体的场景，去看看众安是怎么分辨一些场景的问题，以及去提供解决思路；

3.针对这些解决思路形成的解决方案落实到产品实践上。

一、众安科技的平台为众安产生了什么样的价值？

众安保险是国内首家互联网保险公司，它本身承载了金融和互联网双重属性，金融求稳，我们绝不允许出现任何资金问题，不然会丧失用户对我们的信任。互联网求快，业务方经常被要求两周甚至是一周实现新版本迭代。从我们的普遍认知来说，通常情况下快和稳是没有办法同时兼得的。我们看这个问题时，发现只有你去升级应用架构和研发体系时，才能对这个问题做解决。

在2016年之前，众安没有统一的平台建设方向和计划，当时，所有的团队处于自研或者是开源不统一，自动化程度不统一、开发规范也不统一等等，很多的工作仍然依赖人肉来完成。2016年建立统一平台，我们是从资源管理和服务变更这种运维侧开始的。为什么挑这个？就是考虑运维侧相对于交付侧来说，它更加的标准。到现在，我们也已经实现了应用级的交付能力。

对于Devops平台在众安内部的产品定位来说，首先很直接的就是ToB产品的核心价值“降本增效”，对于我们来说，要做的就是研发效能的提升和IT运营成本的降低，其中IT运营成本包括人和机器的成本。还有一个是现在再去看保险行业，消费群体已经发生了很大的变化，目前，主要的核心消费群体都是在80后到90后的人群。这些人群在保险产品的触达和整个交互过程上有很大的方式转变，他们倾向于线上的体验，在这方面，产品的交付质量也是非常关键的，我们把互联网的运维思路带到了保险这样的传统金融行业。

再看平台去年线上数据与2017年的对比，研发效能上，我们已经全面推行了敏捷项目管理和持续流水线自动化交付的方式，全公司能够实现按两周作为需求迭代周期，一周作为代码交付周期，做高频的小步迭代。2020年全年完成了生产发布达到了6万多次，最高流水线执行并发为489，这个数据在金融行业来说是很大的。

在交付质量方面，我们打通了质量中台和交付流水线的两侧平台联动，将我们的质量扫描、安全扫描、自动化测试等质量能力引入到交付流程中。另外我们还建设了一套监控运维平台，实现从基础设施、中间件、应用到业务的全面监控，大幅降低了我们的生产变更失败率、服务恢复耗时，线上故障也能够分钟级自动发现。

还有一块比较重要的是成本，成本节省上，我们主要关注两个：1.IT资源的成本；2.IT运维的成本。IT资源成本这块，我们做了一系列的数据分析，这块的分析策略后面会讲。IT运维这块来说，相较于2017年，我们当时是以部门制去划分运维职能，每个部门都有1-2个运维人员。现在是公司级的运维组，只需要3个运维人员。这不仅是组织架构的变更，更多是基于云原生的能力，释放了运维的手动操作，也通过将运维的职能左移到了开发侧，最终实现了很好的效果。

第二个环节：在建设和转型过程当中遇到的具体问题。

先列举一些常见的场景和现状，这些我就不一一读取了，在看这些场景的时候，大家应该也都能意识到要解决一些问题并不是去简单地建设一套Devops工具链，或者是提升工具链某一个工程效率就能解决的。但是如果不解决，Leader只能线下使用一些管理手段来解决，这就会中断我们对于全流程线上化的管理。那我们再看之所以解决不了的原因，还是在于工具的简单集成缺乏业务流程上的指导。另外我们还需要识别出一个项目内有所有的角色，有开发、测试和项目经理等，这些角色怎么在你的平台上找到自己的位置，以及通过平台明确切割每个角色之间的工作边界和输出规范，这个是我们平台在搭建底层工具之上需要考虑的事情。

基于上述的理解，针对方法论、工具和人员层面，就会产生一些评估方式。

在工程结构上，我们希望能够对应用技术架构和实施流程去做任务级的解耦，能够按任务去组织人员和流程，这种方式就能非常好的划分大家的工作边界。

在流程协同上，我们希望IT团队有更紧密的线上协作流程，另外还有一些责任共担的机制，摒弃相互甩锅的现象。

在管理上，同样的，按照工程结构切割后的单元去量化IT侧的投入和产出。

为了达到这样的期望，落到工具和流程上，会发现敏捷开发模式、云原生技术、微服务化是很好的支撑，但要真正把这些东西落地，还是有不小的挑战。

这些挑战来源于如何统一大家的文化共识、协作流程，另外底下的工具链应该如何建设。对于流程和工具，我相信大家还比较好理解，但是对于文化，它其实是一种说不清道不明的东西。如果是按字典上的解释，它是“知识、习惯在人与人之间传递的一种方式”。落到实处来讲，它就是一种行为规范，可以说小到IT人员平时的交流是通过IM还是通过邮件，大到整个IT交付侧是采用几个月为迭代周期的瀑布模式，还是以周度为迭代周期的敏捷模式，这些都是文化上的差异。文化改变比较难，需要不断地训练和重复。

基于上述的评估方式，我们就会形成金字塔模型。对于文化侧，敏捷项目管理模式已经很好的帮我们做了抽象，要给大家灌输持续价值交付的共识。流程侧，我们要实现两个横向的打通：1.跨部门级的协作；2.项目内的多角色协作。工具侧，我们要建设整个的DevOps工具链，围绕着工具链帮助文化和流程做落地，这是我们要做的事情。

讲到文化，首先我们要定义一个抓手。昨天听隔壁腾讯讲师的分享，他有一个观点，“Devops的本质其实是度量”，我们也非常的认可。结合众安的业务组织架构和研发体系，我们抽象了一套管道式的交付模型。从业务需求提出到BA分析拆解研发需求、开发人员编码、测试人员测试，到最终的发布上线。

我们在看整个交付链路的研发效能时，首先关注的是流动效率，流动效率是以单次发布的视角来看最大交付流速，在整个过程当中，一些是可以通过工程手段实现自动化，我们叫做工程效率，另一些需要人为介入，我们称为人工效率。围绕这两点，我们去定义关键指标。然后是会被一些公司忽视的资源滚动效率，它是以公司视角来衡量最大交付流速。当我们看公司内的无论是人员还是IT资源，它们都是一个滚动利用的动态状态。我们把人和资源投入到某一个任务当中，只有这个任务结束之后，才能开启下一个任务。如果这个任务堵塞了，它堵塞的是后面一系列任务的执行，所以这块的衡量也是我们认为很重要的。

针对大家文化共识的塑造，我们的策略就是找一些专业的人士产生一些线上线下的培训，然后生成一些可反复学习的线上课程。（图）这个是敏捷培训的实体照片，你会发现，只要我们搭建了这样的学习平台，也提供了咨询服务，业务方还是非常乐意配合的。

再说到流程协同，我们需要识别在一个项目里面涉及到哪些角色，这些角色在整个项目交付过程的不同阶段承担了什么职能。还有一个重要的问题，是对历史职能的调优。调优怎么讲？举个例子，比如说传统的开发运维交互模式，开发人员编码打包之后，将构件传递给运维人员实施部署，从这开始到真正环境部署成功，往往会因为环境问题或者构建问题等原因往复多次。现在基于云原生技术之后，我们已经能够在不泄露集群敏感信息的情况下，把环境部署的工作左移到开发和测试人员去做，这样就能提升你的软件交付效率，同时能释放很大的运维部署负载。诸如此类，我们制定符合自己内部流程的几套核心流程，并在流水线交付过程中串联。

第三部分是工具建设，我相信在开源这么盛行的时代，很多公司说要建设一套开源工具体系跑通整个交付流程，不是一件特别难的事情，但是能用和好用是两个事情，你的工具不是只给开发这个工具的人用的，要考虑的是推广一个工具到整个集团公司，这就需要一套业务线认可的产品化设计以及切实可行的推广方案。在众安内部建设这样一套平台，我们跟业务方会是一个共赢的利益体，在产品上线之前，我们会跟业务方做多轮的咨询和KT，这也是得益于众安科技背靠了众安保险这个天然的大甲方，我们有这样的场景和优势去打磨产品。但是在整个服务过程中，并没有那么容易。我们还是把众安内部所有的业务方当外部客户服务，比如说以releasenotes的方式做新功能的消息触达，配合产品经理做线上线下培训，甚至是在产品前端做用户数据采集的埋点，获取用户行为数据，去验证我们的功能推广程度和使用体验。

策略讲完之后，第三部分来看一些我们具体的产品落地场景。

首先，我们在产品的建设上采用的是容器+非容器的双模方式，也有人好奇，在云原生大背景下，为什么还要做非容器？基于两点原因：

1.对于应用开发人员来说，容器化发布还是一个门槛比较高的事情，即便我们当前常规的方案，是对dockerfile和K8S 的内置对象做可视化的封装，确实能大幅降低大家的使用成本。但是，容器化的真正使用并不是简单地把虚机的壳换成docker就可以了，开发人员需要对应用架构做解耦，以微服务化的方式起容器，这样才能真正发挥价值，然而对于业务线来说放下业务侧的开发，集中搞这个是不可能的。

2.即便我们没有办法实现容器化，但还是可以将这部分业务迁到Devops平台上，实现统一的流程和权限管控，统一的构件管理，这一块的价值也是非常大的。

第二个，刚才说到希望通过一条流水线能够让所有角色在平台上找到自己的位置，并切割大家的边界。我们设计这么一套流水线，在流水线设计上有两个原则：

1.对于流水线的定义一定是足够抽象，抽象到一个系统或者一个部门常用的流水线就一条，而不是说针对不同的代码开发语言、不同的发布对象，需要维护多条流水线，这样对于流水线的使用和运维，都是非常重的负担。

2.通过流水线的节点来定义某个角色的职能，一个节点的设计原则是只涉及一个角色，有清晰的输入和输出规范，内部有清晰的执行过程定义。

接下来讲几个场景，

首先是项目管理侧跟发布侧的同生命周期管理。在众安内部，项目管理平台和发布上线平台是两套不同的平台，当时这么设计我们也是希望在产品侧做到两个工具边界的清晰，底层尽量减少依赖，仅在上层流程上，我们做一些耦合。业务方可以在项目事项上配置任何工作流状态的触发事件，触发事件源可以源于发布流水线的执行结果，触发规则还可以定义复合逻辑。另外，项目管理侧可以基于某个事项直接拉起一个发布平台上的发布单元。这样从需求分析过渡到研发侧，可以做到足够平滑。

第二个是项目管理侧和质量侧的打通，我们也有一个质量中台，集成了质量扫描、安全扫描、自动化测试等能力，刚刚说到要把质量管控引入到交付流程中，我们主要实现了四块：1.质量阈值管理。在平台上可以根据不同租户层级来配置不同质量工具的质量阈值2.在流水线上针对不同的质量工具分别封装工具节点，和其他流水线过程做统一编排；3.流水线执行过程当中会自动获取测试结果，然后与质量阈值做比对，如果测试结果不符合要求，可以自动实现流水线阶段卡点；4.服务熔断和人工放行，一个平台不可能是百分之百可用的，为了不要因为质量中台的不可用影响交付的执行，我们实现了质量节点的服务熔断和人工放行。

第三个场景是一个活动运营场景。在PPT第二部分的最开始，介绍日常研发运维场景里有一个列的就是这个。那在面对活动运营的时候，企业通常会做什么呢？活动开始的前几个月，先要提前规划活动要利用多少计算资源，提前申请新资源的采购、或者是从公共资源池申请，然后将这些资源加入到可调度的计算池子里。活动过程当中需要有人24小时盯盘，随时查看机器、服务。活动结束以后，要重新部署这些服务，将服务实例都聚合到若干个机器，再释放掉闲置的机器。这么一套流程，在我们看来，是可以通过一些自动化手段大大提升它的过程效率和可靠性的。众安这套平台底层打通了工单系统、监控运维系统、CMDB系统和IaaS接口等，在活动前，我们的业务方只要提一个活动资源的申请工单，平台就能够自动完成资源的采购，或者是基于IaaS接口直接拉起若干资源，加入到发布平台的整个可调度池子里。在活动过程中，可以基于监控运维平台产生的监控指标做弹性的过程伸缩，这个伸缩可以做到服务级和主机级。另外一个是过程中的业务实时告警，可以减少24小时人为盯盘，也可以避免人为盯盘引入的消息滞后。活动结束之后，这边会做一个自动的服务重新调度，把一些资源集合到固定几台机器上，释放冗余的主机，这是整个的自动化保障过程。

再讲一下IT资源降本的策略，首先要明确的是IT资源降本要监控哪些KPI，首先很直接的就是集群的CPU和内存水位，再分析哪些现象造成了浪费，我们通过一些数据分析和线上的服务统计，会发现有几类：1.服务实例资源配额冗余，就是一个服务实例的线上使用率只有它最大配额的20%-30%；2.服务实例的长期占用，我们内部称这些服务实例为“死当区资源”，这些服务实例长期没有人认领和处理；3.主机配额占用不均衡，比如说主机的CPU已经达到了80%比较高的使用率，但是内存还是在20-30%；4.业务方没有KPI的指标，没有指标的原因还是因为没有度量数据，也就无从衡量KPI指标。

基于这些现象，会针对性的产生一些根因分析：比如说服务实例资源配额为什么会产生冗余，很大的一个原因就是业务开发人员基于个人经验去预估服务实例的配额本身是一件非常不靠谱的事情。那我们这边给了一个策略就是能够基于当前服务实例的历史数据产生动态基线，去给他一个资源配额的推荐值，直接使用我们推荐值就能够达到一个非常高的使用率水平。

再一个是开发环境的一些服务实例为什么会被长期占用又没人释放？存在两种情况，第一种情况是服务已经发布上线了，但是开发环境资源没有被及时清理掉；还有一种情况是发布过程到开发阶段就停滞了，服务实例始终滞留在开发环境，这个发布单从此就被人遗忘了，再也没有人处理。针对这两种情况，我们产生的策略就是，一个是服务上线之后做自动的开发环境资源回收，另外一个是对开发环境的资源做轮询检查，基于一定的规则做自动释放等等。因为时间有限，我也不一一展开了。

这是我们对于度量这块的设计，针对这块我也不用太多说，因为大家都有自己的建设原则。这就是我们针对不同的项目角色，以及各级领导围绕着质量、效益、成本、进度这4大块，我们定的指标矩阵，大家也可以随便拍做参考。