games-development-ai/docs/architecture/_recall/运维基建-历史设计点.md

运维基建 · 历史设计点回收清单

这份清单做的是一件事：把"运维基建"这个领域里——历史和留痕文档里认真讨论过、但现行 docs/architecture 没有沉淀下来的设计点、想法、顾虑、约束——逐条挖出来，交给创始人判一判该不该捡回。它不是现行架构文档，而是一次穷尽式的"翻旧账"，目的是防止历史上想清楚过的好东西、或本该考虑的约束，在多轮 reframe 和文档域化重构里悄悄丢掉。

判定口径：每条问"它在现行档里讲到没有？"——这里的"现行档"是整棵 docs/architecture/ 域树（产品 / 架构 / 后端 / 前端 / 运营 / 运维 六域 + 生成引擎子树）外加 .agents/（knowledge / rules / skills）。要特别说明的是：运维这个主题被刻意拆在两处——运维/README.md 只承载"环境边界 / 部署链 / 健康门 / 可用性目标"这层薄骨架，而可观测性技术栈（Prometheus/Grafana/Sentry/Jaeger/Loki）、SLO、性能目标、告警升级链、LLM 网关失效巡检这些反而沉淀在 架构/README.md §6、.agents/rules/security-and-reliability.md §5-6 里。所以判"遗落"时，我是拿整棵树 + .agents 一起比对的，不是只看运维那一页——只有整棵树都没有的才算遗落，否则只是"沉淀在隔壁域"，不算丢，我已剔除不再当噪声列入。

扫过哪些历史文档：docs/architecture/_archive/ 三份长设计——技术决策版（HJ-ARCH-001，§3.2 部署拓扑 / §5.2 存储 / §6 选型 / §7.2-7.9 可靠性·可观测·CI/CD·环境·灰度 / §10 成本）、开发团队版（§1 本地环境 / §8 部署流程 / §8.3 回滚 / §10 外部工具）、技术架构与模块（telemetry/compliance 的监控告警·备份 T-id）、投资人版（§7 成本结构·资本效率·Runway）；docs/agent-specs/_archive/ 里 2026-06-08-wave3-staging联调与P0补全-review（最厚的一份隔离 staging 建栈设计，OOM 保护 / 内存硬限 / 网络隔离 / healthcheck / 备份重建）、下一阶段路线-plan、admin-cloud清理-codex执行单、agent-loop 编排器 README/.agent；docs/memorys/（技术护城河复盘 / prefix-cache-preflight 的缓存成本监控）；docs/mvp/（单位经济敏感性模型的 new-api 成本对账）；以及 运营/变现端到端.md 里 XXL-Job 三个结算 job 的运维形态。

怎么读这张表：状态分三档——遗落（讨论过、有价值、整棵树都没沉淀也没被明确弃，这是重点）、过期/弃用（讨论过但已被取代/明确弃，列出来是让创始人知道"考虑过、为什么弃"，避免重复讨论）、不确定（拿不准现行档到底覆盖没，或已部分覆盖、登记防丢）。判定列留空，等创始人裁。

---

表 A：可观测性、监控与告警

绘境的可观测性有一个反直觉的现状：外部技术栈那一层（Prometheus/Grafana/Sentry/Jaeger/Loki + 告警升级链）其实没丢，它被沉淀在 架构/README.md §6 和 .agents/rules/security-and-reliability.md §6 里，是有家的。真正悬空的是另外两类：一是这套栈现在到底部署了没、谁来搭（蓝图画了容器，现实从未起过 Prometheus，运维主档对此一字未提）；二是平台自己内建的那一套监控告警能力（telemetry/compliance 模块里设计的健康监控、异常检测、数据质量监控），它们和外部 Grafana 栈是两回事，却在域化重构后只剩一句"产出监控告警信号"。

ID	设计点（标题 + 一句话）	出处	状态	为什么	判定
运维基建-001	可观测性容器栈从未部署，运维主档对"现状是什么"留白 —— 蓝图在部署拓扑里画了 Prometheus:9090 / Grafana:3001 / Jaeger:16686 三个可观测性容器，但 MVP 现实从未起过它们。	技术决策版 §3.2 部署拓扑图；架构 README §6（描述了目标栈）	遗落	架构域把可观测性目标栈讲清楚了，但那是目标态。运维主档讲"怎么知道服务健康"时，现行答案只有一个秒级冒烟门（smoke-test.sh）+ 可用性目标数字，没有任何一句交代"Prometheus/Grafana 这套栈现在没部署、现状靠什么观测线上、什么时候补"。这正是运维域该回答而没回答的边界：一个 ≥99.5% 可用性的目标，配的却是"部署后跑一遍冒烟"——线上跑起来之后靠什么持续观测、靠什么发现 5xx 飙升，是个真空。值得在运维主档补一句现状与缺口声明。
运维基建-002	telemetry 模块内建的实时健康监控（服务/生成/Runtime 三维 + 异常检测告警） —— T-TEL-13~16 把"实时监控服务健康 / 生成任务健康 / Runtime 健康 + 异常检测与告警"列为 telemetry 的技术功能。	技术架构与模块 telemetry §（T-TEL-13~16/19/20）；13模块.md telemetry 卡片（仅留"产出监控告警"一句）	遗落	现行 架构/13模块.md 只说 telemetry"产出监控告警与数据质量信号"，一句话带过；当年设计的三维健康监控 + 异常检测 + 数据质量监控 + 推荐效果监控这套平台自建的内观测能力（区别于外部 Grafana 旁路监控），没有在任何现行档里展开成"它监控什么、阈值多少、告警去哪"。这是 telemetry 作为"数据底座"承诺过、却在域化重构里被压扁的一块。它和外部 Prometheus 栈不重叠——一个是平台业务级健康（生成成功率、Runtime 崩溃率），一个是基础设施级指标。值得在后端 telemetry 设计或运维档里留一份"平台内建监控清单（待建）"。
运维基建-003	生成成本的周期对账 + 缓存命中率告警（cache_hit_rate < 50%） —— prefix-cache 预研明确列了三条运维待办：集成 cache_info 抽取、周期对账成本、配置 cache_hit_rate < 50% 监控告警。	memory 2026-06-17-prefix-cache-preflight.md §后续行动	遗落	new-api logs.quota 权威成本对账已经接通（单位经济敏感性模型里坐实，那部分不算丢）。但**"前缀缓存命中率掉到 50% 以下就告警"**这条——它是生成成本失控的早期哨兵（缓存一旦因 few-shot 字节漂移而失效，成本立刻翻几倍，年化差 ¥40k+）——在现行档里没有落点。架构 README §6 有"日预算熔断告警"，但那是总量阀；缓存命中率是更前置的成本健康指标。值得在成本台账或运维监控里补一条"缓存命中率哨兵"。
运维基建-004	告警升级链的 P0-P3 分级 + 通知渠道（电话/短信/飞书/钉钉）+ 响应时限 —— P0=服务不可用 5 分钟电话+短信、P1=5xx>2% 或生成成功率<70% 15 分钟、P2=P95>800ms 1 小时、P3 工作时间。	技术决策版 §7.5；security-and-reliability §6（已收录该表）	不确定（已覆盖，登记防丢）	这套已在 security-and-reliability §6 完整收录，不算遗落。放进来只为提醒：它现在是一张纯文档表，没有任何告警通道真的接上（飞书/钉钉 webhook 谁配、P0 电话怎么打，全是空头承诺）。一旦线上化，这是运维必须先落地的一环，别因为表已写好就以为有了。

---

表 B：部署、回滚、灰度与环境管理

这一块是历史与现实落差最大的地方。蓝图设计的是一套很完整的云原生发版链（CI 触发 → 构建镜像 → 安全扫描 → 部署 staging → 冒烟 → 审批 → 滚动部署 prod → 失败自动回滚），外加四套环境、按百分比灰度、镜像回退保留前 3 版。现实是内网四台物理机 + 人工经标准序在 mini-desktop 部署，运维主档已诚实地把蓝图那套标为"目标态、系统性脱节"。所以这里大部分是过期/弃用——但弃用不等于没价值：里面有几个**机制（不是工具）**是真正上线时还得重新捡回来想的，比如灰度的"路由权重 + 旧版本不销毁"思路、Feature Flag 上线后必须删除的纪律。

ID	设计点（标题 + 一句话）	出处	状态	为什么	判定
运维基建-005	按百分比灰度发布（路由权重 5%→20%→50%→100% + 旧版本容器不销毁，异常 5 分钟回退） —— 服务/版本级灰度靠网关路由权重逐档放量，发现异常把权重调回 0%、旧版本不销毁即时回退。	技术决策版 §7.9；开发团队版 §8.3 方式二	过期/弃用（机制可捡回）	现行架构树里"灰度"一词出现 13 次，但全是别的灰度——游戏内容的金丝雀发布（运营/合规："新生成的游戏须经灰度验证")、SAA 派发器的灰度切换、Feature-flag 默认关的灰度 opt-in。服务/版本级的"网关按百分比放量"这套部署灰度机制，整棵树没有。它依赖网关在请求路径上（现行单体下网关不在路径上）+ Nacos 路由权重（Nacos 未部署），所以现实做不了，弃得合理。但列出来是因为：真上云、真要做无感发版时，"路由权重逐档 + 旧版本留着即时切回"是个早想好的正确机制，别到时候从零设计。
运维基建-006	四套环境分层（local/dev/staging/prod）+ 数据策略 + 部署方式 —— local=Docker Compose+seed、dev=共享库可重置、staging=生产数据脱敏子集、prod=审批后滚动部署。	技术决策版 §7.6 环境管理；开发团队版 §8.2	过期/弃用（部分降级现状）	现实只有两层：本地 dev（lili-mac）+ 一套 staging（mini-desktop），没有独立 dev 联调环境、没有 prod。运维主档讲的就是这套两机现实。所以四套环境是有意降级，不算遗忘。但有一条约束被一起丢了：staging 用"生产数据脱敏子集"——现行 staging 是空库 + seed 假数据（wave3 定的"可幂等重建"），等真上线后 staging 要不要、怎么用脱敏后的真实数据来验证（暴露真实数据分布下的 bug），是个没人接的运维-合规交叉约束。列出来防止上线时漏掉"staging 数据该像生产"这条。
运维基建-007	Feature Flag 上线稳定 2 周后必须删除，不留死代码 —— Feature Flag 是临时开关，上线稳定后强制清理，admin 后台可开关无需重新部署。	技术决策版 §7.9 Feature Flag	遗落	现行档里 feature-flag 用得很多（W-G1 开闸 aigc.control-plane.enabled、生成产线 saaSourceMode、九门 GATE_ALL9 等都是默认关的灰度开关），但**"flag 稳定后必须删除、不留死代码"这条纪律，整棵树没有**。这是个真实的技术债红线——现在已经攒了好几个默认关的 flag（控制平面、源项目模式、客观门），没有任何机制规定它们 flip 之后该不该清、什么时候清。值得在工程规范里补一条"feature-flag 生命周期纪律"，否则死开关只增不减。
运维基建-008	镜像回退保留前 3 个版本、5 分钟内可回退 —— 每次部署保留前 3 个版本镜像，发现问题 5 分钟内镜像回退（docker compose pull 指定 tag）。	技术决策版 §7.2/§7.6；security-and-reliability §5.2（留一行）；开发团队版 §8.3 方式一	过期/弃用（被隔离验证变体取代）	现行运维主档的回滚机制是另一套且更适合人工部署：高风险变更走"隔离端口起新 jar 验全过才切 live、失败用 /tmp 备份 jar 恢复"（staging-ops §3 安全变体）。所以"前 3 版镜像回退"这个 CI/容器化前提的机制被有意识地替换了，不算丢。security-and-reliability §5.2 还留着那一行"保留前 3 个版本镜像"是与现实脱节的残留——列出来提示：这行该标注为目标态/已被隔离验证变体取代，免得误导。
运维基建-009	CI/CD 流水线（lint→test→构建镜像→安全扫描→部署 staging→冒烟→审批→滚动部署→健康检查→失败自动回滚）+ 工具选型 —— GitHub Actions + 阿里云 ACR/Harbor + Docker Compose→K8s ArgoCD + Trivy/Snyk 安全扫描 + Checkstyle/ESLint。	技术决策版 §7.6 CI/CD；开发团队版 §8.1	过期/弃用（明确无自建 CI）	运维主档已明说"内网阶段没有 docker-compose、也没有自建 CI 流水线"，整条蓝图是目标态。所以弃得明确。但里面有两件被一起丢掉、且现状真的缺：① 依赖漏洞 / 镜像安全扫描（Trivy/Snyk）——现行没有任何机制扫第三方依赖的 CVE，这是个上线前必补的安全门，不只是 CI 的事；② Checkstyle/ESLint 静态检查门——现行靠人工 review，没有自动化代码规范门。这两条即便不上完整 CI，也该作为"上线前必须有"的独立约束登记。
运维基建-010	K8s + ArgoCD 作为正式阶段编排/部署目标 —— Docker Compose（MVP）→ K8s ArgoCD（正式）的演进路径。	技术决策版 §7.6；§3.2 部署拓扑标题	过期/弃用（远期演进，登记）	现行内网物理机方案明确不上 K8s。K8s/ArgoCD 是远期演进锚，不算遗忘。登记只为留一份"正式阶段编排目标"的索引，免得规模化决策时忘了当年设过这个方向、为什么当时不上（成本盒子 ¥4,300/月撑不起）。

---

表 C：基建组件的运维约束与演进（MySQL/Redis/OSS/MQ/Nacos/Flyway/调度）

这一块里，数据库高可用、备份恢复、存储演进路径这些真上量后躲不掉的运维约束，大多只活在归档长档里，现行档要么只留一行、要么完全没有。MQ/Nacos 的 future-state 状态本身没丢（多处标注了），但"真上它们时的运维形态"在散落各处。

ID	设计点（标题 + 一句话）	出处	状态	为什么	判定
运维基建-011	数据库高可用：MySQL 主从（生产）+ 每日全量 + binlog；OSS 跨区域复制 —— 生产 MySQL 走主从、每日全量备份 + binlog 增量；对象存储跨区域复制做容灾。	技术决策版 §7.2 可靠性表；security-and-reliability §5.2（留一行"MySQL 主从/每日全量+binlog"）	遗落（OSS 跨区复制完全丢）	security-and-reliability §5.2 留了"MySQL 主从 + 每日全量 + binlog"一行，所以数据库高可用没完全丢；但OSS 跨区域复制（游戏包/素材的异地容灾）整棵树没有，而游戏包一旦丢失是不可再生资产（创作者的作品）。更要紧的是：这些全是"上线前/生产"才落地的约束，运维主档作为"可用性怎么达标"的家，却没有一处汇总"上线前数据保护清单"（主从切换、备份频率、恢复演练、OSS 容灾）。≥99.5% 可用性 + 数据不丢，这两条硬约束的落地细节是真空。值得在运维档补一份"上线前数据可靠性前置清单"。
运维基建-012	数据备份与恢复作为 compliance 模块技术功能（T-CMP-38） —— 数据备份与恢复、安全日志与告警（T-CMP-21）被列为 compliance 的技术功能。	技术架构与模块 compliance §（T-CMP-21/38）	不确定	现行 运营/合规闸门.md 讲的是创作链路的合规门（锁风门/分级/审核），没有提"数据备份与恢复"这个被挂在 compliance 名下的运维功能。这条挂得本来就有点怪（备份恢复更像运维而非合规），但既然蓝图把它列为 P0 技术功能，就不该悄无声息消失。列不确定：确认一下数据备份恢复到底归哪——是运维域该接的，还是真的留在 compliance。
运维基建-013	存储演进双写期：事件表 MySQL→ClickHouse、搜索 MySQL FULLTEXT→Elasticsearch —— 事件流增长期迁 ClickHouse、搜索增长期迁 ES，靠 DAO 抽象 + 双写期平滑迁移。	技术决策版 §5.2 存储选型 / §7.10 扩展性	不确定（部分覆盖）	ClickHouse 在现行档里有 3 处提及（事件表增长期目标），所以事件存储演进方向没丢；但Elasticsearch（搜索增长期）整棵树没有，而且**"双写期 + DAO 抽象"这个平滑迁移机制**——它是真做迁移时不停机的关键手法——没沉淀。MVP 单库阶段不咬人。列不确定：是否要在数据模型或运维档留一份"存储演进路线（含双写迁移手法）"，免得增长期重想。
运维基建-014	大表 DDL 用 gh-ost / pt-online-schema-change 不锁表 —— Flyway 迁移规范里，大表结构变更走在线改表工具避免锁表。	技术决策版 §7.6 数据库迁移；engineering-conventions §8（已留一行）	不确定（已覆盖，登记防丢）	engineering-conventions §8 的 Flyway 规范表里确实留了"大表变更用 gh-ost/pt-osc"这一行，所以没丢。登记只为提示：这是真上量后数据侧 review 必须知道的约束，现行单库小表阶段休眠，别因为现在不咬人就忘了它的存在。（注：本条与后端数据契约清单 003 同源，两份清单交叉登记。）
运维基建-015	RocketMQ 真上线时的运维形态（同步刷盘 + 死信队列 + 延迟消息 + broker IP 配置） —— MQ 上线的可靠性配置（同步刷盘保不丢、DLQ 兜异常、延迟消息做定时）+ broker brokerIP1 内网地址配置。	技术决策版 §3.2/§7.2；wave3 review §3.1（broker 容器配置）；security-and-reliability §5.2（留一行）	不确定	RocketMQ 整体 future-state、MVP 未部署，这个状态多处标注了，不算丢。但真上 MQ 时的具体运维形态（同步刷盘/DLQ/延迟消息三件 + broker 内网 IP 配置 + 死信队列怎么消费）只在归档长档和 security-and-reliability 表里零散留着。等第一个 MQ 消费者落地时这些是必须先想清的运维约束。列不确定：看是否值得在运维或可靠性档留一段"MQ 上线运维前置"。（注：与后端数据契约清单 006 同源。）
运维基建-016	Nacos 真上线时的运维形态（3 节点集群 + 配置加密 + 作为配置中心/注册中心） —— Nacos 生产走 3 节点集群、配置加密存储、承担服务注册发现 + 配置中心 + Feature Flag 热改。	技术决策版 §3.2/§5.2/§7.2/§7.9	不确定	Nacos future-state、MVP 未部署 registry/配置中心，状态明确，不算丢。但真上 Nacos 时的运维形态（3 节点高可用、配置加密、它一旦成为配置中心后"业务可调参数热改 + Feature-flag admin 后台开关"才成立）没沉淀。现行 feature-flag 全靠 -D/yaml + 重部署（无热改），这正是因为 Nacos 没上。列不确定：留一份"Nacos 上线后解锁哪些运维能力"的索引。
运维基建-017	XXL-Job 作为平台调度框架的运维面（admin 控制台部署 + executor 注册 + 在哪台机器跑） —— 三个结算/补偿 job（tradeSettlementJob/WithdrawPayoutCompensateJob/RewardPayoutJob，全带 @TenantJob）真实运行在 XXL-Job 上。	运营/变现端到端.md（job 业务逻辑已详述）；security-and-reliability §4（补偿 job 红线）	不确定	XXL-Job 作为调度框架存在这件事没丢——运营域详细讲了三个 job 的业务逻辑、param 约定、补偿口径。但它的运维面是空白的：XXL-Job admin 控制台部署在哪、executor 怎么注册、这些 T+1 凌晨 job 实际跑在哪台机器上（mini-desktop？6c6g？）、调度可视化/失败重试在哪看——运维主档讲"定时任务落在 6c6g"但那指的是 agent 编排 cron，不是 XXL-Job 这套业务调度框架。这是个真实的运维盲区：结算 job 跑不跑得起来、卡了谁发现，没有运维落点。列不确定：运维档是否该补一句"XXL-Job 调度面归属与可见性"。
运维基建-018	生成产物缓存：相同 Prompt hash → 缓存命中 → 跳过 LLM 调用 —— 用 Prompt hash 做生成结果缓存，命中即跳过 LLM 调用，省成本/加速。	技术决策版 §7.10 扩展性；AGENTS §8 效率策略 7	不确定	AGENTS §8"缓存昂贵步骤"把这条列为效率策略，且 prefix-cache（new-api 网关前缀缓存，token 级）已 spike 证绿——所以token 级缓存这条线坐实了。但**"整个生成产物按 Prompt hash 缓存、命中直接跳过整轮生成"这个更粗粒度的机制**（区别于 new-api 的前缀 token 缓存）在现行档里没有独立落点。两者不是一回事：一个省单次调用的输入 token，一个省整轮生成。列不确定：确认产物级缓存是不是有意只做 token 级、不做整轮级。

---

表 D：隔离 staging 建栈的运维约束（wave3 设计，多数随两机现状漂移但机制有价值）

2026-06-08 的 wave3 staging review 是历史上唯一一份系统设计过"在共享机器上安全地拉一套隔离环境"的文档，里面的约束密度很高。但它有个重要的时空错位：当时设计的是"在 mini-infra 共享基建机上拉隔离 staging 栈"，而现行 staging 实际跑在 mini-desktop 上、用的是 mini-desktop 自己的隔离 MySQL/Redis 容器（不与 mini-infra 共享基建混）。所以 wave3 那套"在共享机上和现有服务抢内存"的约束，前提已经变了——但里面几条机制（OOM 优先级保护、全容器内存硬限、磁盘水位告警、代理劫持防护、最小权限 IAM）是任何时候在一台机器上多服务共存都成立的运维红线，现行 staging-ops 里一条都没有。值得逐条看哪些该捡进 staging-ops。

ID	设计点（标题 + 一句话）	出处	状态	为什么	判定
运维基建-019	OOM 优先级保护：给共存的关键服务设负 oom-score-adj，确保 OOM 优先杀新栈 —— 多服务共享一台机时，给现有关键服务设负 oom-score-adj（或给新栈正值），让内核 OOM-killer 优先杀"可重建的新栈"而非"护住的现有服务"。	wave3 review §2 H1 / §3.1 OOM 保护	遗落	现行 staging-ops 只有一条"6c6g 禁跑重活（重型前端构建 OOM）"的回避式约束，没有任何"当多服务真的共存、内存真的紧张时，怎么决定先杀谁"的主动保护机制。oom-score-adj 是 Linux 上唯一能控制 OOM 优先级的杠杆，wave3 把它定为"护住现有服务=铁约束"。mini-desktop 上现在 huijing 单体 + studio + admin + MySQL + Redis 五个服务共存 15G，一旦吃紧内核会随机杀——可能正好杀掉 live 后端。这是个真实的稳定性红线，值得捡进 staging-ops。
运维基建-020	全容器内存硬限 mem_limit + 中间件堆/缓冲池显式限制 —— 每个容器都设 mem_limit，MySQL --innodb-buffer-pool-size、Redis --maxmemory、Nacos JVM_XMX 全部显式限制，不让任何单容器按宿主内存自取。	wave3 review §2 H1 / §3.1 容器表	遗落	现行 staging-ops 完全没提容器内存限制。wave3 的核心洞察是：MySQL 默认 innodb buffer pool 会"按宿主自取"——不显式限，它会吃掉一大块，挤垮同机其它服务。这条和 019 是一对（限额 + 优先级），是"一台机器塞多个服务"的基本功。现行 mini-desktop staging 的 MySQL/Redis 容器有没有设这些限，运维档无从得知。值得捡进 staging-ops 作为"隔离容器起栈的内存纪律"。
运维基建-021	磁盘水位告警 —— 共享单磁盘卷场景下，加磁盘水位告警兜底（与内存限额、OOM 保护并列为三大共享面风险之一）。	wave3 review §3.1 / §5.1 拓扑图 RES 注 / §6 blast radius	遗落	wave3 把"整机内存 + 单磁盘卷"列为隔离栈唯一真实的间接影响面，对磁盘开的兜底是"水位告警"。现行档整棵树没有任何磁盘水位/disk 相关约束。mini-desktop 跑 staging + 构建产物 + jar 备份 + 批跑证据 + 日志，磁盘是会涨满的（构建日志、/tmp 备份 jar、批跑 jsonl/png），满了 MySQL 直接挂、构建直接失败。这是个低成本高价值的哨兵，值得捡进 staging-ops。
运维基建-022	代理劫持防护：no_proxy / nonProxyHosts 放行内网网段 —— 机器上挂了 mihomo 之类代理（占 7890/9090）时，必须把 100.64.0.0/10 内网网段加进 no_proxy/nonProxyHosts，防 jdbc/redis/nacos 连接被代理劫持。	wave3 review §3.3 后端接线	遗落	这是个极隐蔽的真实坑：内网机器若装了代理客户端，Java 进程连内网 MySQL/Redis 时可能被代理拦截，表现为莫名其妙的连接失败。wave3 专门记了这条。现行档里 no_proxy 只在生成域的 new-api 调用 skill 里出现过（那是出网调模型的场景），staging 后端连内网中间件的代理劫持防护整棵树没有。这条该进 staging-ops，作为"后端接 staging 前的环境检查项"。
运维基建-023	共享 MinIO 的最小权限 IAM policy（Resource 限定到本环境 bucket） —— 复用共享 MinIO 时，新建 bucket 必须绑只授 arn:aws:s3:::game-staging/* 的最小权限 key，评审门核验 policy JSON，防配错越权读写现有对象。	wave3 review §2 H2 / §3.1 MinIO / §八 D3	不确定（前提已变）	wave3 当时的前提是 staging 复用 mini-infra 的共享 MinIO，所以要给最小权限 policy 防越权。现行 staging 在 mini-desktop 上用隔离容器，对象存储是否还复用 mini-infra 的 MinIO 不确定——若复用，这条最小权限约束仍成立且现行 staging-ops 没有；若 staging 不碰 MinIO，则这条休眠。这是 §1 SoT《内网凭据与端点》该回答的。列不确定：确认 staging 的对象存储拓扑，再判这条是否捡回。
运维基建-024	healthcheck + depends_on:service_healthy + wait-for-it 启动编排 —— 容器加 healthcheck（mysqladmin ping / redis-cli ping 等），有依赖的容器 depends_on: {condition: service_healthy}，后端启动前 wait-for-it 探端口就绪。	wave3 review §2 M / §3.1 healthcheck	不确定（前提部分变）	wave3 设计这套是为"docker-compose 多容器栈按健康顺序起"。现行 staging 没有 docker-compose（运维主档明说），后端是人工 start-app.sh 起、起后验 health 200——所以"compose 编排 healthcheck"这个形态弃得合理。但底层意图（"等中间件真就绪了再起后端、别连空库"）现行靠人工验门兜着。列不确定：现状人工验门是否等价覆盖了"启动顺序依赖"，还是仍有"后端起太早连到没就绪的 MySQL"的窗口。
运维基建-025	staging 机密走环境变量占位，不明文入库 —— 连接串密码等用 ${STAGING_DB_PWD}/${STAGING_REDIS_PWD} 环境变量占位，避免明文落库。	wave3 review §2 M / §3.3	过期/弃用（被现行口径取代）	wave3 当时定"机密走环境变量占位、不明文入库"。但创始人后来立了相反的内网铁律（memory internal-network-keys-decisions-in-docs）：内网阶段所有密钥+决策直接进项目文档 docs/内网凭据与端点.md，不靠 env var。所以这条被有意识地推翻了——内网阶段为了不被 key 阻塞工作，故意把密钥写进仓内文档。列在过期档是让创始人知道：当年的"机密不入库"洁癖被"内网不设防、写进文档省事"取代了，这是个清醒的、有代价的权衡（内网可接受），真到公网上线时要记得把这条翻回来（机密回到 env/Secret，仓内凭据文档清掉）。
运维基建-026	staging 数据定位为"可幂等重建" + 自动化重建脚本（建库+导基表+Flyway）+ 钱财闭环验通后 mysqldump 存档 —— staging 库被定位成随时可丢、靠脚本一键重建（建空库 → 导 huijing 框架基表 → Flyway 迁移），关键验证通过后 mysqldump 备份留证。	wave3 review §3.1 备份/回滚 / §3.2 建库	不确定	这套"幂等重建"思路在 staging-ops §3（重部署标准序：git reset → clean install → 验门）里部分体现了，但两件具体的没沉淀：① 一个真正的"建库+导基表+Flyway"一键重建脚本（现状重部署只重建 jar，不重建库；库是长期累积的，从没被"一键重建"过）；② "关键闭环验通后 mysqldump 存档"的留证习惯（鉴权波 e2e 报告里提过 jar 备份，但库快照备份没成约定）。列不确定：staging 库要不要有"可一键重建"能力（现在它是个长期手工累积的库，一旦坏了没有重建脚本）。

---

表 E：成本、预算与资本效率

成本这块的对账实现层（new-api logs.quota 权威成本）已经坐实在单位经济敏感性模型里，那部分不算丢。这里列的是预算约束、成本结构、Runway 这些"框约束"的东西——它们大多沉淀在投资人版/运营域，但有几条"成本作为运维硬约束反推架构取舍"的逻辑链，和"成本失控的运维兜底"值得单独点出。

ID	设计点（标题 + 一句话）	出处	状态	为什么	判定
运维基建-027	MVP 月度基础设施成本明细（¥4,300/月分项）+ 监控/备份/冗余预留 ¥500 —— 云服务器/数据库/OSS+CDN/LLM API/域名 SSL/监控备份冗余的逐项月费拆解。	技术决策版 §10.1；投资人版 §7.1	不确定（已覆盖，登记防丢）	运维主档 §1.4 引用了"< ¥5,000/月（约 ¥4,300）"这个总数作为可用性取舍的约束来源，所以总额口径没丢。但分项拆解（尤其"监控/备份/冗余 ¥500"这一项）只在归档长档里。这条登记是想提示一个逻辑断点：预算里明确预留了 ¥500 给监控/备份/冗余，但表 A/B 显示监控栈没部署、备份没落地——这 ¥500 的预算对应的能力其实是空的。要么这笔预算没花（那现状的可观测性真空就解释了），要么该花。值得创始人对一下账。
运维基建-028	成本约束反推架构取舍的逻辑链（不上云托管/单体而非微服务/人工部署而非重 CI，都是为撑在成本盒子内） —— ¥4,300/月这个盒子是运维域所有取舍的约束来源。	运维 README §1.4（已沉淀此论）；投资人版 §7-8	不确定（已覆盖，登记防丢）	运维主档 §1.4 已经把这条逻辑链讲清楚了（"这两个数字是运维域所有取舍的约束来源"），不算遗落。登记只为锚定：这是运维域少数已经写对、写透的地方，作为"成本→架构取舍"这条因果已收口的确认点。
运维基建-029	Runway 18-24 个月 + 融资使用效率分配（研发 40%/算法 20%/扩团队 15%/冷启动 15%/合规 10%） —— 以 5 人核心团队算 Runway，种子轮 3000 万的用途分配。	投资人版 §7.2/§7.3	不确定（属投资人/资本域，非运维）	这条是资本效率/融资框架，严格说不属于运维基建领域——它在投资人版里有家。放进来只为边界说明：运维域只管"基础设施成本作为可用性约束"那一面（已收口，见 028），Runway/融资分配不该往运维档塞。判定倾向：不捡回运维档，留在投资人/资本域即可。列出来是为穷尽，免得有人误以为它丢了。
运维基建-030	成本失控的运维兜底：生成限频限额 + 日预算熔断告警 + 显式 max_tokens，超额暂停生成入口仅模板兜底 —— LLM 成本被滥刷/推理输出吃光配额时的应对：限频限额 + 日预算熔断 + 超额暂停生成、退化到确定性模板。	架构 README §6（已沉淀）；W-G1 开闸门（QUOTA_EXCEEDED/BACKPRESSURE_REJECTED 错误码）	不确定（已覆盖，登记防丢）	这条已在架构 README §6 沉淀（"日预算熔断告警 + 显式 max_tokens，超额则暂停生成入口、仅确定性模板兜底"），且 W-G1 开闸门里已有 QUOTA_EXCEEDED/GENERATE_PAUSED 错误码落地。不算遗落。登记只为和表 A-003（缓存命中率哨兵）串起来看：成本健康监控有两道哨兵——总量阀（日预算熔断，已设计）+ 命中率前哨（缓存 <50% 告警，遗落），前者有家、后者没家，是一对。