@umacloud/knowledge 1.0.14 → 1.0.16

package/mobile/01-standards/flutter-complete.md

@@ -3,14 +3,14 @@ title: Flutter 完整开发标准
 category: mobile/standards
 version: 1.0.0
 last_updated: 2026-03-20
-maintainer: Excellent（11964948@qq.com）
+maintainer: Excellent（）
 knowledge_score: 9.3/10
 domain: mobile
 difficulty: intermediate
 quality_score: 70
 ---
 
-# 开发：Excellent（11964948@qq.com）
+# Flutter 完整开发标准
 
 ## Flutter 完整开发标准
 
@@ -79,7 +79,7 @@ quality_score: 70
 
 ### Widget 组件示例
 ```dart
-// 开发：Excellent（11964948@qq.com）
+// 开发：Excellent（）
 // 功能：用户头像组件
 // 作用：展示用户头像，支持默认头像和加载状态
 // 创建时间：2026-03-20
@@ -150,7 +150,7 @@ class UserAvatar extends StatelessWidget {
 
 ### 网络请求封装示例
 ```dart
-// 开发：Excellent（11964948@qq.com）
+// 开发：Excellent（）
 // 功能：API 客户端封装
 // 作用：统一管理网络请求，包含认证和错误处理
 // 创建时间：2026-03-20
@@ -230,7 +230,7 @@ final apiClient = ApiClient();
 
 ### 状态管理示例（Provider）
 ```dart
-// 开发：Excellent（11964948@qq.com）
+// 开发：Excellent（）
 // 功能：用户状态管理
 // 作用：管理用户登录状态和用户信息
 // 创建时间：2026-03-20

package/mobile/01-standards/react-native-complete.md

@@ -3,14 +3,14 @@ title: React Native 完整开发标准
 category: mobile/standards
 version: 1.0.0
 last_updated: 2026-03-20
-maintainer: Excellent（11964948@qq.com）
+maintainer: Excellent（）
 knowledge_score: 9.2/10
 domain: mobile
 difficulty: intermediate
 quality_score: 70
 ---
 
-# 开发：Excellent（11964948@qq.com）
+# React Native 完整开发标准
 
 ## React Native 完整开发标准
 
@@ -79,7 +79,7 @@ quality_score: 70
 ### TypeScript 组件示例
 ```typescript
 /**
- * 开发：Excellent（11964948@qq.com）
+ * 开发：Excellent（）
  * 功能：用户头像组件
  * 作用：展示用户头像，支持默认头像和加载状态
  * 创建时间：2026-03-20
@@ -138,7 +138,7 @@ const styles = StyleSheet.create({
 ### 网络请求封装示例
 ```typescript
 /**
- * 开发：Excellent（11964948@qq.com）
+ * 开发：Excellent（）
  * 功能：API 客户端封装
  * 作用：统一管理网络请求，包含认证和错误处理
  * 创建时间：2026-03-20
@@ -201,7 +201,7 @@ export const apiClient = new ApiClient();
 ### FlatList 优化示例
 ```typescript
 /**
- * 开发：Excellent（11964948@qq.com）
+ * 开发：Excellent（）
  * 功能：用户列表组件
  * 作用：高性能渲染用户列表，支持下拉刷新和加载更多
  * 创建时间：2026-03-20

package/mobile/02-playbooks/mobile-performance.md

@@ -3,14 +3,14 @@ title: 移动应用性能优化手册
 category: mobile/playbooks
 version: 1.0.0
 last_updated: 2026-03-20
-maintainer: Excellent（11964948@qq.com）
+maintainer: Excellent（）
 knowledge_score: 9.0/10
 domain: mobile
 difficulty: intermediate
 quality_score: 70
 ---
 
-# 开发：Excellent（11964948@qq.com）
+# 移动应用性能优化手册
 
 ## 移动应用性能优化手册
 
@@ -88,7 +88,7 @@ quality_score: 70
 #### React Native 优化
 ```typescript
 /**
- * 开发：Excellent（11964948@qq.com）
+ * 开发：Excellent（）
  * 功能：优化 FlatList 性能
  * 作用：通过配置优化参数提升长列表渲染性能
  * 创建时间：2026-03-20
@@ -165,7 +165,7 @@ export default OptimizedList;
 
 #### Flutter 优化
 ```dart
-// 开发：Excellent（11964948@qq.com）
+// 开发：Excellent（）
 // 功能：优化 ListView 性能
 // 作用：通过 const 和 builder 提升长列表渲染性能
 // 创建时间：2026-03-20
@@ -231,7 +231,7 @@ class _ItemTile extends StatelessWidget {
 #### React Native 性能监控
 ```typescript
 /**
- * 开发：Excellent（11964948@qq.com）
+ * 开发：Excellent（）
  * 功能：性能监控工具
  * 作用：记录和上报关键性能指标
  * 创建时间：2026-03-20
@@ -326,7 +326,7 @@ export const performanceMonitor = PerformanceMonitor.getInstance();
 
 #### Flutter 性能监控
 ```dart
-// 开发：Excellent（11964948@qq.com）
+// 开发：Excellent（）
 // 功能：性能监控工具
 // 作用：记录和上报关键性能指标
 // 创建时间：2026-03-20

package/mobile/03-checklists/mobile-release-checklist.md

@@ -3,14 +3,14 @@ title: 移动应用发布检查清单
 category: mobile/checklists
 version: 1.0.0
 last_updated: 2026-03-20
-maintainer: Excellent（11964948@qq.com）
+maintainer: Excellent（）
 knowledge_score: 9.1/10
 domain: mobile
 difficulty: intermediate
 quality_score: 70
 ---
 
-# 开发：Excellent（11964948@qq.com）
+# 移动应用发布检查清单
 
 ## 移动应用发布检查清单
 

package/mobile/04-antipatterns/mobile-antipatterns.md

@@ -3,14 +3,14 @@ title: 移动开发反模式库
 category: mobile/antipatterns
 version: 1.0.0
 last_updated: 2026-03-20
-maintainer: Excellent（11964948@qq.com）
+maintainer: Excellent（）
 knowledge_score: 9.0/10
 domain: mobile
 difficulty: intermediate
 quality_score: 70
 ---
 
-# 开发：Excellent（11964948@qq.com）
+# 移动开发反模式库
 
 ## 移动开发反模式库
 

package/observability/01-standards/observability-and-slo-operations.md

@@ -0,0 +1,88 @@
+---
+id: observability-and-slo-operations
+title: 可观测性与 SLO 运营规范（埋点契约/关联/错误预算，商业级必读）
+domain: observability
+category: 01-standards
+difficulty: advanced
+tags: [observability, structured-logging, metrics, tracing, correlation, slo, sli, error-budget, instrumentation-contract, cardinality, alerting, 可观测性, 结构化日志, 链路追踪, 错误预算, 商业级]
+quality_score: 95
+last_updated: 2026-06-29
+---
+# 可观测性与 SLO 运营规范（商业级必读）
+
+> 监控回答"系统是不是挂了"，可观测性回答"**为什么挂、挂在哪、影响谁**"——尤其是面对**从没预想过**的故障，你能不能只靠已有的遥测数据查出来，而不必先发一版新代码加日志。
+> 商业级系统把"每个服务必须发出什么遥测"当成**埋点契约**来落地，把三类信号（日志/指标/追踪）用统一关联键打通，并用 **SLO + 错误预算**把"健康"从主观感受变成可运营的数字。
+
+## 1. 三类信号，各司其职
+
+| 信号 | 回答 | 特点 |
+|---|---|---|
+| 指标（metrics）| "坏了吗？坏多少？"（趋势、聚合）| 便宜、可长留、适合告警与看板 |
+| 日志（logs）| "具体发生了什么？"（离散事件细节）| 信息密度高、量大、要结构化 |
+| 追踪（traces）| "慢/错在调用链的哪一跳？"（请求穿越多服务的路径）| 定位跨服务瓶颈与故障点 |
+
+三者不是三选一，而是**互补**：指标发现异常 → 追踪定位到哪一跳 → 日志看那一跳的细节。关键是它们能**互相关联**（见 §3）。
+
+## 2. 埋点契约（每个服务必须发出的最小遥测）
+
+把"该发什么"标准化，避免每个服务各记各的、查问题时拼不起来：
+
+- **结构化日志**：JSON/键值，不是裸文本字符串。必带字段：时间戳（UTC、ISO-8601）、级别、服务名、**关联ID（request_id / trace_id）**、消息；事件相关的关键业务字段。
+- **请求/依赖指标**：每个入站端点与每个出站依赖发出请求量、错误率、延迟分布（直方图，能算分位）；资源侧发出利用率与饱和度。
+- **追踪**：入口生成/承接 trace，向所有下游**传播追踪上下文**，每个关键操作开 span，记录耗时与状态。
+- **业务指标**：注册、下单、支付、转化等业务事件计数——技术全绿但下单为零也是事故。
+- **健康检查**：存活/就绪端点，区分"进程活着"和"能正常服务"（依赖就绪）。
+
+## 3. 关联：把三类信号缝起来
+
+- **统一关联ID**：每个请求在入口生成 `request_id` / `trace_id`，**贯穿**该请求触发的所有日志、span、跨服务调用。出问题时凭一个 ID 就能把一次请求的日志、链路、指标全捞出来。
+- **上下文传播**：调用下游时透传追踪上下文（标准追踪头），让链路不断裂。
+- **日志带 trace_id**：每条日志都带当前 trace_id，实现"从一条慢链路一键跳到对应日志"。
+- **统一维度**：服务名、环境、版本、端点等标签在三类信号里取**一致的命名**，才能交叉关联。
+
+## 4. 基数（cardinality）纪律
+
+可观测性最容易失控、最容易烧钱的地方是**高基数标签**：
+
+- **指标标签不放无界值**：用户ID、请求ID、邮箱、完整 URL 等高基数值**绝不**做指标标签（会让时间序列爆炸、成本失控、查询变慢）。这些放**日志/追踪**里（它们按事件存，能承载高基数）。
+- **路径要模板化**：`/orders/123` 在指标里归一为 `/orders/{id}`，不要每个 id 一条序列。
+- **采样**：高流量追踪可采样（按比例 + 对错误/慢请求强制保留），平衡成本与可见性。
+- **日志分级与量控**：DEBUG 默认关；避免热路径里高频打无用日志把信号淹没、把成本拉高。
+
+## 5. SLI / SLO / 错误预算（把"健康"变成可运营的数字）
+
+- **SLI（指标）**：从用户视角度量服务质量的量——可用性（成功请求占比）、延迟（达标请求占比）、正确性等。盯**用户体验到的**，不是 CPU。
+- **SLO（目标）**：给 SLI 定目标，如"30 天内 99.9% 的请求成功且 p95 < 300ms"。SLO 要现实、可达、对齐业务。
+- **错误预算（error budget）**：100% 减去 SLO = 允许的"不达标额度"。99.9% 即每月约 0.1% 的预算。
+  - 预算**没烧光** → 可以快速发布、大胆迭代。
+  - 预算**烧光** → 冻结高风险变更、优先稳定性，直到回到预算内。
+  - 这把"该求快还是求稳"从拍脑袋变成**数据驱动**的决策（深做见 `operations/slo-sli-playbook`）。
+
+## 6. 告警：少而准，可执行
+
+- **基于症状告警**：对**用户感受到的**问题告警（错误率、延迟、SLO 燃尽），而不是对每个内部抖动（单台 CPU 高）告警。
+- **错误预算燃尽率告警**：按预算消耗速度告警——烧得快（短窗口高燃尽）才需立刻叫人，慢烧给工单即可。
+- **每条告警可执行**：触发即有人能做事，并指向 runbook；不可行动的告警要删，否则养出"告警疲劳"、真事故被淹。
+- **分级**：区分"立刻起床处理"和"工作时间看"，别什么都 P1。
+
+## 7. 反模式（出现即不合格）
+
+1. **裸文本日志**：非结构化字符串，无法检索、聚合、关联。
+2. **三信号各自为政**：日志、指标、追踪没有共同关联ID，出事拼不起来。
+3. **高基数炸指标**：把用户ID/请求ID/原始URL塞进指标标签，序列爆炸、成本失控。
+4. **只测技术指标不看业务**：CPU/内存全绿，但下单为零无人发现。
+5. **只有指标没有追踪**：知道"变慢了"但不知道慢在跨服务调用的哪一跳。
+6. **告警噪音**：成百上千条不可行动告警，真事故被淹，on-call 疲劳。
+7. **无 SLO**：没有"多好才算好"的定义，求快还是求稳全靠吵。
+8. **要查问题先加日志再发版**：遥测不足，未预想的故障无法靠现有数据定位。
+
+## 8. 最低交付 checklist
+
+- [ ] 全部日志结构化，带时间戳/级别/服务名/关联ID/消息。
+- [ ] 每个端点与依赖发出请求量/错误率/延迟分布；有关键业务指标。
+- [ ] 入口生成 trace_id 并贯穿日志与跨服务调用，追踪上下文全程传播。
+- [ ] 指标标签无高基数值，路径模板化；高流量追踪按需采样、错误强留。
+- [ ] 定义面向用户的 SLI 与现实的 SLO，落地错误预算并用于发布决策。
+- [ ] 告警基于用户症状与错误预算燃尽，条条可执行、指向 runbook、分级。
+- [ ] 健康检查区分存活与就绪。
+- [ ] 凭一个 request_id 能捞出一次请求的日志、链路与相关指标。

package/observability/01-standards/observability-standards.md

@@ -12,6 +12,8 @@ last_updated: 2026-06-14
 
 # 可观测性标准（日志 / 指标 / 追踪）
 
+> 本页是**具体配置片段速查**（日志字段示例、PromQL、告警表、健康检查 JSON）。可观测性的权威规范——埋点契约、三信号关联、基数纪律、SLI/SLO 与错误预算——见 `observability/01-standards/observability-and-slo-operations`，两者配合使用。
+
 ## 三柱可观测性
 
 ### 1. 结构化日志

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/aiops-anomaly-detection.md

@@ -8,7 +8,7 @@ tags: [aiops, anomaly, detection, operations, 告警降噪, 实施架构, 常见
 quality_score: 70
 last_updated: 2026-06-15
 ---
-# 开发：Excellent（11964948@qq.com）
+# aiops-anomaly-detection
 # 功能：AIOps 异常检测实践指南
 # 作用：利用机器学习和 AI 技术自动化检测和诊断系统异常
 # 创建时间：2026-03-20

package/operations/capacity-planning.md

@@ -8,7 +8,7 @@ tags: [capacity, operations, planning, 容量规划报告, 容量规划流程,
 quality_score: 70
 last_updated: 2026-06-15
 ---
-# 开发：Excellent（11964948@qq.com）
+# capacity-planning
 # 功能：容量规划实践指南
 # 作用：提供系统容量预测、规划和优化的完整方法论
 # 创建时间：2026-03-20

package/operations/chaos-engineering.md

@@ -8,7 +8,7 @@ tags: [chaos, engineering, operations, 分钟, 实施流程, 实验信息, 实
 quality_score: 70
 last_updated: 2026-06-15
 ---
-# 开发：Excellent（11964948@qq.com）
+# chaos-engineering
 # 功能：混沌工程实践指南
 # 作用：通过主动注入故障验证系统韧性,提前发现和修复潜在问题
 # 创建时间：2026-03-20

package/operations/incident-command-system.md

@@ -8,7 +8,7 @@ tags: [command, incident, operations, system]
 quality_score: 70
 last_updated: 2026-06-15
 ---
-# 开发：Excellent（11964948@qq.com）
+# incident-command-system
 
 ## 事故指挥体系（ICS）手册
 

package/operations/observability-complete.md

@@ -8,7 +8,7 @@ tags: [complete, dashboard, observability, operations, 告警设计, 实施清
 quality_score: 70
 last_updated: 2026-06-15
 ---
-# 开发：Excellent（11964948@qq.com）
+# observability-complete
 # 功能：可观测性完整体系
 # 作用：提供日志、指标、追踪三大支柱的完整实施指南
 # 创建时间：2026-03-20

package/operations/slo-sli-playbook.md

@@ -8,7 +8,7 @@ tags: [budget, operations, playbook, sli, slo, 实施流程, 核心概念, 目
 quality_score: 70
 last_updated: 2026-06-15
 ---
-# 开发：Excellent（11964948@qq.com）
+# slo-sli-playbook
 # 功能：SLO/SLI 实战手册
 # 作用：提供服务水平目标（SLO）和服务水平指标（SLI）的完整实施指南
 # 创建时间：2026-03-20

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

@@ -8,7 +8,7 @@ tags: [deep, dive, operations, sre, 运维环节深度知识库]
 quality_score: 70
 last_updated: 2026-06-15
 ---
-# 开发：Excellent（11964948@qq.com）
+# sre-operations-deep-dive
 
 ## 运维环节深度知识库
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@umacloud/knowledge",
-  "version": "1.0.14",
+  "version": "1.0.16",
   "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 / 发布门禁，回归即拦。
+- [ ] 在贴近生产的环境、真实负载模型与数据规模下做负载测试。
+- [ ] 按风险覆盖负载/压力/尖峰/浸泡，浸泡测试抓泄漏类问题。
+- [ ] 容量按峰值 + 余量规划，已定位主要瓶颈资源。
+- [ ] 建立性能基线，关键发布前重压对比、防回归。