2025년 10월 05일·7분
실시간 SLA 위반 모니터링 및 예방 웹앱 만들기
SLA 타이머를 추적하고 위반을 즉시 감지해 팀에 알리고 실시간으로 준수 상태를 시각화하는 웹 앱을 구축하는 실용적 설계 블루프린트를 학습하세요.
SLA 타이머를 추적하고 위반을 즉시 감지해 팀에 알리고 실시간으로 준수 상태를 시각화하는 웹 앱을 구축하는 실용적 설계 블루프린트를 학습하세요.
스크린을 설계하거나 감지 로직을 작성하기 전에 앱이 무엇을 예방하려 하는지 명확히 하세요. “SLA 모니터링”은 일단위 리포트부터 초단위 위반 예측까지 다양한 의미를 가질 수 있으며, 각각 아키텍처 요구사항이 크게 다릅니다.
팀이 현실적으로 실행할 수 있는 반응 창을 먼저 합의하세요.
지원 조직이 5–10분 단위로 운영된다면(분류 큐, 페이징 순환 등) “실시간”은 1분마다 대시보드 업데이트, 2분 내 알림일 수 있습니다. 분 단위가 중요한 고심각도 사건이라면 10–30초의 감지·알림 루프가 필요할 수 있습니다.
다음과 같은 측정 가능한 목표로 작성하세요: “60초 이내에 잠재적 위반을 감지하고 2분 이내에 온콜에게 알린다.” 이는 이후 아키텍처와 비용 관련 트레이드오프의 가드레일이 됩니다.
추적할 구체적 약속을 나열하고 각 항목을 평이한 언어로 정의하세요:
또한 조직 내 SLO와 SLA 정의가 어떻게 연관되는지 주목하세요. 내부 SLO가 고객 대상 SLA와 다르면, 운영 개선용과 계약 리스크용 두 가지를 모두 추적해야 할 수 있습니다.
시스템을 사용하거나 의존할 그룹을 명시하세요: 지원, 엔지니어링, 고객 성공, 팀 리드/매니저, 인시던트 대응/온콜 등.
각 그룹에 대해 그들이 순간에 내려야 할 결정을 캡처하세요: “이 티켓이 위험한가?”, “누가 담당인가?”, “에스컬레이션이 필요한가?” 이는 대시보드, 알림 라우팅, 권한 설계에 영향을 줍니다.
목표는 단순한 가시성이 아니라 적시 행동입니다. 위험이 증가하거나 위반이 발생하면 무엇이 일어나야 할지 결정하세요:
좋은 결과 진술 예: “동의한 반응 창 내에 위반 감지 및 인시던트 대응을 가능하게 하여 SLA 위반을 줄인다.”
감지 로직을 구축하기 전에 서비스의 ‘좋음’과 ‘나쁨’을 정확히 적어두세요. 대부분의 SLA 문제는 기술 문제가 아니라 정의 문제입니다.
**SLA(서비스 수준 계약)**는 보통 고객에게 하는 약속이며 결과(크레딧, 페널티, 계약 조건)가 따릅니다. **SLO(서비스 수준 목표)**는 SLA보다 안전하게 위에 머물기 위해 내부에서 설정하는 목표입니다. **KPI(핵심 성과 지표)**는 추적하는 모든 메트릭을 말합니다(유용하지만 항상 약속과 연결되지는 않음).
예: SLA = “1시간 이내 응답.” SLO = “30분 이내 응답.” KPI = “평균 첫 응답 시간.”
감지해야 할 각 위반 유형과 타이머를 시작하는 이벤트를 나열하세요.
일반적인 위반 카테고리:
‘응답’이 공개 답변인지 내부 노트인지, ‘해결’이 resolved인지 closed인지, 재오픈이 타이머를 리셋하는지 여부를 명시하세요.
많은 SLA는 근무시간 동안만 시간을 계산합니다. 캘린더를 정의하세요: 근무일, 휴일, 시작/종료 시간, 계산에 사용할 시간대(고객·계약·팀 중 선택). 또한 작업이 경계를 넘어갈 때(예: 16:55에 30분 응답 SLA 도착) 어떻게 처리할지도 결정하세요.
SLA 시계가 멈추는 경우를 문서화하세요, 예를 들면:
이 규칙들을 앱이 일관되게 적용할 수 있도록 작성하고 모호한 사례의 예시를 남겨 테스트 시 사용하세요.
SLA 모니터는 그것을 공급하는 데이터만큼 정확합니다. 각 SLA 시계에 대한 “시스템 오브 레코드”를 식별하세요. 많은 팀은 티켓팅 도구를 라이프사이클 타임스탬프의 진실로, 모니터링·로깅 도구를 원인 설명으로 사용합니다.
실시간 SLA 설정은 보통 소수의 핵심 시스템에서 가져옵니다:
두 시스템이 불일치하면 각 필드에 대해 어떤 시스템의 값이 우선인지 미리 결정하세요(예: “티켓 상태는 ServiceNow, 고객 등급은 CRM”).
최소한 SLA 타이머를 시작·중지·변경하는 이벤트를 추적하세요:
운영 이벤트도 고려하세요: 근무시간 캘린더 변경, 고객 시간대 업데이트, 휴일 일정 변경 등.
근실시간 업데이트에는 웹훅을 선호하세요. 웹훅이 없거나 신뢰할 수 없다면 폴링을 사용하세요. 재조정용(예: 누락된 간격 보정)으로 API 내보내기/백필을 유지하세요. 많은 팀이 하이브리드를 사용합니다: 속도를 위해 웹훅, 안정성을 위해 주기적 폴링.
현실 시스템은 지저분합니다. 다음을 예상하세요:
이것들을 단순한 엣지 케이스가 아니라 제품 요구사항으로 다루세요—감지의 신뢰성은 여기서 결정됩니다.
SLA 모니터링 앱은 아키텍처가 명확하고 의도적으로 단순할 때 구축·유지보수가 쉽습니다. 높은 수준에서, 원시 운영 신호를 “SLA 상태”로 바꾸고 그 상태를 이용해 사람에게 알리고 대시보드를 구동하는 파이프라인을 만드는 것입니다.
다섯 블록으로 생각하세요:
이 분리는 책임을 명확히 합니다: 인게스트에 SLA 로직을 두지 말고, 대시보드에 무거운 계산을 넣지 마세요.
진정으로 얼마나 ‘실시간’을 필요로 하는지 초기에 결정하세요.
실용적 접근은 한두 규칙은 빈번 재계산으로 시작하고, 영향이 큰 규칙은 스트리밍으로 옮기는 것입니다.
초기에는 다중 리전·다중 환경 복잡성을 피하세요. 단일 리전, 하나의 프로덕션 환경, 최소 스테이징으로 충분합니다. “나중에 확장”을 설계 제약으로 두고 처음에는 검증에 집중하세요.
대시보드와 워크플로의 첫 동작 버전을 빠르게 만들고 싶다면 Koder.ai 같은 비브-코딩 플랫폼이 React 기반 UI와 Go + PostgreSQL 백엔드를 채팅 기반 명세에서 빠르게 스캐폴딩하는 데 도움이 될 수 있습니다. 그런 후 실제 대응자가 필요로 하는 화면과 필터를 검증하며 반복하세요.
구현 전에 다음을 적어 두세요:
이벤트 수집은 SLA 모니터링 시스템이 신뢰할 수 있거나, 소음이 많고 혼란스러워지는 지점을 결정합니다. 목표는 간단합니다: 다양한 툴로부터 이벤트를 받아 하나의 ‘진실스러운’ 형식으로 변환하고, 모든 SLA 결정의 근거를 설명할 수 있을 만큼의 컨텍스트를 저장하는 것입니다.
업스트림 시스템이 다양하더라도 “SLA-관련 이벤트”의 표준을 먼저 정하세요. 실용적 기본 스키마는 다음을 포함합니다:
ticket_id (또는 케이스/작업 아이템 ID)\n- timestamp (변경이 일어난 시각, 수신 시간이 아님)\n- status (opened, assigned, waiting_on_customer, resolved 등)\n- priority (P1–P4 또는 동등값)\n- customer (계정/테넌트 식별자)\n- sla_plan (적용되는 SLA 규칙)schema_version처럼 스키마를 버전 관리하여 필드를 진화시켜도 기존 프로듀서를 깨지 않게 하세요.
다른 시스템이 같은 개념을 다르게 부릅니다: “Solved” vs “Resolved”, “Urgent” vs “P1”, 시간대 차이 또는 우선순위 누락. 작은 정규화 레이어를 구축하세요:
is_customer_wait나 is_pause 같은 파생 필드 부착하여 위반 로직을 단순화통합은 재시도합니다. 수신된 이벤트가 중복되어도 중복으로 계산되지 않도록 멱등성을 구현하세요. 일반적 방법:
event_id를 요구하고 중복 거부\n- 결정적 키(예: ticket_id + timestamp + status) 생성 후 upsert“왜 알림을 보냈나?”라는 질문에 답하려면 서류 기록이 필요합니다. 수락된 모든 원시 이벤트와 정규화된 이벤트, 그리고 누가/무엇이 변경했는지를 저장하세요. 이 감사 히스토리는 고객 대화와 내부 검토에 필수입니다.
파싱이나 검증에 실패하는 이벤트가 있을 것입니다. 이를 조용히 버리지 말고, 오류 이유·원본 페이로드·재시도 횟수를 포함한 데드레터 큐/테이블로 라우팅해 매핑을 수정하고 안전하게 재재생할 수 있게 하세요.
SLA 앱에는 두 가지 다른 ‘기억’이 필요합니다: 지금 현재 사실(알림 트리거용)과 시간이 흐르며 무슨 일이 있었는지(설명·증빙용).
현재 상태는 각 작업 항목(티켓/인시던트/주문)의 최신 상태와 활성 SLA 타이머(시작 시각, 일시중지 시간, 기한 시각, 남은 분, 현재 담당자)입니다.
ID로 빠른 읽기/쓰기가 가능한 저장소를 선택하세요. 일반적 선택은 관계형 DB(Postgres/MySQL) 또는 키-값 스토어(Redis/DynamoDB)입니다. 많은 팀에게는 Postgres가 충분하고 리포팅도 단순합니다.
상태 모델은 작고 쿼리 친화적으로 유지하세요. “곧 위반” 같은 뷰를 위해 자주 읽힙니다.
히스토리는 생성, 할당, 우선순위 변경, 상태 업데이트, 고객 응답, 일시중지 시작/종료 등 모든 변경을 불변 레코드로 캡처해야 합니다.
append-only 이벤트 테이블(또는 이벤트 스토어)은 감사와 재처리(replay)를 가능하게 합니다. 나중에 위반 로직에 버그가 발견되면 이벤트를 재처리해 상태를 재구성하고 결과를 비교할 수 있습니다.
실용적 패턴: 초기에는 같은 DB에 상태 테이블 + 이벤트 테이블을 두되, 볼륨이 커지면 분석용 저장소로 분리하세요.
목적별로 보존 기간을 정의하세요:
파티셔닝(월/분기별)을 사용하면 아카이브와 삭제를 예측 가능하게 만듭니다.
대시보드가 자주 물어볼 질문에 맞춰 인덱스를 계획하세요:
due_at과 status에 인덱스 (또는 queue/team 포함)\n- “오늘 위반된 항목”: breached_at(또는 계산된 위반 플래그)와 날짜에 인덱스\n- 고객/서비스별 뷰: (customer_id, due_at) 같은 복합 인덱스성능은 상위 3–5개 뷰에 맞춰 저장 구조를 설계하는 곳에서 결정됩니다.
실시간 위반 감지는 대부분 혼란스러운 사람 중심 워크플로(할당, 고객 대기, 재오픈, 이관)를 신뢰할 수 있는 SLA 타이머로 바꾸는 일입니다.
각 티켓 또는 요청 유형에 대해 어떤 이벤트가 SLA 시계를 제어하는지 정의하세요. 일반 패턴:
이 이벤트들로부터 **due time(기한 시각)**을 계산하세요. 엄격한 SLA는 created_at + 2 hours일 수 있고, 근무시간 SLA는 캘린더가 필요합니다(예: “2 비즈니스 시간”).
다음 두 질문에 일관되게 답하는 작은 캘린더 모듈을 만드세요:
휴일, 근무 시간, 시간대를 한 곳에 모아 모든 SLA 규칙이 같은 로직을 사용하게 하세요.
기한 시각을 얻으면 남은 시간은 due_time - now(해당하면 비즈니스 분 단위)로 계산됩니다. 그런 다음 “15분 내 기한” 또는 “SLA의 10% 미만 남음” 같은 위반 위험 임계값을 정의하세요. 이는 긴급도 배지와 알림 라우팅을 구동합니다.
다음 중 하나를 선택할 수 있습니다:
실용적 하이브리드는 정확성을 위해 이벤트 기반 업데이트를 사용하고, 이벤트가 없을 때 시간 기반 임계값 도달을 잡기 위한 분 단위 틱을 결합하는 것입니다.
알림은 SLA 모니터링이 실제 운영으로 연결되는 지점입니다. 목표는 “더 많은 알림”이 아니라 “기한 전에 적절한 사람이 적절한 행동을 하게 하는 것”입니다.
명확한 의도를 가진 소수의 알림 유형을 사용하세요:
유형별로 긴급도와 전달 채널(채팅은 경고, 페이징은 확정 위반 등)을 매핑하세요.
라우팅은 하드코딩이 아닌 데이터 기반으로 하세요. 간단한 규칙표(예: 서비스 → 담당 팀)를 사용하고 다음과 같은 수식어를 적용하세요:
이는 전체 브로드캐스트를 피하고 책임을 가시화합니다.
인시던트 대응 중에 SLA 상태가 빠르게 플립할 수 있습니다. (ticket_id, sla_rule_id, alert_type) 같은 안정적인 키로 중복을 제거하고:
또한 여러 경고를 주기적 요약으로 묶는 것을 고려하세요.
각 노티피케이션은 “무엇이, 언제, 누가, 다음 행동은?”에 답해야 합니다:\n\n- 소유자/팀 및 온콜 대상\n- 기한 시각과 남은 시간\n- 다음 액션(인정, 할당, 응답)\n- 해당 작업으로의 직접 링크(예: /tickets/123) 및 SLA 뷰 링크(예: /sla/tickets/123)
사람이 읽고 30초 내에 행동할 수 없다면 알림에 더 나은 컨텍스트가 필요합니다.
좋은 SLA 대시보드는 차트보다 누군가가 1분 내에 다음 행동을 결정하도록 돕는 것에 집중합니다. UI를 세 가지 질문으로 구성하세요: 무엇이 위험한가? 왜 그런가? 어떤 행동을 해야 하나?
다음 네 가지 단순한 뷰로 시작하세요. 각 뷰는 명확한 목적을 가져야 합니다:
기본 뷰는 곧 위반에 집중하세요—예방이 여기서 일어납니다.
사용자에게 실제 소유권과 분류 결정을 반영하는 소수의 필터를 제공하세요:
필터는 사용자별로 고정(sticky)되게 하여 매번 재설정하지 않도록 하세요.
“곧 위반”의 각 행에는 짧고 평이한 영어(또는 로컬 언어) 설명이 있어야 합니다. 예:
“세부 정보” 드로어를 추가해 SLA 상태 변경(시작, 일시중지, 재개, 위반) 타임라인을 보여주면 사용자가 계산을 신뢰할 수 있습니다.
기본 워크플로를 검토 → 열기 → 조치 → 확인으로 설계하세요.
각 항목에 소스 오브 트루스로 바로가는 액션 버튼을 제공하세요:
빠른 조치(할당, 우선순위 변경, 노트 추가)를 지원한다면 일관되게 적용 가능하고 변경을 감사할 수 있는 곳에만 표시하세요.
실시간 SLA 모니터링 앱은 곧 성능, 인시던트, 고객 영향을 기록하는 시스템이 됩니다. 초반부터 운영 등급 소프트웨어처럼 다루세요: 누가 무엇을 할 수 있는지 제한하고, 고객 데이터를 보호하며, 데이터 저장·삭제 방식을 문서화하세요.
작고 명확한 권한 모델로 시작하고 필요할 때만 확장하세요. 일반적 설정은:
권한은 워크플로와 정렬하세요. 예: 운영자는 인시던트 상태를 업데이트할 수 있지만, SLA 타이머나 에스컬레이션 규칙은 어드민만 변경할 수 있게 하세요.
SLA 모니터링에는 고객 식별자, 계약 등급, 티켓 내용이 포함될 수 있습니다. 노출을 최소화하세요:\n\n- 기본적으로 고객 세부정보를 마스킹하거나 가리고(권한 있는 역할만 전체 값 보기)\n- 대시보드가 개인정보 없이도 유용하도록 “표시 이름”과 “고유 ID”를 분리\n- 민감 뷰·내보내기 접근을 누가 언제 어디서 했는지 로깅
통합은 취약점이 되기 쉽습니다:\n\n- 최소 권한 스코프 사용: 이벤트 읽기나 알림 전송에 필요한 권한만\n- 비밀값은 코드나 대시보드 설정에 두지 말고 시크릿 매니저에 저장\n- 직원 변경 또는 노출 의심 시 토큰 즉시 회전\n- 가능하면 서명 검증이 있는 웹훅 또는 단기 자격증명 사용
오래된 히스토리를 쌓기 전에 정책을 정하세요:\n\n- 보존 기간: 원시 이벤트, 계산된 SLA 상태, 감사 로그를 얼마나 보관할 것인가\n- 삭제: 고객 요청 시 데이터를 어떻게 삭제할 것인지(컴플라이언스상 삭제 불가 항목 명시)\n- 내보내기: 누가 어떤 형식으로 Operational 리포트를 내보낼 수 있고 어떤 마스킹을 적용할지
이 규칙들을 문서화하고 UI에 반영해 팀이 시스템이 무엇을 얼마 동안 저장하는지 알게 하세요.
SLA 모니터링 앱 테스트는 “UI가 로드되는가”가 아니라 “타이머, 일시중지, 임계값이 계약이 기대하는 방식대로 정확히 계산되는가”에 초점을 맞춰야 합니다. 작은 실수(시간대, 근무시간, 누락 이벤트)는 시끄러운 알림이나 더 나쁘게는 놓친 위반을 초래할 수 있습니다.
SLA 규칙을 구체적 시나리오로 바꿔 엔드투엔드로 시뮬레이션하세요. 정상 흐름과 까다로운 엣지 케이스 포함:
위반 감지 로직이 깔끔한 데모 데이터뿐 아니라 실제 운영의 혼란 속에서도 안정적인지 증명하세요.
재실행 가능한 이벤트 픽스처 라이브러리를 만드세요: ‘인시던트 타임라인’ 예제들을 버전 관리(Git)하고 로직 변경 시마다 재실행해 검증하세요. 기대 출력(계산된 남은 시간, 위반 시점, 일시중지 창, 알림 트리거)을 함께 저장해 회귀를 방지하세요.
SLA 모니터를 프로덕션 시스템처럼 취급하고 자체 헬스 신호를 추가하세요:\n\n- 인게스트 지연(실시간에서 얼마나 뒤처졌나)\n- 실패한 이벤트 처리/데드레터 수\n- 타이머 계산 오류(규칙별)\n- 알림 전달 성공률 및 전송 시간
대시보드가 “그린”인데 이벤트가 막혀 있으면 신뢰를 잃습니다.
일반적 장애 모드에 대한 짧고 명확한 런북을 작성하세요: 컨슈머 정체, 스키마 변경, 업스트림 장애, 백필. 이벤트를 안전하게 재생하고 타이머를 재계산하는 단계(기간, 테넌트, 중복 알림 방지 방법)를 포함하고 내부 문서 허브나 /runbooks/sla-monitoring 같은 페이지에서 링크하세요.
SLA 모니터링 앱은 프로젝트가 아니라 제품처럼 다루면 쉽습니다. end-to-end 루프(수집 → 평가 → 알림 → 누군가가 행동하고 효과를 확인)를 증명하는 최소 기능 릴리스로 시작하세요.
한 가지 데이터 소스, 한 가지 SLA 유형, 기본 알림을 선택하세요. 예: 단일 티켓팅 피드로 “첫 응답 시간”을 모니터링하고 기한 임박 시(위반 이후가 아니라) 알림을 보냅니다. 이렇게 하면 타임스탬프, 시간 창, 소유권과 같은 어려운 부분을 검증하는 데 범위를 좁힐 수 있습니다.
MVP가 안정되면 작은 단계로 확장하세요: 두 번째 SLA 유형 추가(예: 해결 시간) → 두 번째 데이터 소스 추가 → 풍부한 워크플로 추가.
초기부터 dev, staging, production 환경을 설정하세요. 스테이징은 프로덕션 구성을 미러(통합·일정·에스컬레이션 경로)하되 실제 응답자를 알리지 않게 하세요.
기능 플래그로 배포하세요:\n\n- 새 위반 규칙은 먼저 파일럿 팀에 적용\n- 새 통합은 “관찰 전용(observe-only)” 모드(감지 로그만, 알림 없음)로 시작\n- UI 변경은 토글 뒤에 두어 빠르게 롤백 가능하게
Koder.ai 같은 플랫폼을 빠르게 사용하는 경우 스냅샷과 롤백 기능이 유용합니다: 파일럿에 UI·규칙 변경을 배포하고 알림이 시끄러우면 빠르게 되돌릴 수 있습니다.
짧고 실용적인 설정 문서를 작성하세요: “데이터 소스 연결”, “SLA 생성”, “알림 테스트”, “알림 수신 시 할 일”. 제품 근처에 보관(예: /docs/sla-monitoring)하세요.
초기 채택 후 신뢰를 높이고 노이즈를 줄이는 개선을 우선순위에 두세요:\n\n- 이상 징후(비정상적 볼륨 또는 갑작스런 SLA 위험 스파이크)에 대한 간단한 탐지\n- 핵심 서비스용 고객 대상 상태 페이지(선택 사항)\n- 정기 운영 리포트(주간 SLA 요약, 주요 위반 원인, 추세선)
실제 인시던트에 기반해 반복하세요: 모든 알림은 자동화·명확화·제거할 항목을 가르쳐야 합니다.
SLA 모니터링 목표는 다음을 정의하는 측정 가능한 문장입니다:
다음과 같이 테스트할 수 있는 목표로 작성하세요: “잠재적 위반을 X초 이내에 감지하고 온콜에 Y분 이내에 알린다.”
“실시간”의 정의는 기술적으로 가능한 것보다 팀이 실제로 대응할 수 있는 능력에 맞춰 결정하세요.
핵심은 이벤트 → 계산 → 알림/대시보드의 엔드투엔드 지연 목표를 정하고 그에 맞춰 설계하는 것입니다.
실제로 위반할 수 있고(신용/페널티 대상이 될 수 있는) 고객 대상 약속을 우선 모니터하세요. 일반적으로:
많은 팀은 SLA보다 더 엄격한 내부 SLO도 함께 추적합니다. 둘 다 필요하다면 운영자가 조기에 대응하도록 내부 SLO를, 계약 준수를 위해 SLA를 모두 저장·표시하세요.
정의상의 문제가 종종 SLA 실패의 원인입니다. 다음을 명확히 하세요:
이 규칙들을 결정론적으로 인코딩하고 테스트용 예제 타임라인 라이브러리를 만들어 검증하세요.
일관된 캘린더 규칙을 정의하세요:
재사용 가능한 캘린더 모듈을 만들어 다음 질문에 일관되게 답하게 하세요:
필드별로 “시스템 오브 레코드”를 하나씩 정하고 시스템 간 불일치 시 어떤 값이 우선하는지 문서화하세요.
일반적 출처:
근실시간에는 웹훅을 선호하고, 누락된 이벤트와 조정을 위해 폴링/백필을 추가하세요.
최소한 SLA 시계를 시작·중지·변경하는 이벤트를 캡처하세요:
또한 운영자가 흔히 잊는 이벤트들(비즈니스 캘린더 업데이트, 시간대 변경, 휴일 일정 변경)도 고려하세요—이들은 티켓 활동 없이 기한을 바꿀 수 있습니다.
간단한 다섯 블록 파이프라인을 사용하세요:
수집단계에 SLA 로직을 넣지 말고, 대시보드에 무거운 계산을 두지 마세요. 단일 리전·최소 환경으로 시작해 데이터 품질과 알림 유용성이 검증되면 확장하세요.
필요와 긴급도에 따라 둘 다 사용하세요:
권장 하이브리드: 정확성을 위해 이벤트 기반 업데이트를 사용하고, 새로운 이벤트가 없을 때도 임계값 도달을 잡기 위해 분 단위 틱을 추가하세요(예: “15분 내 기한”).
알림을 워크플로로 다루세요. 노이즈를 줄이면서도 조기 포착을 유지하는 방법:
(work_item_id, sla_rule_id, alert_type) 같은 키로 중복 제거하고 상태 전환 시에만, 쿨다운을 적용해 알림을 보냅니다.모든 알림에는 소유자/온콜, 기한과 남은 시간, 다음 액션, /tickets/{id} 및 /sla/tickets/{id} 같은 링크를 포함하세요.