适用于高速团队的 ITSM
DevOps 与 ITIL — 哪个对您的团队至关重要?
在 IT 行业,人们对 DevOps 和 ITIL 有很多看法,而这些观点往往会使这两种 IT 方法相互对立。在许多人看来,你要么是 ITIL 机构,要么是 DevOps 机构。非黑即白,二选其一,只能选择一种。
但是,尽管这些辩论给科技新闻圈带来了有趣的谈资,但这种全有或全无的方法可能代价高昂、令人困惑,对从业者及其企业毫无益处。因为事实上,这并不是全有或全无的情况。无需在这两者中做出选择。
DevOps 和 ITIL 并不会相互排斥。它们可以是互补的方法,各有其优势。敏捷性和协作、流程和控制。混合方法可以从两者的优势中受益。
什么是 DevOps?
关于 DevOps 与 ITIL 的误解
1. DevOps 可以取代 ITIL
“我们不再做 ITIL 了 — 我们现在主营 DevOps!”如果您在科技领域工作了很长时间,可能听过有人做出过这样的声明。
问题在于事实并非如此。因为尽管 IT 部门可能会摆脱 ITIL 培训和流程孤岛,但他们仍然需要做一些服务管理方面的工作。运营、支持、治理、成本核算。这些都是必不可少的业务职能,而且 DevOps 无法像 ITIL 那样为我们提供流程准则,因此,即使是那些现在只主营 DevOps 的公司也可能仍在遵循一些 ITIL 流程或原则。
2. DevOps = 持续开发、集成和自动交付
尽管 DevOps 确实包括持续开发、集成和自动化交付,但这并不是它所能提供的全部,也不一定是实践的核心。DevOps 背后的大部分背景和精神只是为了摆脱旧的分歧,秉持相互尊重和不责备的文化共同努力。
就是这样。协作、共同的目标、相互尊重、不再指责。
即使您的团队尚未完全采用自动化交付或持续开发,这种协作方法也可以改善各种业务指标。
3. ITIL/ITSM 始终需要大量文档,繁琐的流程会拖慢团队的速度
有太多情况表明,ITIL 被滥用为“规则”,而不是指导,并且可以随意解释。
事实是,ITIL 取决于您的团队的选择。如果感觉僵硬,那就是在此过程中的某个位置做出的选择。而且这是一个可以改变的选择。
最好将 ITIL 视为了解大多数企业必须管理的复杂 IT 流程的起点。可以将它看成是一张路线图,一本指南。这并不是说它就是唯一的方法,而是要为我们提供必要的环境,使我们能够尽可能有效高效地做出决策和运行我们的 IT 团队。
如果 ITIL 被视为规则手册,通常会出现成堆的文档和官僚主义。但是,如果使用 ITIL 作为准则,它可以简化操作,而不是使操作陷入困境。
DevOps 和 ITIL 的用例
DevOps 和 ITIL 的用例繁多,但这里有一些例子说明了它们可以解决的不同事务,以及在某些情况下这两种方法如何共同实现最佳解决方案。
利用 DevOps 加快新版本的发布
DevOps 的敏捷方法提供了速度和风险管理方面的优势,因为小型的常规版本可以更快地完成开发,并且在发生事件时更容易回滚或修复。
借助 ITSM 减少 IT 服务台呼叫
ITSM 知识管理最佳实践意味着 IT 团队在解决问题的同时创建文档。通过为内部和外部客户提供自助服务选项,这可能会大大减少服务台的工作量。
利用 ITIL 和 DevOps 防止事件
将 ITIL 中成熟的事件管理流程与 DevOps 专注于自动化审核流程、进行不指责的事后分析以及采取“谁构建,谁运行”的方法相结合,您就能够减少事件数量并缩短事件时间。
通过 DevOps 深入了解事件
DevOps 带来的最有价值的东西之一就是不指责文化。这并不意味着工程师不为错误承担责任。但这确实意味着他们可以坦诚地谈论这些错误,就问题进行更透明的对话,并且这样做也不必担心被解雇。
这种文化转变有助于团队更快地深入了解事件,专注于真正的修复,而不仅仅是将个人作为导致事件的一系列中的活动问题。
减少客户对 ITIL 的困惑
SLA(服务级别协议)是 ITIL 的最佳实践。因为它们概述了您在产品中或对客户的承诺和未承诺的内容,可以帮助减少混乱和投诉。
利用 DevOps 和 ITIL 优化您的流程
ITIL 是 IT 流程的宝典。它已经存在了很长时间,并且已经发展以适应行业不断变化的需求。
就算您有自己的流程,也无需浪费力气去做重复的工作。ITIL 可以说是一个久经考验的起点。。
而且,在 DevOps 可以增加改进的地方,包括不指责的事后分析、自动化、更具协作性的方法等,ITIL 的流程可以进行调整以变得更好。
DevOps 和 ITIL 的用例
表现最好的团队已经知道,IT 需要同时具备 ITIL 和 DevOps 的要素。
DevOps 不仅仅是自动化开发。这是协作和不指责的文化。这种实践为团队创造了空间,让他们能够全力合作,而不是各自努力实现相互竞争的目标。
同样,ITIL 不仅仅是文档。它无需减慢团队的速度或造成不必要的官僚主义麻烦。核心实践健全且经过验证,如果以敏捷开发的方式进行处理,它们可以简化而不是阻塞 IT 流程。