@citian3094
2017-03-23T06:49:25.000000Z
字数 2624
阅读 1234
未分类
在云计算遍及业界的趋势下，以及 DevOps 和 SRE 等先进运维理念的强势助推，运维已然成为驱动各大公司研发运维流程和理念变革的关键角色，如持续集成和发布、场景化的运维自动化、智能监控等理念的落地执行。
可以看到，运维已经慢慢承担起了稳定性保障、流程效率改进、性能优化、用户体验提升以及成本控制等关键职责，但更高的要求必然带来新的挑战和机遇，我们将如何应对？
2017年7月7日-8日，ArchSummit全球架构师峰会将在深圳华侨城洲际酒店举行。本次大会设置了《运维新挑战》专题来深入解读基于容器的持续集成和发布、智能监控和故障自愈等技术的实践案例，其中邀请了腾讯运维总监聂鑫老师前来分享腾讯监控创新术，我们借此机会采访了聂鑫老师，他为我们带来腾讯十年运维建设总结的思考体会，如果读者想了解更多腾讯的运维技术，欢迎报名参加ArchSummit深圳并与聂鑫老师进一步交流。
受访嘉宾介绍：
聂鑫，腾讯运维总监，从开发到运维，伴随腾讯社交网络运营部成长的十年，负责过腾讯社交产品所有业务运维工作，目前主要负责QQ、空间等产品运维团队管理工作。经历多个业务产品的诞生到蓬勃，伴随着运维团队的成长和成熟，见证着腾讯一代代运营技术的创新和发展。作为运维界老兵有好多故事想和大家讲，也特别愿意听听各位经历的酸甜苦辣。
（补充：自己的职责，在分工上能仔细描述一下吗？）
腾讯SNG运营部对接的是腾讯社交网络业务的所有运维工作，负责业务服务研发完成后的所有运维相关工作，主要来说包括应用运维、DBC、组件集群运维及研发、运营体系建设、虚拟化技术、系统运维等全部运营相关领域。从大的分工上来说，运营部实现了在业务研发和基础网络设施中间全部运维的闭环。
回顾BAT的运维建设，很巧合的基本都是2006~2007年开始，一开始从一穷二白什么都没有的阶段开始逐步补充各种点的监控，经历了一大波监控系统覆盖率建设方面的建设红潮。
当初使用的传统监控主要以建设各种系统来补齐监控点为主，监控发现也主要已告警、邮件、日报等方式推送，对监控数据的利用基本还是利用各种规则和单纬度模型来处理。
小规模团队主要以“能看到，能收到”为主，复杂一些的会建立多些指标和规则来减少告警，先进一些的团队会尝试用一些模型来优化；
但这十年来，几大互联网巨头的规模已经扩大了10~20倍，监控数据和告警的体量已经很难通过各种固定指标和单一化模型来解决。
腾讯也历经了这个阶段，目前各种纬度的监控系统超过20多个，日短信告警量超过5万条，各种通知和相关的报告不计其数。
对于运维来说，十年的包袱无法说放下就放下，局部的修改和优化已经无法扭转当前的监控数据泛滥困局。
针对这个问题，我们的思路包括2方面：
从架构上重新理清楚监控的数据本质；
从产品上通过旁路的方式切入当前产品，比如架构上，我们将监控数据分成3类，重点打造这3类的数据架构体系，在无损的前提下将现有监控系统逐一迁入合并。
而在产品上新的创新尝试基本都是通过旁路的方式来验证，比如这次将要分享的织云产品中的ROOT、DLP、算法等。这样可以保障充分的验证和A/B test效果。
从我们的思路来看，我们尊重历史，存在必为合理。不合理的是历史演进而产生的架构落后，可以通过技术解决；不合理的产品则需要充分的创新来破旧立新。
这是自然的产物，相信未来各大同行也会逐步突破，殊途同归。
如前所说，各大互联网同行的运维建设大致都是十年左右，经历的阶段也都类似；比如从一开始的铺开去做各类系统来覆盖监控点，到逐渐做精细化的贴近用户的监控，到业务爆发后开始对已有监控的各类优化，再到目前引入各类创新手段来重新定义监控体系。
数据链路计算选路属于织云产品的一个监控功能，代号ROOT，2014年在业界分享过，获得很多同行和厂商的关注。原理不复杂，仍然是通过既定的模型方式来关联各类告警，比较创新的地方包括引入业务架构计算链路再降维展现，告警叠加后引入面积算法来计算优先级
咱们聚焦在监控上，我个人感触比较深的一点是：作为运维负责人，各种规模大一点的故障的复盘回顾中都会涉及监控的问题，很多案例中会同时出现2种现象：
反馈监控不全，需要补齐；
监控告警太多，人关注不到
这种现象出现的比率非常高，相当的矛盾。补齐告警容易，20多套系统总有一款能补齐告警；把告警发给所有相关的人也容易，这很粗暴。但真正能让告警被有效的关注和处理的却很困难。
如果我们目前做不到无人化的运维，那么必须让人能发挥作用；运维人员有一个合理的承受能力阀值，比如每天最多50条告警。那么为了达到这个目标，创新的方法必不可少；
比如这次分享中会提到的：
ROOT：基于业务架构的链路关联算法；
DLP：业务核心生死指标；
大数据：通过机器有监督学习的方式来优化告警；
全链路：利用海量数据关系来拓展纬度
做创新就像在没有路的山上行走，一定会踩坑。除了信心决心也要为踩坑做好准备，团队需要积累一定的技术深度来解决问题，用开放的心态去学习和接受新事物。
比如ROOT最开始的存储结构很复杂，没有现成的框架，直接制约了我们的想法无法落地。直到偶然的机会学习到腾讯业务产品侧有相似存储场景的实现。
再比如在做全链路监控时，设计阶段对数据按号段存储还是by UIN存储有过争议，可惜的是当时没有坚持，最终导致中期性能瓶颈已经影响产品，需要做动筋骨的调整。
智能运维可以单独有一次长时间的分享。因为十年来腾讯SNG运营部更多的是围绕着织云自动化/智能化运营体系在建设，这儿的创新和各类经验教训一言难尽。
特别有一些有趣的创新和建设成果，即时对目前百花齐放的运维思路来讲，依然有很强烈的借鉴参考意义
运维界的各类理念百花齐放已经比较多，我个人认为是现成流派的一个过程，未来随着流派的形成，各派的“招数”将逐渐形成，华山峨眉不分好坏，而分是否适合各自的企业。
未来运维从业人员需要在各自的流派中深入建设，将各自的招数修炼到极致，运维界才能欣欣向荣。
但有一点，从2010年开始我个人比较坚持，那就是“会的越多包袱越大”，2009年网上有张流行的图画出了运维应该具备的各项技能，而我当时对团队讲的是那张图上的90%的技能都是包袱。
时代的演进，运维界已经不能“打怪靠一招”了，是时候培养属于自己的“召唤兽”了。
InfoQ：感谢聂鑫老师接受我们的采访，期待聂鑫老师在ArchSummit全球架构师峰会分享的《腾讯监控创新术》。