IncidentRelay v2.3.1에 대한 작업 예시(에 확인됨) 아래의 이름, 식별자 및 타이밍은 예시입니다. 프로덕션 자격 증명을 사용하기 전에 테스트 배포에서 이를 검증하세요.
비즈니스 예 · 설정 · 실제 예 · 승인 확인 · 한계 및 실패 모드
비즈니스 예: SaaS 고객은 다양한 시간대에 걸쳐 작업합니다.
고객 사례 연구가 아닌 예시 시나리오입니다. 아래 지표는 측정된 절감액이나 IR에 모든 보고 대시보드가 포함되어 있다는 주장이 아니라 파일럿을 위한 제안 사항입니다.
상황 및 위험. B2B SaaS 팀은 유럽과 북미 지역의 고객에게 서비스를 제공합니다. 고객의 오후 근무 시간이 다른 엔지니어의 저녁 근무 시간과 겹치고 일반적인 응답자는 휴가 중입니다. 합의된 일정이 없으면 팀은 채팅을 먼저 알아차린 사람에게 의존합니다. 위험은 소유되지 않은 가동 중단과 근무 외 직원의 반복적인 중단입니다.
IR을 사용한 워크플로. 인력 배치에 동의한 다음 기본 순환 및 근무일 레이어로 표현합니다. 휴일 대체를 재정의로 기록하고 별도의 백업 에스컬레이션 대상을 구성합니다. 인수인계와 향후 공백을 확인하세요. 계획된 청구 배포의 경우 관련 없는 서비스가 계속 알림을 보내는 동안 서비스 범위 유지 관리 기간을 사용하세요.
검증을 통한 운영상의 이점. 휴가 및 인계를 포함하여 지원 및 엔지니어링에 대한 책임을 예측 가능하게 만듭니다. 계획된 작업에서는 회사 전체의 경고 스트림을 음소거할 필요가 있어서는 안 됩니다.
측정 대상. 팀의 응답 목표 내에서 향후 14일, 막판 수동 인계 및 확인과 같이 정의된 미래 기간에 발견되지 않은 시간(분)을 검토합니다. 실제 인력 배치 일정과 함께 엔지니어별 야간 알림을 비교하세요. 균형 잡힌 달력만으로는 작업량을 표시하지 않습니다.
경계. 달력이 채워져 있다고 해서 추가 직원이 생기거나 누군가가 응답할 수 있다는 것을 증명하는 것은 아닙니다. IR은 계약상 응답 시간을 보장하지 않으며 ACK에서 고객 가용성을 계산하지 않습니다. 더 광범위한 운영 프로세스에서 인력 배치 결정, SLO 모니터링, 고객 커뮤니케이션을 유지하세요.
근무일을 최적화하기 전에 밤을 가리십시오
SRE 팀이 근무일 교대 및 야간 순환에 걸쳐 청구 안정성을 보유하고 있다고 가정합니다. 한 번의 회전에서 우선순위가 10이고 제한되지 않은 24/7 적용 범위를 갖는 기본 레이어를 생성합니다. Europe/Berlin에 월요일~금요일, 09:00~18:00로 제한되는 우선순위가 20인 레이어를 추가하세요. 실제 활동하는 회원을 활용하고 생성된 달력을 확인해보세요.
우선순위가 가장 높은 활성 레이어가 양수인에게 제공됩니다. 재정의는 레이어보다 우선합니다. 이들은 두 명의 동시 응답자가 아닙니다. 백업 범위에 대해 별도의 에스컬레이션 대상 또는 순환을 구성합니다. 활성화된 레이어가 없고 재정의가 적용되지 않으면 담당자가 없습니다. 회전 및 레이어 규칙을 참조하세요.
계획된 배포 중에 청구 알림 일시 중지
인터페이스를 통해 서비스 범위 창을 생성하거나 범위 수정 권한이 있는 인증된 관리-API 세션을 사용하여 이 구성을 POST /api/maintenance-windows에 제출합니다. 섭취 경로 토큰은 관리 자격 증명이 아닙니다. 42을 실제 결제 서비스 ID로 바꾸고 향후 테스트 기간을 선택하세요.
{
"name": "Billing deploy",
"behavior": "suppress_notifications",
"timezone": "Europe/Berlin",
"starts_at": "2026-10-20T10:00:00",
"ends_at": "2026-10-20T11:00:00",
"enabled": true,
"scopes": [
{
"scope_type": "service",
"service_id": 42
}
]
}이러한 타임스탬프는 선택한 시간대의 벽시계 시간이며 Z가 생략된 UTC 값이 아닙니다. 이 기간 동안 수신 청구 알림은 계속 표시되지만 알림, 미리 알림 및 에스컬레이션은 일시 중지됩니다. 다른 서비스는 영향을 받지 않습니다. 이 동작은 새 AlertGroup을 방지하는 suppress_incident 또는 알림을 활성화된 상태로 유지하는 pause_escalation_only가 아닙니다.
교대근무 중간뿐만 아니라 경계를 테스트하십시오.
- 주말 및 일광 절약 시간제 전환 기간 동안 09:00 및 18:00 직전과 직후에 과제를 검사합니다. 임시 재정의를 추가하고 성공했는지 확인한 후 제거합니다.
- 전체 통화 중 상태 점검을 엽니다. 확인된 미래 기간, 공백, 비활성 회원 및 사용 가능한 전달 방법을 검토하십시오. 녹색 요약은 영원히 보장되거나 전화로 전달된다는 증거가 아닙니다.
- 점검 중 결제 및 관련 없는 서비스 테스트 이벤트를 전송합니다. 청구가 표시되지만 조용하고 관련 없는 서비스에서 계속 알림을 보내는지 확인하세요. 이미 해결되지 않은 경고를 포함하려면 기존 경고에 창을 적용하는 옵션을 명시적으로 활성화합니다. 기본적으로 꺼져 있습니다.
- 기간이 종료되면 청구 실행을 그대로 둡니다. 재활성화를 활성화하면 놓친 알림을 모두 재생하지 않고 정상적인 알림이 다시 시작되는지 확인합니다. 실제 응답자가 이를 수신하고 승인할 수 있는지 확인하십시오.
조용한 서비스는 복구된 서비스가 아닙니다.
유지 관리는 서비스를 복구하거나 전달된 메시지를 철회하거나 해결을 의미하지 않습니다. 기본적으로 재활성화는 활성화되어 있습니다. 비활성화하면 창이 종료된 후에도 유지 관리 효과가 유지됩니다. 겹치는 창은 마지막으로 적용 가능한 활성 또는 유지 효과가 해제될 때까지 경고를 조용하게 유지할 수 있습니다. 유지관리 가이드에서 이러한 제어 기능을 검토하세요.
모니터링 스택에 SLO 계산 및 연소율 감지를 유지하세요. IR은 결과 신호를 라우팅하고 조정합니다. AlertGroup은 기술 승인, 해결, 알림 및 에스컬레이션을 소유합니다. 사고는 별도의 운영 워크플로입니다. 여러 AlertGroup을 하나의 사고에 연결해도 기술 기록이 병합되지 않습니다. v2.3.1에서는 응답자와 이해관계자가 여전히 AlertGroups에 속합니다. 사고 상태 변경을 AlertGroup ACK으로 처리하는 대신 두 수명주기를 모두 테스트하십시오.