DevOps 转型，只有工具怎么够！

敏捷软件开发已经打破了需求分析、测试、开发之间的壁垒。在软件开发流程中，开发与运维之间面临着相同的隔离问题。DevOps运动的目标就是打破开发与运维之间的壁垒，鼓励开发与运维之间的协作。

新运维工具的出现以及敏捷工程实践的建立使得DevOps变成了可能[1]，但对于DevOps好处的认识还远远不够，即便拥有最好的工具，如果我们没有正确的文化，DevOps仅仅是一个时髦的词汇而已。

DevOps文化的基本特征是开发和运维角色之间的不断增强的协作。在团队级和组织级都需要文化的转变一支持这种协作。

责任共担是DevOps的团队文化之一，责任共担鼓励团队进一步的协作。如果系统运行与维护的工作交给了其他团队负责，开发团队一般都不会关心具体的运维工作。

当开发团队共同分担系统生命周期中的运维工作与责任时，开发团队就能理解运维团队的痛苦，就能主动简化开发和运维中繁琐的工作（例如：自动化部署和完善日志）。

他们也可以通过生产环境系统监控获取额外的需求。当运维团队主动承担系统的业务目标时，运维团队可以和开发团队更紧密的合作，以理解运维需求并提供支持。

在实践中，协作往往开始于开发团队意识到需要了解更多的运维工作（如部署和监控）或者是运维团队采用了新的自动化工具与实践。

责任共担文化也需要组织上的一些变化。开发团队和运维团队之间不应该有壁垒。在一开始，就不能依靠移交文档来代替一起工作。应该在组织资源结构上支持运维团队尽早地介入到产品交付过程中与其他团队一起工作。

将开发与运维团队放在一起，可以有效地促进他们一起工作。“移交和签收”无益于团队共同承担责任，并且会导致形成责备的文化。反之，开发和运维团队应该共同对产品的成功与失败负责。

DevOps文化模糊了开发与运维之间的界限，最终也将消除这种界限。在向组织中引入DevOps时，一种常见的反模式就是制作出一个DevOps角色或者DevOps团队。这样做只会造成更多的壁垒，并且阻碍DevOps文化和实践在更广泛的团队中传播和使用。

另一个有价值的组织变化是支持自组织团队，为了更高效的协作，开发与运维团队应该自主决策，在采纳变更时也不需要冗长的变更管理流程。这涉及到对团队的信任、对风险管理方式的变化，也需要创建不怕失败的环境氛围。

例如，一个团队需要列出变更清单并且获得一堆签字批准才能发布到测试环境，这些变更经常被推迟。我们应该依靠可审计的版本控制来替代大量的人工检查。在版本控制中的变更可以链接到团队的任务管理工具中，无需人工的签字批准，团队可以自动化部署变更，并缩短测试周期。

向DevOps文化改变的一个影响就是将代码部署到生产环境将变得很容易。这需要更进一步的文化改变。为了保证生产环境变更是可靠的，团队需要重视在开发过程中内建质量。这包括跨职能关注点，如性能和安全。持续交付技术（包括代码自测试）形成一个允许日常的、低风险的部署。

对团队而言，重视反馈也很重要，为了持续的推进开发与运维像一个团队一样工作，生产环境监控是一个很有用的反馈循环，它可以帮助诊断问题和发现潜在改进点。

自动化是DevOps运维的基石，它可以加快协作。自动化测试、配置、部署使得团队有更多的时间专注在其他有价值的活动中，并减少因为人为造成的错误。自动化脚本和测试的另一个好处是总是保证系统的文档是最新的。比如，自动化服务器配置意味着开发和运维团队都能了解并修改服务器的配置。

注：
[1]：运维工具包括虚拟化、云计算和自动化配置管理，在持续集成、增量设计、代码净化等工程实践中都支持这些工具。