端游云原生化改造：500 万/年成本是怎么省下来的

背景

英雄联盟端游和无畏契约的服务端原本跑在虚拟机上，扩缩容靠工单，发布靠脚本。往云原生迁的动机有两个：一是弹性——游戏的负载曲线有极强的日周期和活动尖峰，固定容量意味着按峰值付费；二是交付效率——发布和回滚的流程需要标准化。

成本这一块，钱从哪省的

先说结论：500 万/年里的绝大部分来自纠正规格错配和回收闲置，不是靠削减业务申请的资源。 这个区别很重要，因为「一刀切砍 requests」这种做法能在报表上立刻见效，但会把成本问题转化成稳定性问题，最后一次事故就赔回去了。

拆开来看：

规格错配。 迁移前的资源申请普遍是按「上次出问题时的峰值 × 安全系数」估的，且一旦申请下来就不再回收。实际观测下来，相当一部分服务的 CPU 长期跑在申请量的很低区间，但内存却贴着上限——说明它需要的是内存型规格，却申请了计算型。换规格比缩容量安全得多：业务拿到的内存没少，只是不再为用不上的 CPU 付钱。

闲置识别。 有一类资源是「上线时申请、下线时忘记回收」。这类没有任何风险，纯粹是流程漏洞。做法是把资源和业务负载做关联，长期无流量、无请求、无变更的资源自动进入回收流程——先通知责任人，过期无响应再回收，保留一段时间的可恢复窗口。

弹性机会。 有清晰日周期的服务改成按时段伸缩。这里的关键是伸缩要保守、扩要激进——扩容慢一点会掉用户，缩容慢一点只是多花点钱。两边的代价不对称，策略就不该对称。

计费方式。 长期稳定的基线负载用包年包月覆盖，波动部分用按量。这一项不改变任何技术配置，纯粹是采购结构调整，风险最低但也最容易被忽略——因为它不属于任何技术团队的 KPI。

稳定性提升 60% 是怎么来的

云原生改造本身不自动带来稳定性，某些方面反而引入了新的失败模式（调度抖动、探针配置不当导致的误杀）。提升主要来自三件事：

故障自愈。 健康检查 + 自动重建覆盖掉了大量「重启就好」的问题。这类问题以前要走值班流程，平均恢复时间是分钟到十分钟级；自动化之后是秒级。

发布过程可控。 滚动发布加自动判定，坏版本在小批次就被拦住，而不是全量铺完才发现。

故障域隔离。 把原来混部在同一批机器上的关键服务和非关键服务拆开，避免非关键服务的资源抢占影响核心链路。

问题定位效率提升一倍

原来定位一个问题要跨好几个系统：监控看指标、日志平台查日志、CMDB 查拓扑、变更系统查最近改了什么。每个系统都要单独登录、单独按时间过滤。

做法是把这些信息按「事件」维度聚合——给定一个时间点和一个服务，自动把该时间窗内的指标异常、错误日志、上下游拓扑、变更记录拉到一起。定位效率的提升不来自任何单个系统变强，而来自不用再手工做关联。

这套思路后来延伸成了我现在在做的告警根因分析——把关联做到位之后，下一步自然是让模型在这套上下文里直接给出根因判断。

事后看，值得记下来的

成本优化的第一性原理是「消除浪费」，不是「减少供给」。 这两件事在报表上长得一样，在稳定性上完全相反。任何一条优化建议都应该能回答：如果业务量不变，这条建议会不会让业务变得更脆弱？答不上来的建议不该执行。

不对称代价决定策略的不对称。 扩容和缩容、快和慢、误报和漏报——运维里几乎所有的权衡都是代价不对称的。把它当成对称问题来配参数是最常见的错误。

采购结构的优化经常没人做。 因为它不需要写代码，也不属于任何技术团队的产出。但它的性价比往往是最高的。