一次生产事故，暴露了 IT 事件管理的所有问题

一次生产事故暴露了 IT 事件管理的所有问题那是一个周一早上九点。公司的 ERP 系统突然无法登录正值月初对账高峰财务部门四十多人全部停工。前台电话被打爆IT 部门的微信群里消息刷屏每个人都在问怎么回事什么时候好。IT 负责人赶到办公室发现没有人知道该谁来处理这件事。运维组说可能是应用的问题应用组说网络昨天刚做了调整网络组说他们的变更已经验证过没问题。三个团队互相推没有人牵头定位。一个小时之后才有人想起来查应用日志发现是数据库连接池耗尽。再过半小时问题解决。事后复盘从故障发生到彻底恢复总共用了一小时四十分钟。其中真正用于技术排查和修复的时间不到三十分钟。剩下的七十多分钟全部消耗在找人、扯皮、不知道该怎么办上面。这就是没有 IT 事件管理流程的真实代价。一、IT 事件管理在管什么IT 事件管理Incident Management是 ITSM 体系中最基础、最高频的流程目标只有一个当 IT 服务出现中断或质量下降时以最快的速度恢复服务将业务影响降到最低。注意这个目标的措辞——是恢复服务不是找到根因。这个区别非常重要。很多 IT 团队在处理事件时会陷入一个误区非要把问题彻底搞清楚才肯宣布解决。这个出发点是好的但在高压力的故障现场它往往会延长业务中断时间。事件管理的第一优先级是让业务恢复运转哪怕用的是临时方案找根因、防止再次发生那是问题管理Problem Management的任务。这个分工听起来简单但在实际操作中需要团队有清晰的意识当 ERP 挂掉的时候不是先去翻代码找 bug而是先评估能不能重启、能不能切备用环境、能不能用其他方式让用户临时恢复工作。快速止血永远优先于追根溯源。二、一个成熟的事件管理流程长什么样从事件发生到事件关闭一个规范的流程应该包含几个关键环节。事件识别和记录。事件可能通过多个渠道被发现用户打电话、发邮件、在自助门户提工单或者监控系统自动触发告警。不管来自哪个渠道第一步都是在工单系统里创建一条事件记录记录下事件的基本信息什么时间、什么系统、影响了哪些用户、具体的现象是什么。这一步看起来很基础但很多团队在实际操作中会跳过它——事件发生了大家直接在微信群里讨论忙了两个小时等问题解决了才想起来要创建工单。结果是这次事件没有任何正式记录下次遇到类似问题还是从零开始。优先级评定。不是所有事件都同等重要资源要向高优先级的事件倾斜。优先级通常由两个维度决定影响范围多少人、多少业务受影响和紧迫程度业务损失以多快的速度在累积。一个成熟的优先级判定标准应该是客观的、提前定义好的而不是工程师现场拍脑袋决定的。比如核心业务系统完全不可用自动定为 P1影响超过五十名用户的故障自动升为 P2。标准越客观判定越快高优先级事件才能在第一时间得到应有的资源投入。分配和响应。工单创建、优先级确定之后需要立刻分配给有能力处理的工程师或团队。这个分配动作如果靠人工判断在事件量大或者情况紧急时往往会出现延误。好的 IT 工单系统可以根据预设规则自动完成分配P1 事件自动发送告警给随叫随到的工程师应用类问题自动分配给应用运维团队网络类问题自动分配给网络团队。排查和处置。这是事件管理的核心技术环节。规范的做法是负责工程师接手工单后在工单里实时更新排查进展记录尝试了哪些方法、结果是什么让其他相关人员随时能看到当前状态不需要反复询问进展到哪一步了。如果当前工程师在规定时间内没有进展需要有明确的升级机制自动通知下一级或另一个团队介入而不是等着卡在那里。升级机制是防止事件在某个环节陷入僵局的安全阀。沟通和通报。在重大事件处理过程中给受影响的业务部门同步进展是一件经常被技术团队忽视、但对业务侧非常重要的事情。业务部门最焦虑的不是系统还没好而是不知道有没有人在处理、什么时候能好。定期发出事件通报哪怕内容只是我们正在排查预计再需要三十分钟也能大幅降低业务侧的焦虑减少催问电话让技术团队能更专注地处理问题。这个动作不需要多复杂但需要有人专门负责而不是技术团队一边排查一边还要应付各方追问。关闭和复盘。问题解决之后工单不能直接关闭了事。关闭前需要做几件事确认用户侧已经恢复正常记录最终的解决方案评估是否需要转入问题管理做根因分析更新相关的知识库文章。对于 P1、P2 级别的重大事件应该在关闭后的一两个工作日内做正式的事后复盘Post-Incident Review复盘的重点不是追责而是搞清楚事件为什么发生检测和响应是否及时处置过程中哪些环节可以更快如何防止同类事件再次发生。三、大事件怎么处理重大事件管理的特殊要求普通的事件用常规流程处理就够了但当遇到影响范围大、持续时间长的重大事件Major Incident需要一套额外的运作机制。设立事件指挥官Incident Commander。重大事件现场最容易出现的混乱是人多嘴杂没有人真正负责。事件指挥官的职责不是亲自去排查技术问题而是协调所有相关团队确保每个人都知道自己该做什么避免重复劳动和信息断层。事件指挥官要有权调配资源、做决策这个角色在事件期间的优先级高于一切。开设专用的沟通渠道。重大事件期间把所有相关人拉进一个专门的沟通群而不是在日常的工作群里处理可以极大减少信息噪音让重要的进展更新不被其他消息淹没。事件结束后这个群的记录也是复盘的重要参考。设定明确的升级节点。如果事件持续了一定时间还没有解决思路应该触发升级——找更高级别的技术专家介入或者联系外部供应商支持。升级节点应该提前定义比如P1 事件持续四十五分钟没有进展自动升级给 CTO 和相关供应商而不是等到所有人都束手无策才想到要升级。对外沟通和对内沟通分开处理。对受影响用户的通报和内部技术团队的工作沟通逻辑和频率完全不同应该分开处理。技术团队的内部讨论可以很频繁但对外通报要经过筛选内容清晰、准确不传递不确定的信息避免引起不必要的恐慌。四、IT 事件管理为什么总是做不好每个 IT 团队都知道事件管理重要但真正做规范的不多。原因我归纳了几个。缺少统一的事件入口渠道太分散。用户发微信、打电话、发邮件各走各的渠道IT 工程师各自接单没有统一的记录和跟踪。结果是同一个事件被多个人同时处理或者某个渠道进来的请求完全被遗漏还不知道。解决办法是建立统一的 IT 服务台入口所有渠道的请求都汇聚到一个地方统一处理。优先级判定全靠主观高优先级事件得不到应有的资源。没有客观的优先级标准工程师根据自己的经验判断结果参差不齐。核心业务故障有时被低估导致响应迟缓低影响的问题有时被高估挤占了处理重要问题的资源。处理过程没有记录同样的问题反复解决。每次事件的处理过程如果只存在于工程师的脑子里下次遇到同样的问题还是要从头摸索。把处理过程实时记录在工单里关闭时提炼成知识库文章才能让团队的经验真正积累下来。没有升级机制事件容易卡死。工程师遇到搞不定的问题不知道该找谁或者不好意思承认自己搞不定一个人扛着时间白白流逝。明确的升级路径和时间阈值是防止这种情况的关键机制。SLA 压力没有传导到执行层。SLA 定了但工程师处理事件时感受不到时间压力因为没有人实时提醒他这张工单还有二十分钟就要超时了。工单系统的 SLA 超时预警是让承诺真正落地的技术手段。五、事件管理和其他 ITSM 流程的配合IT 事件管理不是孤立运转的它和其他 ITSM 流程有密切的联动关系。和问题管理的联动某类事件反复出现或者某次 P1 事件影响特别大应该转入问题管理流程做根因分析从源头减少同类事件的发生频率。事件管理关闭的是这次问题管理关闭的是这类。和变更管理的联动很多事件的根源是某次变更引发的问题。事件处理完成后复盘时查一下关联的变更记录往往能很快找到根因。反过来某些紧急事件的处置本身就需要做紧急变更这个变更需要走变更管理的紧急通道事后补录记录。和CMDB的联动事件涉及的配置项服务器、应用、网络设备在 CMDB 里有完整的技术信息和依赖关系工程师处理事件时可以直接调用快速了解受影响的范围和关联系统而不需要凭记忆或者到处问人。和知识库的联动历史事件的处理记录是知识库最重要的内容来源。处理类似事件时工程师在知识库里搜索找到上次的解决方案直接复用可以大幅缩短处理时间。IT 事件管理听起来是一套流程但它解决的是一个很朴素的问题当系统出了问题所有人都知道该做什么、谁来做、多快做完。流程清楚了找人扯皮的时间就会大幅压缩真正用于解决问题的时间才能得到保证。如果你的团队正在建立或优化事件管理流程ManageEngineServiceDesk Plus提供了完整的 IT 事件管理模块支持多渠道工单统一接入、优先级自动判定和分配、SLA 实时追踪与超时预警、事件与 CMDB 配置项关联、知识库一键调用以及重大事件专项管理流程。对于想把事件管理从救火变成有序响应的 IT 团队可以作为选型时的参考起点。