本文讲的是DevOps是一种文化，不是角色！【编者的话】越来越多的企业开始推行DevOps，不过DevOps不是简单的开发运维组织的合并，不是单纯的工具链的整合贯通，更不是某种角色，而是一种文化层面的变革。本文从多个角度阐述了DevOps，并且介绍了一些应该考虑的方面以及实用的最佳实践。
【3 天烧脑式容器存储网络训练营 | 深圳站】本次培训以容器存储和网络为主题，包括：Docker Plugin、Docker storage driver、Docker Volume Pulgin、Kubernetes Storage机制、容器网络实现原理和模型、Docker网络实现、网络插件、Calico、Contiv Netplugin、开源企业级镜像仓库Harbor原理及实现等。
软件无处不在。在如今的世界里，每个主流公司/组织都和软件开发息息相关，并且公司需要向软件一样运作。更快且更敏捷，同时保证安全性和可靠性，这样的要求前所未有的强烈。这样的压力通常体现为项目被取消或者被暂停。这正是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”并不会让大家真正开始。相反，你需要令人信服地回答这样的问题“ 为什么？为什么是现在？ ”。你的所有客户都希望速度更快并且不牺牲系统的可靠性和稳定性——在传统企业里这个目标直接自相冲突。开发人员的任务是尽可能快地让新特性上生产环境。同时，衡量运维团队的指标是在线时间和系统性能。因此这让团队之间变得 对立 而不是 并肩作战 。因此，生产环境的部署一直被延迟和错误所困扰，部署发生的频率比业务实际需要的频率低很多。
让Dev支持DevOps
更快的部署和反馈回路正是开发人员想要的：代码可以更快地从他们的笔记本交付到用户手里，持续交付带来快速的迭代和改进。在早期pilot项目里跟踪变更时间的改进是个不错的开始：
- 代码从开发的笔记本到生产环境需要多久？
- 跟之前的时间相比，有什么改进么？（你是不是自动化了更多的构建流程？你有没有降低需要部署的ticket数量？）
- 现在和以前相比多久需要一次部署？
- 部署有没有变得更为容易并且更快了呢？
让Ops支持DevOps
当开发人员和运维人员紧密工作时，运维人员会受益。可以从同意使用通用的工具链开始，让两个组的人采用相同的工具一起工作，在开发中集成，测试和部署基础架构代码。这样可以让开发人员更为积极地参与到部署和问题定位中，进一步打破以前的障碍，同时提高速度和可靠性。跟踪运维团队关心的度量矩阵将给整个团队带来好处——包括Dev和QA：
- 在线/下线时间：是不是能够更好地达到服务级别的要求？下线时间减少了么？
- 变更失败率：故障是不是变少了？
- 恢复的平均时间：故障发生时，回滚到已知的最近的好状态，这样的回滚时间是不是减少了？
从小处着手，持续成长
那么，如何开始度量这些DevOps的影响，并且支持自己的业务场景呢？从有特定任务和项目的小地方开始。Terri Potts （Raytheon的杰出工程师&软件技术总监）认为这样的方案非常高效。
你无法一下子改变整个程序，但是可以让一些子团队开始尝试正确的方向。从外部引入一些人来自动化一些测试或者build，会很有用，同时给团队一些实际的例子。Raytheon让他的一个团队从每个月两次集成转变为一个晚上运行27次，这是自动化了build后的结果。在单个项目里这是一个很大的成功，这也成为了Portts如何在企业内孵化DevOps的典型示例。
从小处开始，文化转型也要跟上——不要期望一开始就能让所有人都信服DevOps。实际中，在特定项目的小型组织内赢得大家的支持，就赢得了会在公司其他地方帮助宣传DevOps的大使们，这会带来乘数效应。随着业务场景的构建，还需要清醒认识到要达成长期DevOps成功的可能会遇到的障碍。
原文链接：DevOps is a culture, not a role!（翻译：崔婧雯）
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
译者介绍
崔婧雯，现就职于IBM，高级软件工程师，负责IBM WebSphere业务流程管理软件的系统测试工作。曾就职于VMware从事桌面虚拟化产品的质量保证工作。对虚拟化，中间件技术，业务流程管理有浓厚的兴趣。
原文发布时间为：
2017-07-05
本文作者：
崔婧雯
本文来自云栖社区合作伙伴Dockerone.io，了解相关信息可以关注Dockerone.io。
原文标题：DevOps是一种文化，不是角色！
