你的运营部门准备好迎接DevOps了吗?

在最近的一次 ITSM的所有事项 podcast at Knowledge 16, I was asked about my thoughts on Agile and DevOps.

It’s no secret to anybody in IT that DevOps is currently the hottest topic in the ITSM sphere as organizations try to break down the barriers between “Dev” and “Ops” to speed up innovation, enabling continuous development and release of new features and services.

尽管像这样的公司 焦点网 我们已经展示了他们是如何在这种新模式的基础上建立起一种新的工程文化,许多传统的IT组织在试图从旧的 "IT工厂模式 "转向一种新的、更加水平一致的、敏捷的合作模式时,面临着完全不同的挑战。

这个问题与其说是在开发方面,不如说是在运营方面,许多组织仍然缺乏基本的IT流程整合,如事件管理(IM)、问题管理(PM)和变更管理(CM)。

我们在与客户的合作中每天都能看到这种情况,我们发现IM、PM和CM处于不同的领导之下,有不同的优先级,并且很少有接口来确保数据的良好交接。通常缺少的是三个学科的端到端(客户)流程视角,在这种情况下,最终都是为了更快、更持久地解决客户和技术问题,同时最大化IT可用性。

我个人认为,这与ITIL®这样的框架被--我们可以说--"误读 "有很大关系。虽然他们的主要目标之一是建立一个更注重流程的文化,但许多组织已经把它们作为一个理由,围绕不同的流程建立整个功能,在许多企业中,这些功能最终成为很少相互交流的孤岛。

不管有没有DevOps,我们都需要问自己,把这些学科拆开,而不是在一个共同的目标下调整和整合它们,为客户带来什么价值,最终的商业目标是改善正常运行时间和客户体验。在这一点上,我们可能已经准备好转向DevOps,它是关于 "横向业务管理 "和围绕一个共同目标(而不是结构)调整具有不同技能组合的多学科团队。

然而,重新整合企业的运营方不仅仅是在一张纸上调整组织和团队。改变组织结构图本身并不会对业务成果产生影响。这种调整需要与理顺我们的流程并驾齐驱,去除不增值的工作,通过赋予我们的员工在更广泛的学科范围内工作的技能,使他们能够工作。我们需要奖励他们正确的行为(而不是通过把他们放在某个盒子里来限制他们的思维),并清理我们的工具环境,以确保我们能够创造有意义的知识,并能够将简单、重复的任务自动化。

只有这样,我们才能够利用DevOps的真正价值。

相关文章

博客图片1
是什么将ITSM和ITIL®与敏捷和DevOps联系在一起?
博客图片1
衡量ITIL环境下的问题管理质量,第一部分

我们专注于:

联系我们

如需咨询、了解详情,或提出建议