IncidentRelay v2.3.1에 대한 작업 예시(에 확인됨) 아래의 이름, 식별자 및 타이밍은 예시입니다. 프로덕션 자격 증명을 사용하기 전에 테스트 배포에서 이를 검증하세요.
비즈니스 예 · 설정 · 실제 예 · 승인 확인 · 한계 및 실패 모드
비즈니스 예: 사무실이 문을 닫은 후 체크아웃이 실패합니다.
고객 사례 연구가 아닌 예시 시나리오입니다. 아래 지표는 측정된 절감액이나 IR에 모든 보고 대시보드가 포함되어 있다는 주장이 아니라 파일럿을 위한 제안 사항입니다.
상황 및 위험. 온라인 상점에는 4명의 엔지니어가 있습니다. 22시 40분에 고객이 아직 체크아웃하는 동안 모니터링을 통해 실패한 결제 요청이 감지됩니다. 일반 채팅의 메시지에는 누가 문제를 처리하고 있는지 지원팀에 알려주지 않습니다. 완료되지 않은 구매와 늘어나는 지원 대기열은 비즈니스 위험입니다. 경고 자체는 신호일 뿐입니다.
IR 워크플로. 현재 기본 응답자에게 결제 알림을 보냅니다. 아무도 이를 승인하지 않으면 정책은 명명된 백업으로 이동됩니다. 배정된 엔지니어는 그룹을 인정하고 조사합니다. 지원팀에서는 합의된 사고 프로세스를 사용하여 해당 소유자를 찾고 업데이트를 얻을 수 있습니다. 아래의 실패 및 복구 쌍을 사용하여 이 체인을 테스트하세요.
검증을 통한 운영상의 이점. 사용 가능한 엔지니어에 대한 수동 검색을 사전 정의된 소유권 체인으로 대체합니다. 전달된 채팅 메시지를 누군가가 작업 중이라는 의미로 가정하기보다는 전달을 통해 책임을 가시적으로 유지하세요.
측정 대상. 실행 가능한 첫 번째 알림부터 ACK까지의 시간, 내부 목표 내에서 확인된 공유 및 수동 재할당 횟수를 기록합니다. 상거래 모니터링에서 실패한 체크아웃과 성공적으로 결제가 재개될 때까지의 시간을 별도로 추적합니다.
경계. IR은 결제 또는 결제 서비스 제공업체를 수리하지 않습니다. ACK는 고객이 다시 지불할 수 있음을 증명하지 않으며, 두 엔지니어 모두 연락할 수 없는 경우 에스컬레이션 정책이 도움이 될 수 없습니다. 대체 연락 경로와 실제 지불 복구 수표를 유지하세요.
엔지니어 4명, 청구 서비스 1개, 소유권 체인 1개
네 명의 엔지니어가 결제 API에 대한 지원을 공유한다고 가정합니다. 하나의 팀과 하나의 주간 기본 순환으로 시작하세요. 경로에 기본 서비스와 하나의 테스트된 전달 채널을 제공합니다. 백업 담당자를 명시적으로 추가합니다. 공유 채팅방은 에스컬레이션 정책이 아닙니다.
| 물체 | UI 설정 예시 |
|---|---|
| 이름 * | 팀 payments; 서비스 billing-api; 4명의 활성 회원과 24/7 적용 범위가 있는 순환 payments-primary입니다. |
| 섭취 | 소스 webhook, 기본 서비스 billing-api, 정책 에스컬레이션 모드 및 연결된 알림 채널. |
| 관련 기사 | 규칙 1: 기본 회전, 300초 지연. 규칙 2: 명명된 백업 사용자, 600초 지연. 이 파일럿에 대해 repeat_count=0을 설정합니다. |
경고를 보내기 전에 채널과 응답자 연락처를 구성하십시오. 전체 통화 중 상태 진단을 엽니다. 녹색 표 요약만으로는 향후 적용 범위를 검색하거나 메시지가 전화에 도달했음을 증명하지 않습니다.
하나의 실패를 보낸 다음 복구를 보냅니다.
Content-Type: application/json 및 Authorization: Bearer ROUTE_TOKEN를 사용하여 이 JSON 본문을 별도로 POST /api/integrations/webhook에 보냅니다. 자리 표시자를 UI의 테스트 경로 토큰으로 바꿉니다. 소스 제어 및 공유 로그에서 제외하십시오. 이는 정규화된 시뮬레이터 이벤트가 아닌 일반 웹훅 형식입니다.
{
"status": "firing",
"fingerprint": "billing-api:health:prod",
"title": "Billing API health check failed",
"severity": "critical",
"labels": {
"alertname": "BillingUnavailable",
"environment": "production",
"service": "billing-api"
}
}{
"status": "resolved",
"fingerprint": "billing-api:health:prod",
"title": "Billing API health check failed",
"severity": "critical",
"labels": {
"alertname": "BillingUnavailable",
"environment": "production",
"service": "billing-api"
}
}복구를 위해 동일한 경로, 지문 및 그룹화 레이블을 유지하십시오. 지문으로 어린이 경고를 식별합니다. 모든 요청에서 이를 새로운 임의의 값으로 변경하면 중복 제거가 무효화됩니다. 고아 복구는 새 그룹을 생성하지 않습니다.
실제 야간 근무 전에 체인을 증명하세요
- 발사체를 두 번 보냅니다. 하나의 하위 경고, 의도된 서비스 및 현재 기본 담당자를 예상합니다. 단지 HTTP 성공이 아니라 실제 배송을 확인하세요.
- 별도의 테스트 경고를 확인되지 않은 상태로 둡니다. 첫 번째 정책 지연 이후 백업이 대상이 되는지 확인합니다. 스케줄러 케이던스, 대기열 및 공급자 전달은 이것이 정확한 5분 전달 SLA가 아님을 의미합니다.
- 다른 테스트 그룹을 승인하고 보류 중인 실행 전용 알림이 중지되는지 확인합니다. 회복을 보내고 해고된 어린이가 더 이상 없을 때 그룹이 해결하는지 확인합니다.
- 임시 순환 재정의를 만들고 테스트를 반복합니다. 재정의가 유효한 담당자인지 확인한 후 테스트 구성을 제거합니다.
체인이 언제 멈추는지 알아보세요.
정책 모드에서는 팀 알림 기반 에스컬레이션이 무시됩니다. 모든 규칙과 허용된 반복이 소진되면 정책 미리 알림이 중지됩니다. 경고가 계속 실행될 수 있습니다. 근무하는 연락처가 없는 백업 담당자는 데이터베이스에 있는 이름일 뿐입니다.
ACK은 청구 서비스 복구가 아닌 소유권입니다. IR은 애플리케이션을 수리하거나 누락된 엔지니어를 제공할 수 없습니다. IR 또는 해당 알림 제공자를 사용할 수 없는 경우 팀에 연락할 수 있는 외부 방법을 유지하고 온보딩 중에 해당 대체에 동의하십시오.