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