导读：美团到餐研发团队对资源成本进行了一系列优化，目前总体技术资源成本每月下降近 32%，一年节省开支几千万，而且获得了多项专利，我们一起来看看，他们是怎么做到的？
本文来源 | 美团技术团队
作者 | 刘强，美团到店餐饮研发中心数据方向负责人，美团技术委员会数据技术通道委员，2017 年入职美团点评，就职于到店餐饮研发中心，负责到餐数据仓库、数据产品、数据系统的研发工作。之前曾任多家公司的数据方向负责人。
01 背景
工程师主要面对的是技术挑战，更关注技术层面的目标。研发团队的管理者则会把实现项目成果和业务需求作为核心目标。实际项目中，研发团队所需资源（比如物理机器、内存、硬盘、网络带宽等）的成本，很容易被忽略，或者在很晚才考虑。
在一般情况下，如果要满足更多的技术指标如并发量和复杂度等，或者满足峰值业务的压力，最直接有效的方法就是投入更多的资源。然而，从全局来看，如果资源成本缺乏优化，最终会出现如下图所示的“边际效用递减”现象——技术能力的提升和资源的增幅并不匹配，甚至资源的膨胀速度会超过技术能力的提升，从而使技术项目本身的 ROI 大打折扣。
从笔者十余年的工作经验来看，资源成本优化宜早不宜迟。很多管理者在业务发展的较前期阶段，可能并没有意识到资源成本膨胀所带来的压力。等到业务到了一定规模，拿到机器账单的时候，惊呼“机器怎么这么费钱”，再想立即降低成本，可能已经错过了最佳时机，因为技术本身是一个相对长期的改造过程。
所以，正在阅读此文的读者，假如你已经感觉到了成本膨胀的压力，或者正在做成本控制相关的工作，恭喜，这是幸福的烦恼，贵公司的业务体量应该已经达到一定规模，同时也说明你的管理意识已经超前于业务发展了。
本文我们将分享美团到餐研发团队在资源成本优化方面的工作，通过近一年的实践，降低了几千万的资源成本，取得了一些成就。
02 实践
在美团公司内，资源的提供方有多个团队，除了到店餐饮研发团队自用的资源外，还有多个兄弟团队提供资源支持或者联合共建，比如 SRE、大数据团队、风控团队、广告团队等等。每个月拿到成本账单之后，我们都需要抽丝剥茧，对每一项进行拆解，才能制定对应的解决策略。具体流程如下图所示。
- 确定方法论
“凡事预则立，不预则废。”在做一件事之前，要充分评估整个工作完整生命周期的要素，并进行整体工作框架的设计，一个科学的方法论是十分有必要的。成本优化遵循的是一个行业内成熟的 P（Plan）D（Do）C（Check）A（Act）方法论，在每个阶段都又有对应的二次迭代和微循环。
在 Plan 或 Standard 阶段要做的事：建立意识 -> 确定目标 -> 分析现状 -> 确定评价指标。
在 Do 执行阶段要做的事：分解原子项目 -> 确定方案 -> 落实到人 -> 优化原子指标。
在 Check 检查阶段要做的事：规定动作检查 -> 行动结果评估 -> 系统问题定位 -> 修正标准动作。
在 Act 优化处理阶段要做的事：定期复盘 -> 形成报告 -> 迭代认知 -> 升级方法论 -> 下阶段目标。
- 计划规划阶段（Plan&Standard）
在这个阶段的核心目标是：用 2 - 3 个指标来衡量自己的工作。很多工作之所以最后失败，很多时候是相关人员根本没有办法用具体可衡量的指标来衡量自己的工作，这样对于工作结果，只能有一个“定性”的认识（比如很好，很不错，不好，较差），而无法做到“定量”。
对于研发人员来讲，不能定量的结果是不够科学的，具体如何确定指标，或者确定哪些指标作为工作目标，其实也是一门学问（有机会另外发文章讨论）。这个阶段的几个建议步骤为：
建立意识。这个是团队 Leader 的首要责任，要让团队成员明白自己在资源上花了多少钱，成本控制是不是一件真正有意义和价值的事，要做到大家认知一致。虽然见到过一些团队在提倡成本控制，但是落实到具体行动时，却流于形式或者无从下手，最后只能停留在口头上，并没有产生实际的效果。
确定目标。这个过程相对宏观，也可以认为是“定性”的阶段。在这个阶段要明确的就是，在成本控制这件事上，后续动作要解决的问题是什么？比如有些团队是总体成本偏高，但有些团队总成本并不高，而是应该增加成本，有些团队是非核心服务消耗的成本偏高，这些目标都需要经过团队成员讨论后得到一致的结果。在后续阶段的迭代中，也可以进行不断地修正。就像“客户永远不知道自己的需求”一样，很多人是不清楚自己的目标的，可以使用 SMART 原则来明确目标。
分析现状。对成本这件事，罗列相关的数据，尽可能多地帮助自己做判断。自己团队在成本优化这件事上，处在哪一个阶段，哪些工作有可能被进一步优化，在此阶段要明确出来。
确定评价指标。对于不同的专业序列，甚至对于同一专业序列的不同人员，大家对于成本的评价指标都不一样。这个阶段要做到最终的收敛，把团队未来成本优化的结果，用明确的数据表示出来。比如在到餐研发团队中，我们确认了 2 个优化的核心指标：总成本、总订单成本。后续大家所有努力的目标，如果跟这两个指标没有关系或者弱相关，都可以忽略。
本阶段最大的经验是“知易行难”，虽然拍脑袋想出来一两个方向和目标很容易，但是最后用数据论证现状时，如何判断自己这个指标是“优秀”、“良好”还是“不及格”？对标的团队是谁？为什么对标的对象是 TA？都是需要从人员规模、业务阶段、业务量、行业特点等方面考虑仔细，也需要想清楚，其工作量甚至不比实际干活阶段小。
03 执行阶段（Do）
1. 建立思考流程
在执行阶段的流程是：分解原子项目 -> 确定方案 -> 落实到人 -> 优化原子指标。在这里包括两个核心要素：1）把核心指标相关的工作向下一层分解；2）在下一层，找到具体的人来执行，这个人要具备将自己负责的指标继续分解到更细的能力，类似于我们说的树状结构。这样层层地分解下去，每一层的叶子节点都可以找到对应的负责人。这种“总分”结构，在一本经典教材《金字塔原理》中也有详细的阐述。
分解原子项目。在本阶段要建立一个完全细化的分级结构，用金字塔原理中的 ”MECE 不重不漏 ” 原则，将工作内容分解到最细的可控粒度。至于按哪个维度进行拆分，不同的团队或者业务可能会有不同的原则，比如有些团队直接按子团队进行拆分，有些团队按业务进行拆分，有些团队按流程进行拆分。从较多团队通用的角度，成本控制这件事，可以简单的将指标分解到二级指标，包括“自身使用的成本”和“被分摊的成本”。其中，“自身使用的成本”是指，为了满足自己业务的需要，由本技术团队申请或者使用资源产生的成本；“被分摊的成本”是指，由于根据某种计算逻辑，间接使用了其他团队的资源，为其他技术团队承担一部分成本费用，比如常见的资源包括公司其他团队开发的广告、投放、风控、安全等系统。如果可以分拆到具体的系统，则每个系统又可以继续向下拆分到更细粒度的构成项目，每个节点都是一个小的“总分”结构，按这个逻辑继续向下分解，可以分为“可落地的最细粒度的成本”和“可落地的最细粒度的分摊成本”。
再根据开篇描述的方法，确定每个原子的评价指标，无法量化的项目都是“耍流氓”。这样就形成了一个更完整的金字塔结构，如下图所示：
确定方案。根据上面的金字塔结构，每个原子指标，都需要专业的同学来评价分析，确定如何进行优化。比如，系统主机的成本，主要集中在虚拟机 + 存储这样的资源上，衡量的指标可以确定为“资源利用率”和“单订单成本”。为了解决“资源利用率”这个原子指标，就需要考虑目前的空闲机器是否可以下线，在线的服务是否可以优化或者合并；为了解决“单订单成本”这个指标，可以考虑分析下系统架构，跟核心流程处理有关的服务是否可以更加高效或者抽象出来成为服务中台，这样就可以释放一些 ” 烟囱式 ” 的建设资源，使得核心处理能力更加集中、高效。类似这样将所有的解决方案整合起来，就形成了最后的解决方案。
落实到人。有了方案之后，一定要确定唯一的 Owner（主 R），根据经验，主 R 只有一个会比较好，否则会造成“责”、“权”、“利”分割不清。在这个过程中，也是培养团队技术能力和架构能力的好机会。
优化指标。不同的方案，实施的周期和代价不同，各个主 R 深入到不同专业后，会对目前的资源指标有分析和反馈。有可能理论上所有的指标都需要优化，也有可能一些指标已经很好了，这时候要甄别出来哪些资源指标的实施“杠杆率”比较高。建议应用 80/20 原则进行分析，即某些指标投入 20% 的资源和精力可以解决最后 80% 的核心问题，保证投入适合的工作量带来较高的产出。对于没有解决方案的资源或者实施难度过大的资源，建议果断放弃或者搁置。
2. 实践分析框架
在具体实践中，我们可以把以上的过程，再次用一个金字塔结构来表述，如下图所示：
建立了以上的结构，就可以根据各个专业的不同，对各自的指标进行优化了，如果最细一级的指标被成功优化之后，最上层的指标一定会有下降。因为上述指标都有其各自深层次的业务、技术，甚至是财务上的逻辑，故在此把一些需要关注的概念再赘述一下。
很多公司每个技术团队的机器成本，在财务上叫做“网站运维成本”（网站？听起来还像 PC 时代的概念对不对），从顶层可以分为两类构成因素，就是“自己产生的成本”（自己用的）和“被分摊的成本”（别人替你用的）两大类。跟自己有关的继续向下钻取，可以分为交易相关的资源成本（跟业务流程相关的）以及跟分析有关的大数据成本（分析、算法、决策相关）。
（1）业务主机成本
大部分业务系统的团队，使用的资源成本都包含在这个部分，比如商户研发团队、订单系统研发团队、前端研发团队、供应链研发团队、营销系统研发团队、CRM 研发团队等。这些资源典型的物理载体就是物理机、虚拟机、容器资源以及对应的机器连接的存储（数据库、缓存、KV 存储等）资源，还会包含由于交换、存储以上资源之间的数据产生的带宽、云资源、CDN 等。
这部分资源，我们从控制成本的角度，最浅的层次，建议关注服务组（OWT）所消耗主机的资源利用率，如果资源利用率较低的主机数量较多，建议及时下线。同时，从技术方案本身来说，任何一个服务承载的业务能力和消耗资源之间，会有相对的一个“比例”或者权重。某些高利用率的服务从架构上是否可以重构、解耦或者改造，也非常有利于节省资源。这块内容到餐研发团队在过去一年的工作中，对于核心、非核心的服务都进行了梳理，对于其中可以优化的服务也进行了部分重构。相比年初，极大的降低了资源的成本，业务主机成本的两个主要指标变化情况如下：
备注：后续由于新增其他业务导致成本略有上升
（2）大数据成本
大数据在互联网行业的应用目前已经较为成熟，行业主流的数据处理架构都是 YARN 2.0 或者类似框架，核心的资源消耗主要基于 Container（Vcore+Mem）的计算资源 + 基于 HDFS 的存储资源消耗这两部分。
第一部分，是存储资源的消耗，行业通用的模型是基于物理 HDFS 或自研的类似存储引擎，这部分主要是指离线 ETL 用来按分区（一般是按时间戳）进行存储的资源，由于数据仓库的核心理念之一是保存“所有”的数据，并在此基础上按照维度建模理论对数据进行预汇总、加和。但是，由于对模型建设本身的理解深度不同，故在基础数据之上的数据冗余，在很多数据研发人员看来是理所应当的，进而导致存储资源的快速膨胀，这是每个数据团队在管理过程中面临的难题。
在此，到餐研发团队主要采取了两种手段：
a. 对于数据模型的热度进行了分级，把数据分为冷、温、热数据，对于需要保留的数据才保存在生产环境的 HDD、SSD 中，对于不重要的冷数据，通过异构的方式存入其他介质中。
b. 对于数据模型本身，需要重新思考数据的价值和存储，在数据的中间层（汇聚层），对数据模型进行重构，这也是很多数据团队忽略的基本功部分。
到餐研发团队对于数据仓库进行了二次迭代，每次都基于新的业务模式，重新构建中间层以及之上的集市、宽表层，有效节省了空间。还有一种技术手段是压缩，比如流量的数据往往是存储大户，但是流量数据相对的格式比较固定，所以很多流量数据可以进行压缩或者改变其存储格式（如 map 型），根据实测可以节省 20% 以上的流量数据空间。
另外需要补充的，还有一部分 OLAP 存储资源，也会消耗大量资源，比如 Kylin、Elasticsearch、Druid、MySQL 等，这些数据库主要用来将基于 HDFS 上的文件，同步到前端可以直接访问的介质上，供系统访问。这部分资源有些也是基于 HDFS 的（如 Kylin、HBase），有些需要单独的存储介质，也需要关注其膨胀速度以及存储周期。
第二部分，是计算资源的消耗，主要满足基于复杂规则的分析或者机器学习算法中的计算，也就是实时 ETL 计算和离线 ETL 计算的场景（代表性的引擎如 Storm、Flink 的计算还有 MapReduce 的计算）。这部分计算消耗的资源类似于业务系统，可以参照业务系统的“资源利用率”确定几个指标，进行机器优化或者算法逻辑优化。
（3）分摊成本（一）：风控及反爬
在某些公司里，某个技术团队开发的内容，有可能为了服务其他团队业务，比如前文中提到的风控、反爬、广告等，会为各种业务提供基础的技术能力。这时候就涉及到一个重要的概念“分摊”。分摊有两种规则，一种是按“实际用量进行”，另外一种是按照“使用比例”进行，这两种模式之上，可能还有混合计费模式，即“按照实际发生的比例进行整体费用的分摊”。做成本控制时，就要清楚地知道这部分成本是按哪种逻辑来进行计算的。
在风控及反爬的实践中，美团的风控及反爬按照整体风控技术团队的总体成本，按比例分摊给业务团队。所以作为业务团队，如果试图降低这部分成本，也要关注两个组成项：一是自己使用的风控及反爬的原子业务数量的绝对值，对每天风控及反爬的总体请求次数是否合理需要进行判断，以保证自己的业务请求量不增加；二是自己业务使用的比例。需要跟相关技术团队一起进行分析，以防止某些场景下，自身业务使用的绝对值下降了，但是因为其他业务绝对值下降的更快，导致自己比例反而上升，进而导致成本上升。
（4）分摊成本（二）：安全数仓成本
为了保证各个业务团队之间的离线数据交换，美团集团层面建设了安全数据仓库，用来满足跨团队之间的数据交换。这部分的费用也按照实际发生的资源占比进行统计，所以同理，为了降低成本，需要关注两个组成项目：一是自己使用的数量，从架构设计上能否将相关数据模型的效率提升、降低空间是关键因素；二是自己的使用资源在整体资源的占比，这时候也需要跟相关团队一起努力降低总成本。很多公司的技术团队，也有类似的数据共享仓库或者共建仓库的概念。
（5）分摊成本（三）：广告成本
很多互联网公司都有做广告业务的技术团队，广告的形式主要有按点击收费 CPC，按时长收费 CPT 等等，这部分分摊的逻辑同上述两者，也是按最终的总费用中的占比进行分摊。但是这块有一个需要关注的点是，由于广告的业务逻辑并不在到餐自己的业务方，也就是说归到餐研发团队可以控制的部分较小，故在这个过程中需要建立有效的评价体系，来衡量广告分摊的费用，在此采用的指标是“千次曝光成本”和“千元广告收入成本”，这里仅供大家参考。
（6）其他成本
除了以上梳理的项目之外，每月还会有一些新增的成本项目加入进来，团队要保持足够的关注。在实践中会发现某项成本在个别月份突然升高，这时候就要找到是新增加了项目，还是某个指标在业务或者算法上有所调整。
04 检查（Check）
在这个阶段，建议关注以下结果：
规定动作检查。规定的方案是否执行？相关的同学是否按照规定的动作进行了相对应的行动？这个阶段只关注过程不关注结果，而且更多的是关注执行人、配合方、时间点，用项目管理的思路来运营。
结果评估。之前梳理出来的指标是否得到了优化？这个过程是在验证结果，各项指标中得到优化和未优化的都要整理出详细的 List，有些指标如“资源利用率”是立即可以查看结果的，有些结果是需要周期性的时间才能获得。在这个基础上可以继续深入反向思考，按“指标定义是否有问题 -> 方案制定是否有问题 -> 执行人是否有问题 -> 配合方是否有问题”这个流程来进行评估。
系统问题定位。在这个过程中，可以做到小范围闭环，建议针对某个指标的优化方案可以设计多套，方案 A 不行马上迭代成方案 B，快速试错，找到合理的方案。
修正标准动作。在执行的过程中，很多方案和动作，都是在一线现场发现和修正的，不需要等待大规模复盘的时候再提出问题和总结，主 R 要具备这样的意识，在执行过程中多说多问，找到关键要素，相信每个同学都有过这样的经历。经历过某个完整项目生命周期的同学，往往也是团队内成长最快的骨干。
在到餐研发团队的实践中，业务系统的指标定义上也有类似的经验可以分享。开始进行优化工作的时候，定义了非常多的的项目和指标，比如业务主机分为云存储、带宽、CDN、Tair、Redis 等等，关注到每一项对于 RD 投入的时间和精力都是巨大的损耗。后来经过反复跟相关兄弟团队确认，向上抽象了一层“服务组的资源利用率”，这时候就不需要关注太多细碎的项目，而只关注与这些服务有关机器的使用情况，因为机器会自然的消耗 CPU、内存、带宽、CDN 等，这样可以有效节省运营的时间成本，把精力集中在优化机器和优化服务架构设计层面。
05 复盘总结，继续迭代（Act）
定期复盘。复盘是一个非常重要的能力，个人以为，复盘总结的能力在某种程度上也代表了自己的“抽象能力 + 思考能力 + 管理能力”，关于复盘的方法论书籍很多，这里不再进行赘述。在这个阶段，个人建议关注的点在于两个“知道”：“知道自己不知道”，通过复盘掌握了成本优化的方法、框架、方案、团队素质、结果；“不知道自己知道”，通过一些结果，知道了自己原来一直是在正确的道路上还是在错误的道路上前进，把带有“运气”成分的成功，升华成为一种未来的“习惯性成功”。
形成报告。让第一次看到这个报告的人，也能通过一两次实践，学会成本优化这件事。
迭代认知。将之前的过程开始深化和迭代，也是再次进行 PDCA 的过程，反复打磨自己的抽象能力、思考能力、管理能力，使自己工作深度、广度的 ROI 继续提升。在迭代过程中，总会有一些惊喜和收获。从个人来说，原来以为成本项目仅仅是个管理项目，在不断通过技术手段取得成本优化的过程中，收获了对架构、技术的理解，并且很多时候需要用创新的手段来解决前人未曾突破的问题，另外还收获了 7 项跟架构升级、数据压缩、技术处理有关技术专利，也是技术能力提升的一个佐证。
06 总结
成本优化这件事，有可能被阶段性忽略，但是重要性一直存在。到餐研发团队通过将近一年时间的运营，帮助公司节省了几千万的成本。这个过程有时候枯燥，有时候让人兴奋，有时候又让人懊恼和沮丧，某些时候其实是在拷问自己一个问题，即“保证业务不停的前提下，敢砍掉多余的机器吗？”在管理越来越精细化的今天，相信更多的有识之士也有一些需求或者进行了一些实践。期待跟行业同侪一起，在保证技术能力和满足业务的前提下，更加合理使用资源，节约公司成本，不断提升研发团队的效率。
不知道大家读完本文是否有所启发？6 月 21-23 日，我们邀请到了三位美团的讲师参与 GIAC 峰会，为我们分享以下话题：
除美团讲师外，组委会还邀请到了 Google、微软、Oracle、eBay、百度、阿里、腾讯、商汤、图森、字节跳动、新浪等企业技术专家，围绕互联网架构最热门的 AI、大中台、Cloud-Native、IoT、混沌工程、Fintech、数据及商业智能、工程文化及管理、经典架构等专题分享他们的实践经验、遇到的问题及解决方案。想了解大会更多案例，不妨识别图中二维码。此外，还有机会获得大会体验票一张哦！