腾讯最赚钱的部门是怎么做运维的？

腾讯最赚钱的部门是怎么做运维的？背景介绍
腾讯互动娱乐事业群的主营业务是游戏，所有腾讯游戏都是由这个事业群做的，估计很多⼈都玩过，像《英雄联盟》、《全民突击》等。

我所在的部门叫运营部，负责所有腾讯游戏的技术运营⼯作。

简单解释⼀下，什么叫技术运营⼯作，这⾥包括了⼏个部分：运维，营销开发，数据分析和数据挖掘，⽤户运营（所谓⽤户运营，不是传统的客户服务，是⼀些⾼端的⽤户运营。

）
⽐如说在腾讯游戏上⼀年花⼋万，就是我们的VIP，我们有专属的服务经理对接，就像银⾏的VIP⽤户⼀样。

这⾥就不展开了，重点说说我所负责的运维管理⼯作吧：
如上所说，我们所负责的运维⼯作，是运营部的⼀部分⼯作。

我们现在运维了⼏百款游戏，⽽且数字还在快速增长，特别⼿游加⼊以来，每年都有⼀两百款。

简单介绍⼀下腾讯游戏运维团队的发展历程：我们团队是2003年随着腾讯代理《凯旋》游戏⽽成⽴的，发展到2005年的时候，我们做了⼀件事情，就是DO分离，DO分离的概念前些年提得⽐较多，现在⼤家好像不再提了。

回头来看，我们觉得DO分离是很有必要的，因为开发跟运维需要具备的核⼼能⼒是不同的。

接下来，在2006年的时候我们做了QO分离，意思就是我们把质量管理团队（QA）和运维分离开了，这个后⾯我会再讲⼀下。

随着团队进⼀步扩张，业务进⼀步增加，2007年的时候我们把DBA专业团队分离出来了。

到2009年的时候发现业务发展很快，⽼板不给我们这么多⼈，怎么办？光靠⼈去填的模式已经运⾏不下去了，所以当时成⽴了运维开发团队，专门建设运维⼯具。

同时在2009年我们还成⽴了⼀个内部安全团队，这个团队可能很多公司都没有，⽐较特殊。

因为⼤家知道游戏⾏业，有些游戏类道具⾮常值钱，说不准哪个同学⼿⼀抖给⾃⼰加个⼏⼗万，所以我们成⽴了内部安全团队，做安全监控，其中也包括权限控制，⼤家都知道，⾃动化系统权限控制⾮常重要，如果这个没控制好就会出现灾难性后果。

时间到了2012年，我们开始提倡运维转型，⿎励运维向运维开发转型，让运维⾃⼰开发所需的⼯具来实现⾃动化。

现在，我们提倡运维服务化和平台产品化，这个后⽂会提到。

接下来，我从⽂化、组织、⼈、流程、⼯具这⼏个维度分享⼀下运维管理的点滴经验。

我们团队的运维⽂化
运维⽂化：当⼀个团队规模较⼤时，例如我们团队，有两三百⼈的规模，这个时候我们可能需要⼀些⽂化层⾯的东西来统⼀⼤家的思想，让⼤家在⾏为上按照我们的⽂化来思考和执⾏。

我们⽬前提倡的⽂化，叫“运维四化”：服务化、标准化、⾃动化、产品化。

标准化和⾃动化⼤家都⽐较好理解，我就不讲了。

重点强调⼀下我们为什么提出运维的服务化。

为什么要“服务化”？
运维的本质到底是什么？
我从2002年开始做运维，⼀直到现在，都算是在运维⾏业⾥摸爬滚打，以前，我觉得做好发布变更、故障处理，让业务保持运⾏稳定就是运维的价值，但通过这⼏年的思考和实践，我觉得那是不够的。

那么运维的本质到底是什么呢？我觉得是服务，是服务于业务，因为运维是⽤技术解决业务问题，运维的价值要依托于业务才能体现。

运维不是因为技术⾼深，或者管理了⼏万台服务器⽽很⽜逼，也不是能玩转很多开源⼯具⽽很⽜逼，这都不是运维的关键。

我提⼀个观点：对于运维来说，服务第⼀，技术第⼆。

运维技术再⽜，如果不能服务于业务，帮助业务取得成功，那价值也是有限的。

那么怎样服务业务呢？我们总结了四点：
1.贴近业务：就是我们⼀定要与业务⾛得⽐较近，保持信息的畅通。

2.理解业务：要知道业务⽬标是什么，⽤户群是什么，商业模式是什么样的。

之前我见过很多运维，甚⾄在公司做了半年、⼀年，还不知道所运维的业务的商业模式是什么，这样的话，我们怎么能有针对性地提供服务，去帮助业务成功呢？理解业务还意味着要站在业务运营的⾓度思考问题，⽽不仅仅站在运维的⾓度思考。

3.挖掘需求背后的价值：我们经常会收到运营⼈员提出的需求，在理解业务的基础上，我们要挖掘这些业务需求背后的价值，⽐如说运营⼈员让发⼀个版本，做为运维，我们是不是把这个版本发布完就OK了呢？
肯定是不够的，我们还要去看业务发这个版本的⽬的是什么？可能是为了拉新⽤户，也有可能
是做个活动去拉收⼊，或者是修复bug。

每⼀个版本的⽬的不⼀样，运维所做的事情是可以不同的。

⽐如这个版本是拉新⽤户，我们把版本发布完以后，还可以采集更多的数据，去帮助运营⼈员分析，看是不是达到了拉新⽤户的⽬的。

或者协助运营⼈员分析，这个版本的⽤户体验对于拉新⽤户是不是有瓶颈。

这都是运维可做的事情，也是业务运营很需要的事情。

4.扩展服务价值：着眼于业务和服务，我们可以不断挖掘到新的价值点，扩展运维服务的价值。

当然了，这⾥绝不是说技术不重要，优秀的运维服务需要强⼤的技术来⽀持。

举个例⼦，你想协助运营⼈员做⽤户体验的分析，这需要较强的技术能⼒来⽀撑。

因为像上述的版本数据分析对实时性的要求很⾼，如果你没有及时分析出来，错过了运营时机可能就来不及调整了。

可以说，业务视⾓和服务意识决定了运维服务可以拓展到哪⾥，⽽技术能⼒则决定了这些服务最终可以实现多少。

前⽂讲了我们的历程，在2009年，我们做了⼀些组织分⼯，我们DBA团队，开发团队，安全团队都从这⾥分离出来了。

关于组织
这⾥想分享的经验是：当团队和业务发展到⼀定规模的时候⼀定要考虑到专业化分⼯，业务和团队规模⼩的时候没必要分的太细，因为业务场景对专业性的要求可能不⾼，随着业务发展和团队变⼤，专业性的要求就⾼了。

所以我们现在的内部划分成5个⾓⾊，第⼀个⾓⾊是运维规划。

⼤家可以认为它是运维的PM，他起到的作⽤是充分理解业务需求，挖掘需求背后的价值，同时他也熟悉运维内部的各种资源，可以协调各种资源来满⾜业务的需求。

这些运维规划都是从运维成长起来的，懂运维。

第⼆个⾓⾊业务运维，这个就不讲了，⼤家都清楚。

第三个⾓⾊DBA，⼤家都知道DBA的重要性，他们最重要的职责之⼀就是要保证数据的安全。

⼀个业务，就算是遇到像携程这次的情况，就算全部线上环境都没有了，但是只要数据还在，业务都还是可以恢复的，但如果连数据都找不到了，那就真完蛋了，所以DBA⼀定是独⽴的，⼀定要保证数据是万⽆⼀失的。

系统运维这个⾓⾊也不说了，⼤家也⽐较清楚。

还有就是运维开发的⾓⾊，我们觉得运维开发不是传统的开发，运维开发⾸先是运维，其次才是开发，他们需要站在运维视⾓看问题的，站在运维视⾓开发⼯具给运维⽤。

关于⼈员管理和培养体系
组织⾥最重要的是⼈。

在⼀个⼀定规模的团队⾥，建⽴⼈员的成长和培养体系是很重要的，尤其像规模到⼏百⼈的时候，我们怎么样保证团队⾥的同学们具备相应的能⼒和成长空间。

在我们团队⾥，有⼀套运维的成长体系，运维同学希望从事管理或者协调⽅⾯的⼯作，可以往运维规划⽅向发展；如果希望从事开发⽅⾯的⼯作，可以向运维开发⽅向发展。

配合成长体系，有⼀套培养体系。

新⼈加⼊以后，⾸先有新⼈培训。

这⾥所培训的内容都是与运维相关的，⽐如运维系统的培训，在新⼈培训⾥有专门的篇幅是安全意识相关的，从刚⼊职开始就灌输安全意识。

此外，新⼈培训中还包括腾讯游戏运维⾎泪史，通过分享之前的教训提⾼新同学的运维操作意识。

新⼈在⼊职以后到转正有三个⽉，在这三个⽉中，⼀般情况下新同学不能独⽴操作正式的运营环境。

只能在导师的带领下操作。

那怎么才能具备独⽴操作能⼒呢？需要考运维上岗认证，这个认证包括考试和评估两个环节，考试的内容⼤部分是新⼈培训的内容，例如安全意识、运维操作规范等。

评估的形式是⼏位资深的运维现场对被评估者进⾏评测，考察他们在各种场景的理解和反应，这些是不能通过背书本知识来回答的，所以还是⽐较考验新同学的能⼒和意识的。

通过上岗认证后会拿到⼀个上岗证，以前是会发⼀个红⾊的证书，现在不发实体证书了，变成电⼦的了。

这个上岗证后⾯还有⼀个作⽤，后⾯我会讲到。

新同学转正后，⽇常⼯作中会接触到很多技术培训和分享，这些⼤部分是由内部同学贡献的，当然也有公司内外部的各种培训资源。

当某位同学在团队内⼯作了⼀段时间之后可能会⾯临成长的问题，我们会挑选出有潜⼒的同学上运营规划培养班或运维开发培训班。

这两个培养班分别培养运营规划和运维开发。

拿运营规划培养班做例⼦，选定的同学经过半年的培养后通过考核才能成为的运营规划，通过率⼤概在40~60%。

运维⼈员的考核体系
运维⼈员的考核分为⼏个部分：
第⼀，业务指标。

业务指标就是业务的⼀些关键性指标，⽐如可⽤性、发布效率等等，还有很多其他指标。

这些指标的作⽤是评估运维⼈员的基础⼯作完成质量，这是由QA，就是前⾯所述的质量管理团队统计的，不是运维⾃⼰上报的，这样可以保证其客观性。

第⼆，关键事件。

关键事件是运维⾃⼰制定的，⽤于引导运维不断优化⼯作。

这个关键事件每个⽉定⼀次，由运维和他的leader和运维规划三⽅⼀起制定。

举个例⼦，我们发现某个游戏它的发布时长过长，就可以把发布时长优化做为这个游戏的运维⼈员这个⽉的关键事件，⽬标是把这个业务的发布时长从多少降到多少。

制定关键事件的⽬标时⽐较细，要求是量化的，⽉底时运维根据完成情况获得关键事件的得分。

第三，加分项⽬。

例如做分享和培训都可以加分，积极参加团队建设也可以获得加分。

第四，扣分项⽬
我们的考核思路是尽量⽤正向加分的⽅式引导，⼀般不扣分。

除⾮是⼈为失误造成业务故障。

所谓⼈为失误指运维操作不当造成的问题，我们对⼈为失误持“低容忍” 的态度，因为我们觉得做为运维，意识是⾮常重要的，操作时要时时刻刻秉持⼩⼼谨慎的态度，抱着敬畏的⼼情对待运营环境。

如果出现⼈为失误造成业务故障的情况，对于个⼈会有什么影响呢？
前⾯提到的运维上岗证的另⼀个作⽤就在这⾥了，⼤家都知道违章后驾照扣分这项处罚措施挺有威慑⼒的，我们吸取了经验，对运维上岗证也实⾏积分扣分制度：运维上岗证每半年都有10分的积分，如果出现⼈为失误的故障就从中扣除⼀定的分数，如果分数扣完，上岗证就会被注销，那么这位运维就需要被评估是否适合在运维岗位上继续⼯作了。

当然，这个扣分制度的⽬的肯定不是为了处罚，主要还是希望通过这种⽅式提⾼⼤家的操作意识，避免⼈为失误。

有的同学可能会问，为什么不靠⾃动化来降低⼈为失误，⽽要⽤这种考核⼿段？
这⾥我想说，根据我们的经验，游戏运维是很复杂的体系，特别是团队⼤了以后，⾃动化程度再⾼还是有很多⼈为失误的空间，最终的决定性因素还是⼈，所以，意识强化和考核⼿段还是不可或缺的。

关于流程的⼏点思考
流程的本质就是管理和控制，其实⼤家做的每⼀件事情都有流程，随便做⼀个发布，做的这些步骤就是流程，所以流程其实是⽆处不在的。

很多运维同学都觉得流程好⿇烦，觉得流程就是给运维的桎梏，其实⽤好流程是可以保护运维的。

我们很多时候需要跟运营和研发配合，如果⽤好了流程这个⼯具是可以保护运维利益的。

但是，流程执⾏起来的确有成本，那怎么降低流程的成本呢？
我们觉得流程应该“隐形化”，就是让流程融⼊到运维系统中，让运维同学不⽤花额外的精⼒去执⾏流程，感觉不到流程的存在，让流程起到控制作⽤的同时，尽量不降低我们的效率。

关于⼯具建设的⼏点思考
⾸先，我们认为⼯具的建设者必须是⼯具的使⽤者，要懂得应⽤场景，否则的话，造出来的⼯具是不好⽤的。

因为在这⾥我们是吃过⼀些亏的，刚才提到2009年我们就建⽴了运维开发团队，但是到2011年发现我们⼯具覆盖的情况还是不够好，运维不愿意⽤，我们建⽴的是专业的开发团队，有产品经理、开发、测试，但是为什么做出来的⼯具就不对运维的胃⼝呢？
我们后来发现，开发团队并不懂运维场景，虽然他们也会做很多运维需求的访谈，但总是发现做出来的东西不是运维想要的。

所以后来我们改变了⼯具开发的模式，改成在运维中培养运维开发，让运维开发⾃⼰开发⼯具给⾃⼰⽤。

这样的话，为了降低开发成本，我们做了蓝鲸平台，运维只要经过两周左右的培训就可以在蓝鲸上⾯开发⼯具。

标准化是⾃动化最重要的⼀个基础，如果没有标准化的话⾃动化是不会长久的。

如果业务之间架构差异过⼤怎么办呢？可以降低标准化的维度，⽐如我们去实现原⼦操作的标准化。

了解的同学应该知道，游戏架构是很不标准化的，游戏不像Web应⽤，有很多框架模型，它没有，各家⼚商各做各的，因此我们只能做原⼦操作的标准化，然后再在其上去组装各种场景作业。

我们做⾃动化⼀定要打通企业内的各个信息孤岛，全流程的⾃动化才是真正的⾃动化。

只有都打通了，在作业执⾏过程中才不会中断，可以实现⽆⼈值守的⾃动化，蓝鲸平台就是这样的，它有⼀条ESB，打通了很多外部的系统接⼝。

运维在蓝鲸上开发⼯具需要打通其他系统的直接调⽤就⾏了，⼤⼤提⾼了开发效率。

产品化：运维平台要以产品理念建设
最后，我想说的是，前⾯提到运维⽂化中有⼀个产品化，为什么提产品化？因为我觉得运维平台是要以产品的理念来建设的，这⾥包括很多的层⾯，这⾥就简单提其中⼀点：重视平台的⽤户交互。

以前，⼤家觉得运维平台是内部系统，能⽤就⾏，交互好不好⽆所谓。

但是我们发现，内部平台也需要交互优良，如果交互不好的话，可能有以下负⾯作⽤：⼀是交互不好容易造成误操作的情况引发故障；⼆是交互不好，很难⽤的话可能会被内部⽤户抛弃，被新的系统或平台替代。

所以，运维平台做为内部平台，也需要重视⽤户的交互，⼀定要有良好的界⾯，要让⽤户操作起来⽐较⽅便⽽且不容易发⽣误操作。

本⽂转载⾃InfoQ (ID:infoqchina)
⼩编精⼼为⼤家挑选了近⽇最受欢迎的⼏篇热⽂↓↓↓
（关注订阅号dbaplus，回复以下数字，即可获取相应⽂章）
回复011，看邹德裕《数据库运维⼯具化：⼀切从“简”，只为DBA更轻松》。

回复012，看马育义《Oracle内核系列3-揭秘ASM磁盘头信息》。

回复013，看吕海波《去不去O，谁说了算？》；
回复014，看杨德胜《Oracle故障⽇志采集“神助攻”—TFA⼯具详解》；
回复015，看郭耀龙《假事务之名，深⼊研究UNDO与REDO》；
回复016，看陈能技《基于Docker的开发模式驱动持续集成落地实施》；
回复017，看朱贤⽂《数据库与存储系统》；
回复018，看卢钧轶《揭秘Facebook数据库备份策略》；
回复019，看杨建荣《看似简单的dual，其实深藏⽞机》；
回复020，看黎君原《扒⼀扒Oracle数据库迁移中的各种坑》。