很高兴昨天上午收到了 anguskwan的邀请， 今天我简单介绍了我目前在公司扮演的角色－－运维技术支持
一，大家的关注点
一款好的游戏，不仅仅能吸引玩家，还能让玩家感受到较好的运营质量（如客服的响应速度，停服的时间控制，无缝体验等等）
作为公司的策划和研发团队往往更注重游戏本身的可玩性和较低的异常现象（卡战斗，出现刷xxx Bug，更新出现异常等）
作为公司运维，客服，则更关注游戏本身的运营品质。比如部署成本，维护成本（更新，迁移，性能，备份等）；玩家较少的抱怨。
作为公司另外一个特殊团体：运营技术支持组 则充当了研发，运维和客服的中间桥梁。以运维的思维融入产品来简化游戏运营成本。
二。运营技术支持的作用
当一个产品需要从RC版本进入产品验收环节，我们的运营技术便 介入代码包装，并与研发时刻 商讨对其进行运维级别的优化改良：部署测试，更新测试，性能测试和数据监控，目的是尽可能的降低运维成本，提高运维效率，减少故障点，使得我们的一线运维人员能较快、低故障的进行产品准时发布。
a.下面以一个完整的游戏流程为例
Oh,My god ! 周五做了课题演示，丢在公司服务器上，忘了拷贝的笔记本了。。。
b.假设现有流程运维比较复杂，且从代码级别进行优化成本过高
c.游戏代码功能运维功能较弱
d.游戏状态异常捕获
e.存在性能瓶颈
f.数据分析
B.当游戏运维流程比较复杂，体现在 游戏版本部署，更新和搬迁几个阶段
流程解剖
版本部署无非以下几个元素 相关的ip，端口号 目录结构，认证 权限 等
我们可以通过维护一个配置列表用变量来实现自动化更替大量的配置文件ip和端口号
我们可以通过使用相对路径和分类归档来实现游戏的搬迁启动和配置自动化遍历修改
版本更新无非以下几个元素 必要的停服流程，相关代码包目录替换。假如存在缓存，我们需要确保缓存文件在停服过程立即存盘。可能某些大版本变动会显得类似版本部署
游戏服务器搬迁 停服，写完干净缓存（或迁移），迁移代码和配置包， 再进行一次版本部署
运维希望部署尽可能简洁，但很多时候代码已经写死了，没法简洁。
从运维生产线返回的情况，我们可能犯错的地方 是配置各个元素出疏漏。但可以通过运营支持与研发协调 对相关元素进行初始化校验，必要提示，即可避免很多常规疏漏。
C。游戏运维功能较弱体现在故障排查阶段，运维人员很难定位故障点。
主要原因是游戏日志缺乏必要的明显打印，这个开发量不大，但运维的意义很重大。我们的脚本可以通过捕获这些必要打印来获知游戏状态在哪个程面出现异常。而不用很费劲的分析故障原因，因为故障原因已经被打印出来了。比如“认证通讯接口启动异常”或“无法接连数据库” 而不只是一连串代码报错。
D。游戏状态异常捕获这个功能特别重要，有助于我们提高代码的运营质量，分析潜在问题。
比如某天晚上22点 某个游戏的进程占用cpu 90％（正常值为59％），持续时间5分钟。 5分钟后状态未再现，该如何捕获？
如果我们有一套很好的监控系统的同时，能有大量的游戏调试接口被脚本监控和调用那就能捕获这个异常。
比如cpu达到一定值，我们启动一次代码状态全打印到日志，当然启用次数会在脚本做好时间间隔限制。
E。性能瓶颈，这个也强烈依赖于我们的监控去提前预测，通过监控日志，我们可以发现玩家在线数 游戏内活动触发状态。监控系统，我们会发现 带宽 cpu 内存 IO 数据库 之间的某种联系。
也有助于研发在后续开发中把这些可能关联的数值进行可配置化，来激活我们的排队或cache机制。
当我们的一线运维在忙碌于日常维护工作的同时，我们有很多的时间去思考如何改进目前架构和降低成本，如何让下一代的运维更精简高效融入到游戏本身中。
F。数据分析。 很多时候我们的gm工具无法满足现有可能，就需要我们的一线运维登录服务器对原始数据进行分析。 大多数是对文本文件的字符串进行过滤，统计，运算。 初期我们可以通过先手工来现实，但由于随时可能需要查证原始数据，这个工作量大，于是复杂的log.sh 脚本单身了，但起初它可能是功能单一且不能通用的。
日志分析器的通用，需要我们游戏代码对日志进行尽可能标准化符合运维思路，这样有助于我们高效处理大规模数据，而不用经常性去写过于复杂的字符操作脚本来供大家分析使用。
三。运维人员的技术演变
一线
高度的责任心
规范的操作流程
常规部署
日常维护
二线
一般故障分析，近期无法改进的高成本运维操作，知识管理一线
三线
运营技术支持
张海锋
2010.08
阅读(1161) | 评论(0) | 转发(0) |
