可能不会!
随着敏捷和DevOps的出现，有些人说，ITIL已经死了！这是真的吗？这是真的吗？简短的回答是'不！'
然而，我们需要了解声称ITIL无关紧要和IT服务管理（ITSM）过时的理由是什么。当然，许多已经 "实施ITIL "或 "符合ITIL标准 "或 "与ITIL接轨 "的组织目前确实面临着许多挑战。这些问题包括不必要的官僚主义、不灵活和复杂的流程、过时的工具和技术、孤立和敌对的IT部门，以及其他重大问题和功能障碍。
人们普遍认为ITIL和IT服务管理（ITSM）是教条主义的，并且固守僵化的流程。另一种流行的看法是，ITIL对运营的偏爱大于对软件开发的偏爱，因此与 "应用人 "无关。
一个误解的问题
许多组织误解了ITIL的最佳实践和/或糟糕地实施了ITSM原则。同样地，许多组织把敏捷搞得一团糟，特别是如果他们对敏捷的解释是 "随心所欲 "的同义词。在未来的几年里，我们很可能会看到许多组织尝试DevOps，然后失败。然而，仅仅因为一些人可能实施的敏捷和DevOps很差，这不应该是对这些令人难以置信的强大概念的指控。在这些框架中，"用户错误 "比缺陷更多，包括ITIL。
ITIL不应该是一个 一个尺寸适合所有的人 每个组织都要以同样的方式来实施解决方案。ITIL的格言之一是 "采用和适应"。这条箴言的目的是鼓励灵活地实施ITIL框架。
ITIL不应该是官僚主义的，也不应该是阻碍灵活性和创新的。事实恰恰相反。ITIL鼓励采用新技术和创新，以满足企业的需求，为客户创造价值。ITIL的概念应该以这样的方式实施，即从人员、流程和技术的角度来优化结果。
假设冲突不存在
与流行的看法相反，ITIL与敏捷或DevOps思想并不冲突。ITIL也不限于基础设施或运营。ITIL的最新版本专注于端到端的服务。这些通常包括对应用、开发、基础设施、运营的管理，以及与业务战略和客户价值的协调。
此外，ITIL有一个基于原则的开发生命周期，与敏捷和DevOps使用的软件开发生命周期几乎完全相同。ITIL生命周期的一个重要部分是 "服务设计"，而ITIL在如何进行应用开发的话题上是相当不可知的。ITIL对项目管理的瀑布式方法没有固有的偏见，它既能容纳敏捷，也能容纳任何其他可能的设计服务或运行项目的方法。当涉及到工具、组织结构以及设计政策和程序时，ITIL大多没有规定性。
没有不兼容的情况
ITIL中描述的许多最佳实践和概念与敏捷和DevOps中倡导的相似，甚至相同--或者至少与ITIL并不冲突。例如，ITIL并没有说你需要每季度做一次 "大爆炸 "式的发布，或者有一个缓慢而复杂的变更管理过程。ITIL允许频繁的发布和灵活的变更过程。
最近出版的书。 网站可靠性工程。谷歌如何运行生产系统。 详细描述了谷歌的DevOps实施。谷歌的DevOps融合了敏捷方法论、ITIL最佳实践、系统化的问题解决和决策，以及一种成熟的无责任的持续改进文化。当然，所有这些都是在谷歌高度先进的应用程序、虚拟化基础设施、监控和警报工具等专有技术上运行。谷歌从人员、流程和技术的综合和整体的角度来利用最佳实践，类似于自20世纪80年代以来ITIL所倡导的那样。
谷歌和许多其他组织使用两个重要的DevOps概念--持续集成和持续交付--鼓励频繁发布，在某些情况下每天发布数百个。这些概念与ITIL并不对立，ITIL建议通过一套符合业务需求的流程、工具和技能，以受控的方式完成这些工作。DevOps、Agile和Google都表示赞同。
DevOps和Agile不是IT的 "狂野西部
为了建立一个有效和高效的发布管理系统，系统的分析、坚实的计划和仔细的管理都是必需的。如果期望的最终结果是按季度进行发布的传统方法，这一点很重要，而使用具有持续交付目标的DevOps模型则更为重要。DevOps和Agile并不等同于马虎或 "狂野的西部"。纪律和结构对ITIL、敏捷和DevOps至关重要。在这方面，谷歌也不例外。
将ITIL最佳实践与DevOps和Agile相结合
那么，持续集成和持续交付是如何与ITIL和其他ITSM最佳实践相结合的？
通过将尽可能多的变更推入标准变更（即预先批准）类别，可以部分实现持续集成和交付。例如，你的与ITIL相一致的变更政策可以是这样的："如果提议的变更请求通过了所有要求的测试，那么就可以预先批准实施变更请求，而不需要任何额外的权限或管理监督"（从而绕过你典型的每周变更咨询委员会等）。另一个补充方法是在变更管理过程中尽可能多地将审批点自动化。
自动化是关键
自动化测试和监控已经存在了很长时间，并得到了ITIL最佳实践的充分支持。DevOps只是将这一做法向前推进了一步。有了DevOps，目标是尽可能早地在开发生命周期中实施自动化测试和监控能力。内置的基于代码的自动化测试鼓励程序员开发能够检测到几乎所有可能出现问题的系统的应用程序。如果程序员真的很狡猾，那么他们甚至会尝试建立一个解决方案来自动修复所有检测到的问题，而不需要任何人工干预（也不需要提出一个新的事故单--尽管系统可以在事件管理系统中创建一个信息警报）。
DevOps通常并不适合于遗留系统
说到这里，我们不要忘记，在许多组织中，在所有情况下使用敏捷或DevOps并不总是现实或可取的。遗留系统怎么办？那些既没有虚拟化也没有基于云的系统怎么办？如果你的组织还没有准备好使用敏捷或DevOps，因为缺乏必要的技能、工具、文化成熟度、组织结构等，怎么办？传统的ITIL和/或其他相关的服务管理框架仍然是处理传统IT系统和服务管理的一些最佳方式。
总而言之。在许多组织中，结合使用各种方法是有意义的。ITIL用于某些事情，敏捷用于某些开发，瀑布用于其他项目，而DevOps则是在某些条件允许的情况下（也许是通过运行试点或只对新产品和数字服务使用DevOps）。
那么ITIL死了吗？不！它仍然是相关的，而且在某些情况下比以往任何时候都更需要。它仍然是相关的，而且在某些情况下，现在比以前更需要。
