手游测试工作总结(1) - 简书
手游测试工作总结(1)
1、概要本报告旨在总结手游测试的流程，主要从黑盒功能测试方面出发，以手游测试为中心作出的一份工作总结报告。2、QA测试的定义和工作职责我所理解的QA（QualityAssurance），中文为“质量保证”，在整个项目产品的生命周期中，QA将与项目中的其他所有部门进行协助合作，跟踪和分析产品中的问题，督促问题的解决，同时尽可能从用户玩家的角度分析游戏的不足及不合理之处，以保证游戏质量达到项目需求。QA工作职责是对游戏进行测试和建议，在项目生命周期内游戏各阶段正常运行为工作重点。合格的QA在进行测试工作的同时会逐步成为对项目产品最了解的人员，应当对游戏的各个方面和项目的工作有充分的了解，从而及时发现游戏中的缺席和项目管理中的缺陷，并提出专业性建议。QA所着重做的三件事：①发现并跟踪游戏的BUG。②指出游戏中存在的瑕疵。③从用户角度提出游戏的不足和对游戏的建议。3、游戏测试的流程游戏测试流程依附于游戏开发的流程，一个正确，正规，合理且科学的测试流程对测试的效率和工作质量有至关重要的作用，这里不再赘述。下图是我个人对游戏测试流程的理解，这份报告也将围绕我所理解的测试流程展开。
4、测试准备期测试准备期是测试工作的酝酿奠基期，为整个测试的工作打好基础。4.0 项目计划测试应当尽早介入项目，从测试的专业角度为项目提出意见。根据项目计划分析出测试需求，从而为测试计划做铺垫。4.1 测试计划4.1.0测试计划定义测试计划依附于项目计划，同时又应该有自己的独立性，对项目计划有监督催促的作用。当测试计划与项目计划发生冲突，断档时，应及时向PM反应，以检查项目或测试计划哪个部分出了问题，作出相应的调整，保证之后的流程能正常正确的进行。测试计划制定应依据测试需求，将测试工作进行合理有效的划分，为下一阶段的测试做好准备和规划，使测试人员清晰的了解项目测试情况以及每个测试阶段该做什么，也可以让项目的其他人员了解测试人员工作内容，以便配合测试工作。测试计划分为总体测试计划和详细测试计划。4.1.1测试计划的目的测试计划的制定应明确：（1）为什么做这些测试。（2）不同工作阶段的测试内容。（3）不同测试阶段的起止时间。（4）测试环境，测试文档存放位置，BUG的管理方法。（5）测试人员安排。（6）如何测试，测试的方法。（7）测试的风险评估（8）游戏所要达到的质量标准测试计划编写完成后，需所有测试和开发人员进行评审，对测试计划进行完善修复，直至大家达成一致。然后根据测试计划制定详细的测试方案，测试计划和测试方案最大的区别在于前者重点在于“做什么”，而后者重点在于“怎么做”。4.2测试用例测试用例是对测试任务的细化描述，包含具体的测试方案，测试方法，测试技术，测试策略等的一个文档。理论上测试用例应包括以下几个要素：①编号：同一份用例中编号应具有唯一性。②模块：用例对应的功能模块。如：背包的一键整理功能③重要性：用例的重要程度。④预置条件：执行用例的前置条件。如：游戏版本号，运行环境等等⑤测试输入：执行用例所需的输入。⑥操作步骤：执行用例详细的步骤。⑦预期结果：执行操作步骤后预期所得到的结果。⑧测试结果：PASS/NG/NT⑨备注：补充说明。4.2.1编写用例的准备首先，详细阅读策划文档，拆分策划文档中的功能点。然后，根据功能模块进行划分，细化每个模块的用例。然后，根据功能模块的逻辑，关联设计用例。最后，依据测试用例的设计方法，保证测试用例的规范，有效。4.2.2测试用例的设计方法（1）需求文档拆分转化法所见即所得，策划文档是我们设计用例的基础，将我们在策划文档中所见到的都转化成我们的测试用例。包括但不限于：所有策划文档需求描述的文字信息，所有策划文档中的流程图，示意图，状态图等，所有和策划进行交流所达成的需求信息等等。都可以转化成测试用例。这是我写测试用例的第一步，也是我最开始写用例的基础。这个过程应当充满着愉快（？）的交流，一定要耐心询问策划自己的每一个对需求的质疑和不确定的地方。（2）错误推测法基于上述所得用例，及自己的经验直觉，推测出游戏中所可能存在的错误，从而针对性的写出测试用例。包括但不限于：正确操作过程的不正确操作，容易发生错误的情况，在以前测试中发现的相同或相似错误，相同逻辑下其他用例发现的错误等等。（3）边界值法边界值法是很重要的一个用例设计方法，也是问题出现较多的地方。边界值法就是对输入和输出的边界进行测试。边界值的例子有很多，比如：购买物品的最小值和最大值，UI界面的边缘，活动的开始和结束时间等等。需注意凡是文档中规定了有取值范围（值不一定就是具体的“数”，重点在于范围）的都需要进行边界值测试；凡是有次数和时间相关的，都需进行边界值测试；凡其他有边界的情况（单项边界，双向边界），需进行边界测试。边界测试的取值应注意：①给定了取值范围，应选取恰好在边界，在边界外，在边界内三种来测试。②给定了个数或次数，应选取对应个数，最大个数，最小个数，比最大最小个数恰好大1或小1等几种值来测试。③其他各种边界情况。（4）等价类划分法如果穷举来写用例的话，用例是无穷无尽的，不仅浪费了大量的用例编写时间，而且非常影响用例执行的效率，做了无用功。等价类划分法通常与边界值法相联系来写用例。等价类通常划分为有效等价类和无效等价类。等价类法可以提高测试用例编写的速度和用例执行的效率。举几个例子来说下有效等价类和无效等价类：①比如购买物品，数量最小为1，最大为20。那么购买1-20个物品就是有效等价类，也就是1-20是等价的。小于1或大于20的就是无效等价类。当然边界情况要根据边界值来进行用例编写，这也是为什么我说等价类划分和边界值通常要联系着来写用例。②再比如购买物品输入数字，只能输入数字，其他都不能输入，那么所有数字算是一个有效等价类，其他如汉字，符号，字母等是无效等价类。等价类还有很多例子，不再一一列举。（5）穷举法穷举法用在等价类不能作用在的情况。比如，玩家起名字不能用特殊符号，此时需对特殊符号进行穷举测试。（6）逻辑图法画出文档实现的逻辑关系图，或询问程序功能所实现的逻辑，对功能的逻辑结构有所了解然后遍历逻辑图中的各个路径。通常有：判定逻辑的真值和假值（可看做if··else··，true or false，如果为真，则怎么怎么样，如果不为真，怎么怎么样，），条件逻辑的分支覆盖（可看做swich
case1 case2··），还有上面两种的组合逻辑，等等。这种方法我不太常用，很多情况是在出现BUG后像程序或策划询问分析BUG时，深入询问实现逻辑才会做。（7）其他的用例设计方法用例的设计方法还有很多，上面是我经常所用到的方法，除此外还有因果图法，正交实验设计法等等。留待以后作深入研究再补上。4.2.3编写用例所需要注意的地方（1）尽量根据用例的执行顺序编写用例，从而提高用例的执行效率。（2）编写用例前一定要熟知功能系统的需求。（3）编写用例时要根据测试功能项目进行分类，便于之后的分析和阅读。（4）编写用例时要着重主要功能需求的重点，以及功能需求和流程中风险较高的地方。（5）用例条数的多少不能说明用例质量的好坏，做到不多不少，覆盖全面最好。（6）测试用例写完后应在项目组内进行评审，评审通过后方可执行。4.3 测试环境这里所说的测试环境是广义的测试环境，包括测试工作所需的软件和硬件。硬件环境如测试所需服务器，客户端，网络设备，各种测试机等等。软件如测试工作所需操作系统，数据库，BUG管理软件，版本管理控制软件（SVN）以及其他所需用到的软件。测试环境的要求：①应符合游戏或服务器正常流畅运行的最低要求。②所选软件应较普及便利，方便工作进行。③测试环境应尽量独立，纯净。④虚拟测试环境应尽量接近真实环境。测试环境的搭建了解并不深入，此处不做深入讨论。兵马未动，粮草先行。测试准备期的工作做好了，方能为之后的工作顺利进行做好保障。在测试准备期通常具体的工作流程如下：①提交策划文档策划提交策划文档，通过SVN上传到策划文档目录下，并通知测试人员。②策划文档的分配测试拿到测试文档后，由测试组长进行工作分配，测试人员进行策划文档的测试。③策划文档测试测试人员应对策划文档中游戏玩法功能的合理性，可玩性等作出分析，是否存在问题，并对存在的问题作出相应反馈，反馈到相应策划。④测试用例编写策划文档测试进行之后，进行对应文档的测试用例编写。⑤用例审查用例编写完成之后在测试组内进行用例审查，互相检查用例，进行用例的补全和修正，通过审查的用例进入执行。⑥策划案修改这是不可避免的流程，策划对策划案进行修改后，必须通知相关测试人员，重新进入步骤③。
1.测试与软件模型 软件开发生命周期模型指的是软件开发全过程、活动和任务的结构性框架。软件项目的开发包括：需求、设计、编码、测试、稳定、部署、维护等阶段。 常见的软件开发模型有瀑布模型、迭代开发、螺旋开发和敏捷开发。 1.1 瀑布模型 瀑布模型式是最典型的预见性的方法，严格...
1.测试与软件模型 软件开发生命周期模型指的是软件开发全过程、活动和任务的结构性框架。软件项目的开发包括：需求、设计、编码、测试、稳定、部署、维护等阶段。 常见的软件开发模型有瀑布模型、迭代开发、螺旋开发和敏捷开发。 1.1 瀑布模型 瀑布模型式是最典型的预见性的方法，严格...
1、什么是兼容性测试？兼容性测试侧重哪些方面？ 参考答案： 兼容测试主要是检查软件在不同的硬件平台、软件平台上是否可以正常的运行，即是通常说的软件的可移植性。 兼容的类型，如果细分的话，有平台的兼容，网络兼容，数据库兼容，以及数据格式的兼容。 兼容测试的重点是，对兼容环境的...
文章来自：http://blog.csdn.net/mj813/article/details/ 问：你在测试中发现了一个
bug ，但是开发经理认为这不是一个
bug ，你应该怎样解决。首先，将问题提交到缺陷管理库里面进行备案。然后，要获取判断的依据和...
相关文章： 《再说说APP测试设计-1》《再说APP测试设计-2》《关于ad hoc test》《干了这碗蛋炒饭 继续APP性能提升-1》《突破测试的墨菲定律 -- 有感于一次UAT组织》 【前言】 之前的测试用例规范，很多人都做过一些分享了，内容大多集中在测试用例的分析方...
【讯操盘今日策略】昨日沪深两市早盘双双低开，个股呈现普跌态势，钛白粉、业绩预增股表现抢眼。从盘面上看，钛白粉、网络安全、电商、智能医疗、食品安全等板块涨幅居前；钢铁板块、石墨烯概念持续活跃；煤炭、保险、建筑材料、特色小镇等板块跌幅居前。 近期行情持续出现跷跷板行情，指数和个...
过客 不论朝那方行进
都有一些小小的酒店
数不清的过客
都吻过那缺口的老土碗
饱赏了酸甜苦辣
把比食盐还咸的人生
当酒菜吞下
沿着横斜的黄昏
让悠长而又细腻回味
第三讲作业: 1、以《三言两拍》中“二拍”的第一篇为标尺，确定出自己的阅读层次，并据此制定一个阅读套餐。（文言几成+旧小说几成+现代白话文几成） 阅读文言文《转运汉遇巧洞庭红波斯胡指破鼍龙壳》还较为顺畅，颇有兴趣 我制定的阅读套餐为：文言四成+旧小说两成+现代白话文四成 在...
D23/100 中秋前天气预报说有台风，中秋那天我们也就没有出门，太阳正好。第二天因为在空调房呆的太久，似乎有些不适，下午4点强行带娃带老公出门去公园。 娃娃的目标很明确，告诉我们要去游乐场。游乐场的路已经被挖的坑坑洼洼了，我们选择了一条远路，虽然远但没有太阳，会凉快一些。...
面膜文案 1 敷住时间的秘密 互动 带走属于你的美肌“膜”法 汽车文案 1 驾上·“驶”诗 2 骑·驶 —精神 价值 荣耀-忠己一个游戏测试的工作感悟（转）
最近这几年，逐步从需要同事帮忙解决问题的人，慢慢的变成想办法解决自己的问题，同时还要帮其他同事解决问题的多面手。每一次的蜕变和革命都非常辛苦，然而却始终给人的感觉是前戏做足，缺乏高潮。游戏测试是需要不断的学习和创新的岗位，因为你负责的产品在不断的变化，就算产品不变，你面对的市场环境和玩家需求在变化，因此需要新的技能和新的方案来适应这些变化，只有这样才能保证你所负责的产品一直能高品质的交付给我们的玩家。
测试现在做的工作内容越来越丰富，和5年前我刚接触软件测试时，工作内容的复杂度更高，测试技术的深度和广度成指数上升。当面临这种情况，一个问题引起我们的思考，游戏测试到底是干嘛的？如果面对一个完全不懂测试的人，应该如何向他解释我们的工作内容？看似简单的问题，解释起来还真不一定能解释清楚。我记得有个开发GG向策划GG解释什么是CGI，半天没解释清楚，后来另外一位开发GG解释道“CGI就是一段程序”，策划GG顿时懂了。有个微博说：“前台开发是写界面的，后台开发是部署服务器的，美术是画画的，测试是找bug的”，顿时引起对应岗位的同学不满。其他的我不解释，怕越解释越糟，还是说说我对测试的理解吧。测试岗位的职责应该是研究各种测试方法保证产品质量，并不断提升测试效率。我认为测试最应该关注的是客户导向意识，其次是成本意识。对游戏测试而言，客户导向意识即是保证产品质量，其实就是保证我们玩家的利益不受损害，让玩家放心玩，安心花钱，不会受到任何功能、性能、安全、体验等问题的困扰；成本意识方面，不仅要求测试早一点发现问题，减少修复问题所带来的成本，例如在测试环境发现一个蠕虫漏洞并修复，与在外网发现再修复，修复成本带来的影响显而易见；在成本意识方面，还要求测试要不断思考ROI，不断提高测试效率，优化测试流程、研发新的工具、设计新的测试方案、引入自动化测试等，进而减少测试人力带来的成本、减少过度测试的成本。
最近这两年，做的最多的事情就是思考，总有很多令人头疼的问题需要思考和理顺。但是思考确实可以令我的眼界更加开阔，心胸更加豁达，心态更加成熟。思考在哪儿都可以进行，公交上、厕所里、
读书时，都能令我们有所启发。“停止工作，但不要停止思考”，这是我最喜欢的一句话。人是很奇怪的动物，非要实践之后，对事物的理解才会深刻。测试也是这么个职业，需要不断的尝试和实践。下面分享一些游戏测试相关的实践与思考，希望能对爱思考的人，有所启发。
测试环境一定要测试人员自己维护，勿依赖运维同事。我们团队的每款游戏，不管是代理，还是自研，都是测试人员自己维护测试环境。测试人员自维护测试环境，与开发环境分开，保证测试的完整性和准确性；可以在测试环境快速构造数据，提高测试效率；快速导入外网数据，进行外网问题重现和分析；避免因为运维人员不在，测试工作无法开展；测试环境集成测试工具，适时监控版本运行情况；测试人员通过熟悉测试环境，对系统架构理解更加深刻，测试设计更有针对性，有助于测试质量的提高。当然，在测试环境上可以做的远不止这些，还可以做持续集成、单元测试、问题代码调试等等。
用心去做安全测试，你会发现获得的东西远不止安全测试这个领域的知识。你可能了解到社会工程学，这是能使人们顺从你的意愿、满足你的欲望的一门艺术与学问；很多普通人看起来完全没有用的信息，用在社会工程师的手上可能是一场灾难。你可能了解到产品技术实现的本质，当我们用尽浑身解数发现安全问题，提交给研发同事，请不要止于此。因为还有一件重要的事情等待我们去做，挖掘问题产生的根源，当一直这么去做，你会发现还有其他地方存在此类问题，同时可以提出彻底杜绝这类问题的方案。你可能了解到不同的编程语言和对应工具，因为你完全不会这些，很难再继续发现安全问题。你可能了解很多安全测试的工具，并发现这些工具不只用于安全测试。你还可能交到一群闷骚的技术宅男朋友，因为你不是一个人在战斗。
做专项测试一定要和研发同事提前沟通好。认真去和研发同事沟通好各项专项测试内容和指标后，再进行专项测试，你会发现专项测试方案在研发同事的帮助下更加完善，测试目标更加清晰，沟通更加顺畅。千万别一厢情愿的去做一些事情。我们在webgame前端性能测试建设初期，不断和不同的主程序去碰这些指标，最后整个测试标准和指标在很多人帮助下，逐步完善。我们发现他们也很关注这些问题，在后期发现问题后，他们会第一时间解决，因为这是我们一致认可的标准和方案。
关注客户端性能测试，你会发现老板和玩家都很关注，因为你关注的实际是钱。在研究webgame前端性能的过程中，我们发现成功进入游戏的玩家比例，与加载游戏的时长是成反比关系的，即进入游戏加载时间越长，中途流失的玩家越多，很多玩家是没有耐心等待慢慢加载的，我们测试过的游戏最严重的在加载阶段流失掉超过50%。假设按照获取一个玩家的市场推广费用为3元，当注册用户为500W时，可能因为这个性能问题损失掉的钱是3*500*50%=750W元。公司服务于海量的互联网用户，当我们产品的用户到了亿级，每一个小的性能优化，在流量上节约的成本是非常庞大的数字，因此cache策略的应用、压缩算法的应用、预加载与延迟加载策略的应用、DNS划分等都显得尤为重要。
换个角度看兼容性测试。兼容性测试是客户导向意识的很好反映。兼容性测试的实质是让尽可能多的用户，可以正常使用我们的产品。经常隐藏在一些玩家群里面，看到很多兼容性测试不到位的问题，比如在某些操作系统下无法安装游戏、某些分辨率下无法正常显示、某些低配置机器无法玩、网通和教育网用户玩游戏卡和延迟等问题时有发生。兼容性问题将直接导致游戏可玩用户群变低，流失率增高。目前游戏的兼容性测试，暂时还缺乏一套系统对所有兼容性测试机进行管理，同时可以采用虚拟机的方式，将当前的实体机充分利用起来，让所有想测试兼容性的测试人员可以远程登录对应兼容性测试机，将以前串行接待兼容性测试需求的方式，变更为远程并行自助测试的方式。
对于成长相对慢的新人，导师、TM和leader一定要多给他试错的机会，有一天他的成长会超乎你的想象。我们在关注一个新人的时候，更多的是应该关注他的态度，只要有学习的激情和工作的动力，他就是不错的新人。因为从招聘进来那一刻，几位面试官就已经认可了他的基本素质。两年之后，发现在我们身边持续给力支持的，可能是原来的这些适应较慢的新人，这也许就叫做厚积薄发吧。
关于游戏测试的深度和广度。一方面由于业务的多样性，强调了解测试技术的广度；一方面由于系统的复杂性，要求测试技术的深度，在有限的时间里如何平衡这两块内容的学习？首先，我们得承认一个事实，测试是不可能一招就可以解决所有问题，我们得不断的见招拆招。我们得尝试在测试的一个方向如安全测试、性能测试、协议测试、自动化测试等做深，多思考、多沉淀。当积累到一定程度，你会发现就好像学习了九阳神功，再学习其他东西非常快，有很多经验性的东西都很类似。在这里面思考变得尤为重要，每一次失败都是一笔重要的财富。
最后留一些问题可以一起思考。游戏测试是玩家的代言人，那玩家对游戏的真实需求和期望是什么？开发可以进行极限开发，测试的极致在哪里，“极限测试”可能是怎么样的？大部分的测试还只针对CS间进行，SS间的测试是否有必要？游戏的安全测试，除了应用程序级的安全，还有其他的么，网络安全由谁来保证？游戏玩法的测试如何进行，如何量化？如何测试才能保证测试通过的游戏不是垃圾游戏？游戏测试能否往前做，能否达到系统开发完毕即可发布外网，而无质量问题？
思考一直在持续，问题会不断被解决。感谢看到这里的朋友，以上言论仅代表个人观点，若与您的思考相悖，请略过。
已投稿到：
以上网友发言只代表其个人观点，不代表新浪网的观点或立场。国内最大的游戏大佬如何开展运维实践？_极客邦科技Geekbang_传送门
国内最大的游戏大佬如何开展运维实践？
有料、有用、有趣的互联网学习平台“大牛V课堂”是Geekbang核心栏目，我们以线上微课堂的形式邀约互联网特定领域内的顶级大牛分享含金量最高的专业干货主讲人：涂彦腾讯互动娱乐运维总监大家上午好，非常高兴，也很高兴有这样的机会跟大家做这样的分享，因为来晚了，昨天一直修正一些内容，没有来得及跟大家打招呼，先问候一下大家，去年跟大家交流，今天又来了，从其他地方过来的朋友。也非常感谢线上参加直播的，应该是圈内的朋友和同行，希望下面这样的交流机会跟大家分享一下我们在游戏运维领域的一些实践和未来的一些想法。大家记得去年的时候腾讯游戏运维的负责人跟大家做了一个分享，当时是《腾讯游戏云的理想与实践》。今天我的题目叫做：服务才是未来，腾讯游戏运维服务的理想与实践。跟去年的题目几乎是一致的，腾讯游戏云的理想与实践，我的题目是腾讯游戏运维服务的理想与实践。去年在cloud分享提到对运维未来的憧憬，通过运维的服务，帮助游戏走向成功。它其中里面提了几点，包括游戏运维的架构设计，包括游戏技术工具的建设，产品运营决策支持，用户游戏体验以及业务异常定位规避。其实这些点在去年cloud分享当中，腾讯运维团队在日常业务运维过程当中进行实践了。去年更多跟大家分享架构方面，或者是方向方面的想法。今天我也接着去年cloud这样的思路跟大家汇报一下腾讯运维团队在过去的5年里面，从10年开始到现在，我们怎么样落地去做我们的运维服务的一些分享。问题带入与团队介绍在我今天讲之前，请大家关注下面几个问题。一、什么是四化？从13年开始到现在一直关注这样的四化理论，未来也是遵循着这样的四化理论指导游戏运维的思路。二、为什么要做标准化？其实标准化提了很久，包括业内的一些写手，包括萧总，包括UC的王总，大家对运维最近做一些热烈的讨论，特别是标准化，包括怎么样去提升运维的价值化的内容，去做一些讨论。我们也是基于这一块想谈一下腾讯游戏运营怎么做标准化的建设。三、希望在运维里面有一些突破，在进行标准化建设服务化建设希望向智能运维发展。首先来介绍一下我们的团队，整个腾讯游戏运维团队，我们一共发展12年时间，整个运维团队有12年时间，最早在上海发展的，后来逐步发展，去了深圳，现在主要是在深圳做支撑腾讯游戏的运维工作。现在一共有300款以上的游戏，包括端游，手游、页游，这是坚持化理想，努力让运维工作不再苦逼，相信未来运维可以边喝咖啡边处理故障。运维建设三阶段分享今天的内容之前我想跟大家汇报一下我们在整个运维建设当中的三个阶段。1、第一个阶段10年到13年围绕着整个标准化运营。2、第二个阶段13年到15年围绕服务化运营的。3、第三个节但15年到17年智能化方向发展的。标准化运维里面我们经历两个阶段，第一个技术运营的阶段。第二个阶段是产品运营的。最近大家比较关注的是什么？试衣间，还有什么？Kepler—452b。还有什么？蓝鲸，在最近的一些高效运维群里面，很多老师都对蓝鲸有一些评价，其实蓝鲸12年到现在发展了3、4年时间，我们也对蓝鲸做了很多工作，讲第一个标准化里面必须把蓝鲸提出来，因为蓝鲸跟我们是息息相关的。大家知道腾讯有一个QQ游戏平台的业务，这个里面有几百款休闲的小游戏，风靡大江南北，现在日活跃超过千万。由于业务的持续火爆，QQ运维团队人员非常少，原来一共有5个同事，一个领导，其中4个都是我们业务部门的同事，面对这些不计其数的需求，面对我们整个业务的快速增长，我们整个QQ团队处在非常被动的过程。因为本身业务运维比较单一一些，包括我们的能力也比较单一，没有办法迎接大量的需求，包括整个项目的业务增长以后，包括整个的人员不断的增长。鲁迅先生说过一句话：不在沉默中爆发就在沉默中灭亡。现在蓝鲸产品的负责人选择了灭亡，开个玩笑。实际上他主动选择了这样的变革，因为没有变革的话我们不知道后面的运维往哪儿走。在10年开始整个QQ运维团队从原来的4个运营业务逐步向运维方向发展，叫做运维转型的运作。因为蓝鲸的关系大家都比较佩服把整个蓝鲸体系在游戏团队里面做起来，刚才我们说到整个QQ的运营团队有4个运营，我们重新做一个定位，凭着这个咖啡党过一段时间，成功忽悠了几个青年加入QQ运维团队里面，正是有这样的几个人加入到里面，也为高效运维支撑里面奠定了基础。运维岗位设置对于不同的运维岗位，操作运维专著在反复进行。第二类是业务运维。第三类是规划运维，规划运维是我们原来的技术PM的角色，他们可以专著的在运维工作里面规划。第四类就是我们的开发的运维，开发运维和运营开发其实都OK，他们主要是专著运维工具的开发，然他们也是可以做运维工作的。我们看一下这4类运维在整个团队里面怎么样支撑快速发展的业务以及项目人员快速发展的过程。首先因为已经把整个岗位运维瓜分了，和原来的业务运维有完全不一样的能力定位了，之前的业务运维大部分做脚本的编写，包括日常工具的一些操作，比如说如果是合作游戏的话，直接帮你操作。在我们新的运维转型之后，我们4个不同的运维，其实在整个的运维里面它的定位不一样的，大家看到在整个这样的一个循环的圈里面，最上面的是我们的业务运维，先有业务运维熟悉我们业务以后把常规的变革任务定义成各个操作中的内容，然后定向细化每一部分的操作，我们会把我们所有的这些最基本的运维操作，把它抽象成一个一个的原子，这些原子进行场景化分装的因子。第二部分，我们有了这个操作原子以后，我们开发运维会通过平台的页面进行原子操作的流程作业的开发，我们有自己的作业平台，通过把这些原子操作分装到操作平台里面，我们把这些页面化。第三部分，我们规划运维，对我们的业务最熟悉的，需要去规划我的这些操作场景有哪些？我的需求有哪些？把这些场景分装起来，场景分装之后其实就是把我们的这些流程，把所有的运维操作流程，把每一步骤流程化，分装之后，对于我们后面的操作运维来说，就可以固化的进行工具的操作。刚才讲的三个运维，其实还有一个没有讲到，就是我们的操作运维岗位。我们来看一下，经过刚才原子的集成，包括页面化之后到最后的场景化分装之后，我们的操作运维就可以进行工具的操作了。这些业务针对百级以上的项目团队，这些项目团队他们每天都会提无数个需求给我们，比如说发布变更，包括一些配置管理的操作。我们如果是用原来的方式有运维做，这个运维肯定忙不过来，一个人要对几百个项目团队。因为这样的运维平台搭建以后有我们的操作运维团队基于我们的工具进行固化操作。运维实效看一下运维的实际操作效果，蓝色的部分是09年到12年的整个单据的总量，2012年7月份的时候蓝色线达到了最高点，也就是当时是在7月份的时候583单。红色线是我们操作运维，它通过工具对这些单据进行操作的数据，大家看到这个数据是546单，也就是说在2012年的7月份我们通过不断的工具建设之后，我们整个的操作运维，非业务运维进行操作，这样的一个比例已经达到了93%。基本上所有的单据都是由非运维去做，运维基本上可以不用再做这些日常的繁复的工作了，可以去喝咖啡了。需求有把运维的能力释放出来以后，业务也逐渐的下降，因为之前没有进行运维之前，大家看最早的时候这个蓝色的线09年到10年每年的突发量非常多的，通过这样的工具化以后操作运维固化进行操作以后，我们准备的单据量逐年下降。2012年7月份到12月份整个QQ游戏的业务突发出现了令人发指的运维故障，在整个运维团队里面，甚至每个Q都有团队上演着运维0故障的，因为我们的工具在日常工作里面落地，使得我们有更多的时间来做日常的需求之外的事情。同时的话，我们的故障也降的越来越低。刚才讲的整个QQ游戏作为一个运维团队怎么样在技术方面去支撑的业务的，由于我们的大量业务需求过来以后，很多的变更需要有操作运维去做，在解决了技术运营工具的基础上，我们还能去做什么呢？在QQ游戏里面有咖啡党在，需要跟我们的项目组沟通，需要什么工具？我们除了一些技术应用，还可以提供更多的工具。在整个游戏运维当中，在上QQ游戏平台这样的业务当中，其实它是有非常多非常多日常的运营工具，是需要去开发的，原来的模式我是一个产品的团队，我会把这些需求提给我的游戏开发的团队，游戏开发团队专门的同事来进行工具的开发，大家可能做过游戏都知道的。因为游戏开发本身会更专著在游戏内部的开发上，他们没有更多的时间去响应我们产品运维的需求，今天让我做一个小工具，做游戏开发的都有这样的经历，没有时间做这样的工具，这个时候QQ游戏的运维团队冲在最前面，因为他们和项目组团队沟通以后，包括之前的技术铺垫，让项目团队觉得我们对于工具建设，或者我们运维有能力做这样的工具建设的需求。在这之前运维只能做什么？只能做一些脚本，只能做一些固化的操作，因为我们的平台建设以后我们完成基础运维工具之后我们开始向产品的运维工具转化了。比如说对外业务配置的变更，甚至一些数据挖掘的工作，还有发公告，放奖币，以及日志提取，这些需求都有运维团队基于我们的腾讯平台做开发，原来开发这样的工具可能一个游戏开发需要一周时间，现在给到我们的运维团队，他们可能需要按天，甚至于小时去提供这样的工具。由此之后出现一个现象，项目组和运营团队，每次来都提很多需求，觉得好像有人专门给我们做工具，我是不是也提一些需求，他也给我做工具。包括游戏开发也好，都在很早期的时候一个业务上线之前都跟QQ游戏团队接触，去规划我们要开发哪些工具，可能在游戏上线以后这个工具就已经开发好了，大大提升了我们的运营效率，让QQ游戏的运维团队，工具开发能力，项目满意度也逐年提高。再上一张图，紫色的这个部分是我们QQgame的基于蓝鲸开发的工具，可以看到整个产品运营工具占到QQgame工具的50%以上，右边的这个图里面，整个工具里面操作的占比，产品人员直接去通过工具进行日常的运营操作，已经达到了42%。所以从这个数据里面可以看到，QQgame从技术应用工具到产品工具，在两层的标准化运维建设道路上走的非常扎实，也能够看出来整个团队运维转型做的非常成功。刚才说的这么多，归结到一点，在上面的这张图里面是我们整个运维转型的最标准的模式，一个团队里面有一个领导，再包括4个不同岗位的运维的同事在里面，他们各司其职，各自负责接收需求，包括工具的开发，包括日常固定的操作，这就是一个成功的运维转型之后的腾讯运维标准的模型。正是因为这些的探索以后从10年到13年整个QQgame的运维人数始终保持在5个人，在整个QQgame的业务线，项目组，开发人员和产品人员人数翻了无数倍，我们始终还能够保持5个人支撑的规模。所以从这一点可以看出来我们的人员转型以及工具建设在QQgame已经是非常标准的模型，也是非常成功的。QQgame运维团队是腾讯游戏的一个缩影，大家看到我有一个问题，为什么做标准化？因为大家刚才已经知道，腾讯游戏有300款，QQgame只是一个缩影。我们还有众多的运维团队，他们怎么样来进行标准化呢？这是我自己的一段总结，也代表蓝鲸的整个总结，来给大家念一下：“通过QQgame的创新模式，转型工具我们看到运维完全可以通过标准化的工具建设来解决业务爆发式增长与运维人员人力支撑间的矛盾，也就是运维可以用较少的能力完全业务中常规的工作。这种模式可以给更多的业务进行复用的，也就是运维作为技术平台的核心价值之一，也是我们为什么通过运维转型，通过QQgame这样的一个试点去进行整个腾讯游戏运维大团队的标准化的工作。因为我们的人力是有限的，需要有限的人力提升的业务技术团队的核心价值之一。”在整个腾讯游戏的大盘里面，尤其运维团队里面大盘里面有几十个运维团队，每个负责的游戏不一样的，有的业务是自研的游戏，有的游戏是我们合作代理的游戏，甚至于还有页游，还有手游，他们有很多不同类型的游戏。对于一个架构上面我们很容易的做一些工具，整体进行比较好的规划。但是对于游戏来说它的生命周期从上线一共有3、4年时间，不断的运营很多新的游戏，而且这些游戏，我们的运维团队大概有10到15人规模组成的，这些运维团队中间有很多的差异化。运维标准化与其面临的问题怎么样做标准化呢？我们对于标准化的建设，它是相对的概念，我们会提供更好的生态体系，提供工具开发的开放模式，让更多的运维有很低的门槛进来去开发他的这些工具。同时，我们再加上管理和审核机制，让体系可以更好的去运转。我给大家分享一下我们在整个标准化建设当中碰到的一些问题，可能也对大家有一些帮助。在我们整个标准化建设的第一个半年里面，2012年或者是2013年的周期里面，我们整个蓝鲸平台其实本身也是在发展过程当中，它周边的接口，原来知道我们内部除了自己的蓝鲸平台之外，还需要跟很多的业务系统打通，这样的话数据才能进行交互。当时碰到的问题，一个是我们的周边接口不丰富。第二，我们原来用的一些经验，我们认为把之前的做过30款40款的游戏，我们把它的一些步骤规范起来，在规范的基础上，我们再加一定的3个或者4个灵活性，让这样的标准保证它。这样的话我们的脚本是有标准的团队做的，并不是每个业务运维团队自己做这样的标准。我们在整个标准化过程当中，对原有的业务再改造起来成本也是比较高的。最后一个是整个蓝鲸平台并发的性能，最早期的时候，它是串型处理的，这是当时碰到的问题。因为这样的问题我们进行标准化的运维改革当中其实是失败的，只有一部分的业务可以去接纳我们整个的标准化的操作当中去。通过半年的思考之后，我们重新又对我们的标准化运维建设去做了思考。随着蓝鲸整个的工具平台逐步的成熟之后，我们接口比原来丰富了。我们的步骤比原来更灵活了，并且允许不同的业务进行自定义的制度。我们的脚本也可以自定义。在整个工具上线过程当中有审核，有开发的标准界定，帮助大家在一个有规则的体系或者环境下面更好的去快速的上线，去为业务服务。最后一点，并且支撑了并发的处理。帮助场景的模板化，我们通过这些方式把标准化建设，第二阶段里面做这样的优化。通过这样的建设之后我们发现我们有很多的业务可以逐步接进来，现在在腾讯游戏里面接入到整个标准运维工具里面的业务已经超过了80%以上。这些业务可以在整个标准运维工具里面进行自由的定义，以及操作，它们的准确去，包括任务执行的高效都是有保障的。我们来看一下14年的7月份到15年的7月份在整个一年里面整个标准运维建设之后，整个标准运维提供发布、开区、扩容，缩容、自定义等场景，整个任务2万3千930次，剔除了等待，以及中途未完成的任务，任务执行786个工作日的量，我们有更多的业务接到我们平台里面来，这样运维更可以喝咖啡了。服务化运维，从标准建设也是一步一步过来的，并不是一帆风顺的。做了这么多标准线以后，运维把这些精力都释放出来了，我们还可以做其他的吗？我们通过数据驱动我们的服务。我们在整个的服务化当中，非常强调我们的闭环服务，这也是我们在服务化运维建设当中，在每个业务的落地当中特别强调的，并且特别关注的。如果是说标准运维它解决了运维本身的痛点，包括技术运营也好，包括产品建设也好，在服务化运维里面，其实更多的要去解决的产品的痛点。大家都知道，标准化运维，作为运维来说我是指什么问题呢？需求给到我，我来根据需求进行，这样的运维是被动的运维。服务的运维是主动的运维，我们自己发现问题，并且通过我们的能力解决问题。我们服务化运维到来的时候，我们怎么样迎接挑战，实现被动到主动的本质的突破呢？腾讯游戏四大名著服务化运维的突破让我们一起看一下腾讯游戏4大名著的运维怎么进行服务化运维的突破。我们来看一下DNF这样的游戏业务里面，怎么样做运维的服务建设呢？我们在这张图里面我们看到绿色的线，游戏每年都有一个维护，我们需要停机进行更新的，平时不更新的情况下我们这个绿色的线，它一直保持着的，随着正常的胜利周期，白天再重新上，这是整个在线的走势。这张图可以看到，下面有两个圈，右边的这个圈是13年DNF在1月份的时候，更新以后，我们花了将近12个小时才让我们的在线恢复正常。在最左边的一个圈里面，是我们在今年15年的6月份的时候，我们在停机维护结束之后的0.9个小时让DNF在线恢复到正常绿色的水平。大家看到这样的一个箭头，我们从13年到14年到15年3年过程当中，我们不断的去打磨整个在线恢复运维服务的方案，这样可以自豪的说DNF的运维团队很精准的控制或者提供在线恢复的方案。我们看一下怎么样做到的？让我们DNF在线恢复从13年到15年缩短了将近10倍。首先第一个我们先来看一下技术优化，对于运维来说是最基础的解决方案。我们在线恢复的过程当中，有一个最重要的因子，我们所有的玩家更新以后进入到游戏的市场，如果补丁包越大更新以后进入游戏的时间越长，如果一个补丁包300兆在线恢复，大家看到的这根线，它很慢才能恢复上去。所以只有我们的下载，我们的补丁包更新速度非常快才能让所有的玩家开启之前准备好资源包，并且进入到游戏里面去。在整个下载优化里面，我们主要是针对补丁包下载方案。大家看到13年的版本当中，当时没有下载的，所有的下载都是通过APP的方式进行下载的，当时用户下载速度是157K，大家可以看到当时是1320几，耗了很多带宽，其实下载非常慢，是非常传统的运维的补丁包下载和在线下载方式，我们调速以后，整个下载速度提升485K，带宽的消耗峰值反而下降的。14年6月份的时候我们对我们的预下载方案进行第一个版本的试验，通过腾讯游戏的登陆器，我们通过预下载的方式进行补丁包的推送。14年的时候让整个下载速度提升650K，在今年的5月份的时候整个预下载做进一步的优化，除了登陆器一个渠道之外我们还通过了腾讯游戏平台，包括管家这些不同的平台进行推送，精准的推送之后让整个的下载速度提升1.2兆，带宽峰值进一步下降。这是下载的技术方案。大家知道如果仅仅是有这样的下载技术方案，能不能真正帮你精准的控制，答案是不能的。所以我们才有下一步。DNF的在线时常优化，非常核心的一点我们策略下发，大家看到在左边和右边各有两个指标，其中一个是用户平均在线的时长，右边是用户活跃时常分布，给大家分享一下我们在整个的优化过程当中碰到的问题。在一开始的时候我们采用了用户平均在线时常这样的数据来控制我们下载的速率，但是在这个用户平均时常里面发现一个问题，用户平均时常只代表这一天里面，或者一段时间里面某一个用户玩了两三个小时，到底这三个小时里面是上午玩的还是下午玩的，哪个时间段分布的不知道。如果用这样的指标可能只有50%的成功率，可能还有50%并不知道，已经精准的影响到两个小时的用户，可以估算出用户更新补丁包的时间，但是没有精准的推送给用户群，我们也有很好的预下载方案，但是没有办法精准的控制好到底有多少用户，可以在不同的时间段里面下载完这样的补丁包，在我们的运维开始以后进行到游戏当中来。我们在14年尝试这个方案以后，又对这些用户数据进行进一步的分析。我们发现在用户活跃市场分布的指标里面，把所有的DNF的玩家，按照一天24个小时去进行活跃时常的分布，也就是说可能有10%的玩家在今天的，他的时常是1个小时，可能在今天的某个时间段里面进行现在，还有一些活跃玩家3个小时4个小时的在线时常，可能从晚上8点到第二天凌晨2点。我们通过寻找这样的用户活跃时常的分布指标，发现这里面的一个秘密，什么样的秘密呢？我们可以通过更精整的策略的下发去控制我们推送给这些不同特征用户下载的精准度。比如说我们在晚间高峰的时候，我们可以把这个策略调整成对某一些大区，或者对某一些活跃用户进行推送，他可以去进行一个预推送的下载。但是对于那些热点大区，因为我们一方面要完成这样的预推送下载，最主要控制成本，我们也不是说达到峰值很高的高点，在热点大区最高访问的时候可能不会推送资源的下载，会在闲时进行推送。通过这样的方式，我们一方面把预下载的下发策略做精准的推送，同时我们也可以很好的进行带宽的消峰停补的优化。精准的策略推送非常重要的。这里面其实也让我们想到一点，这样的一个用户平均在线时常或者用户活跃时常分布，这样的数据其实在10年前产品运营数据里面已经记录这样的数据了。谁会想到它会和在线恢复时常有如此紧密的关联。所以我觉得在传统的运维工作当中很难想象的，只有获取到更多的数据来影响，或者发现有价值的数据。这样才能体现出来运维服务化充分的价值。除了这两点，大家知道游戏门槛登陆进来以后我们要进行正常的游戏了，在游戏过程当中是否还会掉线？我们整个在线恢复时常，如果你是游戏用户，可能今天中午进来的，如果我们不稳定，随时随地会掉出游戏区，第一游戏体验非常差。第二，对于大家来说花了很多成本经费，在大版本更新之后第一天，我可以让我的在线充高，或者这样的活动有更多人参与的时候，我们的情绪稳定性是不是也非常重要。我们在线时常恢复优化当中，还有一个非常关注的连续，记录游戏的掉线率，蓝鲸发展很多年，提供很多非常好的工具，我们通过蓝鲸提供的实时附载工具，看它的附载情况，甚至是秒级的，和开发人员定位问题，争取晚上高峰来临之前修复问题，从而保证整个在线修复的整体稳定。在DNF的孵化建设当中，在线时常优化的方案当中，我们提供了三个关键路径保证服务化运维。第一个就是技术优化。第二是精准策略推送。第三是实时采集保证我们的版本质量的持续的优化。通过这三点之后我们提升了玩家资源准备的成功率，同时又能够覆盖到推送精准的活跃玩家。通过这三点可以看到非常完整和非常尽心的运维服务建设，通过13、14、15年的三年过程不断的进行数据的积累，不断进行方案的打磨，在我们活跃用户的选择方面更精准的下发我们的策略，进入游戏以后实时抓取到进程，保证整个服务建设的完整性。除了刚才说到的DNF的案例之外，刚才也说到，一共有4大名著的三个名著，因为时间关系在这边简单跟大家分享一下做过的运维服务化的工作。第一个是我们的《英雄联盟》，大家可以看到这张图里面，一共有三条曲线，没有这样的服务化建设之前没有任何的数据看到《英雄联盟》排队的情况，包括它的容量，包括它大区的复杂，没有办法去分析出到底在排队当中出现什么问题？经常有很多人，有几万的玩家在外面排队，通过我们的数据采集之后，大家可以看到蓝色是我们的排队速率，大家发现在排队高峰和在线高峰都出现的情况下，大区容量没有满的，说明我们的登陆数据存在瓶颈的，需要提升登陆速率。我们13年开始就通过数据不断的优化和去提升整个《英雄联盟》的单区容量和登陆速率，通过数据有利的推动开发商优化程序的复杂性，也让整个《英雄联盟》的单区容量不断提升。大家知道整个《英雄联盟》日的活跃用户已经超过千万级，如果没有非常好的后端的保证，我们是不能保证这些玩家都能够在里面进行稳定的游戏，并且快速的进入到游戏里面。第二个《穿越火线》，我们可以实时看到玩家在整个《穿越火线》里面，怎么样登陆大区，包括哪些大区容量已经满了，我们需要在满了之后进行调整，给玩家去推送，当他登陆的时候给他推送，看到一些可以登陆的大区，可以迅速登陆到大区里面去，去获得活动的奖励，然后再进行比较良好的游戏体验。在这样的一个优化之后，整个《穿越火线》的大区容量，之前我们的大区容量只有80%到90%左右，通过这样的优化之后我们让整个大区容量提升到95%。第三个是QQ炫舞，要求所有在游戏里面的主播都能够跟玩家有一个非常好的活动，如果当网络的效果不理想的时候我们需要及时的进行优化，或者是进行处理。在这样的一个服务化的建设当中，我们和之前不一样的做法，我们在最早功能，在上线之前的2到3个月里面，我们已经开始深度参与到整个功能的开发过程当中，在这个过程当中和游戏开发团队有一个非常深入的沟通和讨论之后，我们制订了我们的网络探测工具方案。当这个产品功能上线以后我们通过这样的工具快速的去进行数据的实时采集，分析异常处理，形成闭环的信息联动，让用户使用视频的体验得到很好的保障。通过刚才的一些服务化的建设的分享，回到了我刚才一开始说的服务化建设的主题，我们认为在整个服务化运维建设当中以用户体验为基础的，所有的服务化建设都应该基于玩家进入游戏前和进入游戏后整个闭环的游戏体验，我们的工具，我们的运维服务的方案需要提供更多的基于数据，基于决策的方案来去影响或者提升玩家的用户体验。从数据驱动来说有两点心得，数据运营，我们平时会做一些常态化的数据收集，正是因为这些数据化收集才有很多参考，有了这些数据以后我们还要学会运营数据，也就是刚才在DNF里面通过3年不断的数据收集以后我们找到有价值的一些数据，从而能够去提升玩家的游戏体验。团队众多，服务如何落地？说了这么多游戏服务建设之后，大家想整个腾讯游戏有这么多的业务，有这么多的运维团队，你们怎么来让这些服务落地呢？我们可以看到这张图里面，我逐步把每一块打出来，其实大家可以看到，我们的服务化建设也不是说随随便便去做的，我们有这样的一个框架，我们有这样的一个思路去进行整个服务化建设的搭建，从这个图里面，我们可以看到整个的游戏运维服务体系。我们从12年开始进行建设，包括了一开始我们进行的整个理论的重建，包括去归纳整个腾讯游戏用户生命周期的线路。从而形成了整个腾讯游戏运维服务的体系。在下面还有很多的一些支撑平台，这个就是整个腾讯游戏的服务体系，我们也是依托于这样的体系下面去进行我们的服务建设的。再进一步大家在这里看到的我们整个服务场景的细化，我们会把游戏的服务场景分为版本服务、用户体验服务，运营服务，运营成本服务。刚才讲的无论是炫舞的案例也好，或者是DNF的案例也好，都是基于不同的服务场景，基于我们经验的累计，基于我们经验的收集进行服务的优化。这张表还在不断完善当中，将来可以作为游戏服务标准的框架，也希望让更多的游戏行业的运维，可以有所收益，也希望除了游戏之外，未来还会有更多的一些互联网的行业公司，或者是一些企业，或者一些运维，可以从游戏的标准场景里面获得你们本身行业的一些积累和标准。运维服务，成效喜人刚才讲的服务化的运维框架以及我们的案例之后给大家汇报一下我们在腾讯游戏服务建设的一些成果。除了刚才我讲的这些服务之外，我们还有很多固化下来的服务种类，包括登陆服务，包括下载服务等，这些服务都是从服务场景里面抽化出来，并且每半年进行游戏实践落地的。可以看到最近一年里面通过登陆服务建设以后，使登陆类用户投诉率下降50%，有的甚至超过80%，下载类服务里面，我们达到每百兆高的，下载速率100分里面可以完成，从小时压缩到分钟级别，通过版本服务我们提升用户的活跃度。讲了第一部分标准运维服务，讲了第二部分服务化的运维服务之后，我们到了第三部分智能运维，我们认为通过了之前的标准建设，通过了服务化建设之后我们有足够的平台，我们有这么多的业务数据，我们可以通过更好的闭环，通过更好的智能策略下发让整个游戏的运维服务更加智能。这就是未来运维游戏的未来，在智能化上。在智能化的运维服务里面有这么几点非常重要。第一点是业务数据的收集和清洗，经过大量的收集以后，去进行智能清洗以后才能找到每个不同业务的逻辑所需要的最核心的数据。第二点，希望通过复杂的场景进行智能分析，并且决策下发，我们精准的进行推送。目前还是一些人工做的，这一部分我们相信在未来智能运维服务里面，我们也可以基于复杂场景，基于智能进行分析，可以去智能化、自动化进行下发，而不需要人工干预。第三，所有的运维服务需要闭环进行自动执行，闭环对于我们运维服务基本要求，如果你不能做到闭环，你这样一个运维服务它的质量是会打折扣的，只有通过闭环之后，我们才能让这样一个质量可以被评估，并且被你的服务者所认可的。最后一块就是运维大数据影响产品运营决策，在去年分享里面，运维服务未来应该影响到产品的决策，我们希望通过更多的运维大数据这样的分析，以及我们一些建议和输出一些技术方案，能帮助影响到产品的运营决策。综上所述，在智能运维服务里面，成本和服务是互相兼顾的，同时智能化定义未来运维的建设方向。回到今天主题，腾讯游戏运维服务建设分享方面，从刚才我们一个简短的介绍里面，通过标准化来到了服务化，最后在智能化运维方向大步往前迈进着，这个也是运维的未来，我们相信只有智能化运维之后，运维的能力，运维的价值才会进一步去提升。这是前不久我去青海旅游的一些照片，在当中发生很多事情，我们的车坏了，我们在晚上很冷的时候，半夜里面开着车经过了3800米的高原，包括一些山，很辛苦，包括整个全程开了1千多公里。我觉得这个就像我们做运维建设一样，在整个运维建设过程当中，在从2010年腾讯游戏运维到2015年整个建设过程当中，我们也经历很多挫折，也经历了很多“坑”，我们一步一步也在往前走着。希望能在未来有机会和在座各位一起携手，让整个游戏运维，或者让整个互联网运维价值更大展现出来。最后给大家一记话，路虽艰辛，当旅途的风景值得大家期待！
觉得不错，分享给更多人看到
极客邦科技Geekbang 微信二维码
分享这篇文章
7月31日 15:07
极客邦科技Geekbang 最新头条文章
极客邦科技Geekbang 热门头条文章