主页（http://www.zhonghuagame.com）：游戏运维编年史 最详细的游戏运维指南
21世纪什么最重要?信息最重要!运维所需信息要涉及：机房、物理服务器、虚拟机、交换机、网络、承载业务、业务配置、承载服务进程、端口等信息。不管是自己采购还是购买云服务，物理服务器和虚拟服务器都做为资产存在，在采购后录入相关的资产管理，给它打上标签，属于哪个游戏，哪个平台，这样不同游戏平台间就不能混用服务器了。然后，是再给不同的服务器标识它承担的业务角色，比如它是MongoDB，我们需要打上的标签会是大掌门-APPSTORE-MongoDB-主库-90000端口-第一组服务。这样一个基础信息录入就完成了。
业务监控
6、数据的出现丢失或错误，整体数据回滚。谁来保证?怎么保证?
批量管理的难点在于：
配置管理：nginx 、apache、lighttpd、MySQL。
随着私有云转为公有云、云时代推动着云计算以及移动互联网的发展，网游行业慢慢进入了手游黄金时代，云时代的变革不仅挑战了整个游戏行业，也挑战了游戏运维。
1，构建CMDB
f. 等等
这里说的不止是网游，前不久育碧旗下网游大作《全境封锁》上线时闹出个小笑话：由于很多国内玩家下载之前没注意是网游，下意识的以为育碧的游戏肯定是单机，好不容易下完之后才发现玩不上，进而发生了不少的骚动。这不是第一个发生这种情况的传统游戏厂商，肯定也不是最后一个，很多有名的游戏公司都在做类似的尝试，Popcap的《植物大战僵尸：花园战争》系列，暴雪的《暗黑3》等，甚至那些还有单机成分的大作也早就开始网络化：大名鼎鼎的《GTA5》、FPS风向标《使命召唤》系列和《战地》系列，网络联机部分的比重也在一年一年的增加。
3.2 手游运维业务范围：阿里云、 亚马逊 、UCloud、 蓝汛CDN、 听云监控。
e. 对于关系型数据库磁盘读写慢问题突出。
2，青铜时代：页游
采用5分钟压缩包的另外一个原因在于每台服务器每天产生业务日志大概有5-6G的数据，分到5分钟后，切割完每个文件就是20M-30M，压缩后只占用很少的空间。这样就解决了占用大量带宽的问题。
这样的信息只要是用来将来批量化部署、管理服务器使用，以及当出现故障时，运维可以很方便的查询相当的服务器以及服务信息。但是数据的及时性、准确性、可检查是一个难点。
2、大掌门使用了听云Server，能够对服务器响应慢和不可用进行定位，查看慢应用追踪和Web应用过程功能，能够实时定位消耗资源最大的代码和语句，这样就能帮助实时进行有针对性的调整和优化，并且可以快速定位问题时间，最快能到分钟级别。
想要了解如今的游戏运维，不得不从早期的端游运维开始说起。对于08年入行端游，11年经历过页游最后14年全面接触手游的吴启超来说，这几年的游戏运维经历让他深切感受到运维思路的巨大转变。
邮件服务器：postfix +sasl +ssl 收发服务、反垃圾邮件服务。
d. 人员账号权限管理，权限分发及回收
2. 社交化的页游
3、数据的准确性谁来保证?日志内容不对、切割不对、传输丢失、入hadoop过滤
运维开发：写着各种的逻辑，因为业务、网络环境、BUG、刚刚帮忙扛完服务器。
在2011-2013年左右的页游运维，游戏市场处于探索期，其实运维也处于探索期。端游时代每个新服都要经历上架、装系统，装服务的过程，一般一到两周可以上线一个区服，对于端游高粘性低流动的特性来说可能还好，但是当页游出现时，转变给运维带来的冲击无法估量。页游时代1天开100多个新服的概念，是传统端游运维所不能理解的。当时的运维认为页游就是把所有服务器实现自动部署服务，同时搭配运维自动部服工具就可以了。但事实上如果在开服时一组一组的使用物理服务器，开服速度根本跟不上，资源浪费还非常巨大，两周后用户留存率仅剩5%-7%。成本巨大亏空，急需技术转型，这个时间点上出现了两种概念影响了以后的手游以及云的发展。
b. 虚拟机网卡，超负荷down、丢包
对于数据方面，运维的压力来自于需要贯穿及掌握所有的数据，并且为所有部门服务。简单的以下图的ETL为例：
系统运维：安装各种软件，调试各种不兼容的软件，在各种版本的Linux、Windows上。
b. 执行过程中，不同功能的不同权限要求
网络质量监控：somkingping各个机房的交换，各个安放点服务器。
除了性能和硬件监控之外，对于游戏业务运转是否正常也需要建立一套标准去评判。
3，黄金时代：手游
说完了游戏运维的历史，我们要开始今天的重头戏，如何做好游戏运维?这里就用吴启超的一个冷笑话作为开始：运维为什么存在?a，有服务器;b，因为研发忙不过来。不管是笑没笑，运维确实因为上面两个原因才会诞生的。那么回到正题，想成为玩转上千服务器的游戏运维应该怎么样做呢?系统部运维构建大致如下图：
那大掌门又是如何解决这些问题的呢：
传统运维，任务道远，正因为有过去那些年的翻译文档，兼顾整合方案，以及大批分享技术的前辈、社区，踩着前辈一步一个坑的走过来，才能有今天的运维的局面。
5、数据传输后需将数据放到数据仓库(DW)中，数据下载完毕后会根据文件进行存储，当天的数据按照5分钟1个压缩包进入MySQL，MySQL则进入当天的查询。在数据仓库中，数据包按游戏及平台进行分类，这种格局的安排为了在并发时更好的运行。由于游戏与游戏之间是隔离的，因此按照这种模式是为了保证数据进行顺利并发。
4、数据ETL过程监控，如果出现数据丢失怎么办?
1、日志切割工作谁做?研发还是运维。日志切割按什么规则?大小还是日期?
CMDB不是TXT文件，而是要变成EXE文件。运维在面临大量服务器的情况下，批量化工具的出现成为必须的结果，在日常的工作当中需要把其流程固化下来，为完成批量化安装、管理打下基础。大掌门喜欢使用 ssh sshpass paramiko libssh2这些基础的技术做批量管理。原因是不用安装简单、稳定、安全、可控。当然吴启超也表示推荐大家使用在市面上流程行puppet、Ansible、SaltStack等技术，为什么?简单、简单、简单!下图就是在做自动化半自动化运维过程中的模型。
e. 物理服务器、云服务器统一化安装及老项目改造
1、将数据日志进行切割(按照业务打包日志)并合理命名。比如A登陆日志，B充值日志，C消费日志。分门别类进行打包后，对数据每5分钟切割1次，并生成md5包。
3.1 手游的运维工种：系统型运维，业务型运维。
静态缓存服务器：squid + apache|nginx
IDC运维：装机、换配件、扛着2U的服务器全国各个机房来回跑。
d. 多虚拟机间的安全访问，虚拟机与物理机间的安全管控
数据对于运维的痛点：
3.3 手游游戏服务器架构：一般来讲都是以一组服务器集群为一个平台单位，不同的集群提供不同的服务。
4、产品：关心功能热度、用户体验
a. 命令的并发执行，要控制各点的超时时间
c. 多虚拟机间争抢cpu、内存
