UptimeLens 值班管理

UptimeLens 值班管理 是做什么的？

通过 UptimeLens MCP 服务器，在客户自己的资源上操作 UptimeLens 的值班与升级工作流。本技能将值班询问（“谁在值班？”、“确认那个通知”、“替我值班”）转化为正确的 MCP 工具调用序列。

何时使用该技能

用于事件通知的操作层面：

• 查找当前谁在值班（或为什么没人值班）。
• 确认或静音正在通知某人的活动升级。
• 通过覆盖值班轮换为某时间段替班。
• 检查升级运行（活动通知 + 历史记录）和升级策略。

对于事件的根因分析（相对于管理通知），请使用只读的 triage_incident MCP 提示，或只读工具 get_incident、get_root_cause、list_status_changes 和 query_metrics。本技能保持在值班/升级层面，仅在有助于决定谁应采取行动时链接到事件上下文。

前提条件

1. UptimeLens MCP 服务器已连接到本客户端。所有计划均支持只读工具。
2. 写入操作（acknowledge_escalation、bulk_acknowledge_escalation、resolve_escalation、snooze_escalation、escalate_escalation、create_on_call_override、update_on_call_override、delete_on_call_override、create_cover_request、accept_cover_request、decline_cover_request）需要读写 API 令牌和Pro 计划或更高。使用只读令牌时，写入工具甚至不会列出；在免费计划上，它们会返回 FeatureNotAvailable。
3. 其中一些操作在计划闸门之上还有第二层按功能闸门，且并非所有操作使用同一个闸门：
   • create_on_call_override、update_on_call_override 和 accept_cover_request 需要值班覆盖功能。接受代班请求算作产生一个活动覆盖——这正是该功能所销售的。 （在付费计划上创建的待处理请求，在降级后被接受，本会创建一个计划不再包含的覆盖；这一漏洞已被有意填补。）
   • create_cover_request 需要一个不同的功能——值班代班请求——因此一个计划可以包含其中一个而不包含另一个。
   • delete_on_call_override 和 decline_cover_request 有意不设闸门：撤销操作必须在降级后仍然可行，否则一个无法再编辑的班次交换也无法再取消。 即使使用读写令牌，上述任何操作都可能返回 FeatureNotAvailable。

如果写入工具缺失或返回 FeatureNotAvailable，请告知用户哪条前提条件未满足，而不是重试。

工具

这些工具来自 UptimeLens MCP 服务器。请使用完全限定名称引用它们为 UptimeLens:<tool>——将 UptimeLens 替换为本客户端中连接器给定的名称，否则可能找不到该工具。

只读工具（发现与上下文）：

• UptimeLens:list_on_call_schedules——值班计划；who_is_on_call 和 create_on_call_override 所需的 scheduleId 来源。
• UptimeLens:who_is_on_call——当前某个计划的值班人；无人值班时返回 gapReason。
• UptimeLens:get_on_call_schedule——未来 N 天（默认 7 天，最多 90 天）内某个计划的排班表：每个班次（谁、何时、轮换 vs 覆盖）、覆盖缺口及其原因，以及覆盖情况摘要。用于未来覆盖；who_is_on_call 仅用于当前。
• UptimeLens:list_on_call_overrides——某个计划的活动和即将到来的覆盖；update_on_call_override 和 delete_on_call_override 所需的 id 来源。每个条目携带用户（谁替班）、请求者（requestedBy，仅针对待处理的代班请求设置——谁请求的覆盖）、时间窗口、原因和状态。只有 active 覆盖可编辑；pending 条目是仍待目标用户接受的代班请求，update_on_call_override 会拒绝它。过去的覆盖不列出。
• UptimeLens:list_escalation_runs——升级运行（活动通知 + 历史记录）；acknowledge_escalation、snooze_escalation 和 escalate_escalation 所需的 runId 来源。进度从 1 开始：currentStep（升级到达的步骤）、nextStep（下一个触发的步骤）、totalSteps。
• UptimeLens:get_escalation_run——一个运行的完整状态：升级到达了哪一步以及下一步触发哪个（currentStep/nextStep 的 totalSteps）、重复进度、紧急程度、确认/解决方法（为何结束）、静音和确认超时截止时间、nextActionAt、触发监控器/事件。
• UptimeLens:get_escalation_run_timeline——一个运行的时间顺序事件日志：通知、投递结果、确认超时、跳过目标、重复、解决——关于“发生了什么 / 为何升级”的最丰富信息来源。
• UptimeLens:list_escalation_policies——值班通知规则。
• UptimeLens:get_escalation_policy——一个策略的详细信息：有序步骤编号为 1..N（list_escalation_runs 中的 currentStep/nextStep 数字指向这些步骤），每个步骤的延迟、目标策略和目标。通过 who_is_on_call 解析计划目标，通过 list_team_members 解析用户目标。
• UptimeLens:list_team_members——团队成员；create_on_call_override 所需的 userId 来源。

写入工具（更改状态——请参阅“写入前确认”）：

• UptimeLens:acknowledge_escalation——停止对一个活动运行的进一步通知。输入：runId。
• UptimeLens:resolve_escalation——永久关闭通知。输入：runId。与确认不同，已解决的运行不会再通知，因此仅在确认根本问题已修复时使用——而不是作为让嘈杂通知静音的方法。
• UptimeLens:bulk_acknowledge_escalation——一次确认多个活动运行。输入：runIds（1–50）。部分成功：已解决/未知的运行会计为跳过，而不是错误。在 list_escalation_runs(state=active) 之后使用，以清除一批通知。
• UptimeLens:snooze_escalation——暂停对一个运行的通知指定分钟数。输入：runId、durationMinutes（1–240）。
• UptimeLens:escalate_escalation——现在通知下一个尚未通知的步骤，而不是等待其计时器（“立即升级”）。输入：runId。不会跳过任何步骤：显示为 nextStep 的步骤会触发；最后一个步骤之后，下一个重复立即开始，如果没有重复剩余，则运行会作为已耗尽关闭（nextStep 为 0——告知用户没有更多人可以通知）。运行恢复为活动状态，其紧急程度变为 high。对于测试运行和已完成运行，此操作被拒绝。
• UptimeLens:create_on_call_override——将一个用户安排为某个计划在某个时间窗口内值班。输入：scheduleId、userId、endAt；可选 startAt（默认为现在）、reason。需要值班覆盖功能（参见前提条件）。
• UptimeLens:update_on_call_override——原地编辑现有覆盖：更改其 endAt 或 reason，并且（仅在开始之前）更改其 userId 或 startAt。输入：id（来自 create_on_call_override 的结果，或通过 list_on_call_overrides 发现当你没有刚刚创建它时）加上要更改的字段；省略字段则保持不变。这是你缩短、延长或重新分配代班的方法；当交换根本不应发生时使用 delete_on_call_override。需要值班覆盖功能。
• UptimeLens:delete_on_call_override——彻底删除覆盖：交换被取消，常规轮换重新生效。输入：id。当代班根本不应发生时使用此操作而不是编辑。
• UptimeLens:create_cover_request——请求队友代班一个时间窗口，而不是直接分配：创建一个 pending 请求并发送电子邮件给目标用户，目标用户必须接受才能变为活动覆盖。输入：scheduleId、userId（被请求的人）、startAt、endAt；可选 reason。当你想立即分配班次而不需要询问时，使用 create_on_call_override。
• UptimeLens:accept_cover_request——接受一个 pending 代班请求 → 它变为活动覆盖（目标用户接管班次）。输入：id（来自 list_on_call_overrides 的一个 pending 条目）。只有目标用户或管理员可以接受。
• UptimeLens:decline_cover_request——拒绝一个 pending 代班请求（不创建覆盖）。输入：id（来自 list_on_call_overrides 的一个 pending 条目）。只有目标用户或管理员可以拒绝。

核心工作流：处理值班通知

大多数写入工具需要一个只有只读工具才能提供的 ID，因此始终先进行发现。复制此清单并按步骤操作：

值班响应：
- [ ] 1. 查找活动升级运行（list_escalation_runs, state=active, isTest=false）
- [ ] 2. 选择相关运行（按 startedAt 排序；检查紧急程度和 currentStep/totalSteps）
- [ ] 3. 如果有用，添加上下文（incidentId → get_incident；triggeringMonitorId → list_status_changes → get_root_cause）
- [ ] 4. 决定：确认（接管，通知停止）或静音（暂停 N 分钟，通知恢复）
- [ ] 5. 向用户确认操作，然后使用运行的 id 调用写入工具

第 1 步——查找活动运行。 使用 state="active" 调用 list_escalation_runs。对真实的事件触发通知使用 isTest=false；isTest=true 是“通知自己”的测试运行，不应视为真实事件。

第 2 步——选择运行。 每个运行都有一个 id（这是写入工具的 runId）、urgency（高/低）、currentStep 的 totalSteps（升级已攀升的步数——从 1 开始；数字越大表示已通知的人越多；nextStep 是下一个被通知的人），以及 startedAt。当多个运行时，按 startedAt 排序（最旧的优先），并优先显示 high 紧急程度。

第 3 步——上下文（可选）。 如果运行有 incidentId，调用 get_incident 获取影响和时间线。如果有 triggeringMonitorId，使用该监控器 ID 调用 list_status_changes 查看其最近的上下变化，然后使用该列表中的 statusChangeId 调用 get_root_cause 获取按探测的网络诊断。仅用于帮助用户做决定；不要在这里开始全面调查。

第 4/5 步——操作。 选择确认、静音还是升级（见下文），确认，然后写入。

确认、解决、静音或升级

• 确认（acknowledge_escalation）表示“我现在接手这个”——在你处理期间停止通知。这是对“接管”、“我收到了”或“静音”通知的正确回应。确认一个不再活动的运行会返回 EscalationRunAlreadyResolved 错误——无害（它已被确认或解决）；报告为已处理并不要重试。

• 解决（resolve_escalation）表示“这个结束了”——运行被永久关闭且永远不会再次通知。当用户表示根本问题已修复时使用，而不仅仅是在处理中。当事件解决时，运行也会自行解决，因此手动解决用于通知比问题持续时间更长的情况。因为它不可撤销，有疑问时优先使用确认。

• 静音（snooze_escalation）表示“静音 durationMinutes 分钟，然后再次通知”——一种延迟，而非接管。它不是幂等的：每次调用将静音窗口重置为现在 + N 分钟，因此再次调用会延长静音时间。使用最适合的最小持续时间（1–240），并且当通知确实需要负责人时，不要用静音代替确认。

• 立即升级（escalate_escalation）表示“这需要更多人，现在”——运行的 nextStep 被立即通知，而不是等待其等待时间，紧急程度变为 high（安静时间不再适用），已确认的运行重新变为活动状态。当用户表示当前响应者无法处理或无人响应时使用；它是静音的反面，因此不要在同一个回合中对同一个运行同时调用两者。告知用户哪个步骤将被通知（从 get_escalation_run 获取的 nextStep）。

确认错误的运行会静音一个真实通知，且没有其他人会被通知，因此确认 runId 与用户所指的通知匹配。

覆盖缺口

当无人值班时，who_is_on_call 返回一个 gapReason：

• schedule_disabled——计划已关闭；策略依赖其他目标。
• no_active_rotations / no_rotation_members——计划当前没有分配任何值班人。
• outside_active_window——超出了此计划的活动时间。

当存在缺口且需要有人接管通知时，create_on_call_override 将一个特定用户放入某个时间窗口的值班。通过 list_on_call_schedules 发现 scheduleId，通过 list_team_members 发现 userId（团队成员不暴露电子邮件或电话——通过姓名/角色匹配）。

who_is_on_call 仅报告当前发生的缺口。要在之前找到会的缺口，调用 get_on_call_schedule 查看计划——其 gaps 数组列出了未来 N 天内每个未覆盖的时间窗口及相同的原因，coveragePercent 总结了期间的覆盖情况。这是 who_is_on_call 的主动辅助工具。

写入前确认

自由读取和分类。对于写入工具，陈述你将要做的事情并首先获得用户同意——这些操作会改变谁被通知：

• 确认/静音：命名运行（紧急程度、触发原因），对于静音还要指定分钟数。
• 解决：明确说明通知正在永久关闭且不会再次通知。询问根本问题是否确实已修复——“让它停止”是确认或静音的请求，而不是解决。
• 覆盖：命名计划、用户和确切时间窗口（startAt–endAt，UTC RFC3339）。如果窗口跨午夜，endAt 的日期应是次日；endAt 必须在 startAt 之后。
• 删除覆盖/拒绝代班请求：命名谁的班次将回退到常规轮换。取消代班和创建代班一样会改变谁被通知。

其中大多数是可逆的——覆盖可以编辑或缩短，确认或静音可以重新升级——因此目标是明确的人类决策，而不是权限壁垒。有两个是不可逆的：

...

[因翻译而截断]