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 기준 순위; urgency 및 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(high/low), currentStep (totalSteps 중 — 에스컬레이션이 얼마나 올라갔는지 1부터 시작; 값이 높을수록 더 많은 사람이 페이지되었음을 의미하며 nextStep은 다음에 페이지될 사람), startedAt이 있습니다. 여러 개가 활성화된 경우 startedAt 순으로 순위를 매기고(가장 오래된 것 먼저) high 긴급도를 먼저 표시하세요.

3단계 — 컨텍스트(선택 사항). 실행에 incidentId가 있으면 get_incident를 호출하여 영향 및 타임라인을 확인하세요. triggeringMonitorId가 있으면 해당 모니터 ID로 list_status_changes를 호출하여 최근 업/다운 변경 사항을 확인한 다음, 해당 목록의 statusChangeId로 get_root_cause를 호출하여 프로브별 네트워크 진단을 확인하세요. 사용자의 결정을 돕기 위해서만 사용하고, 여기서 전체 조사를 시작하지 마세요.

4단계 / 5단계 — 조치. 인지 vs 일시 중단 vs 에스컬레이션(아래 참조) 중에서 선택하고, 확인 후 쓰기 작업을 수행하세요.

인지, 해결, 일시 중단 또는 에스컬레이션

• 인지(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보다 이후여야 합니다.
• 오버라이드 삭제 / 커버 요청 거부: 누구의 교대 근무가 일반 로테이션으로 돌아가는지 지정하세요. 커버를 취소하는 것은 생성하는 것만큼이나 누가 페이지를 받을지 변경합니다.

이러한 대부분은 되돌릴 수 있습니다 — 오버라이드는 편집하거나 단축할 수 있고, 인지 또는 일시 중단은 재에스컬레이션할 수 있습니다 — 따라서 목표는 명확한 인간의 결정이지 권한 장벽이 아닙니다. 두 가지는 그렇지 않습니다:

…

[번역을 위해 잘림]