致运维——运维军团告诉你如何走过七年之痒

前言

七年多的成长，从最初2～3人小分队到日益壮大的运维军团，发展至今已是一个集系统、开发等运维岗位的综合职能中心。我们也创造了多个项目自研技术包括开源项目以及核心运维应用等。例如自建CDN系统、网络分析预警平台、运维自动化平台等。这一切果实的背后少不了风雨洗刷和烈日暴晒，每一次痛痒都是通往成熟的养分。

发展至今，我们团队业务现状大体概况如下所示。

1. 管理 万级 服务器。

2. 管理 百 + 游戏项目。

3. 自建CDN平台承载能力达 T级。

在自建自用领域是业界领先水平，响应能力甚至可以媲美商用CDN

4. 游戏业务单服在线 万级。

这样的量级并不能与单纯的web业务来比，游戏app的运行比web复杂的多。考验运维的重点在数据库架构和高可用性能方面的优化管理能力。

七年，一个据说会痒的数字，爱情有七年之痒，团队也有七年之痒，其实，“痒”一直都在，挺过去就是新生。

运维时代

时势造英雄，感恩环境、感恩和团队成长的所有成员。我们从钻木取火到石器时代，再到自动化和服务化。

一、原始时代 —“守”

（2008-2009）

遥想7年前， 那是一个 “赤膊上阵、钻木取火”的时期：大量的手动、人工作业；整体运维复杂度也不高，可替代性强。没有海量、高并发的运维场景，自然也没有应对高并发的概念。

公司正值创业初期，技术的职能分工还不明确，运维还没有专职，一些碎片式的运维工作例如机器配置、扩容、维护更新，都是开发兼职。

如果要问运维是干嘛的？当时大家的回答应该是修电脑的。。。

1 主站资源运维——为服务器而生

公司主站当时已经有一定用户积累，需要大量的服务器和带宽来支撑网站运营。于是运维场景开始诞生：大概有100台服务器，由2-3人专职。

由于cdn技术在当时发展还不够成熟，还没有边缘节点cache、中间层、源站的概念。我们的页面、资源服务器是作为单个节点存放静态资源直接面向用户访问。 由于整体带宽量大，单机最高带宽峰值500M（可能现在大家觉得500M不算什么，可在当时那会儿一家中小型做ISP接入的idc公司总出口带宽实际也才500M不到），于是我们开始采用dns轮询作为最原始的负载均衡技术来承载海量带宽请求带来的压力。原始架构场景就在这时候基本定型下来，既简单又实用，也和boss的理念相得益彰。

但随着业务发展，这个原始架构也带来了一些问题：

1）dns轮询不均；

2）零自动化；

3）磁盘故障率高；

4）监控不成熟；

5）内部协同靠“喊”，文档传承意识薄弱。

那时候100多台的服务器节点，当时还没有在Windows下形成比较好的业务层监控系统，只能一个个资源去下载拨测。更让人吃惊的是我们的领导之一，时常也会深入一线业务，孜孜不倦地对100多台服务器、数十万个资源下载点进行人肉拨测，而且总能发现一些故障点以及问题改进方法，作为一个拥有运维背景的leader，这一份深入业务的钻研精神令所有运维人都甘拜下风。 

领导者的行为比语言更重要，正是leader这份以身作则、坚持修炼运维领域的精神，在我们军团内部得以流传，一直被视为新进人员的传教模范。

这个时期的整体大环境，技术资源确实比较匮乏、运维相关资料也寥寥无几、甚至连熟悉linux系统的人都不多。加上整个团队正处在野蛮生长的幼年时期，运维理念、经验都比较零散，没有形成成熟的知识体系。

纵使存在种种问题种种难关，踩过无数的坑，也总有那么几次会怀疑运维的人生是否灰暗：没有自动化的实现，没有完善的技术体系，难道运维的宿命就是敲着键盘的IT民工？但合则同谋，所幸的是，团队还是聚集了志同道合的一批人，始终坚守运维理想。处于原始时代的我们一起坚守着，在团队成员分布于各个工作室的情形下，依然把战斗力提升上去了。

二、石器时代 —“攻”

（2010-2012）

2010年开始，Linux开源工具开始崭露头角。 监控、自动化、批量管理等等在行业内都逐步开始有了成熟的解决方案。

我们开始拥抱Linux开源，把开源工具逐步应用到生产环境。 lnmp基础环境、shell自动化、nagios、cacti、puppet、salt、ossec等等这些工具都开始慢慢成了标配。

“黑猫、白猫，能抓到老鼠就是好猫”。虽是草莽出身、没有华丽的理论包装，也不纠缠于每一个技术的底层原理，但我们必须要把技术转换成生产力。满足业务需求、解决业务场景中的实际问题才是最核心的结果导向。

1. 页游巅峰

这个时期，整个页游市场如雨后春笋般迅速崛起，从研发到运营形成了一个自产自销的页游产业链。 一直到2012年，迎来了到迄今为止页游最巅峰的时代。

这是一个全新的行业领地，业务场景和需求都在不断变化。对运维来说，也是在探索期，没有前人的经验可以借鉴，也没有一成不变的模式。只有摸着石头过河，在工作中慢慢琢磨，朝着结果导向步步为营，逐步进攻。

当时公司页游主要分成开服型游戏、大世界游戏。两种游戏类型特点不一，随着巅峰时代业务爆发式的增长，都给运维带来了巨大的冲击和挑战。

1.1 开服型游戏

初期是传统运维的模式，单元开服型给团队带来的内耗相当大。

特点：

1）多平台联运模式，开服频率高。

如一爆款游戏高峰期间，单平台单日最高开服2-3个，单日总开服数高达200个 

2）此消彼长：新服开启，老服在线和留存迅速下降，合服速度相对较慢

3）用户分布复杂度高、攻击频繁

群集开服力挽狂澜

基于开服型游戏的特点，如果按照传统运维，开一个服提供一组机器的思路，会导致以下问题：

• 复杂度高、效能低下——高频率的开服需求

• 资源冗余，严重浪费——新服开启、老服在线下滑，大量的老服、死服占用机器资源

• 维护久、内耗大——针对区服迁移做硬件整合的需求（俗称硬合服）

这些问题如果用今天云时代的思路来审视， 可能大家会觉得是很小儿科的问题，用虚拟化之类的方案就可以解决。我们当时也考虑过用虚拟化如Xen，但由于方案不够完善在实践过程中也暴露了不少缺点。一方面是物理机虚拟化带来的硬件性能损耗，例如虚拟网卡丢包、虚拟机磁盘iops抢占互斥等等。另一方面虚拟化带来的资源复用还不足够高，基于开服的自动化支持也不够完善。

“能否用更高的硬件配置来换取单服务器部署更多的区服，以最大化提高物理机器的资源复用？”这是群集开服架构最开始的念头。随着在业务场景中的检验和论证，群集开服架构这个时候逐步完善并成型。

群集开服架构里是以单个游戏服逻辑进程作为集群的子单元，多个子单元集中在一个物理服务器里；这样可以充分利用单台物理服务器的处理能力。同时搭载我们自研的游戏运维统一管理后台做群集开服的统一智能调度，提高服务器集群架构的高可扩展能力，打破了以往一个服一组机器的模式。

群集开服架构图

架构优点

1 在线负载性能提升——高配服务器同时满足IO密集 cpu性能，足够支持2个以上新服

2 服务器压力减少——合理的利用WebGame开服此消彼长的特点，新服开启时老服在线下降

3 开服效率大大提高——无需为新服另外准备硬件配置环境，结合游戏运维统一管理后台的一键开服即可高效满足开服需求

4 节省维护时间——无需硬合服，维护内耗降低，提高线上业务的稳定性

5 可复制性高——可以大面积推广应用、扩展性强

6 硬件及IDC支出成本降低——大大减少服务器的采购数量

开服模式效能比对图

启用群集开服架构后，单群集组机开服最少比例为：1:15（百分比越低效能越高）；开服效率大大提升，成本降低也超过一半以上，这得益于群集开服架构对资源的充分利分。

1.2 大世界游戏

大世界游戏和传统的端游有点类似。 开发跟据需求设计了游戏的内部架构。

不同的游戏进程模块化区分：如gateway（网关）、gameserver (主游戏逻辑)、login（登录）、聊天、DB存储等等提供游戏内不同的功能服务。

不同的服务模块设计初期要求集群化的思路：即分布式扩展、负载均衡、故障转移这些都是标配。

运维需根据不同的服务模块，做服务器相应的硬件配置选型。如gameserver 一般为cpu密集、 gateway主要网卡密集（软中断压力）、DB一般是IO密集。

跟端游表面区别是 ，用户入口由以前的客户端变成了web网页端。

 

大世界架构图

随着用户的爆发式增长、系统访问量的增加，高并发的用户请求、海量的数据存储，变成了最大的技术挑战。

数据库压力：存储量到T级，DB服务器IOPS吞吐高到万级。数据库存储和压力是当时最大的难题。

1 硬件调优：升级磁盘的raid阵列、更换ssd 换取更高性能的iops吞吐

2 系统层调优： mysql配置my.cnf、内核调优、文件系统 。 这些是标配，但杯水车薪

3 业务逻辑方面：分库 按照业务逻辑水平横向切分 ； 分表 日期切表或递增切表

4 中间件缓存： mysql前端加redis做缓存， redis做主从。主库纯内存储备、不落地。 从库用于备份，aof策略落地。

2. 网络优化-BGP中转重连

用户量级到了10W级，游戏玩家分布全国各地，加上国内网络错综复杂。会存在因为种种网络问题导致部分玩家连不上游戏gateway的的端口。

为此与客户端程序员一起讨论研究了解决方案，并测试了方案的可行性。

bgp转发逻辑图

找一台优质网络的BGP机房的中转服务器，做tcp转发。结合客户端的逻辑判断处理 如果玩家连接不上游戏服gateway的端口则尝试重连。 即尝试重连bgp中转，以增大游戏联通率。

3. APM性能监控

那个时候还没有apm的概念，但是由于玩家量级大，大世界游戏模块结构相对复杂。 

玩家到游戏的整个逻辑交互过程 都发生了什么？ 每个逻辑交互的步骤 能否把过程数据化、透视化？

于是后台统计的做法：跟客户端研发协商，把游戏内部的逻辑交互埋点打日志，通过接口统一上报至APM后台，APM后台主要做web可视化呈现。

由于业务在这两年里飞速增长，经营模式从原始时代的简单粗放调整优化成系统化的架构管理。这一切看起来可以恣意调整、修改，改变架构的成本似乎相当低；现实却不是这样，在实际攻克架构转变的过程中有些问题会在你想象不到的地方冒出来，死死拖住你。这是一个开始半自动化的工具年代，页游巅峰时期攻克的不仅仅是以上架构调整的难关，还有一些运维管理后台系统也开始逐步建立起来。

三、解冻时代 —“转”

（2013-2015）

2013年是游戏行业风云变幻的一年，源于手机功能和移动互联网的发展，手游行业从“屌丝”瞬间华丽升级为“土豪”，这一颠覆的转变只用了一年的时间，这也是游戏行业未来的一个蓝海，但无数同行却撑不过“黎明前最黑暗最黑暗的那一刻”。如此的转变将无疑改变了运维开服的架构规划，手游与页游在系统设计架构上本就有着明显的区别。

2013年无疑是一个值得纪念的时期，也是我们团队历经变革的一个转折点。如果说一个人的改变是凭着毅力和努力，那么一个部门的转变，则是凭着团队所有人的凝聚力和执行力。

同年6月正式成立了运维中心职能部门，首当其冲的是要整合原本分散的、各自一套的、不统一不规范的运维工作流程，SOP体系因此应运而生；其次是开发与运维关系的转变，要实现D/O分离与协作；再者，为了“精益求精”，实现运维大数据、运维自动化的战略，以便解决业务快速迭代导致人力、成本提升带来的困扰，我们成立了《运维开发部》，两年时间里，开发了蓝海系统（运维开服自动化）、CDN统一管理平台、公有云平台等一系列运维自动化后台。

1. SOP体系 标准化

我们把日常工作的经验和技术碎片汇集成规范、流程，形成能够快速迭代、实现统一管理的方法论。

2. D/O 分离与协作

“D/O分离与协作”是指开发与运维分离，相互之间不干扰，各自负责各自的业务需求，主要是能做到权限管理上的独立管理。然而在一个共同维护的业务环境下，运维与开发之间依然是要相互配合以实现业务需求导向，共同完成任务。协作既不与分离原则相抵触，又可增进运维与开发之间的默契。最大的好处在于能提升生产效益，这也是未来运维服务化的一个目标理念。

3. 蓝海系统 自助自动化时代

众所周知，运维是公司产品线上运营的核心技术部门，在满足产品快速迭代规模迅速扩张的要求下，从早期的人肉执行原始时代，发展到今天的运维自动化、平台化的时代，经历了无数的苦逼与辛酸，在这个过程中运维也积累了很多项目管理经验以及自动化运维技术，随着技术的更新和业务的发展，我们重新定位了需求，以自助化、自动化、定制化为核心思想打造了一个全新的平台——《蓝海系统》。另外我们建立了完善的运作体制，在业务当中开发技术与运维技术需要做到很好的衔接，从而明确上线的操作规范，相互配合协同。到未来我们希望提供的不再只是基础的运维交付能力，而是更契合业务的运维服务化、高度自助化。

4. CDN统一管理平台

CDN项目成立之初，我们遵循的是简单高效的管理方式，写了大批量的脚本来实现各个域的带宽检测、调用检测、调度优化、批量更新和内容推送刷新管理等功能，后来业务场景需要慢慢对外，就开始了初步的cdn后台开发，提供简单的内容管理功能。随着我们业务规模的扩大以及视野的开拓，我们需要让后台功能更加的透明化，可视化，分析可以更加的细腻(颗粒度)，把它当成一个对外产品，可以持续地进行交付。这个产品分为前后端，后端由运维进行日常维护，前端交由用户使用，到现在系统运维申请CDN已经实现完全自助化。

后端管理界面

前端界面

CDN后台要做到更小的颗粒度，就离不开原始日志，而对于一个庞大的CDN系统来说，这个日志量是海量的，我们在日志管理方面采取了ELK（ElasticSearch、Logstash、Kiabana）+redis的架构，目前日志插入量高峰达到70K/s，每天20-40亿条的数据已经成为了我们CDN后台从简单的日志统计到现在的大数据分析转换的基石。

当然在搭建整套系统的过程当中也遇到不少的坑：

1、配置rsyslog的缓存队列时，未区分main和action队列，导致系统日志积累

2、logstash处理逻辑过多，导致索引性能低下

3、salt经常发生节点无响应的情况、旧的salt因为消息中间件版本过低的原因丢失数据等

4、各频道日志数据过于庞大, 前端搜索耗时较长等等一系列的问题。

大数据日志架构参考图

5. 公有云

公有云平台立项之初，其实是一脸懵逼的，部门在前期并没有做过一些技术储备，而网上一波流的云技术，但是实际上很少公司会自建云应用在大规模生产环境。大部份还是所谓技术牛人的“实验室环境”。但是说做就做，我们从部门中抽调了8名精英利用了不到一年的时间完成了这个项目—— 蓝云BlueCloud。在建立之初我们针对了各大云架构进行了对比，最后选用的方案是OpenStack，因为OpenStack拥有优秀强大的社区，而且最重要的是它以python语言为主的开源框架，我们可以很方便地实现二次开发。

一开始搭建基础系统时，遇到了很多技术问题，尤其是作为云底层的存储系统。我们先给它设一个小目标：实现150个实例，运行1500个游戏服。在有限的条件下保证最基本的IO读写能力。我们的存储架构简单粗暴，没有什么万兆网卡，万兆光纤交换机，全系列SSD硬盘啥的！领导的指示是“你只能使用原始的SAS万转硬盘，千兆网络......”，对于要支撑150个实例来说，这“家产”简直属于贫困户。没办法，领导的指示下来，只能使出浑身解数搞技术突破了。我们云团队花了大量的时间在研究和测试存储的最合理方案，终究还是凭着坚持的毅力创造出了我们的孩子。

存储方面，我们使用openstack的好伴侣，大ceph分布式存储系统。ceph的出现就是冲着openstack来的，他能够与openstack实现无缝的对接。性能嘛！那得见仁见智了。

我们最终的测试结果（单节点）:

或许有同学会发表疑问：“对于一个计算节点来说，这数据也并没有什么大不了的，甚至比单机Raid10的性能还差。” 对的，但是不要忘记这是分布式存储，它有着高可用性和高扩展能力，还可实现线上无缝热迁移。

如果只是搞一批Raid10的本地存储服务器作为计算节点，那玩的只能算是虚拟化，并不是“云”。

细心的同学还会发现，由于我们使用的只有千兆网络，理论最大的吞吐能力只有128M/s（无损极限）。但是测试结果”写入“却有220M/s，这是为什么？

这是因为使用了双网卡绑定（Bounding）技术，利用多个网卡做流量合并，但这仅仅只有写入（即接收数据）的情况才能实现，读取（即发送数据）时只能保持千兆不变。这也是Bounding技术的一个特性，目前还没有找到解决办法。另外要实现以上结果我们还做了一件事，就是把双SAS万转硬盘做成Raid0作为ceph的一个OSD节点，提升其写入能力。这里我们并不担心Raid0本身的风险，因为ceph本身就是一个含有多副本的高可用存储（至少设置了3份副本），即使某个OSD节点的Raid0出现故障，并不影响到全局运行。

方案总结（测试环境）：

平台：ceph v0.89

网络：双1G Bounding (RX=2G,TX=1G)

设备：SAS-600G Raid0（IOPS=2~3W,W=400M/s）

副本：3份

节点：12个

上层业务决定基础设施需要足够的灵活性，为了满足数十款爆款项目的上线快速部署、迁移等，需要对基础资源进行高效管理和容灾容错能力。云计算可以从容应付这种“快部署快回收”的应用场景，还可以整合底层物理资源，充分发挥每个独立单元的性能，从而能够灵活分配和管理业务。因此搞“云”是志在必行的事了。

云平台（前端界面）

云计算时代给大家带了很多机遇，同时也带来了很多挑战，也让运维从业人员开始思考很多问题。

这是一个解冻时代，怎么突破重围、与时俱进，怎么在手游行业一展身手，利用手游趋势去改造去升级团队。从外人的角度来看，这或许很正常，是转型必经的阵痛。但从一个团队创始人的角度看，从原始两三个人没有枪的时代一路拼杀，其中经历了多少不为人知的崎岖艰辛。

四、重生时代——“新”

（2016至今）

运维服务化、平台产品化，这是2015年就开始酝酿的想法，只是今年思路才慢慢地越来越清晰起来，知道要做哪些事情，如何去做。纵观整个时间轴，我们会发现从当中的一些问题，有些是值得我们运维人员深思的地方。现在的互联网已经不比以前了，前面提到2009年当时懂linux的是很稀缺人才，而且互联网上的资料都很少。但是现在7年过去了，各种公有云、各种开源软件、各种服务集成商，几乎你能想到的知识点和服务都能在互联网上获取到。一些底层的基础技术全面自动化，这很大程度降低了对运维的依赖。

「云的诞生把一些基础运维的服务整合，彻底公有化，基础运维就变得像水和电一样无处不在。」

在平台化高度整合的今天我们遇到的困境并不是以“技术为导向”了，那么我们的价值在哪？前路在哪？ 

1. 实现平台化战略

唯一的出路就是“影响业务、创造口碑、创造价值”，而这从运维的角度来看，我们充分利用现有基础资源和业务特性，从被动的运维服务转向主动的运维服务。尤其是我们的很多技术思维必须转变成服务思维，从技术运维升级到服务运维，更加强调是业务交付能力，我们要更懂业务。自身的技术修养，要转换成生产力，要转换成我为公司做多大的贡献。

服务化的前提，就是能后台化的工作要尽量全部后台化，后台对外的可视化、功能自助化。对内的可配置化是核心原则、后台各项的服务闭环是基本原则。

2. 提升软实力

我们在修炼业务的同时，软实力也要跟着提升上来。运维的危机感从来都不会离去，我们只有拥抱变化，不断的做自我调整，才会有一席生存空间，才会得到更多人的认可。 

3. 特立飞行的猪——重获新生

运维新时代——智能服务化，我们只能破茧重生，寻找新的征程和领地。我们的境地就像一群在猪圈里的猪，有一天猪圈会停止投放饲料了，饲料就只有那么多，马上就快吃完了，我们可能会饿死。所以我们得提前想办法长出一双翅膀变成一只会飞的猪，飞出去找到新的领地找到饲料吃，或许一只特立飞行的猪才有一席之地。而运维服务化就是我们的翅膀，我们运维人不应该是配角是附属的，通过运维服务化建设，未来我们是主角，有一天可以站在舞台的中央享受掌声、享受荣耀！

作者 | YW原创   来源 | 运维军团   ID | ywjtshare