DevOps 是闭环反馈系统，围绕计划、编码、构建、测试、发布、部署、运维、监控8个关键动作；持续交付聚焦测试通过到生产就绪的自动化与可控性保障。
DevOps 流程不是一条线性流水线，而是一个闭环反馈系统；它没有“标准阶段数”，但所有成熟实践都围绕 8 个关键动作展开：计划、编码、构建、测试、发布、部署、运维、监控——其中 持续交付（CD）特指从测试通过到生产就绪这一段的自动化与可控性保障。
Plan & Code：需求对齐和代码准入是CD成败的起点
很多团队把 持续交付 当成“写完代码自动上线”，结果卡在环境不一致或需求反复上。真实瓶颈常在前期：Plan 阶段没对齐验收标准，Code 阶段没强制执行分支策略或提交规范，后续所有自动化都会失焦。
- 必须用
Git管理代码，且采用GitHub Flow或GitLab Flow（非 Git Flow），确保每个feature分支可独立构建、测试、部署 -
PR提交必须关联需求 ID（如 Jira ticket），CI 流水线才可自动触发对应环境的验证 - 禁止直接向
main推送；所有变更必须经code review+ 自动化检查（SonarQube扫描 + 单元测试覆盖率 ≥80%）才允许合并
Build & Test：构建产物不可变，测试必须分层且可重放
Build 不是“编译成功就行”，而是生成一个带唯一标识、环境无关、可审计的制品（artifact）。一旦构建完成，它就不能再被修改——否则 Test 和 Deploy 就失去可信基础。
- 构建命令统一用
mvn clean package -DskipTests（Java）或npm ci --only=production（Node.js），禁用本地依赖缓存 - 测试必须分三层：
unit（秒级，开发本地跑）、integration（分钟级，CI 中运行）、e2e（需真实服务依赖，放在 CD 前置网关后） - 所有测试用例必须幂等；
test阶段失败即中断流水线，不许“跳过”或“忽略”
Release & Deploy：发布决策权必须收口，部署必须可灰度、可回滚
Release 是人为判断“是否具备上线条件”的关口，不是技术动作；Deploy 才是技术动作。混淆这两者，会导致“自动上线”失控。
-
Release阶段只做三件事：检查changelog、确认合规扫描（Trivy镜像漏洞、CheckovIaC 风险）、人工审批（钉钉/飞书机器人推送待签卡片） -
Deploy必须支持策略：蓝绿部署用Kubernetes的Service切换，金丝雀用Argo Rollouts控制流量比例，滚动更新必须设maxSurge/maxUnavailable - 每次部署生成唯一
release ID（如v1.2.3-20260128-1422），所有日志、指标、链路追踪都打标，便于快速定位问题版本
Operate & Monitor：监控不是“看仪表盘”，而是驱动下一轮 Plan 的输入
运维和监控数据如果不能反哺到 Plan 阶段，DevOps 就只是“快一点的瀑布流”。真正的闭环，是让 error rate、p95 latency、deployment frequency 成为下次迭代的硬性约束。
- 必须采集三类信号：
metrics（Prometheus）、logs（Loki + Promtail）、traces（Jaeger）；缺一不可 - 告警必须分级：
critical（影响核心交易）触发on-call，warning（延迟上升 20%）仅发企业群，info（部署成功）推给产品团队 - 每次线上
incident必须产出postmortem报告，并将根因归入下个sprint的backlog，否则流程就断了
