事件与问题管理→生产缺陷，错误或问题
更改和发布管理→连续交付
事件管理→记录，遥测，仪表和警报
#1 楼
在我看来，DevOps文化伴随着朝着敏捷流程管理的方法转变。 br />这并不意味着ITIL与Devops不兼容，但是通常这将是两个单独的过程，具有不同的时间表。我的意思是，通常将延迟在ITIL引用中包含新产品，直到产品/应用程序在生产中发布了一段时间为止，在此之前，早期的陷阱和集成ITIL所需的一些文档已完成并在以后进行了调整产品是“实时”的。
ITIL中的一件事是服务设计，假定该服务设计是在任何开发任务之前定义的，那么敏捷过程将/可能会在每次迭代中审查设计，正如您所说，ITIL的主要目标是提供一个框架，以确保在设计/构思和维护阶段（构建/运行）之间不遗漏任何东西。 。在devops文化中，整个团队长期负责所有阶段，因此减少了形式主义的原因。我认为，应该将其用作构建产品初始积压清单的清单。有时甚至不适用，因为在团队之间需要较少的信息传输，因为任务是由同一团队完成的。
评论
或者，为OP提供更完整的答案：这取决于您要遵循两种结构的紧密程度。它们可以同时实施吗？是的，绝对可以，但是它们都有一些互斥的要点。如果您想同时实现这两种方法，而这是我在组织中尝试实现的，则全部都与找到正确的平衡有关。
– kazaamjt
17 Mar 2 '17 at 12:20
#2 楼
我已经获得ITIL认证（尽管已经有一段时间了。）我同意Tensibai：ITIL和DevOps并不兼容，但这并不一定使他们成为好朋友。使得ITIL中的流程必须以某种方式发生，特别是对于大型组织。成功地整合已经实施ITIL的DevOps实践，需要仔细的计划，沟通和执行。再说一遍，对于任何DevOps转换都是如此。 。只要组织中的每个人都在同一页面上，使用相同的语言，ITIL和DevOps可以在合并时增加价值。
#3 楼
我喜欢IT怀疑论者在DevOpsCafe.org上的一集中提供的答案。如果我没记错的话，他的思路是，如果您真正了解ITIL，就不会有冲突。大多数ITIL准则都是非常通用的，并且冲突主要是在ITIL的某些实现之间，而不是在实际规范之后。评论
虽然该链接可以回答问题，但如果您的回答中断，则毫无意义。最好在答案中用您自己的词来概括这个想法，并保持链接的扩展。
–滕西拜
17 Mar 2 '17 at 16:02
我将重新收听该剧集，并在此处进行总结。
–吉里·克劳达（Jiri Klouda）
17 Mar 2 '17 at 16:16
评论
可能扩展什么是ITIL？可以肯定，有些人（像我一样）对此一无所知:)好的，我已经更新了问题，并接受了带有Wikipedia页面链接的编辑-谢谢大家的改进。
@RichardSlater由于您尚未接受答案，因此以上答案中是否缺少某些内容，或者只是您根本不想接受某个答案？