第2章核心指标

核心指标：RTO、RPO、SLA、SLO，如何定义游戏业务的可用性？

聊到高可用架构，很多人第一反应就是「多部署几台服务器」、「搞个集群」。但说实话，没有量化指标的可用性，都是耍流氓。

你想想看，老板问你：「咱们游戏服务器稳不稳？」你怎么回答？「还行吧，基本不挂」？这种话在技术评审会上根本站不住脚。

所以，咱们得先统一度量衡。游戏行业里，最核心的四个指标就是：RTO、RPO、SLA、SLO。我习惯把它们分成两组来理解。

这两个指标，说白了就是回答两个问题：「挂了多久能修好？」 和 「丢了多久的数据？」

RTO 指的是从故障发生到服务完全恢复，所允许的最大时间。比如 RTO=5分钟，意思就是：从你发现游戏登录不了，到玩家能重新连进来，必须在5分钟内搞定。

我在项目中遇到过最头疼的情况，就是核心数据库挂了。当时我们定的 RTO 是 15 分钟，但实际演练时发现，光是从备份机拉起数据库就要 10 分钟，再加上检查数据一致性、切换 DNS，根本来不及。后来我们不得不把 RTO 放宽到 30 分钟，同时优化了切换流程。

注意：RTO 不是拍脑袋定的。它直接决定了你的灾备方案成本。RTO 越短，你需要投入的热备资源就越多，成本呈指数级上升。

RPO 指的是允许丢失多少时间的数据。比如 RPO=1分钟，意思就是：如果服务器在 14:00 宕机，恢复后最多只能丢失 13:59 到 14:00 这一分钟的数据。

嗯，这里要注意，RPO 和备份频率直接挂钩。如果你每小时做一次全量备份，那 RPO 就是 1 小时。如果你用 binlog 实时同步，RPO 可以做到秒级甚至零丢失。

我曾经见过一个项目，RPO 定的是 5 分钟，但实际用的是每 30 分钟一次的冷备。结果真出故障时，丢了 25 分钟的游戏充值记录，玩家炸了锅，运营团队被骂得狗血淋头。说白了，指标和实现不匹配，就是给自己挖坑。

指标	定义	游戏场景举例	常见实现方式
RTO	恢复服务所需的最大时间	玩家登录、匹配、战斗等核心功能恢复	主备切换、多活架构、自动扩容
RPO	允许丢失的最大数据量（时间维度）	玩家充值记录、道具获取、等级进度	实时同步、增量备份、WAL 日志

RTO 和 RPO 是内部技术指标，而 SLA 和 SLO 是对外的承诺。

SLO 是你给自己定的目标。比如：「核心战斗服务，全年可用性达到 99.99%」。这个目标通常比实际承诺的要高一些，给自己留点余量。

我个人的习惯是，SLO 定得稍微「狠」一点。比如对外承诺 99.9%，内部 SLO 就定 99.95%。为什么？因为你要考虑到监控误差、人为操作失误、第三方依赖抖动等因素。你想想看，如果 SLO 和 SLA 一样，那每次故障都踩在红线上，运维团队压力太大了。

SLA 是正式对外承诺的可用性指标，通常还附带赔偿条款。比如：「游戏登录服务可用性不低于 99.9%，每低于 0.1% 赔偿当月流水的 1%」。

这里有个坑，我曾经踩过。有一款游戏，我们对外承诺了 99.99% 的 SLA，也就是全年宕机时间不超过 52.56 分钟。结果一次机房光缆被挖断，我们整整宕了 2 小时。那次的赔偿金额，够我们运维团队干一年了。

  核心观点：SLA 是商业合同，SLO 是技术目标。千万别把 SLO 直接当 SLA 签出去，否则你会被运营和法务追着打。

好了，四个指标都讲清楚了。那具体到游戏业务，怎么定义可用性？我一般分三步走：

划分业务等级：不是所有功能都值得 99.99%。登录、支付、核心玩法是 P0 级；聊天、排行榜、好友系统是 P1 级；活动弹窗、新手引导是 P2 级。不同等级，RTO/RPO 不同。
设定量化目标：比如 P0 级服务，RTO=5分钟，RPO=0（零丢失），SLO=99.995%；P1 级服务，RTO=30分钟，RPO=5分钟，SLO=99.9%。
持续验证：指标定好了，不演练等于白定。我建议每季度至少做一次故障演练，看看实际恢复时间能不能达到 RTO，数据丢失量有没有超过 RPO。

小技巧：定义可用性时，别忘了「维护窗口」。很多团队把计划内维护也算作宕机时间，这其实不合理。我一般会在 SLA 里明确排除「提前公告的维护时段」，否则你每次更新版本都算故障，谁也扛不住。

最后说一句，这些指标不是一成不变的。游戏上线初期，玩家少，RTO 可以长一点；到了大版本更新或活动期间，RTO 必须缩短。说白了，指标要跟着业务走，别死守着年初定的数字不放。