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

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

期间，他带领运维团队负责QQ延伸出来的各种社群的运维和维护，包括QQ空间、QQ音乐、QQ会员、QQ秀等一系列的QQ产品。团队89个人，维护了10万家服务器。经历的大事件有：

• 红米在QQ空间首发时，90 秒卖出 10 万台设备，获得1亿点赞；

• 天津大爆炸事件，把天津 2 亿多活跃用户，从天津快速调到深圳以及上海；

• 春节红包准备工作，2016年比2015年的红包访问量增长了10倍+，快速的扩充了 5000 台设备，最高访问量达到 477 万次/秒。

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

运维团队的五个“杀手锏”

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

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

L5 有由 L5、DNS 和 L5、agent 两部分构成。CGI 通过给模块提 ID，根据模块下设备的成功率和延迟情况，通过 IP+PROT 给 CGI 一个反馈，访问之后，通过成功率和延迟情况，把数据上报给了 L5agent，然后做统计数据。

当发现失败率特别低的时踢掉。当发现成功率和失败率有一定下降，会把访问权重降低，从而达到容错和负载均衡的作用。

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

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

• 减少了 80~90% 的日常故障；

• 不再需要频繁的变更 ip+port（也是故障源）；

• 同过名字便利的服务上下线；

• 通过权重灰度上线；

• 模块访问关系可帮助定位根源故障；

• 接口的延迟和失败率可用来监控；

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

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

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

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

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

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

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

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

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

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

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

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

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