@umacloud/knowledge 1.0.14 → 1.0.16

package/backend/01-standards/resilience-and-fault-tolerance.md

@@ -0,0 +1,101 @@
+---
+id: resilience-and-fault-tolerance
+title: 实现级韧性与容错规范（超时/重试预算/熔断/舱壁/背压，商业级必读）
+domain: backend
+category: 01-standards
+difficulty: advanced
+tags: [resilience, timeout, retry-budget, backoff, jitter, circuit-breaker, bulkhead, backpressure, load-shedding, fallback, deadline, 韧性, 容错, 超时, 重试, 熔断, 舱壁, 背压, 商业级]
+quality_score: 95
+last_updated: 2026-06-29
+---
+# 实现级韧性与容错规范（商业级必读）
+
+> 架构级讲"同城/异地容灾、RPO/RTO"（见 `architecture/resilience-and-disaster-patterns`）；本规范讲**代码里每一次外部调用怎么写才不会被拖垮**。
+> 分布式系统里依赖**一定会**变慢、超时、抖动、半死不活。商业级服务把超时、重试预算、熔断、舱壁、背压写进每一次出站调用，让一个依赖的故障**不会**级联拖垮整个服务。默认值（无超时、无脑重试、共享线程池）正是雪崩的配方。
+
+## 1. 核心原则
+
+- **每一次出站调用都有超时**：没有无限等待这回事。没设超时 = 把自己的命交给对方。
+- **失败要快、要可控**：宁可快速失败 + 降级，也不要慢慢挂死拖垮上游。
+- **重试是有预算的**：重试能救瞬时抖动，也能在故障时制造**重试风暴**压垮已经半死的依赖——必须限额。
+- **隔离故障域**：一个依赖的故障不能耗尽全服务的资源（线程/连接/内存）。
+- **降级有契约**：依赖不可用时返回什么、是否可缓存兜底，要事先设计，不是临时拍。
+
+## 2. 超时与截止时间（deadline）
+
+- **每个出站调用设超时**：连接超时 + 读超时分开设；按依赖的 p99 + 余量定，不要一律 30s。
+- **超时预算自上而下分配**：入站请求带总预算（如 800ms），调 A 花掉的时间从预算里扣，传给 B 的是**剩余预算**——避免"上游已超时放弃、下游还在傻等"。
+- **传播截止时间**：把 deadline 随调用链传递（header/context），下游据此决定还值不值得开工。
+- **超时要小于上游超时**：下游超时必须短于上游，否则上游先放弃，下游白做功还占资源。
+
+| 反例 | 正解 |
+|---|---|
+| 全局一个 30s 超时 | 按依赖分别设（DB 200ms、内网 RPC 300ms、外部 API 2s）|
+| 上游 1s 超时，下游 5s | 下游超时 < 上游，并扣除已耗时 |
+| 无截止时间传播 | deadline 随 context 下传，下游过期即放弃 |
+
+## 3. 重试与重试预算
+
+- **只重试可重试错误**：超时、连接失败、5xx/服务不可用、明确的"瞬时"错误可重试；4xx 参数错、鉴权失败、业务拒绝**不重试**（重试也白搭，还放大压力）。
+- **指数退避 + 抖动（jitter）**：退避间隔指数增长并加随机抖动，避免所有客户端**同步**在同一刻重试形成尖峰。
+- **重试预算（retry budget）**：限制"重试请求占总请求的比例"（如 ≤10%）。一旦依赖整体故障，重试占比飙升即**自动停止重试**——这是防重试风暴的关键，比单纯"最多重试 3 次"更有效。
+- **幂等前提**：只对幂等操作重试；非幂等写（扣款、下单）重试必须配幂等键（见 `backend/01-standards/idempotency-and-safe-retries`）。
+- **不在每一层都重试**：多层各自重试会**指数级放大**请求（3 层各重试 3 次 = 27 倍）。在**一处**重试，其余层只透传错误。
+
+## 4. 熔断器（circuit breaker）
+
+防止对一个已经故障的依赖持续打无效请求，给它恢复时间，并让调用方快速失败。
+
+| 状态 | 行为 | 转移条件 |
+|---|---|---|
+| 关闭（closed）| 正常放行，统计失败率 | 失败率/慢调用率超阈值 → 打开 |
+| 打开（open）| 直接快速失败，不打依赖，走降级 | 冷却时间到 → 半开 |
+| 半开（half-open）| 放少量探测请求 | 探测成功 → 关闭；失败 → 重新打开 |
+
+要点：按**失败率 + 慢调用率**触发（不只是异常数）；冷却期给依赖喘息；半开只放少量探测，别一下子全量灌回去。**熔断打开时必须有降级路径**，否则熔断只是把"慢失败"变成"快失败"，用户还是没结果。
+
+## 5. 舱壁隔离（bulkhead）
+
+把资源按依赖**分池**，一个依赖打满它自己的池，不波及其他。
+
+- **线程/并发隔离**：每个慢依赖用独立的线程池/信号量限并发；它卡住只耗尽自己那一格，主线程池不受影响。
+- **连接池隔离**：不同依赖、不同优先级用独立连接池；别让一个慢查询占满整个 DB 连接池饿死其他请求。
+- **限制在途请求数**：对每个依赖设最大在途（in-flight）上限，满了立即拒绝/降级，而不是无限排队耗内存。
+- **核心与非核心隔离**：关键链路（下单/支付）与非关键（推荐/埋点）用不同资源池，非核心拖垮不了核心。
+
+## 6. 背压与负载保护（backpressure / load shedding）
+
+- **背压**：下游处理不过来时，向上游传递"慢一点"信号（有界队列满即拒绝、流控窗口），而不是无限缓冲到 OOM。
+- **有界队列**：所有队列/缓冲必须有上限；满了走拒绝或降级，**绝不**无界堆积。
+- **主动卸载（load shedding）**：过载时**主动丢弃**低优先级请求，保住核心请求的 SLO——半数请求成功远好于全部一起慢死。
+- **限流前置**：入口按用户/IP/端点限流（见 `backend/01-standards/rate-limiting-complete`），把过载挡在门外。
+- **并发上限**：服务自身设最大并发，超过即排队有界 / 拒绝，保护自己不被打挂。
+
+## 7. 降级与兜底（fallback）
+
+- **降级要有契约**：依赖挂了返回什么——缓存的旧值、默认值、空集合、还是明确的"暂不可用"——事先设计好。
+- **缓存兜底**：读路径可在依赖不可用时返回最近一次缓存（标记为 stale），保证可用性。
+- **优雅降级**：非核心功能（推荐、个性化）失败时静默降级为通用内容，不让整页崩。
+- **降级也要可观测**：降级触发要打点告警，别让"一直在降级"被无声忽略。
+
+## 8. 反模式（出现即不合格）
+
+1. **无超时调用**：任何 HTTP/RPC/DB 调用没设超时，一个慢依赖挂死全服务。
+2. **无脑重试**：对所有错误重试、固定间隔无抖动、无预算 → 故障时制造重试风暴。
+3. **多层叠加重试**：每一层都重试，请求被指数放大压垮下游。
+4. **熔断无降级**：熔断打开但没兜底，用户照样拿不到结果。
+5. **共享资源池**：所有依赖共用一个线程池/连接池，一个慢依赖拖垮全部。
+6. **无界队列/缓冲**：积压无上限，过载直接 OOM。
+7. **超时倒挂**：下游超时比上游还长，上游先放弃、下游白干。
+8. **对非幂等写重试**：重复扣款/重复下单。
+
+## 9. 最低交付 checklist
+
+- [ ] 每个出站调用（HTTP/RPC/DB/缓存）都有连接 + 读超时，按依赖分别设定。
+- [ ] 超时预算自上而下分配，截止时间随调用链传播，下游超时 < 上游。
+- [ ] 只重试可重试错误，指数退避 + 抖动，且有重试预算上限。
+- [ ] 重试只在一层做，非幂等写重试配幂等键。
+- [ ] 关键依赖有熔断器（失败率/慢调用触发）且熔断时有降级路径。
+- [ ] 慢依赖用舱壁隔离（独立线程池/信号量/连接池 + 在途上限）。
+- [ ] 所有队列有界，过载时主动卸载低优先级请求保核心 SLO。
+- [ ] 降级有明确契约，降级触发可观测、有告警。

package/backend/01-standards/transactions-and-concurrency-control.md

@@ -0,0 +1,92 @@
+---
+id: transactions-and-concurrency-control
+title: 事务与并发控制规范（商业级后端必读）
+domain: backend
+category: 01-standards
+difficulty: intermediate
+tags: [transaction, isolation, locking, concurrency, acid, deadlock, consistency, 事务, 隔离级别, 锁, 商业级]
+quality_score: 95
+last_updated: 2026-06-29
+---
+# 事务与并发控制规范（商业级后端必读）
+
+> 多个请求同时改同一份数据时，"看起来能跑"的代码会丢更新、读脏数、超卖。
+> 商业级后端必须显式定义**事务边界**、选对**隔离级别**、用对**锁策略**。
+> 本规范聚焦单库内的本地事务与并发；跨服务/跨库一致性见 `architecture/distributed-transactions`。
+
+## 1. 事务边界 = 用例边界
+
+- **一个用例（业务操作）= 一个事务**。在**应用层/服务层**开启与提交事务，而不是在 repository 里各开各的（否则一个用例里多次提交，失败时一半已落库）。
+- 事务要**短小**：只把"必须原子"的读写包进去。**绝不**在事务里发 HTTP 调用、发消息、等外部 IO——会长时间持锁、放大死锁与连接耗尽。需要对外副作用时，用发件箱（outbox）在事务内只写消息，事务外再投递。
+- 事务里**先做校验/计算，再做写**，把写集中在末尾，缩短持锁时间。
+- 失败必须**整体回滚**；不要 catch 异常后继续提交"半截"数据。
+
+## 2. ACID 与一致性底线
+
+- **原子性**：要么全成功要么全回滚，没有"半完成"。
+- **一致性**：事务结束后所有约束（唯一/外键/check/余额非负）都成立——把不变量尽量交给 **DB 约束**，不要只在应用层校验。
+- **隔离性**：并发事务互不干扰的程度，由隔离级别决定（见 §3）。
+- **持久性**：提交即落盘，宕机不丢。
+- 金额用**定点/整数（分）**，绝不用浮点；时间带时区；并发计数器避免"读-改-写"丢更新。
+
+## 3. 隔离级别与并发异常
+
+选错隔离级别会出现这些异常，按场景选最低够用的级别：
+
+| 隔离级别 | 脏读 | 不可重复读 | 幻读 | 写偏斜(write skew) | 典型用途 |
+|---|---|---|---|---|---|
+| Read Uncommitted | 可能 | 可能 | 可能 | 可能 | 几乎不用 |
+| Read Committed | 否 | 可能 | 可能 | 可能 | OLTP 常见默认 |
+| Repeatable Read | 否 | 否 | 可能/否* | 可能 | 需要稳定快照的读 |
+| Serializable | 否 | 否 | 否 | 否 | 强一致关键写（账务/库存判定） |
+
+\* 不同数据库在 Repeatable Read 下对幻读的处理不同；需要严格不变量时用 Serializable 或显式加锁。
+
+- 异常含义：**脏读**=读到未提交数据；**不可重复读**=同一行两次读值不同；**幻读**=同一查询条件两次返回行数不同；**写偏斜**=两个事务各自读一致快照后分别写，合起来违反不变量（如"至少留一个值班医生"被两人同时请假打破）。
+- 经验：默认 **Read Committed**；对"读后据此决定写"的关键判定（余额、库存、配额），升到 **Serializable** 或用显式锁，否则会有写偏斜/超卖。
+
+## 4. 乐观锁 vs 悲观锁
+
+| 维度 | 乐观锁 | 悲观锁 |
+|---|---|---|
+| 机制 | 版本号/时间戳，提交时 CAS 校验 | `SELECT ... FOR UPDATE` 先锁后改 |
+| 适用 | 冲突少、读多写少 | 冲突多、临界区短、必须串行 |
+| 失败处理 | 影响行数=0 → 重读重试（带上限） | 等待锁/超时 |
+| 风险 | 高冲突下大量重试 | 持锁久 → 死锁、吞吐下降 |
+
+- **乐观锁**：`UPDATE t SET val=?, version=version+1 WHERE id=? AND version=?`；影响行数为 0 表示已被他人修改，重读后按业务决定重试或放弃。**先查后写**前必须有这层校验，否则丢更新。
+- **悲观锁**：`SELECT ... FOR UPDATE` 锁定将要修改的行，确保串行。务必：① 加锁范围最小；② 设锁等待超时；③ **所有事务以相同顺序加锁**以避免死锁。
+- **原子写优先**：能用一条原子语句就别先查后写——如 `UPDATE stock SET qty=qty-1 WHERE id=? AND qty>=1`（影响行数=0 即库存不足），既无竞态又免去显式锁。
+
+## 5. 死锁与锁竞争
+
+- **死锁成因**：两个事务以**相反顺序**持有/请求锁。根治：固定全局加锁顺序（如总是按主键升序锁多行）。
+- 数据库会检测死锁并回滚其中一个事务——业务侧要**捕获死锁错误并重试**（幂等前提下，带退避）。
+- 减少锁竞争：缩短事务、降低隔离级别到够用、给热点行设计分桶/分片、把"读多"路径走快照读不加锁。
+- **连接池**：事务持有连接，长事务会拖垮连接池；设置语句/事务超时，杜绝"忘了提交"的悬挂事务。
+
+## 6. 读一致性
+
+- **读己之写（read-your-writes）**：用户写完立刻读应看到自己的写；主从架构下要把"刚写完的读"路由到主库或加版本校验，避免读到滞后的从库。
+- 报表/聚合类长读用**快照读**或专门的只读副本，别和 OLTP 写抢锁。
+- 需要"一批读相互一致"时，把它们放进同一个（Repeatable Read/Serializable）事务的同一快照里。
+
+## 7. 反模式（出现即不合格）
+
+1. **事务里做外部 IO**：在事务内发 HTTP/MQ，长持锁、易死锁。
+2. **repository 各自提交**：一个用例多个事务，失败留下半截数据。
+3. **先查后写无并发保护**：丢更新、超卖（缺乏唯一约束/乐观锁/原子写）。
+4. **隔离级别不假思索**：关键判定用 Read Committed 出现写偏斜。
+5. **金额用浮点 / 计数器读改写**：精度丢失、并发丢更新。
+6. **长事务 + 大锁范围**：吞吐塌方、死锁频发、连接耗尽。
+7. **不处理死锁/锁超时**：偶发死锁直接变成用户报错。
+
+## 8. 最低交付 checklist
+
+- [ ] 事务边界在服务层、对齐用例；事务短小、无内部外部 IO。
+- [ ] 隔离级别按场景显式选择；关键"读后写"判定有写偏斜防护。
+- [ ] 并发写有保护：原子写 / 乐观锁（版本号）/ 悲观锁，三选一且最小化。
+- [ ] 多行加锁顺序固定；捕获死锁与锁超时并安全重试。
+- [ ] 不变量尽量落 DB 约束（唯一/外键/check），不只应用层校验。
+- [ ] 金额用整数/定点；计数器用原子更新而非读-改-写。
+- [ ] 有并发场景的自动化测试（并发下单/扣减/转账不出错）。

package/cicd/cicd-blueprint-deep-dive.md

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

package/cicd/release-readiness-gate.md

@@ -1,37 +1,88 @@
 ---
 id: release-readiness-gate
-title: release-readiness-gate
+title: 发布就绪门禁规范（每次发布的 pass/fail 闸门：阻断高风险变更，商业级必读）
 domain: cicd
-category: release-readiness-gate.md
-difficulty: intermediate
-tags: [cicd, gate, readiness, release, 发布就绪门禁清单]
-quality_score: 70
-last_updated: 2026-06-15
+category: cicd
+difficulty: advanced
+tags: [release-gate, readiness-gate, ci-cd, quality-gate, go-no-go, blocking-criteria, change-management, rollback, canary, post-deploy-verification, build-provenance, 发布门禁, 就绪门, 阻断, 灰度, 回滚, 商业级]
+quality_score: 95
+last_updated: 2026-06-29
 ---
-# 开发：Excellent（11964948@qq.com）
+# 发布就绪门禁规范（商业级必读）
 
-## 发布就绪门禁清单
+> "构建绿了"不等于"能发"。CI 通过只证明代码编得过、测试跑得过；它不证明这次变更**可控、可观测、可回滚**。把"绿色流水线"直接当成放行信号，是大量线上事故的起点。
+> 发布就绪门禁是发布管线里一道**确定性的 pass/fail 闸门**——**每一次**进入生产的变更都必须穿过它，任一必过项不满足就**自动阻断**，不靠人情、不靠"这次先放一下"。它和一次性的服务级生产就绪审查不同（服务能否被运维见 `operations/01-standards/production-readiness-review`，逐条自检见 `development/03-checklists/release-readiness-checklist`）：本规范定义的是**每次发布都重复执行**的机器可判定闸门。
 
-### 目标
-- 用统一发布门禁阻断高风险变更，保证发布可控。
+## 1. 门禁的三条铁律
 
-### 必过门禁
-- 代码质量：lint、类型检查、静态分析通过。
-- 测试质量：核心回归通过、阻断缺陷清零。
-- 安全质量：高危漏洞清零，密钥泄露检查通过。
-- 构建质量：制品可追溯、版本标签一致。
-- 运维质量：发布与回滚脚本可执行。
+| 铁律 | 含义 | 违反的后果 |
+|---|---|---|
+| 确定性可判定 | 每个必过项是机器可判定的 pass/fail，不是"看着差不多" | 门禁形同虚设，靠主观放行 |
+| 强制不可绕过 | 门禁是合并/发布的硬阻断，绕过需留痕审批且属例外 | "临时跳过一下"成为常态，门禁名存实亡 |
+| 既看构建也看运行 | 不止"构建成功"，还要发布后验证"运行健康" | 部署成功但服务已坏，靠用户投诉才发现 |
 
-### 发布前检查
-- 是否完成变更影响评估与回滚预案。
-- 是否完成灰度策略与阈值配置。
-- 是否完成关键指标基线确认。
+核心判据：**门禁的价值在于敢说 fail。** 一个从不阻断任何发布的门禁等于没有门禁。
 
-### 发布后检查
-- 错误率、时延、成功率是否在阈值内。
-- 告警是否异常增加。
-- 关键业务链路是否连续成功。
+## 2. 必过门禁（任一不过即阻断）
 
-### 常见失败模式
-- 只检查构建成功，不检查运行质量。
-- 门禁定义存在但未强制执行。
+每一类给出**机器可判定**的通过条件，全部满足才进入发布阶段。
+
+| 门禁类别 | 通过条件（pass） | 失败即阻断（fail） |
+|---|---|---|
+| 代码质量 | 格式化/lint/类型检查/静态分析全过，无新增告警 | 存在 error 级问题或新增告警 |
+| 测试质量 | 关键路径回归全绿，覆盖率不低于基线，无阻断缺陷开放 | 测试红、覆盖率回退、存在未关阻断缺陷 |
+| 安全质量 | 依赖/镜像无未处理的 Critical/High 漏洞，密钥扫描无泄露 | 高危漏洞未分诊、检出明文密钥 |
+| 构建可信 | 制品可追溯（版本↔commit SHA 一一对应）、已签名验签、来源可证 | 制品来源不明、版本与代码对不上、未签名 |
+| 配置就绪 | 目标环境配置键齐全、启动校验通过、与制品版本绑定记录 | 缺配置、配置漂移、来源含糊（见 `architecture/01-standards/configuration-and-environment-management`） |
+| 可回滚 | 回滚方案存在且**已验证可执行**（应用/配置/数据） | 无回滚路径或从未验证 |
+| 可观测 | 本次变更涉及路径有监控指标与告警，发布后看得见 | 关键路径无遥测，出事不可见 |
+
+## 3. 发布前检查（pre-deploy）
+
+进入放量前必须确认，缺一不可：
+
+- **变更影响评估**：本次改了什么、影响哪些上下游、风险等级是多少，已记录。
+- **回滚预案就位**：回滚步骤明确且演练过；高风险变更预先准备好"一键回退"。
+- **灰度策略与阈值**：放量批次、观察窗口、自动回退触发阈值（错误率/延迟/成功率）已配置，不全量瞬时生效。
+- **指标基线确认**：发布前抓取关键指标基线（错误率、P95/P99 延迟、关键交易成功率），作为发布后对比的锚点。
+- **数据库变更安全**：Schema 变更前向兼容、可回滚，先迁移后发布、扩展式变更（见 `development/01-standards/database-migration-strategies`）。
+- **发布窗口与值班**：避开高风险时段，值班与升级路径在线、可响应。
+
+## 4. 发布后验证（post-deploy gate）
+
+部署完成**不是**发布成功——必须用运行信号确认。这是门禁的"后半扇"：
+
+- **黄金指标在阈值内**：错误率、延迟、饱和度、关键交易成功率在发布前基线的容忍带内。
+- **告警无异常抬升**：发布后未触发新的 P0/P1，告警量无异常飙升。
+- **关键链路连续成功**：核心业务链路（登录/下单/支付等）端到端连续成功，而非仅健康检查返回 200。
+- **观察窗口达标后才扩量**：每批灰度都要过观察窗口再放下一批；指标越界**自动回退**，不等人决策。
+- **失败即回滚并复盘**：触发回退条件就执行已验证的回滚，事后归档"为什么发坏了"。
+
+## 5. 例外与放行口径
+
+- **门禁是默认拒绝**：必过项有一项 fail，默认结果就是 no-go。
+- **例外必须留痕**：极少数业务紧急情况下的带条件放行，需要明确审批人、原因、补救项与期限，并归档可审计——而不是悄悄跳过。
+- **绝不降低红线**：可回滚、可观测、无高危漏洞、无明文密钥属硬红线，任何"紧急"都不豁免。
+- **门禁结果可追溯**：每次发布留下门禁判定记录（哪些过、哪些放行、谁批的），出事能反查。
+
+## 6. 反模式（出现即不合格）
+
+1. **绿即放行**：把 CI 通过直接当成可发布信号，不查可回滚/可观测/运行健康。
+2. **只看构建不看运行**：部署成功就宣布完成，没有发布后验证步骤。
+3. **门禁可随意绕过**："这次先跳过一下"成为习惯，硬阻断变软建议。
+4. **主观判定**：通过条件不是机器可判定的 pass/fail，靠人眼"差不多"。
+5. **无回滚就发**：没有已验证的回退路径，出事只能向前硬修。
+6. **全量瞬时生效**：不灰度、不设自动回退阈值，一发就是全量。
+7. **无基线对比**：发布后没有基线可比，指标好坏全靠感觉。
+8. **门禁无留痕**：放行与例外没有审计记录，事后无法追责复盘。
+9. **为赶进度降红线**："紧急发布"时豁免高危漏洞/明文密钥/无监控。
+
+## 7. 最低交付 checklist
+
+- [ ] 门禁是发布管线里**强制、确定性、不可随意绕过**的 pass/fail 闸门。
+- [ ] 必过门禁齐备：代码/测试/安全/构建可信/配置/可回滚/可观测，任一 fail 即阻断。
+- [ ] 发布前完成影响评估、回滚预案、灰度阈值、指标基线、DB 变更安全、值班就位。
+- [ ] 发布后用黄金指标+告警+关键链路验证，过观察窗口再扩量，越界自动回退。
+- [ ] 可回滚、可观测、无高危漏洞、无明文密钥为硬红线，紧急也不豁免。
+- [ ] 例外放行有审批人/原因/补救/期限并归档；每次门禁判定可追溯。
+- [ ] 服务级一次性就绪见 `operations/01-standards/production-readiness-review`；逐条自检见 `development/03-checklists/release-readiness-checklist`。

package/cloud-native/01-standards/container-security.md

@@ -10,7 +10,7 @@ difficulty: intermediate
 quality_score: 70
 ---
 
-# 开发：Excellent（11964948@qq.com）
+# 容器安全标准
 # 功能：容器安全完整标准
 # 作用：为容器镜像、运行时、编排提供安全规范
 # 创建时间：2025-03-20

package/cloud-native/01-standards/kubernetes-complete.md

@@ -10,7 +10,7 @@ difficulty: intermediate
 quality_score: 70
 ---
 
-# 开发：Excellent（11964948@qq.com）
+# Kubernetes 完整标准
 # 功能：Kubernetes 完整开发与运维标准
 # 作用：为 K8s 集群管理、应用部署、安全治理提供统一规范
 # 创建时间：2025-03-20

package/cloud-native/02-playbooks/gitops-with-argocd.md

@@ -10,7 +10,7 @@ difficulty: intermediate
 quality_score: 70
 ---
 
-# 开发：Excellent（11964948@qq.com）
+# GitOps ArgoCD 作战手册
 # 功能：GitOps 与 ArgoCD 实施作战手册
 # 作用：指导使用 ArgoCD 实现声明式持续部署
 # 创建时间：2025-03-20

package/cloud-native/02-playbooks/k8s-troubleshooting-playbook.md

@@ -10,7 +10,7 @@ difficulty: intermediate
 quality_score: 70
 ---
 
-# 开发：Excellent（11964948@qq.com）
+# Kubernetes 故障排查作战手册
 # 功能：Kubernetes 全场景故障排查作战手册
 # 作用：指导 K8s 集群各类故障的诊断、根因分析与修复
 # 创建时间：2026-03-28

package/cloud-native/02-playbooks/multicloud-governance.md

@@ -10,7 +10,7 @@ difficulty: intermediate
 quality_score: 70
 ---
 
-# 开发：Excellent（11964948@qq.com）
+# 多云治理作战手册
 # 功能：多云环境治理作战手册
 # 作用：指导多云架构的统一管理、成本优化和风险控制
 # 创建时间：2025-03-20

package/cloud-native/02-playbooks/serverless-patterns.md

@@ -10,7 +10,7 @@ difficulty: intermediate
 quality_score: 70
 ---
 
-# 开发：Excellent（11964948@qq.com）
+# Serverless 模式作战手册
 # 功能：Serverless 架构模式作战手册
 # 作用：指导 Knative、云函数等 Serverless 实践
 # 创建时间：2025-03-20

package/cloud-native/02-playbooks/service-mesh-playbook.md

@@ -10,7 +10,7 @@ difficulty: intermediate
 quality_score: 70
 ---
 
-# 开发：Excellent（11964948@qq.com）
+# 服务网格作战手册
 # 功能：服务网格实施与运维作战手册
 # 作用：指导 Istio/Linkerd 服务网格的部署、配置和运维
 # 创建时间：2025-03-20

package/cloud-native/03-checklists/container-security-checklist.md

@@ -10,7 +10,7 @@ difficulty: intermediate
 quality_score: 70
 ---
 
-# 开发：Excellent（11964948@qq.com）
+# 容器安全检查清单
 # 功能：容器安全全面检查清单
 # 作用：确保容器镜像和运行时满足安全标准
 # 创建时间：2025-03-20

package/cloud-native/03-checklists/k8s-production-readiness-checklist.md

@@ -10,7 +10,7 @@ difficulty: intermediate
 quality_score: 70
 ---
 
-# 开发：Excellent（11964948@qq.com）
+# Kubernetes 生产就绪检查清单
 # 功能：Kubernetes 生产环境部署前检查清单
 # 作用：确保应用具备生产环境运行条件
 # 创建时间：2025-03-20

package/cloud-native/04-antipatterns/container-antipatterns.md

@@ -10,7 +10,7 @@ difficulty: intermediate
 quality_score: 70
 ---
 
-# 开发：Excellent（11964948@qq.com）
+# 容器反模式库
 # 功能：容器常见反模式识别与修正
 # 作用：帮助团队避免容器化常见错误
 # 创建时间：2025-03-20

package/cloud-native/04-antipatterns/k8s-antipatterns.md

@@ -10,7 +10,7 @@ difficulty: intermediate
 quality_score: 70
 ---
 
-# 开发：Excellent（11964948@qq.com）
+# Kubernetes 反模式库
 # 功能：Kubernetes 常见反模式识别与修正
 # 作用：帮助团队避免常见错误，建立正确实践
 # 创建时间：2025-03-20

package/cloud-native/05-cases/case-k8s-migration.md

@@ -10,7 +10,7 @@ difficulty: intermediate
 quality_score: 70
 ---
 
-# 开发：Excellent（11964948@qq.com）
+# 案例：Kubernetes 迁移
 # 功能：Kubernetes 迁移实战案例
 # 作用：分享传统应用到 Kubernetes 的迁移经验
 # 创建时间：2025-03-20

package/cloud-native/05-cases/case-k8s-scaling.md

@@ -10,7 +10,7 @@ difficulty: intermediate
 quality_score: 70
 ---
 
-# 开发：Excellent（11964948@qq.com）
+# 案例：Kubernetes 扩展
 # 功能：Kubernetes 自动扩展实战案例
 # 作用：分享 K8s 弹性伸缩的实践经验
 # 创建时间：2025-03-20

package/cloud-native/05-cases/case-k8s-security-incident.md

@@ -10,7 +10,7 @@ difficulty: intermediate
 quality_score: 70
 ---
 
-# 开发：Excellent（11964948@qq.com）
+# 案例：Kubernetes 安全事件
 # 功能：Kubernetes 安全事件响应实战案例
 # 作用：分享 K8s 安全事件的处理经验
 # 创建时间：2025-03-20

package/cloud-native/06-glossary/cloud-native-glossary.md

@@ -10,7 +10,7 @@ difficulty: intermediate
 quality_score: 70
 ---
 
-# 开发：Excellent（11964948@qq.com）
+# 云原生词汇表
 # 功能：云原生核心术语定义
 # 作用：统一术语理解，便于沟通和学习
 # 创建时间：2025-03-20

package/compliance/01-standards/audit-logging-and-evidence.md

@@ -0,0 +1,111 @@
+---
+id: audit-logging-and-evidence
+title: 审计日志与合规证据规范（商业级必读）
+domain: compliance
+category: 01-standards
+difficulty: intermediate
+tags: [audit-log, audit-trail, evidence, tamper-evident, accountability, who-did-what, retention, compliance, 审计日志, 审计追踪, 合规证据, 防篡改, 商业级]
+quality_score: 95
+last_updated: 2026-06-29
+---
+# 审计日志与合规证据规范（商业级必读）
+
+> 普通日志回答"系统发生了什么"，审计日志回答"**谁**在**何时**对**什么**做了**什么**、结果如何"。
+> 当出现纠纷、越权、数据泄露、监管问询时，审计日志是你唯一能自证清白或定位责任的证据。
+> 它和应用日志是两套东西：审计日志要**防篡改、可追溯、长期保留、独立于业务日志**。事后补不出来——必须从一开始就记。
+
+## 1. 审计日志 ≠ 应用日志
+
+| 维度 | 应用日志 | 审计日志 |
+|---|---|---|
+| 目的 | 排障、可观测 | 问责、合规、取证 |
+| 内容 | 系统行为、调用链 | 主体对客体的安全相关操作 |
+| 可改 | 可轮转、可删 | 防篡改、不可改、定期保留 |
+| 读者 | 工程师 | 审计员、安全、监管、法务 |
+| 保留 | 几天~几周 | 数月~数年（按合规要求）|
+
+两者**分开存储**：审计事件可以同时进可观测体系，但合规证据要有独立、受控、防篡改的留存。
+
+## 2. 必须记录的事件
+
+凡是"安全相关、合规相关、影响他人数据/权限"的操作都要记：
+
+- **认证**：登录成功/失败、登出、MFA 校验、会话创建/失效、密码/密钥变更。
+- **授权**：权限/角色变更、提权、访问被拒、敏感资源访问。
+- **数据**：对个人/敏感数据的访问、导出、修改、删除（尤其批量与跨用户操作）。
+- **配置/管理**：安全配置变更、功能开关变更（尤其 kill-switch）、用户/账号增删、密钥轮换。
+- **特权操作**：管理员/运维的高权限动作、以他人身份操作（impersonation）、数据库直连改数。
+- **合规动作**：数据主体请求（导出/删除/更正）的受理与完成。
+
+## 3. 每条审计记录的必备字段（5W）
+
+| 字段 | 含义 |
+|---|---|
+| who（主体）| 操作者身份：用户/服务账号ID、角色；以他人身份操作时记**真实操作者 + 被代理者** |
+| when（时间）| 高精度、可信时间源、统一时区（UTC），不可被客户端伪造 |
+| what（动作 + 客体）| 做了什么操作、对哪个资源（资源类型 + ID），变更前后值（敏感值脱敏/只记引用）|
+| where（来源）| 来源 IP、设备、会话ID、请求ID（贯穿应用日志便于关联）|
+| result（结果）| 成功/失败/被拒；失败也要记（被拒的越权尝试本身就是关键信号）|
+
+补充：记录**关联ID**（request_id / trace_id）把审计事件和应用链路打通；失败的敏感操作**和成功的一样重要**。
+
+## 4. 防篡改与完整性
+
+审计日志的价值全在"没被改过"。要做到：
+
+- **只追加（append-only）**：审计日志只写不改不删；应用账号对审计存储**没有**修改/删除权限。
+- **权限隔离**：写审计的身份 ≠ 能读全部审计的身份 ≠ 能管理留存的身份；管理员也不能悄悄删自己的痕迹。
+- **完整性校验**：用哈希链/链式校验/独立签名等手段，使任何删改可被检出（tamper-evident）。
+- **外移**：审计日志尽快写到独立、受控的存储（与被审计系统不同的信任域），防止入侵者就地销毁证据。
+- **时间可信**：用可信时间源，防止时间戳被回拨伪造。
+
+## 5. 审计日志本身要合规
+
+- **脱敏**：审计记录里**不存**密码、token、卡号明文；记录"改了哪个字段"而非把敏感值原样落进审计。
+- **最小必要**：记录足够定位责任，但不把敏感数据复制进审计造成二次暴露面。
+- **访问受控**：谁能查审计日志本身要受控、要留痕（查审计的动作也是审计事件）。
+- **保留期**：按合规要求定保留期限（常以年计），到期前不可删，到期后按策略处理。
+
+## 6. 合规证据（不只是日志）
+
+认证审计（SOC2 / ISO 27001 / 行业监管等）要的是"能证明你确实做了控制"的**证据**，审计日志是其中一类。还要留：
+
+| 证据类型 | 内容 |
+|---|---|
+| 操作审计 | who-did-what 审计日志（本规范主体）|
+| 同意记录 | 用户同意：谁、何时、对哪版条款、通过什么方式（见 `privacy-and-compliance-readiness`）|
+| 数据主体请求 | 导出/删除/更正请求的受理与**完成**记录 |
+| 访问评审 | 定期"谁有权访问敏感资源、是否仍需要"的评审记录 |
+| 变更/发布 | 谁、何时、发了什么版本、对应 commit（见 `release-engineering/`）|
+| 控制落实 | 安全扫描、权限配置、加密配置等控制项的执行证据 |
+
+证据要**可检索、可导出、带时间线**——审计员问"给我看 X 时间 Y 操作的记录"，你要能立刻调出。
+
+## 7. 与其他规范的关系
+
+- 隐私/数据主体权利的工程化见 `compliance/01-standards/privacy-and-compliance-readiness`。
+- 谁能做什么（授权模型）见 `security/01-standards/authorization-and-access-control`。
+- 应用侧可观测/结构化日志见 `observability/`（审计是其特殊子集，但留存与防篡改要求更高）。
+- 数据泄露响应见 `incident/` 与 `security/02-playbooks/incident-response-security-playbook`。
+
+## 8. 反模式（出现即不合格）
+
+1. **不记或漏记**：敏感操作（删数据、提权、导出）没有审计，事后查无可查。
+2. **审计可被改/可被删**：应用账号能改写审计日志，入侵者一进来就抹痕迹。
+3. **只记成功不记失败**：被拒的越权尝试（最该警觉的信号）没留下。
+4. **审计混进应用日志**：跟着业务日志几天就轮转没了，达不到保留要求。
+5. **审计里存明文敏感值**：把密码/卡号/token 原样落进审计，制造新暴露面。
+6. **没有"谁操作的"**：只记"某记录被删"，记不出是谁删的。
+7. **代理操作不记真实人**：以他人身份操作只记被代理者，查不到真正动手的人。
+8. **合规当临上线补文档**：平时不留证据，审计前临时编造，经不起追溯。
+
+## 9. 最低交付 checklist
+
+- [ ] 审计日志与应用日志分离，独立、受控、长期保留。
+- [ ] 认证/授权/数据/配置/特权/合规等安全相关操作全部记审计。
+- [ ] 每条记录含 who/when/what/where/result，失败操作同样记录。
+- [ ] 代理操作记录真实操作者 + 被代理者；带关联ID可与应用链路打通。
+- [ ] 审计只追加、应用账号无删改权、有完整性校验、尽快外移到独立信任域。
+- [ ] 审计记录脱敏，不存明文敏感值；查审计本身也受控并留痕。
+- [ ] 审计保留期按合规要求设定，到期前不可删。
+- [ ] 同意记录、数据主体请求、访问评审、变更发布等合规证据可检索可导出。