2.4 DevOps 与持续交付思维

DevOps 不只是工具链。它是一种缩短“构建软件”和“运行软件”之间距离的方式。

旧的失败模式是：“开发把代码扔过墙，运维承受痛苦。”DevOps 用交付、可靠性、可观测性和恢复能力的共同责任替代这种模式。

持续交付关注可发布状态

持续交付意味着系统持续保持在可发布状态。它不等于每次提交都必须立刻推给所有用户。

健康的交付路径通常包括：

• 版本控制和清晰评审。
• 多层次自动化测试。
• 可重复构建的制品。
• 显式且可评审的环境配置。
• 数据库迁移检查。
• 预发布或预览环境。
• 功能开关或渐进发布。
• 监控、告警和回滚。

更深层的思想是小批量。变化越小，越容易评审、测试、发布、监控和逆转。

发布保护覆盖发布前和发布中。事故发生后，团队还需要知道第一步如何止损，以及事后用什么改进降低下一次风险。

可观测性会改变工程行为

日志、指标、链路追踪不只是运维团队的工具。它们会改变工程师的设计方式。

如果你知道一个功能必须在生产环境中被观察，你会问更好的问题：

• 对用户来说，成功是什么样子？
• 伤害出现的第一个信号是什么？
• 哪些错误是预期内的，哪些值得告警？
• 能否把生产症状连接回某次发布、请求、用户旅程或依赖？
• 谁会被通知，他们第一步该做什么？

DevOps 作为文化

工具有帮助，但文化决定工具是否真正有效。DevOps 文化重视共同所有权、快速反馈、自动化、从事故中学习，以及尊重运行现实。

问题不是“我们有没有 CI/CD？”更好的问题是“我们能否安全地改变生产环境，并从中学习？”