• 欢迎访问安全专题网站,安全专题信息,安全专题教程,推荐使用最新版火狐浏览器和Chrome浏览器访问本网站,欢迎加入安全专题 QQ群
  • 安全专题现已支持滚动公告栏功能,兼容其他浏览器,看到的就是咯,在后台最新消息那里用li标签添加即可。
  • 如果您觉得本站非常有看点,那么赶紧使用Ctrl+D 收藏安全专题吧

运维如何为公司节省一个亿?

安全运维 网络收集 2年前 (2016-12-24) 257次浏览 0个评论

运维如何为公司节省一个亿?

作者简介:

梁定安,现就职于腾讯社交网络运营部,负责社交平台、增值业务的运维负责人;开放运维联盟委员;腾讯云布道师;腾讯课堂运维讲师。

SNG 社交网络运营部管理着近 10 万台的 Linux 服务器,以此支撑着腾讯社交业务海量业务与用户,如日活 2.47 亿的 QQ、月活 5.96 亿的 QQ 空间(数据来源:腾讯 2016Q2 财报)等众多千万级在线的胖子业务。

运维如何为公司节省一个亿?

面对业务体量的不断增胖的社交类 UGC 业务,如何能既保证业务的发展,又能有效的控制运营成本的增长?是运维团队迫在眉睫要解决的运营成本难题。经过不断的探索和深挖,我们庆幸

在过去的 2 年中,找到了一条有效的设备成本管理的路子——精细化容量管理的设备成本优化之路,并连续 2 年,每年为公司节约过亿的运营成本。

众所周知,提升设备的使用率是运维界常用的管控运营成本的有效办法,那么如何能够针对不同的设备使用场景、不同的设备类型制定出适宜的度量与管理办法呢?请看腾讯运维在实践中总结出的 6 个方法:

运维如何为公司节省一个亿?

方法 1:性能管理法

在衡量服务器的使用合理性中,CPU 使用率当仁不让的成为头号被关注对象。随着多核超线程技术 CPU 的普及,CPU 负载不均的问题逐渐在海量运维场景下,成为了设备运营成本的吞噬者。

运维如何为公司节省一个亿?

为了发现并优化多核 CPU 负载不均的现象,我们提出了 CPU 极差的度量指标,

CPU(极差)=CPU(max)-CPU(min),若 CPU(极差)>30%,则该设备存在 CPU 使用率不合理的问题,需优化整改。(备注:优化方法可参考多队列网卡优化与 CPU 亲和,本文不展开)。

同理,在分布式集群的模块容量管理中,运维规范要求实现模块的一致性管理,包括容量一致性,为此我们同样提出模块的容量极差的度量指标,模块 CPU 使用率极差= CPU 最高的 IP 的 CPU 使用率 – CPU 最低的设备的 CPU 使用率,若同模块下不同设备的 CPU 使用率极差>30%,则该模块容量使用不合理,需要优化整改。(备注:一般此类情况源于配置、权重、调度等不一致管理问题,不问不展开。)

方法 2:密度管理法

对于内存使用的合理性,很难直接用内存使用率来度量,为此,在内存型设备使用中,我们提出了密度管理的管控办法——访问密度。访问密度计算公式:,模块下的设备内存访问密度应该一致,否则纳入负载不均的一致性整改范畴。通过对全量内存型模块访问密度的统计分析,我们可以得出一条平均负载水平线,结合容量管理的实际需要,提高平均水平线或优化低于水平线的模块,都能实现优化设备成本管理的目的。同时,密度管理法也适用于 SSD 盘的使用场景。(备注:访问密度会受业务请求包大小的影响,但是在海量的运维场景下,个别情况可以忽略。)

方法 3:特性管理法

特性管理法,同功能模块的 QPS 管理类似,就是用来衡量在特定业务场景下,业务逻辑的处理性能是否最优,要结合不同产品下的同类应用场景的 QPS 同比来得出分析结论。这种管理办法因业务逻辑而异,本文主要举例说明下。

例如,在移动互联网的业务运维场景中,有些场景是非常规容量管理手段能度量的,针对一些个性但是规模庞大的模块,我们提出了特性管理法。举个例子,QQ、QQ 空间、信鸽等业务都有长连接功能模块,该场景的容量 CPU 少而使用内存多,因此可以使用每 G 内存维持的长连接数量来横向比较 QQ、QQ 空间、信鸽等业务,督促性能低的业务程序整改优化。

又例如,在直播场景中,有对主播视频实时在线转码的需求,不同的开发可能使用的转码技术方案不一,也可以利用同样的特性管理法来衡量在线转码的性能是否有优化空间。

方法 4:碎片管理法

腾讯社交网络业务历史悠久,从“大哥”QQ 到“新秀”企鹅 FM,业务类型覆盖 IM、UGC、多媒体、阅读、动漫、游戏、直播等主流的娱乐化社交玩法,其中有当红的产品,也有长尾的产品;有几十亿次每秒功能模块,也有几十次每秒的功能模块。碎片化管理法,就是针对请求量不高的小集群准备的。因为分布式高可用的运维要求,通常生产环境的部署最小单元都为 2 台设备,在物理机时代,访问量小的模块浪费成本严重,但随着虚拟化技术的广泛应用,该场景遇到的问题迎刃而解。利用虚拟化技术将硬件资源碎片化,让小模块可以很好的兼顾设备成本和高可用。

与虚拟化解决碎片资源利用率的方案类似,我们还有 PaaS 平台“蜂巢”,基于腾讯社交的标准开发框架 SPP,解决小业务小模块的容量管理难题。(后续专题聊蜂巢。)

方法 5:木桶管理法

腾讯平台级的业务,如 QQ、QQ 空间、QQ 音乐等,基本上都普及了三地三活的 SET(专区)容灾架构能力,这是真正意义上的异地多活。(正巧在 923 上海运维大会的海量运维专场,会有个主题与异地容灾的海量运维实践分享,如果大家感兴趣的话,诚邀大家参加。)对于平台级业务的运维,我们会根据运维规范管理的要求,将实现一定业务场景的多个模块划分为 SET(减少运维对象),在不同的社交场景下,我们就得出了各种不同类型的 SET,通过自动化运维能力扩大到 SET 的自动化运维能力,运维能很轻松的实现 SET 异地化部署,如此实现该业务场景异地多活的容灾容错。

运维如何为公司节省一个亿?

再说 SET 的容量管理,平台级 SET 就意味着用户量和请求量不会暴增,那么对于 SET 的可运维性而言,我们必须要对 SET 的请求量和用户量等指标进行量化度量。为此,运维赋予 SET 一个可量化的指标,在我们的场景下,如在线用户数、核心请求量等视 SET 的用途而定,基于压测可以得到单 SET 的最合理的容量值,该值符合木桶原理,也就是我们的木桶管理法,SET 由多个模块组成(SET=木桶,模块=木板),支撑一定的用户量,SET 的容量管理就像木桶原理一样,木桶的水位高低取决于最短板,因此 SET 的最大容量取决于 SET 中性能最低的模块容量。

运维如何为公司节省一个亿?

腾讯的平台级业务同时在线用户数是相对稳定的,也就意味着全国要实现多地多活,需要准备多少冗余容量是可预期可规划的,换而言之,要部署的 SET 的数量是能被提前量化的。同时,结合业务的自动化部署、调度方案、柔性策略和有损服务能力,我们就可以利用很合理的成本就能实现异地多活。

举例说明,假设我们共有 1000w 的同时在线用户,且用户量相对稳定,我们就可以规划 3 个支撑 500w 在线的 SET,利用业务架构的调度能力分别让 3 个 SET 的容量平均化,在灾难场景时,1 个 SET 不可用,另外两个 SET 可以完全容灾,在此规划下,极端场景 2 个 SET 不可用是要开有损服务的。通过量化 SET 管理,业务运维则可以灵活的根据成本管理的需求调整 SET 的容量水位,以达到最优性价比的高可用架构。

方法 6:硬件选型法

关注硬件瓶颈,升级硬件降低单机运营成本。比如,过去做 UGC 内存存储时(QQ 相册、视频),使用了大量 2T 硬盘,当 4T、8T 硬盘成本量产使用,及时的升级硬盘容量,可以有效的提升单机存储量,以规模效应实现花小价格换来了大成本。又如,在图片社交或视频社交的业务场景下,因玩法的多样性需求,会延伸出很多计算量繁重的逻辑,像人脸识别、鉴黄等功能,这时候选用 GPU 设备代替 CPU 设备,也是让性能飞的一种有效做法。(该方法尤为适用于 UGC 类的存储量只增不减的业务,如微云、网盘、图片存储、视频存储等。)

后记:

包括但不限于上述 6 种容量管理的方法,使得我们能在用户数据只增不减社交 UGC 业务中,能稳步的可持续前行。设备成本管理还涉及很多细节的技术手段和业务代码优化,本文只是从运维的视角阐述对容量管理的思考,希望能够抛砖引玉,对各位同行有帮助。带宽成本管理的优化带来的成本节省价值会更大,因为其中涉及的技术点和方法论更多,此文不深入探讨。

转载请注明:安全专题


    Selinux 中国 , 版权所有丨如未注明 , 均为原创丨本网站采用BY-NC-SA协议进行授权
    转载请注明原文链接:运维如何为公司节省一个亿?
    喜欢 (0)
    发表我的评论
    取消评论
    表情 贴图 加粗 删除线 居中 斜体 签到

    Hi,您需要填写昵称和邮箱!

    • 昵称 (必填)
    • 邮箱 (必填)
    • 网址