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