引言：随着DevOps的出现，越来越多的企业做出了一个重要转变，即学习如何在今天的组织中实现必要的文化变革。

伴随DevOps的出现，越来越多的企业开始向这种新的运维模式转变。这并不是一个容易的转变，但企业需要将自身变为极为敏捷。几乎没有人知道，DevOps会在短短几年发生如此大的改变，以至于DevOps的概念随之发生变革。

大约十年前，DevOps还仅仅是Netflix、Facebook等企业在用。如今，DevOps更多地被认为是从计划到生产的连续管道。每隔几年，随着理念的革新，企业都需要建立一个更健康的DevOps文化，以促进整个行业的进步。

DevOps的十年历程

自DevOps诞生以来，它已经经历了许多时代，希望用一个最简洁的时间表，来阐明这些年，它是如何变化的。

早期的DevOps

早期的DevOps只要是为了协调开发与运维团队间沟通的鸿沟，避免开发人员与运维人员之间的推诿。DevOps提出了“沟通”方面的解决方案，但并没有明确工具和流程，因此了解DevOps是如何工作的，还要取决于领导的决定。

DevOps和容器

自2010年起，容器技术通过提供像Docker这种平台即服务的产品备受瞩目，容器技术帮助开发了DevOps的工具和技术，DevOps文化也从单纯的“想法”变成一套可以实施的运维策略。

DevOps崛起

2014年左右，DevOps发生了重大转变，从只关注开发人员和运维工程师，变为更多其他利益相关者在内。此时，软件测试人员、质量保证工程师和安全专家也包含在DevOps策略中，换言之，整个组织成为DevOps无缝机制的一部分，这直接导致了DevOps 2.0的兴起。

连续的DevOps 2.0

近年来，每当有人谈论DevOps时，人们都会强调它应该是“连续的”。这不再是为使组织敏捷需要的一组操作，而是在项目所有阶段进行的持续性策略。这种“连续性”的概念引发了一种名为“一切连续”的概念的发展。

DevOps是一种文化

DevOps的目标是整个组织团队从一开始就同步工作，包括Dev、Ops和QA在内所有成员都需要参与其中，以便能够按时交付项目，每一步都有DevOps的介入，这种文化思想明确了团队成员如何按照预期的方式工作。

Mike Dilworth曾表示，“DevOps是一种文化，而不是一种角色！整个公司都需要做DevOps才能发挥作用。”

DevOps适用于不同规模的企业和组织，它抽象了每个组织的管理和沟通策略，所有这些战略，只有在高级管理人员和团队成员不断整合和努力的情况下才能取得成功，他们不会将你待到特定的状态，而是不断帮助企业转变为敏捷组织。

为什么需要做出改变？

由于需要交付的产品众多，组织同时需要提供稳定性和新功能，这些都需要DevOps介入。在DevOps环境中，团队可以共享代码仓库，并贯穿SDLC整个生命周期。如何您还没有应用DevOps，以下的几点原因或许能够打动您。

技术视角

DevOps直接影响着开发速度。由于DevOps是不同团队之间的持续协作，它提高了开发人员编码速度和进入开发阶段的速度。通常，团队需要6-8个月才能完成全部产品的研发，而使用DevOps，可以将开发周期缩短到每小时和每周一次的发布。

DevOps文化支持敏捷开发方法。通过促进协作并引入迭代的开发周期以及模块化编程实践，开发和运营团队的工作相对而言变得更加容易。

文化视角

DevOps的文化目标是在组织内部建立实践，为用户提供出色体验的高质量软件。最终，DevOps帮助组织与客户建立忠诚的合作关系。凭借出色的客户体验，公司可以缩短恢复时间，降低更改故障，改善部署时间。

由于收益与软件生产质量的提高，随着客户群之间信任度和信誉度的提高，公司可以从中获得更大的收益。

如何建立更好的DevOps文化

尽管DevOps已经从“想法”阶段过渡到一整套策略和工具，但某些组织仍旧未正确实施DevOps文化。

“通常来讲，这些团队经常使用大量专有脚本将自己编码到一个角落，这些脚本实际上在系统中徒增更多的浪费，而不是从系统中消除了浪费，而这正是DevOps运动背后的驱动力所在。”Mike Kavis说。

多年来，我们已经注意到了一些实践，这些实践引导组织通过发展健康的DevOps文化来贯穿始终。

价值传递

这或许是最明显的一个，因为DevOps都是关于沟通和协作的，因此建议所有的团队在任何时间都要建立良好的沟通，沟通的方法可能是邮件、文字或适合的沟通工具，但这些并不重要，重要的是两个团队的立场是一致的。

沟通流程需要从C-Lvevl级别到新晋员工。我们经常听到这样的疑问，“我们到底该使用Docker还是K8s？”这让我们感到困惑。DevOps文化的精髓是“沟通”，大家怎么能跳过工具和技术，而不关注这个简单的事实呢？这些都是很棒的工具，除非它们能够实现“良好的沟通”，否则他们不会对企业有任何好处。

想要建立更好的DevOps文化，关键在于认真地改变思维方式。它要求公司中每个人都走出自己的舒适区，开始与拥有不同技能的人沟通。你不能仅仅雇佣一个“DevOps工程师”，就希望组织奇迹般地转变为一个健康的DevOps文化。过渡当然不容易，它需要一个大的改变，但这样做会让每个人都保持在良性的循环中。

使用DevOps方法进行项目管理

与其他部门一样，DevOps也影响了管理。在通常的开发生命周期中，项目经理遵循着一种单一瀑布式的开发模式。然而，DevOps需要项目经理和他们的开发团队一起改变，他们再也不能只专注于召开会议和制定月度图表。

正如DevOps文化在开发和运维部门推广敏捷方法一样，它也适用于项目管理。你可以看到敏捷方法不仅仅是一种软件方法，它还是一直持续集成/持续交付的过程。减少了项目交付的时间表。项目经理需要建立更短的时间表，在团队跟进过程中进行检查，而不是在月底召开会议。

项目需要像开发一样，使用微服务架构进行拆分，因此项目可以被分割成更小的单个目标/可交付成果。随着时间的推移，这种策略使项目进展速度更快。在遵循DevOps文化的组织中，PM严格遵循这样的策略。

在为客户开发解决方案时，我们总是遵循敏捷方法。此外，当Novateus开始采用DevOps文化时，我们设计了自己的项目管理软件Cuewel。我们对每个项目都采用微服务方法，将其划分为每周的可交付成果，并相应地进行报告。

促进创造性思维

组织坚持他们所知道的——流程、管理变革、开发周期等，所有员工都遵循这些做法，这种单调的方法导致生产力的总体下降。有没有想过Uber和Pinterest这样的创意是从哪里冒出来的？他们甚至提出了客户都不知道的需求。

在DevOps术语中，你可以从组织的角度来看待它。鼓励员工为内部流程思考解决方案。当有机会的时候，人们会想出一个反效果的解决方案来解决长期存在但从未被发现的问题。

在健康的DevOps文化中，创造性思维会得到回报，否则这些想法就会随着潮流而消失。提倡这样一种文化，这些想法不会受到轻视或更坏的影响，甚至被否定，并在必要的时候付诸行动。

利用现有的人力资源

太多的博客建议建立良好的沟通，虽然这可能是最重要的一方面，但一些深入了解应该清楚这种集成是有帮助的。对于bat而言，人们认为最有效的解决办法就是雇佣一个DevOps专职人员，可以是工程师、专家，也可以是任何有DevOps经验的人。

虽然这可能是最快捷的一种，但并不是最优的。留住员工和其他人一样重要，现有的人力资源是企业的一项资产，他们比聘用的任何专家都更了解企业的业务流程。留住现有员工和招聘DevOps员工一样重要。此外，人们相信，新的人才可以帮助企业实现DevOps的可操作性。

你首先需要关注组织中的人才，那些乐于改变的人。可以为有意愿改变的员工提供培训，雇用新员工的成本是利用现有员工的成本的六倍。

两个披萨团队

“两个披萨团队”是一个新概念，它强调的是建立足够小的团队，两个披萨就能让团队吃饱。亚马逊利用这一理念震撼了DevOps的世界。它遵循的理念是在团队内部建立更小的沟通循环，每个团队都是一个微服务，其工作是在更短的开发周期内开发软件。Jeff Benzos的理念非常简单，更多的人意味着更多的协调，更多不必要的沟通和更加混乱。

每个团队成员保持沟通联系越多，团队就会变得越不正常。这种简单的微服务和微观管理理念使事情变得容易多了，两个披萨团队成员不必面对过多的沟通成本，因为他们已经积累了大量的工作量。“数量上有优势”的概念不再适用，而是应该组建能够创造、创新和测试的小团队，这些团队可以再整个组织中形成更好的DevOps文化。

结语

DevOps并不是一个小小的转变，它需要在整个组织范围内进行变革。评价一家公司优秀与否，并不能简单依据是否形成健康的DevOps文化。这个伟大的变革需要整个组织付出很大的努力。因此，建议大家从小事着手，多在公司走一走，花点时间与员工交流，发掘那些愿意接受改变的人才。此外，使用上面提到的一些技巧，你可以为建立更健康的DevOps文化铺平道路。该说的已经说明白了，你还在等什么？！