我斩获了这5把,优维科技EASYOPS

十年不苟且的运维之路

3月12日,优维科技与又拍云联合举办的Open Talk No.29《云上运维与研发最佳实践》在上海顺利举行,优维科技CTO黎明带来了《微服务架构下的运维平台构建》的精彩分享,结合微服务架构特点,解读如何构建一个高效运维管理平台。

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

加入腾讯已十年的运维老兵,回顾这十年:

黎明:带领团队自主研发全栈DevOps运维管理平台——EasyOps,是目前行业领先的智能化运维管理平台。

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

2004年:加入腾讯,做贺卡开发;2005年:加入QQ空间开发团队,负责留言版模块;2006年~至今:公司组织架构调整,接触运维工作。

曾是腾讯最复杂业务部门的运维研发负责人,主导了多个运维系统研发舆情监控、大数据监控平台、CMDB、实时日志分析平台、织云、客户端体验监控等。

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

期间,他带领运维团队负责QQ延伸出来的各种社群的运维和维护,包括QQ空间、QQ音乐、QQ会员、QQ秀等一系列的QQ产品。团队89个人,维护了10万家服务器。经历的大事件有:红米在QQ空间首发时,90 秒卖出 10 万台设备,获得1亿点赞;天津大爆炸事件,把天津 2 亿多活跃用户,从天津快速调到深圳以及上海;春节红包准备工作,2016年比2015年的红包访问量增长了10倍+,快速的扩充了 5000 台设备,最高访问量达到 477 万次/秒。

以下为黎明分享稿,经编者整理。

那么怎么办?

不要让自己变成一个救火队员

今天演讲的主要内容有三点:

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

作为运维,最重要的是先保证自己做的系统可靠、不会轻易出错,不要让自己变成一个救火队员。可靠之后,就要用更多时间去解决效率问题,让工作变得更加高效,追求更高的目标。

1、微服务架构特点及其传统巨石架构的差异,以及传统运维工具面临的挑战;

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

对团队工作帮助最大的是什么?

2、面向微服务的运维平台架构;

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

资源管理:把写出来的程序和代码,进行清晰划分和分类,对每个资源采用不同形式进行搭建;容错方案:在维护海量服务、运维过程中出现故障时,确保不能影响项目服务,服务器要做到及时处理;统一架构 CMDBA:把一个业务模块上所有依赖资源全部登记进去;同时如果做快速决策和调度,还需要有效的监控。DLP:内部定义的一个非常关键的监控,这个点发生后,可以知道哪里出现故障;

3、运维平台微服务进化。

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

入口监控:告知出现故障的根源在哪儿,容错方案的 L5 是用来解决容错、灰度,路由等。

一、 微服务架构与巨石架构的差异

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

运维团队的五个“杀手锏”1.L5系统

“微服务”与“巨石架构”两者并非对立,而是分别针对不同场景的解决方案。

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

世界上管理服务器最多的系统

巨石架构指将所有“大脑”集中在一起,以CS架构为代表,将所有的逻辑放在唯一应用中,再加入前端UI组件、Service、MVC架构、数据库等部分。它的技术架构不复杂,调试、部署、管理方便,是适用于绝大部分系统的解决方案。

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

运营管理系统管理了上亿服务器,脉络非常清晰,根本不会出现混乱。L5 系统也类似于 DNS 系统,有一排能提供的服务模块,从而解决的单点问题。

但是在互联网要求“多、快、好、省”的应用场景下,“巨石架构”面临诸多挑战。

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

L5 如何做容错?

多:互联网用户量巨大,达百万级在线量;

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

L5-主机/接口级的容错原理

快:服务请求反应速度要在一秒以内甚至更快;

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

L5 有由 L5、DNS 和 L5、agent 两部分构成。CGI 通过给模块提 ID,根据模块下设备的成功率和延迟情况,通过 IP+PROT 给 CGI 一个反馈,访问之后,通过成功率和延迟情况,把数据上报给了 L5agent,然后做统计数据。当发现失败率特别低的时踢掉。当发现成功率和失败率有一定下降,会把访问权重降低,从而达到容错和负载均衡的作用。

好:服务质量稳定性要高;

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

可以注册一个模块,加多台设备,形成容错效果。如发现一台机器失败率很高,就把它踢掉。它成功率恢复过来,还可以再加回来。

省:硬件成本增涨要低于用户量增涨速度。

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

新加一台服务器设计它的权重为 1,假如之前的是 100,可以逐渐上线。还可以给它一个得分,得分下降的时候,快速把它踢掉。L5 具有灰度、容错、路由、负载均衡的能力。

如何解决这四个问题——增强整个平台的灵活性。

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

L5 对运维团队有哪些帮助?

平台扩展能力

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

减少了 80~90% 的日常故障;不再需要频繁的变更 ip+port;同过名字便利的服务上下线;通过权重灰度上线;模块访问关系可帮助定位根源故障;接口的延迟和失败率可用来监控;

1.平行扩展:一般的无状态服务器可以通过服务器扩容完成平行扩展;

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

集容错、负载均衡、路由、灰度、监控能力于一身。

2.分区:对于有状态的服务可以通过分区增强平台灵活性,如:南北方用户分属A、B不同集群。

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

2.统一框架和架构

平台上的扩展“巨石架构”可以适应,但是功能上的扩展却比较难适应。

二、DEV与OPS:求同存异

团队里有上千号开发同事,每年会有大量毕业生加入,也会有社交同事。进来以后,都希望为平台做更多的代码贡献、展现自己的技术实力,亦或是提高自己。

功能扩展能力

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

那么,问题来了。在开发过程中,如下图,有管道、消息队列、信息文件锁、记录锁、文件影射内存、还有迭代服务器 Select poll Io 等,这些是用各种各样技术组合生产出来的代码,交给团队维护,数以万计不同性格的服务器,要掌握得非常好,了解它的工作机制和原理,更好的维护它基本上是不可能的。

功能维度上,如何使系统变得更融洽?

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

那怎么办呢?把网络通讯部分列成一个标准框架,提高它的通讯效率,统一维护。

1.灵活控制成本:局部调整,变更模块、逻辑,而不是整个系统去修改。

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

统一框架

巨石架构的所有模块都捆绑在一起,进行扩展时,由于每个模块巨大,只能高成本平行整体扩容。

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

业务逻辑部分用 SO 动态库方式编写与框架分离部署,类似 Web 服务器上的CGI。接入层用 QZHTTP,逻辑层是 SPP 和 SF 的框架。

微服务架构下模块产品的服务器分布非常灵活,扩容成本低,现在都会选择将服务器模块切分,进行微服务化改造,提升平台支撑能力。

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

作为社区类服务,虽然用户的热点并不是很集中,但数据量、访问量还是很大。大量用 CKV 存储,同时针对访问量非常大的问题,如说用户没有开通空间,游戏用户,会员等标记,之后均做一个定位,形成一个高访问量的模块即可。

二、微服务架构下如何构建一个运维管理平台

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

如下图,是一个架构体系:

上文讲述了微服务架构与巨石架构的差异,接下来了解如何构建一个运维管理平台。

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

接入层是 TGW,流量从它进、从它出;中间层,利用 L5 进行调度;

运维平台管理最重要的是应用。对于应用运维来说,系统的前端所接入的官网、中间的逻辑服务,后端的存储、缓存,分属于不同的运维。

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

存储层,因为每一个存储模块要分耗段,故加入 Access,从上到下把技术架构进行了统一规范,同时在组织上也通过接入逻辑运维层,进行标准化的维护。

把运维平台拆分成三块具体化部件对应到工作中。

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

统一框架对运维有什么帮助?

运维平台的内部应用、内部依赖是什么?——程序、配置文件、计算的资源

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

网络框架和业务逻辑 SO 分离管理、运维人员学习成本大大降低、框架稳定性极大提高、可跨业务统一维护、运维效率提升最高可达 10 倍。3.资源打包管理

是什么支撑运维平台作为一个互联网应用?——内存、CPU

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

如上图,资源打包管理是对开发出的程序包进行标准打包操作,一个程序开发出来有不同特征,有需要加银行参数,有需要依赖目录,还有需要前面准备工作和后续善后工作。

运维平台依赖的资源有哪些?——系统镜像

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

把它全部放在一个类似于包里面,装进一个盒子里。之后提供标准的操作接口,如安装、卸载、启动、停止操作等这些操作让它们变成有关联的。

这是CMDB IT资源管理系统要承载的,在自动化扩容、环境部署时,只有了解这些数据,上层系统才知道如何构建这个应用。很多运维团队,仅仅做到“工具化”,却没有跟“资源管理配置”联动起来。

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

资源打包管理对运维有什么帮助?

资源有效管理之后,是研发、运维这类的动作管理。如:版本更新,迁移服务、搭建测试环境等标准化的动作。

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

部署规范统一,再也不担心找不到、标准化了操作界面,极易学习掌握、支持前后置脚本做准备和善、进程级运转的所有资源的完整镜像。

在拥有资源和动作,达成自动化运维的闭环后。运维人员只需事前维护好准确的资源配置数据(CMDB),余下动作系统会自驱完成。如果把资源跟动作相混杂,每次运用都需要耗费资源定制专用的发布脚本、构建脚本。

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

4.资源登记—CMDB 虚拟镜像

除了资源跟动作管理,还有状态(监控)管理。每个公司都会有“监控”系统。这里需要强调的是意识的问题,因为在整个上层、应用层监控设计中考虑了“自动容灾切换”能力,所以我们不需要关注底层的监控。只要应用层没有告警,不用管底层服务器和机房是否挂掉。

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

资源登记到二级 CMDB 形成服务的虚拟镜像,除了传统基础配置信息,把一个模块依赖的资源,全部记录进 2 级 CMDB,形成一个模块的虚拟镜像。

我刚参加工作时,系统经常告警,需要半夜爬起来重启机器、删文件。现在运维只会接到通知,告知服务器挂掉,进行确认,不用实时处理。基于这个逻辑,在业务没有告警的情况下,我们系统就是正常的。

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

CMDB+资源=虚拟镜像

完善的运维管理平台能够合理的把资源、动作、状态协调管理。

再讲就是组件化,这里也有一个实例。假设我们现在要上一个网站,必须要有一个Web Server,不同的开发团队会有不同的选择,有人说Apache性能好,有人说NGINX比Apache强,有人说我用IIS,有人说那三个都是垃圾,我自己写的是最好的。

CMDB 虚拟镜像对运维有什么帮助?

这张图将上面那张简单的图做了扩展、细分。

很不幸,这个事情如果在2009年之前在腾讯确实是这样子的,百花齐放,这就导致我们没有办法维护。对运维来说,100个不同的Web Server我就要选择100次。

一个模块运转的所有资源的“完整镜像”、记录了模块运转所依赖的所有资源、不再需要文档说明。

最上面是面向运维,包含运维、研发者的服务目录和日常任务中心、状态中心的统一运维门户。

为什么我们不能要求一致?我们站在组件化的高度及要求下,同一种应用场景只能选一个,这次才能针对这种组件化去做到极致。

5.决策调度—自动化部署平台

下面是调度编排系统,产品扩展根据不同行业及其业务特性,做出不同编排需求,将这些不同的需求选项进行固化。

说完我们的一些框架化、组件化的举例,通过提出了这样一些要求,我们运维团队让我们每一个业务开发,开发出来的架构都基本上长成上面的样子了。还有一些组件TGW、L5这些东西没有介绍到,大家可以在搜索引擎上查到之前的分享。

在团队内部有织云自动化部署平台,从申请设备获取资源、发布部署、检测,进行测试,上线。在每个环节还有些细节步骤,如申请设备的时屏蔽告警事件,如发布时同步传输文件、如发布后检测程序的包进程是否启动,启动之后进行业务测试。

中间是运维平台的核心,执行层的系统。忽略灰色的传统API模块,现在我们运维日常使用的就是这个包括持续交付平台、统一监控平台和ITOA运营分析平台在内的立体化监控系统,通过它实现动作、状态管理。针对基础设施、平台系统、应用级、服务级甚至更高层的需求,提供精确度、优先级不同的接口。

今天我特别希望把这个理念跟大家完整阐述一遍。当我们的业务架构的层级都长成这个样子的时候,我们无论是对它做自动化运维也好,做监控也好,都很方便。

自动部署流程 23 步

底层是CMDB资源管理。传统CMDB管理对象,属于硬件资产。在云化技术发展之后,会越来越弱化。应用运维就不需要关注太多。这里CMDB包含了业务信息管理、应用程序包、配置、定时调度任务、流程、工具、权限、系统配置等基础资源。

刚刚上一个老师提到一点我觉得很有启发,一款应用我们应该怎么样去度量它?指标是怎么样子的?

如下图,是我们内部自动化部署的平台。相当于把这个进程开发出来以后,依赖的资源全部打包放在盒子里,把盒子里的东西放资源仓库中,有一些模块全部登记在 CMDB。

三、运维平台的微服务进化

腾讯内部是直播年。腾讯自己也在做直播,我们社交的直播光是APP估计两个数手不完,各种开发团队都在做直播,不同的直播怎么度量?

自动化运维体系

伴随着公司业务的发展,如何将正在应用的系统进行架构上的优化或者规划?

所以这时候,运维团队就占了很重要的决定性的作用。我出来说直播的质量、体系就应该这么看,我就给你定好了这种指标。

如果要部署一个模块 A 或进行扩容,可以人工触发或自动系统触发。

1.技术选型

我觉得有很多事情,不是说技术好或不好,而是看谁来做更合适。这时候运维作为一个公共的支撑的团队,它更有这种权利或者说它更应该去规范这样的东西,让我们对同质的业务场景可度量。

控制人工系统进行操作,把模块边上三个资源,由资源仓储部署在模块 1 上,通过 L5 系统进行一个注册,这个模块就可自动上线。之后会把一个模块登记回来,对它进行自动化操作,每一个方块是一个步骤,这个步骤执行过去之后是绿色的,执行失败是红色,没有执行是灰色。

首先,微服务跟基础架构的区别在于,微服务的组件拆分后是通过网络传输的。因此通讯标准要做出合理的选型。

前面两个部分,把我们的理念讲完了。我们要怎么样去落地?细节是什么样子的?下面有一个全局的图。

执行成功就可以看到,可以做自动化的扩容,可以做日常演习,还可以回收等工作。

微服务的架构,通常是异构架构。比如我们的平台运用了Python、JAVA、PHP等语言,必须选择同时兼容多种语言的协议。就像我们之前选用protobuf时,发现Python自带的库兼容Linux系统不成熟。在不同场景下,微服务的技术选型需要有较强的兼容性。

在我们社交运维团队,我们主要的运维产品有四大块:一个是织云,主要负责运维自动化方向,还有一个天网,还有我们的报表体系,专门用来做我们可度量的。最后还有一个手机运维MSNG,这里面包含了很多子的系统,今天主要是讲织云里面的一小部分。

全自动扩缩容

其次是语言的选择。微服务强调接口的稳定性,在保证服务稳定的情况下,可以自由选择熟悉的语言。

三、运维自动化的技术细节

运维规范的推进历程

2.微服务的规划

今天着重介绍织云,并且是织云最核心的功能点。有了标准化以后要做很多事情,才可以很轻松的实现运维工作的自动化。

如下图,是运维规范的推进历程。看起来是自然而然的过来。但实际上这个过程并没有那么容易。

单一职责原则:每个服务应该负责该功能的一个单独的部分。

光是在运维自动化里面,大家都说标准化、运维规范,那究竟是什么?今天特别想跟大家一起打开这个黑匣子,看一下腾讯运维的标准化是怎样的?

作者:

明确发布接口:每个服务都会发布定义明确的接口,而且保持不变,消费者只关心接口而对于被消费的服务没有任何运行依赖;

我们把业务架构又切分成不同的层,其实就是刚刚那个图的另外一种表现形式。五层,不同的层级,我们要做的标准化针对的对象不同的。

赵建春,腾讯社交网络运营部助理总经理、技术运营通道会长、专家工程师。04年加入腾讯,先后从事过研发、运维、数据方面的建设和管理工作,在海量技术运营方面积累了丰富的实战经验。

独立部署、升级、扩展和替换:每个服务都可以单独部署及重新部署而不影响整个系统,这使得服务很容易升级与扩展。

就像我们的设备层什么是标准?统一的机型、计算型的、内存型的、SSD,你是用关系型数据库,要用什么机型,要用大硬盘的,你是做Web Server的,内存标配一个就可以了。

3. 平台构建

特别是在虚拟化的今天,如果任由一个业务随意去选择它的机型,对于我们来说就是多了一种对象。在腾讯这么大的体量下我们没有办法容忍随随便便给我多增加一个运维对象。

通过下面的两个模块来讲解平台的架构。

所以我标红了几个字,就是要减少运维对象。像其他的业务层,你是IM型的应用,架构分布必须要三地、三活,QQ调度方案跟Q Zone的调度方案必须是一样的。所以我们做的一切的一切都是要减少运维对象。

1) CMDB系统怎样做简单的分拆,使之更容易维护?

减少完运维对象怎么去执行?在开发前,把整个产品的生命周期分成这么几块,在开发前、上线前、上线中、运营中,不同阶段,考虑的点不一样。

CMDB是一个有大量配置系统存在的可以进行查询、修改的数据库管理系统,它的内部包含模型管理,配置管理、自动发现。

开发前,知道业务形态长成什么样,可能用到什么样的组件、什么样的框架,这个时候基本上杜绝了写死IP的念头,或者对本地存储特别敏感的情况。

A)模型管理

其实我只是写出来,在真正运维工作中并没有说每次上线一个产品我们都去评审,时间也耗不起。

CMDB中,我们会管理大量随着产品技术站演进动态变化的资源和相异的动作,所以要独立出模型管理的模块,保证CMDB动态可调整。

当我们形成了这样一个开发和运维合作的文化之后,开发团队自己就会遵守了,并且在不同的阶段,我们提出了不同的要求。每个要求都会对应了我们运维的一个工具系统,去支撑它,就是说我们的标准化可以落地了。

B)配置管理

再来看基于我们互联网业务的架构层分层的特征,针对不同层次的对象去建设对应维护对象的系统,这些系统所产生的数据都把它结构化落地到我们的配置管理CMDB里面,这个CMDB就在整个运维自动化的过程中扮演了一个很核心的地位。

由于CMDB的信息敏感度高,很多公司要求,将敏感业务信息,特别是应用和IP这类关联关系的信息保存在里面。

CMDB层是什么东西?

C)自动发现

我们开发和运维先天性就有一些思考模式的不同。我们在CMDB中提出了一个概念,就是模块概念。为什么要有模块这个概念?可能开发人员看到他自己写的一套代码,这套代码对他来说部署在一个地方和部署在三个地方都是一套代码。

如果CMDB没有完善的自动发现机制,它失败的概率会非常高。就像传统CMDB有一个在严谨的审批机制运行下的配置变更流程。但是即使在配置跟现网一致的情况下,还是需要每半年进行一次资产盘整,对信息进行纠正。对于有海量业务的系统来说,没有“自动发现”能力的CMDB是不合格的

但是对于腾讯来说,我们所有核心服务都是三地三中心,对于用户来说,天津的用户量跟深圳的用户量不一样,北方的用户跟南方的用户量不同,容量不同,准备的设备数量就不同,提前规划的机房也不一样。

通过“自动发现”,去自动化采集服务器带宽、网卡速度、内存、磁盘空间、进程等信息,由CMDB进行管理。模块管理相对传统,“自动发现”是CMDB的核心,在同时管理数十万台服务器时,只能通过“自动发现”的探侦才能进行自动化维护。

这时候我们就提出了一个概念,就是模块。这个模块必须要按照运维的命名规则去定义它,存我们固定资产的信息,硬件配置、软件配置、运营设置,还有资源配置、流程配置、测试用例等。

2) 持续部署系统

存这些东西有什么用?

持续部署系统负责自动化发布。上图将持续部署系统的平台构建分为多个子模块。

如果CMDB一下子就能看到我们整个QQ的某一个功能,分布在天津、上海、深圳的容量分布图,或者说记录了这个模块的测试用例。那么,我们在做自动化的时候,我把它部署完就可以自动调它的测试用例,自动测试然后上线。实现这个目的,都是为了自动化做铺垫。

A) 构建管理

1、织云的运维思想

构建即以静态图片、业务程序、配置文件等为主的部署对象。根据DevOps中的原则,需要将一切版本化。所以需要一个构建库负责管理所有发布到生产环境的资源。

前面我们一直讲思想讲理念,前面两个部分介绍了标准化,以及标准化怎么变成我们的配置化,变成配置化之后最后一步就是实现自动化。

通过统一的构建库,对所有发布到线网上的数据进行标准化管理,以此可以快速在其他机房重建原系统等。同时它还拥有信息共享功能,过去运维发包之后跟踪困难,现在研发人员只需向构建库输入版本信息,运维从构建库中导出就好了。

实现自动化的过程,技术上看似很简单,无非就是把一堆结构化的数据通过配置,通过一些自动化的手段或者写批量的脚本,全部传上机器把它还原就可以了。

B) 任务管理

现在业界比较流行Docker,Docker的口号是BUILD、SHIP、RUN(构建、传输、传上生产环境执行起来),但是事实上有没有这么理想化?

任务库负责存储日常发布任务,满足自动化发布需求。曾经由于很多研发人员贪图方便,选择在现网直接更改系统,记录信息错乱变更很不利于任务管理的日常下发。

上图是我们在腾讯每一个发布要做的事情。事实上我框起来的这些内容Docker并没有帮我们解决的,编入业务权限怎么申请,这个可能很有腾讯特色。

常常是错误的,所以我们并不使用“任务下发完成之后,系统设置自动更新”这种设计。在无法信任上层管理系统的情况下,现网信息、数据必须实时扫描上报。

大家都知道,腾讯很多业务都是生长在QQ这样一个关系链体系下的,并不是所有的业务都有权限去拉QQ关系链的。访问QQ关系链必须要经过一个授权,这个是镜像部署解决不了的问题。但是我们织云平台必须要解决这样的事情。

为了保证信息的发布成功,必须以Agent上报的信息为准。因为配置信息存在大量变更入口,在无法保证唯一入口的情况下,不能想当然的设计系统。

此外还有一些Docker解决不了测试的问题,比如有人说我直接在测试环境测好打成一个镜像,这可以。

命令通道与数据通道是除了构建库、任务库、实例库之外的上层系统的基本构成。首先命令通道与数据通道需要分开管理。腾讯曾经需要将1G的文件发送到两千台服务器,频率达到一周一次,一次一周,不断重试、失败。后来将命令与数据切开,每次只传输几十K的命令脚本,服务器再也没有阻塞。

但是,我们QQ有些大集群上千台机器,每发一次都重启一次吗?这也不现实。测试怎么解决?灰度怎么解决?最后怎么上线?Docker也没有解决上线的问题。我们网站型的应用,最后还是要加到域外解析,加到DNS。怎么办?

开源方案部分问题依旧无法解决,像现在的异构网络,在混合云的场景下,必须保证网络互通,才能做到直连。大家可以选择自己去编写Agent练手,通过反向通道连接中心管理服务器去解决此问题。

为了解决它,所以我们内部整理了一个最适合腾讯社交的流程,如下图。

微服务架构下平台架构的底层基础服务

我们把整个自动部署的过程抽象成六大步,但其实分解开来是有23步,我们为了兼容带着业务特色的部署发布,带着我们运维要求的一些部署发布,还必须要有一个测试的环节,必须要有灰度的环节,最终完成上线。

1.名字服务

我们把我们的自动化的流程抽象成23步放在我们的资源平台,但是资源平台究竟起到一个什么样的作用?或者说它的特别之处在哪里?我们是用了七大点把它总结出来,如下图。

名字服务指通过配置文件中匹配的名字查IP端口的服务,可以选择合适的开源方案。如果自研的话,可以对服务进行灵活分区等。如深圳的服务器A访问在深圳、上海两地均部署服务的B,我们只需要在,名字服务中与CMDB打通,使用深圳的服务器访问深圳的IP,达到同城访问的效果。这个操作在开源方案中就无法完美实现。

首先它是要能传承的,所有的运维经验都是一种配置项资源存在CMBD里面,并且需要提出了很多标准,这些标准落地在我们管理不同对象的运维系统里面,最终是协作的。

  1. 状态监控。

这么多个特征组成整个织云的技术架构,我今天都不讲了,因为我觉得不需要这么多复杂的东西。

要求能达到接口即调用数据采集的应用层监控。

2、运维自动化的核心组件

通过访问量、成功率、平均时延这三个核心指标,低成本把握绝大部分需求。以访问量为例,当访问失败率上升告警时,直接触发名字服务联动,将故障节点自动摘除。

接下来想跟大家深入一点的去交流自动化运维最核心的CMDB、流程系统,把我们的一个一个的工具通过我们的传输通道能串起来。

3.负载均衡。

只要你实现了这些,你的运维效率就提高很多,不需要完全自动化,不需要无人职守。为什么要无人职守?本来就500台机器,10个人,每个人50台机器是很容易。

当系统规模扩大,节点剧增时,增加中间代理的方法会增加系统内部压力。

上图是我们最重要的CMDB的技术架构,归根结底就是一个关系型的数据库。

如果落地到Agent,通过名字服务查询IP列表,合并状态信息,均衡节点请求,可以更好的达到负载均衡。

我们要存哪些配置项来设计表的结构,并且可以提供接口化,让我们的工具系统可以调度。

负载均衡的极端就是容灾,正常情况下根据性能状况保证每个节点处理合适的请求量即可。

如果要做部署包的系统,首先要知道操作的对象是谁?这个对象的模块名是谁?我刚才提到很重要一点,我们统一了开发和运维的语言,操作这个模块每次部署需要装哪些包?发哪些配置?近期都存在我们的CMDB数据库里面,拉出来调我们的流程系统,调我们的传输工具,把这些资源推到我们的生产环境。

这三点是运维平台或业务生产的系统中的核心能力。包括腾讯在内的运维平台都是基于这三个服务闭环去运行的。只有在做到这三点,才能解决系统异常,维持系统的正常运转。

推完之后,要启动流程系统、启动步骤、测试步骤、灰度步骤、上线步骤,一步一步串起来。这就是为什么说自动化运维很重要的一个核心就取决于我们有什么样的一些料可以做这道菜。

微服务运维平台的迭代重心

接下来是流程系统,现在业界没有一些特别适用的开源方案,但是我们还是在做流程系统,今年又在做一版新的,希望做得更强壮。

其实我们在平台构建的时候,在整个的平台进化的过程中,其实是要有优先级,要有取舍的。总得来说,优先要解决我们的瓶颈问题。 然后是平行扩展的能力,还有考虑服务复用的能力,甚至是一些开源的解决方案的利用。但是开源这个东西,我从来不觉得是说大家把一堆的开源工具用在一起,能够形成一个很好的一个运维平台。

假设我们写了100个脚本,只是一个大的脚本,把这100个脚本串起来就是我们流程系统。

大家应该是把这些开源的能力,这些一个个的微服务,核心的这个架构还是必须要有自己的控制力在这里。比如:监控。很多开源的系统,它是更偏重于执行层的工具,但是核心的CMDB,核心的流程控制还是需要我们去建设的。

它可以通过一定的数据触发执行,什么时候这个流程跑什么样的工具都是有一些决策的,或者说当某个工具失败了,究竟是重试还是跑分支流程,还是说终止告警,这就是我们的流程系统。

我们之前提供了一些函数头,里面的工具写好自己的逻辑,能够通过一些公共输入输出的函数方法,让这个工具本身处理完的输入输出能够被流程理解,能够传给下一个工具。

主要核心就是做了这样一个事情,架构做成什么样子不重要,所以今天我画的是原理,并不是架构。如果大家想看流程系统的架构,可以搜一下我以前分享过的运维自动化的PPT,里面有那个架构。

最后是传输通道,怎么样让流程串起来?

最终要操作生产环境的时候要怎么样做?在腾讯我们用一个C/S的架构来实现我们叫做命令通道的东西,可以传文件,可以执行命令。

大家写一个C/S,自己配一个协议,传一堆文件,它能解析指令、执行,找到对应的文件执行完,这个就是我们的传输通道最基础的一些功能。

但是传输功能是不是仅仅这么简单就足够了?

基于安全性考虑,我们还需要去关注我们的源IP权限,防止被黑客攻击变成肉机之后,随意发起批量操作,有损大厂名誉。

其次是用户身份的健全,QQ的运维不可能操作QQ音乐的设备,当然如果兼岗是可以的。我们会对执行的命令做一些解析,防止高危操作,防止某个人失恋了要删数据库走人。

还有约束目标的IP,对我们生产环境管理的理念是息息相关的,少数的像系统运维,因为他负责整个10万台机器,一次1万台也要分10次处理,而不是说一个命令把10万台搞定,因为人总会犯错的。

做完这些CMDB流程系统,还有传输通道,如果大家所在企业的规模或者你所管理的设备量不大的话,效率已经提到很高了。

大家可以想一下,我要操作的对象都存在配置管理里面,配置好一个流程做执行,就是先安装包,再去启动相关的包,再把测试程序调用一下,把灰度接入两台在域名上,然后去验证一下没有问题,然后再接着全量上线。我们点几下按纽就解决了,不需要完全无人职守。

但是在腾讯这个体量还是不够,所以我们做了无人职守,做了无人职守还要做到这七点:你的设备怎么管理?究竟怎么样决策?应该用哪个设备?

还有我们的智能决策,依赖什么样的数据决策,应该起什么样的流程?

假设我们有一个Web层有10台机器同时挂了8台,当只挂了一台时我们可以不马上发告警,因为有一个决策系统在。

我知道Web层的机器无状态,我直接重启它把它踢下线,但是又挂、又挂,挂了5台时候决策系统就可以做一个决策,它的IP数量超过30%的不可用的时候,不能够再不发通知了,这个时候就应该发通知给运维人员,让人来干预这个事情,这是我们的智能决策。

还有我们的自动测试、灰度放量。

灰度放量基于怎样的策略来灰度放量是灰度管理系统考虑的。还有变更体检,有没有基础指标,CPU,你新上线的设备是不是跟现在设备CPU曲线吻合,或者说有没有一些业务监控能够告诉我,这就是变更体检要做的一些事情。

还有日志通知,自动化系统跟监控系统联动的时候,就像做一个变更,那边有业务告警,这两个数据一关联起来,可能业务告警就不发了,那个取决于监控系统那边告警策略建设。

3、实战案例

做完了这七点,可以实现什么状态?上面是腾讯QQ会员的一个真实案例,大家如果有用腾讯的产品肯定都收过腾讯给你推的红点。

有些人处女座一定要点那个红点,马上请求量就来了。这一点对于运维来说就是一个恶梦,如果没有提前准备容量,业务请求量就会飙高。

但是在无人守职的运维能力下,你也什么都不用做。你会收到一条短信提醒,无论是聊天工具的弹框,还是手机短信提醒你,现在正在有一个自动扩容在执行,它自己就跑完了整个流程。

因为我们把最核心的那三个部分,还有辅助它能实现最后一步七步做完,在自动化这一块是可以说走在到了人生的巅峰。

最后想跟大家一起小结一下:今天分享的主题没有把它铺得特别大,大家回去可以看一下,我们有什么样管理对象可以做成标准化,要怎么样把它框起来,框起来之后针对这种标准的场景怎么样做到最高效的运维。

我们的标准化、配置化,再把流程系统,把我们对标准对象要做的一切连接起来,最终就可以实现我们的运维自动化。好了,今天的分享讲完了,谢谢大家。

本文由澳门威斯尼人平台登录发布于服务器&运维,转载请注明出处:我斩获了这5把,优维科技EASYOPS

相关阅读