服务问题台账按“一个问题一条记录”组织，至少需要覆盖五组信息：问题标识与来源、问题描述与影响、分类与归属、处置与根因、状态与验证。本文提供一张可直接复制到表格工具的空白台账，并逐字段说明填写口径、必填与选填的取舍，再用一条完整记录示范从事件上报到问题关闭的填法，便于团队统一记录方式。
要点总览（TL;DR）
- 服务问题台账按“一个问题一条记录”组织，核心字段分为五组：问题标识与来源、问题描述与影响、分类与归属、处置与根因、状态与验证。
- 最小可用台账由10个必填字段组成：问题编号、问题标题、来源事件/工单编号、发现时间、问题现象、影响服务/系统、严重程度、责任团队、责任人、当前状态，可先运行一到两个月再按缺口扩展。
- 来源事件编号记录问题从哪次服务事件中被识别，关联变更/缺陷单记录为消除根因而发起的治理动作，两者分列填写；临时规避措施与最终解决方案同样分开记录。
- 严重程度和当前状态等枚举项应在建表时一次性定义并固定为下拉选项，字段说明、空白模板与填写示例三处保持一致。
- 台账上线后需固定复核节奏与责任人，字段增删保留变更记录，关闭记录定期归档，并通过编号互引与事件记录、缺陷单衔接。
可复制空白服务问题台账模板
下表为空白台账结构，列顺序按“先定位、再判断影响、后跟踪处置”排列。复制到 Excel、在线表格或文档表格中即可使用，第一行作为表头，第二行起每条问题占一行。示例行中的“待填”仅提示填写位置，实际使用时替换为真实内容或直接删除。
| 问题编号 | 问题标题 | 来源事件/工单编号 | 上报人 | 发现时间 | 问题现象 | 影响服务/系统 | 影响范围 | 严重程度 | 受影响用户/客户 | 问题类型 | 所属服务/系统 | 责任团队 | 责任人 | 临时规避措施 | 根因分析 | 关联变更/缺陷单 | 解决方案 | 当前状态 | 目标解决时间 | 关闭时间 | 验证人 | 验证结论 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 待填 | 待填 | 待填 | 待填 | 待填 | 待填 | 待填 | 待填 | 待填 | 待填 | 待填 | 待填 | 待填 | 待填 | 待填 | 待填 | 待填 | 待填 | 待填 | 待填 | 待填 | 待填 | 待填 |
列名与后文字段说明、填写示例保持一致，便于对照阅读。若团队使用在线表格，建议将“严重程度”“当前状态”“问题类型”设置为下拉选项，减少手工输入造成的口径差异。
每个字段记录什么：字段说明与填写口径
23个字段按五组划分，每组承担不同的记录任务。分组的作用是让填写人知道先填什么、后填什么，也方便后续按组筛选和统计。
| 分组 | 字段 | 含义 | 取值方式 | 填写要点 |
|---|---|---|---|---|
| 问题标识与来源 | 问题编号 | 台账内唯一标识 | 按规则生成，如 PB-2025-001 | 建立时即分配，不复用、不跳号 |
| 问题标识与来源 | 问题标题 | 一句话概括问题 | 文本，建议20字以内 | 写“什么服务出现什么异常”，不写解决过程 |
| 问题标识与来源 | 来源事件/工单编号 | 触发该问题的原始事件 | 引用事件或工单编号 | 可填多个，用逗号分隔；与关联缺陷单区分 |
| 问题标识与来源 | 上报人 | 提出该问题的人员 | 姓名或工号 | 填实际发现或上报的人，不填责任团队 |
| 问题标识与来源 | 发现时间 | 问题首次被记录的时间 | 日期或日期时间 | 统一格式，如 YYYY-MM-DD HH:mm |
| 问题描述与影响 | 问题现象 | 可观察到的异常表现 | 文本 | 写事实，如报错信息、响应超时；不写推测原因 |
| 问题描述与影响 | 影响服务/系统 | 受影响的业务服务或系统 | 从服务清单中选择 | 使用统一的服务名称，便于统计 |
| 问题描述与影响 | 影响范围 | 影响的功能、区域或流程环节 | 文本 | 描述边界，如“仅影响订单查询，不影响下单” |
| 问题描述与影响 | 严重程度 | 问题对业务的影响等级 | 枚举，如 P1/P2/P3/P4 或 高/中/低 | 建立时定义分级标准并写入说明，全表统一 |
| 问题描述与影响 | 受影响用户/客户 | 受影响的用户数量或客户名称 | 数量或名单 | 涉及重点客户时逐一列出，便于后续沟通 |
| 分类与归属 | 问题类型 | 问题的归类 | 枚举，如配置、性能、数据、流程、第三方依赖 | 类型清单由团队维护，新增类型需同步更新说明 |
| 分类与归属 | 所属服务/系统 | 问题归属的服务或系统 | 从服务清单中选择 | 与“影响服务/系统”区分：此处指责任归属 |
| 分类与归属 | 责任团队 | 负责处置的团队 | 团队名称 | 跨团队问题时填主责团队，协作方写入备注或关联单 |
| 分类与归属 | 责任人 | 具体跟进人 | 姓名 | 一人一责，避免填团队名代替 |
| 处置与根因 | 临时规避措施 | 为恢复服务采取的临时动作 | 文本 | 写动作和生效时间，如“切换备用节点，10:20恢复” |
| 处置与根因 | 根因分析 | 导致问题的根本原因 | 文本 | 在分析完成后填写，未完成时标注“分析中” |
| 处置与根因 | 关联变更/缺陷单 | 为消除根因而发起的变更或缺陷记录 | 引用编号 | 与来源事件编号分列，前者是输入，后者是治理动作 |
| 处置与根因 | 解决方案 | 消除根因的最终处理方式 | 文本 | 写最终措施，不重复临时规避内容 |
| 状态与验证 | 当前状态 | 问题所处阶段 | 枚举，如待分析、分析中、处理中、待验证、已关闭 | 状态取值建立时固定，流转需有记录 |
| 状态与验证 | 目标解决时间 | 计划完成处置的时间 | 日期 | 按严重程度设定，逾期需在复核中说明 |
| 状态与验证 | 关闭时间 | 验证通过并关闭的时间 | 日期 | 与目标解决时间对照，用于统计解决周期 |
| 状态与验证 | 验证人 | 确认问题已解决的人员 | 姓名 | 建议由上报人或服务负责人验证，不由处置人自验 |
| 状态与验证 | 验证结论 | 验证结果说明 | 文本 | 写验证方式和结果，如“连续观察3天无复发” |
两组容易混淆的字段需要特别说明。“来源事件/工单编号”记录问题从哪次服务事件中被识别出来，属于输入信息；“关联变更/缺陷单”记录为消除根因而发起的治理动作，属于输出信息，两者不能互相替代。“临时规避措施”服务于快速恢复，“解决方案”对应根因消除，分开填写才能在复盘时区分恢复动作与治理动作。严重程度和当前状态的取值应在台账建立时一次性定义，写入字段说明并作为下拉选项固定下来，避免不同人按各自理解填写。
必填与选填：最小可用台账怎么定
起步阶段字段宜少，判断标准是：缺少该字段，团队是否还能定位问题、判断影响、找到责任人和验证关闭。满足这四点的字段列为必填，其余按需要补充。
| 字段 | 必填/选填 | 理由或适用场景 |
|---|---|---|
| 问题编号 | 必填 | 唯一标识，用于引用和检索 |
| 问题标题 | 必填 | 快速识别问题内容 |
| 来源事件/工单编号 | 必填 | 追溯问题来源，关联服务记录 |
| 发现时间 | 必填 | 计算解决周期的基础 |
| 问题现象 | 必填 | 判断问题性质的前提 |
| 影响服务/系统 | 必填 | 确定影响面和统计口径 |
| 严重程度 | 必填 | 决定处置优先级和目标时间 |
| 责任团队 | 必填 | 明确处置归属 |
| 责任人 | 必填 | 落实到具体跟进人 |
| 当前状态 | 必填 | 支撑流转跟踪和逾期识别 |
| 上报人 | 选填 | 需要回访上报人时填写 |
| 影响范围 | 选填 | 影响边界复杂时填写，简单问题可省略 |
| 受影响用户/客户 | 选填 | 涉及重点客户或批量用户时填写 |
| 问题类型 | 选填 | 需要按类型做趋势分析时启用 |
| 所属服务/系统 | 选填 | 责任归属与影响面不一致时填写 |
| 临时规避措施 | 选填 | 采取了临时恢复动作时填写 |
| 根因分析 | 选填 | 分析完成后填写，关闭前应补齐 |
| 关联变更/缺陷单 | 选填 | 需要研发修复或变更时填写 |
| 解决方案 | 选填 | 关闭前补齐 |
| 目标解决时间 | 选填 | 有明确时限要求的问题填写 |
| 关闭时间 | 选填 | 关闭时填写 |
| 验证人 | 选填 | 关闭前填写 |
| 验证结论 | 选填 | 关闭前填写 |
最小可用台账由10个必填字段组成：问题编号、问题标题、来源事件/工单编号、发现时间、问题现象、影响服务/系统、严重程度、责任团队、责任人、当前状态。这套字段能支撑问题登记、分派和状态跟踪，适合刚建立台账的团队。完整台账在最小集基础上增加影响范围、受影响用户、问题类型、临时规避措施、根因分析、关联变更/缺陷单、解决方案、目标解决时间、关闭时间、验证人、验证结论等字段，适合需要做根因治理和复盘统计的团队。建议先运行最小集一到两个月，根据实际出现的记录缺口再逐项补充，避免一次性铺开大量字段导致填写负担过重、记录质量下降。
填写示例：一条服务问题记录的完整填法
以下为演示情景，用于说明各字段如何配合，不指向任何真实客户或系统。
| 字段 | 填写内容 |
|---|---|
| 问题编号 | PB-2025-014 |
| 问题标题 | 订单查询接口在高峰期响应超时 |
| 来源事件/工单编号 | EV-2025-1032、EV-2025-1041 |
| 上报人 | 客服组 李某 |
| 发现时间 | 2025-03-10 09:40 |
| 问题现象 | 每日9:30至10:30订单查询接口平均响应超过5秒，部分请求返回超时错误 |
| 影响服务/系统 | 订单服务 |
| 影响范围 | 仅影响订单查询，下单与支付流程正常 |
| 严重程度 | P2 |
| 受影响用户/客户 | 客服坐席约30人，涉及查询类工单 |
| 问题类型 | 性能 |
| 所属服务/系统 | 订单服务 |
| 责任团队 | 交易研发组 |
| 责任人 | 王某 |
| 临时规避措施 | 3月10日10:05临时扩容查询节点，响应恢复至2秒以内 |
| 根因分析 | 查询语句缺少复合索引，高峰期并发上升后全表扫描导致响应变慢 |
| 关联变更/缺陷单 | 缺陷单 BUG-2025-208 |
| 解决方案 | 补充复合索引并调整查询条件，3月14日发布上线 |
| 当前状态 | 已关闭 |
| 目标解决时间 | 2025-03-15 |
| 关闭时间 | 2025-03-17 |
| 验证人 | 客服组 李某 |
| 验证结论 | 上线后连续观察3个工作日高峰期，响应稳定在2秒以内，未再出现超时工单 |
这条记录体现了几个填写要点。来源事件编号填了两个，说明同一问题由多次事件暴露，合并为一条问题记录，符合“一个问题一条记录”的原则。临时规避措施写清了动作和生效时间，与解决方案分开，复盘时可以清楚看到先恢复、后治理的两步动作。根因分析在处置过程中补充，关闭前补齐，验证结论由上报方确认，避免处置人自验。字段与空白模板、字段说明表完全对应，团队可以照此格式填写其他记录。
台账落地到工具时，可以把问题记录作为工作项管理，将来源事件与缺陷单以编号互引的方式关联。ONES Desk 提供事件管理及问题管理能力，工单可直接关联到待办事项列表，打通服务团队和研发团队的协同；工单也可一键关联到 ONES Project 的需求/缺陷工作项持续跟踪，或关联到 ONES Wiki 页面记录分析过程、沉淀服务经验。字段与工作流可通过自定义工单属性、自定义工单内容和工作流配置来适配团队实际的台账口径，具体可配置范围以实际版本为准。
台账的调整与维护方法
台账上线后需要固定的维护规则，否则字段会随人员更替逐渐失真。以下规则可按团队规模调整执行力度。
字段增删的触发条件与变更记录
出现以下情况时考虑调整字段：连续多个记录在某一选填字段上留空，说明该字段实际无用，可考虑删除或改为按需填写；复核中发现同类信息反复写在备注里，说明缺少对应字段，应新增；统计口径变化，如需要按客户维度分析，则补充受影响客户字段。每次增删字段都在台账外的变更记录中登记日期、变更内容、发起人和影响范围，并在字段说明表中同步更新，保证模板、说明、示例三处一致。
定期复核的节奏与责任人
建议每周由台账负责人复核一次在办记录，检查状态是否与实际一致、逾期记录是否有说明、责任人和目标时间是否缺失；每月由服务负责人抽查已关闭记录，检查根因分析和验证结论是否完整。复核检查项包括：必填字段无空值、状态与最近一次处置动作匹配、关闭记录均有验证人和验证结论、关联编号可追溯。复核结果记录在案，作为下月改进依据。
状态流转与关闭后的归档处理
状态按“待分析—分析中—处理中—待验证—已关闭”流转，每次变更记录时间和操作人。关闭后的记录保留在台账中，按季度或半年归档到单独的工作表或文档，归档时保留问题编号、标题、影响服务、根因和解决方案等关键字段，便于后续检索和复发比对。归档不删除原始记录，避免历史数据丢失。
台账与事件记录、缺陷单的衔接方式
台账通过编号互引与上下游衔接：问题记录引用来源事件编号，需要研发修复时另建缺陷单并回填编号，台账本身不承担缺陷修复流程。这样事件记录负责服务恢复过程，缺陷单负责研发修复过程，台账负责问题从识别到关闭的全过程跟踪，三者职责清晰、互相可查。若团队使用 ONES Wiki 承载台账，可利用页面模板库一键创建制式化文档，并通过版本记录查看和回滚历史修改，保持台账结构稳定。
常见问题
团队刚开始建台账，字段填不全怎么办？
起步阶段可以先只启用10个必填字段，把问题编号、标题、来源事件、发现时间、现象、影响服务、严重程度、责任团队、责任人和当前状态填完整，其余字段留空或暂不建列。运行一到两个月后，统计哪些信息反复被写进备注、哪些选填字段长期为空，再据此增删字段。这样比一次性铺开23个字段更容易保持记录质量。
同一个问题由多次服务事件暴露，台账里要建几条记录？
按“一个问题一条记录”的原则，合并为一条问题记录，在“来源事件/工单编号”字段中填写多个事件编号，用逗号分隔。这样复发次数和影响面可以在一条记录里看清，也避免同一根因被拆成多条记录后重复分析。若后续确认是不同根因，再拆分为独立问题记录。
临时规避措施和解决方案可以写在同一栏吗？
建议分列。临时规避措施记录为快速恢复服务采取的动作和生效时间，解决方案记录消除根因的最终处理方式。两者混填会导致复盘时分不清哪些是恢复动作、哪些是治理动作，也无法统计从恢复到根治的间隔。若团队字段有限，至少保留两列或在同一字段内用固定格式分段填写。
问题关闭后，台账记录需要删除吗？
不删除。关闭记录保留在台账中，按季度或半年归档到单独的工作表或文档，归档时保留问题编号、标题、影响服务、根因和解决方案等关键字段，便于后续检索和复发比对。原始记录保留，历史数据可用于分析同类问题的出现频率和解决周期。
台账和缺陷单的边界怎么划？
台账负责问题从识别、分派、恢复到关闭的全过程跟踪；需要研发修复时另建缺陷单，并把缺陷单编号回填到“关联变更/缺陷单”字段。缺陷单内部的具体修复流程由研发侧管理，台账只引用编号、跟踪状态，不重复记录修复细节。这样事件记录、问题台账、缺陷单三者职责清晰、互相可查。
用表格工具还是专业系统承载台账？
记录量小、参与人少的团队可以先用在线表格，把枚举字段设为下拉选项即可。当问题需要跨服务团队与研发团队流转、要求状态变更留痕和权限控制时，可考虑用专业系统承载。ONES Desk 提供事件管理及问题管理能力，工单可关联到待办事项列表，也可一键关联到 ONES Project 的需求/缺陷工作项或 ONES Wiki 页面；字段与工作流可通过自定义工单属性、自定义工单内容和工作流配置适配团队口径，具体可配置范围以实际版本为准。
