诸天域

笔者从20年开始参与某大中型手游运维工作，以及在组内其他游戏运维经验的见解
粗略描写，后续补充

叙述

游戏运维面对的挑战

架构复杂多样化

游戏架构大多架构复杂，为了应对海量的用户，架构上都是高度集群以及分布式

模块数量多

随着游戏生命周期的不断延续，其运营的过程中，会随着运营的发展不断增加模块来支持不同的玩法和活动，我所接触的某fps手游就多达100以上的游戏进程模块。

发布频繁

游戏运营过程中，必然随着运营所带来的各种活动和策划的玩法修改，必然会有不断的频繁的发布。这就要求运维必须有能力支持这种频繁的发布，特别是面对复杂游戏业务的时候。

有状态过多

游戏一般为了保障用户体验，大部门的游戏模块都是有状态设计，这就导致了不能像web应用可以使用大规模无状态应用的发布方式。对于有状态的应用的发布，必然慎之又慎，避免用户数据丢失导致的用户体验和用户投诉。

不停机发布的挑战

为了保障用户的良好体验，越来越多的游戏都开始建设了不停服发布的发布流程，就是为了保证玩家体验不中断。但是不停服就给游戏架构和运维带来了挑战，如何建设一个稳定的不停服发布流程是需要运维和开发需要不断沟通设计的。

准备阶段

本章阐述游戏的基础准备内容，运维人员应该在游戏正式发布之前建设好以下内容，在随着游戏运营的不断发展进行调整。

机器资源容量评估

机器资源容量评估是一个非常重要的准备工作，我们对于容量评估必须保证合理以及冗余。

• 模块数量
• 单模块承载容量
• 机器非游戏进程的以外其他进程的消耗
• 适量的冗余
• 我们必然保证模块从前往后应该逐渐冗余，上游模块压垮下游模块

容量评估完成，必须沉淀为标准公式即

当前预计容量 / 单模块单机（需要明确机型）容量 = 机器数量

完成标准公式是为之后的标准化流程建设准备

CDN容量评估

CDN是游戏成本的大头，我们需要考虑每次发布所需要的CDN容量，来进行必要的容量准备，以及可以的成本优化。常见的成本优化方法

• 预下载
• 边缘CDN
• P2P下载

成本核算

运维需要对游戏消耗成本的高度敏感，我们需要了解游戏成本方方面面，明确占比，在必要的时候，需要进行成本优化，将不必要的成本优化掉，减少必要的浪费。

• CDN
• 机器成本
• 储存成本
• 营销机器成本

机器初始化准备

我们需要梳理机器所必要的一些初始化的准备

• 网络内核参数调优
• 运营目录结构
• crontab定时作业
• 必要的非游戏进程（监控，管控，数据上报）

模块划分

我们需要按模块合理划分游戏进程，这一步一般需要和开发进行沟通考虑。运维侧最好有相关的元数据管理系统，沉淀模块信息。

统一的基础设施建设

一个统一的基础设施是非常有必要的，避免人员迭代以及不规范的一些操作导致线上环境不断发散腐烂。

基于虚拟机或物理机器到运维基础设施建设

统一的机器镜像

我们最好事先准备一个统一的机器镜像，里面安装了必要的软件和去除不必要的东西。

统一的脚本

我所见到很多老运维对于脚本管理简直是混乱不堪，线上存在许许多多的脚本，而不明确每个脚本的作用。我们必须建设统一的cli工具作为统一运维console工具的入口。虽然shell是运维的强大工具。在这里我推荐的是go来构建统一的cli工具。

• go直接打包成可执行二进制，不分散文件
• 静态语言的特性保证了工具的质量
• 不需要关心机器的运行环境

统一的cli工具的优势

• 唯一的操作入口
• 沉淀工具脚本
• 各个环境版本一致

统一的配置

上面我们说了建设统一cli工具，那我们的环境配置也需要统一的配置，通过统一的环境配置，我们可以在不同的环境通过不同的环境配置就可以达到不同环境一个脚本一个操作，而不必不同环境单独书写不同的脚本。操作统一，避免事故。推荐yaml形式作为配置。

版本化的管理

我们以上的统一的建设，都必须要做到一个要求，就是版本化的管理。我们可以使用版本管理软件将以上建设纳管。 我们就可以建设一套基础设施管理的流程。我们可以通过软件开发的方法保证我们的基础设施的质量。 我们遵循gitflow或者github flow的方式，来对我们的基础设施进行发布管理 然后通过CD工具自动发布到全部的机器，保证全部环境的统一。

基于容器的基础设施建设

随着业务上云的趋势。我们也在探索容器在游戏领域的探索。

k8s集群的基础设施

首当其冲就是k8s集群的管理，这里建议的是最好是托管到各个云平台的容器服务，自建k8s集群需要投入必要的容器运维人员。

helm配置管理

容器的配置管理自然是helm，我们需要根据游戏架构的设计，进行对应template的文件编写。

流程管理

流程是一个游戏运营生命周期非常重要的一环，最好是有一个流程编排系统，并且打通相关的系统。方便我们进行流程的编排和自动化。 我们的要求是 - 不需要人的地方，由工具操作 - 需要人的地方，工具辅助人操作

虚拟机或物理机

发布流程

一个完整的发布流程一般有以下部分

• 当前版本容量评估阶段
• 机器准备阶段
• 机器初始化阶段
• 产物发布
• 进程发布
• 检查
• 发布完成

不停服发布

不停服发布需要游戏架构支持，一般的不停服发布主要有以下方式

• 两个版本两批机器

  • 发布不影响上一版本
  • 需要版本发布期间需要两部容量的机器

• 机器分批发布

  • 模块需要数量需要为2n以上，避免分批发布过程中，出现单点
  • 需要架构支持玩家下线不在路由导向另一批机器
  • 存在一定的用户体验影响，强制引导另外一批机器入口

停机发布

停机发布只要遵循正常发布流程即可，需要运营侧发布正常的停机公告。

容量调整

在游戏运营过程中，我们不可避免，某次活动导致玩家人数上升，需要扩容机器，某段时间玩家人数下降，导致缩容机器。

扩容流程&缩容流程

游戏进程一般分局内局外进程。所以正常的两块的机器是不一样的。

• 扩容流程

  • 机器准备
  • 分发对应游戏版本产物
  • 启动进程
  • 检查
  • 扩容完成

• 缩容

  • 等待玩家下线（需要进程支持配置模块不接受新玩家）
  • 停止进程
  • 检查
  • 机器下线

故障替换流程

• 替换流程
  • 新机器准备
  • 分发对应游戏版本产物到新机器
  • 启动进程
  • 检查
  • 切换
  • 替换完成
  • 下线故障机器

可观测性建设

在游戏运营过程中，我们必须建设好业务的可观察性，避免故障发生，没有及时的发现，以及方便的排除各种问题。

必要关键链路

• 登录
• 注册
• 在线
• 付费
• 对局

指标

业务指标

• 在线指标
• 登录指标
• 注册指标
• 付费指标

机器指标

• cpu
• 内存
• 磁盘
• 网络

日志

需要建设必要的分布式日志系统，以及统一的日志规范。 可以基于ELK开源方案构建日志系统。 或者云厂商的日志方案

分布式跟踪

游戏模块后台链路复杂，最好游戏支持从客户端开始的分布式跟踪协议,这里建议的是opentelemetry ，最好支持染色机制，排查特定的链路问题。

告警建设

建设好可观测相关的内容之后，我们就可以建设稳定的监控策略

• 各种环境的策略
• 策略的干系人
• 策略的阈值
• 策略的对象 随着建设的不断完善，我们也可以建设智能监控相关的能力。

运维需要的相关工具

• CMDB平台
• 作业系统
• 文件分发系统
• 版本管理系统
• 流程编排
• 可观察性平台
• 文档系统

游戏数据分析

我们需要建设游戏领域的数据场景模型

• 在线场景
• 登录场景
• 注册场景
• 付费场景
• 网络场景
• 客户端路径
• 服务端路径
• 游戏地图分析
• 客户端设备分析