------------------------------------------------------------------------------------------------------------------------

【转载】51CTO博客：http://mp.weixin.qq.com/s/0CJljYZ2yL9ogL1idqqBjg

虽然文章好多地方不明白，但是觉得写的很好，拿来学习、存档。感谢51CTO博客的整理

------------------------------------------------------------------------------------------------------------------------

回顾运维十年，如有一次重来的机会，什么才是最重要的？什么才是团队需要优先做的？才能在未来支撑我们更好的前行。

注：本文整理自 WOT互联网运维与开发者大会 主题分享《如果运维可以重来一次》

“十年"不苟且的运维之路

加入腾讯已十年的运维老兵赵建春，回顾这十年：

• 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 系统

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

运营管理系统管理了上亿服务器，脉络非常清晰，根本不会出现混乱。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 系统进行一个注册，这个模块就可自动上线

。之后会把一个模块登记回来，对它进行自动化操作，每一个方块是一个步骤，这个步骤执行过去之后是绿色的，执行失败是红色，没有执行是灰色。

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

织云全自动扩缩容

运维规范的推进历程

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

赵建春

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