作者简介：梁定安，目前就职于腾讯社交网络运营部，负责社交平台及增值服务的运维；开放运维联盟成员；腾讯云布道者；腾讯课堂运维讲师。SNG社交网络运营部管理着近10万台Linux服务器，支撑着腾讯海量的社交业务和用户，如日活2.47亿的QQ、月活5.96亿的QQ空间（数据来源：腾讯2016Q2财报）等。***网上发胖生意。面对社交UGC业务不断增长的业务量，如何在保证业务发展的同时，有效控制运营成本的增长？这是运维团队必须解决的一个紧迫的运营成本问题。经过不断的探索和挖掘，我们有幸在过去的两年里找到了一条行之有效的设备成本管理途径——精细化产能管理的设备成本优化之路，并连续两年为公司节省了亿元。在运营成本中。众所周知，提高设备的利用率是运维行业普遍采用的控制运营成本的有效方式，那么如何针对不同的设备使用场景、不同的设备类型制定合适的衡量和管理方法呢？参见腾讯运维在实践中总结的六种方法：方法一：性能管理法在衡量服务器使用的合理性时，CPU使用率是首要关注的对象。随着多核超线程技术CPU的普及，CPU负载不均的问题逐渐成为海量运维场景下设备运行成本的吞噬者。为了发现和优化多核CPU负载不均的现象，我们提出一个CPU极差衡量指标，CPU（极差）=CPU（最大）-CPU（最小），若CPU（极差）>30%，则该设备存在CPU占用不合理的问题，需要优化整改。（备注：优化方式可参考多队列网卡优化和CPU亲和性，本文不再展开）。同样，在分布式集群的模块容量管理中，运维规范要求实现模块一致性管理，包括容量一致性。为此，我们还提出了一个模组容量极差的衡量指标，模组CPU占用率极差=CPU最高IP的CPU占用率-CPU最低的设备CPU占用率。如果同一模组下不同设备的CPU占用率差异极大>30%，则说明模组容量使用不合理，需要优化整改。（备注：一般这种情况源于配置、权重、调度等管理不一致的问题，不问不展开。）方法二：密度管理方式内存使用的合理性难直接用内存使用率来衡量，在内存类设备的使用中，我们提出了一种密度管理的控制方法——存取密度。访问密度计算公式：模块下的设备内存访问密度要一致，否则会被纳入负载不均的一致性整改范围。通过对全内存模组访问密度的统计分析，得出一个平均负载水平，结合容量管理的实际需要，提高平均水平或优化水平以下的模块，可以达到优化设备成本管理的目的。同时，密度管理方式也适用于SSD盘的使用场景。（备注：访问密度会受到业务请求包大小的影响，但在海量运维场景下，个别情况可以忽略。）方式三：特征管理方式特征管理方式类似于函数式的QPS管理modules，用来衡量业务逻辑在特定业务场景下的处理性能是否最优，需要结合不同产品下相似应用场景的QPS得出分析结论。这种管理方式因业务逻辑而异。本文主要通过实例进行说明。比如在移动互联网的业务运维场景中，有些场景可以通过非常规的容量管理方式进行衡量。对于一些个别但规模较大的模块，我们提出了一种特征管理方法。比如QQ、Q空间、信鸽等服务都有长期连接功能模块。在这种场景下，CPU的容量很小，使用的内存很大。因此，可以用每G内存维护的长连接数来横向比较QQ、Q空间和信鸽。等业务，督促整改优化绩效不佳的业务项目。再比如，在直播场景中，有主播视频实时在线转码的需求。不同的开发可能会采用不同的转码技术方案。同样的特征管理方法也可以用来衡量在线转码的性能是否优化。空间。方式四：碎片化经营方式腾讯社交业务由来已久，从“老大哥”QQ到“菜鸟”企鹅FM，业务类型涵盖IM、UGC、多媒体、阅读、动漫、游戏、直播等主流娱乐社交玩法，其中有热门产品和长尾产品；每秒有数十亿个功能模块，每秒有几十个功能模块。分片管理方式是为请求量小的小集群准备的。由于分布式高可用的运维需求，通常生产环境的最小部署单位是两台设备。在物理机时代，访问量小的模块会浪费大量的成本。不过，随着虚拟化技术的广泛应用，这种场景遇到的问题已经迎刃而解。利用虚拟化技术对硬件资源进行碎片化，让小模块兼顾设备成本和高可用性。类似解决碎片资源利用的虚拟化方案，我们也有一个PaaS平台“Hive”，基于腾讯的社会标准开发框架SPP，解决小业务和小模块的容量管理问题。（后续话题聊hive。)方法五：Cask管理方法腾讯平台级业务，如QQ、QQ空间、QQ音乐等，基本普及了三地三活的SET（特殊区域）容灾架构能力，即真正意义上的异地Live更多。（正好在923上海运维大会的海量运维环节，会有一个话题分享海量运维异地容灾的实践，感兴趣的小伙伴，诚挚的invitedtoparticipate.)对于平台级业务的运维，我们根据运维规范管理的要求，将实现一定业务场景的多个模块划分为SET（减少运维对象）。在不同的社交场景中，我们得到了各种类型的SET。通过自动化运维能力扩展为SET的自动化运维能力，运维可以轻松实现SET的远程部署，从而实现多活异地的容灾容错。业务场景。再说说SET的容量管理。平台级别的SET意味着用户和请求的数量不会急剧增加。对于SET的可维护性，我们必须对SET的请求数、用户数等指标进行量化。为此，O&M给了SET一个可量化的指标。在我们的场景中，在线用户和核心请求的数量取决于SET的目的。基于压力测试，可以得出单个SET最合理的容量值。值符合桶原则，也就是我们的桶管理方式。SET由多个模块组成（SET=桶，模块=木板），支持一定数量的用户。SET的容量管理就像木桶原理。水桶的水位取决于最短的木板，所以SET的最大容量取决于SET中性能最好的模块的容量。腾讯平台级业务的同时在线用户数相对稳定，这意味着要在全国范围内实现多站点多活，需要准备多少冗余容量是可以预期和规划的。换句话说，可以预先量化要部署的SET的数量。同时，结合业务的自动化部署、调度方案、灵活的策略、有损服务能力，我们可以以非常合理的成本实现异地多场直播活动。比如假设我们总共有1000万同时在线用户，并且用户数量比较稳定，我们可以规划3个支持500万在线的SET，利用业务架构的调度能力来平均容量三个SET。在灾难场景下，一个SET不可用，另外两个SET可以完全容灾。在这个方案下，在极端场景下，如果有两个SET不可用，就必须开启有损业务。通过量化的SET管理，业务运维可以根据成本管理的要求，灵活调整SET的容量水平，从而实现性价比最高的高可用架构。方法六：硬件选型法聚焦硬件瓶颈，升级硬件，降低单机运行成本。比如以前在做UGC内存存储（QQ相册、视频）时，大量使用2T硬盘。当4T、8T硬盘量产并量产使用时，适时升级硬盘容量，可有效提升单机存储容量，实现成本效益与规模经济。小代价换来大成本。再比如，在图片社交或者视频社交等业务场景中，由于玩法需求的多样性，会扩展很多计算量大的逻辑，比如人脸识别、色情等功能。此时使用GPU设备代替CPU设备。也是让性能飞起来的有效方式。（这种方式特别适用于微云、网盘、图片存储、视频存储等UGC存储容量只增不减的业务）后记：包括但不限于以上六种容量管理方式，从而使我们能够在用户数据只增不减的社交UGC业务中，能够稳健、可持续的向前发展。设备成本管理还涉及很多细节技术手段和业务代码优化。本文只是从运维的角度来阐述对容量管理的思考。希望能对同行有所帮助。带宽成本管理优化带来的成本节约价值会更大，因为涉及的技术点和方法论较多，本文不做深入探讨。
