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

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

传统运维困境  

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

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

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

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

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

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

十年运维的包袱与创新  

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

1、从架构上重新理清楚监控的数据本质，归纳为：流数据、多维数据、日志数据等；

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

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

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

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

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

1、反馈监控不全，需要补齐；

2、监控告警太多，人关注不到

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

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

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

·                     ROOT：基于业务架构的链路关联算法；

·                     DLP：业务核心生死指标；

·                     大数据：通过机器有监督学习的方式来优化告警；

·                     全链路：利用海量数据关系来拓展纬度。

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

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

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

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

培养新时代的“召唤兽”  

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

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

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

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

近年来一些新的东西比如Hadoop、ELK、Docker、AI等被大量引入运维领域并应用起来，带来了最近的运维界春天，而作为运维从业者勇敢的放弃过去的包袱，才能拥抱新技术并创新的去扩展和应用。

时代的演进，运维界已经不能“打怪靠一招”了，是时候培养属于自己的“召唤兽”了。

（聂鑫原创）

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

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

传统运维困境  

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

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

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

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

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

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

十年运维的包袱与创新  

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

1、从架构上重新理清楚监控的数据本质，归纳为：流数据、多维数据、日志数据等；

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

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

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

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

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

1、反馈监控不全，需要补齐；

2、监控告警太多，人关注不到

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

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

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

·                     ROOT：基于业务架构的链路关联算法；

·                     DLP：业务核心生死指标；

·                     大数据：通过机器有监督学习的方式来优化告警；

·                     全链路：利用海量数据关系来拓展纬度。

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

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

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

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

培养新时代的“召唤兽”  

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

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

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

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

近年来一些新的东西比如Hadoop、ELK、Docker、AI等被大量引入运维领域并应用起来，带来了最近的运维界春天，而作为运维从业者勇敢的放弃过去的包袱，才能拥抱新技术并创新的去扩展和应用。

时代的演进，运维界已经不能“打怪靠一招”了，是时候培养属于自己的“召唤兽”了。

（聂鑫原创）