从QQ运维的历史遗留问题看公司运维的进化过程
2016-02-20 19:34:14   来源： 梁定安 高效运维    评论：0 点击：

主要讨论人员

◆提问： 智锦

◆回答： 梁定安(大梁)

嘉宾介绍

梁定安

10年运营开发、海量运维和架构规划经验，任腾讯社交平台运维团队、综合运维团队leader，主要负责Qzone、相册、音乐等社交平台类业务的运营开发和运维规划工作，精通海量服务的架构设计和自动化运维建设，目前专注于devops、APM、大数据的运维实践探索。infoq高级运维讲师，腾讯云布道师。

引言

「坐而论道」是高效运维社区独创的一种技术交流形式，由技术高手之间互相提问并进行解答，每周讨论一个话题，由其中一位发起提问并指定下一位进行解答，解答完的人继续提出新的问题并指定下一位回答者，以此类推。

精彩回答

◆运维面对最困难的问题，我们统称历史遗留问题。如无标准化包管理、配置有硬IP、监控点覆盖不全等。

◆织云解决了运维持续部署的难题，实现服务的快速自动上下线，基本上满足了80%运维效率的诉求，目前我们主要做的还是在不断的打磨让系统用的更顺，标准化流程的适用面更广。

◆但整个织云体系的对外开放，目前的计划是有所限制的，暂时只会对腾讯系的企业输出。

◆QQ和微信，分属腾讯的SNG和WXG，这两款产品都算得上是国内IM的巨头，在IM的运维场景下，有着相同的运维挑战。

Q1 :QQ产品线和历史如此悠久，历史上的遗留问题和遗留工具一定很多，作为用运维人员，如何去解决历史遗留问题；作为运维开发人员，如何吸纳历史上的工具系统，降低重构的代价。这方面有没有经验和案列可以分享。

答：这个问题真的说到运维的痛点上了，运维面对最困难的问题，我们统称历史遗留问题。我们面对的历史遗留问题也挺多的，如无标准化包管理、配置有硬IP、监控点覆盖不全等。

所幸我们从09年就开始着手进行运维的标准化统一，得益于和开发、测试团队的良好合作关系(6年前就可以说开发、测试、运维间就已经萌芽了devops的文化)，运维推动的包管理系统、配置管理系统、cmdb、质量监控规范都被很好的贯彻落地了。

我举个简单例子：

09年时，我们为了推包管理规范，就一度要求研发如果上线了非标准化的包，就必须要来运维团队做1周的打包苦力。通过这样的举措，我们将一个个历史遗留问题的山头攻克，现在我们内部的织云自动化平台，也是整合了运维团队一直以来的建设成果功，利用流程引擎整合而成的自动化系统，让我们的运维效率得以提高。

现在游离在运维标准化体系外的业务还是有的，原因很多，有并购的公司、有组织架构调整引入的老架构等等，对这部分的管理，只要还要增长的服务，运维都会提出可运维规范要求，如打包、接入织云，如稳定期，不需要继续增长的服务，我们就不求自动化运维效率多高，只要求有路由的自动容错，保障服务的质量，维持现状即可。

Q2 :作为QQ这样成熟的产品，“织云”未来的技术上的发展规划是怎么样的，还会不会有一些新的设计思路。

答： 织云解决了运维持续部署的难题，实现服务的快速自动上下线，基本上满足了80%运维效率的诉求，目前我们主要做的还是在不断的打磨让系统用的更顺，标准化流程的适用面更广。提到新的设计思路，根据SNG的业务场景和不同时期运维关注点的不同，我们针对服务调度、跨IDC搬迁、SET复制、成本管控的场景，都有开发相应的工具，但这一切都是基于自动上线这个核心功能的。

Q3 :织云和蓝鲸都是腾讯系的比较成功的运维产品，而蓝鲸已经从服务内部开始走向服务外部游戏客户了，织云有没有类似的走出去的规划?

答：走出去的案例是有的，如织云的核心模块包管理系统，简化版tars已经在腾讯云的应用市场对外开放，大家可以在腾讯云上搜下。在一些腾讯系的企业，如webank、富途、滴滴，都有或多或少的使用织云的一些模块。

但是整个织云体系的对外开放，目前的计划是有所限制的，暂时只会对腾讯系的企业输出，原因有二：

1.在腾讯适用的海量运维平台，对小企业未必适用，可能只需要其中的个别模块就已经足够；

2.我们团队的职能还是要聚焦在腾讯内部支持，在释放运维效率后，我们还有很多智能监控、运维大数据、APM等方向要继续钻研。

Q4 :QQ的运维，和微信的运维，你觉得有差异或者不同的挑战吗?

答： QQ和微信，分属腾讯的SNG和WXG，这两款产品都算得上是国内IM的巨头，在IM的运维场景下，有着相同的运维挑战。

不同点，我列3点我的个人理解：

◆国际化的挑战，微信用户国际化程度很高，QQ用户相对集中在国内；

◆微信的增值功能相对少，QQ属于一个大平台，很多应用基于QQ生长，这也是运维的区别之一；

◆PC端的管理，微信和QQ的主要差异，QQ正在PC端继续发力突破，如在线教育等领域，这些是微信没有的。

Q5 :从QQ的运维出发，在“容量管理”和“故障的根源分析和自动处置”这个两个运维的难点来看，分享一下你的经验。

答： 监控相关的问题，涉及的背景比较大，我尽量简单的说：

1.容量管理，运维基于容量管理，对成本管控、业务趋势预测、调度决策等做了很多自动化和分析的事情。首先在成本管控方向，基于容量对不同业务的平均负载、单机QPS、容量一致性等纬度进行分析，驱动运维和开发针对性的优化，2014年给腾讯节省了3亿运营成本。

业务趋势预测、调度决策，其实说白了就是基于容量对单个模块做快速上下线的运维操作，对SET服务做调度或柔性决策参考。

2.故障的根源分析和自动处理，先说自动处理，对于基础告警(死机、进程/端口挂、硬盘满/只读)我们是有自愈策略的，主要是基于我们的标准化运维体系，包括：包管理、设备响应级别、自定义处理逻辑等基础实现的。织云的流程系统，也支持类似“蓝鲸”的自定义告警处理逻辑，以应对不同场景的需求，但是SNG内部标准化程度很高，基本上一套自愈策略就能cover绝大多数的业务。

3.故障根源分析，我们内容有个ROOT项目(2015年7月的AS大会上有分享过《腾讯端到端运维监控体系》)，原理是基于业务的访问拓扑，在单位时间片内把各个监控系统的告警信息叠加在链路上的各个模块中，通过算法计算出最有可能的告警点，从而从众多的现象告警和原因告警中，筛选出原因告警，从而实现故障的根源分析。

还有一个《智子》的apm项目，主要是针对移动APP运维的场景，类似听云和oneapm的方案，在app的每个方法中都注入我们的耗时计算逻辑，实现移动端的卡慢、异常分析，是代码级的监控系统。

如何一起愉快地发展

“高效运维”公众号（如下二维码）值得您的关注，作为高效运维系列微信群的唯一官方公众号，每周发表多篇诚意满满的原创好文：来自于系列群的讨论精华、运维讲坛线上精彩分享及群友原创。“高效运维”也是互联网专栏《高效运维最佳实践》及运维2.0官方公众号。

提示：目前高效运维新群已经建立，欢迎加入。您可添加萧田国个人微信号xiaotianguo8 为好友，进行申请，请备注“申请入群”。

重要提示：除非事先获得授权，请在本公众号发布2天后，才能转载本文。尊重知识，请必须全文转载，并包括本行。

【编辑推荐】