DevOps是一种文化，不是角色！

作者：佚名 2017-07-13 16:43:23

云计算软件无处不在。在如今的世界里，每个主流公司/组织都和软件开发息息相关，并且公司需要向软件一样运作。更快且更敏捷，同时保证安全性和可靠性，这样的要求前所未有的强烈。这样的压力通常体现为项目被取消或者被暂停。

[[196812]]

软件无处不在。在如今的世界里，每个主流公司/组织都和软件开发息息相关，并且公司需要向软件一样运作。更快且更敏捷，同时保证安全性和可靠性，这样的要求***的强烈。这样的压力通常体现为项目被取消或者被暂停。这正是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：