Linux就业技术指导（七）：游戏类运维重点流程解析
一，某游戏公司例行上线与更新流程示例
例行维护/更新流程
1.1 更新前天
提前确认好要更新的是什么，更新会有人通知你，一般是运营人员
比如：我们明天做什么什么更新
1.2 第2天更新
一般固定点更新，会先收到更新邮件
运营人员会发公告给玩家，说我们什么什么游戏，几点进行维护
比如：10点更新：
（1）关闭游戏端口，禁止外部访问，对自己公司开放（更新完要测试）
通过防火墙脚本实现（参考公司已有并在线上正常使用的脚本）
（2）停止游戏程序
如果做了监控，停服前可以关闭监控，如果你知道是自己在停服，也可以不关
这个问题具体要问开发，我们公司就是停止游戏程序的时候会把数据写到数据库，所以等程序关闭后再备份。（如果不先停止游戏程序，那么会导致数据库的数据不一致）
（3）备份数据库
通过脚本实现数据备份并问下研发需要备份哪些库
备份完毕后，检查备份的数据大小，判断是否与前几天备份的数据有没有太大的差异（差距太大表明有问题，需要检查）
（4）通知相关人员进行更新操作（一般是开发，也可能是自己，根据公司情况而定）
如果是你自己做更新，先看看是什么更新（促销更新，版本更新，web更新等）
那就得根据是什么更新，就执行什么更新操作（开发会给更新流程），如果有老人带，做完后总结下（这样自己会更明白些）
更新内容，比如添加几个文件，数据库添加字段等，熟练后可以写成脚本
（5）启动游戏程序
当更新完毕后，就启动游戏程序，以便进行下面的测试
（6）通知相关人员进行测试（研发，测试人员，运营人员等）
游戏能不能正常打开，能不能正常登录，该更新的东西有没有更新好
（7）打开游戏端口，允许外部访问
如果测试没有问题，运营人员会说，可以开服了；就可以把游戏端口对外，就是玩家可以登陆游戏
和相关人员确认好什么时候可以停止游戏程序操作（停之前备份数据库还是之后）
1.3 总结
- 接收到更新邮件
- 查看是什么更新
- 不同的更新执行不同的更新流程
- 和相关人员确认好什么时候可以进行更新操作
- 到了更新时间后进行更新流程
- 连上需要更新的服务器
- 执行防火墙脚本，关闭游戏端口，禁止外部访问，对自己公司开发
- 停止游戏程序
- 备份数据库
- 通知相关人员进行更新操作
- 更新完毕后，启动游戏程序
- 通知相关人员进行测试
- 测试没问题，执行防火墙脚本，开放游戏端口，让玩家登陆游戏
1.4 注意事项
更新前操作：
（1）收到更新邮件，可以先确认邮件中更新文件是否能够正常下载
机器比较多，开发也很忙，有时会出现，开发并没有把包上传到固定的机器或者没有传好之类的。
（2）确认好更新维护时间
一般是固定时间，然后运营人员要对玩家发布公告
（3）可以先连上需要操作的机器
（4）如果做了监控，停服前可以关闭监控，如果你知道是自己在停服，也可以不关
（5）检查游戏开放的端口
进行更新时：
（1）第一步关闭游戏端口并确认端口确实关闭了
（2）停止游戏程序并确认确实关闭了（可以通过查看进程的方式，如果是java写的程序，直接ps -ef | grep java即可）
（3）执行备份数据库的脚本并验证备份文件的大小是否正常
（4）备份好了后，通知相关人员进行更新操作并确认更新正确，比对md5，文件时间等（如果是自己更新，就提取准备好更新的步骤；熟练后，可以写成脚本）
（5）所有服更新完毕后，启动游戏程序并确认启动成功
（6）通知相关人员进行测试，比如，是否能登陆游戏，登陆游戏后需要改变的地方有没有改变（一般运营人员操作）
（7）测试没有问题，执行防火墙脚本，开放游戏端口，让玩家登陆游戏
1.5 游戏业务类专业术语解释
- [x] 合服：其实就是合并玩家数据（例如：1服和2服合并，其实就是合并玩家的数据，将1服数据导入2服数据库，然后1服就能用来开3服了）
- [x] 混服：就是同一个服务器，运营两款不相同的游戏
- [x] 同服：在一个配置比较高的服务器上，同时部署两款相同的游戏，比如火影忍者，可以部署1服2服等（就是将程序拷贝一份，修改端口等在启动====>类似多实例）
- [x] 跨服：多个服的玩家在一起玩，比如1，2，3，4服玩家都在一起玩。
