《云上社交行业技术服务白皮书》——第四章 云上社交保障与服务案例——4.2 社交流量潮汐性——4.2.3 云上成本优化（2） https://developer.aliyun.com/article/1232306?groupCode=supportservice
4.2.3.3.3 执行阶段(Do)
在执行阶段的流程是：分解原子项目、确定方案、落实到人、优化原子指标。在 这里包括两个核心要素：
1、把核心指标相关的工作向下一层分解；
2、在下一层，找到具体的人来执行，这个人要具备将自己负责的指标继续分解 到更细的能力，类似于我们说的树状结构。这样层层地分解下去，每一层的叶子节点 都可以找到对应的负责人。这种“总分”结构，在一本经典教材《金字塔原理》中也 有详细的阐述。
•分解原子项目：在本阶段要建立一个完全细化的分级结构，用金字塔原理中的 "MECE不重不漏"原则，将工作内容分解到最细的可控粒度。至于按哪个维度进行拆 分， 不同的团队或者业务可能会有不同的原则， 比如有些团队直接按子团队进行拆 分，有些团队按业务进行拆分，有些团队按流程进行拆分。从较多团队通用的角度， 成本控制这件事，可以简单的将指标分解到二级指标，包括“自身使用的成本”和“被 分摊的成本”。其中，“自身使用的成本”是指，为了满足自己业务的需要，由本技术 团队申请或者使用资源产生的成本；“被分摊的成本”是指，由于根据某种计算逻 辑，间接使用了其他团队的资源，为其他技术团队承担一部分成本费用，比如常见的 资源包括公司其他团队开发的广告、投放、风控、安全等系统。如果可以分拆到具体 的系统，则每个系统又可以继续向下拆分到更细粒度的构成项目，每个节点都是一个 小的“总分”结构，按这个逻辑继续向下分解，可以分为“可落地的最细粒度的成本” 和“可落地的最细粒度的分摊成本”。
再根据开篇描述的方法，确定每个原子的评价指标，无法量化的项目都是“耍流 氓”。这样就形成了一个更完整的金字塔结构，如下图所示：
•确定方案： 根据上面的金字塔结构，每个原子指标，都需要专业的同学来评价 分析，确定如何进行优化。比如，系统主机的成本，主要集中在虚拟机+存储这样的 资源上，衡量的指标可以确定为“资源利用率”和“单订单成本”。为了解决“资源利用 率”这个原子指标，就需要考虑目前的空闲机器是否可以下线，在线的服务是否可以 优化或者合并；为了解决“单订单成本”这个指标，可以考虑分析下系统架构，跟核 心流程处理有关的服务是否可以更加高效或者抽象出来成为服务中台，这样就可以释 放一些"烟囱式"的建设资源，使得核心处理能力更加集中、高效。类似这样将所有的 解决方案整合起来，就形成了最后的解决方案。
•落实到人： 有了方案之后，一定要确定唯一的Owner(主R)，根据经验，主R 只有一个会比较好，否则会造成“责”、“权”、“利”分割不清。在这个过程中，也是 培养团队技术能力和架构能力的好机会。
•优化指标： 不同的方案，实施的周期和代价不同，各个主R深入到不同专业 后，会对目前的资源指标有分析和反馈。有可能理论上所有的指标都需要优化，也有 可能一些指标已经很好了，这时候要甄别出来哪些资源指标的实施“杠杆率”比较 高。建议应用80/20原则进行分析，即某些指标投入20%的资源和精力可以解决最 后80%的核心问题，保证投入适合的工作量带来较高的产出。对于没有解决方案的 资源或者实施难度过大的资源，建议果断放弃或者搁置。
在具体实践中，我们可以把以上的过程，再次用一个金字塔结构来表述，如下图所示：
建立了以上的结构，就可以根据各个专业的不同，对各自的指标进行优化了，如 果最细一级的指标被成功优化之后，最上层的指标一定会有下降。因为上述指标都有 其各自深层次的业务、技术，甚至是财务上的逻辑，故在此把一些需要关注的概念再 赘述一下。
很多公司每个技术团队的机器成本，在财务上叫做“网站运维成本”，从顶层可 以分为两类构成因素，就是“自己产生的成本”和“被分摊的成本”两大类。跟自己有 关的继续向下钻取，可以分为交易相关的资源成本(跟业务流程相关的)以及跟分析有 关的大数据成本(分析、算法、决策相关)。
4.2.3.3.4 检查(Check)
在这个阶段，建议关注以下结果：
•规定动作检查：规定的方案是否执行？相关的同学是否按照规定的动作进行了 相对应的行动？ 这个阶段只关注过程不关注结果，而且更多的是关注执行人、配合 方、时间点，用项目管理的思路来运营。
•结果评估：之前梳理出来的指标是否得到了优化？这个过程是在验证结果，各 项指标中得到优化和未优化的都要整理出详细的List， 有些指标如“资源利用率”是立 即可以查看结果的，有些结果是需要周期性的时间才能获得。在这个基础上可以继续 深入反向思考，按“指标定义是否有问题->方案制定是否有问题->执行人是否有问题 ->配合方是否有问题”这个流程来进行评估。
•系统问题定位：在这个过程中，可以做到小范围闭环，建议针对某个指标的优 化方案可以设计多套，方案A不行马上迭代成方案B，快速试错，找到合理的方案。
•修正标准动作：在执行的过程中，很多方案和动作，都是在一线现场发现和修 正的，不需要等待大规模复盘的时候再提出问题和总结，主R要具备这样的意识，在 执行过程中多说多问，找到关键要素，相信每个同学都有过这样的经历。经历过某个 完整项目生命周期的同学，往往也是团队内成长最快的骨干。
4.2.3.3.5 复盘总结，继续迭代(Act)
•定期复盘：复盘是一个非常重要的能力，个人以为，复盘总结的能力在某种程 度上也代表了自己的“抽象能力+思考能力+管理能力”，关于复盘的方法论书籍很 多，这里不再进行赘述。在这个阶段，个人建议关注的点在于两个“知道”：“知道自 己不知道”，通过复盘掌握了成本优化的方法、框架、方案、团队素质、结果；“不 知道自己知道”，通过一些结果，知道了自己原来一直是在正确的道路上还是在错误 的道路上前进，把带有“运气”成分的成功，升华成为一种未来的“习惯性成功”。
•形成报告：让第一次看到这个报告的人，也能通过一两次实践，学会成本优化 这件事。
•迭代认知：将之前的过程开始深化和迭代，也是再次进行PDCA的过程，反复 打磨自己的抽象能力、思考能力、管理能力， 使自己工作深度、广度的ROI继续提 升。在迭代过程中，总会有一些惊喜和收获。从个人来说，原来以为成本项目仅仅是 个管理项目，在不断通过技术手段取得成本优化的过程中，收获了对架构、技术的理 解， 并且很多时候需要用创新的手段来解决前人未曾突破的问题， 另外还收获了7项 跟架构升级、数据压缩、技术处理有关技术专利，也是技术能力提升的一个佐证。
《云上社交行业技术服务白皮书》——第四章 云上社交保障与服务案例——4.2 社交流量潮汐性——4.2.3 云上成本优化（4） https://developer.aliyun.com/article/1232304?groupCode=supportservice
