针对高速团队的事件管理
DevOps 时代的事件管理
将开放、无指责的沟通原则应用于事件管理团队
如果不反思事件应对方法，您就无法重新思考如何去构建、部署和操作软件。
在 2009 年题为“每天部署 10 次以上：Flickr 开发与运营密切配合”的开创性演讲中，John Allspaw 和 Paul Hammond 勾勒了他们所憧憬的开发人员和 IT 运营团队协同工作并经常发布的世界。在接下来十年中，这一愿景随着 DevOps 运动而逐渐成形。
DevOps 的性质取决于新的事件响应方式。在 Allspaw 和 Hammond 的演讲中，事件管理受到如此多关注不足为奇。
Hammond 在演讲中提到，“我们要意识到一个重点，失败难免发生。问题不在于是否发生，而在于何时。”
与 ITIL 等框架不同，没有针对 DevOps 团队的“官方”最佳实践文档。但我们普遍认为，DevOps 的核心是打破组织孤岛、提高透明度以及促进开发人员和 IT 运营团队之间的开放式沟通，从而为组织提供商业价值。
同样的透明度、可视性和快速学习文化可延伸至事件管理。
为什么？因为事件管理的第一步（也是最关键的一步），是要了解出了什么问题，安排合适的人员解决问题，以及培养一种无指责的文化。
DevOps 事件管理要求在开发人员和 IT 运营团队之间发展开放、无指责的沟通文化。还要建立轻量级的流程，来加强 IT 服务可靠性、提高客户满意度，并推动业务价值。DevOps 工程师可以帮助实施 DevOps 文化和实践。
相比之下，ITIL 是一个由 26 个流程、程序、任务和清单构成的规范集合，旨在改进 IT 服务管理中的特定实践。ITIL 侧重于服务质量和一致性，以及改进系统的弹性。
ITIL 有一个好处，组织若要改进 ITSM，可以从模板化的最佳实践着手，不必从头开始。尽管有些人认为 ITIL 最适合大型企业，但该框架足够灵活，小型公司也可挑选对自己业务有意义但仍能找到价值的流程。
ITIL 也有一个缺点，当您急于改变事件响应流程时，却要牵涉正式变更管理并需要专家顾问参与，因而拖延了改进。
对于想要立即入门的团队，DevOps 事件管理方法可以帮助他们齐心协力并立即实现效益。