什么是 DevOps 文化？

其实从这幅图中我们就能看到文化的影子。我们都知道 DevOps 强调打通开发团队与运维团队的壁垒，要求两个团队拉齐认知与责任，不再各自为战，而是一起为更快地交付更高质量的产品而努力。没错，这就是最基础的 DevOps 文化。

那么如何拉齐认知与责任呢？

首先可以确认的是，我们在组织架构上直接融合 Dev 和 Ops 团队，这并不是一个 DevOps 团队。人是不是坐在一起，改变的只是沟通的效率。这里我想强调两点：

责任共担，在一个 DevOps 模式组建团队里，每个人都需要为软件开发交付的整个生命周期而负责；

技能共享，通过持续学习，互相学习，让本是传统 Dev 的工程师学习 Ops 的技能，同时传统 Ops 的工程师也需要学习 Dev 的技能。

Dev 与 Ops 互相学习彼此领域技能，每个人都懂开发又懂运维，抱着“成长的观念”，持续学习，不满足于当前已掌握的技术栈。

但是我们也需要意识到不能要求每个工程师都精通开发与运维，这是不可能的。这里说的 Dev 掌握 Ops 能力，更多的是 Dev 能够借助完善的工具链从而掌握“应用运维”的能力，能够在自己完成开发之后，有能力和权限将应用部署上线，同时线上应用出问题后，能够直接对其负责，定位、修复、更新升级等。而一些基础设施的运维能力需要独立出来考虑，比如机房里的局域网配置、虚拟机挂 NAS 盘等传统运维能力。

同理 Ops 需要理解应用开发的生命周期，知道 Dev 的痛点，尤其是在流程上的痛点，比如怎样提升应用的构建速度，怎样优化应用的 cd 流程等，Ops 要关注应用的“生产过程”，进而发力去优化这个过程或相应的工具，让应用能够更可靠更快速地完成 cicd 流程等，更容易地部署上线或者对外交付。也就是说我们并不是要求 Ops 也去写业务代码，而是协助 Dev 去解决业务代码之外的痛点，让 Dev 能够更加专注于业务功能实现。

最后，一个 DevOps 模式组件的团队中每个人都为整个软件研发生命周期的速度和质量负责，每个具体的角色就像一个大头钉，底部很宽，代表着技术面广，关注整个软件研发生命周期的所有环节；同时顶部很高，在某个环节里专注，做好做精。

DevOps 成功落地的关键是什么？

我们前面说到的“其乐融融”的场景，我们希望 Dev 和 Ops 能够互相学习，共担责任，一起为更快更好地交付产品而努力。但是，工程师们为什么要这样做？他们的动力在哪里？