一直以来，开发与运维团队之间的裂痕是提升企业IT能力最主要的障碍之一，克服这个难题是一个企业走向成功的关键因素。事实上，每个公司都应该通过改进流程自动化机制，实现更好的工作流程细化规定以达到和谐，这就是向DevOps文化迈进的阶梯。DevOps方法要求你必须对这种文化有详细的理解和学习，这将影响你对企业组织架构所期望看到的变化。

根据Gartner最近的研究,DevOps只有在开发和运维双方愿意合作的情况下才能体现出价值。他们需要在行为层面上迎合变化从而实现文化的改变。否则有90%的DevOps计划都可能面临失败。

在讨论实施DevOps技术中交流的重要性时，Gartner的研究主管Laurie解释道:“出于对文化的尊重，DevOps试图动态的改变开发和运维团队的协作方式。这个变化的关键是信任、诚实和责任的问题。本质上，DevOps的目标是让每个团队的运作对于其他团队来说都是高透明、高可控同时又互相促进的。”

理论与实践

在现实中，运维和开发团队现有的自主性是DevOps方法的可能失败的最常见的原因之一。虽然企业文化是建立在创新和打破陈规之上，但没有基于已有规则的的运维工作似乎是不可想象的。近一步说，两支团队通常被各自的上级所隔离。毕竟，对两只团队下发不同的任务和目标是一种传统的的做法。

随着开发和运维开始各自意识到对方的业务价值，让各部门最终达成共识只有两个业务因素：期限和目标。这往往导致了互相推卸责任的恶果，更容易以对方团队不够给力来作为解释项目延期或失败的原因。

通过发起合作来杜绝这种不良行为，并提醒他们是属于同一个组织，是提高创新效率及迭代速度的最优方案。IT经理必须建立起沟通的桥梁，并鼓励开发和运维团队发掘新的方法来完成他们共同的目标。

为敏捷而来的DevOps

现代企业已经意识到，虽然敏捷开发提高了开发速度和交付日期，但它可能会忽略一些非常重要的方面。“脆弱的基础设施”这个术语就是用来描述开发团队因为使用敏捷开发而不得不在最后期限妥协所造成的损害。

多数人认为DevOps的及时出现使它成为从文化层面上影响公司迈向敏捷卓越团结的救星。DevOps领路人之一Mike Kavis指出：DevOps方法用于规范开发和运维的协作关系，共同构建一个适当的自动化脚本而无需额外的配置，就像按一个按钮一样简单。

而在实施DevOps方法时，开发人员可能是最难缠的，他们会记住所有运维参与的临时代码而导致功能出现问题时的争论和分歧，从而招致运维团队的恐惧和怨恨。所以问题仍然存在：如何建立这种合作？

正确激励

正如Forrester分析师Kurt Bittner所言，如今的IT公司正在帮助缓解开发与运维之间的裂痕,去激励团队做不同事情实现快速迭代。开发团队负责快速开发，而运维团队则负责保证业务的有效运转。朝着相反的方向使劲，两个业务部门最终必然会割裂，这使合作看起来不太现实。

因为大多数公司在其激励政策的基础上设置了优先权，重要的是，这些优先事项与公司的目标一致。简而言之，一旦实行“DevOps”就要确保你的激励政策是鼓励而不是阻碍合作。

设定共同目标

在DevOps支持者眼中，DevOps已经上升为一种文化、一种哲学而并非一个框架或是简单的方法。

“DevOps是一种远离花费大量时间去部署一个脆弱系统而是快速部署可靠而健壮系统的思维模式。DevOps需要极大的团队协作精神，不仅仅包括IT部门，产品和管理成员也应该参与其中。”

确定目标是弥补团队裂痕使其发挥共同的积极作用的极好方式。Bittner解释说：“这意味开发的稳定性、运维的创新性都有了衡量标准，但是最好的办法是奖励每一个有效改善产品用户体验的人。”定的目标本身可以很简单，但要充满野心，这会促使不同的团队更加紧密的合作并解决了许多造成系统困扰的日常问题。

像许多专业人士一样，Burton也认为应当尽快改善整个组织架构以防止大量损失，确立一个譬如如何提高用户体验这样的共同目标。事实上，维护一个系统帮助其升值与开发一个新特性同样重要。

改变恐惧文化

企业文化一旦出现有利的转变，那么实践DevOps方法将成为公司内部降低满负荷运转情况的杀手锏。尽管如此，它的协作方式在一些公司依然是可望而不可及的，一些失败的案例会使每个项目经理和员工感到恐惧。

EMC科技公司VP的Randy Bias认为“恐惧文化”在组织内部是存在的，它已成为项目失败“流行病”的根源。由于企业内对于失败的项目予以重罚，而不是专注于如何最大限度减少可能造成的损失，没有鼓励实验性创新而造成的。一些经验不足的公司通常指责和羞辱造成错误的员工，这使开发人员感到内疚和恐惧。

真正的问题是，当你的企业已经岌岌可危时如何实现这一点。成功的秘密是在不会导致公司破产的基础上建立一个单独的组织机构。

依靠单一应用程序的企业最好是采用微服务架构，这就允许管理者充分给予开发人员自由，即使这意味着要为潜在的错误付出代价。Mike Kavis称，允许人们犯错误的原因，可以自由将其转为生产力，并不是推卸责任。

眼见为实

与管理者的一对一会议、头脑风暴都不足以有效的影响文化变革。用适当的奖励来促进团队间的沟通才是至关重要的。但需要现代的管理者进一步推动促成此事。最好的办法是让开发人员理解业务，反之亦然，让他们聚集在一起，分享对各自工作内容的描述。例如Onshape这样的公司，使开发人员和运维一起工作，这其实是一个双赢的游戏，这种变化已经帮助了两个团队。

   

开发者对于代码错误的造成的后果有了把握，运维也获得了理解代码是如何工作的能力。此外，开发和运维共同承担责任也从一定程度上分担了压力，通过交流沟通来更有效的共同处理问题。

世纪互联在这个方向更加先进，通过讲起开发和运维团队转换成产品团队从而支持整个服务的原型，目标是发现项目管理过程中每个产品团队被分配到的焦点应该聚集在哪里。

善用工具

如今，把开发和运营作为整体来看待的DevOps工程思想逐步深入人心，随之也逐步有了对DevOps系统的需求，善用一些第三方工具也是开发运维人员应具备的技能。

Docker

Docker以其集装化技术为应用程序带来便携性，在Docker中，应用程序可以跨平台运行自给系统。Docker是由Docker引擎和Docker集线器组成的，前者是一个轻量级的运行时间和包装工具，后者则是应用程序共享和工作流程自动化的云服务。

APM

目前企业的运维手段很难触及深入到业务级的应用性能管理。这并非是技术上的问题，而是由于传统的Web性能监控关注的焦点往往偏向后端，比如服务器本身的CPU、内存等，这种监控方式较标准化、规范化，获得的数据也更方便直观。

而当涉及到应用层面的性能监控时，需要将响应时间、数据库调用、缓存、SOA、RPC、External API等都作为监控的重要目标。在应用系统较复杂的情况下，还要涉及Web Service的调用。这使运维人员非常苦恼，因为他们很难再找到一个标准化的方式去执行。

APM通过嵌码的方式深入应用代码中，通过调用的监测方式去监测业务代码的调用时间，出错与异常，并及时上报监测到的指标。通过对Web应用的性能和可用性进行监控和管理，发现和定位性能瓶颈和故障，并将其做成一种SaaS服务。依靠SaaS平台，运维人员就可以在应用上线后，根据业务需求完成监控动作，而不再像之前只能依赖于研发才能实现某种功能，运维不再像原来那样，必须依赖于研发才能实现它的监控，这使研发、运维都能将更多的精力投入到对业务的更新迭代中去，加速了企业DevOps实现的进程。

积极探索

由于每个企业的组织架构和服务都有其独特之处，并依靠非常多的个体，没有严格规定实施DevOps应该遵循的规则。DevOps是当团队有了有新需求和流程时对应初始阻力的最好处理方式，应当寻找和鼓励可以影响这种文化萌发的意见领袖，帮助其他团队接受这个新的方法。

匆促改变只能获得一个临时解决方案，指定明确的目标才是成功实施DevOps的第一步。随着DevOps越来越普及，人们可以从前辈那里收集到更多的经验。所以现在是一个比任何时候都适合尝试DevOps的时机，去体验它真正带来的价值。（来自听云）

一直以来，开发与运维团队之间的裂痕是提升企业IT能力最主要的障碍之一，克服这个难题是一个企业走向成功的关键因素。事实上，每个公司都应该通过改进流程自动化机制，实现更好的工作流程细化规定以达到和谐，这就是向DevOps文化迈进的阶梯。DevOps方法要求你必须对这种文化有详细的理解和学习，这将影响你对企业组织架构所期望看到的变化。

根据Gartner最近的研究,DevOps只有在开发和运维双方愿意合作的情况下才能体现出价值。他们需要在行为层面上迎合变化从而实现文化的改变。否则有90%的DevOps计划都可能面临失败。

在讨论实施DevOps技术中交流的重要性时，Gartner的研究主管Laurie解释道:“出于对文化的尊重，DevOps试图动态的改变开发和运维团队的协作方式。这个变化的关键是信任、诚实和责任的问题。本质上，DevOps的目标是让每个团队的运作对于其他团队来说都是高透明、高可控同时又互相促进的。”

理论与实践

在现实中，运维和开发团队现有的自主性是DevOps方法的可能失败的最常见的原因之一。虽然企业文化是建立在创新和打破陈规之上，但没有基于已有规则的的运维工作似乎是不可想象的。近一步说，两支团队通常被各自的上级所隔离。毕竟，对两只团队下发不同的任务和目标是一种传统的的做法。

随着开发和运维开始各自意识到对方的业务价值，让各部门最终达成共识只有两个业务因素：期限和目标。这往往导致了互相推卸责任的恶果，更容易以对方团队不够给力来作为解释项目延期或失败的原因。

通过发起合作来杜绝这种不良行为，并提醒他们是属于同一个组织，是提高创新效率及迭代速度的最优方案。IT经理必须建立起沟通的桥梁，并鼓励开发和运维团队发掘新的方法来完成他们共同的目标。

为敏捷而来的DevOps

现代企业已经意识到，虽然敏捷开发提高了开发速度和交付日期，但它可能会忽略一些非常重要的方面。“脆弱的基础设施”这个术语就是用来描述开发团队因为使用敏捷开发而不得不在最后期限妥协所造成的损害。

多数人认为DevOps的及时出现使它成为从文化层面上影响公司迈向敏捷卓越团结的救星。DevOps领路人之一Mike Kavis指出：DevOps方法用于规范开发和运维的协作关系，共同构建一个适当的自动化脚本而无需额外的配置，就像按一个按钮一样简单。

而在实施DevOps方法时，开发人员可能是最难缠的，他们会记住所有运维参与的临时代码而导致功能出现问题时的争论和分歧，从而招致运维团队的恐惧和怨恨。所以问题仍然存在：如何建立这种合作？

正确激励

正如Forrester分析师Kurt Bittner所言，如今的IT公司正在帮助缓解开发与运维之间的裂痕,去激励团队做不同事情实现快速迭代。开发团队负责快速开发，而运维团队则负责保证业务的有效运转。朝着相反的方向使劲，两个业务部门最终必然会割裂，这使合作看起来不太现实。

因为大多数公司在其激励政策的基础上设置了优先权，重要的是，这些优先事项与公司的目标一致。简而言之，一旦实行“DevOps”就要确保你的激励政策是鼓励而不是阻碍合作。

设定共同目标

在DevOps支持者眼中，DevOps已经上升为一种文化、一种哲学而并非一个框架或是简单的方法。

“DevOps是一种远离花费大量时间去部署一个脆弱系统而是快速部署可靠而健壮系统的思维模式。DevOps需要极大的团队协作精神，不仅仅包括IT部门，产品和管理成员也应该参与其中。”

确定目标是弥补团队裂痕使其发挥共同的积极作用的极好方式。Bittner解释说：“这意味开发的稳定性、运维的创新性都有了衡量标准，但是最好的办法是奖励每一个有效改善产品用户体验的人。”定的目标本身可以很简单，但要充满野心，这会促使不同的团队更加紧密的合作并解决了许多造成系统困扰的日常问题。

像许多专业人士一样，Burton也认为应当尽快改善整个组织架构以防止大量损失，确立一个譬如如何提高用户体验这样的共同目标。事实上，维护一个系统帮助其升值与开发一个新特性同样重要。

改变恐惧文化

企业文化一旦出现有利的转变，那么实践DevOps方法将成为公司内部降低满负荷运转情况的杀手锏。尽管如此，它的协作方式在一些公司依然是可望而不可及的，一些失败的案例会使每个项目经理和员工感到恐惧。

EMC科技公司VP的Randy Bias认为“恐惧文化”在组织内部是存在的，它已成为项目失败“流行病”的根源。由于企业内对于失败的项目予以重罚，而不是专注于如何最大限度减少可能造成的损失，没有鼓励实验性创新而造成的。一些经验不足的公司通常指责和羞辱造成错误的员工，这使开发人员感到内疚和恐惧。

真正的问题是，当你的企业已经岌岌可危时如何实现这一点。成功的秘密是在不会导致公司破产的基础上建立一个单独的组织机构。

依靠单一应用程序的企业最好是采用微服务架构，这就允许管理者充分给予开发人员自由，即使这意味着要为潜在的错误付出代价。Mike Kavis称，允许人们犯错误的原因，可以自由将其转为生产力，并不是推卸责任。

眼见为实

与管理者的一对一会议、头脑风暴都不足以有效的影响文化变革。用适当的奖励来促进团队间的沟通才是至关重要的。但需要现代的管理者进一步推动促成此事。最好的办法是让开发人员理解业务，反之亦然，让他们聚集在一起，分享对各自工作内容的描述。例如Onshape这样的公司，使开发人员和运维一起工作，这其实是一个双赢的游戏，这种变化已经帮助了两个团队。

   

开发者对于代码错误的造成的后果有了把握，运维也获得了理解代码是如何工作的能力。此外，开发和运维共同承担责任也从一定程度上分担了压力，通过交流沟通来更有效的共同处理问题。

世纪互联在这个方向更加先进，通过讲起开发和运维团队转换成产品团队从而支持整个服务的原型，目标是发现项目管理过程中每个产品团队被分配到的焦点应该聚集在哪里。

善用工具

如今，把开发和运营作为整体来看待的DevOps工程思想逐步深入人心，随之也逐步有了对DevOps系统的需求，善用一些第三方工具也是开发运维人员应具备的技能。

Docker

Docker以其集装化技术为应用程序带来便携性，在Docker中，应用程序可以跨平台运行自给系统。Docker是由Docker引擎和Docker集线器组成的，前者是一个轻量级的运行时间和包装工具，后者则是应用程序共享和工作流程自动化的云服务。

APM

目前企业的运维手段很难触及深入到业务级的应用性能管理。这并非是技术上的问题，而是由于传统的Web性能监控关注的焦点往往偏向后端，比如服务器本身的CPU、内存等，这种监控方式较标准化、规范化，获得的数据也更方便直观。

而当涉及到应用层面的性能监控时，需要将响应时间、数据库调用、缓存、SOA、RPC、External API等都作为监控的重要目标。在应用系统较复杂的情况下，还要涉及Web Service的调用。这使运维人员非常苦恼，因为他们很难再找到一个标准化的方式去执行。

APM通过嵌码的方式深入应用代码中，通过调用的监测方式去监测业务代码的调用时间，出错与异常，并及时上报监测到的指标。通过对Web应用的性能和可用性进行监控和管理，发现和定位性能瓶颈和故障，并将其做成一种SaaS服务。依靠SaaS平台，运维人员就可以在应用上线后，根据业务需求完成监控动作，而不再像之前只能依赖于研发才能实现某种功能，运维不再像原来那样，必须依赖于研发才能实现它的监控，这使研发、运维都能将更多的精力投入到对业务的更新迭代中去，加速了企业DevOps实现的进程。

积极探索

由于每个企业的组织架构和服务都有其独特之处，并依靠非常多的个体，没有严格规定实施DevOps应该遵循的规则。DevOps是当团队有了有新需求和流程时对应初始阻力的最好处理方式，应当寻找和鼓励可以影响这种文化萌发的意见领袖，帮助其他团队接受这个新的方法。

匆促改变只能获得一个临时解决方案，指定明确的目标才是成功实施DevOps的第一步。随着DevOps越来越普及，人们可以从前辈那里收集到更多的经验。所以现在是一个比任何时候都适合尝试DevOps的时机，去体验它真正带来的价值。（来自听云）