| 导读 | DevOps是文化的转变，是关于每个人如何以正确的方式参与到工作当中。在软件定义的世界里，出现了一系列问题。我们如何让某些东西快速进入生产环境？我们怎么知道使用的是最佳方案呢？我们能多快地使用改进和更新？ |
软件无处不在。在如今的世界里，每个主流公司/组织都和软件开发息息相关，并且公司需要向软件一样运作。更快且更敏捷，同时保证安全性和可靠性，这样的要求前所未有的强烈。这样的压力通常体现为项目被取消或者被暂停。这正是DevOps尝试解决的问题：如何让企业内部的开发，运维和其他组织协作，达成一系列共同的目标，更快更可靠地向客户和终端用户交付软件？支持DevOps项目的核心技术实践包括让开发和运维团队为软件交互标准化一系列常见的敏捷流程和工具。这通常包括：
- 自动化的配置管理，测试和应用部署；
- 应用程序和基础架构代码的版本控制，助力协作和回滚；
- CI（持续集成）自动化代码构建，并且通过更频繁，风险更低的版本带来更快的反馈和迭代。
DevOps试图通过尽早地在交互型流程里涉及到所有人从而让大家都参与进来。达到DevOps的成功需要首先理解核心业务优势。企业能够更快地前进，下线时间更短，并且安全问题更少。DevOps需要高级领导层的支持，也需要和最终产品相关的所有人的参与，而不仅仅是开发和运维部门。
和很多IT领导者一样，你想要的不仅仅是交付前所未有的多的产品和服务，而且还要更快更好地交付——并且没有可靠性和安全性的问题。DevOps看上去确实会有所帮助！但是……在真正开始之前，你就已经开始让团队产生怀疑了。
上面的问题是个良好的开始。构建业务场景是成功的DevOps转型的重要部分（特别是在大型企业里）。在一场有名的TED演讲里，Simon Sinek认为伟大领导者和积极变化的催化剂的共同点是：
更快的部署和反馈回路正是开发人员想要的：代码可以更快地从他们的笔记本交付到用户手里，持续交付带来快速的迭代和改进。在早期pilot项目里跟踪变更时间的改进是个不错的开始：
- 代码从开发的笔记本到生产环境需要多久？
- 跟之前的时间相比，有什么改进么？（你是不是自动化了更多的构建流程？你有没有降低需要部署的ticket数量？）
- 现在和以前相比多久需要一次部署？
- 部署有没有变得更为容易并且更快了呢？
当开发人员和运维人员紧密工作时，运维人员会受益。可以从同意使用通用的工具链开始，让两个组的人采用相同的工具一起工作，在开发中集成，测试和部署基础架构代码。这样可以让开发人员更为积极地参与到部署和问题定位中，进一步打破以前的障碍，同时提高速度和可靠性。跟踪运维团队关心的度量矩阵将给整个团队带来好处——包括Dev和QA：
- 在线/下线时间：是不是能够更好地达到服务级别的要求？下线时间减少了么？
- 变更失败率：故障是不是变少了？
- 恢复的平均时间：故障发生时，回滚到已知的最近的好状态，这样的回滚时间是不是减少了？
那么，如何开始度量这些DevOps的影响，并且支持自己的业务场景呢？从有特定任务和项目的小地方开始。Terri Potts （Raytheon的杰出工程师&软件技术总监）认为这样的方案非常高效。
你无法一下子改变整个程序，但是可以让一些子团队开始尝试正确的方向。从外部引入一些人来自动化一些测试或者build，会很有用，同时给团队一些实际的例子。
Raytheon让他的一个团队从每个月两次集成转变为一个晚上运行27次，这是自动化了build后的结果。在单个项目里这是一个很大的成功，这也成为了Portts如何在企业内孵化DevOps的典型示例。
从小处开始，文化转型也要跟上——不要期望一开始就能让所有人都信服DevOps。实际中，在特定项目的小型组织内赢得大家的支持，就赢得了会在公司其他地方帮助宣传DevOps的大使们，这会带来乘数效应。随着业务场景的构建，还需要清醒认识到要达成长期DevOps成功的可能会遇到的障碍。
原文来自：
本文地址： //lrxjmw.cn/devops-really.html编辑：李帅，审核员：逄增宝
本文原创地址：//lrxjmw.cn/devops-really.html编辑：public，审核员：暂无
