@umacloud/knowledge 1.0.1

package/incident/06-glossary/incident-glossary.md

@@ -0,0 +1,114 @@
+---
+id: incident-glossary
+title: 事故管理术语表 (Incident Management Glossary)
+domain: incident
+category: 06-glossary
+difficulty: intermediate
+tags: [agent, checklist, glossary, incident, 事故响应, 变更管理, 可观测性, 可靠性指标]
+quality_score: 70
+last_updated: 2026-06-15
+---
+# 事故管理术语表 (Incident Management Glossary)
+
+> 适用场景：SRE 团队建设、On-Call 培训、事故管理流程制定、可靠性工程实践。
+> 涵盖范围：可靠性指标、事故响应、混沌工程、可观测性、服务等级管理等核心术语。
+
+---
+
+## 可靠性指标
+
+| 术语 | 英文 | 定义 |
+|------|------|------|
+| 平均恢复时间 | Mean Time to Restore (MTTR) | 从事故发生到服务完全恢复的平均时间。是衡量事故响应效率的核心指标。MTTR = 检测时间 + 响应时间 + 修复时间 + 验证时间。 |
+| 平均无故障时间 | Mean Time Between Failures (MTBF) | 两次故障之间的平均间隔时间。MTBF 越长说明系统越稳定。MTBF = 总运行时间 / 故障次数。 |
+| 平均故障前时间 | Mean Time to Failure (MTTF) | 系统从启动到首次故障的平均时间。通常用于不可修复组件（如硬盘）的可靠性评估。 |
+| 平均检测时间 | Mean Time to Detect (MTTD) | 从故障实际发生到被监控系统或人员发现的平均时间。衡量监控覆盖度和告警灵敏度。 |
+| 可用性 | Availability | 系统在指定时间段内正常运行的比例。通常以"几个 9"表示：99.9%（年停机 8.77 小时）、99.99%（年停机 52.6 分钟）。 |
+
+---
+
+## 服务等级管理
+
+| 术语 | 英文 | 定义 |
+|------|------|------|
+| 服务等级协议 | Service Level Agreement (SLA) | 服务提供方与客户之间关于服务质量的正式协议，包含可用性、延迟、吞吐量等指标的承诺值和违约条款。 |
+| 服务等级目标 | Service Level Objective (SLO) | 组织内部设定的服务质量目标，通常比对外 SLA 更严格。例如：SLA 承诺 99.9% 可用性，SLO 内部目标 99.95%。 |
+| 服务等级指标 | Service Level Indicator (SLI) | 用于度量服务等级的具体指标。例如：请求成功率、P99 延迟、错误率。SLI 是 SLO 的度量基础。 |
+| 错误预算 | Error Budget | SLO 允许的失败空间。如 SLO 为 99.9%，则月度错误预算为 0.1%（约 43 分钟停机时间）。预算耗尽时应冻结变更、优先修复可靠性。 |
+| 燃尽率 | Burn Rate | 错误预算的消耗速度。燃尽率 > 1 表示按当前速度将在周期结束前耗尽预算。用于触发告警和决策。 |
+
+---
+
+## 事故响应
+
+| 术语 | 英文 | 定义 |
+|------|------|------|
+| 事故指挥官 | Incident Commander (IC) | 事故响应的总协调人，负责决策、资源调配和沟通。不直接排查技术问题，专注于协调和全局把控。 |
+| 值班工程师 | On-Call Engineer | 在指定时间段内负责接收和响应告警的工程师。通常采用轮值制度，分为一线和二线。 |
+| 升级 | Escalation | 将事故提升到更高级别处理的行为。可以是自动升级（超时未解决）或手动升级（需要更多资源或权限）。 |
+| 事故等级 | Severity Level | 事故的严重程度分级。通常 P0（最严重）到 P4（最轻微），每个等级有明确的定义和响应流程。 |
+| 回滚 | Rollback | 将系统恢复到上一个已知稳定版本的操作。是最常用的快速恢复手段，回滚时间应控制在 5 分钟以内。 |
+| 降级 | Graceful Degradation | 在部分功能不可用时，有意关闭非核心功能以保证核心功能正常运行。例如：关闭推荐系统以保证搜索可用。 |
+| 熔断 | Circuit Breaking | 当下游服务异常时，主动断开调用链，防止级联故障。达到阈值自动触发，恢复后逐步放量探测。 |
+| 战情室 | War Room | 事故响应期间，相关人员集中在同一物理/虚拟空间进行协调和排查的模式。适用于 P0/P1 重大事故。 |
+
+---
+
+## 复盘与改进
+
+| 术语 | 英文 | 定义 |
+|------|------|------|
+| 无责复盘 | Blameless Postmortem | 聚焦系统改进而非追究个人责任的事故复盘方式。核心原则：人不是根因，系统允许错误发生才是根因。 |
+| 近失事件 | Near Miss | 差点引发事故但最终未造成实际影响的事件。主动上报和分析近失事件是预防事故的重要手段。 |
+| 行动项 | Action Item | 复盘后制定的具体改进措施。必须符合 SMART 原则（具体、可度量、可分配、可实现、有时限）。 |
+| 根因分析 | Root Cause Analysis (RCA) | 系统化地追溯事故发生的根本原因的方法。常用工具：5 Whys、鱼骨图（石川图）、故障树分析。 |
+| 运维苦差 | Toil | 手动的、重复的、可自动化的、随服务规模线性增长的运维工作。SRE 的核心目标之一是减少 Toil。 |
+
+---
+
+## 混沌工程
+
+| 术语 | 英文 | 定义 |
+|------|------|------|
+| 混沌工程 | Chaos Engineering | 通过主动向生产或类生产环境注入故障来验证系统韧性的实践。原则：先建假设、最小爆炸半径、自动回滚。 |
+| 爆炸半径 | Blast Radius | 一个故障或变更可能影响的范围。设计系统时应最小化爆炸半径（隔离、限流、分区）。在混沌实验中需严格控制。 |
+| 演练日 | Game Day | 定期组织的事故模拟演练活动，验证团队的事故响应能力、Runbook 的有效性和系统的容错能力。 |
+| 操作手册 | Runbook | 针对特定告警或故障场景的标准化操作手册，包含诊断步骤、恢复操作和升级条件。On-Call 的核心参考文档。 |
+| 故障注入 | Fault Injection | 有意识地在系统中引入故障（网络延迟、服务宕机、磁盘满、CPU 打满）的技术。工具：Chaos Monkey / Litmus / Gremlin。 |
+| 稳态假设 | Steady State Hypothesis | 混沌实验前定义的系统正常行为指标。实验目的是验证注入故障后系统能否维持稳态。 |
+
+---
+
+## 可观测性
+
+| 术语 | 英文 | 定义 |
+|------|------|------|
+| 可观测性 | Observability | 通过系统外部输出推断其内部状态的能力。三大支柱：日志（Logs）、指标（Metrics）、追踪（Traces）。 |
+| 分布式追踪 | Distributed Tracing | 追踪请求在微服务架构中的完整调用链路的技术，帮助定位跨服务的性能瓶颈和故障。工具：Jaeger / Zipkin / OpenTelemetry。 |
+| 告警疲劳 | Alert Fatigue | 由于告警数量过多或质量过低，On-Call 人员对告警产生麻木感，开始忽略甚至静音告警的现象。 |
+| 状态页面 | Status Page | 向用户公开展示服务运行状态和历史事故信息的页面。透明的状态页面能提升用户信任度。 |
+| 黄金信号 | Golden Signals | Google SRE 提出的四个核心监控指标：延迟（Latency）、流量（Traffic）、错误（Errors）、饱和度（Saturation）。 |
+| RED 方法 | RED Method | 微服务监控方法论：Rate（请求速率）、Errors（错误率）、Duration（请求耗时）。适用于请求驱动的服务。 |
+| USE 方法 | USE Method | 资源监控方法论：Utilization（利用率）、Saturation（饱和度）、Errors（错误数）。适用于基础设施资源监控。 |
+
+---
+
+## 变更管理
+
+| 术语 | 英文 | 定义 |
+|------|------|------|
+| 变更管理 | Change Management | 对生产环境变更（代码部署、配置修改、基础设施调整）进行计划、审批、执行和验证的流程。 |
+| 变更冻结 | Change Freeze | 在特定时间段（如大促前、节假日）禁止非紧急变更的策略，降低事故风险。 |
+| 蓝绿部署 | Blue-Green Deployment | 维护两套完全相同的生产环境，新版本部署到备用环境验证后切换流量，出问题立即切回。 |
+| 金丝雀发布 | Canary Release | 将新版本先发布给小比例用户（1-5%），监控指标正常后逐步扩大，异常则回滚。 |
+| 功能开关 | Feature Flag | 通过配置开关控制功能的启用/禁用，无需重新部署即可调整功能可见性。支持灰度发布和快速回滚。 |
+
+---
+
+## Agent Checklist
+
+- [ ] 团队对 SLA/SLO/SLI/Error Budget 的概念和关系已对齐
+- [ ] On-Call 新人已阅读并理解本术语表中的事故响应相关术语
+- [ ] 事故等级定义已在团队内达成共识并文档化
+- [ ] 复盘报告中使用的术语与本表定义一致
+- [ ] 新引入的运维/SRE 术语已补充到本术语表

package/incident/postmortem-and-response-deep-dive.md

@@ -0,0 +1,39 @@
+---
+id: postmortem-and-response-deep-dive
+title: postmortem-and-response-deep-dive
+domain: incident
+category: postmortem-and-response-deep-dive.md
+difficulty: intermediate
+tags: [and, deep, dive, incident, postmortem, response, 事故响应与复盘深度知识库]
+quality_score: 70
+last_updated: 2026-06-15
+---
+# 开发：Excellent（11964948@qq.com）
+
+## 事故响应与复盘深度知识库
+
+### 目标
+- 把每次故障转化为可复用的组织能力，持续降低重复事故概率。
+
+### 响应流程
+- 发现：告警触发与人工上报统一入口。
+- 分级：按业务影响和恢复难度分级。
+- 止损：优先保护核心链路与关键数据。
+- 恢复：分阶段恢复服务并验证。
+- 通报：同步进展、影响范围、预计恢复时间。
+
+### 复盘结构
+- 时间线：关键事件与决策点。
+- 根因：技术原因、流程原因、组织原因。
+- 影响：用户、业务、数据、品牌。
+- 修复：已完成措施与待完成措施。
+- 预防：门禁、监控、演练、规范更新。
+
+### 验收标准
+- 每次 P1 及以上事故必须复盘。
+- 改进项必须落地到具体负责人和截止日期。
+- 关键改进项必须在质量门禁或发布门禁中固化。
+
+### 常见失败模式
+- 只有故障描述没有根因分析。
+- 复盘后没有工程化措施，问题重复出现。