以“工匠”的精神对待每一个版本
“工匠”精神具有精益求精、严谨、一丝不苟、耐心、专注、坚持、专业、敬业。
游戏每一次版本更新对于玩家来说都是非常值得期待的,版本准备、版本验证、版本更新、版本更新后的每一刻,不只是体现游戏开发、策划者的独具匠心,版本如何顺利发布给玩家,并且助力玩家完成更新,都凝聚着游戏业务运维人的”工匠“精神。
日常版本
QQ炫舞、DNF分别为MUG、ACT类游戏,前者一个月一个版本,后者可以达到一月八个版本。
QQ炫舞每个月的版本只有一个,所以经常会伴随着架构调整、新的系统接入、功能、活动开放,以及运维侧遗留下来的环境类变更。因此长时间的发布准备,详细的checklist是每次发布前的例行工作。
由于版本发布还伴随了较多的变更,在老的流程下单次停机时长高达6小时,较影响玩家体验。
为了压缩每次的停机时长,运维侧会把很多工作都挪到发布准备时间,保证运维的发布操作时间控制在0.5小时之内;同时测试同事会加大灰度发布的测试覆盖度,全服发布只需过基本功能即可,在此基础上继续增加测试人力;通过如上的一些努力,保障每月一次的发布控制在3小时左右。
DNF为动作类的MMOG游戏,需要不断更新版本内容以吸引玩家,由于游戏逻辑处理的不同,导致外挂较多。
在不断更新游戏内容及反外挂对抗功能的背景下,DNF的版本频率达到了惊人的每月八次。任何一次的运维失误、或响应不及时都会影响到最终外网版本的发布,为保障每次版本高效、高质的更新测试服、体验服、及外网。
运维侧与韩方规范化了版本交付流程,通过这个规范实现标准的版本更新,与版本质量跟踪app;同时将标准化的版本更新作业交付一线同事操作,以减少运维人力。
DNF版本更新app如下图,填好参数后一键执行更新:
运维会对发布到现网的版本质量进行跟踪、监控,以便能及时发现现网问题并处理;同时可以根据带宽使用、在线恢复趋势等数据制定更好的发布策略,以优化发布成本,提升玩家的体验。
如下为版本发布前后状态对比(停服前30分钟、起服后30分钟、60分钟3个点):在线趋势(主要指标)
其他趋势指标
- 1、程序负载
- 2、程序稳定性
- 3、掉线量
- 4、支付
- 5、下载
- 6、突发
通过上面可以看出,不同的业务版本侧重点会有不同,运维侧要做的就是保持与开发商、项目同事的紧密沟通,共同优化版本更新中遇到的问题(停机时长、更新频率)。
大版本支撑
QQ炫舞为国内代理游戏,其大版本主要集中在功能的横向扩展上,如不断推出海滩社区、舞厅社区、KTV、视频秀等功能,不断丰富游戏的玩法。
这些版本需要进行架构调整、新的api接入;运维侧需要进行机型选型、容量压力评估、物理架构的调整、监控跟进等等。
方案选型:炫舞是第一个做视频秀的端游,没有其他游戏可参考。当时是参考了内部几个流媒体产品,最终确定视频技术+流媒体CDN的方式实现。
架构优化:多点部署主播接入点,从源头保障视频流的传输质量。推动CDNProxy等关键模块热备实现,并分物理机部署,在机器故障时保证关键功能可用。
成本:小流量模块使用虚拟机。
体验监控:监控方面,运维在产品前期就推动开发在客户端、服务端进行了详细的日志记录。如tqos日志实时监控玩家、主播端的质量;服务端的oss log实时分析玩家异常行为。通过监控->优化的闭环不断推动玩家体验提升,大幅提升了视频秀稳定性,且投诉下降20%左右。
DNF主要在玩法的横向与纵向扩展上,如新的职业、转职、觉醒内容的添加,游戏决斗场改编、地下城改编,等级提升等方面。且大版本的内容基本是从韩服版本直接拷贝过来进行修改。相当于服务端的程序基本是全新的,无论从性能,稳定性,以及bug数量都会对运营带来很大的挑战。同时超大的客户端更新、黑盒的db工具变更也会对运维带来不少挑战。一般会经过十几个版本的迭代测试才会上到现网。
版本迭代:创新世纪版本约经过20个子版本,50次的测试环境更新才上线到现网。这期间更新效率、质量都需要得到保证。因此DNF运维开发了测试环境更新app,将更新全流程打通以提升效率;并将更新内容入库,保障更新的准确性。
“DNF2013年发布的超大更新包,导致CDN带宽翻倍,直接垮掉”。有了这次惨痛的教训之后,DNF是这样更新超大包的。
- 预下载
- 拆分包,资源包拆分并且提前分发
- 提升p2p率
- 阉割版完整包提前外放
- 网吧预推送,网吧用户预下载无法触达,进行网吧预推送。
DNF大版本改动内容很多,因此在服务端更新、db变更、测试上都需要花大量的时间,导致停服时间很长,从收入、口碑产品都有直接影响。一般大版本的db变更、测试时间会占到总时间的80%。我们在保障质量、压缩时间方面做了如下调整:
- checklist评审,涉及完整性、回退方案、效率等方面。
- DB变更提前在小型区、大型区、合服区的DR上进行测试,保证每个区都能正常执行。
- DB变更执行多并发,并利用tmysql在线加字段等特性节省变更时长。
- DB变更按数据量大小分两批同时执行,小数据量的大区即可先开区测试,待测试完成后,大数据量的大区也以起服并测试,这样会充分利用测试时间。
下图是14年大版本在优化前后的时间对比:
转自:腾讯大讲堂
- 目前还没评论,等你发挥!