首页 on 孙恒 · SRE / 数据基础设施

把手游发布从 1.5 小时压到 30 分钟

Mon, 20 Jul 2026 00:00:00 +0000

问题

《魔法战旗》海外服和《决胜巅峰》国服的一次常规发布要占掉 1.5 小时。最初的判断是构建和分发慢，但把每个阶段的耗时拆出来之后，结论反了：

真正的时间都花在串行的人工确认上。发布是分批次的，每批之间要等人工核对上一批的监控指标是否正常，确认了才敢继续。核对本身只要几分钟，但等人从别的事情里切回来、打开几个看板、逐个确认，中间的空档累积起来比所有机器操作的总和还长。

这是一个典型的「优化错了对象」的陷阱——如果按最初的判断去优化构建速度，就算把构建做到零耗时，总时长也只能降到一小时出头。

做法

思路是把人工确认变成机器判定，人只在判定不通过时介入。

第一步：把「正常」写成可执行的判定条件。 原来的核对是经验性的——老手看一眼看板就知道对不对。要自动化，就得先把这份经验落成明确的指标阈值和判定逻辑：哪几个指标、看哪个时间窗、超过多少算异常、哪些波动是发布本身必然带来的正常抖动。这一步花的时间最长，也最容易被低估：它本质上是在给一群人的隐性判断做知识提取。

第二步：批次间的等待改成自动观测窗口。 每批发布完成后自动进入固定时长的观测期，期间持续拉取判定指标。全绿则自动继续下一批，任一条不满足则暂停并推送告警，附带具体是哪条指标、当前值、阈值。人被叫来的时候看到的是结论，不是一堆看板。

第三步：把回滚也做成一条命令。 自动化推进的前提是出错时能快速退回。回滚路径不可靠的话，没人敢让流程自己往下走——这一点比自动化本身更影响推进意愿。

结果

单次发布耗时从 1.5 小时降到 30 分钟。
发布窗口不再必须占用一个完整的人力时段，值班同学可以并行处理别的事。
判定条件被写成了配置，新项目接入时是填表而不是重新攒经验。

事后看，值得记下来的

「慢」的归因经常是错的。 大家凭直觉认为是机器慢，因为机器耗时是可见的、有日志的；人工等待是不可见的，没有人记录「我什么时候被叫来的」和「我什么时候真正开始看的」。要先把不可见的部分量化出来，才谈得上优化。

自动化的阻力不在技术，在信任。 判定逻辑写好之后，还跑了一段时间的「影子模式」——机器给判定，人照旧手工确认，两边比对。跑到人发现机器的判定和自己一致，才愿意把控制权交出去。这段并行成本是必要的，跳过它换来的是流程上线后没人敢用。

隐性经验的显式化，本身就是交付物。 阈值和判定逻辑写下来之后，价值不只是给自动化用——新人 onboarding 时不用再靠师傅带着看看板了。

告警根因分析 Agent

Mon, 01 Jan 0001 00:00:00 +0000

这个 Demo 还在搭

交互界面和后端推理正在实现中。设计已经定稿，四个阶段是：

信号提取 — 从告警文本和指标片段里拆出实体（服务、节点、指标名）、时间顺序和异常方向。
假设生成 — 基于信号组合列出候选根因，不预设只有一个。
证据匹配 — 逐个假设去找支持与反驳的证据，明确标出「缺少哪条数据就无法判定」。
收敛定论 — 给出根因、置信度、影响链路，以及被否决的假设和否决理由。

三个预置样例都刻意选了表象与根因不一致的场景：

六个服务同时 P99 超时 → 根因是上游连接池耗尽，不是这六个服务自己的问题。
节点内存持续上涨 → 是 page cache 增长，实际没有泄漏。
磁盘 IO 阶梯式跳升 → 定时任务与备份窗口重叠。

先看看另一个 Demo，或者项目案例。

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

Fri, 10 Jul 2026 00:00:00 +0000

背景

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

成本这一块，钱从哪省的

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

拆开来看：

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

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

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

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

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

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

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

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

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

问题定位效率提升一倍

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

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

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

成本优化分析 Agent

Mon, 01 Jan 0001 00:00:00 +0000

这个 Demo 还在搭

交互界面和后端推理正在实现中。设计已经定稿，分析维度是五个：

规格错配 — CPU 与内存的实际使用比例是否匹配所选机型。换规格比缩容量安全得多。
闲置识别 — 长期无流量、无请求、无变更的资源。这类回收没有风险，纯粹是流程漏洞。
弹性机会 — 有清晰周期性的负载。策略上扩要激进、缩要保守，因为两边代价不对称。
计费优化 — 稳定基线用包年包月覆盖，波动部分走按量。不改任何技术配置。
收益排序 — 按「节省金额 ÷ 变更风险」排，而不是只按金额排。

两个预置样例：一个是明显有水分的集群，一个是已经比较紧凑但仍存在弹性机会的集群——后者更能说明分析的下限在哪。

核心约束是：每条建议必须带依据数据和风险等级，不做一刀切砍 requests。 砍配额能在报表上立刻见效，但它把成本问题转化成了稳定性问题。

先看看另一个 Demo，或者项目案例。

两款数据库 Operator：从部署文档到声明式配置

Sun, 28 Jun 2026 00:00:00 +0000

问题

两款分布式数据库的部署原本靠一份很长的文档：几十个步骤，多个组件有严格的启动顺序，配置项之间有隐含约束（比如某个副本数必须和某个分片数匹配）。文档写得再细，人执行还是会错——错的地方还很分散，有人漏了一步，有人把顺序搞反，有人配置项填了个合法但不兼容的值。

更麻烦的是出错之后不好查。因为部署过程没有留下结构化的状态，只能靠翻日志倒推执行到哪一步、哪一步出了偏差。

做法

Operator 的核心价值不是「自动化部署」——脚本也能自动化。核心价值是把「期望状态」和「当前状态」都变成可查询的结构化数据，然后让控制循环去消除两者的差距。

把隐含约束写进 CRD 校验。 配置项之间的约束原来只存在于文档的注意事项里，现在写成 OpenAPI schema 校验和 admission 逻辑。填了不兼容的值会在提交时被拒绝，而不是部署到一半才崩。这一项对「出错率降低 80%」的贡献最大——大部分部署失败根本不是执行错误，是配置本身就不合法。

启动顺序交给状态机，不是交给 sleep。 脚本化部署里常见的做法是「启动 A，睡 30 秒，启动 B」。这在慢环境里会失败，在快环境里会浪费时间。Operator 里改成显式的阶段状态：A 真正就绪了才推进到 B，就绪的判定是查询 A 的实际状态而不是等时间。

状态可查询。 CR 的 status 字段暴露当前处于哪个阶段、每个组件的健康状况、上一次协调的结果和错误。查问题从「翻日志倒推」变成 kubectl get 一眼看到。

关于 OperatorHub.io Level 3

Operator 的成熟度分五级。Level 1 是能装，Level 2 是能升级，Level 3 是要支持完整的生命周期——备份、恢复、故障转移、灾难恢复。

关于我

Mon, 01 Jan 0001 00:00:00 +0000

一句话

从虚拟机运维做到云原生平台，再做到数据链路和 AI 分析——每一段都是因为「重复劳动太多」而往上走了一层。

现在关注的问题是：运维领域积累的大量数据（告警、指标、变更、账单），能不能真的交给模型去产出结论，而不只是做个更好看的看板。 这个站点上的两个 Agent Demo 就是这个思路的具体化。

经历

沐瞳科技 · SRE / 数据基础设施 · 2024.10 — 至今

AI 告警数据智能分析框架：告警、指标、变更记录原本分散在不同系统，值班同学要靠经验串起来。我把这些源接成统一数据链路，再让模型在这套上下文里做根因定位。
智能成本数据分析模型：把资源使用画像、计费数据、业务波动周期喂给模型，产出带依据和风险等级的优化建议——而不是一句「利用率低，建议缩容」。
负责海外服与国服的发布与稳定性保障，详见项目。

腾讯 IEG · 运维开发 · 2021.11 — 2024.04

英雄联盟端游、无畏契约的云原生化改造，覆盖容器化、资源调度、发布流程与故障自愈。
累计节省集群成本 500 万/年——主要来自规格错配的纠正和闲置资源的回收，不是靠压缩业务配额。
稳定性提升 60%，问题定位效率提升一倍。
掌上英雄联盟的交付流程改造，交付效率提升 40%。

易鲸捷 · 云原生研发 · 2020.06 — 2021.10

开发两款分布式数据库的 Kubernetes Operator（esgynDB / qianbaseDB），通过 OperatorHub.io Level 3 认证。
把原先靠文档和人工执行的部署流程收敛成声明式配置：部署出错率降低 80%，交付效率提升 50%。

钢银电商 · 运维工程师 · 2019.04 — 2020.06

管理 2500+ 虚拟机、5000+ Pod 的混合环境。
通过资源画像与调度策略调整，资源利用率提升 25%，年节省成本百万级。
建设内部运维平台，协作效率提升 35%。

技能

层面	内容
熟练	Go、Python、Kubernetes、Prometheus、数据采集与链路建设
掌握	Docker、MySQL、CI/CD、可观测性体系
在做	LLM Agent 工程化：提示词编排、工具调用、结果可验证性

教育

计算机网络与安全学士 · 英国伯明翰城市大学 · 2014 — 2018