网络安全检测|网络安全服务|网络安全扫描-香港墨客投资移动版

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

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

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

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

受访嘉宾介绍：

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

传统运维困境

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

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

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

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

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

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

十年运维的包袱与创新

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

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

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

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

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

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