2021年10月22日，在云栖大会的《云上运维最佳实践》分论坛，映客高级技术总监黄继发表了主题为“7天从开发到上线，云上高效运维实践与探索”的演讲，为大家阐述映客团队如何在较短时间内快速完成业务的开发，同时还要保障业务上线后的稳定运行、快速扩展、访问质量和数据化运营等经验。
本文根据他的演讲整理而成，主要分为三个部分：
一、映客业务的效率问题与挑战。
二、应对思路与实践探索。
三、未来方向与规划。
图：映客高级技术总监黄继
映客业务的效率问题与挑战
说到映客，在大部分人理解或认识里，映客就是一个直播的平台。但实际上，映客是有一系列泛娱乐化的各种APP，比如有在线相亲、香港地区的电商直播、陌生人的音视频社交等。截止到目前为止，映客大约有40个业务在线运营。
在映客内部，我们非常鼓励去做新赛道探索和内部创业。所以，我们每年都还会有十多个新的业务被立项、开发和投入上线。在这个大的背景下，时间和效率对我们来说至关重要。
在时间短这个前提下，对我们主要造成的问题或者一些挑战就来自于这三个方面：
1. 业务需快速做功能迭代。尤其在APP上线初期，有大量的业务需求和功能去完善，我们需要一个比较完善的工具平台和智能化体系。
2. 验证周期短。在数据运营方面，大部分产品在上线之初就设计好了付费、盈利的模式。所以产品会在非常短的时间周期内进行验证。只要验证可行，就会马上转入流量推广和增长获客的阶段。
3. 服务质量。因为我们业务验证周期很短，在这个周期之内，很可能会遇到突发的用户新增。所以我们希望所有的用户，都有比较好的用户体验。这就要求在业务刚上线的初期，在稳定、访问速度等方面，要达到成熟业务的标准。
在刚开始的时候，我们大部分产品的必要功能就很多，比如支付、审核、用户触达等。这些功能在初期就是必备功能，涉及到很多团队，需要多方去沟通和对接；其次，内部的流程有时候也会影响工作效率；在服务质量方面和数据运营方面，初期没有什么投入，大家的精力基本都在功能上。
如果说把这些问题都拉到一个比较长的周期来看，其实不是太大的问题。但在我们的场景里，我们希望在业务上线的时候就已经解决了这些问题，或者能够尽快解决这些问题。
我们的解决思路大致分为四个维度：
1. 敏捷，努力完善我运维体系和服务治理体系，从而加快内部的迭代效率；
2. 解耦，通过解耦让业务更加的纯粹，只需要关心自己的业务逻辑；
3. 复用，这么多业务中有一些功能是相同的，把这些功能作为公共服务提供；
4. 场景化，比如说用户注册之后，会涉及到风控、审核、数据可视化和用户触达等。我们把部分能力做了整合，让它在快速获得这些能力。
我们给自己定了一些目标和口号，比如我们的目标是“711”，口号是“让业务更专注业务”。“711”意思是7个双端的研发可以在1周时间开发上线1个APP。具体实践的过程是：
◾ 首先，提前做统一的资源管理；
◾ 其次，在内部所有的业务之间统一服务架构；
◾ 第三，做标准的公共服务组件；
◾ 最后，沉淀我们自己的业务场景和闭环。
应对思路与实践探索
下图是我们应对思路与实践探索示意图，底层主要是统一资源的管理，上面两层是为服务端和客户端提供的开发框架的服务组件，横向部分是将第三方服务和我们自己内部的服务去做一些场景提炼和沉淀。
最早，我们先从统一资源管理开始做，其中公有云也提供了一些管控的能力。但为什么我们还要考虑自己来做呢？
1.多云支持。这里最早是为了解决服务质量，在发生故障时方便做热备切换。
2.去差异化。如果云扩展了，相互之间会有不同和差异。对于业务层，我们需要把这些差异做到屏蔽，让他们觉得平滑和透明。
3.自有体系。在这个基础上更容易建立自己的自有体系，包括运维自动化的体系和服务管理的体系。
4.成本管理。因为我们需要在很早阶段就做更精细的成本管控，所以我们需要看APP的维度，去看大家的费用消耗或者资源使用情况。
上图是当前所有的运维工具和平台的体系。右边最下面是CloudAPI层，我们把所有公有云提供的资源，只要能支持API接口的都做了接入。在这个基础之上，按资源的分类去做相对应的管理工具和平台，包括安全组，因为它的变更频率非常高，所以我们对安全组做了抽象和重新设计，还有一个对应的管理平台。这些资源一旦被开通和投入线上使用，都会和我们自己的服务树做关联绑定。
这棵服务树就是右边黑色的图，在这个树上按照产品、子系统、功能模块进行业务拆分。因为这个树上记录了每个业务和资源的对应关系，所以服务树和内部其他的系统进行关联和联动。
比如与监控系统联动，可以实现监控自动地添加和删除。这棵树不但是运维管理的基础视角，还是内部其他系统数据源。所以它的信息需要准确及时，不能是静态或者手动回复。那么我们如何动态维护和管理这棵树呢？我们通过和上层服务治理结合的方式实现。
先介绍一下自动化运维里三个基本的概念。
◾ 首先是Service Tag，即微服务模块。当它横向排列展开时就是如图的字符串。在这个字符串里包含了子系统的信息、服务系统的信息、模块的名字。如果把它竖向排列，就和服务树一样，它很多时候可以通过这个Tag生成服务树。
◾ 再往上是service Name，包含服务名字、子系统。这两个有相似性，本质是一个东西，只是一长一短。长的这一块更偏向资源和运维管理，短的这个更偏向服务应用。
◾ 再往上就是Appid，即业务的标识。Appid下关联了很多业务属性，比如业务的负责人，相关的业务属性等。
这三个基础的概念，底层有一个关联的逻辑关系，可以梳理业务下面的服务，服务所关联的资源。这三个是一一对应的关系。我们所有的自动化运维体系围绕这三个来展开的。
具体运行的模式，这里简单跟大家介绍一下。如果创建了一个新的业务。它首先在映客云平台上立项添加；然后生成和业务对应的属性；其次，通过一些接口或者生成工单的形式通知运维平台做基础资源的准备。
同时，研发可以开展代码开发的工作。在代码开发的同时，它需要先到KAE平台创建和生成serviceName和serviceTag的字符串。当这个业务在平台发布线上之后，业务和资源的对应关系会自动生成关联到树上。基于服务树，我们进一步做自动监控，基于KAE平台进一步做远程配置、流量录制。同时业务还会生成一些源数据给大数据做计算分析。生产数据也利用service和Appid信息去决定生产到什么样的队列，去做一些隔离和优先级划分等等，最后落地到大数据。
业务在最初创建时，会和我们的数据平台去做关联。当源数据生成之后，对应的数据就能可视化，和APP相关的数据都会和映客云做一个关联。
为了让所有业务都能遵守这样的机制，我们提供了统一的一套开发框架。这套框架提供了一些能力，包括日志、监控上报等基础功能。围绕这个框架，我们也做了周边的脚手架，以便快速生成一个项目。对于整个框架依赖的公共资源，我们抽取出来进行集中的统一管理和运维。
下一阶段做一些通用公共服务组件的提炼，包括短信、推送、加解密、埋点等服务。这些都变成公共服务，并且尽可能让它实现自助对接。我们在客户端也同样做了类似的事情，比如热修复、网络优选、通用埋点。我们都提供一个公共的能力。
包括对于一些第三方，我们也做了一些提炼。这个设计图底层就是音视频SDK所提供的能力，在高阶应用接口这一层，我们按照房间操作和使用角度去提供接口。通过这样的方式，我们去实现底层SDK接口快速切换，来做到对业务层更加透明。
在业务场景化这一块，我们内部主要在使用的是用户、金融、IM这三块。比如用户，我们对基本的注册/登录，风控、推广投放和数据可视化能力进行了整合。
这些整合过的能力，我们尽可能让它自助配置，自助的对接。我们现在设计的一个目标就是每个组件可以在30分钟内完成接入，达到可连调的条件。
经过上面几个阶段的发展之后，我们主要的变化和收益在研发人员这边。
一是他们可以跨业务的灵活迁移。比如说这个项目要去做了，它可以快速从其他产品里抽调人手。如果不做了，这些人可以快速分散到其他业务里；
二是他们更多时间是聚焦在业务逻辑上，所以可以降低一些经验要求。在业务端，我们对业务可以减少开发的工作量；很多组件可以快速对接，我们目前大部分都可以做到30分钟-1小时完成；
三是底层服务升级更加透明，而且这些服务有专人维护，更加成熟稳定，避免业务之间重复踩坑。最后是一些默认的功能整合。
我们整套体系从最初100%基于公有云来去搭建和建设，某种程度上也符合最近比较流行的云原生理念。在上图，左边是初期已经开始在用的一些服务，右边是随着现在公有云产品越来越丰富和完善，我们也陆续用了更多的一些能力。大家在准备上云，或者在云上运维里，不可避免都会遇到类似这样的问题，比如说云的定位是什么？云上产品越来越丰富，到底直接使用还是考虑自研？云需不需要去做混合云，或者做多云架构？我觉得这个需要根据业务和场景来做具体的分析和决策。
我个人认为这些问题在可控性、迁移性和低投入，这三个角度去寻找平衡。而这三个角度某种程度上点像一个不太严谨的CAP理论。只能占有两个，牺牲掉一个或者放弃掉其中一个。在映客最初的定位里，我们更多侧重在可控性和可迁移性上。
未来方向与规划
针对未来，我们要做的一些事情。
首先，持续建设多云热备架构，以及迁移能力的加强，这方面主要考虑是服务质量。随着公有云本身的稳定性和可用区域越来越多。这件事情变成一个重要，但不紧急的事情。但是对于一些大面积故障，或者区域性故障，我们仍然是不可接受的。
其次，中台化相关的能力，主要针对海外。因为我们越来越多的业务开始去探索海外市场。这一块我们的积累沉淀还很少。
最后，更多的场景化。让业务可以更简单，比如客服或者智能投放的能力。
