可观测、合规与 DORA：从 SBOM/SLSA 到 Four Keys 与事故响应

0. 元信息

• 主题路径：docs/topics/ci-cd-and-release/subtopics/observability-compliance-and-dora/README.md
• 主分类：工程技术
• 辅助分类：安全与可靠性
• 适合对象：已经把 CI/CD 与 GitOps 跑通，想度量交付能力并接入合规审计的工程师
• 建议周期：5～8 天，每天 1.5～2 小时
• 前置知识：iac-and-gitops
• 最终目标：能从 CI/CD + incident 系统自动采集 DORA Four Keys，能用 cosign 拒签伪造制品，能写 incident postmortem，能用 SBOM/SLSA 满足 SOC2 / ISO 基本要求

1. 学习路线

DORA Four Keys：部署频率 / 变更前置时间 / 变更失败率 / 失败恢复时间
  → Prometheus / Grafana 仪表盘
  → SLSA / SBOM / cosign 签名验证
  → audit log + immutable log sink
  → incident response + postmortem
  → chaos drill + game day
  → 合规对照：SOC2 / ISO 27001 / NIST SSDF

2. 阶段周数分配

精简子主题不固定周数。按概念、正常路径、失败路径、综合实验四段推进，共 5～8 天。

3. 九阶段表

4. 第一周任务

精简子主题省略逐日表。每天只引入一个变量；先跑正常路径，再做四类失败实验。Day 1 必须明确指标采集源（GitHub API / Argo CD / Prometheus）与保留周期。

5. 阶段通用验收

采用父主题 §5；本页额外要求保存仪表盘截图、SBOM 样例、cosign verify 输出、audit log 索引、postmortem 模板与清理命令。

6. 最终验收

完成 1 个 DORA 仪表盘（4 指标 + 服务维度）、1 份 cosign verify 流水线（拒签伪造）、1 份 postmortem、至少 4 类失败实验（签名失败、SBOM 缺失、audit log 断流、指标断采）、1 次 chaos drill，并用 10 分钟解释 DORA 与事故响应闭环。

7. 综合项目

把本页产出合入父主题首选项目：GitHub Actions → GHCR → k8s Argo Rollouts 金丝雀发布全链路。单独交付时，提供 DORA 仪表盘 JSON、cosign verify step、postmortem 模板、chaos drill runbook、notes/retrospective.md。

本主题贡献

本主题把交付能力、合规证据与事故响应闭环：DORA Four Keys 度量交付能力、SBOM / SLSA 供应链安全、cosign 签名验证、OPA 策略门控、postmortem blameless 文化、chaos drill game day 演练，可对 SOC2 / ISO 27001 / NIST SSDF 出证据。

职责（3 项）

1. 采集 DORA Four Keys（部署频率 / 变更前置时间 / 变更失败率 / MTTR），定义 incident severity 与 SLI/SLO/error budget，能解释 lead time 起点是 commit timestamp 而非 PR merge、为什么直接优化 raw metric 反而退化、为什么 elite 团队 change failure rate < 15% 且 MTTR < 1 小时；
2. 生成 SBOM（Anchore Syft 输出 SPDX 或 CycloneDX）、SLSA Build L3 provenance（in-toto attestation）、cosign keyless 签名（OIDC + Fulcio + Rekor transparency log），在 deploy gate 用 cosign verify 拒签伪造制品，能解释 provenance 描述「怎么 build」、signature 证明「谁签」，以及 OPA / Conftest 策略卡「不接受未签名 image」；
3. 写 postmortem blameless 模板（时间线 + 根因 + 行动项 + owner + due + follow-up），配 chaos drill game day（Chaos Mesh / LitmusChaos 注入 pod kill / network partition），能解释为什么 root cause 不写「谁」写「为什么」、为什么 audit log 必须 WORM + retention ≥ 1y。

交付物（4 项）

1. DORA 仪表盘（Grafana + Prometheus，按服务维度展示 4 指标 P50/P95/趋势），含 weekly 自动 report 发 Slack；
2. cosign verify-image + cosign verify-blob 流水线（keyless 模式，OIDC issuer = GitHub Actions / GitLab CI），含 transparency log 入 log 证据；
3. postmortem 模板（5 section + 行动项 owner + due），含真实事故复盘（DORA 指标反向作用到 CI 改进）；
4. chaos drill runbook（Chaos Mesh pod-kill + network-partition 注入，团队按 runbook 10 分钟内恢复）+ chaos drill 演练记录。

指标（3 项）

1. DORA 部署频率（按服务）≥ 1/day（elite 团队基线，DORA report 对照）；
2. MTTR ≤ 1 小时（elite 基线，recovery time - incident time 从 incident 系统自动算）；
3. cosign verify 阻断伪造制品率 = 100%（deploy gate 强制 verify，未签拒部署）。

8. 推荐开源资料

Prometheus（Apache-2.0）、Grafana（AGPL-3.0）作指标可视化；Sigstore cosign（Apache-2.0）、Rekor（Apache-2.0）、Fulcio（Apache-2.0）作签名；in-toto（Apache-2.0）作 provenance；Anchore Syft / Grype（Apache-2.0）作 SBOM 与扫描；Chaos Mesh（Apache-2.0）、Litmus（Apache-2.0）作 chaos；DORA 报告（dora.dev）作行业基线；SLSA（slsa.dev）作供应链规范。复制前核对当前 LICENSE。

9. 学习资料汇聚（v0.3 自包含）

9.1 背景与动机

可观测让你知道系统在做什么，合规让你能向监管与客户证明系统在做什么，DORA 让你知道团队交付能力在变好还是变差。三者闭环才能形成可持续的工程纪律。

DORA 由 Google Cloud 的 DevOps Research and Assessment 团队运营，Nicole Forsgren、Jez Humble、Gene Kim 在 Accelerate（2018）中系统化。四指标：部署频率（Deployment Frequency）、变更前置时间（Lead Time for Changes）、变更失败率（Change Failure Rate）、失败恢复时间（Mean Time to Restore / MTTR）。

供应链安全从 SolarWinds（2020）、Log4Shell（2021）、xz-utils（2024）等事件后变成硬要求。SLSA v1.0 把 build provenance 分级；cosign 提供无密钥签名；SBOM（SPDX / CycloneDX）让依赖可追溯。

Incident response 与 postmortem 文化来自 Google SRE Book（2016）、Charity Majors 的 Observability Engineering（2022）。今天的事故响应必须 postmortem-without-blame：时间线、根因、行动项、owner、due、follow-up。

9.2 概念地图

flowchart LR
  CI[CI runs] --> Metric1[deploy frequency]
  Git[Git commits] --> Metric2[lead time]
  Incident[incident system] --> Metric3[change failure rate]
  Incident --> Metric4[MTTR]
  Metric1 --> DORA[DORA dashboard]
  Metric2 --> DORA
  Metric3 --> DORA
  Metric4 --> DORA
  CI --> SBOM[SBOM generation]
  CI --> Sign[cosign sign]
  Sign --> Rekor[Rekor transparency log]
  Deploy[deploy gate] --> Verify[cosign verify]
  Verify --> Allow{allow?}
  Allow -- yes --> Cluster
  Allow -- no --> Block[block deploy]
  K8s[k8s audit] --> Sink[immutable log sink]
  ArgoCD[Argo CD audit] --> Sink
  GitHub[GitHub audit] --> Sink
  Sink --> SOC2[SOC2 / ISO / NIST evidence]
  Incident --> IR[incident response]
  IR --> PM[postmortem]
  PM -.行动项.-> CI
  PM -.反馈.-> DORA

核心关系：CI / Git / incident 是 DORA 的数据源；SBOM + sign + verify 是供应链门；audit log 是合规证据；postmortem 反过来改进 CI 与 DORA。

9.3 基础知识讲解

9.3.1 论文 / 规范

9.3.2 书

9.3.3 博客 / 文档

9.3.4 人物

9.3.5 方法

9.4 经典问题与经典案例

9.5 学习难点

概念难点

思维难点

工程难点

9.6 技术标准与接口

9.6.1 Entity

9.6.2 Scope

DORA 是度量框架；SLSA 是供应链等级；Sigstore 是签名工具链；SBOM 是依赖清单；audit log 是合规证据；postmortem 是事故闭环；chaos 是演练方法。它们之间用 SBOM 关联签名，用 audit log 关联合规，用 postmortem 关联 DORA 趋势。

9.6.3 Structure

DORA 四指标公式：deploy frequency = deploy count / period；lead time = deploy time - commit time；change failure rate = incident count / deploy count；MTTR = recovery time - incident time。cosign：sign / verify-blob / verify-image / verify-attestation。SBOM：syft packages / grype sbom:。

9.6.4 Ecosystem

Prometheus + Grafana 是事实标准；Datadog / New Relic / Honeycomb 是商业替代；cosign 与 Rekor / Fulcio 配套使用；Anchore Syft / Grype 与 cosign 集成；Chaos Mesh / LitmusChaos 互为对照。

9.6.5 Depth Tiers

本子主题目标是 L3。

9.6.6 Source

• DORA Four Keys 指南
• SLSA v1.0
• Sigstore 文档
• Anchore Syft
• Prometheus 文档
• Google SRE Book
• 引用版本快照日期：2026-07-30；实作前运行 cosign version、syft version、prometheus --version。

10. 常见误区

• DORA 直接优化 raw metric，不看业务结果；
• change failure rate 没定义 incident severity；
• lead time 起点用 PR merge 而不是 commit；
• cosign 签了但 deploy 不 verify；
• keyless 签名在本地或 air-gapped 跑失败；
• SBOM 输出但 deploy gate 不卡；
• audit log 当 logrotate 对象定期清理；
• postmortem 写成甩锅文档；
• chaos drill 只在 staging 跑一次；
• 合规文档齐全但 owner 与 due 缺失；
• 行动项没有 follow-up，下个事故再写一遍；
• 把 error budget 当上限而不是下限；
• SLI/SLO 拍脑袋，没用历史数据反推；
• 把 metric 采集与业务结果割裂。

11. 所有知识点分类（统一规则）

1. 编程语言；2. 数据结构与算法；3. 计算机基础；4. 工程技术；5. Web 与后端；6. 前端与客户端；7. 数据与人工智能；8. 项目与职业能力；9. 安全与可靠性。

本计划归属：工程技术 主 + 安全与可靠性 辅。