DevOps

DevOps 起初是对一种特定功能失调的回应：开发人员把代码越过一堵墙扔给一个独立的运维团队，出问题时运维被指责，而编写软件与运行软件之间的反馈回路被打断了。DevOps 弥合了这个回路。构建软件的团队也负责交付和运行它，运行某物的痛苦会直接回流到能够修复它的人那里。

在实践中，这种文化由自动化来支撑：CI/CD 让改动安全且频繁地流入生产环境，持续交付的纪律让每一个构建都是可发布的，基础设施即代码让环境可复现而不是手工搭建的「雪花」，可观测性（日志、指标、追踪、告警）让团队看清生产环境实际在做什么。这些工具单独哪一个都不是 DevOps。它们是让这种文化得以存续的东西。

「DevOps 工程师」这个职位头衔在很大程度上是个误称，而且很说明问题。DevOps 不是一个你雇来坐在开发和运维之间的角色，那只是用一个新名字重建了那堵墙。大多数「DevOps 工程师」招聘实际想要的，是一名构建其他开发人员所用自动化的平台或基础设施工程师。人有用，标签贴错了。如果你的组织有一个负责部署、好让开发人员不必动手的 DevOps 团队，那你拥有的是换了招牌的运维，而不是 DevOps。

「你构建它，你运行它」按设计意图奏效的样子，举个实际例子：一名工程师周四上线了一个改动，周五凌晨两点因为它引起一处缓慢的内存泄漏而被呼叫，于是在凌晨那几个小时里修自己的代码。那种难受只发生一次。它同时也是史上最有效的代码评审制度，因为那名工程师再也不会上线那一类 Bug，而且下一次设计东西时，他会去想它在凌晨两点的表现。当一个独立的运维团队替他吸收掉那份痛苦时，那个本来能阻止下一次泄漏的人，永远感受不到上一次的后果，于是同样的错误会无限期地复发。呼叫不是惩罚，它是反馈回路。

Wavect 的看法：DevOps 是一种工作方式，而不是一个部门。我们构建那种让小团队能够端到端地负责自己软件的自动化，并把「你构建它，你运行它」当作默认值。看看我们的全栈开发工作，了解这在实践中如何展开。