作者介绍
赵建春,腾讯社交网络运营部助理总经理、技术运营通道会长、专家工程师。04年加入腾讯,先后从事过研发、运维、数据方面的建设和管理工作,在海量技术运营方面积累了丰富的实战经验。
十年不苟且的运维之路
加入腾讯已十年的运维老兵,回顾这十年:
2004年:加入腾讯,做贺卡开发;
2005年:加入QQ空间开发团队,负责留言版模块;
2006年~至今:公司组织架构调整,接触运维工作。
期间,他带领运维团队负责QQ延伸出来的各种社群的运维和维护,包括QQ空间、QQ音乐、QQ会员、QQ秀等一系列的QQ产品。团队89个人,维护了10万家服务器。经历的大事件有:
红米在QQ空间首发时,90 秒卖出 10 万台设备,获得1亿点赞;
天津大爆炸事件,把天津 2 亿多活跃用户,从天津快速调到深圳以及上海;
春节红包准备工作,2016年比2015年的红包访问量增长了10倍+,快速的扩充了 5000 台设备,最高访问量达到 477 万次/秒。
不要让自己变成一个救火队员
作为运维,最重要的是先保证自己做的系统可靠、不会轻易出错,不要让自己变成一个救火队员。可靠之后,就要用更多时间去解决效率问题,让工作变得更加高效,追求更高的目标。
对团队工作帮助最大的是什么?
资源管理:把写出来的程序和代码,进行清晰划分和分类,对每个资源采用不同形式进行搭建;
容错方案:在维护海量服务、运维过程中出现故障时,确保不能影响项目服务,服务器要做到及时处理;
统一架构 CMDBA:把一个业务模块上所有依赖资源全部登记进去;同时如果做快速决策和调度,还需要有效的监控。
DLP:内部定义的一个非常关键的监控,这个点发生后,可以知道哪里出现故障;
入口监控:告知出现故障的根源在哪儿,容错方案的 L5 是用来解决容错、灰度,路由等。
运维团队的五个“杀手锏”
世界上管理服务器最多的系统
运营管理系统管理了上亿服务器,脉络非常清晰,根本不会出现混乱。L5 系统(上图)也类似于 DNS 系统,有一排能提供的服务模块,从而解决的单点问题。
L5 如何做容错?
L5-主机/接口级的容错原理
L5 有由 L5、DNS 和 L5、agent 两部分构成。CGI 通过给模块提 ID,根据模块下设备的成功率和延迟情况,通过 IP+PROT 给 CGI 一个反馈,访问之后,通过成功率和延迟情况,把数据上报给了 L5agent,然后做统计数据。
当发现失败率特别低的时踢掉。当发现成功率和失败率有一定下降,会把访问权重降低,从而达到容错和负载均衡的作用。
可以注册一个模块,加多台设备,形成容错效果。如发现一台机器失败率很高,就把它踢掉。它成功率恢复过来,还可以再加回来。
新加一台服务器设计它的权重为 1,假如之前的是 100,可以逐渐上线。还可以给它一个得分,得分下降的时候,快速把它踢掉。L5 具有灰度、容错、路由、负载均衡的能力。
L5 对运维团队有哪些帮助?
减少了 80~90% 的日常故障;
不再需要频繁的变更 ip+port(也是故障源);
同过名字便利的服务上下线;
通过权重灰度上线;
模块访问关系可帮助定位根源故障;
接口的延迟和失败率可用来监控;
集容错、负载均衡、路由、灰度、监控能力于一身。
团队里有上千号开发同事,每年会有大量毕业生加入,也会有社交同事。进来以后,都希望为平台做更多的代码贡献、展现自己的技术实力,亦或是提高自己。
那么,问题来了。在开发过程中,如下图,有管道、消息队列、信息文件锁、记录锁、文件影射内存、还有迭代服务器 Select poll Io 等,这些是用各种各样技术组合生产出来的代码,交给团队维护,数以万计不同性格的服务器,要掌握得非常好,了解它的工作机制和原理,更好的维护它基本上是不可能的。
那怎么办呢?把网络通讯部分列成一个标准框架,提高它的通讯效率,统一维护。
统一框架
业务逻辑部分用 SO 动态库方式编写与框架分离部署,类似 Web 服务器上的CGI。接入层用 QZHTTP,逻辑层是 SPP 和 SF 的框架。
作为社区类服务,虽然用户的热点并不是很集中,但数据量、访问量还是很大。大量用 CKV 存储,同时针对访问量非常大的问题,如说用户没有开通空间,游戏用户,会员等标记,之后均做一个定位,形成一个高访问量的模块即可。
如下图,是一个架构体系:
接入层是 TGW,流量从它进、从它出;
中间层,利用 L5 进行调度;
存储层,因为每一个存储模块要分耗段,故加入 Access,从上到下把技术架构进行了统一规范,同时在组织上也通过接入逻辑运维层,进行标准化的维护。
统一框架对运维有什么帮助?
网络框架和业务逻辑 SO 分离管理、运维人员学习成本大大降低、框架稳定性极大提高、可跨业务统一维护、运维效率提升最高可达 10 倍。
如上图,资源打包管理是对开发出的程序包进行标准打包操作,一个程序开发出来有不同特征,有需要加银行参数,有需要依赖目录,还有需要前面准备工作和后续善后工作。
把它全部放在一个类似于包里面,装进一个盒子里。之后提供标准的操作接口,如安装、卸载、启动、停止操作等这些操作让它们变成有关联的。
资源打包管理对运维有什么帮助?
部署规范统一,再也不担心找不到、标准化了操作界面,极易学习掌握、支持前后置脚本做准备和善、进程级运转的所有资源的完整镜像。
资源登记—CMDB 虚拟镜像
资源登记到二级 CMDB 形成服务的虚拟镜像,除了传统基础配置信息,把一个模块依赖的资源,全部记录进 2 级 CMDB,形成一个模块的虚拟镜像。
CMDB+资源=虚拟镜像
CMDB 虚拟镜像对运维有什么帮助?
一个模块运转的所有资源的“完整镜像”、记录了模块运转所依赖的所有资源、不再需要文档说明。
决策调度—自动化部署平台
在团队内部有织云自动化部署平台,从申请设备获取资源、发布部署、检测,进行测试,上线。在每个环节还有些细节步骤,如申请设备的时屏蔽告警事件,如发布时同步传输文件、如发布后检测程序的包进程是否启动,启动之后进行业务测试。
自动部署流程 23 步
如下图,是我们内部自动化部署的平台。相当于把这个进程开发出来以后,依赖的资源全部打包放在盒子里,把盒子里的东西放资源仓库中,有一些模块全部登记在 CMDB。
自动化运维体系
如果要部署一个模块 A 或进行扩容,可以人工触发或自动系统触发。
控制人工系统进行操作,把模块边上三个资源,由资源仓储部署在模块 1 上,通过 L5 系统进行一个注册,这个模块就可自动上线。之后会把一个模块登记回来,对它进行自动化操作,每一个方块是一个步骤,这个步骤执行过去之后是绿色的,执行失败是红色,没有执行是灰色。
执行成功就可以看到,可以做自动化的扩容,可以做日常演习,还可以回收等工作。
全自动扩缩容
运维规范的推进历程
如下图,是运维规范的推进历程。看起来是自然而然的过来。但实际上这个过程并没有那么容易。
本文整理自WOT互联网运维与开发者大会主题分享《如果运维可以重来一次》,首发于51CTO技术栈订阅号。
近期热文
近期活动