DevOps 文化

敏捷软件开发已经打破了需求分析、测试和开发之间的一些壁垒。部署、运营和维护是其他一些与软件开发过程的其他部分分离的活动。DevOps 运动旨在消除这些壁垒，并鼓励开发和运营之间的协作。

DevOps 之所以成为可能，很大程度上是由于新的运营工具和成熟的敏捷工程实践相结合的结果 [1]，但这些还不足以实现 DevOps 的好处。即使拥有最好的工具，如果没有正确的文化，DevOps 也只是一个流行词。

DevOps 文化的首要特征是开发和运营角色之间加强协作。在团队内部和组织层面上，有一些重要的文化转变可以支持这种协作。

共同责任的态度是 DevOps 文化的一个方面，它鼓励更紧密的协作。如果将一个系统的运营和维护工作交给另一个团队负责，那么开发团队很容易对该系统失去兴趣。如果开发团队在其整个生命周期内都承担着维护系统的责任，那么他们就能够分担运营人员的痛苦，从而找到简化部署和维护的方法（例如，通过自动化部署和改进日志记录）。他们还可以通过监控生产环境中的系统获得额外的观察需求。当运营人员分担系统的业务目标责任时，他们就能与开发人员更紧密地合作，更好地了解系统的运营需求，并帮助满足这些需求。在实践中，协作通常始于开发人员对运营问题（如部署和监控）的意识增强，以及运营人员采用新的自动化工具和实践。

需要进行一些组织上的转变，以支持共同责任的文化。开发和运营之间应该没有壁垒。移交期和文档并不能替代从一开始就共同努力寻找解决方案。调整资源结构，让运营人员尽早参与到团队中来，这是很有帮助的。让开发人员和运营人员在同一个地点办公，将有助于他们进行合作。移交和签字会 discourage 人们分担责任，并助长了相互指责的文化。相反，开发人员和运营人员都应该对系统的成功和失败负责。DevOps 文化模糊了开发人员和运营人员之间的角色界限，并可能最终消除这种区别。在组织中引入 DevOps 时，一个常见的反模式是指定某人为“DevOps”或将某个团队称为“DevOps 团队”。这样做会 perpetuate DevOps 旨在打破的那种壁垒，并阻止 DevOps 文化和实践在更广泛的组织中传播和采用。

另一个有价值的组织转变是支持自治团队。为了有效地协作，开发人员和运营人员需要能够在没有复杂的决策流程的情况下做出决策并应用变更。这包括信任团队、改变风险管理方式以及创造一个不怕失败的环境。例如，一个团队如果必须为了部署到测试环境而生成一份变更清单以供签字，那么它很可能会经常被推迟。与其要求进行这种人工检查，不如依赖版本控制，因为版本控制是完全可审计的。版本控制中的变更甚至可以链接到团队项目管理工具中的票据。如果没有人工签字，团队就可以自动化他们的部署，并加快他们的测试周期。

向 DevOps 文化转变的一个影响是，将新代码投入生产变得更加容易。这需要进行一些进一步的文化变革。为了确保生产中的变更可靠，团队需要重视在开发过程中构建质量。这包括跨职能的关注点，如性能和安全。持续交付的技术，包括自测试代码，构成了允许定期、低风险部署的基础。

团队重视反馈也很重要，以便不断改进开发人员和运营人员的合作方式以及系统本身。生产监控是一个有用的反馈循环，用于诊断问题和发现潜在的改进。

自动化是 DevOps 运动的基石，它促进了协作。自动化测试、配置和部署等任务，使人们能够腾出时间专注于其他有价值的活动，并减少人为错误的可能性。自动化的一个有益的副作用是，自动化脚本和测试可以作为系统有用且始终最新的文档。例如，自动化服务器配置消除了与雪花服务器相关的猜测，这意味着开发人员和运营人员都能够平等地了解和更改服务器的配置方式。