腾讯十年运维的包袱与创新

在云计算遍及业界的趋势下，以及 DevOps 和 SRE 等先进运维理念的强势助推，运维已然成为驱动各大公司研发运维流程和理念变革的关键角色，如持续集成和发布、场景化的运维自动化、智能监控等理念的落地执行。

可以看到，运维已经慢慢承担起了稳定性保障、流程效率改进、性能优化、用户体验提升以及成本控制等关键职责，但更高的要求必然带来新的挑战和机遇，我们将如何应对？

2017 年 7 月 7 日 -8 日， ArchSummit 全球架构师峰会将在深圳华侨城洲际酒店举行。本次大会设置了《运维新挑战》专题来深入解读基于容器的持续集成和发布、智能监控和故障自愈等技术的实践案例，其中邀请了腾讯运维总监聂鑫老师前来分享《腾讯监控创新术》。

我们借此机会采访了聂鑫老师，他为我们带来腾讯这十年运维建设的思考体会，如果读者想了解更多腾讯的运维创新实践，欢迎报名参加 ArchSummit 深圳站并与聂鑫老师进一步交流。

受访嘉宾介绍：

聂鑫，腾讯社交网络运营部运维负责人，从开发到运维，伴随腾讯社交网络运营部成长的十年，负责过腾讯社交产品所有业务运维工作，目前主要负责 QQ、空间等产品运维团队管理工作。经历多个业务产品的诞生到蓬勃，伴随着运维团队的成长和成熟，见证着腾讯一代代运营技术的创新和发展。作为运维界老兵有好多故事想和大家讲，也特别愿意听听各位经历的酸甜苦辣。

传统运维困境

腾讯 SNG 运营部对接的是腾讯社交网络业务的所有运维工作，负责业务服务研发完成后的所有运维相关工作。团队组织形式上主要分为应用业务运维、DBC 团队、组件集群运维及研发、运营体系建设团队、虚拟化技术团队、系统运维等，全部运营相关领域都会涉及，从大的分工上来说，运营部实现了在业务研发和基础网络设施中间全部运维的闭环。

回顾 BAT 的运维建设，很巧合地基本都是 2006~2007 年开始，大家一开始从一穷二白什么都没有的阶段开始逐步补充各种点的监控，经历了一大波监控系统覆盖率建设方面的建设红潮。

当初使用的传统监控主要以建设各种系统来补齐监控点为主，监控发现也主要以告警、邮件、日报等方式推送，对监控数据的利用基本还是利用各种规则和单纬度模型来处理。小规模团队主要以“能看到，能收到”为主，复杂一些的团队会建立多个指标和规则来减少告警，先进一些的团队会尝试用一些模型来优化。

但这十年来，几大互联网巨头的规模已经扩大了 10~20 倍，监控数据和告警的体量已经很难通过各种固定指标和单一化模型来解决。

腾讯社交网络 Group 也历经了这个阶段，服务规模从千级迅速膨胀到二十万级，历经十年的建设目前各种纬度的主要监控系统超过 20 多个，日短信告警量超过 5 万条，极端情况下运维和研发人员每天要接受超过 1500 条短信告警，各种通知和相关的报告更是不计其数。

当然我们也尝试过很多种基于经验、统计学、大数据等方式的技术优化探索，也将告警的量级降了近 2 万条，但对于庞大的基数和不断扩张的业务，传统的优化手段已经很难帮助团队走出困境。

十年运维的包袱与创新

对于运维来说，十年的包袱无法说放下就放下，局部的修改和优化已经无法扭转当前的监控数据泛滥困局，针对这个问题，我们的思路包括 2 方面：

1. 从架构上重新理清楚监控的数据本质，归纳为：流数据、多维数据、日志数据等；
2. 从产品上通过旁路的方式切入当前产品，比如架构上，我们将监控数据分成 3 类（流、多维、日志），重点打造这 3 类的数据架构体系，通过选择优秀的开源（Storm,Spark,ELK）或者自研 (monitor,harmer) 的数据架构来优化，尽量通过接口适配方式或者数据迁移方式，在尽量不改变原有产品形态的基础下，实现无损的将现有监控系统逐一迁入合并。

而在产品上新的创新尝试则基本都是通过旁路的方式来验证，比如这次在 ArchSummit 上将要分享的织云产品中的 ROOT、DLP、算法等，这样可以保障充分的验证和 A/B test 效果。

从我们的思路来看，我们尊重历史，存在必为合理。不合理的是历史演进而产生的架构落后，可以通过技术解决，不合理的产品则需要充分的创新来破旧立新，这是自然的产物，相信未来各大同行也会逐步突破，殊途同归。

如前所说，各大互联网同行的运维建设大致都是十年左右，经历的阶段也都类似：比如从一开始的铺开去做各类系统来覆盖监控点，到逐渐做精细化的贴近用户的监控，到业务爆发后开始对已有监控的各类优化，再到目前引入各类创新手段来重新定义监控体系。

而咱们聚焦在监控上，在这么长的运维建设中我个人感触比较深的一点是：作为运维负责人，各种规模大一点的故障的复盘回顾中都会涉及监控的问题，很多案例中会同时出现 2 种现象：

1. 反馈监控不全，需要补齐；
2. 监控告警太多，人关注不到

这种现象出现的比率非常高，相当地矛盾。补齐告警容易，20 多套系统总有一款能补齐告警，把告警发给所有相关的人也容易，这很粗暴，但真正能让告警被有效的关注和处理的却很困难。

如果我们目前做不到无人化的运维，那么必须让人能发挥作用，运维人员有一个合理的承受能力阀值，比如每天最多 50 条告警。那么为了达到这个目标，创新的方法必不可少。

比如在这次 ArchSummit 深圳站分享的《腾讯监控创新术》会提到的：

• ROOT：基于业务架构的链路关联算法；
• DLP：业务核心生死指标；
• 大数据：通过机器有监督学习的方式来优化告警；
• 全链路：利用海量数据关系来拓展纬度。

代号 ROOT 的项目即我们的数据链路计算选路，属于织云产品的一个监控功能，2014 年在业界分享过，获得很多同行和厂商的关注。原理不复杂，仍然是通过既定的模型方式来关联各类告警，比较创新的地方包括引入业务架构计算链路再降维展现，告警叠加后引入面积算法来计算优先级。

做创新就像在没有路的山上行走，一定会踩坑。除了信心决心也要为踩坑做好准备，团队需要积累一定的技术深度来解决问题，用开放的心态去学习和接受新事物。

比如 ROOT 最开始的存储结构很复杂，没有现成的框架，直接制约了我们的想法无法落地，直到偶然的机会学习到腾讯业务产品线有相似存储场景的实现。

再比如在做全链路监控时，设计阶段对数据按号段存储还是 by UIN 存储有过争议，可惜的是当时没有坚持，最终导致中期性能瓶颈已经影响产品，需要做动筋骨的调整。

培养新时代的“召唤兽”

说到智能运维可以单独有一次长时间的分享，因为十年来腾讯 SNG 运营部更多的是围绕着织云自动化 / 智能化运营体系在建设，这儿的创新和各类经验教训一言难尽。特别有一些有趣的创新和建设成果，即时对目前百花齐放的运维思路来讲，依然有很强烈的借鉴参考意义。

运维界的各类理念百花齐放已经比较多，我个人认为是现成流派的一个过程，未来随着流派的形成，各派的“招数”将逐渐形成，华山峨眉不分好坏，而分是否适合各自的企业。未来运维从业人员需要在各自的流派中深入建设，将各自的招数修炼到极致，运维界才能欣欣向荣。

但有一点，从 2010 年开始我个人比较坚持，那就是“会的越多包袱越大”，2009 年网上有张流行的图画出了运维应该具备的各项技能（比如要会写批量脚本，要会做系统内核调优，要懂数据库 SQL，要会很多 Linux 命令等等），而我当时对团队讲的是那张图上的 90% 的技能都是包袱，因为人很容易陷入通过自己已经熟悉和掌握的技术来解决问题的思考方式。

更好的方式或许是不断地分析分解我们要达到的目标是什么，为了达到这个目标我们应该借鉴哪些新思想，学习掌握什么技能，如果要超越目标，又需要做哪些布局和应用哪些新技术，甚至引入新领域人才。

近年来一些新的东西比如 Hadoop、ELK、Docker、AI 等被大量引入运维领域并应用起来，带来了最近的运维界春天，而作为运维从业者勇敢的放弃过去的包袱，才能拥抱新技术并创新的去扩展和应用。时代的演进，运维界已经不能“打怪靠一招”了，是时候培养属于自己的“召唤兽”了。

InfoQ：感谢聂鑫老师接受我们的采访，期待聂鑫老师在 ArchSummit 全球架构师峰会分享的《腾讯监控创新术》，该专题下也邀请了小米云平台工程师陈帅分享《小米监控实践之路》，点击“阅读原文”获取更多分享内容。

ArchSummit 将在 7 月 7-8 日在深圳华侨城洲际酒店举办，目前限时 8 折报名优惠，如果在报名的过程中遇到任何问题，都可以联络我们的售票天使豆包，QQ：2332883546，电话：18515221946，微信：497788321，欢迎骚扰～

感谢丁晓昀对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们。