本文翻译自：https://martinfowler.com/bliki/DevOpsCulture.html
敏捷软件开发打破了需求分析、测试和开发之间的一些孤岛。 部署、运维和维护是与其他软件开发过程类似分离的其他活动。 DevOps运动旨在消除这些孤岛并鼓励开发和运维之间的协作。
DevOps已经成为可能，主要是由于新的操作工具和已建立的敏捷工程实践的结合[1]，但这些还不足以实现DevOps的优势。 即使使用最好的工具，如果你没有合适的文化，DevOps也只是另一个流行语。
DevOps文化的主要特征是增加开发和运维角色之间的协作。 在团队内部和组织层面，有一些重要的文化转变支持这种合作。
有共同责任的态度是DevOps文化的一个方面，鼓励更紧密的合作。如果系统交给另一个团队照顾，开发团队很容易对系统的操作和维护不感兴趣。如果开发团队负责在整个生命周期内管理系统，他们就能够分担运维人员的痛苦，从而确定简化部署和维护的方法（例如，通过自动化部署和改进日志记录）。他们还可能通过监控生产中的系统获得额外的ObservedRequirements。当运营人员分担系统业务目标的责任时，他们能够与开发人员更紧密地合作，以更好地了解系统的运营需求并帮助实现这些目标。在实践中，协作通常始于开发人员对运营问题（例如部署和监控）的认识提高以及运营人员采用新的自动化工具和实践。
需要进行一些组织变革来支持共同责任的文化。开发和运维之间应该没有孤岛。切换期和文档不能替代从一开始就在解决方案上合作。调整资源结构有助于操作人员尽早参与团队。让开发人员和运营人员共处一地可以帮助他们一起工作。交接和签字不鼓励人们分担责任并导致责备文化。相反，开发人员和操作人员都应该对系统的成功和失败负责。 DevOps文化模糊了开发人员和运营人员之间的界限，最终可能消除这种区别。将DevOps引入组织时，一种常见的反模式是为某人分配“DevOps”角色或将团队称为“DevOps团队”。这样做可以延续DevOps旨在打破的各种孤岛，并防止DevOps文化和实践扩散并被更广泛的组织采用。
另一个有价值的组织转变是支持自治团队。 为了有效协作，开发人员和运营人员需要能够做出决策并应用变更，而无需复杂的决策过程。 这涉及信任团队，改变风险管理方式以及创建一个不用担心失败的环境。 例如，为了部署到测试环境而必须生成用于签核的更改列表的团队可能会经常被延迟。 不需要这样的手动检查，可以依赖版本控制，这是完全可审计的。 版本控制中的更改甚至可以链接到团队项目管理工具中的票证。 如果没有手动注销，团队可以自动部署并加快测试周期。
转向DevOps文化的一个影响是，将新代码投入生产变得更容易。 这需要进一步的文化变革。 为了确保生产变化合理，团队需要将构建质量评估为开发过程。 这包括性能和安全性等跨职能问题。 持续发布技术（包括自测试代码）构成了允许定期，低风险部署的基础。
为了不断改进开发人员和操作人员以及系统本身的协同工作方式，团队重视反馈也很重要。 生产监控是一个有用的反馈循环，用于诊断问题和发现潜在的改进。
自动化是DevOps运动的基石，有助于协作。 自动化测试、配置和部署等任务可以让人们专注于其他有价值的活动，并减少人为错误的可能性。 自动化的一个有用的副作用是 自动化脚本和测试可以作为有用的、始终是系统最新的文档。 例如，自动化服务器配置可消除与SnowflakeServer相关的猜测，这意味着开发人员和运维人员同样能够了解和更改服务器的配置方式。
总结
本文概括起来讲了以下几点：
- DevOps的宗旨：消除开发与运维人员的隔阂，让大家一起合作；
- 共同责任：开发和运维人员都应该对系统负责，而不是推卸责任；
- 组织结构调整：打破开发和运维人员的界限；
- 自治团队：充分相信团队可以自己决定什么时候部署，而无需复杂的手续；
- 自动化：是DevOps的基础；
- 其他：更快的部署，系统的反馈也很重要；