IncidentRelay v2.3.1에 대한 작업 예시(에 확인됨) 아래의 이름, 식별자 및 타이밍은 예시입니다. 프로덕션 자격 증명을 사용하기 전에 테스트 배포에서 이를 검증하세요.
비즈니스 예 · 설정 · 실제 예 · 승인 확인 · 한계 및 실패 모드
비즈니스 예: 야간 백업 1회가 완료되지 않음
고객 사례 연구가 아닌 예시 시나리오입니다. 아래 지표는 측정된 절감액이나 IR에 모든 보고 대시보드가 포함되어 있다는 주장이 아니라 파일럿을 위한 제안 사항입니다.
상황 및 위험. 회사는 근무일이 시작되기 전에 두 대의 서버에 주문 데이터베이스를 백업합니다. 한 작업이 자동으로 중지됩니다. 다른 하나는 성공합니다. 단일 공유 성공 신호로 격차가 숨겨집니다. 비즈니스 위험은 복원이 필요할 때만 오래되었거나 누락된 복구 지점을 검색하는 것입니다.
IR을 사용한 워크플로. 완료 기한을 정의하고 각 예상 서버를 개별적으로 추적합니다. 호스트는 작업 및 성공 확인이 완료된 후에만 하트비트를 보냅니다. 완료가 누락되면 백업 에스컬레이션 경로와 함께 플랫폼 응답자에게 전달되는 기한 초과 알림이 생성됩니다. 엔지니어는 작업을 조사하거나 다시 실행하고 결과를 기록합니다.
검증을 위한 운영상의 이점. 다음 업무 교대 전에 자동으로 예약된 작업 실패를 자신의 작업으로 전환합니다. 완료 신호가 실제로 성공을 나타내는 경우 동일한 패턴이 예약된 내보내기 또는 일괄 작업에 적용될 수 있습니다.
측정 대상. 서버당 놓친 기한, 기한부터 확인까지의 시간, 최근에 확인된 백업의 기간을 추적합니다. 백업 확인 및 복원 훈련 결과를 백업 시스템 또는 운영 보고서에 보관합니다. 녹색 심장박동에서 이를 추론하지 마세요.
경계. 하트비트는 신호가 도착했음을 증명하는 것이지 데이터를 복원할 수 있다는 것을 증명하지는 않습니다. 복구 지점이나 복구 시간을 보장하지 않습니다. 복원을 독립적으로 테스트하고 동일한 오류 도메인 외부에서 IR 자체를 모니터링합니다.
페이징 시스템을 귀하가 운영하는 서비스로 취급하십시오.
프로덕션 클러스터와 야간 데이터베이스 백업을 담당하는 플랫폼 팀을 생각해 보세요. 모니터링 스택 근처에 IR이 필요하지만 이로 인해 팀을 깨우는 시스템을 담당하게 됩니다. 웹 서비스, 스케줄러, 데이터베이스, 비밀 및 복구 절차의 소유자를 지정합니다.
출시 Docker 설정은 웹 및 스케줄러 서비스를 별도로 실행합니다. 테스트 환경에서 배포 가이드를 따른 후 릴리스 체크아웃에서 검사하세요.
docker compose ps
docker compose logs --tail=50 incidentrelay
docker compose logs --tail=50 incidentrelay-scheduler
웹 프로세스는 들어오는 경고를 받아들입니다. 스케줄러는 알림, 에스컬레이션 및 정기 작업을 처리합니다. 모든 웹 작업자 내부에서 스케줄러를 시작하지 마십시오. 작동 중인 로그인 페이지는 시간 제한 에스컬레이션이 실행 중임을 증명하지 않습니다.
한 호스트에서 누락된 백업 감지
소스가 heartbeat인 경로에 연결된 UTC 기준 매일 03:00에 마감되는 예약 완료 하트비트를 만듭니다. 인스턴스 추적을 활성화합니다. 고정 집합의 경우 db-1 및 db-2와 같은 정적 예상 인스턴스를 사용합니다. 플랫폼 순환 또는 정책과 테스트 채널을 연결합니다.
호스트 백업 및 성공 확인이 완료된 후 이 본문을 JSON 콘텐츠 유형을 사용하여 POST /api/heartbeats/ping/HEARTBEAT_TOKEN에 보냅니다. 경로 토큰이나 관리 API 토큰이 아닌 해당 하트비트의 비밀 URL을 사용하십시오.
{
"status": "completed",
"instance": "db-1",
"payload": {
"job": "nightly-database-backup"
}
}
각 호스트에서 고유한 인스턴스 값을 보냅니다. 인스턴스 추적이 없으면 한 서버에서 성공적인 핑이 발생하면 다른 서버의 누락된 백업이 숨겨질 수 있습니다. 작업 실패 후 쉘 정리 핸들러에서 무조건 성공 핑을 보내지 마십시오. 프록시 및 작업 로그에서 비밀 ping URL을 수정합니다.
테스트 실패, 스타트업뿐만 아니라
- 두 예상 인스턴스를 모두 핑한 다음 짧은 테스트 일정에서 의도적으로 하나를 생략합니다. 정상 인스턴스가 정상 상태를 유지하는 동안 해당 인스턴스에 대한 기한이 지난 알림이 예상됩니다.
- 누락된 인스턴스를 재개합니다. 자동 해결이 활성화된 경우 다른 인스턴스의 오류를 해결하지 않고 기한이 지난 알림이 해결되는지 확인하세요.
- 테스트 배포에서만 스케줄러를 중지합니다. 시간 초과 작업에 미치는 영향을 관찰하고 독립 모니터가 이를 인지하고 있음을 증명합니다. 그런 다음 복원하고 처리를 확인하십시오.
- 아웃바운드 알림이 차단된 격리된 환경으로 데이터베이스, 구성 및 필수 비밀을 복원합니다. 전달을 허용하기 전에 이전 발사 그룹을 검토하여 복원 훈련이 생산 응답자를 호출할 수 없도록 합니다.
성공적인 핑은 복원 테스트가 아닙니다.
하트비트는 누락된 신호를 감지합니다. 활성 HTTP/TCP 프로브가 아니며 백업이 사용 가능하다는 것을 증명할 수 없습니다. IR은 또한 자체적인 전체 중단에 대해 확실하게 알릴 수 없습니다. 외부 가용성 확인과 동일한 장애 도메인 외부에 별도의 연락 경로를 유지하세요.
셀프 호스팅은 채팅, 이메일, 음성 또는 네트워크 종속성을 제거하지 않습니다. 워크로드에 적합한 데이터베이스 및 배포 모델을 결정하고, 테스트된 릴리스를 고정하고, 업그레이드 및 롤백을 연습해 보세요. 이러한 예에서는 고가용성 또는 처리량 보장을 설정하지 않습니다.
의도적으로 보관을 설정합니다. 해결된 알림 기록은 기본적으로 무기한 보관됩니다. 정리는 연결된 댓글과 배달 기록도 제거할 수 있으며 반드시 데이터베이스 파일을 축소하지는 않습니다. 보존은 백업을 대체할 수 없습니다.