问题、变更与内部服务台：围绕工单存在的那些东西
支持控制台回答的是“现在什么坏了”。围绕它还有另外两个问题，而在此之前无处记录：**为什么这件事一再发生**（问题）以及**我们即将要改动什么**（变更）。两者都住在“客户服务扩展”里，与依赖关系图、
支持控制台回答的是“现在什么坏了”。围绕它还有另外两个问题，而在此之前无处记录：**为什么这件事一再发生**（问题）以及**我们即将要改动什么**（变更）。两者都住在“客户服务扩展”里，与依赖关系图、内部服务台和配置包放在一起。
问题：反复出现的工单背后的原因 问题不是第二个工单。它没有 SLA、没有渠道、也没有队列，并且绝不会出现在你的支持数字里。它存在的意义是承载两段文字：
- **临时规避方案**，也就是客服今天可以告诉客户的做法；
- **根本原因**，也就是必须修好、才能让它不再发生的东西。
把这个问题所能解释的工单关联进来。从此以后，打开其中任何一个工单的人，都会在控制台里看到临时规避方案，AI 工具 `known_errors_for_case` 也可以引用它。
有两条规则由服务端强制执行，而不只是界面上的限制： - 把一个问题标记为**已知错误**，必须先写下临时规避方案。一个没有任何话可以告诉客户的已知错误，只是换了个好听名字的问题； - **解决**它必须填写根本原因，这和重大事件本来就要求的规则是同一条。
已经关联了工单的问题不会被删除。把它关闭即可：解释过那些工单的历史会保留下来。
变更：将要动到什么，以及什么时候动 一个变更带有时间窗口、实施方案、**回退方案**，以及在类型要求时的审批。类型沿用通行的说法：
- **预先批准**：例行工作，其审批在流程中一次性给出。它绝不会发起审批请求；
- **常规**：走你的审批策略，与本产品中其他所有审批用的是同一套引擎；
- **紧急**：用来修复已经坏掉的东西。
标出该变更会动到的设备。正是这一点，让你在为某个夜晚下决心之前，可以做两项有用的检查：
- **冻结期**（月末、旺季）会阻止安排在其中的任何事项。当冻结策略允许时，紧急变更可以通过，因为冻结紧急变更等于冻结对已经坏掉的东西的抢修；
- **冲突**：另一个变更在重叠的时间窗口内动同一台设备。这一项只做提醒。两个团队可以在明知情的情况下，在同一个夜晚动同一台服务器；但没有人应该在冻结期里稀里糊涂地动手。
没有回退方案就排期会被拒绝。登记一次失败或一次回滚而不说明发生了什么，同样会被拒绝：六个月后再来读它时，那段说明才是全部意义所在。
依赖关系图 配置项就是工单本来就指向的已装机资产，而不是第四套设备台账。画出谁依赖谁（依赖于、运行于、属于、连接到、备份）之后，这张图就能回答那个深夜的问题：**这个停了，还有什么会跟着停**，并附上每一个受影响项上已经打开的工单数量。会造成层级环状引用的关系会被拒绝；当遍历达到深度上限时，界面会说明这份清单是不完整的，而不是假装到此为止。
内部服务台（人事、IT、财务） 服务台是你自己的员工向内部团队提出请求的地方。这里没有外部门户：提出请求的人本来就已经登录了。服务台声明队列、优先级，以及在必要时声明该主题属于**机密**。
机密不是装饰。工单一诞生就是受限的：只有拥有敏感工单权限的人才能打开它，而且每一次查看都会被记录。这用的是产品本来就有的那道防线，而不是另起一套。
有请求记录的服务台不会被删除，而是被停用。停用意味着“不要再从这里提这类请求了”；它绝不会取消已经打开的请求。