你有没有遇到过这种情况：CI 流水线挂了半小时，没有人发现，直到测试跑来问“包怎么还没出”？线上出了故障，靠用户截图才知道？发版完成了，群里吼一嗓子，结果该知道的人全错过了？
这些问题的本质都一样——你在该知道的时候，不知道。
这背后缺的是什么？不是监控。Prometheus 搭了，Grafana 大盘亮着，日志也收着。缺的是从“看见”到“行动”之间的那座桥——反馈。
一、DevOps 循环的两个版本
聊 DevOps 的人都见过这个环：Plan → Code → Build → Test → Release → Deploy → Operate → Monitor。这是流传最广的经典版本，带了一个独立的“运维”（Operate）阶段。
但本博客采用的导航结构是另一个版本：Plan → Code → Build → Test → Release → Deploy → Monitor → Feedback。
跟经典版本比，有两个区别。一是把“运维”去掉了——部署之后直接进入监控，因为我们讨论的 DevOps 实践中，运维不是独立阶段，而是贯穿在部署和监控之中。二是把经典版里隐式的“反馈”显式化——在 Monitor 之后、回到 Plan 之前，独立一个 Feedback 阶段出来。
这个博客的分类导航就是按这个顺序组织的：需求 → 编码 → 构建 → 测试 → 发布 → 部署 → 监控 → 反馈。本文是“反馈”分类下的第一篇。
二、为什么要把“反馈”单列出来
Monitor 之后，然后呢？监控系统看到了异常（CPU 飙了、错误率上去了、构建失败了），但谁来把 Monitor 看到的问题，变成相关人的行动？
这就是“反馈”。
“反馈”这个词，本意是一个系统接收信息后、将其返回以影响下一步行为。在 DevOps 里，反馈就是：把系统状态的变化，推送给需要知道的人，驱动他们做出决策和行动。
这里有一个重要的区别——在体系层面，我称它为“反馈体系”；在具体行为层面，就是“通知”。通知是反馈体系的手和脚，用来把消息送出去；而反馈体系是大脑，决定什么时候、什么情况、通知谁、怎么通知。
通知不做决策，它只是把信号送到人手里。做决策的是人。反馈体系的目标，就是让人能在正确的时间、拿到正确的信息、做出正确的决策。
三、一个常见的误解：反馈只在 Monitor 之后吗
需要说明的是，把 Feedback 放在 Monitor 之后只是环路模型上的位置，不意味着反馈只发生在监控阶段。实际上，反馈在整个 DevOps 循环中都存在：
- 编码阶段：Code Review 的评论就是反馈，驱动你修改代码
- 构建阶段：编译失败的通知就是反馈，告诉你代码有问题
- 测试阶段：测试报告的推送就是反馈，让你知道哪些用例挂了
- 发布阶段：发布单的审批结果就是反馈，决定了能不能上线
- 部署阶段：部署状态的通知就是反馈，告诉测试/运维可以开始验证了
- 监控阶段：线上告警就是反馈，让你知道系统出了问题
所以准确地说：反馈贯穿 DevOps 全程，但作为环路上的独立阶段，它特指把来自各环节的信号系统化地推送到正确的人、触发正确的行动。 这个独立阶段的存在，是为了让你不要只建了监控却忘了“通知到人”这最后一公里。
四、通知的三个通道
反馈体系的执行层是通知，目前 DevOps 场景下最常用的通知通道有三类：
| 通道 | 典型场景 | 优势 | 劣势 |
|---|---|---|---|
| 邮件 | 构建报告、发布公告、周报汇总 | 信息量大，可归档，跨平台 | 实时性差，容易沉没在收件箱 |
| 短信 | 线上 P0 告警、On-Call 唤醒 | 强制触达，不看手机也能收到 | 成本高，信息量有限 |
| 即时通讯 | 构建状态、部署通知、日常运维 | 实时性好，天然适合团队协作 | 依赖第三方平台，协议各异 |
这三者不是替代关系，而是互补关系。一个成熟的反馈体系，通常是三通道配合——日常走 IM，紧急走短信，归档和正式通知走邮件。
五、通知不是“发个消息”这么简单
刚开始做 DevOps 的时候，我也觉得通知就是“发个消息”——失败的时候发封邮件不就完了？
做久了才发现，通知这件事没那么简单：
- 通道选择：什么时候发邮件，什么时候发短信，什么时候走即时通讯？
- 内容设计：一封通知里该放什么信息？堆满日志别人不看，信息太少又没法定位问题。
- 送达保障：邮件进了垃圾箱怎么办？短信被运营商拦截怎么办？Webhook 超时重试怎么设计？
- 避免告警疲劳：一天收 200 条通知，再重要的事也会被忽略。
更麻烦的是，这些不是“选一个工具就行”的问题。它涉及协议基础（SMTP 怎么工作的？短信通道的协议是什么？Webhook 的推送模型是怎样的？），涉及集成方式（怎么在 Jenkins Pipeline 里发通知？怎么和飞书机器人打通？），还涉及团队规范（什么时候该通知谁？通知到什么程度？）。
六、通知在 CI/CD 流水线中的位置
以一条典型的 Pipeline 为例：
代码提交 → 编译 → 单元测试 → 静态检查 → 打包 → 部署到测试环境
│ │ │ │ │ │
└─────────┴────────┴─────────┴────────┴───────────┘
│
├── 失败 → 即时通知 + 邮件
├── 成功 → 即时通知（可选）
└── 部署完成 → 通知相关方
通知不应该只在“失败”的时候发。成功的构建也应该有记录（至少归档到邮件），部署完成后应该通知测试团队可以开始验证了。关键是不同事件走不同通道、发给不同人——这叫通知策略。
七、这个系列的计划
这个系列计划写 5 篇文章，从通道基础到体系设计，逐步讲清楚 DevOps 中的反馈体系：
| # | 文章 | 内容 |
|---|---|---|
| 一 | 概述（本文） | 什么是反馈体系、通道概览、系列总览 |
| 二 | 邮件通知 | SMTP 协议基础、邮件模板设计、Pipeline 集成 |
| 三 | 短信通知 | 短信通道接入、DevOps 场景下的告警设计 |
| 四 | 即时通讯通知 | 飞书/企业微信机器人、Webhook 原理与实战 |
| 五 | 通知策略设计 | 通知分级、避免告警疲劳、DevOps 通知规范 |
小结
反馈这件事，做浅了就是“配个 Webhook 发消息”，做深了是一个需要认真设计的体系——选什么通道、发什么内容、什么时候发、发给谁、怎么保证送到。它处在 Monitor 和 Plan 之间，是 DevOps 循环从“看见问题”到“解决问题”的关键一环。
下一篇，我们从最古老的通道开始——邮件通知。聊聊 SMTP 协议是怎么回事，怎么设计一封有效的通知邮件，怎么把邮件通知集成到 Jenkins Pipeline 里。
每天前进一小步，就是一个新的高度！