DevOps不是一个角色，而是一种文化

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

软件无处不在。在当今世界，每一个主要的公司/组织都与软件开发相关，并且需要作为一个整体行事。在不牺牲安全性或可靠性的情况下，移动得更快、更敏捷的压力比以往任何时候都大。这种压力往往表现为项目被取消或搁置。这就是DevOps寻求解决的情况：如何让组织内的开发、运营和其他小组围绕一组共享目标进行协作，以更快、更可靠地向客户和最终用户交付软件？支持DevOps计划的关键技术实践包括让开发人员和ops团队对通用的敏捷过程和软件交付工具集进行标准化。这些通常包括：

• 自动化配置管理、测试和应用部署；
• 应用程序和基础设施代码的版本控制，以支持协作和回滚；
• CI（持续集成）自动化代码构建，并通过更频繁、更低风险的发布实现更快的反馈和迭代。

DevOps是一个关于每个人应该如何以正确的方式工作的文化视角。在一个软件定义的世界里，出现了一堆问题。
我们如何让某样东西迅速投入生产，一旦它投入生产？我们怎么知道我们已经想出了最好的解决方案？我们可以多快地应用改进和更新？
DevOps的目标是通过让每个在游戏中有利害关系的人早期参与合作过程来包括他们。通过DevOps实现成功，首先要了解关键的业务好处。组织能够以更少的停机时间和更少的安全问题更快地行动。
敏捷和DevOps转型负责人Mike Dilworth最近表示：

DevOps是一种文化，而不是一种角色！整个公司都需要做DevOps才能工作。

需要高层领导的支持，也需要每个与最终产品有利害关系的人的参与，而不仅仅是开发和运营部门。

我曾经读过Puppet的一份白皮书，关于我们如何建立一个高效的IT团队。A部分有一些有趣的理论和实践，我想和你们分享。
DevOps在行业、公司规模和技术环境中进行了深入和广泛的切割。然而，在组织内部领导成功的DevOps转换的IT经理们有一个共同的克制。DevOps是关于持续的学习和改进，而不是一种结束状态。

构建业务案例

像许多IT领导者一样，您不仅被要求提供比以往任何时候都多的产品和服务，而且要以更快的速度和更高的质量这样做–并且不影响可靠性或安全性。DevOps似乎真的会有帮助！但是……在你真正开始之前，你就遇到了对你的团队的怀疑。

你如何为DevOps提出一个清晰、令人信服的理由，以减少恐惧，并将怀疑者转化为冠军？

从上面的问题开始实际上是一个很好的开始。构建业务案例是成功的DevOps转换的关键部分（尤其是在大型组织中）。在一次著名的TED演讲中，Simon Sinek指出了伟大领袖和积极变革催化剂的共同点：

人们不会相信那些领导人在做什么，而是相信他们为什么这么做。

在构建DevOps转换的组织支持时，同样的想法也适用。简单地宣布“我们正在做DevOps”不会让人们同意。相反，你需要一个令人信服的答案来回答“为什么？为什么是现在？“。我们所有的客户都希望在不损害其系统可靠性和稳定性的情况下更快地移动–这些目标在传统组织中直接相互冲突。开发人员的任务是尽快将新特性投入生产。与此同时，运营人员是根据系统的正常运行时间和性能来衡量的。所以这些团队成为对手而不是盟友。因此，部署到生产中会受到延迟和错误的困扰，而且它们的发生频率远低于业务的实际需要。

让开发人员加入DevOps

更快的部署和反馈循环是开发人员想要的核心：代码从他们的笔记本电脑更快地到达用户手中，并且持续的交付能够快速迭代和改进。在早期试点期间跟踪更改准备时间的改进是一个很好的开始：

1. 代码从开发人员的笔记本电脑到生产的速度有多快？
2. 这和你以前的交货期有什么关系？（您是否自动化了更多的构建过程？是否减少了部署所需的票证数量？）
3. 您现在和那时多久部署一次？
4. 部署变得更容易和更快了吗？

使用DevOps让Ops参与进来

当开发人员与他们密切合作时，Ops会受益。首先商定一个通用的工具链，并让这两个小组一起工作，采用开发中使用的相同工具来集成、测试和部署基础结构代码，这可能是有帮助的。这使得开发人员更加积极地进行部署和故障排除，在提高速度和可靠性的同时进一步打破了旧的障碍。跟踪Ops关心的几个指标将强调整个团队的胜利–包括开发人员和QA：

1. 正常运行时间/停机时间：您是否能够更好地满足服务级别的要求？停机时间减少了吗？
2. 变更失败率：失败减少了吗？
3. 平均恢复时间：当故障发生时，你是否缩短了回滚到上次已知的良好状态所需的时间？

从小处着手，从早期的成功中成长。

那么，您如何开始衡量这些DevOps的影响并支持您的业务案例呢？从具体的任务和项目开始。这种方法对Terri Potts（雷神公司的工程研究员和软件技术总监）来说非常有效
你不能改变整个程序，但你可以从让你的几个子团队朝着正确的方向前进开始。从外部引入一些人来自动化一些测试或构建，并为团队提供一些可供构建的示例，这可能会有所帮助。

雷神公司的一个团队可以从每月两个集成过程转变为在一个晚上运行27个集成过程，这是其构建自动化的结果。这是一个重大的胜利，在一个单一的倡议，它成为Potts的更广泛的案例的一部分，在组织内发展DevOps。
从文化转变开始–不要指望一下子把DevOps卖给每个人。事实上，通过用特定的项目赢得较小的团体，您将创建大使，帮助在组织的其他地方推广DevOps，从而产生乘数效应。当您构建业务案例时，您还应该注意长期DevOps成功的潜在障碍。