IT服务事件（Incident）指IT服务出现实际或潜在中断、质量下降时被记录并需要恢复服务的单次情况，例如系统无法登录、接口超时、打印机不可用。它关注的是尽快恢复服务，根因排查与长期治理由问题管理承担。本文围绕定义、边界、处理机制以及事件与问题治理的衔接展开，软件缺陷修复、硬件维修操作与攻击技术不在讨论范围内。
要点总览（TL;DR）
- IT服务事件指IT服务出现实际或潜在中断、质量下降时被记录并需要恢复服务的单次情况，判断要素是已登记、影响范围与优先级。
- 事件管理的目标是尽快恢复服务；根因排查与长期治理由问题管理承担，软件缺陷修复归缺陷管理，计划内变更的预期影响不按事件处理。
- 事件处理依次经过上报登记、分类定级、一线处理与升级、临时恢复与验证、关闭与回访，临时措施与永久修复需在记录中分开标注。
- 重复事件与重大事件应转入问题治理，通过事件单与问题单关联、已知错误与规避方案回填，形成从恢复到防复发的闭环。
- 事件关闭只代表服务恢复，不代表根因已消除；维护窗口影响、操作错误和一般咨询通常按服务请求处理。
IT服务事件的定义与判断标准
IT服务事件是服务管理中对“一次服务异常”的称呼，英文为Incident。它描述的是一个具体时间点上，某项IT服务未能按预期提供功能或质量，从而影响用户完成业务动作的情况。定义中有两个关键词：服务中断和服务质量下降。前者指服务完全不可用，后者指服务仍可运行但响应变慢、结果错误或时断时续。两种情况都可能构成事件，判断依据是用户能否正常完成原本依赖该服务的任务。
一个情况要被认定为事件，通常需要同时满足三个要素。第一是被记录：口头抱怨或聊天群里的一句话，如果没有进入事件记录，就无法跟踪、统计和复盘，因此登记是事件成立的起点。第二是影响范围：需要明确受影响的用户数量、业务环节、地域或系统范围，影响范围决定了这件事的严重程度。第三是优先级：优先级由影响范围与紧急程度共同决定，影响核心交易链路的事件通常高于影响个别办公设备的事件。三个要素齐备，事件才具备可处理、可排序、可关闭的基础。
事件通常由服务的使用者提出，包括业务人员、外部客户，也包括监控系统自动告警。受理方一般是IT服务台或一线支持团队，他们负责确认现象、登记信息并给出初始优先级。提出者不必判断根因，受理方也不必在登记阶段就给出解决方案，双方的共同任务是让这次异常被准确描述并进入处理队列。
事件不包括什么：与问题、缺陷、变更的边界
事件管理的范围止于服务恢复。理解这一点，需要把事件与几个相邻概念区分开。事件与问题最容易混淆：事件是单次的服务异常，目标是尽快让服务恢复可用；问题是导致一个或多个事件的深层原因，目标是消除根因、防止再次发生。同一现象可以既是事件又是问题的线索，但两者的处理对象和完成标志不同。事件关闭的标志是服务恢复并经确认，问题关闭的标志是根因被定位并消除或有了稳定的规避方案。
软件缺陷修复归缺陷管理。当事件排查发现是代码逻辑错误导致，修复该缺陷通常进入缺陷管理流程，由开发团队按缺陷的严重程度排期修复。事件管理负责在缺陷修复前维持服务可用，缺陷管理负责让错误代码被正确修改，两条流程通过关联单据衔接，不互相替代。
计划内的变更与维护窗口不按事件处理。系统升级、设备更换、配置调整如果在预定时间窗口内按变更流程执行，期间出现的短暂不可用属于预期影响，应通过变更通告告知用户，而不是登记为事件。只有当变更执行后出现非预期的服务异常，才作为事件处理，并与对应变更单关联以便回溯。
硬件维修操作与网络攻击技术同样不在本文范围。硬件故障可以作为事件的现象被记录，但拆机维修、备件更换属于具体的维修作业；攻击手法、漏洞利用与安全攻防属于安全领域，事件管理只负责在安全事件影响服务可用时协调恢复。
| 对象 | 关注目标 | 完成标志 | 与事件的关系 |
|---|---|---|---|
| 事件 | 尽快恢复服务 | 服务恢复并经用户确认 | 本文主题 |
| 问题 | 消除根因、防止复发 | 根因定位并消除或有稳定规避方案 | 由重复或重大事件触发 |
| 缺陷 | 修正软件错误 | 缺陷修复并验证通过 | 事件排查发现代码错误时转入 |
| 变更 | 按计划调整系统 | 变更实施完成并验证 | 计划内影响不按事件处理 |
事件从上报到关闭的处理机制
事件的生命周期由若干固定环节组成，每个环节都有明确的输入和产出。环节完整，事件才能被稳定地处理、交接和复盘。
上报与登记是起点。受理人需要记录三类信息：现象，即用户看到的具体表现，例如页面报错、登录无响应、打印任务堆积；影响对象，即受影响的系统、业务功能、用户群体和地域；发生时间，即首次出现的时间和被发现的时间。现象描述越具体，后续排查越省力。登记完成后事件获得唯一编号，进入待处理状态。
分类与优先级判定决定处理顺序。分类按服务目录或系统模块划分，便于分派到对应团队。优先级依据影响范围和紧急程度确定：影响核心业务且无替代方案的事件优先级最高，影响个别用户且有临时替代方式的事件优先级较低。优先级不是一次定死的，随着影响扩大或缩小应当调整，并在记录中留下调整原因。
一线处理、升级与跨团队协作构成处理主体。一线支持先尝试标准化的已知处置方案，例如重启服务、清理缓存、切换备用线路。当一线在约定时间内无法恢复，或判断需要更深权限与专业知识时，事件升级到二线或相关团队。升级的对象可以是层级，也可以是跨团队协作，例如网络、数据库、应用开发团队同时介入。升级的目的是缩短恢复时间，不是追究责任。
临时恢复措施与永久修复需要分工。事件处理阶段优先采用临时措施，例如回滚最近一次配置、启用降级页面、临时扩容，让业务先恢复可用。永久修复可能涉及代码修改、架构调整，通常转入缺陷管理或变更流程排期实施。记录中应区分“已采取的临时措施”和“待实施的永久修复”，避免服务恢复后被误认为问题已经解决。
关闭条件与回访确认是终点。事件关闭需要满足：服务已恢复，用户或监控确认异常消失，处理过程与临时措施已记录。对于影响较大的事件，关闭前应回访提出者，确认业务动作可以正常完成。关闭状态不等于根因已消除，这一点需要在记录中明确标注，为后续问题治理留下入口。
| 环节 | 主要动作 | 产出 | 状态变化 |
|---|---|---|---|
| 上报与登记 | 记录现象、影响对象、发生时间 | 事件单与唯一编号 | 待处理 |
| 分类与定级 | 按服务目录分类，依据影响与紧急程度定优先级 | 分类、优先级与分派对象 | 处理中 |
| 处理与升级 | 一线处置，必要时升级或跨团队协作 | 处置记录与协作记录 | 处理中 |
| 恢复与验证 | 实施临时措施，确认服务可用 | 临时措施说明与验证结果 | 待关闭 |
| 关闭与回访 | 回访提出者，记录待办修复项 | 关闭结论与后续事项 | 已关闭 |
当事件数量增多、跨团队交接频繁时，登记、分派、升级和关联记录需要落在同一套工作项体系中，避免信息散落在聊天工具和邮件里。ONES支持将事件登记为工作项，设置优先级与处理人，通过状态流转记录从上报到关闭的过程，并可将事件与问题单、缺陷单建立关联，使临时措施与后续修复在同一处可查。
事件与问题治理如何衔接
事件关闭后，一部分事件需要进入问题治理，形成从“恢复”到“防复发”的闭环。衔接的起点是识别哪些事件值得进一步分析。
重复事件与重大事件是主要识别对象。同一现象在短时间内反复出现，说明临时措施只能缓解表象；影响核心业务、造成较大损失或长时间不可用的事件，即使只发生一次，也值得追查根因。识别可以由服务台在处理记录时标记，也可以在定期复盘时按分类和频次统计得出。
从事件记录中提取根因线索是衔接的核心动作。事件处理过程中留下的现象描述、排查步骤、临时措施和恢复时间，都是问题分析的输入。例如多次通过重启恢复的事件，线索指向资源泄漏或连接未释放；集中在特定时段的事件，线索指向定时任务或峰值容量。把这些线索整理成问题单的背景信息，可以避免问题分析从零开始。
问题单与事件单的关联方式应当明确。一个问题是多个事件的共同原因，因此问题单需要关联相关的事件单列表，事件单也应在关闭时标注是否已纳入问题分析。关联关系让后续查看任一事件时都能找到对应的根因分析进展，也让问题关闭时可以回溯验证相关事件是否不再复发。
已知错误与临时规避方案需要回填。当问题分析确认了根因但永久修复尚未实施，应将其登记为已知错误，并附上可复用的临时规避方案。此后同类事件再次发生时，一线可以直接调用规避方案快速恢复，而不必重复排查。这一回填动作把问题治理的成果转化为事件处理的效率，是闭环真正生效的标志。
一个具体例子与常见误解
以下为演示情景，用于说明判定与处理过程。某电商平台的登录接口在促销开始后出现超时，用户无法完成登录，进而无法下单。监控告警与客服反馈同时到达服务台。受理人登记现象为“登录接口响应超时，页面提示请求失败”，影响对象为“全部移动端与网页端用户，涉及下单链路”，发生时间为促销开始后约十分钟。由于影响核心交易且无替代登录方式，优先级定为最高。
一线排查发现登录服务所在节点连接数接近上限，先采取临时措施：扩容登录服务实例并重启异常节点，约二十分钟后登录恢复，下单链路随之恢复。事件在回访客服确认无新增报障后关闭，记录中标注“临时扩容，根因待查”。随后该事件被标记为重大事件，转入问题分析。分析发现连接未及时释放与近期一次配置调整有关，问题单关联了本次事件单及此前两次同类事件，永久修复排入变更流程，修复前将“扩容并重启节点”登记为已知规避方案。这个例子说明：事件关闭只代表服务恢复，根因消除是问题治理的成果。
常见误解有三类。其一，把事件等同于故障根因。事件描述的是服务异常这一事实，根因需要另行分析，二者分属不同流程。其二，认为事件关闭等于问题解决。关闭条件只要求服务恢复并确认，若未识别根因，同类事件仍会复发。其三，认为所有报障都是事件。计划内维护窗口的预期影响、用户操作错误导致的问题、以及可以通过标准指引当场解决且不涉及服务异常的咨询，通常按服务请求处理，不登记为事件。区分的关键仍回到定义：是否存在服务中断或质量下降，以及是否需要恢复服务。
常见问题
事件关闭后，什么情况下必须转入问题管理？
并非每个事件都需要转入问题管理。通常两类事件值得进一步分析：一是同一现象在短时间内反复出现，说明临时措施只缓解了表象；二是影响核心业务、造成较大损失或长时间不可用的重大事件，即使只发生一次也应追查根因。识别可以在处理时由服务台标记，也可以在定期复盘时按分类和频次统计得出。对于一次性的、已明确原因且不会再复发的异常，记录完整即可，不必强行开问题单。
临时恢复措施和永久修复如何区分记录？
事件处理阶段优先采用临时措施让业务先恢复可用，例如回滚配置、启用降级页面、临时扩容；永久修复可能涉及代码修改或架构调整，通常转入缺陷管理或变更流程排期。记录中应分别写明“已采取的临时措施”和“待实施的永久修复”，并在关闭结论中标注根因是否已消除。这样后续查看事件时，不会把服务恢复误认为问题已经解决。
监控系统自动告警算不算事件？由谁受理？
算。事件的提出者既包括业务人员、外部客户，也包括监控系统自动告警。受理方一般是IT服务台或一线支持团队，负责确认现象、登记信息并给出初始优先级。提出者不需要判断根因，受理方也不要求在登记阶段给出解决方案，双方的任务是让这次异常被准确描述并进入处理队列。
计划内维护窗口出现短暂不可用，需要登记事件吗？
按变更流程在预定窗口内执行的升级、设备更换或配置调整，期间出现的短暂不可用属于预期影响，应通过变更通告告知用户，不登记为事件。如果变更执行后出现非预期的服务异常，则作为事件处理，并与对应变更单关联以便回溯。判断的关键是影响是否在计划与通告范围内。
用户操作错误导致的报障怎么处理？
如果用户操作错误没有造成服务中断或质量下降，且可以通过标准指引当场解决，通常按服务请求处理，不登记为事件。若操作错误引发了服务异常，例如误配置导致接口不可用，则按事件登记并恢复服务。区分标准仍回到定义：是否存在服务中断或质量下降，以及是否需要恢复服务。
