作者 | 乌拉
导读
企业降本增效的诉求越发强烈，研发效力成为近来极为火爆的话题，本文从效力剖析整体思路、实际案例、技术实现介绍了如何从效力度量逐渐演变造成基于价值的数字化决策零碎的过程，通过本文能够理解到：
1、研发效力的实质和数字化剖析思路
2、以理论剖析场景为例，理解如何通过数据构建问题分析模型，开掘效力问题并驱动改良落地
3、搭建具备数字化智能诊断决策能力的数字化平台的技术实现计划
全文 9164 字，预计浏览工夫 23 分钟。
01 前言
企业降本增效的诉求越发强烈，研发效力成为近来极为火爆的话题，效力数字化建设也成为很多公司度量效力现状，发现效力瓶颈的不二抉择。对于研发效力度量百度曾经深耕多年，从开始通过工程能力地图的模式驱动工程能力晋升，到建设研发效力度量平台，通过在线化报表数据驱动各业务团队研发外围指标的晋升。
△工程能力地图
△在线化度量报表
后期的效力剖析根本分为两步发展：
- 定性分析：次要通过指标趋势剖析等形式来理解效力变动状况，是晋升了还是降落了，进而判断团队效力好坏。
- 定量分析：通过下钻、逻辑树、相关性剖析等形式找到效力晋升或者降落的起因，并依据起因制订改良措施。
能够看到，这样的效力剖析模式是基于问题驱动的，从后果指标找到有异样的点，通过异样点驱动深入分析，找到改良点优化带来效力晋升。这样的形式在数字化后期可能疾速辨认问题，驱动改良带来成果，随着后果数据逐渐趋于稳定，就难以再继续推动研发效力的晋升，且面临着以下几个问题：
- 过于以谋求指标为指标达成容易导致数据失真和造成漠视研发效力的实质，容易走弯路；
- 问题驱动的形式往往聚焦于局部优化，比方数据指标关注测试品质，为了达成指标减少大量的测试环节，漏测率是变少了，然而测试周期大幅度晋升，并没能达成全局最优；
- 未给出影响外围指标的要害口头，无奈领导业务团队改良。
为了躲避以上问题，效力数字化工作在思路上转向针对实际的业务场景进行数据分析模型的建设，并通过指标剖析找出关键问题给出改良计划，防止陷于 ” 数字游戏 ”。在新的模式下，数字化不仅要指出问题在哪里，还须要能领导应该改哪里，改完的预期成果怎么样观测，数字化技术层面从度量平台开始向诊断、归因、决策平台转变。如前所介绍，本文不再以围绕如何构建一套研发效力指标体系的思路进行介绍（如需理解百度的研发效力指标体系，能够留言后续咱们逐步登出），而将会介绍咱们效力剖析的整体思路、实际案例、技术实现，先了解研发效力的实质和数字化思路的前提下，重在用理论案例介绍如何分析效力潜在的那些“瓶颈”，而非只是流程与工具，让大家理解咱们是如何通过效力剖析疏导并驱动团队行为上的扭转而不是仅仅数据上“难看”。
02 效力剖析思路
次要思路是从研发效力的定义登程，找到影响研发效力的关键因素，围绕关键因素孵化和设计场景，建设分析模型，通过可控的过程改良，驱动效力长期继续的晋升。
2.1 影响效力的关键因素
研发效力定义：“研发 效力”就是更高效、更高质量、更牢靠、可继续地交付更优的业务价值的能力。
研发效力：单位工夫内研发团队实现的对业务有理论价值的需要的人均产出，即：肯定工夫内，需要吞吐 * 有价值的需要占比 * 价值 / 老本
从上述定义，能够提取出影响研发效力的三个外围因素：
- 做正确的（高价值的）事：咱们的研发资源是否投入在了更有价值的需要上，外围是洞察高价值的需要以及资源投入与需要匹配状况。
- 正确的做事：通过采纳更加正当的形式晋升研发效率、品质，缩小资源、工夫节约最终晋升需要吞吐，降低成本。
- 可继续的顺畅交付：让交付过程顺畅、稳固、可继续，可能继续保障高的需要吞吐。
2.2 影响效力的要害场景
基于下面提到的影响研发效力的 3 个外围因素，咱们采纳 GQM 的办法进行剖析，提取效力剖析的指标体系以及要害场景。以下是局部场景提取示例：
2.3 从度量向诊断决策转化
有了明确的分析模型之后，咱们就能通过指标状况来理解咱们关注的问题论断，然而剖析论断最终须要转化成可能驱动业务口头能力带来理论的收益，所以除了数字化剖析能力还须要打造可能把剖析论断无效散发，改良成果无效回收的能力。如下图所示，基于数字化分析模型，构建多渠道的剖析论断利用闭环通路，帮助数字化高效诊断以及决策落地，实现从度量向主动诊断决策服务的转化。
03 剖析改良案例
上面通过理论案例来具体介绍，如何通过数据分析来理解某个问题场景，开掘其中暗藏的问题，并对开掘到的问题提出针对性的改良提案推动落地，从而促成指标达成。
PS：以下案例数据为虚构数据，仅作为剖析思路解说应用。
3.1 做正确的事 - 人效剖析
3.1.1 剖析指标
研发资源是否投入在了有价值的事件上，这是决定最终产出的外围因素。咱们心愿剖析不同的岗位角色，人力是如何调配的，评估以后的人力资源分配是否正当，驱动资源分配优化配置，从而晋升最终产出。
上面以业务测试人员为例剖析。
3.1.2 剖析思路
人效最终谋求的是最优资源配置，所以咱们要答复的问题是现有的需求量下，投入多少人员，如何调配能失去最大产出。基于该问题咱们首先得定义，业务测试人员的投入和产出别离是什么。
参考制造业的 OLE 指标体系能够看到，最终的 OLE 波及到三个层面的问题：
1、工夫利用率：在这里相当于测试需要饱和度，能够用测试需要时长 / 实践上的总工时
2、生产效率：在这里相当于测试产出效率。在这里咱们测试产出是 BUG，所以以发现 bug 的效率作为掂量指标。
3、品质合格率：在这里相当于我的项目品质，咱们能够用漏测率来示意。
OLE = 工夫利用率 * 生产效率 *（1- 漏测率）
基于以上公式，咱们能够从人员的工夫利用率、测试效率、测试品质三个方向来进行剖析。
3.1.3 指标体系
基于上述剖析，咱们采纳 GQM 办法合成出如下的业务测试人员人效剖析指标体系：
上面是指标的具体阐明：
3.1.4 剖析实例
测试人效数据受到工程能力、业务代码复杂度、等因素影响。故业务差别较大的团队间不具备可对比性。以下实例以单个业务作为剖析主体，不思考工程能力视角因素对人效数据的影响。
后果面剖析
首先咱们通过后果面数据也就是间接影响 OLE 值的三大因素指标的趋势状况来理解以后现状，如下图所示：
饱和度：长期稳固在 30% 左右，阐明均匀每天有将近 60% 的人力处于不饱和状态，具备较大晋升空间。
均匀人天 BUG：1，2 月份受到过年前后假期影响，偏低，其余月份稳固在 0.8 高低。联合饱和度也较为安稳的数据能够判断，该业务需要的 bug 密度处于较稳固状态。
漏测率：出现不稳固稳定，和人员饱和度无相关性，阐明人员负载目前没有对测试品质产生影响。
因为人员饱和度过高易导致漏测率的回升，能够长期察看以上三个指标帮忙团队达到在可承受的漏测率规范下最大的饱和度和单位产出。
过程面剖析
接下来咱们通过过程面不同视角的剖析，来开掘外围问题是什么，须要改良的计划是什么（以下仅以需要和人员视角为例）
-
需要调配视角
需要依据批改危险大小，能够应用不同的品质保障伎俩。如低危险需要能够采纳研发自测 +CI 自动化伎俩保障品质。
需要调配视角次要答复以下两个问题：
-
测试工作是否采纳了最低老本的的测试伎俩来实现品质保障工作。
通过比照最终上线后没有 bug 的需要占比，和理论需要采纳的测试计划能够看到，咱们只有大略 20% 是理论有 bug 的，然而采纳研发自测形式保障的需要仅占比 50-60%。阐明咱们有大量的测试人力耗费在无 BUG 需要上。
△无 bug 需要占比
- 须要调配到测试人员的测试任务分配是否平衡，是否有闲置人员和闲置工夫。
通过饱和度在工夫维度和人员维度上的调配散布，能够看到 在工夫维度上，存在显著的忙时和闲时，人员维度上存在显著的不平衡状况，且存在 0 饱和度成员。
△工夫维度饱和度散布
△人员维度饱和度散布（横轴代表饱和度百分比）
- 人员能力视角
人员能力视角次要答复以下问题：
-
是否存在能力有余成员
通过人员粒度的交付需求量以及漏测率的散点图数据能够看到，存在产出少且产出品质差的成员。
△人员交付 & 漏出状况
改良计划开掘
基于以上过程面剖析，能够看到在需要调配、人员能力层面都有显著的问题，针对某一个具体的问题指标咱们须要开掘具体的改良计划并驱动落地，上面咱们以需要调配维度的工夫平衡度问题为例进行详细分析拆解。
- 关联剖析
察看人员饱和度散布能够看到，忙时周期和发版周期统一，阐明发版周因为存在批量提测导致人员饱和度晋升。为了可能在发版周保障按时交付，业务须要保障有短缺的测试人员可用。
△工夫维度饱和度散布
解决工夫维度调配不平衡问题咱们须要做到在忙时可能有充沛的人力资源可用，在闲时可能开释人力资源。因为人员不可能疾速减少或缩小，所以咱们心愿看下是否能够通过在更大的团队范畴内进行资源共享来达成以上目标。剖析不同业务的需要饱和度周期散布如下：能够发现不同团队间的忙闲时段是有差别的，如下图 A 团队在周三最忙而 B 团队是在周五，阐明以上提议可行。所以针对需要调配的工夫平衡度问题提出改良计划:通过建设多团队间的测试人员池化机制，晋升整体饱和度。
△A 团队工夫维度饱和度散布
△B 团队工夫维度饱和度散布
3.2 正确的做事 – CR 过程剖析
3.2.1 剖析指标
CR（CodeReview）是代码指标保障中的重要一环，也是研发日常工作中的一个重要组成部分，咱们心愿通过对于 CR 过程和 CR 投入产出的状况进行剖析，评估以后 CR 工作的投入产出状况，驱动 CR 工作过程改良带来品质和效率的晋升。
3.2.2 剖析思路
因为评审对后续品质效率的数据相关性，一是很难立即获取到，二是获取到后是否有正相关性不可控，受其它因素影响很多，所以临时不以 CR 对于质效后果指标的影响为剖析重点，而是 假如 CR 工作以及良好的 CR 习惯，能够晋升我的项目品质效率，那么咱们能够通过引领团队晋升 CR 参与度，躲避不好的实际，落地好的实际来改良 CR 过程晋升 CR 产出。
所以在后果面上，咱们谋求的是 CR 的投入产出比，在过程面上咱们首先须要晋升 CR 的投入度，其次须要关注 CR 执行过程，辨认好的实际和不好的实际。调研业内好的 CR 工夫准则，咱们总结了几个外围因素：
- CR 评审须要疾速响应，防止因为 CR 导致流程阻塞，个别该当在一个工作日内实现
- 筛选能对你代码做出最全面最精确评估的人为评审者，保障评审品质
- 防止单次提交过多代码，尽可能小的，增量的，实现一个残缺性能的提
3.2.3 指标体系
基于上述剖析，咱们采纳 GQM 办法合成出如下的 CR 剖析指标体系：
上面是局部指标的具体阐明
3.2.4 剖析实例
通常指标数据须要有比照基准，和业界或者和本人历史状况比照才好判断优劣，然而这个案例是首次剖析不是看趋势所以没有历史数据比照，相干指标业界也没有对应的数据披露，所以这里没有采纳基线对照的形式评估。
后果面剖析
首先咱们通过后果面指标状况，来理解 CR 现状，判断是否须要改良以及哪些团队须要重点改良，如下图所示能够看到如下论断：
- 70% 的团队无效评审数较小，且这 70% 的团队内有大量团队均匀 CR 耗时超过较高，存在高投入低产出景象，须要改良。
- 以后单无效评论老本和无效 CR 率出现肯定的负相关性。
过程面剖析
接下来咱们通过四个角度的过程面剖析，来开掘外围问题是什么，须要改良的计划是什么。
△评审过程标准状况
首先从评审提交和评审过程标准状况来剖析，能够看到下面两张图所示数据：
- 提交角度：单次提交大于 400 行的占比占比 12%，这部分提交不利于评审人员疾速评审发现问题
- 评审过程：
- 秒过率在 16% 以上且有上扬趋势，阐明存在大量 ” 走过场 ” 的 CR，仅仅为了代码合入操作评审通过，并未理论评审。这种状况齐全没有产出，而且耗费的肯定的流程老本
- 自评率维持在 5% 左右，尽管占比不高，然而这类 CR 和秒过相似，都是为了代码合入而走的流程，须要优化
- 24 小时以上完成率 8% 左右，无显著问题
△人员调配是否正当
接着从人员调配角度来看是否正当：
- 参与度：从参与度上看放弃在 40% 左右，阐明有大量的研发同学是没有参加到 CR 工作，这不利于技术探讨气氛的建设和常识交换，须要晋升。
- 饱和度：饱和度长期处于 10-15% 之间，阐明 CR 工作以后对于大家来说不是一个高频工作，不会造成太大累赘。
-
职级散布：从职级散布来看，大量的 CR 是由中级工程师来实现的，高级工程师作为经验丰富可能给出更多无效倡议的个人人均评审量较低，能够联合我的项目重要度正当调配更多 CR 工作。
改良计划开掘
基于以上过程面剖析，能够看到在评审提交、执行以及人员调配视角咱们都有须要晋升和改良的指标，那针对某一个具体的指标改良如何开掘具体的改良计划并驱动落地呢？上面咱们以秒过率为例进行详细分析拆解。
下钻剖析
为了进一步发现问题，咱们能够针对指标进行下钻剖析，如下图：
△依照部门维度下钻
△依照人员维度下钻（右）
从部门维度下钻看秒过率数据，能够看到 部门 1、部门 6、部门 8 三个部门的秒过率大于 20%，是所有部门内最高的，能够将这个比照数据通过剖析报告的模式推送给对应部门负责人进行改良。部门维度能够进一步下钻到人员维度，给部门负责人提供秒过率异样高的人员信息，作为改良的抓手推动具体的优化。
关联剖析
除了从不同维度下钻找到足够细粒度的，可执行层面的优化点，还能够通过关联剖析的形式剖析指标指标受到哪些因素的影响，通过关联因素剖析来制订更正当的优化计划细则。
△与职级关联
从职级关联度数据能够看出，随着职级的晋升，秒过率越低，大量秒过产生在低级别人员互评场景，所以咱们能够从评审调配优化以及制订 CR 实际标准并向低级别人员宣贯的形式晋升执行标准度。
从秒过率和代码变更行量的关联数据分析，并未呈现代码行越多秒过率越低的状况（如果都是认真评审的话，改变越大破费工夫越长越不会秒过），阐明以后的很多秒过评审的确是无脑过单，并不是代码改变小评审速度快。
针对不同异常现象具体数据进行细化剖析起因，依据起因分类别离制订优化计划。举例如下：
代码更改量大然而秒过
- 未查看代码就间接过单：能够通过在 CR 工具链上减少情谊提醒以及快捷评审标记的形式，在升高 CR 老本的同时及时揭示大家恪守标准，升高此类走过场行为。
- 配置改变 / 渺小改变不须要细看：晋升 CR 提交自动化扫描能力，针对变更能自动识别变更类型和危险水平，对于低危险 CR 可主动通过无需人工染指，升高 CR 老本。
针对过程面剖析中提到的各个须要优化的指标，采纳上述下钻剖析、关联剖析、相关性剖析等形式，就能够 得出不同指标不合理的起因、进而找到应该由谁来执行改良，以及具体的改良内容，从而切实的驱动执行落地。
3.3 可继续的顺畅交付 – 流程瓶颈剖析
3.3.1 剖析指标
通过业务流程全局视角，察看并剖析研发测试周期各环节存在的瓶颈点和根因，驱动瓶颈优化带来整体效率的晋升。
3.3.2 剖析思路
思考到服务端和 APP 端的交付流程存在差别，分两个业务类型切分不同的流程阶段来剖析。
- 首先通过全流程阶段透视的形式，开掘流程中的显著瓶颈点。瓶颈指在整个我的项目流程中制约产出的各种因素，一旦呈现瓶颈，从阶段数据上有以下两种景象，在评估初期，能够重点关注期待耗时。
- 存在较长期待周期
-
某个阶段耗时过长
“期待”贯通于整个需要交付周期里，以明线（绿色）和暗线（灰色）为两种形式存在，如下图，可通过统计各阶段耗时散布进行瓶颈辨认：
明线：具备明确的工夫起止点，可被明确度量，通常起因往往是人力层面的问题。
暗线：暂无明确的工夫起止点，起因简单。
- 针对第一步找出的显著瓶颈点，进行归因剖析，驱动理论落地改良
3.3.3 指标体系
上面是局部指标的具体阐明：
上图局部指标是复合计算指标，如需要复杂度、自动化能力等，基于多个根底指标计算，可进一步细化开掘，此处未一一列举。因为各维度指标过多，上图次要体现剖析的 5 大维度，并未列全指标。
3.3.4 剖析实例
后果面剖析
首先通过期待耗时占比和各阶段耗时占比来理解现状，找到 top 的期待耗时环节：
- 期待耗时占比：在 20% 左右稳定，近期占比有所回落，有较大优化空间。
- 各环节期待 / 耗时占比：能够看到期待耗时集中在集成期待、测试期待、上车期待三个阶段。
过程面剖析
接下来咱们从下面列出的影响维度来剖析，对于测试期待景象进行归因逻辑树梳理如下：
篇幅所限上面以人力不足为例进行细化剖析：
- 业务测试人员产能是否足够
假如每个测试人员的产能一样，每天能实现的需要个数为 X，每个版本的测试阶段周期为 Y 天，每个版本的需求量为 Z。
以上三个值的估算逻辑如下：
人均产能：取历史上测试饱和度 90% 以上的人天数据计算人天吞吐作为人均产能。
测试周期：依照业务版本周期的 30% 工夫核算
版本需求量：因为每个版本的需求量是有稳定的，所以取历史上所有版本的 80 分位需要数为参考计算，偶然超出的局部能够通过长期借调人员来进行补充。
示例业务 X * Y > Z 阐明，测试产能有充裕。
- 业务测试调配是否平衡
从工夫和人员两个维度，来看业务版本人力应用的均衡性，如下图：
工夫维度：存在显著的提测集中挤兑景象，11 月 14 日的提测量占版本总量的 42%。
人员维度：人员负载和产出存在较大差别，负载最高的人员承当了版本 40% 的需要，最低的仅 3%，高负载人员的测试期待耗时较高。
△工夫维度提测和测试吞吐状况
△人员平衡状况
-
业务测试是否存在人员单点瓶颈状况（某些类型的需要仅固定人员能负责，导致相干工作多的时候阻塞）
通过历史数据，统计不同业务方向 / 代码模块的需要的测试人员散布，看已经测试过某个业务方向 / 代码模块的人数占业务总人数的占比，如下：
能够看到整体散布较平均，未呈现显著单点瓶颈
改良计划开掘
基于以上过程面剖析，能够看到人员层面在工夫和人员调配上存在较大平衡度问题。上面以工夫维度调配不平衡为例进行改良计划开掘。
需要提测工夫过于集中，可能有以下几方面起因：
1、版本打算就是这样制订的
2、研发估点误差较大，较多需要都沉积到 deadline 提测
3、长期插入需要较多或需要调整过多
按照以上 3 个方向进行进一步细化剖析如下：
从以上数据可看出，导致工夫维度上提测挤兑景象的次要起因是长期需要插入较多、有提测 delay，且这两类问题集中在 10、11 两日内呈现，所以针对该问题从长期需要管控以及按时提测率两方面改良。
长期需要治理流程进行优化:
1、长期需要插入须要有准入机制
2、长期需要插入后须要置换等量的暂未开始开发的低优需要移出
3、版本长期插入设定 deadline 日期，deadline 后不容许再插入
4、长期需要占比作为长期度量指标，定期披露数据，驱动改良
提测 Delay 是由多种起因导致的，针对提测 delay 景象的优化，须要进一步的细化剖析，这里就不开展了。
04 数字化系统工程实现
4.1 技术挑战
随着数字化剖析场景的拓展和逐步深刻，对于数据的丰富性、时效性以及数据分析的效率都有更高的诉求，数字化技术层面面临着以下几个方面的挑战：
- 研发全过程指标采集和治理带来的数据采集、存储和保护老本剧增，同时高速增长的数据量和灵便多变的查问诉求也给数据查问性能带来了高挑战。
- 个性化剖析场景诉求剧增，然而具备数据分析能力的团队成员无限，剖析人力和效力难以满足业务数据分析诉求。
- 数据分析论断依附各层级人员下发，零碎不具备散发到具体执行人员的能力，难以主动实现改良成果回收。
4.2 具体计划
为了解决下面提到的问题，咱们从以下三个方面进行建设：
- 建设低成本的数据采集、荡涤、存储、治理计划，提供高性能的查问。
- 建设一套可能通过配置化的形式实现用户关注指标的智能剖析，给出剖析论断、倡议的零碎，达到可规模化服务的成果。
- 面向的不同的用户，提供不同场景下的产品化能力，达到剖析论断无效触达和成果回收。
整体技术架构设计如下：
底层数仓：对立数仓、配置化的数据采集能力、数据分层设计、高性能的数据查问服务
决策引擎:
- 元数据：提供，表、字段、指标等根底元数据自动化采集，结构化存储，以及查问能力，提供指标元数据的增删改查能力。
- 算法核心：提供对单指标、多指标的罕用数据分析算法能力，如趋势剖析、散布剖析、异样辨认等。
- 模型治理：实现依据模型配置调用剖析服务获取剖析数据，并存储剖析后果，生成可视化剖析报告，提供模型后果数据查问服务。
- 触达：与外部多零碎买通，数字化剖析出的危险问题可通过触发服务生成待跟进工作揭示到对应负责人，驱动闭环。
服务场景：
- 业务负责人：提供具体的数字化剖析报告，蕴含问题剖析和改良提案。
- 一线经理：提供个性化的主动诊断报告、在线化报表以及数据问题疾速定位能力。
- 一线员工：提供异样问题告诉、闭环等能力。
4.3 主动剖析案例
4.3.1 新建分析模型
1、创立新的分析模型
2、新建剖析策略，抉择策略类型以及须要剖析的指标
3、配置要剖析的数据范畴，范畴值能够采纳动静参数的模式配置
4、配置要剖析的维度（示例是趋势剖析，所以有主维度配置）
4.3.2 剖析报告
模型创立后会主动生成一个模型对应的剖析报告页面，如下：
- 过滤条件依赖模型配置内的动静参数生成，可在页面内填入不同的值，获取不同数据范畴的剖析后果。
- 依据策略配置生成对应的指标图表以及根底数据解读。
05 总结
以上咱们从效力剖析整体思路、实际案例、技术实现介绍了咱们是如何逐步形成基于价值的数字化决策零碎，通过下面介绍能够理解到：
1、影响研发效力的三个外围因素：做正确的（高价值的）事、正确地做事、可继续顺畅交付。
2、业务测试人员人效剖析：人员需要饱和度有余，其中一个起因是需要调配不平衡，能够通过人员池化的形式晋升人效。
3、CR 过程剖析：CR 工作存在高投入低产出景象，其中一个起因因为 CR 执行中存在大量秒过景象，能够通过 CR 工具链优化进行改善。
4、瓶颈剖析：全周期中存在不少的纯期待耗时，其中测试期待占比拟高，其中的一个起因是长期需要插入多，导致短时间内集中提测呈现挤兑，能够通过长期需要管理机制优化进行改善。
5、数字化系统工程实现：搭建具备数字化智能诊断决策能力的数字化平台的技术实现思路。
效力数字化工作能够帮忙团队造成基于数字剖析的决策零碎，通过数据的诊断、归因，挖掘出问题起因并举荐改良计划来影响决策，驱动实在的价值达成。
06 瞻望
数字化剖析的外围是剖析数据的齐备性、有效性和基于研发效力实质状况下场景开掘数字化，咱们先须要有数据能力进行剖析改良，而以后研发过程中还是有大量工作是未留痕，或者因为依赖人工操作留痕导致的数据不精确问题。后续须要通过持续性的工作过程的在线化，以及流程自动化建设晋升数据自身的丰盛度和准确度，让数字化剖析在更多场景发挥作用。
——END——
举荐浏览：
百度内容了解推理服务 FaaS 实战——Punica 零碎
精准水位在流批一体数据仓库的摸索和实际
视频编辑场景下的文字模版技术计划
浅谈流动场景下的图算法在反作弊利用
Serverless：基于个性化服务画像的弹性伸缩实际
图片动画化利用中的动作合成办法