DevOps 不是装一条流水线

很多团队谈起 DevOps，第一反应是「我们要不要上一套 CI/CD」。工具当然必要，但把 DevOps 等同于装流水线，常常装好之后协作还是老样子：开发写完扔给运维，发布仍然像每月一次的赌博。

DevOps 的内核是一套共享目标的工作方式：开发、测试、运维对同一条交付流水线负责，谁写的代码谁负责到上线，质量在写代码时就被内建，而不是在上线前被人拦截。

流水线只是把已经正确的协作自动化，它不会替你修好那面墙。
本文核心知识点
  • 共同责任线上出问题，开发和运维一起面对，而不是互相甩锅。
  • 小批量每次只发一小步，出问题能在分钟级定位回滚。
  • 质量内建测试与扫描进流水线，不靠人临上线前拦截。
  • 不指责复盘问系统为什么让人犯错，而不是追究谁的责任。
  • 度量流动看前置时间与恢复时长，不看谁加班更多。
DevOps 示意：一堵正在崩解成发光粒子的半透明砖墙，两侧扁平小人隔墙伸手相握，外围环绕发光节点组成的环形持续交付光带，蓝色扁平插画
墙拆掉之后，代码从提交到上线不再需要翻越一道道交接。

拆掉开发与运维之间的墙

传统分工里，开发在本地把代码写完，交接给运维部署上线，双方对彼此的环境和约束几乎一无所知。这面墙的代价很直接：上线像开盲盒，回滚靠手气。

  • 开发不了解部署方式与线上监控，出了问题只能等运维查日志。
  • 运维不了解代码结构与业务逻辑，只能靠经验判断该不该放行。
  • 本地、测试、线上环境不一致，「我本地是好的」成为最常见的推诿。

拆墙不是让开发去背服务器，而是让双方对同一张看板、同一份告警、同一个上线流程负责。开发有权看到自己代码的运行状态，运维有权要求发布满足自动化的准入门禁。

小批量、高频次地发布

一次发布几百个改动，出问题几乎没法定位；一次发布一个小特性，出问题几小时就能定位、敢回滚。批次越小，每次发布的风险就越可控。

发布方式单次批次出问题时团队心理
月度大发布几百个改动难定位、不敢回滚发布日如临大敌
每周发布几十个改动半天内可定位逐步平常心
持续发布单个提交分钟级定位回滚发布成为日常

高频发布的前提不是胆子大，而是自动化测试与灰度能力托底。没有它们，高频只是把风险放大成高频事故。

让每个提交都随时可发布

「可发布」不该是一个特殊节点，而应该是任何一个主分支提交的默认状态。做不到这一点，发布才需要反复彩排和人工把关。

# 每次提交自动走完一条流水线（示意，按注释理解）
lint            # 静态检查：风格与可疑写法
unit-test       # 单元测试：新增逻辑必须有覆盖
build           # 构建产物并固定版本号
scan            # 依赖与镜像漏洞扫描
staging-deploy  # 自动部署到预发环境
smoke           # 关键链路冒烟用例

# 以上全部通过才允许合并到主干；
# 主干因此永远处于「可以发布」的状态。

当任何一个提交都能安全上线，发布就从一场需要排期、需要评审、需要领导批准的仪式，变成一个随时可以执行的普通操作。

失败是系统问题，不是人的问题

线上出故障之后，最忌讳的是第一时间问「是谁点的按钮」。人都会犯错，成熟的系统应当让错误在变成事故之前就被拦住，而不是依赖每个人时刻保持紧张。

  • 把危险操作做成需要双人确认或必须经过流水线，而不是靠人记住。
  • 用灰度与自动回滚把单次发布的影响面控制在很小范围内。
  • 故障复盘只问「系统哪里还能改进」，不点名批评具体的人。

blameless 的复盘文化，让人敢于在风险刚冒头时就喊出来，而不是藏着掖着，等到它变成一次真正的事故。