DevOps转型的五个误区

Jez Humble提出了DevOps转型的五个误区：

下面我们来详细分析一下：

误区一：放弃现有的系统管理员、测试人员，招聘新的DevOps专家不得不说，这绝对是一个糟糕的想法，建议不要这样做。从经验来看，招聘新的DevOps专家是一件很困难的事情，我身边的一些朋友都在寻找这样的人才，但其实很难找到完美的人选。因为DevOps工程师或专家不是直接能够培训出来的，也没有一所大学教授DevOps的课程，这些有经验的人都是在工作中不断遇到和解决问题的过程中逐渐成长起来的。

所以问题的关键在于，如何建立一个组织环境，让员工可以在工作中学习，他们不会被刻意地限制在各自的角色中，而是被鼓励在解决问题的过程中不断学习新技能，并为整个组织服务。

误区二：进行大规模组织结构重组（Re-Org）有的组织转型很干脆，一上来就进行大规模的组织结构重组。但经验告诉我们，组织结构重组是非常容易引起混乱的活动，组织通常会消耗数月时间和巨大的能量，员工需要重新熟悉新的组织结构和工作方式，这对组织生产力的打击是非常大的。

值得注意的是，我们并不是说不需要对组织进行改进。我们都知道，跨职能团队（比如面向服务或特性）会比按职能切分的团队具有更高的生产力，所以建立跨职能团队本身是非常有效的。但这里观点是Re-Org并不是唯一的选择。我们也可以用其他方式达到这个目标，比如让这些不同角色的人员物理地聚在一起；或者下游职能团队通过自动化的自服务平台，把他们的能力赋予给上游的团队使用（见下图）。很多让人敬佩的DevOps组织也没有完全形成跨职能团队（如Etsy，Google和GitHub），但他们的生产率同样非常高。

误区三：重新编写你的应用并迁移到云上DevOps现状调查报告中也显示，DevOps适用于各种场景，包括Mainframe主机系统和商业套装软件（COTS）。

在我的上一篇文章 DevOps听起来不错，但适合你的企业么 ，我讲到了在大型嵌入式软件、保险公司的大型机系统上进行持续交付的案例。除此之外，在《DevOps Handbook》中也提到在传统的POS机上，采用蓝绿部署进行快速和低风险发布的例子。

所以，你不用等待漫长的应用重建并迁移到云上，而是可以在现有系统和组织环境中使用DevOps的思路进行逐步改进，最好的转型启动时间点就是现在！

误区四：购买一揽子DevOps工具DevOps发展到今天，已经出现了非常多的支撑工具。我们认可好的工具可以对DevOps的实施提供出非常强有力的支持，但我们的观点是：如果仅仅是购买工具，无法真正帮助你解决问题。

Jez Humble与Dave Farley在2005~2006年进行持续交付的工作时，并没有上图中展示的如此众多的工具，很多自动化的工作都是由Bash脚本完成的，但也同样获得了非常显著的效果。问题的关键在于你如何解决问题，而不是具体应用哪一款的工具。如果组织仅仅是购买工具而不改变工作流程，这样不会改变任何事情。

我就曾经见过有人把Jira用成了管控型的传统项目管理工具，把Jenkins用成了批处理任务的手动触发器，只有工具而没有方法和实践的改变，是无法走上DevOps成功之路的。

误区五：给开发生产环境的完全访问权限有人说DevOps就是让开发自己进行发布，所以需要给开发所有生产环境的权限。我们认为这是一种可怕的想法。理想情况下，任何人都不应该有生产环境的权限，所有生产环境的部署应该由人工触发后，只通过自动化的方式进行。

只有在特殊的场景下，比如需要在生产环境进行诊断时，才可以允许有人登陆到生产环境。但这种情况下仍然需要特别小心，比如使用一次性的登陆口令，并将任何操作日志都记录下来并发送给系统管理员。

总结今天我们从鸟飞派和空气动力学派的类比说起，DevOps的转型不能照搬其他组织的实施过程，而是应该深入理解其背后的原理、原则和实践。

由于篇幅所限，本文重点介绍了DevOps转型的五个误区，分别是：放弃现有人员而招聘新的DevOps专家、进行大规模组织结构重组、重新编写应用并上云、购买一揽子DevOps工具、给开发生产环境完全访问权限。

那么DevOps转型的正确姿势应该是怎样的呢？我将在下一篇文章中，对DevOps转型的五个关键实践、具体转型路径进行详细阐述，敬请期待！

DevOpsDays大会北京站报名通道：http://event.31huiyi.com/1281765435/index?c=osc

2018年5月5日，与大神Jez Humble面对面畅聊DevOps！