Close

更好的事件管理之路从这里开始

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 事件管理方法可以帮助他们齐心协力并立即实现效益。

DevOps 事件管理流程

DevOps 管理事件的方法与传统的有效事件管理步骤并无太大区别。DevOps 事件管理包括明确强调让开发人员团队从头开始参与(包括待命),并根据专长而不是职称来分配工作。

1. 检测
DevOps 事件响应团队不指望事件永不发生(因为这是必定的),而是高度重视准备工作。他们会协同配合,通过识别系统中的弱点来规划对潜在事件的响应。他们会设置监控工具、警报系统和运行手册,帮助每位成员知道在检测到事件时该联系谁以及下一步该怎么做。

2. 响应
DevOps 事件管理团队不会安排一名待命工程师来负责响应待命轮班中的所有事件,而是指定多个团队成员以接收上报。如果指定的待命工程师无法独立解决事件,则可以参考运行手册来作为指导。待命工程师可以引入适当人员来评估问题的影响和严重程度,并将其上报给正确的响应者。

3. 解决
需要对事件做出响应时,DevOps 事件管理团队通常能够快速达成解决方案。这是因为,他们在总体上更加熟悉应用或系统代码,因为编写代码的正是他们!而且,借助提前准备和良好的沟通系统,他们可以共同完成解决事件的工作,以比第一次看到代码的第三方响应团队更快的速度达成解决方案。

4. 分析
DevOps 事件管理团队在结束事件时会进行无指责事后分析流程。他们会齐聚一堂,分享信息、指标和经验教训,力求不断提高系统弹性,以及快速、高效地解决未来的事件。

5. 准备
当事件得到解决,所有补救步骤均已完成,并且系统恢复正常后,DevOps 事件管理团队会退后一步,评估他们对下一次事件的准备情况。他们会利用在事后分析过程中得到的收获,更新运行手册,并对监控工具和警报系统进行必要的调整。而且,DevOps 对持续改进的关注也适用于人员和团队,而不仅仅是技术。发生一起事件后,每个团队成员都会更充分地准备好迎接下一事件的到来。

高效 DevOps IM 团队的最佳实践

采用 DevOps 方法来响应事件,可以改善开发和 IT 运营团队之间的沟通,加快事件响应和补救速度,并且提高系统的弹性。

自动化流程和工作流
整合您的服务台、监控、请求单、CMDB/资产管理和聊天工具,以简化 IT 事件警报和工作流,确保对应人员可获得寻找解决方案所需的信息。设置含有预定义工作流的运行手册,以便人们可以在事件发生时顺畅无碍地着手应对。

在团队之间进行沟通
确保团队成员可以使用实时聊天工具在整个组织内进行沟通。使用工具来创建事件记录,这样任何人都可以随时介入并快速了解发生的情况和正在做的工作。

采用无指责方法
在解决了事件后,作为一个团队聚到一起,回顾所发生的情况以开展无指责事后分析。避免指责他人,专注于分享信息,帮助每个人改进工作并为提高系统可靠性而出力。

识别并关注业务利润
DevOps 事件响应不仅是一种改进沟通的手段,也是一种确保开发人员和运营部门齐心协力实现真正商业价值的方法。跟踪平均检测时间 (MTTD)、平均修复时间 (MTTR) 和平均故障间隔时间 (MTBF) 等指标,了解团队进步提高的速度。

利用待命值班表将开发人员和系统管理员定位为 SRE
在 DevOps 团队中,开发人员和系统管理员之间的界限已开始模糊,响应事件的人员通常会成为站点可靠性工程师 (SRE)。尽管如此,个别人员很有可能在应用代码或基础架构代码方面有所专长。设置待命值班表,确保拥有适当的专业技能组合来响应事件。

详细了解 Jira Service Management 如何支持 DevOps 方法事件管理。

后续内容
SRE