@umacloud/knowledge 1.0.15 → 1.0.17

package/operations/01-standards/cost-and-finops-engineering.md

@@ -0,0 +1,84 @@
+---
+id: cost-and-finops-engineering
+title: 成本与 FinOps 工程规范（把成本当一等预算来设计/归因/护栏，商业级必读）
+domain: operations
+category: 01-standards
+difficulty: advanced
+tags: [finops, cost, cost-budget, unit-economics, cost-attribution, tagging, guardrails, autoscaling, rightsizing, egress, observability-cost, 成本工程, 成本预算, 成本归因, 单位经济, 护栏, 商业级]
+quality_score: 95
+last_updated: 2026-06-29
+---
+# 成本与 FinOps 工程规范（商业级必读）
+
+> 云上成本是一个**工程指标**，不是月底财务才看的账单。一行代码（少一层缓存、多一次跨区调用、一个没上界的自动扩容、一条高基数指标）就能让账单翻倍——而问题往往要到下个月才被发现，那时钱已经花掉了。
+> 商业级团队把成本当成和延迟、可用性同级的**一等约束**：设计时就估、运行时就看、超了就有护栏拦。本规范给出把成本变成可设计、可归因、可治理的工程纪律——目标不是"省钱第一"，而是**为业务价值花对的钱、且每一分都看得见**。
+
+## 1. 核心原则
+
+- **成本是一等指标**：和性能、可用性并列纳入设计取舍与就绪审查，不是事后优化。
+- **谁产生谁负责**：成本归因到团队/服务/功能，让花钱的人看得见自己的账单，而不是汇总成一笔无主的总数。
+- **看单位经济，而非总额**：盯**每请求/每用户/每订单成本**的趋势。总额涨可能是业务在涨（好事），单位成本涨才是效率在退化（坏事）。
+- **左移 + 护栏**：设计阶段估成本（左移），运行阶段用预算与护栏防失控，而不是月底被账单惊吓。
+- **价值导向**：目标是性价比最优，不是绝对最省——为可靠性/体验该花的钱要花，浪费的钱要砍。
+
+## 2. 成本可见与归因（看不见就治不了）
+
+- **统一标签/账单维度**：所有资源带强制标签（团队、服务、环境、功能/产品线），否则账单无法拆分。无标签资源应被检测并追责。
+- **成本看板**：把成本接入可观测体系，按团队/服务/环境出看板与趋势，让成本和延迟、错误率一样**天天可见**。
+- **单位经济指标**：定义并跟踪每请求/每活跃用户/每业务事件的成本，作为效率北极星。
+- **拆到驱动因素**：把成本拆到可操作的驱动项——计算、存储、网络出口（egress）、数据库、第三方 API、可观测性数据量——知道钱花在哪一类，才知道砍哪里。
+- **共享成本分摊**：平台/共享资源按可解释的规则分摊到使用方，避免"公共成本"成为无人负责的黑洞。
+
+## 3. 成本预算与护栏（防止月底惊吓）
+
+| 机制 | 作用 |
+|---|---|
+| 预算与阈值告警 | 给团队/服务设月度/环境预算，按消耗速度（而非到月底）预警，烧得快立即报 |
+| 异常突增检测 | 对成本曲线做异常检测，新部署/配置变更导致的突增**当天**发现，而不是下月对账 |
+| 硬性护栏 | 对易失控项设硬上界：自动扩容上限、单环境资源配额、非生产环境闲时自动停机 |
+| 变更成本预估 | 重大资源/架构变更在评审时给出成本影响预估，纳入决策 |
+| 浪费扫描 | 定期扫描闲置/超配/孤儿资源（无人用的实例、未挂载磁盘、过期快照），定期回收 |
+
+护栏的关键是**自动**：靠人记得去关、去缩容必然失守；让闲置自动停、让扩容有上界、让突增自动告警。
+
+## 4. 架构与实现层的成本杠杆
+
+成本主要在设计与代码里决定，下面是高杠杆项：
+
+- **按需伸缩 + 设上界**：自动扩缩容跟随真实负载，闲时缩容；但**必须设上限**，否则一次流量异常或重试风暴能把账单打穿。非生产环境闲时自动停。
+- **规格匹配（rightsizing）**：按实测用量选规格，不要"宁大勿小"长期超配；定期用利用率数据回收余量。
+- **存储分层与生命周期**：冷热数据分层，过期数据自动归档/清理（也呼应 `data` 的数据生命周期），别让日志/快照/临时数据无限增长。
+- **网络出口与跨区**：跨区/跨云/出公网流量是隐形大头——同区就近、减少不必要的跨区调用与数据搬运。
+- **缓存换计算/换调用**：合理缓存减少重复计算与昂贵的下游/第三方调用次数（注意缓存本身也有成本，取平衡）。
+- **可观测性数据成本**：高基数指标、全量追踪、海量 DEBUG 日志是成本失控重灾区——指标控基数、追踪采样、日志分级（与 `observability/01-standards/observability-and-slo-operations` 的基数纪律一致）。
+- **第三方/调用计费**：对按量计费的外部服务（含按 token/调用计费的能力）设用量预算与上限，避免单点失控烧钱。
+- **批处理与时段**：可延迟的批量作业放低峰/廉价资源跑，削峰填谷。
+
+## 5. 落地到交付流程
+
+- **设计阶段**：架构评审给出**成本量级预估**与主要驱动项，和性能/可用性一起取舍。
+- **实现阶段**：资源声明带标签、扩容带上界、非生产带停机策略，作为基础设施代码评审项。
+- **就绪阶段**：把"有成本归因、有预算告警、扩容有上界、无明显浪费"纳入生产就绪审查（见 `operations/01-standards/production-readiness-review`）。
+- **运营阶段**：定期成本复盘——看单位经济趋势、扫浪费、回收超配，把优化项排进迭代。
+
+## 6. 反模式（出现即不合格）
+
+1. **成本月底才看**：账单来了才发现翻倍，钱已花掉，无法事前干预。
+2. **资源无标签**：账单是一坨无主总额，拆不到团队/服务，谁也不负责。
+3. **自动扩容无上界**：一次异常/重试风暴把账单打穿，无硬护栏拦截。
+4. **只看总额不看单位经济**：分不清"业务在涨"还是"效率在退化"。
+5. **长期超配 + 闲置不回收**：宁大勿小，孤儿资源/闲置实例无人清理。
+6. **可观测性成本失控**：高基数指标 + 全量追踪 + 海量日志，遥测账单比业务还贵。
+7. **跨区/出口流量随意**：隐形网络费用长期被忽视。
+8. **省过头伤可靠性**：为省钱砍掉冗余/备份/必要余量，把成本问题变成可用性事故。
+
+## 7. 最低交付 checklist
+
+- [ ] 成本作为一等指标纳入设计取舍与生产就绪审查。
+- [ ] 资源强制打标签（团队/服务/环境/功能），无标签资源被检测追责。
+- [ ] 成本接入看板按团队/服务可见；定义并跟踪单位经济（每请求/每用户成本）。
+- [ ] 设团队/服务预算 + 按消耗速度告警 + 成本突增异常检测（当天发现）。
+- [ ] 自动扩容设上界、规格按实测匹配、非生产闲时停机、定期扫并回收浪费。
+- [ ] 存储分层与生命周期、减少跨区/出口流量、合理缓存降低重复计算与外部调用。
+- [ ] 可观测性数据成本受控（指标控基数/追踪采样/日志分级）；按量第三方设用量上限。
+- [ ] 重大资源/架构变更附成本预估；定期成本复盘把优化排进迭代。

package/operations/01-standards/production-readiness-review.md

@@ -0,0 +1,103 @@
+---
+id: production-readiness-review
+title: 生产就绪审查规范（PRR：上线前的 go/no-go 决策门，商业级必读）
+domain: operations
+category: 01-standards
+difficulty: advanced
+tags: [production-readiness, prr, go-no-go, slo, observability, rollback, runbook, on-call, launch-gate, sign-off, operability, 生产就绪, 上线决策, 可运维性, 回滚, 值班, 交付门, 商业级]
+quality_score: 95
+last_updated: 2026-06-29
+---
+# 生产就绪审查规范（PRR · 商业级必读）
+
+> "代码写完了"不等于"可以上线了"。一个服务能不能交付生产，取决于它能不能被**运维**：出问题看得见吗、扛得住吗、回得来吗、有人值班吗、有手册吗。
+> 生产就绪审查（PRR）是上线前的一次**结构化 go/no-go 决策**——把 SLO、可观测性、回滚、安全、容量、值班、手册这些散落的线索汇到一张桌子上，做一次明确的"放行 / 不放行"判定，并留下可审计的签字。它不是又一份逐条勾选的清单（清单见 `development/03-checklists/production-readiness-checklist`），而是把那些维度**收口成一个决策**的流程与门。
+
+## 1. 什么时候触发 PRR
+
+| 触发场景 | 是否需要 PRR |
+|---|---|
+| 新服务首次上线 | 必须，完整 PRR |
+| 重大架构变更 / 新增关键依赖 | 必须，聚焦受影响维度 |
+| 承接显著增长流量 / 新区域部署 | 必须，重点容量与容灾 |
+| 日常功能迭代（已就绪服务内） | 不需要，走常规发布门 |
+
+PRR 审查的是**服务的可运维性**，不是这一次代码改动的正确性。后者由代码评审、测试、发布门禁覆盖；PRR 回答的是"这个服务上了生产，运营得起来吗"。
+
+## 2. 心态：上线是一个决策，不是一个事件
+
+- **可运维性优先于功能完整**：宁可少上一个功能，也不要上一个出了事看不见、回不来的服务。
+- **未就绪要敢拦**：PRR 的价值在于敢说 no-go。橡皮图章式的 PRR 等于没有。
+- **就绪是带条件的**：可以"有条件放行"——明确遗留项、责任人、期限与补救方案，而不是非黑即白。
+- **审查留痕**：决策、未决项与签字归档，出事可回溯"当初是怎么放行的"。
+
+## 3. 审查维度（七根支柱，逐一收口）
+
+每一维度判定 **就绪 / 有条件 / 未就绪**，并指向其权威标准。
+
+### 3.1 SLO 与服务目标
+- 是否定义了**面向用户**的 SLI 与现实可达的 SLO（可用性/延迟/正确性）？错误预算如何使用？（见 `observability/01-standards/observability-and-slo-operations`、`operations/slo-sli-playbook`）
+- 关键业务指标是否明确（不止技术指标）？
+
+### 3.2 可观测性
+- 日志结构化、指标（RED/USE + 业务）、追踪是否齐备且**可关联**（一个 request_id 串起一次请求）？
+- 凭现有遥测能否定位**未预想**的故障，而不必先发版加日志？（见 `observability/01-standards/observability-and-slo-operations`）
+
+### 3.3 告警与值班
+- 告警是否**基于用户症状/错误预算燃尽**、条条可执行、指向 runbook、已分级？
+- 是否有明确的**值班轮值 + 升级路径 + 关键联系人**，且通知链路端到端验证过？
+
+### 3.4 回滚与恢复
+- 是否有**已验证可执行**的回滚方案（应用/配置/数据），回滚和发布同等可靠？（见 `release-engineering/release-rollback-and-recovery-playbook`）
+- 备份是否做了且**恢复演练过**（不是纸面备份）？关键数据 RPO/RTO 是否满足业务？（容灾见 `architecture/resilience-and-disaster-patterns`）
+
+### 3.5 韧性与容量
+- 出站调用是否有超时/重试预算/熔断/舱壁/降级？过载有无背压与卸载？（见 `backend/01-standards/resilience-and-fault-tolerance`）
+- 是否做过容量评估与压测（≥ 预期峰值的余量）？关键依赖故障的影响面是否已知且可控？
+
+### 3.6 安全与合规
+- 认证/授权/密钥管理/输入校验/安全头是否到位？依赖漏洞是否已分诊处理？（见 `backend/01-standards/dependency-and-supply-chain-hygiene`）
+- 审计日志、数据合规（个人数据处理）是否满足要求？
+
+### 3.7 运维手册与所有权
+- 是否有**Runbook**（常见故障的诊断与处置步骤，新人可照做）？
+- 服务**owner 明确**、依赖清单与上下游 SLA 清楚、变更/回滚方式已文档化？
+
+## 4. 决策判定与放行口径
+
+| 整体判定 | 条件 | 动作 |
+|---|---|---|
+| Go（放行） | 所有支柱"就绪"，无 Blocker | 批准上线，归档签字 |
+| Conditional Go（有条件放行） | 无 Blocker，存在带责任人+期限的遗留项 | 放行 + 跟踪遗留项到关闭 |
+| No-Go（不放行） | 存在 Blocker（无回滚/无监控/无值班/未达 SLO 前提） | 拦截，修复后重审 |
+
+**硬 Blocker（任一存在即 No-Go）**：没有可执行回滚；故障基本看不见（无遥测/无告警）；无人值班或升级路径不通；备份从未验证恢复；已知严重且可利用的安全漏洞未处理。这些是"上了就是赌运气"的红线。
+
+## 5. 角色与产出
+
+- **服务 owner**：发起 PRR，准备证据（SLO 定义、监控看板、回滚演练记录、runbook）。
+- **审查者**：运维/SRE 视角 + 安全视角，逐维度判定，敢于给 No-Go。
+- **产出物**：一份 PRR 记录——逐维度判定、遗留项（责任人/期限/补救）、最终 go/no-go 决策与签字，归档可审计（建议落 `output/`）。
+- **闭环**：有条件放行的遗留项必须被跟踪到关闭；上线后一段时间复盘 SLO 实际表现与首批事故。
+
+## 6. 反模式（出现即不合格）
+
+1. **橡皮图章 PRR**：走过场签字，从不给 No-Go，等于没审查。
+2. **代码评审冒充 PRR**：只审这次改动对不对，不审服务能不能被运维。
+3. **没有回滚就上**：出事只能向前修，没有"撤回"按钮。
+4. **遥测/告警缺位还放行**：上线后故障看不见，全靠用户投诉。
+5. **无人值班 / 升级路径不通**：半夜出事没人响应，告警发进黑洞。
+6. **备份没验证恢复**：以为有备份，真要恢复时发现恢复不出来。
+7. **有条件放行后不跟踪**：遗留项一放就忘，技术债与风险沉淀。
+8. **PRR 只在首次上线做一次**：重大架构变更后从不重审，老结论早已失效。
+
+## 7. 最低交付 checklist
+
+- [ ] 明确 PRR 触发条件，新服务/重大变更/扩量/新区域强制 PRR。
+- [ ] 七根支柱逐一收口判定（就绪/有条件/未就绪），各指向权威标准并附证据。
+- [ ] SLO 面向用户且现实；遥测可关联、能定位未预想故障；告警可执行分级。
+- [ ] 回滚方案已验证可执行；备份已演练恢复；RPO/RTO 满足业务。
+- [ ] 韧性（超时/熔断/降级）与容量（压测余量）已验证；依赖故障影响面可控。
+- [ ] 值班轮值 + 升级路径 + 通知链路端到端验证；服务 owner 明确；Runbook 可照做。
+- [ ] 给出明确 go / conditional-go / no-go 决策；硬 Blocker 一律 No-Go。
+- [ ] PRR 记录（判定/遗留项/责任人/期限/签字）归档可审计；有条件放行项跟踪到关闭。

package/operations/01-standards/prometheus-monitoring-complete.md

@@ -5,8 +5,8 @@ domain: operations
 category: 01-standards
 difficulty: intermediate
 tags: [complete, grafana仪表盘, kubernetes监控, monitoring, operations, prometheus, prometheus核心概念, promql查询语言]
-quality_score: 70
-last_updated: 2026-06-15
+quality_score: 90
+last_updated: 2026-06-29
 ---
 # Prometheus监控完整指南
 

package/operations/aiops-anomaly-detection.md

@@ -1,18 +1,14 @@
 ---
 id: aiops-anomaly-detection
-title: aiops-anomaly-detection
+title: AIOps 异常检测体系
 domain: operations
-category: aiops-anomaly-detection.md
+category: 01-standards
 difficulty: intermediate
-tags: [aiops, anomaly, detection, operations, 告警降噪, 实施架构, 常见失败模式, 异常检测算法]
+tags: [aiops, 异常检测, anomaly-detection, 告警降噪, 时序, 根因, operations]
 quality_score: 70
 last_updated: 2026-06-15
 ---
-# 开发：Excellent（11964948@qq.com）
-# 功能：AIOps 异常检测实践指南
-# 作用：利用机器学习和 AI 技术自动化检测和诊断系统异常
-# 创建时间：2026-03-20
-# 最后修改：2026-03-20
+# AIOps 异常检测体系
 
 ## 目标
 建立 AIOps 异常检测体系,通过机器学习算法自动识别系统异常、减少告警噪音、加速根因定位、实现智能运维。

package/operations/capacity-planning.md

@@ -1,18 +1,14 @@
 ---
 id: capacity-planning
-title: capacity-planning
+title: 容量规划体系
 domain: operations
-category: capacity-planning.md
+category: 01-standards
 difficulty: intermediate
-tags: [capacity, operations, planning, 容量规划报告, 容量规划流程, 当前状态, 执行摘要, 核心概念]
+tags: [容量规划, capacity-planning, 资源预测, 扩容, 成本, operations]
 quality_score: 70
 last_updated: 2026-06-15
 ---
-# 开发：Excellent（11964948@qq.com）
-# 功能：容量规划实践指南
-# 作用：提供系统容量预测、规划和优化的完整方法论
-# 创建时间：2026-03-20
-# 最后修改：2026-03-20
+# 容量规划体系
 
 ## 目标
 建立科学的容量规划体系,预测业务增长带来的资源需求,提前规划扩容,避免性能瓶颈和资源浪费,实现成本与性能的最优平衡。

package/operations/chaos-engineering.md

@@ -1,18 +1,14 @@
 ---
 id: chaos-engineering
-title: chaos-engineering
+title: 混沌工程实践
 domain: operations
-category: chaos-engineering.md
+category: 01-standards
 difficulty: intermediate
-tags: [chaos, engineering, operations, 分钟, 实施流程, 实验信息, 实验概况, 核心原则]
+tags: [混沌工程, chaos-engineering, 故障注入, 韧性, 演练, operations]
 quality_score: 70
 last_updated: 2026-06-15
 ---
-# 开发：Excellent（11964948@qq.com）
-# 功能：混沌工程实践指南
-# 作用：通过主动注入故障验证系统韧性,提前发现和修复潜在问题
-# 创建时间：2026-03-20
-# 最后修改：2026-03-20
+# 混沌工程实践
 
 ## 目标
 建立混沌工程实践体系,通过受控的故障注入实验,验证系统在生产环境真实负载下的韧性,提前发现和修复潜在问题,提升服务可靠性。

package/operations/incident-command-system.md

@@ -1,16 +1,14 @@
 ---
 id: incident-command-system
-title: incident-command-system
+title: 事故指挥体系（ICS）手册
 domain: operations
-category: incident-command-system.md
+category: 02-playbooks
 difficulty: intermediate
-tags: [command, incident, operations, system]
+tags: [事故指挥, incident-command, ics, 应急响应, 值班, operations]
 quality_score: 70
 last_updated: 2026-06-15
 ---
-# 开发：Excellent（11964948@qq.com）
-
-## 事故指挥体系（ICS）手册
+# 事故指挥体系（ICS）手册
 
 ### 目标
 - 在生产事故中实现统一指挥、快速止损、清晰协同。

package/operations/observability-complete.md

@@ -1,18 +1,14 @@
 ---
 id: observability-complete
-title: observability-complete
+title: 可观测性完整知识库
 domain: operations
-category: observability-complete.md
+category: 01-standards
 difficulty: intermediate
-tags: [complete, dashboard, observability, operations, 告警设计, 实施清单, 常见失败模式, 技术选型]
+tags: [可观测性, observability, 监控, 追踪, 日志, 告警, operations]
 quality_score: 70
 last_updated: 2026-06-15
 ---
-# 开发：Excellent（11964948@qq.com）
-# 功能：可观测性完整体系
-# 作用：提供日志、指标、追踪三大支柱的完整实施指南
-# 创建时间：2026-03-20
-# 最后修改：2026-03-20
+# 可观测性完整知识库
 
 ## 目标
 建立生产环境全链路可观测能力,实现故障快速定位、性能瓶颈精准识别、用户体验量化评估。

package/operations/slo-sli-playbook.md

@@ -1,18 +1,14 @@
 ---
 id: slo-sli-playbook
-title: slo-sli-playbook
+title: SLO/SLI 实践手册
 domain: operations
-category: slo-sli-playbook.md
+category: 02-playbooks
 difficulty: intermediate
-tags: [budget, operations, playbook, sli, slo, 实施流程, 核心概念, 目标]
+tags: [slo, sli, 可靠性, 错误预算, error-budget, 服务质量, operations]
 quality_score: 70
 last_updated: 2026-06-15
 ---
-# 开发：Excellent（11964948@qq.com）
-# 功能：SLO/SLI 实战手册
-# 作用：提供服务水平目标（SLO）和服务水平指标（SLI）的完整实施指南
-# 创建时间：2026-03-20
-# 最后修改：2026-03-20
+# SLO/SLI 实践手册
 
 ## 目标
 建立以 SLO 为中心的可靠性工程体系,量化服务质量,平衡功能交付与稳定性,实现数据驱动的故障响应和容量规划。

package/operations/sre-operations-deep-dive.md

@@ -1,16 +1,14 @@
 ---
 id: sre-operations-deep-dive
-title: sre-operations-deep-dive
+title: 运维环节深度知识库
 domain: operations
-category: sre-operations-deep-dive.md
+category: 01-standards
 difficulty: intermediate
-tags: [deep, dive, operations, sre, 运维环节深度知识库]
+tags: [sre, 运维, 可观测, 应急, 容量, operations]
 quality_score: 70
 last_updated: 2026-06-15
 ---
-# 开发：Excellent（11964948@qq.com）
-
-## 运维环节深度知识库
+# 运维环节深度知识库
 
 ### 目标
 - 构建可观测、可响应、可恢复的生产运行体系。

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@umacloud/knowledge",
-  "version": "1.0.15",
+  "version": "1.0.17",
   "description": "UmaDev curated engineering knowledge corpus (standards, methodologies, expert playbooks, design systems, miniprogram/uniapp guides). Platform-independent data shipped once so npm users get the full KB offline.",
   "license": "MIT",
   "repository": { "type": "git", "url": "https://github.com/umacloud/umadev.git" },

package/performance/01-standards/performance-budgets-and-load-testing.md

@@ -0,0 +1,91 @@
+---
+id: performance-budgets-and-load-testing
+title: 性能预算与负载测试规范（商业级必读）
+domain: performance
+category: 01-standards
+difficulty: advanced
+tags: [performance-budget, latency-budget, load-test, soak-test, spike-test, stress-test, core-web-vitals, headroom, percentile, capacity, 性能预算, 负载测试, 压测, 容量, 商业级]
+quality_score: 95
+last_updated: 2026-06-29
+---
+# 性能预算与负载测试规范（商业级必读）
+
+> "感觉挺快"不是性能标准。商业级团队把性能写成**预算**——每条关键路径有明确的延迟/资源上限，超了就当成 bug，在上线前就拦住；并用**负载测试**在真实压力下证明系统在容量内仍守得住这些预算。
+> 性能不是上线后被用户骂了才优化的事，而是**事先定额、持续度量、纳入门禁**的工程纪律。
+
+## 1. 核心原则
+
+- **预算先行**：先为关键路径定下"最慢可以多慢、最多用多少资源"，再实现，而不是事后测一下凑合。
+- **看分位数，不看平均**：平均值会骗人。盯 **p95 / p99**——尾延迟才是真实用户的痛点。
+- **预算即门禁**：性能预算接进 CI / 发布门禁，回归就拦，别等用户发现。
+- **在压力下验证**：单用户快不算数，要在**目标并发**下仍满足预算才算达标。
+- **留余量（headroom）**：系统要在峰值之上留容量缓冲，不能跑在 100% 上等着被一个尖峰打挂。
+
+## 2. 性能预算定什么
+
+为每条**关键路径**（核心 API、关键页面、关键作业）定可度量的上限：
+
+| 维度 | 预算示例 | 度量 |
+|---|---|---|
+| 后端接口延迟 | 关键读接口 p95 < 200ms、p99 < 500ms | 服务端指标 |
+| 端到端延迟 | 核心操作端到端 p95 < 800ms | 真实用户监控（RUM）|
+| 前端加载 | 关键页面在 4G、中端设备上达成核心网页指标的"良好"档 | 实验室 + 现场 RUM |
+| 资源体积 | 关键页面首屏 JS ≤ N KB、总传输 ≤ M KB | 构建产物分析 |
+| 吞吐 | 系统在目标 QPS 下错误率 < 0.1% | 负载测试 |
+| 资源占用 | 单实例峰值 CPU < 70%、内存不增长（无泄漏）| 资源监控 |
+
+要点：预算要写成**带数字 + 带分位 + 带条件**（设备/网络/并发）的可验证目标，不写"要快"（见 `experts/product-manager/requirements-engineering-ears` 对 NFR 的要求）。
+
+## 3. 前端：核心网页指标与资源预算
+
+- **核心网页指标**：加载速度、交互响应、视觉稳定性三类用户体验指标，对每条关键页面设"良好"阈值，并在**现场真实用户数据**（而非只在实验室）上达标——实验室绿、现场红等于没达标。
+- **资源预算**：限制关键页面的 JS/CSS/图片体积与请求数；构建时检查，超预算就拦 PR，防止"每次加一点点"温水煮青蛙式劣化。
+- **关键路径优先**：预算优先盯首屏与核心交互路径，而不是平均所有页面。
+
+## 4. 负载测试的四种形态（别只跑一种）
+
+| 类型 | 问什么 | 做法 |
+|---|---|---|
+| 负载（load）| 预期峰值下达标吗？ | 加压到目标峰值并维持，看延迟/错误率是否守预算 |
+| 压力（stress）| 极限在哪、怎么坏的？ | 持续加压直到崩溃，找拐点与失效模式（是优雅降级还是雪崩）|
+| 尖峰（spike）| 流量突增扛得住吗？ | 瞬间拉高再回落，看能否快速吸收与恢复 |
+| 浸泡（soak）| 长时间稳定吗？ | 中等负载跑数小时~数天，抓内存泄漏、资源耗尽、连接池枯竭、缓慢劣化 |
+
+只跑短时负载测试会**漏掉浸泡才暴露的泄漏类问题**——很多生产事故是"跑了三天才挂"。四种各问不同的问题，按风险选跑。
+
+## 5. 测试方法纪律
+
+- **环境贴近生产**：在与生产相近规模/配置的环境压测；玩具环境的数字不可外推。
+- **真实负载模型**：用接近真实的请求分布、数据规模、并发曲线，别只压一个最快的接口。
+- **数据规模真实**：在生产量级的数据上测（大表的查询才会慢），用合成/脱敏数据（见 `testing/01-standards/test-data-and-ephemeral-environments`）。
+- **隔离变量**：一次只改一个因素，否则分不清是谁的影响。
+- **建立基线 + 防回归**：记录基线，关键发布前重压，对比是否劣化；理想情况接入流水线定期回归。
+
+## 6. 容量与余量
+
+- **按峰值 + 余量规划**：容量按业务峰值再留缓冲（不跑在满载），应对突发与故障转移后的负载集中。
+- **找瓶颈**：通过压测定位最先饱和的资源（CPU/内存/IO/连接池/下游依赖），那就是容量上限所在。
+- **自动伸缩有上限与冷启动成本**：弹性扩容不是万能——扩容有延迟、有上限、冷启动有代价，尖峰场景要预热或预留。
+- **与韧性联动**：过载时的行为（限流、卸载、降级）见 `backend/01-standards/resilience-and-fault-tolerance`；容量规划深做见 `operations/capacity-planning`。
+
+## 7. 反模式（出现即不合格）
+
+1. **只看平均延迟**：平均很美，p99 很惨，真实用户在尾部受苦。
+2. **无预算**：没有事先定额，性能好坏全凭感觉，劣化无人察觉。
+3. **只测单用户**：本地一个人点着很快，目标并发下直接崩。
+4. **不跑浸泡**：短测全绿，上线三天后内存泄漏/连接耗尽挂掉。
+5. **玩具环境压测**：在远小于生产的环境压出的数字拿去承诺生产容量。
+6. **空库压测**：在没数据的库上测查询，生产大表上全慢。
+7. **跑满不留余量**：容量卡在峰值，一个尖峰或一次故障转移就雪崩。
+8. **性能不进门禁**：性能回归靠用户投诉发现，而不是 CI 拦住。
+
+## 8. 最低交付 checklist
+
+- [ ] 关键路径有明确性能预算（带数字、分位、条件），写成可验证目标。
+- [ ] 盯 p95/p99 尾延迟，不以平均值判定达标。
+- [ ] 前端关键页面对核心网页指标在现场真实数据上达标，并有资源体积预算。
+- [ ] 性能预算接入 CI / 发布门禁，回归即拦。
+- [ ] 在贴近生产的环境、真实负载模型与数据规模下做负载测试。
+- [ ] 按风险覆盖负载/压力/尖峰/浸泡，浸泡测试抓泄漏类问题。
+- [ ] 容量按峰值 + 余量规划，已定位主要瓶颈资源。
+- [ ] 建立性能基线，关键发布前重压对比、防回归。

package/product/feature-prioritization-framework.md

@@ -1,40 +1,102 @@
 ---
 id: feature-prioritization-framework
-title: feature-prioritization-framework
+title: 功能优先级决策框架（商业级必读）
 domain: product
-category: feature-prioritization-framework.md
+category: 02-playbooks
 difficulty: intermediate
-tags: [feature, framework, prioritization, product]
-quality_score: 70
-last_updated: 2026-06-15
+tags: [优先级, prioritization, 排期, roadmap, rice, kano, 价值成本矩阵, 决策门, 取舍, 需求评审, 产品, 商业级]
+quality_score: 95
+last_updated: 2026-06-29
 ---
-# 开发：Excellent（11964948@qq.com）
-
-## 功能优先级决策框架（深度版）
-
-### 目标
-- 统一需求排期口径，避免“拍脑袋优先级”导致资源浪费。
-
-### 四维评分模型
-- 业务价值：是否直接推动收入、留存、效率提升。
-- 用户价值：是否解决高频痛点或关键任务阻塞。
-- 实现成本：研发、测试、运维、培训与迁移成本。
-- 风险敞口：合规、安全、稳定性、依赖不确定性。
-
-### 评分规则
-- 每维 1-5 分，最终分数 = (业务价值+用户价值)×权重 - (实现成本+风险敞口)×权重。
-- 默认权重：业务价值0.35、用户价值0.25、实现成本0.2、风险0.2。
-- 分数相近时，以“减少关键链路风险”优先。
-
-### 决策门禁
-- 涉及账号、支付、权限、数据导出功能时，风险评分必须由安全与运维双签。
-- 涉及跨系统变更时，必须有回滚方案与兼容策略。
-- 未给出可量化验收标准的需求不得进入开发。
-
-### 输出模板
-- 需求名称
-- 预期业务影响
-- 用户受益群体
-- 估算工作量
-- 依赖项与风险
-- 发布策略与回滚方案
+
+# 功能优先级决策框架（商业级必读）
+
+> 优先级决定一个团队把有限的研发产能投到哪里——它比"做得好不好"更早、更致命地决定产品成败。最常见的失败不是把某个功能做砸，而是把整季产能投在低价值需求上。"拍脑袋排期""谁声音大做谁的""老板说的先做"都不是优先级方法，只是把决策责任藏起来。本框架把优先级从主观争论升级为**可复算、可追责、带门禁的决策**：每个需求都要有量化打分、验收标准、回滚策略，且高风险项必须双签。
+
+## 1. 先分类，再打分（不要对所有需求用同一把尺）
+
+打分前先用一个粗筛把需求分桶，避免把"救火"和"探索"放进同一个排序里：
+
+| 类型 | 判定 | 处置 |
+|---|---|---|
+| **合规/安全/止血** | 不做会违法、泄露、资损或线上事故 | 不进打分队列，直接最高优先级排期 |
+| **核心价值线** | 直接驱动北极星指标（激活/留存/收入/成本） | 进加权打分，主战场 |
+| **体验/效率优化** | 改善现有任务流的成功率与耗时 | 进打分，与价值线竞争产能 |
+| **探索/赌注** | 高不确定性、可能高回报 | 单独留固定产能比例（如 10–20%），不与确定性需求直接比分 |
+| **债务/可维护性** | 不做会持续拖慢未来交付 | 量化"拖慢成本"后进打分，禁止长期归零 |
+
+## 2. 四维加权评分模型
+
+每个进入打分队列的需求按四维各 1–5 分，给出可复算的综合分。
+
+| 维度 | 含义 | 1 分 | 5 分 | 默认权重 |
+|---|---|---|---|---|
+| 业务价值 | 对收入/留存/成本/战略的直接推动 | 几乎无关 | 直接撬动北极星指标 | 0.35 |
+| 用户价值 | 解决痛点的频率 × 强度 | 边缘场景 | 高频关键任务阻塞 | 0.25 |
+| 实现成本 | 研发+测试+运维+迁移+培训（反向计入） | 一周内 | 跨团队多季度 | 0.20 |
+| 风险敞口 | 合规/安全/稳定性/依赖不确定性（反向计入） | 隔离可控 | 触及账号/支付/数据 | 0.20 |
+
+`综合分 = (业务价值×0.35 + 用户价值×0.25) − (实现成本×0.20 + 风险敞口×0.20)`
+
+- 权重不是固定的：早期产品调高用户价值，规模化阶段调高业务价值与风险；权重一旦定了，**整季不随单个需求改**，否则打分失去公信力。
+- 分数相近（差值在 0.3 内）时，**以"减少关键链路风险/降低不确定性"优先**——先做能解锁后续决策的需求。
+- 打分是输入不是判决：评审用分数聚焦讨论分歧最大的维度，而不是机械按分排期。
+
+## 3. 价值/成本四象限（快速版，用于粗排与对齐）
+
+当需求多、时间紧时，用二维矩阵先对齐方向，再对争议项做四维细打分。
+
+| | 低成本 | 高成本 |
+|---|---|---|
+| **高价值** | 立即做（quick win） | 重点投入，需拆分里程碑 |
+| **低价值** | 顺手做/批量清 | 不做或砍掉（最危险象限：高成本低价值） |
+
+- 警惕"高成本低价值"象限——它最容易因为"已经投入了"而被沉没成本绑架。
+- "高价值高成本"必须拆成可独立交付、可独立验证的里程碑，避免一次性大爆炸。
+
+## 4. 满意度模型：区分"必备"与"惊喜"
+
+同样高分的需求，对用户满意度的作用并不线性，排期时要区分：
+
+- **必备型**：缺了就投诉、做到顶也只是"不扣分"（如登录稳定、支付不丢单）→ 必须满足基线，但不要过度打磨。
+- **期望型**：投入与满意度线性相关 → 主战场，按四维分排。
+- **惊喜型**：用户没预期，做到了显著加分 → 适合作为差异化赌注，但不能挤占必备型产能。
+
+## 5. 决策门禁（硬约束，不可绕过）
+
+- 涉及**账号、支付、权限、数据导出/删除**的功能，风险评分必须由**安全 + 运维双签**方可进开发。
+- 涉及**跨系统/跨团队**变更，必须附**回滚方案 + 向后兼容策略**，否则不予排期。
+- **没有可量化验收标准**的需求不进开发队列（"做个更好的搜索"不是需求，"搜索 P95 < 300ms 且 0 结果率 < 5%"才是）。
+- 每个排期需求必须绑定**至少 1 个业务指标 + 1 个质量指标**，并预设上线后的验证窗口与下线条件。
+
+## 6. 输出模板（每个排期需求必须填全）
+
+- 需求名称与一句话价值主张
+- 预期业务影响（绑定哪个指标、预期幅度、衡量口径）
+- 受益用户群体与触发场景频率
+- 四维打分 + 综合分（含权重快照）
+- 估算工作量与关键依赖
+- 风险敞口与缓解措施（高风险需双签记录）
+- 验收标准（可判定）+ 上线后验证窗口 + 回滚/下线条件
+- 发布策略（灰度比例、放量节奏）
+
+## 反模式
+
+- **拍脑袋优先级**：用职级、嗓门、最近一次会议决定排期，没有可复算的打分，事后无法追责。
+- **权重随需求漂移**：为了让某个需求排上去临时改权重，打分体系沦为表演。
+- **只算价值不算风险**：把账号/支付/权限类高风险需求当普通功能排，绕过双签，埋下资损与合规雷。
+- **沉没成本绑架**：因为"已经做了一半"就继续投入高成本低价值项，而不是及时止损。
+- **无验收标准入队**：需求描述模糊、没有可量化的成功定义，导致做完无法判断成败，也无法回滚。
+- **探索与确定性混排**：把高不确定性赌注和确定性需求放进同一个排序，要么赌注永远排不上、要么挤垮基本盘。
+- **必备型过度打磨**：在"做到顶也只是不扣分"的必备功能上投入惊喜型的产能。
+
+## 最低交付 checklist
+
+- [ ] 所有候选需求已分桶（合规止血 / 核心价值 / 体验优化 / 探索 / 债务），止血类不进打分直接排期。
+- [ ] 进队列需求均有四维打分 + 综合分，权重在本季度内固定且公开。
+- [ ] 高成本需求已拆为可独立交付、可独立验证的里程碑。
+- [ ] 账号/支付/权限/数据类需求已完成安全+运维双签并留痕。
+- [ ] 跨系统变更均附回滚方案与向后兼容策略。
+- [ ] 每个排期需求绑定 ≥1 业务指标 + ≥1 质量指标，并有可判定的验收标准。
+- [ ] 探索类需求有独立产能配额，未挤占确定性基本盘。
+- [ ] 排期结论与未采纳需求的理由均有记录，可向相关方解释。