如需转载请联系听云College团队成员小尹 邮箱：yinhy#tingyun.com

关于DevOps，我们都知道它可以看作是Development、Technology Operations、Quality Assurance三者的集合，是一套针对几个部门之间沟通与协作问题的流程和方法。

如果一个互联网企业拥有面向多维度用户、具备不同功能的产品，那么它的研发周期必然会很短、更新迭代的速度也会很快。这就需要各个部门之间能够很好的团结协作，DevOps模式的引入，对产品的开发、测试、交付、维护有着深远的影响。DevOps模式的出现，可以打破各个部门之间存在的鸿沟，使得各个部门之间有更多的协作和交流。

那么DevOps到底需要什么，我们很难找到一个完美的答案。但“DevOps是一种文化，活动和实践使软件交付变为自动化过程以及基础设施的变化都需要软件开发者和信息技术专家们去交流协作”，这句话可能是一个很好的解释。

你理解的DevOps又是什么呢？或者那些不属于DevOps，但你的企业却决定去执行它？除了指望两个分散的部门之间去协作还会带来什么可见的变化？简单地说，成功的DevOps组织会更加流畅的在更短的时间内发布更多的新产品。在开始之前，了解一些你和你的团队要实现DevOps转变可能面临的一些潜在的挑战是很重要的。

1 不要自上而下的驱动

这是一个共性问题，当公司尝试着在他们的团体中执行DevOps 时，一个C-Level 的高管不会在还没有看到良好数据前就突然将公司转到DevOps模式。

当DevOps从一种基层运动转变成一种文化变革催化剂的时候是最成功的。在一个理想状况下，DevOps首先需要开发和运维人员建立一种融洽的关系，这样新创建的团队获得的力量就会自然地分布在两方，有一致的反馈过程和工作节奏。

2 选择一个合适的项目再开始

大多数中型和大型公司办公区和员工遍布全球，很显然，这对DevOps的有机协作进程来说是一个重大的挑战。不管是语言上的障碍，还是时区问题，或只是办公地点，从各方面来看较大的组织更难建立一个完全成熟的DevOps模式。这就是为什么用正确的方法鼓励合作是至关重要的。同样的，选择合适的项目也是很重要的。

通过这些方式，DevOps结构每一步微小的提升，都会带来实实在在的收获，所以更多团队愿意去尝试新的工作模式。当开发和运维一起工作时，完成的产品质量更高，并且所有团队的成员也将为彼此感到骄傲。当他们发现工作影响力很容易被看见的时候，每个团队成员都会感觉到自己更多的价值，随后的工作也会更加努力。

3 云计算的兴起，新的工具和策略

在这种情况下，每个人都会有自己的挑战。首先，最重要的是以前团队遗留的氛围和文化，这也是为什么只在小范围内实行DevOps模式而不是公司范围内，直到他们感受到了变化，质疑声才会变小。

第二个遗留问题是现有的工具。如果你的团队使用的工具是不支持快速迭代的，这在讨论工具转移会是一个影响因素。越来越多的企业开始将他们的钱和信任都投资到云和集成产品当中，当你决定投资哪种工具的时候，要确保这种工具可以完美地融入到产品的生命周期当中并且要和其他的工具很好的配合。

4 量化的影响

另一个可以预知的挑战就是我们得知DevOps组织在难以量化时很难得到管理层的支持.

解决这个问题最重要的是需要监测当前的状态。

我们先来问自己一些问题：

• 你们产品的版本多久更新一次？

• 版本更新后可以得到多少支持？

• 你们解决应用问题的平均时长？

• 每一个问题的收益或品牌的影响是什么?

这些问题将会帮助你量化目前产品的更新进度并且告诉你哪里还可以提高。一旦定义了这些，你就可以罗列最适合组织的KPI目标呈现给你的管理团队。

5 在整个生命周期中选择正确的工具

我们经常看到团队选择工具仅仅是因为他们看起来很酷或某些团队在使用他们，后来才发现他们成为案例是有原因的，每个团队都应当选择适合他们的工具。

如今，互联网进入了一个新的时代，一个企业的业务需求，越来越依赖于软件系统。”以用户为中心”的业务级运维转型也越来越急迫，随着云计算、移动互联网、大数据等技术的快速发展，市场上对于工具的依赖也在逐年增大。

对于大多数互联网企业，DevOps的实现确实会面临很多挑战，运维部门和开发部门之间的鸿沟绝对不可能在短时间内消除，这无形中阻碍了企业对DevOps的执行。在这种情况下，工具的出现无疑给想要转变为Devops模式的企业带来了福音，其中最典型的就是APM。依靠APM平台，运维人员可以随时根据业务需求完成对产品的多维度监控，了解用户最真实的需求，而不再像之前一样，只能依赖于研发才能够实现某种功能。不仅如此，APM还可以实现代码级定位，为开发人员的工作提供了便利。这就使得研发和运维都能够将更多的精力投入到对业务的更新迭代中去，加速了企业DevOps实现的进程。