# DevOps & SRE Master OS — Synthesis

> DevOps 与站点可靠性工程 (SRE) 行业操作系统 — 从 commit → build → 渐进式发布 → on-call → 事件 → 无指责复盘 → 错误预算 全 delivery + operability lifecycle, 心智模型 + 决策 playbook + 工具栈 + SOP + 表达 + 工程伦理边界 一体化。Phase 3 (skill writeup) 直接消化本文件。

---

## 1. 心智模型 (Mental Models)

### 1.1 错误预算思维 — 可靠性是产品决策, 不是技术债; 100% 是错误的目标

> (figures: Liz Fong-Jones / Jez Humble / Charity Majors / Google SRE 团队)

**一句话**: 可靠性不是越高越好 — `error budget = 1 - SLO` 是一笔可花的预算, 它把"该发功能还是修可靠性"从情绪/道德争论变成 dev/SRE/产品三方共享的数字决策; 盲目追 100% 可用 = 把所有预算耗在边际可靠性、牺牲功能交付速度, 是反模式 (Google SRE 学科核心: 100% 是错误的可靠性目标)。
**应用**: 服务上线先选 user-facing SLI (成功率/p99 延迟) → 定一个"用户察觉不到差异"的 SLO (99.9% vs 99.99% 多半无感) → 算 budget → 写"烧光怎么办"的 error budget policy (冻结发布、全员转修); 当 dev 与 SRE 在"发功能 vs 修稳定"扯皮时, 用 budget 余额裁决而非谁嗓门大。
**局限**: 仅对有真实用户体验可度量的服务成立; 对监管型/安全合规/生命攸关系统 (医疗、航空), 法律/安全底线高于 budget 经济学; SLA (对客户的法律合同) 应宽松于内部 SLO, 别把内部目标变法律承诺。

- **figures**: Liz Fong-Jones / Jez Humble / Charity Majors / Google SRE 团队
- **evidence**: [T01-S013 / T03-S002 / T04-S001 / T06-S002]

### 1.2 小批量高频部署 > 少发布 (反直觉) — 速度与稳定不是 trade-off

> (figures: Jez Humble / Gene Kim / Nicole Forsgren / DORA team)

**一句话**: 直觉是"少发布就少出事", 但 DORA 用 23,000+ 受访者的统计学证明这是错的 — 低部署频率 = 大批量变更 = 更高 change failure rate + 更难定位; elite performer 部署更频繁 AND 恢复更快 AND 失败更少, 四者正相关不是取舍 (Accelerate 核心反直觉发现)。
**应用**: 面对"我们最近故障多, 要不要降低发布频率"的提议, 反向回答 — 减小批量 + 加自动化测试金字塔 + 渐进式发布 (canary) + 自动回滚 + trunk-based + feature flag (deployment ≠ release); 用 DORA 四指标 (部署频率/前置时间/变更失败率/MTTR) 度量改进, 但绝不把它当个人 KPI 考核 (Goodhart 定律一上 KPI 就被博弈失真)。
**局限**: monorepo / 强监管 / 嵌入式 / 数据库 schema 等领域落地受限 (需 expand-contract 等专门技术); "高频"的前提是自动化测试 + 可回滚 + 可观测都到位, 否则只是更快地把 bug 推上生产。

- **figures**: Jez Humble / Gene Kim / Nicole Forsgren / DORA team
- **evidence**: [T01-S003 / T03-S029 / T04-S009 / T06-S006]

### 1.3 无指责复盘 — 没有单一 root cause, 只有贡献因素; blameless ≠ 无问责

> (figures: John Allspaw / Nora Jones / Richard Cook / Lorin Hochstein)

**一句话**: 复杂系统的故障从不是单一根因 + 单个人犯错, 而是多个本身不足以致灾的贡献因素叠加; 复盘的目的是从系统里榨出最大学习, 不是找人背锅 — 因为指责个人 = 工程师下次隐藏真相 = 下次故障更严重; 但 "blameless ≠ no accountability", 它是系统/流程问责 ("改这个流程") 而非个人惩罚 ("开除谁")。
**应用**: 故障后建事实时间线 → 列 ≥ 3 个贡献因素 (技术 + 流程 + 信息) → 不只问"为什么坏了"更问"为什么难被检测/难止血" → action items 必带 owner + 日期 + 闭环跟踪; 主持人开场重申 blameless 规则, 措辞写"系统让人这么做了"而非"某人犯了错"; 把"人在事件中如何即兴救场"的隐性专长显性化进 runbook (人是韧性来源不是故障来源)。
**局限**: blameless 常被外行/管理层误读为"出事没人负责" — 必须显式区分系统问责 vs 个人惩罚; 监管/安全事件复盘同样 blameless 但访问受控、对外版本需脱敏。

- **figures**: John Allspaw / Nora Jones / Richard Cook / Lorin Hochstein
- **evidence**: [T01-S027 / T03-S028 / T04-S020 / T06-S004]

### 1.4 toil 量化削减是 mandate — 手工救火是组织失败信号, 不是英雄主义

> (figures: Tom Limoncelli / Liz Fong-Jones / Gene Kim / Google SRE 团队)

**一句话**: toil 有严格定义 (手工 + 重复 + 可自动化 + 无长期价值 + 随服务规模线性增长的运维劳动), SRE 建议 toil < 50% 时间 — 把削减 toil 当作 mandate 不是"有空再做"; 把通宵救火、英雄主义加班当美德, 是组织失败信号而非个人光荣。
**应用**: 任一运维任务做第二次就问"这是不是 toil", 量化它吃掉多少时间, 列入自动化 backlog; 资深人擅长判断"哪步是低信号 toil 可跳" (人工 staging 点测 / vanity 指标 / 仪表盘堆砌) 和"哪步该从人转交给机器" (canary 自动分析 / multiwindow burn-rate / policy-as-code 门禁)。
**局限**: 不是所有手工劳动都是 toil — 一次性的工程设计、需要人类判断的语义决策不是 toil; 自动化本身也有成本, 极低频的任务自动化可能得不偿失 (要算 toil 总量而非单次)。

- **figures**: Tom Limoncelli / Liz Fong-Jones / Gene Kim / Google SRE 团队
- **evidence**: [T01-S039 / T03-S005 / T04-S001 / T06-S003]

### 1.5 监控 (known-unknowns) vs 可观测性 (unknown-unknowns) — 不混为一谈, 也不对立营销

> (figures: Charity Majors / Cindy Sridharan / Brendan Gregg)

**一句话**: monitoring 处理 known-unknowns (预设 dashboard/alert, 你知道要盯什么), observability 处理 unknown-unknowns (高基数 wide events 任意维度事后下钻, 排查"从没见过的故障"); 二者是层次不是对立 — 但厂商把 "observability" 当 "metrics+logs+traces 三件套 SKU 打包"卖是营销窄化 (Charity Majors 反复批), 同时也不能因此否定 metrics 监控的价值。
**应用**: 简单已知指标 Prometheus 监控足够; 复杂分布式系统排查 unknown-unknowns 才上高基数 wide events (Honeycomb); 用 OpenTelemetry 一次 instrument 防锁定 (改 collector config 即切后端, 别把 instrument code 绑死厂商 SDK); 判断团队是在做监控还是可观测性 = 问"能不能回答一个你从没预设过的问题"。
**局限**: 高基数是 observability 的前提也是成本炸弹 (custom metrics 易占 30-50% 账单), 要按价值采样; observability 不是"不写测试"的借口 ("test in prod" 常被初级工程师误读)。

- **figures**: Charity Majors / Cindy Sridharan / Brendan Gregg
- **evidence**: [T01-S009 / T02-S027 / T04-S015 / T06-S030]

### 1.6 声明式 + GitOps + 不可变 — cattle not pets, git 为单一真相源

> (figures: Kelsey Hightower / Mitchell Hashimoto / Adam Wiggins / CNCF)

**一句话**: 服务器/基础设施应像牲畜 (可编号、可替换、坏了重建不抢救) 而非宠物 (独一无二、SSH 进去手工照料); 用声明式描述"期望的最终状态" (K8s/Terraform) 让系统自己 reconcile 收敛, 以 git 为单一真相源 (GitOps: pull-based reconcile + drift 自动纠正), 而非命令式 ClickOps 手点控制台。
**应用**: 改基础设施/部署一律走代码 + PR review + 声明式 apply, 禁止登生产手改 (制造 drift + 不可复现); 区分真 GitOps (Argo CD/Flux pull reconcile) vs CIOps ("git 存 YAML + CI 跑 kubectl apply" 是 push 模式不算 GitOps); 资深口头禅 "is this GitOps or ClickOps" / "declarative not imperative" / "don't SSH in to fix it"。
**局限**: 有状态服务 (数据库) 上不上 K8s 仍有争议 (DBRE 谨慎); 声明式对"一次性紧急 break-glass 操作"反而笨重, 但事后必须立即纳管。

- **figures**: Kelsey Hightower / Mitchell Hashimoto / Adam Wiggins / CNCF
- **evidence**: [T04-S014 / T04-S035 / T06-S009 / T02-S012]

### 1.7 IaC state 是危险操作面 — terraform state 含明文密钥, apply 前必 plan review

> (figures: Mitchell Hashimoto / Yevgeniy Brikman / HashiCorp / OpenTofu)

**一句话**: 基础设施即代码把"点鼠标"变成"可审查可回滚的代码", 但 `terraform.tfstate` 含明文密钥 + 是整个 IaC 最危险的操作面 — 误删 / 本地存储 / 提交 git / 两人同时 apply 都是灾难; 一个 typo 的 `count`/`for_each` 能批量删生产服务器 (类比手术前不核对就开刀)。
**应用**: state 必须远程后端 + 加锁 (S3+DynamoDB / GCS lock) + 加密 (KMS / OpenTofu native encryption) + 最小权限, 绝不进 git; apply 到生产前必 `plan` review (尤其看 destroy); 危险操作要有防呆 (限制批量删除、二次确认、变更窗口); 用 policy-as-code (OPA/Conftest/Checkov) 在 CI 卡 plan, 把安全基线变成不可绕过门禁; CI 跑 apply 用短期 OIDC token 不用长期 key。
**局限**: 这条心智模型针对 mutable cloud 资源声明; 对纯应用层代码、无状态制品不适用; policy-as-code 门禁过度会把 IaC 变成审批地狱, 要卡基线不卡业务意图。

- **figures**: Mitchell Hashimoto / Yevgeniy Brikman / HashiCorp / OpenTofu
- **evidence**: [T03-S016 / T03-S017 / T04-S028 / T06-S036]

---

## 2. 标准 Playbook (10 条 决策启发式)

1. **如果 服务上线但没有可靠性目标 / 告警全是 cause-based 噪音 / dev 与 SRE 在"发功能还是修稳定"扯皮**: 则 选 user-facing SLI → 定一个用户无感的 SLO (不是越高越好) → 算 error budget → 写"烧光就冻结发布"的 policy (跨 dev/SRE/产品签字)。案例: Google SRE 把 100% 列为错误目标, 99.9% vs 99.99% 用户多半无感, 余下预算用来发功能 (T03-S002 / T04-S001)。
2. **如果 change failure rate 高、团队想"少发布更安全"**: 则 答案不是少发布, 而是减小批量 + 自动化测试 + 自动回滚 + 渐进式发布 + trunk-based。案例: DORA Accelerate 证明 elite performer 部署更频繁 AND 更稳定, 速度与稳定不是 trade-off (T03-S029 / T04-S009)。
3. **如果 生产正在受损 (事件战时)**: 则 先止血 (回滚 / 切流量 / 降级 / 扩容), root cause TBD, 永不 fix-and-learn 同时进行。案例: Knight Capital 2012 边查边亏 45 分钟 4.4 亿美元破产; 资深 IC 严守 "let's not fix and learn at the same time" (T03-S010)。
4. **如果 一个达到门槛的事件解决后 (通常 SEV-2+)**: 则 开 blameless 复盘 — 列 ≥ 3 个贡献因素而非单一 root cause, 追问"为什么难检测/难止血", action items 必带 owner + 日期 + 闭环。案例: GitLab 2017 误删生产主库 + 5 层备份全失效, 正确复盘不骂工程师而落在"备份必须验证恢复 + 危险操作防呆" (T03-S028 / T04-S020)。
5. **如果 要新建/修改/删除基础设施资源**: 则 写声明式代码 → 远程加密加锁 state → `plan` 预演 → code+plan review (尤其 destroy) → `apply` → 定时 drift 检测; 禁手改控制台。案例: AWS S3 us-east-1 2017 一条命令 typo 多删服务器引发大面积故障, 教训是危险操作要有防呆 + 预览 (T03-S016 / T04-S028)。
6. **如果 要配一条告警**: 则 必须基于用户感知的 symptom (四个黄金信号 / SLO burn-rate) 且 actionable (有人能立刻做某事), 否则删掉或降级为 ticket/dashboard。案例: alert fatigue 是管理失败不是个人韧性问题, "这个告警一直响先静音吧"是漏报真事故的温床 (T03-S032 / T04-S001)。
7. **如果 某运维任务手工、重复、且随服务规模线性增长**: 则 标记为 toil、量化耗时、列入自动化 backlog (不是"有空再做"), 目标 toil < 50% 时间。案例: SRE 把削减 toil 当 mandate, 把救火加班当美德是组织失败信号 (T03-S005 / T06-S003)。
8. **如果 想做混沌工程 / game day**: 则 先定义稳态 (可量化的"正常") + 提假设 + 最小化爆炸半径 + 准备自动 abort, 而非随机砍服务; 且 chaos 前先验证基本功 (备份能恢复、告警 actionable、能回滚)。案例: Cloudflare 2019 一条 WAF 正则灾难性回溯 100% CPU 全球宕机, game day 正可暴露这类"全量推送"风险 (T03-S025 / T04-S025)。
9. **如果 是小团队 (<10 人) / 刚起步 / 验证想法**: 则 默认托管 PaaS (Cloud Run/ECS/Fly.io) + GitHub Actions + 云原生托管监控, 别为"显得专业"上 K8s + service mesh + multi-cloud。案例: DORA 2025 强调平台质量 > 工具先进度, 小团队的可靠性瓶颈是基本功不是工具栈复杂度, "do you really need Kubernetes for this" (T02-S060 / T02-S049)。
10. **如果 选可观测性/云/IaC 工具**: 则 用厂商中立标准层防锁定 — OTel 之于可观测性、Terraform/OpenTofu 之于云、K8s 之于编排; instrument/声明一次, 后端/云可换, 别把 instrument code 绑死厂商 SDK。案例: Datadog custom metrics 易占 30-50% 账单, 37% 团队为切换自由选 OTel, 成本压力使负载回流 OSS (T02-S022 / T02-S058)。

---

## 3. 工具栈 (Tools)

> 直接消化 Track 02 的四层结构 (必备 / 场景特化 7 类 / 新兴 / 选型决策树) + 一致性 sanity-check。所有 GitHub stars/活跃度为 2026-05-19 实测。

### 3.1 必备层 (≥ 80% 从业者用, 14 个)

- **编排**: Kubernetes (容器编排事实标准, 云原生底座, stars 122k) [T02-S001] + Docker/OCI (镜像与本地构建通用语) [T02-S002]。
- **IaC**: Terraform (HCL + 最大 provider 生态, 注 2023 改 BUSL 许可催生 OpenTofu fork) [T02-S003]。
- **CI/CD + GitOps**: GitHub Actions (最低摩擦起步) [T02-S041] + Argo CD (K8s GitOps 多数采用方案, ~60% 集群应用交付) [T02-S012, T02-S051] + Helm (K8s 应用打包标准) [T02-S032]。
- **可观测性**: Prometheus (指标监控事实标准, 67% 生产采用) [T02-S016, T02-S020] + Grafana (可视化通用层) [T02-S018] + OpenTelemetry (厂商中立 telemetry 标准, 79% 总采用, 防锁定) [T02-S021, T02-S020]。
- **配置/密钥**: Ansible (无 agent 配置管理常青树) [T02-S008] + Vault (密钥/动态凭证事实标准) [T02-S035]。
- **事件/on-call**: PagerDuty (告警路由 + 排班 + IC 流程) [T02-S045, T02-S046]。
- **商用可观测性**: Datadog (企业 all-in-one 默认, 但成本会失控) [T02-S028]。
- **云平台**: AWS / GCP / Azure (Well-Architected, DORA 2025 称 90% 组织已采用至少一个) [T02-S049, T02-S057]。

> Sanity check: 必备层 14 个 ≥ 3 ✅, 多个有 survey ≥ 50-86% 采用率背书 (Prometheus 67% / OTel 79% / Argo CD ~60% 集群)。

### 3.2 场景特化 (7 类, 不同 engagement 不同侧重)

- **CI/CD 与发布**: GitLab CI (一体化 DevSecOps 平台) / Jenkins (legacy 存量大, 绿地别新上) / Tekton (K8s 原生构建块) / Flux (controller-only GitOps) / Spinnaker (多云重型, 运维成本高份额下滑) / Argo Rollouts (canary 自动分析) [T02-S047, T02-S040, T02-S014, T02-S039]。
- **IaC**: OpenTofu (Terraform 开源 fork, native state 加密) / Pulumi (通用语言写 IaC) / Crossplane (云资源即 K8s CRD) / OPA (通用 policy-as-code Rego) [T02-S005, T02-S007, T02-S009, T02-S010]。
- **容器与编排**: Kustomize (无模板 overlay, kubectl 内置) / Istio (功能最全 mesh, 重) / Linkerd (轻量 Rust mesh) / Cilium (eBPF CNI + 网络可观测) [T02-S033, T02-S029, T02-S030, T02-S031]。
- **可观测性**: Loki (低成本日志) / Tempo (对象存储追踪) / Jaeger (追踪 UI) / VictoriaMetrics (Prometheus 长存替代) / Thanos (全局视图) / Honeycomb (高基数 wide events 查 unknown-unknowns) [T02-S019, T02-S024, T02-S023, T02-S025, T02-S026, T02-S027]。
- **事件与 on-call**: Opsgenie (Atlassian, 注已宣 EOL 2027 别新选) / Grafana OnCall (OSS) / incident.io [T02-S045, T02-S046]。
- **云平台与 FinOps**: OpenCost (K8s 成本归因开放规范) + 云厂 Cost Explorer + AWS Builders' Library (运维一手) [T02-S055, T02-S057]。
- **平台工程与 DevSecOps**: Backstage (Spotify IDP 框架, 需专职平台团队) / Trivy (镜像+IaC+SBOM 一体扫描) / cosign+sigstore (制品签名/供应链) / Kyverno+OPA (admission policy) / Falco (eBPF 运行时安全) [T02-S034, T02-S036, T02-S037, T02-S053, T02-S054]。

### 3.3 新兴 / 实验层 (近 12 月起势, 6 个, decay 多 high)

- **OpenObserve** — Rust + 列存 OSS Datadog 替代, benchmark 称 60-98% 成本下降 (业内 benchmark, 生产前充分评估) [T02-S052, T02-S058]。
- **ClickHouse-as-observability (ClickStack)** — TB/日级 telemetry 列存自建省 >90% (业内估), ThoughtWorks Radar 收录 [T02-S048, T02-S058]。
- **Kyverno** — YAML 原生 K8s policy (对标 OPA Gatekeeper, 不用学 Rego), 已近成长期 [T02-S053]。
- **OpenCost** — FinOps 成本归因开放规范 [T02-S055]。
- **Grafana Pyroscope / Parca** — continuous profiling 作为可观测性"第四支柱" [T02-S059]。
- **Falco** — eBPF 运行时安全 (CNCF 毕业, 采用仍在扩散) [T02-S054]。

### 3.4 选型决策树 (7 分支, 原则: 先问"你真的需要这个复杂度吗")

1. **小团队/起步/<10 人** → 托管 PaaS + GitHub Actions + 托管监控; **不推荐** K8s+mesh+multi-cloud (resume-driven 重灾区) [T02-S060, T02-S049]。
2. **要 production-grade CI/CD** → GitHub Actions + Argo CD (GitHub 生态) / GitLab CI (要一体化) / Argo Rollouts 做 canary (别用 Spinnaker 除非真大厂多云) [T02-S041, T02-S012, T02-S039]。
3. **IaC** → Terraform/OpenTofu (声明式最大生态, 顾虑 BUSL 选 OpenTofu) / Pulumi (开发者背景) / Crossplane (K8s 原生自助); 全分支硬规矩: state 远程加锁加密 + apply 前 plan review [T02-S003, T02-S005, T02-S007, T02-S009]。
4. **可观测性** → Prometheus+Grafana+Loki+OTel (OSS 默认防锁定) / Datadog (企业 all-in-one, 但用 OTel instrument 保留切走能力) / Honeycomb (高基数 unknown-unknowns) / 列存自建 (体量巨大成本敏感, experimental) [T02-S016, T02-S028, T02-S027, T02-S052]。
5. **事件与 on-call** → PagerDuty + 其开源 Incident Response 手册; 别新选 Opsgenie (EOL); OSS 用 Grafana OnCall; 硬规矩: 每条告警必 actionable [T02-S045, T02-S046, T02-S056]。
6. **平台工程** → Backstage (需专职平台团队); 前提检查 DORA 2025 "门户≠平台质量"; **不推荐** 设独立"DevOps 团队"做发布 (制造第三个筒仓) [T02-S034, T02-S049, T02-S048]。
7. **DevSecOps/供应链** → Trivy (shift-left CI 门禁) + cosign/sigstore (签名) + OPA/Kyverno (admission) + Vault (密钥); 先扫已知漏洞再追 SLSA 等级 [T02-S036, T02-S037, T02-S010, T02-S038]。

### 3.5 避坑清单 (≥ 5 条)

1. ❌ 为"显得专业"上 K8s+service mesh+multi-cloud — 多数公司不需要, 瓶颈是基本功不是工具先进度 ("do you really need Kubernetes for this") [T02-S001, T02-S060]。
2. ❌ 把 terraform.tfstate 当普通文件 (本地/进 git/误删) — 含明文密钥+是危险操作面, 必须远程加锁加密 [T02-S004, T02-S006]。
3. ❌ 把可观测性厂商 SDK 绑进 instrument code — 用 OTel instrument 一次, 换后端只改 collector config [T02-S022, T02-S020]。
4. ❌ 无视 Datadog custom metrics 账单 — 易占 30-50% 账单 + 加服务时 40-200% 跳涨, 定期审计 metric 基数 [T02-S058]。
5. ❌ 把 observability 当"三件套 SKU 打包"买 — observability 是系统属性不是产品层级 [T02-S027]。
6. ❌ 新项目选 Jenkins/Opsgenie/Spinnaker — legacy/EOL/份额下滑; 绿地用 Actions/PagerDuty/Argo CD+Rollouts [T02-S047, T02-S045, T02-S039]。
7. ❌ 把第三方 GitHub Action pin 到 tag — tag 可被重指 (2025 多起 action 投毒), pin 到 commit SHA [T02-S038]。
8. ❌ 假设备份没问题就不测恢复 — GitLab 2017 五层备份全失效, 备份必须定期验证恢复 [T02-S043, T02-S057]。

---

## 4. 工作流 (Workflows)

> 直接消化 Track 03 的 8 个 SOP (入门 SOP / 资深路径 skip-optimize-add / 近期变化) + 一致性 sanity-check。8/8 workflow 均有完整 skip+optimize+add。

### 4.1 CI/CD 渐进式发布 (commit → build → test → canary → 自动回滚)
- **入门 SOP**: commit+CI 触发 → 构建不可变制品 (不是 `latest`) → 自动化测试金字塔门禁 → staging 验证 → canary 1-5% 流量 → 逐步放量看 SLI → 指标恶化即回滚到上一个不可变 digest [T03-S031, T03-S033, T03-S012]。
- **资深路径**: 跳过 人工 staging 点测 (信任自动化测试 + 真实 canary) / 优化 为指标驱动的自动 canary 分析 (Argo Rollouts AnalysisTemplate 查 Prometheus 自动 promote/abort) / 额外 做 kill switch (feature flag 解耦 deploy 与 release) + deploy freeze 窗口 + 自动回滚护栏 [T03-S031, T03-S012, T03-S033]。
- **近期变化**: medium decay — progressive delivery 主流从"时间驱动放量"转向"指标驱动自动 canary 分析"; canary 自动化工具链 12-24 月仍在演进。

### 4.2 事件响应 + on-call (alert → triage → declare SEV → IC → mitigate → comms → resolve)
- **入门 SOP**: ack 告警 → triage 评估影响 → declare SEV 等级 → 指定 IC (只协调不动手) → mitigate 先止血 → comms/status page 内外更新 → resolve + 移交复盘 [T03-S006, T03-S007, T03-S008, T03-S010]。
- **资深路径**: 跳过 事件中过早 root-cause 调查 (mitigate first) / 优化 declare 阈值 (宁可多 declare, 晚 declare 比误 declare 代价大) + runbook 一键缓解 / 额外 做角色分工 (IC/Deputy/Scribe/Comms/SME) + follow-the-sun 排班避免熬夜 [T03-S010, T03-S007, T03-S009, T03-S032]。
- **近期变化**: low decay — IC/SEV/先止血是数十年 ICS 稳态; 增量是 AI 辅助 incident summary, 但人定 SEV + IC 协调不变。

### 4.3 无指责复盘 (timeline → contributing factors → action with owners → 不指责个人)
- **入门 SOP**: 建事实时间线 → 找 ≥ 3 个贡献因素 → 追问"为什么难检测/难缓解" → action items 带 owner+日期 → 保持 blameless 措辞 → 分享+闭环跟踪 [T03-S004, T03-S028, T03-S027]。
- **资深路径**: 跳过 寻找单一 root cause (接受复杂系统无孤立根因) / 优化 提问方式 (从"who/why-blame"转"what made this hard" + second-stories 还原当时决策合理性) / 额外 做可检测性 + 适应能力分析 (把人的隐性专长显性化进 runbook) [T03-S028, T03-S027]。
- **近期变化**: low decay — 复盘文化 1998 Cook + 2009 Allspaw 已成熟; LFI 社区把焦点从 MTTR 推向"事件作为学习投资"。

### 4.4 SLO 定义 + error budget (pick SLI → set SLO → policy → burn-rate alerting)
- **入门 SOP**: 选 user-facing SLI → 定基于历史的 SLO (不是越高越好) → 算 budget=1-SLO → 写 error budget policy (烧光的强制动作) → 配 burn-rate 告警 [T03-S003, T03-S002, T03-S001]。
- **资深路径**: 跳过 vanity/cause-based 指标 (CPU/内存当 SLI) / 优化 告警为 multiwindow multi-burn-rate (长窗防抖动 + 短窗快响应) / 额外 做 error budget policy 的跨团队谈判落地 (dev/SRE/产品签字, 烧光真冻结) + 定期 review SLO 是否仍反映用户体验 [T03-S003, T03-S001, T03-S002]。
- **近期变化**: medium decay — multiwindow burn-rate 已成默认; 各平台把 burn-rate 告警内建 + OpenSLO 推 SLO-as-code。

### 4.5 IaC 变更 (写 module → plan → review → apply → state 管理 → drift 处理)
- **入门 SOP**: 写/改声明式 module → 配远程 state backend + 加锁 + 加密 → `plan` 预演 → code+plan review (尤其 destroy) → `apply` → 定期 drift 检测 [T03-S015, T03-S016, T03-S017]。
- **资深路径**: 跳过 任何手改控制台/ClickOps (紧急时也走 break-glass IaC 路径或事后立即纳管) / 优化 review 为 policy-as-code 自动门禁 (OPA/Conftest/Checkov 卡 plan) / 额外 做 state 安全纵深 + 定时 drift 检测排程 + module 抽象成 golden path [T03-S015, T03-S034, T03-S016]。
- **近期变化**: low decay — IaC 第一性原理稳; HashiCorp BUSL 催生 OpenTofu (native state encryption); 定时 drift 检测工具兴起。

### 4.6 Kubernetes 部署与运维 (manifest/Helm → resource limits → rollout → HPA → 排 CrashLoop/OOM)
- **入门 SOP**: 写 manifest/Helm/Kustomize → 设 resource request/limit → 配 liveness/readiness probe → rollout (坏了 `rollout undo`) → 配 HPA 弹性 → 排 CrashLoop/OOM (`logs --previous` + `describe`) [T03-S021, T03-S019, T03-S020]。
- **资深路径**: 跳过 手写裸 YAML 和命令式 `kubectl apply` (走 GitOps, git 单一真相源) / 优化 request/limit 用实测数据而非拍脑袋 (内存 limit=request 防 OOM) / 额外 做 PodDisruptionBudget + 反亲和 + topology spread + probe 精调 [T03-S011, T03-S019, T03-S018]。
- **近期变化**: medium decay — GitOps 已是 K8s 交付多数采用方案; K8s 推进 in-place pod resize / sidecar containers GA。

### 4.7 可观测性 instrumentation (RED/USE → metrics+logs+traces → dashboards → actionable 告警)
- **入门 SOP**: 选方法 RED (服务) / USE (资源) → 用 OTel 一次埋点 → 结构化日志 (带 trace_id) → traces 串联跨服务 → 做用户旅程仪表盘 → 配 actionable 告警 [T03-S023, T03-S024, T03-S022]。
- **资深路径**: 跳过 仪表盘堆砌与"什么都监控" (只盯 RED/USE + SLO) / 优化 为 OTel 一次埋点 + 高基数宽事件支持任意维度下钻 / 额外 做 SLO 驱动告警 (burn-rate symptom 而非 cause) + telemetry 成本治理 (按价值采样) [T03-S023, T03-S022, T03-S024]。
- **近期变化**: medium decay — OTel 已成中立采集事实标准; profiling 第四支柱兴起 + ClickHouse 列存自建 (成本驱动) + Observability 2.0 wide events。

### 4.8 混沌工程 / Game Day (hypothesis → steady state → blast radius → experiment → learn)
- **入门 SOP**: 定义稳态 (可量化"正常") → 提假设 ("当 X 发生稳态仍保持") → 控爆炸半径 (最小范围起步 + 安全停止条件) → 注入真实世界事件 → 观测验证假设 → 学习+修复+复盘 [T03-S025, T03-S026]。
- **资深路径**: 跳过 低价值随机故障注入 (只对有真实假设的场景做, 先确保基本功) / 优化 blast radius 控制与自动安全停止 (稳态一偏离即停 + 自动回滚) / 额外 做 pre-mortem + 跨团队 game day 编排 (含 comms/IC 演练) + 验证过的实验自动化持续跑 [T03-S025, T03-S026]。
- **近期变化**: high decay — 唯一 high decay workflow; chaos 工具更深度 K8s 原生 (实验即 CRD) + 安全混沌工程 + AI 辅助生成假设; 但五原则不变。

---

## 5. 表达 DNA

> 不模拟某个具体 figure, 而是模拟"这一行的资深人 (SRE/平台/DevOps 工程师) 聚在一起讨论时的 register"。多人融合, 流派分裂在表达层也应体现。

### 5.1 高频黑话 / 内行用语 (Track 06 Tier 1)
error budget (是用来花的不是技术债) / toil (有严格定义, 量化削减非美德) / blameless (≠ no accountability) / "who's IC?" (事件开场第一句) / "declaring a SEV2" (是个动作) / "is this actionable" / "is this GitOps or ClickOps" / cattle not pets / declarative not imperative / "do you really need K8s for this" / "let's not fix and learn at the same time" / "the system let them do it" / symptom-based alerting / 几个 9 (nines) / p99 (念 "p-ninety-nine", 百分位不能相加平均) / SEV (念 "sev-one" 不是 "S-E-V-1") / SLSA (念 "salsa") / "burning error budget" / "reduce MTTR not chase MTBF"。

> 中国一手 register (zh-CN): 稳定性 / 降级预案 / 全链路压测 / 容量水位 / 故障演练 / 红线·SEV 定级 / 值班 oncall 拉群 / 复盘 action 落地 / 可观测性体系建设。

### 5.2 外行破绽 (outsider-tells, Track 06 直接用)
- "我们要 100% 可用性" → 100% 是错误目标, 每多一个 9 成本指数上升 [T06-S002]。
- "加个 DevOps 团队负责发布" → 制造第三个筒仓 (Team Topologies 明确批判) [T06-S031]。
- "上生产手动改一下就行 / SSH 进去修" → cattle not pets, 造 drift 不可复现 [T06-S008]。
- "这个告警一直响先静音吧" → 告警必 actionable, 静音=alert fatigue 温床 [T06-S005]。
- "备份肯定没问题不用测" → 未验证恢复的备份等于没有 (GitLab 2017) [T06-S004]。
- "少发布就少出事" → 反直觉错, 低频=大批量=更高失败率 (DORA) [T06-S006]。
- "找到根因了, 是某某人为失误" → 复杂系统无单一根因, 归咎个人是危险信号 [T06-S004]。
- "把 tfstate 提交 git 方便共享" → 含明文密钥+危险面 [T06-S036]。

### 5.3 厂商话术拒绝 (vendor-speak the field rejects)
"Single pane of glass" (营销老梗, 一块屏解决不了根因) / "NoOps" / "serverless 消灭运维" (运维责任不消失只换形态, 仍需 SLO/可观测性/成本/冷启动) / "observability = 我们的 metrics+logs+traces 三个 SKU 打包" (Charity Majors 反复反对, observability 是能力不是产品组合) / "AIOps/AI 自动运维取代 SRE" (抽象层上移不消除可靠性工程判断) / "买我们就 Well-Architected 了" (WAF 是评审框架不是可购买状态)。共同价值观: **抽象不消除责任, 可靠性是工程纪律不是采购** [T06-S030, T06-S008, T06-S020]。

### 5.4 对话样本库 (industry voice 实战语料)

> voice_confidence: medium — DevOps 一手材料多为书面文章而非访谈逐字稿, 且 research 受"引用 < 30 字"约束, 故多数样本标 (转述) 而非 (原话)。SKILL.md §5 主风格输出部分靠 LLM 默认补足, 见 §8 诚实边界。

#### 5.4.1 客户 / 面向利益相关者版 (面对 CISO/产品/管理层解释)
- 「我们不该追 100% 可用 — error budget 把可靠性变成一个共享的产品决策: 预算没烧光就继续快速发功能, 烧光了我们就停下来集中修可靠性。99.9% 和 99.99% 对用户多半是无感的, 多出来的那个 9 是指数级成本。」(source: T01-S013, 转述, 场景: 向产品/管理层解释为什么不追 100%)
- 「Elite 团队部署更频繁 AND 失败更少 — 速度和稳定不是 trade-off, 这是 DORA 四年两万多份数据的反直觉结论。所以你们故障多, 答案不是少发布, 是把批量拆小、加自动回滚。」(source: T01-S003, 转述, 场景: 反驳"少发布更安全"的管理层直觉)

#### 5.4.2 同业版 (私下 / 内训 / 同业讨论)
- 「If it hurts, do it more often, and bring the pain forward — 发布痛就更频繁地发, 把痛提前。攒大批量一次发才是最危险的。」(source: T01-S016, 原话, 场景: CD 名言, 同业内训)
- 「这告警 actionable 吗? 不 actionable 的 page 就是噪音, 噪音多了人就麻木静音, 然后真事故被淹。page on symptoms users feel, not on causes。」(source: T01-S012, 转述, 场景: 同业讨论告警治理)
- 「SharpHound 全 collection 在现代 EDR 秒级被抓 — 别偷懒, 写 targeted ldapsearch。」对应到 SRE 语境: 「别手写裸 YAML 在集群里 apply, 走 GitOps, drift 它自己纠。」(source: T03-S011, 转述, 场景: 同业 code review)

#### 5.4.3 事件战时 / 复盘专业版 (事件指挥 + postmortem register)
- 「Who's IC? 现在只做一件事: 先止血。回滚还是切流量? root cause 留到复盘, let's not fix and learn at the same time。Scribe 把时间线记下来, Comms 去挡客服和高管。」(source: T03-S009, 转述, 场景: 事件战时拉群)
- 「这次复盘是 blameless 的 — 我们找贡献因素不找背锅的人。问题不是这个工程师误删了库, 是系统让他能在生产主库上误操作、而且备份从来没验证过恢复。blameless ≠ 没人负责, 是改流程不是开除人。」(source: T01-S027, 转述, 场景: GitLab 2017 式复盘主持开场)

#### 5.4.4 反例版 (资深人绝不会这样说的话 / 被错位包装的话术)
- 「我们要 100% 可用性, 加个 DevOps 团队专门负责发布, 先上 K8s + service mesh + multi-cloud 显得专业。」(source: T06 outsider-tell, why 反例: 三连外行破绽 — 100% 是错误目标 + DevOps 团队是新筒仓 + resume-driven 过度工程) [T06-S002, T06-S031]
- 「这个告警一直响先静音吧, 备份肯定没问题不用测, on-call 被叫醒扛一扛就行。」(source: T06 outsider-tell, why 反例: 静音=alert fatigue / 未验证备份=没备份 / on-call 可持续是管理伦理问题不是个人韧性) [T06-S004, T06-S005]
- 「买我们的 observability 三件套就有可观测性了, single pane of glass, AIOps 自动修复一切。」(source: T06 厂商话术拒绝, why 反例: observability 是能力不是 SKU 打包, 抽象不消除运维责任) [T06-S030]

---

## 6. 质量基准 + 反模式

### 6.1 什么算"好" — 4 条可验证基准
1. **可靠性是量化的产品决策, 不是 100% 口号** — 每个核心服务有 user-facing SLI + SLO + error budget policy (烧光的强制动作) + burn-rate 告警; SLI 是 symptom (用户感知) 不是 cause (CPU)。[T04-S001, T03-S001]
2. **变更小批量 + 渐进 + 可观测 + 可回滚** — 不可变制品 (非 latest) + 自动化测试门禁 + canary 指标门禁 + 一键回滚到上一个 digest + feature flag 解耦 deploy/release; 用 DORA 四指标度量但不当个人 KPI。[T04-S009, T03-S012]
3. **基础设施声明式 + GitOps + state 安全** — git 单一真相源 + 远程加密加锁 state + apply 前 plan review + policy-as-code 门禁 + 定时 drift 检测; 禁 ClickOps。[T03-S015, T04-S028]
4. **告警 actionable + 复盘 blameless + on-call 可持续** — 每条告警有人能立刻动作; 复盘找贡献因素 + action 带 owner + 闭环; on-call 合理轮值 + follow-the-sun + 告警必 actionable。[T04-S001, T03-S004]

### 6.2 反模式 — 11 条必避免 (工程伦理 anchor 不软化)

1. **追求 100% 可用** — 100% 是错误的可靠性目标, 把预算全耗在边际可靠性 = 牺牲功能速度; 错误预算是产品决策不是技术债 (盲目追 100% 是 anti-pattern)。[T06-S002, T03-S002]
2. **复盘指责个人 / "root cause 是某某人为失误"** — 归咎个人 = 工程师隐藏真相 = 下次更严重; 复杂系统无单一根因; blameless ≠ no accountability (系统/流程问责而非个人惩罚, 严防被误读为"出事没人负责")。[T06-S004, T03-S028]
3. **"少发布更安全" / 攒大批量一次发** — 低部署频率 = 大批量 = 更高 change failure rate + 更难定位; DORA 证明小批量高频 AND 更稳定, 不是 trade-off。[T06-S006, T03-S029]
4. **手工救火 / 英雄主义加班当美德** — toil 必须量化削减 (< 50% 时间) 是 mandate; 通宵救火文化是组织失败信号不是光荣。[T06-S003, T03-S005]
5. **"on-call 被叫醒扛一扛就行"** — on-call 可持续性是伦理 + 管理问题; 长期 burnout + alert fatigue + 周末被毁是管理失败不是个人韧性不够; 健康 on-call = 合理轮值 + 告警必 actionable + 补偿 + follow-the-sun。[T06-S004, T03-S032]
6. **把 terraform.tfstate 当普通文件 (本地/进 git/误删)** — state 含明文密钥 + 是危险操作面; 必须远程后端 + 加锁 + 加密 + 最小权限 + apply 前 plan review (类比手术前核对)。[T06-S036, T03-S016]
7. **设孤立"DevOps 工程师"岗位 / "DevOps 团队"** — DevOps 是消除 dev/ops 鸿沟的文化运动, 设一个夹在中间的 DevOps 团队 = 制造第三个筒仓 (Team Topologies 明确批判); 正确是平台团队提供自助能力 + 产品团队 you-build-it-you-run-it。[T06-S031, T04-S013]
8. **resume-driven development / 厂商锁定 / 过度工程** — 为 K8s 而 K8s、不需要 multi-cloud 硬上、小团队套大厂微服务 = 把简历需求当架构决策; 多数公司的可靠性瓶颈不是工具先进度而是基本功 (备份能否恢复 / 告警是否 actionable / 变更是否可回滚)。[T06-S031, T02-S060]
9. **告警不 actionable 还静音** — 长期"那个老响的告警先静音吧"是 alert fatigue 温床 + 漏报真事故; 告警必须基于 symptom + actionable, 否则删/降级。[T06-S005, T03-S032]
10. **把 monitoring 与 observability 对立营销 / 当三件套 SKU 买** — monitoring (known-unknowns) 与 observability (unknown-unknowns) 是层次不是对立; 厂商窄化成"三件套打包"是营销, 但也别因此否定 metrics 监控价值。[T06-S030, T03-S022]
11. **信 NoOps / "serverless 消灭运维" / "AI 取代 SRE" 过度营销** — 抽象层上移不消除运维责任只改变形态 (serverless 仍需 SLO/可观测性/成本/冷启动/供应商风险管理); 标边界, 不否定 serverless 在合适场景的价值。[T06-S030, T06-S008]

> **反例 (工程教训 + 技术批评, 不入嘲讽当事人)**: Knight Capital 2012 (手工部署漏一台 + 复用废弃 flag + 无 kill switch, 45 分钟亏 4.4 亿美元破产 — 教训: 全自动化部署 + flag 生命周期管理 + 必备 kill switch) / GitLab 2017-01-31 (误删生产主库 + 5 层备份全失效, 全程直播恢复 — 教训: 备份必须验证恢复 + 危险操作防呆; 直播恢复本身是 blameless 文化示范) / AWS S3 us-east-1 2017 (一条命令 typo 多删服务器 — 教训: 危险操作要防呆 + 预览) / Cloudflare 2019 (一条 WAF 正则灾难性回溯 100% CPU 全球宕机 — 教训: 规则变更要灰度) / Facebook 2021-10-04 (BGP 撤回 + 内网 DNS 自锁连物理门禁都进不去 — 教训: 带外管理通道 + 依赖环识别)。这些标 secondary 仅用于反模式 + 韧性教学, 强调系统设计教训不嘲讽 [T03-S030, T03-S004, T03-S016, T03-S025, T03-S010]。

---

## 7. 智识谱系

DevOps & SRE 行业 4 个主要学派 (保留分歧而非抹平):

1. **流派 A — Google-SRE 工程纪律派 (bottom-up)**: 奠基 = SRE Book + Workbook + Building Secure & Reliable Systems (sre.google 三部曲); 创立者 Benjamin Treynor Sloss (2003 创 Google SRE); 当前代表 Niall Murphy / Betsy Beyer / Liz Fong-Jones / Alex Hidalgo。**特征**: 可靠性是软件工程问题, SLO/error budget/toil 量化, bottom-up 工程纪律。[T04-S001, T04-S002, T04-S032]
2. **流派 B — DevOps 文化运动派 (top-down)**: 奠基 = 10 Deploys Per Day (Allspaw/Hammond 2009) + DevOpsDays (Debois 2009) + Phoenix Project + Continuous Delivery + DevOps Handbook + Accelerate; 当前代表 Gene Kim / Jez Humble / Nicole Forsgren / Patrick Debois。**特征**: 消除 dev/ops 鸿沟的文化 + 三步法 + DORA 度量, top-down 组织变革。[T04-S008, T04-S009, T04-S012, T04-S043]
3. **流派 C — 韧性工程 / 安全科学派**: 奠基 = How Complex Systems Fail (Richard Cook) + Sidney Dekker 安全科学 + Principles of Chaos + Release It!; 当前代表 John Allspaw / Nora Jones / Lorin Hochstein / Casey Rosenthal (Learning from Incidents 社区)。**特征**: 从认知/安全科学借鉴, 关注 human factors / 复盘深度 / 混沌实验, 把可靠性当社会技术系统问题。[T04-S020, T04-S025, T04-S031, T01-S027]
4. **流派 D — 平台工程 / DevEx 派 (较新)**: 奠基 = Team Topologies + 12factor + CNCF 云原生生态 + Backstage; 当前代表 Skelton/Pais (产品化) / Kelsey Hightower (简约主义)。**特征**: 平台即产品 + golden path + 认知负荷管理, 是 DevOps 文化派的组织落地形态。[T04-S013, T04-S014, T01-S033]

**保留的核心分歧 (不抹平)**:
- **可靠性认识论之争**: DORA 可度量学派 (B 派 Kim/Humble/Forsgren — "root cause 存在且可度量, 用统计/指标驱动改进") vs 韧性工程派 (C 派 Allspaw/Cook — "没有单一 root cause, 只有贡献因素; 度量永远抓不住真实工作, 人是适应来源")。两者不对立但侧重相反: 前者信"度量带来改进", 后者信"度量永远抓不住真实工作"。[T04-S009 vs T04-S020]
- **SRE vs DevOps 是否同一回事**: A 派 (Google bottom-up 工程) vs B 派 (top-down 文化), 业内长期争论, 主流共识"SRE 是 DevOps 的一种具体实现 (class implements interface)"。[T04-S001, T04-S008]
- **平台抽象的度**: 简约主义 (Hightower 反 K8s 滥用) vs 平台工程产品化 (Skelton+Pais 建平台团队 + IDP) — 在"该建多重的平台"上有张力。[T01-S020 vs T01-S033]
- **可观测性范式**: observability 2.0 / wide events 单一真相源 (Majors) vs 三支柱务实派 (传统 metrics/logs/traces 厂商生态); Sridharan 居中偏批判三支柱框架。[T01-S009 vs T02-S027]
- **混沌主动注入 vs 事件被动萃取**: Rosenthal (生产受控实验) vs Nora Jones/Allspaw (从已发生事件学习) — 同属韧性但方法论方向相反。[T01-S035 vs T01-S037]
- **"DevOps 团队"是否反模式**: Team Topologies 明确批判设独立 DevOps 团队制造新筒仓, 但行业大量岗位仍叫此名 (canon vs 现实张力)。[T04-S013]
- **数据库/有状态服务该不该上 K8s**: DBRE 谨慎, K8s 生态乐观, 仍未定论。[T04-S034, T04-S035]

---

## 8. 诚实边界

1. **不替代真人 + 真环境**: 本 skill 是 DevOps/SRE 认知操作系统 + 决策框架, **不替代** 客户 specific 环境知识 + 实际 hands-on 经验 + on-call 实战 + 组织 specific 的 error budget policy 谈判。AI 不能直接 execute 生产变更, 只能协助决策 / 设计 / 复盘 / 学习。

2. **信息截止 2026-05-19, 工具/工作流衰减最快**: 工具栈 + 工作流模块衰减最快, 建议每 3-6 月跑 update。**最易过期处**: chaos 工具链 (chaos-as-CRD + 安全混沌,唯一 high decay workflow) / 可观测性成本架构 (ClickHouse·OpenObserve 列存回流, decay high) / profiling 第四支柱 (Pyroscope·Parca) / SLSA Source·Dependencies track (仍草案, high) / Opsgenie EOL 2027 + Spinnaker 份额下滑。**稳态可信赖**: 事件响应 (IC/SEV 数十年 ICS) + 无指责复盘 (1998 Cook + 2009 Allspaw) + SLO 第一性原理 (low decay)。

3. **zh-CN figures 维度结构性偏弱**: 最有分量的 zh-CN figure 陈皓 (左耳朵耗子) 已于 2023-05 离世、无新增动态; 在世 zh-CN 一手 (倪朋飞/张磊/石雪峰等) 主要是极客时间课程作者而非自洽思想家, 且其内容主平台 (知乎/微信公众号/CSDN/掘金/51cto/cnblogs) 全在黑名单。中国一手只能靠 CoolShell 存档 + 极客时间 + InfoQ 中文 + 大厂技术团队博客 (美团/字节) surrogate, 不是主战场 (intake locale=en)。

4. **一手率 ~94% 但多为 surrogate_primary (域名规则产物, 非数据薄)**: source_verifier 不把 .io/.com/.org/.dev/.google 当 primary (仅 .gov/.edu/.org.cn + github.com/{org}/{repo} root + dora.dev/research + cacm.acm.org/research.google + cloud.google.com/blog + kubernetes.io + developer.hashicorp.com 自动 verified)。故几乎所有 DevOps 一手 (sre.google / charity.wtf / itrevolution.com / teamtopologies.com / principlesofchaos.org / 12factor.net / brendangregg.com 等) 都标 surrogate_primary + note 含 "vendor docs" / "协会"。这些**全部是作者/出版社/协会的第一手** (Google SRE 官方全文 / IT Revolution 出版社 / O'Reilly 书页 / 作者个人博客 / CNCF·USENIX·Linux Foundation 协会), 是规则结构性产物不是真实一手性弱。

5. **mental model claim 多源自机构一手, 建议交叉对照**: 多数心智模型 claim 源自 Google SRE / DORA / CNCF / Honeycomb 等机构/厂商一手, 而非独立第三方; 二次校验时建议交叉对照 textbook (Accelerate / SRE Book / How Complex Systems Fail) 与韧性工程派 (避免单一机构立场)。

6. **voice_confidence: medium**: DevOps 一手材料多为书面文章而非访谈逐字稿 + research 受"引用 < 30 字"约束, 大量 voice sample 标 (转述)/(推断) 而非 (原话); §5.4 对话样本库 4 类 × ≥ 2 段达标, 但多数 (转述)。SKILL.md §5 主风格输出部分靠 LLM 默认补足而非纯真行业语料, 用户应回溯 source_id 校验。

7. **每个数字/%/$都带来源或 caveat**: 本 synthesis 所有 `%` / 具体数字 / 价格均带 source_id 或标注 (DORA 数据)/(Google SRE)/(业内估)/(业内 benchmark)/(CNCF Survey) — 无裸编的统计。Knight Capital 4.4 亿美元 / 99.9% ≈ 43 分钟·30 天 / Datadog custom metrics 30-50% 账单 / OpenObserve 60-98% 降本等均已挂源或标 caveat。

---

## 9. Agentic Protocol — 研究维度

> DevOps/SRE 工程师拿到一个新系统/新组织/新问题, 标准做功课的 7 个研究维度。互斥不 overlap, 各自独立产出不同结论。Phase 3 cli_writer.py 会把每个维度编排进 `cli/protocol/agentic.sh`。

### 9.1 可靠性目标与错误预算现状
- **看什么**: 核心服务是否有 user-facing SLI + SLO + error budget policy; SLI 是 symptom (成功率/p99) 还是 cause (CPU); SLA (对客户合同) 与内部 SLO 的关系; 是否有"烧光怎么办"的强制动作; 是否在追 100% / 拍脑袋 99.999%; budget 是否真驱动 dev/SRE 决策还是装饰。
- **在哪看**: 现有 SLO dashboard (Grafana/Datadog) + error budget policy 文档 + SLA 合同条款 + 询问"上次 budget 烧光发生了什么"; 对照 Google SRE Book Ch3-4 + Implementing SLOs (Hidalgo) + Art of SLOs workshop。
- **输出格式**: SLO 覆盖清单 (哪些服务有/无) + SLI 质量评估 (symptom vs cause) + error budget policy 有效性 (有强制动作? 真执行?) + 100%-追求 / vanity-SLI 红旗清单 + 第一份/改进 SLO 建议。

### 9.2 部署/交付管线成熟度 (DORA 四指标)
- **看什么**: 部署频率 / 变更前置时间 / 变更失败率 / 恢复时间 (MTTR) 四指标现状; 是 trunk-based 小批量还是长命分支大合并; 制品是否不可变 (非 latest); 有无自动化测试金字塔门禁 + 渐进式发布 (canary/blue-green) + 自动回滚 + feature flag (deploy ≠ release); 四指标是否被当个人 KPI (Goodhart)。
- **在哪看**: CI/CD 配置 (GitHub Actions/GitLab CI/Argo) + 部署日志/制品库 + 询问"上次回滚怎么做的、多久" + DORA 自评 (dora.dev) + 对照 Accelerate / Continuous Delivery。
- **输出格式**: DORA 四指标当前估值 + performer 分层 (elite/high/medium/low) + 管线 gap (无门禁?无 canary?无自动回滚?latest tag?) + "想少发布"的反模式红旗 + 小批量化改进路径。

### 9.3 可观测性覆盖与告警可用性
- **看什么**: 是 monitoring (预设 dashboard) 还是有 observability (能查 unknown-unknowns); RED/USE 方法是否落地; metrics+logs+traces 三信号是否齐 + 结构化日志 + trace 串联; instrument 是否绑死厂商 SDK (vs OTel 中立); 仪表盘是围绕 user journey 还是堆主机指标; 告警是 symptom/SLO burn 还是 cause; 告警是否 actionable (有无 alert fatigue / 长期静音); telemetry 成本 (custom metrics 基数爆炸?)。
- **在哪看**: Prometheus/Grafana/Datadog/Honeycomb 配置 + 告警规则库 + 询问"上次半夜被 page 是为什么、能做什么" + 账单 (Datadog custom metrics 占比) + 对照 Observability Engineering + RED/USE 原文。
- **输出格式**: 可观测性成熟度 (monitoring vs observability) + 三信号覆盖 gap + 告警 actionable 率评估 + alert fatigue 红旗 + 厂商锁定风险 (instrument SDK 绑定?) + telemetry 成本异常 + OTel 迁移建议。

### 9.4 事件/on-call 健康度与复盘文化
- **看什么**: 有无 IC 制 + SEV 定级 + runbook + status page; on-call 轮值是否可持续 (follow-the-sun? 告警量? 周末被毁?); 战时是否"先止血不 fix-and-learn"; 复盘是否 blameless (找贡献因素还是背锅? action 带 owner 闭环?); blameless 是否被误读为"没人负责"; 是否从事件学习 (LFI) 还是只算 MTTR。
- **在哪看**: PagerDuty/Opsgenie 排班 + 历史 postmortem 文档 + incident channel 记录 + 询问"上次 SEV 谁是 IC、复盘怎么开的、action 闭环了吗" + on-call 工程师访谈 (burnout 信号) + 对照 PagerDuty Incident Response + How Complex Systems Fail。
- **输出格式**: 事件流程成熟度 (IC/SEV/runbook 有无) + on-call 可持续性评估 (轮值/告警量/补偿) + 复盘文化评级 (blameless? action 闭环率?) + alert fatigue + burnout 红旗 + 伦理风险 (on-call 当个人韧性问题?) + 改进建议。

### 9.5 基础设施与变更安全 (IaC / state / 回滚)
- **看什么**: 基础设施是 IaC 声明式还是 ClickOps 手改; state 是否远程加锁加密 (vs 本地/进 git/明文密钥); apply 前是否 plan review (尤其 destroy); 有无 policy-as-code 门禁 + drift 检测; 是 GitOps (pull reconcile) 还是 CIOps (push); 部署是否不可变 + 可回滚 + 有 kill switch。
- **在哪看**: Terraform/OpenTofu/Pulumi 代码 + state backend 配置 + CI 的 plan/apply 流程 + GitOps 工具 (Argo CD/Flux) + 询问"上次误改/误删基础设施怎么恢复的" + 对照 Terraform Up & Running + IaC 变更 SOP。
- **输出格式**: IaC 覆盖率 (vs ClickOps) + state 安全评估 (远程?加密?加锁?进 git?) + plan-review 门禁有无 + GitOps vs CIOps 判定 + 危险操作面红旗 (tfstate 明文密钥/无 plan review/手改控制台) + state 安全纵深建议。

### 9.6 平台/认知负荷与团队拓扑
- **看什么**: 有无孤立"DevOps 团队"/"DevOps 工程师"夹在中间制造筒仓; 平台是否当产品做 (golden path / paved road / 自助 IDP) 还是强制管控; 产品团队是否 you-build-it-you-run-it; 团队认知负荷是否超载 (职责无限扩); 是否 resume-driven (小团队套大厂 K8s+mesh+multi-cloud); 工具/平台是否匹配团队规模与能力。
- **在哪看**: 组织架构图 + 团队职责文档 + IDP/Backstage 有无 + 询问"发布是谁负责、平台团队提供什么自助能力" + 工具栈复杂度 vs 团队规模 + 对照 Team Topologies。
- **输出格式**: 团队拓扑诊断 (有无 DevOps 筒仓反模式) + 平台成熟度 (产品化? golden path?) + 认知负荷评估 (超载?) + resume-driven / 过度工程红旗 ("真的需要 K8s 吗") + 团队拓扑重构建议。

### 9.7 成本/容量与供应链安全
- **看什么**: 云成本可见性 + 单位经济学 + rightsizing (vs 长期超配); 可观测性账单是否失控 (Datadog custom metrics); 容量规划是否有 headroom (vs 等 OOM 才扩); 有无负载管理 (load shedding/限流/熔断/优雅降级); 供应链安全 (SBOM/SLSA/签名/依赖扫描); 备份是否验证恢复 (RTO/RPO); 密钥管理 (Vault vs 明文)。
- **在哪看**: 云账单 + FinOps 工具 (OpenCost/Cost Explorer) + 容量 dashboard + CI 安全扫描 (Trivy/Dependabot) + 备份恢复演练记录 + 询问"上次验证备份恢复是什么时候" + 对照 AWS Builders' Library + SLSA 框架。
- **输出格式**: 成本健康度 (账单异常? observability tax?) + 容量规划评估 (headroom? rightsizing?) + 负载管理 gap (无限流/熔断?) + 供应链成熟度 (SBOM/SLSA 等级) + 备份恢复红旗 (验证过吗?GitLab 2017 教训) + 韧性模式建议。

---

## 元数据

- **Synthesis date**: 2026-05-19
- **Industry**: DevOps & SRE (industry_type: engineering_practice_global_en_primary_zh_cn_secondary; locale=en; profile=practitioner; focus: operational primary / technical secondary)
- **Source counts (six-track)**: 271 sources 总计 (T01 figures 55 / T02 tools 60 / T03 workflows 36 / T04 canon 44 / T05 sources ~38 / T06 glossary 38) — **94.1% first-hand** (verified_primary + surrogate_primary), 0 blacklist, 0 dead。一手率高度依赖 surrogate_primary (域名规则结构性产物, 见 §8.4, 几乎所有 .io/.com/.dev/.google DevOps 一手都标 surrogate + "vendor docs"/"协会"; verified_primary 主要来自 dora.dev/research + github root + honeycomb·brendangregg·verica·hashicorp 的 /blog·/author + cacm.acm.org·research.google + cloud.google.com/blog + kubernetes.io + developer.hashicorp.com)。
- **组件计数**: 7 心智模型 + 10 playbook (每条含 案例:) + 14 必备工具 + 7 类场景特化 + 6 新兴 + 7 分支决策树 + 8 避坑 + 8 完整 workflow (各含 skip/optimize/add) + 4 类对话样本 (≥ 2 段/类) + 4 质量基准 + 11 反模式 + 4 学派 + 7 保留分歧 + 6 诚实边界 + 7 Agentic 维度。
- **voice_confidence**: medium — DevOps 一手多书面文章非访谈逐字稿 + "引用 < 30 字"约束使多数 voice sample 标 (转述)/(推断) 而非 (原话); 仅 1 段 (原话, Jez Humble "if it hurts...")。§8.6 已明示主风格输出部分靠 LLM 默认补足。
- **工程伦理 anchor (不软化, 11 处全覆盖)**: 错误预算是产品决策非技术债 (§1.1, §6.2-1) / blameless ≠ no accountability (§1.3, §6.2-2) / 小批量高频 > 少发布 (§1.2, §6.2-3) / toil 量化削减非英雄主义 (§1.4, §6.2-4) / on-call 可持续是伦理 (§6.2-5) / terraform state 是危险面 (§1.7, §6.2-6) / "DevOps 团队"=新筒仓 (§6.2-7, §7) / resume-driven + 厂商锁定 + 过度工程严控 (§6.2-8) / 告警 actionable (§6.2-9) / monitoring vs observability 不对立营销 (§1.5, §6.2-10) / NoOps·serverless·AI 取代 SRE 过度营销 (§5.3, §6.2-11)。反例 (Knight Capital / GitLab 2017 / AWS S3 2017 / Cloudflare 2019 / Facebook 2021 BGP) 作工程教训不嘲讽 (§6.2 末)。
- **未解决的跨 track 矛盾 (保留, 供 Phase 2.5 review)**: 无阻断性矛盾。保留的是 §7 列出的**学派分歧** (这是 feature 不是 bug, 按 extraction-framework 要求保留而非抹平): (a) DORA 可度量学派 vs 韧性工程派对"root cause 是否存在/可度量"的认识论分歧 (B 派"存在且可度量" vs C 派"无单一根因, 只有贡献因素"); (b) SRE 与 DevOps 是否同一回事; (c) 平台抽象的度 (简约主义 vs 产品化); (d) 数据库该不该上 K8s。这些在 SKILL.md 中应中立呈现各派, 不和稀泥不背书一家。
