DevOps转型成功之路2 - 转型的五个误区

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！