腾讯SNG梁定安：显微镜下的运维自动化

《腾讯SNG梁定安：显微镜下的运维自动化》要点：
本文介绍了腾讯SNG梁定安：显微镜下的运维自动化，希望对您有用。如果有疑问，可以联系我们。

本文来自腾讯社交多媒体业务负责人@梁定安(大梁)在APMCon2016·听云的同名主题演讲,解读了在亿级在线用户和十万级服务器的海量运维压力挑战下,如何把繁杂的运维工作变成自动化.

今天我跟大家交流的是实实在在的怎么样做运维自动化这个主题.

可能之前大家也听过我介绍织云平台怎么做,我最近想一个事情,像腾讯这种体量(QQ月活量是8.3亿,8.3亿的DAU)及海量运维压力下,构建出的自动化运维平台如果真的放在一些中小企业,是没有太多的用武之地.

那么怎么办?

我一直在想怎么样能够让大家没白来这次的分享,所以我特意把我之前对整个运维自动化分享的内容重新提炼总结,通俗点的说就是更接地气,我节选了我们这么多年做运维自动化里面最重要的一些功能模块.

所以今天不会给大家介绍一个很庞大的系统,我会专门去讲自动化里最核心的环节(CMDB分层、技术架构及后续落地办法等等),说不定大家做了这些核心环节,就能提升到很高效的水平.

一、运维自动化的能与不能

今天的分享主要有三部分,前两部分会重点跟大家讲一下,我们做运维自动化之前,应该具备什么样的理念.无论是运维还是开发这两个角色,其实都需要去遵循这样一些俗称的标准化,我们的规范是什么?基于这样的一些规范,我们怎么把我们的自动化落地.

自动化不是万能的,并不是所有的场景都适用.运维自动化也是一样,在腾讯体量很小的时候,我们就一直琢磨着要怎么样高效运维.

因为腾讯的社交产品是树状结构,小的一些应用特别多.只有核心的几个像QQ相册、QQ空间、QQ音乐体量特别大,其他都是很碎片的小应用,如果这些小应用杂乱无章的生长,怎么规范化它?在它发展的时候我们的运维效率又能跟上.

去年6月份,腾讯整个集团的物理机刚刚突破50万,我们运维团队的人增幅远没有服务器增长的快.

我们先来看一下自动化想解决什么样的问题?

上面这些挺有意思的话节选于我们团队内部：比如文档即过期,我们做运维的,老板整天希望我们写一些所谓的运维文档,这个文档写出来的时候其实就意味着它已经过期了.

还有一些资深同事离职,经验也就消失了,这些都希望在自动化里解决.还有逻辑的解耦、微服务,写死IP,或者有必要的切换等,这些肯定是在做运维自动化的时候不希望去触的雷区,还包括包括人为同时的失误、架构的失控等等.

我们怎么样提出标准化规范?让我们的研发团队、运维团队更高效合作,避免出现误区?

做自动化不是为了炫酷,不能为了自动化而自动化,20%的工作消耗了我们80%的精力,我们只要集中精力把那20%的工作做好基本上就可以达到很好的状态了,就可以释放精力去做大数据、做智能化运维,而不是说什么场景都要追求到完完全全的极致.

我们团队内部,大家都会经常说一句话,任何事情做到80分,我们投入半年就够了.但是要把另外20分做完,可能要投入的时间远大于那80分,所以这时候,我也是希望大家在回去规划自己的运维自动化场景的时候,能够着重思考这一点,哪个优先去做.

我们给我们的运维自动化下了一个定义,做任何事情之前,首先清楚我们的目标：在大规模运维场景下,将重复度高的工作,基于监控数据智能决策触发,实现无人参与的自动操作的运维能力,称之为运维自动化.

这里很重要的是无人参与,目前我们的平台是可以做到无人职守扩和缩,今天就跟大家介绍怎么实现的.

再次回到业务场景,在腾讯的社交业务场景下,海量、敏捷、复杂高可用上面都有一些具体的描述,这也是在中国这么大的用户群体下所有社交产品的一个普遍表现形态.

二、DEV与OPS：求同存异

在这样一个海量的业务压力下,我们怎么样跟我们的开发人员、运维人员去共同定制我们能够落地实现的标准化运维方案?

在2008年、2009年的时候,我们当时提D/O分离,但我一直觉得D/O分离有点自己坑自己的味道,你开发好程序给我你就不用干了,我含着泪都要把这个干好.

一个架构很差的程序,我们没有办法把它维护得很高效.

在腾讯社交这个产品线,我们现在功能模块有5000多个,底下对应的微服务得上好几万个,这种情况是没有办法维护一些架构很差程序代码的.

在当时2010年的时候,DevOps的概念还没有提出,我们已经意识到这个问题,所以当时就已经开发了织云这个平台,当它真正的跟DevOps这个理念对齐的时候是不谋而合的.

只有合作才能走得更快,才能在激烈的互联网红海竞争下取得胜利,怎么去做?

我们把开发和运维有可能打交道的地方分成四大块：首先是架构.

运维很关注架构,不然没办法评估它的质量好坏跟架构有没有直接的关系.运维希望开发遵守我们的规范.

之前我跟一些传统行业的同行也有过交流,他们写了很多规范开发不能做,这些都是流于形式,没有办法实实在在的去要求.

为此,我们带着这样的问题,一起来看一下腾讯是怎么实践的.

我们推崇的统一架构、运维规范,怎么作用到开发人员的身上?然后基于这样的统一的规范,如何能够去打造运维的工具系统,让它实现自动化?

基本上所有的互联网业务架构,我们都是可以用上图来简单概括,分为客户端,用户用的终端、PC,中间是运营商,然后三层架构：接入层、逻辑层、数据层.

腾讯整个社交,大概是分成这个样子,针对同样的架构,我们就开始提出管理理念：框架化、组件化、无状态、分布式.

我们的框架化是怎么落地的?

在腾讯社交这边,我们的业务开发整个技术栈,基本上都是用C为我们的主要开发语言,不是用Java,所以说没有办法基于Java无痛注入的方案做APM,我们必须对开发的技术习惯设计更适合我们的框架.

为此,我们针对Socket通信把CS架构的服务端,按照公共的功能专门用来通讯、收发包,些能力变成一个框架.业务开发只需要专注写它的业务逻辑,实现我们的框架.

在腾讯基本上我们有支持同步的开发框架、支持异步的开发框架,还有Web服务的一些应用,都是有通用的框架来支持的.

（编辑：ASP站长网）