第 11 章 DevOps 与持续交付学习目标理解 DevOps 的文化内核与闭环思想掌握 CI/CD 流水线的阶段与门禁了解容器化、基础设施即代码(IaC)的基本概念掌握发布策略(蓝绿、金丝雀、特性开关)理解可观测性(日志/指标/追踪)与 SRE 的可靠性工程熟悉 DORA 四大指标掌握事故管理与复盘方法11.0 为什么交付之后也是工程传统过程在交付处画句号:开发交钥匙,运维接盘子,两个团队两套激励(开发要快,运维要稳)。结果是:上线是大事件(季度一次),风险集中爆发;线上问题不是我的锅(开发/运维互相甩);生产反馈回不到需求,系统无法基于真实使用进化。DevOps 的回答:把运行期纳入工程过程,用自动化压缩反馈时延,用共享指标统一激励。第 2 章说的生命周期闭环在这里落地。11.1 DevOps 的本质DevOps ≠ 一套工具,而是文化 流程 度量的组合:文化:打破开发/运维部门墙,“你构建,你运行”(You build it, you run it);共享指标、共享责任;流程:自动化一切可自动化(构建、测试、部署、回滚);闭环:生产反馈(监控/日志)回流为需求与改进输入,生命周期从线变环(呼应第 2 章)。核心张力:开发要快变,运维要稳定。DevOps 的解法不是牺牲一方,而是用自动化与可观测性让快不再必然不稳。文化落地的三个抓手(不靠喊口号):共享值班:开发轮值 on-call,直面线上;共享指标:速度与可靠性同一张 DORA 看板,不分开考核;事故共担:复盘对事不对人,改进项由开发执行(因为他们最懂)。11.2 CI/CD 流水线持续集成(CI)定义:开发者频繁(每日多次)将变更合入主干,每次合入自动触发构建 测试。纪律:主干常绿:构建失败 全员最高优先级修复(先修主干,后写新功能);合入门禁:lint 单测 集成测试全绿;构建快:目标 10 分钟反馈(超时则并行化/缓存)。构建提速手段:手段效果测试并行(分片)线性缩短增量构建/缓存依赖去掉重复劳动测试分层触发(先快后慢)早失败早反馈只跑受影响测试(变更分析)大仓库关键持续交付/部署(CD)持续交付(Continuous Delivery):任何时刻都有可发布的制品,发布是手动触发的受控动作;持续部署(Continuous Deployment):通过所有门禁后自动上线,无人工步骤。选 CD 还是 CDeploy(持续部署)的判断:自动部署适合:流量可金丝雀、数据迁移向后兼容、回滚 5 分钟、无合规发布窗口;保留手动触发(OOS 选择):有业务发布窗口(大促冻结)、需要人工确认的合规发布、数据迁移需 DBA 把关。流水线阶段(典型)提交 → 拉取构建 → 静态分析 → 单元测试 → 构建制品(不可变) → 制品入库 → 集成/契约测试 → 部署到预发(Staging) → 系统/E2E 测试 → 部署到生产(策略化) → 冒烟验证 → 监控观察每个阶段是门禁:失败即阻断,并通知责任方。流水线设计原则:阶段耗时预算化(单阶段超时即失败,防挂死);慢阶段(性能/安全)异步并行,不阻塞主链;预发环境 生产缩容版(同镜像、同配置模板、1:10 数据);流水线配置即代码(第 7 章),改流水线走 PR。关键工程实践不可变制品(第 7 章):测试与部署的是同一个制品;环境一致性:开发/预发/生产用相同镜像与配置模板,消灭在我机器上是好的;配置与代码分离:配置按环境注入,不硬编码;一切可回滚:每次发布记录制品版本 配置版本 数据迁移版本。11.3 容器化与基础设施即代码容器(Docker/OCI)应用 依赖打包为镜像,跨环境一致;编排(Kubernetes):调度、扩缩容、自愈、滚动更新;价值:环境一致性 弹性扩缩容 标准化部署单元。容器化纪律:镜像用 digest 定址(第 7 章不可变三环节);基础镜像版本化并定期升级(安全补丁);一个镜像一个职责,不塞全家桶;健康检查探针(存活/就绪)必须定义,否则编排自愈失效。IaC(基础设施即代码)服务器/网络/数据库用声明式代码描述(Terraform/Ansible);基础设施进版本库、可评审、可复现、可回滚;手动改生产配置被视为事故而非日常。IaC 检查单:所有环境(含测试)由代码生成,无手工资源;变更走 PR 评审 plan/apply 审计;状态文件受版本与权限保护;密钥不进代码库(专用密钥管理);漂移检测:定期实际 vs 声明比对,漂移即告警。11.4 发布策略策略机制回滚成本适用直接发布停机或滚动替换中(需重新部署旧版)小型、可接受短暂中断蓝绿部署两套完整资源环境,流量一键切换低(切回蓝)可承受双倍资源金丝雀(Canary)小比例流量(如 5%)先上新版,观察指标后逐步放量低(停放量)高风险变更、大流量系统(OOS 采用)特性开关(Feature Flag)代码已上线,功能按开关/人群渐进暴露极低(关开关)功能级风险隔离、A/B分批/滚动按实例/地域逐步替换中通用金丝雀决策指标:错误率、P99 延迟、业务关键转化(下单成功率)——任一越阈值自动回滚。金丝雀放量剧本(OOS 模板):阶段0: 制品晋级至生产金丝雀池,5% 流量,观察 30 分钟 通过标准: 错误率 ≤0.3%、P99 ≤300ms、下单转化无劣化 阶段1: 25%,观察 2 小时(覆盖一个业务高峰) 阶段2: 50%,观察 4 小时 阶段3: 100%,旧版本保留 24 小时热备 任一阶段失败: 自动切回 5%→0%,告警 通知,MTTR 目标 15 分钟策略组合经验:金丝雀管版本风险,特性开关管功能风险,两者正交——版本用金丝雀放量,功能用开关灰度,大功能可以版本全量 开关 1% 用户起步。11.5 可观测性(Observability)三根支柱:支柱内容工具例日志(Logs)离散事件,结构化(含 traceId)ELK、Loki指标(Metrics)数值时序,聚合统计Prometheus、Grafana追踪(Traces)请求跨服务的完整路径与耗时Jaeger、OpenTelemetry可观测性 ≠ 监控:监控回答系统是否按预期(已知问题告警),可观测性支持从外部行为推断内部状态(未知问题定位)。实践:日志结构化 关联 traceId(一次下单全链路可查);告警基于症状(用户侧错误率)而非原因(CPU 高)——“用户无感的告警是噪音”;SLI/SLO/错误预算(见 11.6)。可观测性建设次序(资源有限时):先建 SLI(黄金指标:流量/错误/延迟/饱和度)看板;再建基于 SLI 的告警(症状导向);然后日志结构化 traceId(定位能力);最后分布式追踪(复杂依赖时)。跳过 1 直接上追踪 有了显微镜没有体检表。11.6 SRE 与可靠性工程SLI(指标):如下单请求成功率;SLO(目标):如30 天成功率 ≥99.9%;错误预算(Error Budget):100% − SLO 允许的失败额度(99.9% → 每月约 43 分钟不可用预算);预算充足 → 团队可自由追求新功能速度;预算耗尽 → 冻结功能,专注可靠性。用同一把尺子管理速度 vs 稳定的张力,替代部门博弈。SLO 设定纪律:从用户定义 SLI(下单成功率,不是进程存活率);SLO 要有依据(业务容忍度 历史基线),不是拍99.99;多 SLO 分层:核心链路 99.9%,非核心 99%;错误预算消耗速度是告警信号(如本周已耗 60%预警)。预算耗尽后的防永久冻结机制:冻结有期限(如 2 个迭代),到期强制复审;复审问题:可靠性根因修了吗?SLO 是否设得过高?允许预算重置条件(如连续 4 周零 S1 事故)提前解冻;极端情况:与业务共同下调 SLO(承认现实),记录在案——SLO 是承诺,不是信仰。混沌工程(Chaos Engineering):主动注入故障(杀进程、断网、延迟),验证系统韧性——把未知的脆弱变成已知的、可修复的脆弱。混沌实验设计要素(OOS 支付超时实验):假设: 支付网关超时 30s 时,下单主流程不受影响(熔断生效) 注入: 对支付网关调用注入 30s 延迟(仅金丝雀流量) 成功判据: 下单成功率 ≥99.5%;超时订单进入重试队列; 无重复扣款;告警在 5 分钟内触发 失败判据: 下单超时 / 队列积压 1000 / 无告警 回滚: 停止注入(秒级);观察 10 分钟无残留 窗口: 业务低峰;业务方知会11.7 DORA 四大指标指标含义参考水平(2024)部署频率(Deployment Frequency)多久发一次按需(分钟~小时)变更前置时间(Lead Time for Changes)提交到上线的时长1 小时变更失败率(Change Failure Rate)导致故障的发布占比5%恢复时间(MTTR)故障到恢复的时长1 小时四个指标应一起看:只追求部署频率而忽略失败率与 MTTR,是快而脆。DORA 的常见误读:不是 KPI(考核即扭曲,如为频率拆小发布制造伪部署);是系统属性不是人的属性(度量流水线,不度量个人);参考水平是世界级团队统计值,不是及格线——按趋势管理;四指标相关:失败率高的团队 MTTR 通常也长,改善往往联动。11.8 事故管理与复盘事故分级(与第 6 章缺陷分级衔接,但视角是正在发生):P1:核心业务中断/数据损坏 → 立即全员响应;P2:主要功能受损,有绕过 → 当班响应;P3:局部异常,用户可感知 → 排期处理。事故响应流程:发现(告警/用户) → 分级 → 组建作战室(指挥官执行记录) → 止血优先(回滚/降级,先恢复后定位) → 恢复确认 → 降级为 P3 跟踪根因纪律:止血优先于定位(为什么在复盘做,不在作战室做);指挥官只指挥不执行;全程时间线记录(自动生成优于人工)。无指责复盘(Blameless Postmortem):时间线(自动采集) 影响范围与持续时长 根因(5 Why,到系统/流程层为止,不停在某人疏忽) 为什么没被预防(对照第 9 章内建机制:哪层该拦没拦?) 改进项(≤5 条,每条有 Owner 期限 验收)有效性度量:改进项按期关闭率 80% → 复盘流程失效,比事故本身更危险。11.9 OOS 的 DevOps 落地(汇总)流水线:提交 → 构建单测静态分析(10min)→ 制品入库 → 预发 E2E → 金丝雀(5%→25%→100%)→ 冒烟;容器化 K8s 编排,大促前按 SLI 自动扩缩容;基础设施 Terraform 管理,环境一致性;SLO:下单成功率 99.9%(30 天),错误预算月度回顾;大促前混沌演练:随机杀支付网关连接,验证熔断与补偿;双周 DORA 看板:部署频率、前置时间、失败率、MTTR。上线 6 个月 DORA 实绩:部署频率 3 次/周、前置时间 4h、变更失败率 4%、MTTR 35min——对照参考水平:频率与 MTTR 达标,前置时间受业务发布窗口约束(手动触发,见 11.2),属有意识取舍而非过程缺陷(ADR-011 记录)。11.10 本章 FAQQ1:小团队(没有专职运维)需要 DevOps 吗?需要DevOps 纪律而非DevOps 组织:CI 门禁、不可变制品、可回滚、SLI 看板、事故复盘。五件事成本都很低,收益是小团队不背大系统的锅。Q2:上 Kubernetes 是 DevOps 的前提吗?不是。K8s 是编排工具,DevOps 是反馈时延与文化。单体 良好 CI/CD 可观测性的小系统,反馈循环可能比上了 K8s 但流程混乱的大系统健康得多。Q3:告警太多没人看,怎么办?三步:① 只保留症状导向告警(用户可感知的 SLI 越界),原因类降级为看板指标;② 每条告警有值班动作卡片(该做什么),无动作的告警删除;③ 目标:单值班人单日 5 条需响应告警。告警疲劳的代价(狼来了)高于漏报。Q4:持续部署会不会把 bug 直接推给用户?风险由金丝雀 错误预算 快速回滚管控,而非由人工审批管控。人工审批是一次性闸门,金丝雀是持续验证——后者对真实流量的覆盖更强。前提是你的 SLI 真的代表用户(11.6 纪律 1)。Q5:从零开始,团队 DevOps 的最小集是什么?五件事,按优先级:① CI 全绿作为合入门禁;② 不可变制品 制品库;③ SLI 看板 3 条核心告警(症状导向);④ 一键回滚(发布能退回上一版);⑤ 事故复盘模板 月度回顾。这五件到位,快而稳的地基就在了;容器、K8s、完整可观测性都可以等团队用得起来再上。顺序反了(先上平台后建纪律)是最常见的浪费。Q6:如何度量DevOps 做成功了?不数工具,看三个:① DORA 四项趋势(一起看);② 线上事故15 分钟内定位的比例(可观测性有效性);③ 需求中来自生产反馈的占比(闭环有效性)。第三项最容易被忽略,却是闭环与流水线的本质区别——生产数据没有变成需求输入,就还是传统流水线换了个更快的传送带。Q7:值班(on-call)与功能开发冲突怎么解决?轮值制(两周/轮) 值班期功能负载下调;值班质量指标(MTTR、误报率)反馈给引入问题的模块 Owner(不是考核,是谁修谁最快的效率逻辑)。核心原则:值班不是惩罚,是最短的反馈回路——轮值过的开发,写的防御代码和日志质量会肉眼可见地变好。附录 A:DevSecOps——安全左移阶段活动工具类型编码安全编码规范、依赖漏洞/许可证扫描SCA(Snyk、Dependabot)提交CI 中代码漏洞扫描SAST(Semgrep、CodeQL)构建镜像漏洞扫描、密钥泄漏检测(防 AK 入库)Trivy、gitleaks发布DAST 动态扫描、季度渗透测试OWASP ZAP、人工运行WAF、异常检测、应急补丁流程WAF、SIEM纪律:安全门禁分级(阻断高危/警告中危,与第 5 章门禁分级一致);高危漏洞 SLA:24 小时内阻断发布(CCB 接受风险除外,须留记录);密钥管理:密钥永不进仓库(扫描兜底),用专用密钥服务,定期轮换;安全事件复盘对照哪层上游门禁本可拦截(9.2 质量内建映射的安全版)——事件只修不查上游,等于买了一次性保险。附录 B:DevOps 落地常见坑坑症状对策工具主义买了一堆平台,流程照旧第 2 章:先过程后工具自动化表演自动化了不稳定 UI,维护成本 手工第 6 章层次纪律告警疲劳每天 50 条,没人看11.5:症状导向 动作卡片DevOpsDev值班全在运维,开发无责11.1:共享值班、共享指标SLO 崇拜纸面 99.99%,无预算机制11.6:SLO 必须配错误预算混沌表演为演示注入,无假设无判据11.6 混沌实验五要素绿分支幻觉主干绿,特性分支全红分支短命 每日同步冻结常态化“发布窗口半年一次”冻结有期限 到期复审使用方式:每季度对照本表自查一次,命中即立项改进(第 9 章 PDCA)。坑不会自动消失,它们等纪律。11.11 小结DevOps 是文化 流程 度量的闭环,核心是快而不脆;CI 主干常绿 构建提速手段;CD 与自动部署按判断标准选,OOS 保留手动触发;不可变制品 环境一致 配置分离 一切可回滚;容器化与 IaC 有纪律(探针/密钥/漂移检测);发布策略按风险选型,金丝雀有放量剧本,特性开关与金丝雀正交组合;可观测性建设有次序:SLI → 告警 → 日志 → 追踪;SLO/错误预算统一速度与稳定的张力,有防永久冻结机制;混沌实验 假设 注入 判据 回滚;DORA 四指标整体看、不考核;事故:止血优先,无指责复盘,改进项关闭率是流程健康度。思考题持续部署与持续交付的区别是什么?OOS 为什么选持续交付而非持续部署?金丝雀发布中,除了错误率与延迟,还应观察哪些业务指标?为什么?错误预算耗尽时冻结功能发布,如何避免永远在还可靠性债、永远不交付?设计 OOS 的支付网关超时混沌实验:注入方式、预期行为、成功判据、回滚预案。为你的系统定义 3 个 SLI 与对应 SLO,写出错误预算月度回顾会议程。按 11.5 建设次序评估你团队的现状:卡在哪一步?补上的最小成本是什么?写一次无指责复盘:选一个真实(或模拟)事故,产出 ≤5 条改进项(含 Owner、期限、验收)。DORA 四指标中,哪一个最难改善?改善它需要哪些其他指标配合?