软件无处不在。在如今的世界里，每个主流公司 / 组织都和软件开发息息相关，并且公司需要向软件一样运作。更快且更敏捷，同时保证安全性和可靠性，这样的要求前所未有的强烈。这样的压力通常体现为项目被取消或者被暂停。这正是 DevOps 尝试解决的问题：如何让企业内部的开发，运维和其他组织协作，达成一系列共同的目标，更快更可靠地向客户和终端用户交付软件？支持 DevOps 项目的核心技术实践包括让开发和运维团队为软件交互标准化一系列常见的敏捷流程和工具。这通常包括：
自动化的配置管理，测试和应用部署；
应用程序和基础架构代码的版本控制，助力协作和回滚；
CI（持续集成）自动化代码构建，并且通过更频繁，风险更低的版本带来更快的反馈和迭代。
DevOps 是文化的转变，是关于每个人如何以正确的方式参与到工作当中。在软件定义的世界里，出现了一系列问题。
我们如何让某些东西快速进入生产环境？我们怎么知道使用的是最佳方案呢？我们能多快地使用改进和更新？
DevOps 试图通过尽早地在交互型流程里涉及到所有人从而让大家都参与进来。达到 DevOps 的成功需要首先理解核心业务优势。企业能够更快地前进，下线时间更短，并且安全问题更少。
Mike Dilowrth，敏捷和 DevOps 转型领导者，最近说：
DevOps 是一种文化，不是角色！整个公司都需要参与到 DevOps 里才能成功。
DevOps 需要高级领导层的支持，也需要和最终产品相关的所有人的参与，而不仅仅是开发和运维部门。
我之前读过一篇 Puppet 的白皮书，关于如何构建高效的 IT 团队。其中开始部分就提出了一些有意思的理论和实践，这里我想分享给大家。
DevOps 和行业，公司规模以及技术环境密切相关。至少，在企业中领导过成功 DevOps 转型的 IT 经理们，总结时都认为，DevOps 指的是持续学习和改进的过程，而不是某种最终状态。
和很多 IT 领导者一样，你想要的不仅仅是交付前所未有的多的产品和服务，而且还要更快更好地交付——并且没有可靠性和安全性的问题。DevOps 看上去确实会有所帮助！但是……在真正开始之前，你就已经开始让团队产生怀疑了。
怎么才能为 DevOps 制定清晰，令人信服的场景，可以降低担忧，并且将怀疑转化为成功呢？
上面的问题是个良好的开始。构建业务场景是成功的 DevOps 转型的重要部分（特别是在大型企业里）。在一场有名的 TED 演讲里，Simon Sinek 认为伟大领导者和积极变化的催化剂的共同点是：
让人们信服的不是领导者在干什么，而是为什么要这么干。
在构建企业对 DevOps 转型的认同方面，也是同样的道理。简单宣布“我们要做 DevOps”并不会让大家真正开始。相反，你需要令人信服地回答这样的问题“为什么？为什么是现在？”。你的所有客户都希望速度更快并且不牺牲系统的可靠性和稳定性——在传统企业里这个目标直接自相冲突。开发人员的任务是尽可能快地让新特性上生产环境。同时，衡量运维团队的指标是在线时间和系统性能。因此这让团队之间变得对立而不是并肩作战。因此，生产环境的部署一直被延迟和错误所困扰，部署发生的频率比业务实际需要的频率低很多。
更快的部署和反馈回路正是开发人员想要的：代码可以更快地从他们的笔记本交付到用户手里，持续交付带来快速的迭代和改进。在早期 pilot 项目里跟踪变更时间的改进是个不错的开始：
代码从开发的笔记本到生产环境需要多久？
跟之前的时间相比，有什么改进么？（你是不是自动化了更多的构建流程？你有没有降低需要部署的 ticket 数量？）
现在和以前相比多久需要一次部署？
部署有没有变得更为容易并且更快了呢？
当开发人员和运维人员紧密工作时，运维人员会受益。可以从同意使用通用的工具链开始，让两个组的人采用相同的工具一起工作，在开发中集成，测试和部署基础架构代码。这样可以让开发人员更为积极地参与到部署和问题定位中，进一步打破以前的障碍，同时提高速度和可靠性。跟踪运维团队关心的度量矩阵将给整个团队带来好处——包括 Dev 和 QA：
在线 / 下线时间：是不是能够更好地达到服务级别的要求？下线时间减少了么？
变更失败率：故障是不是变少了？
恢复的平均时间：故障发生时，回滚到已知的最近的好状态，这样的回滚时间是不是减少了？
那么，如何开始度量这些 DevOps 的影响，并且支持自己的业务场景呢？从有特定任务和项目的小地方开始。Terri Potts （Raytheon 的杰出工程师 & 软件技术总监）认为这样的方案非常高效。
你无法一下子改变整个程序，但是可以让一些子团队开始尝试正确的方向。从外部引入一些人来自动化一些测试或者 build，会很有用，同时给团队一些实际的例子。
Raytheon 让他的一个团队从每个月两次集成转变为一个晚上运行 27 次，这是自动化了 build 后的结果。在单个项目里这是一个很大的成功，这也成为了 Portts 如何在企业内孵化 DevOps 的典型示例。
从小处开始，文化转型也要跟上——不要期望一开始就能让所有人都信服 DevOps。实际中，在特定项目的小型组织内赢得大家的支持，就赢得了会在公司其他地方帮助宣传 DevOps 的大使们，这会带来乘数效应。随着业务场景的构建，还需要清醒认识到要达成长期 DevOps 成功的可能会遇到的障碍。
本文首发于 Docker 公号，来源链接：https://mp.weixin.qq.com/s/P4Z2_twlp8JNQMttuI-omg，经授权分享。英文原文链接：https://dev.jlelse.eu/devops-is-a-culture-not-a-role-be1bed149b0
活动推荐
DevOps 的概念变迁，从繁到简，从抽象到具象，现已成为各公司基础架构部门发展的必然趋势。但大多数人知道 DevOps 是什么，却不知 DevOps 如何高效落地？在 DevOps 分工模式下如何跨部门高效率协作？面对飞速发展的运维技术，如何转型为智能化运维？……在 DevOps 环境下，给传统的运维工作带来大量的不确定性，一系列问题随之而来，而解决这些“疑难杂症”就成了传统 IT 企业和各大互联网企业真正的需求。
为了更好的解决企业有关 DevOps 的需求，我们依托 CNUTCon 全球运维技术大会，特设了为期 2 天（9 月 8 日—9 日）的深度学习培训。让参会者在会前 9 月 8 日—9 日两天的时间里，跟随一线技术大咖学习 DevOps 如何在企业落地，DevOps 环境下如何跨部门协作，如何利用机器学习来进行快速监控和排障等更多实战技术。