IncidentRelay 팀의 비교입니다. 에 검토된 문서입니다. IncidentRelay 범위: v2.3.1. 이는 성능 벤치마크나 기능 동등성에 대한 약속이 아닌 문서 기반 평가입니다.
빠른 결정 · 기능 · 이전 제한 · 파일럿 체크리스트
종료 날짜부터 시작
Opsgenie은(는) 2025년 6월 4일에 신규 판매를 중단했습니다. Atlassian은 마이그레이션되지 않은 고객 데이터를 삭제하고 2027년 4월 5일에 종료할 것이라고 밝혔습니다. 이것은 단지 새로운 기능의 끝이 아닙니다. 기존 사용자에게는 대상과 데이터 보존 계획이 필요합니다. 공식 Opsgenie 이전 공지를 참조하세요.
팀이 Atlassian Cloud를 유지하고 연결된 서비스 관리 워크플로를 유지하기를 원하는 경우 Jira Service Management을(를) 평가하세요. 자체 인프라에서 의도적으로 오픈소스 대기 시스템을 운영하고 가용성, 업그레이드, 백업을 소유할 수 있다면 IncidentRelay을(를) 평가해 보세요.
셀프 호스팅은 마이그레이션 작업에 대한 지름길이 아닙니다. 목적지를 소유한 사람이 변경됩니다. 호스팅 및 엔지니어링 노력을 일대일 라이센스 교체 가정이 아닌 실제 대상 계획, 사용자 역할 및 알림 요구 사항과 비교하십시오.
실제로 무엇을 움직이고 있는지
| 결정 | IncidentRelay v2.3.1 | Atlassian 마이그레이션 경로 |
|---|---|---|
| 운영 모델 | 자체 호스팅, 오픈 소스 애플리케이션. 귀하의 팀이 배포를 운영합니다. | 마이그레이션 도구는 Jira Service Management Data Center가 아닌 Atlassian Cloud를 대상으로 합니다. |
| 일정 및 에스컬레이션 | 순환, 레이어, 재정의 및 에스컬레이션 규칙을 다시 작성합니다. On-call Health를 통해 확인하세요. | Atlassian은 지원되는 구성의 자동 마이그레이션을 제공합니다. 결과 일정과 정책을 검토합니다. |
| 이벤트 라우팅 | 전역 및 서비스 조정, 정규화된 라벨, 시뮬레이션, 재생 및 섀도우 모드. | 통합 변경 사항 및 더 이상 사용되지 않는 기능을 검토합니다. 세입자를 이동한다고 해서 동일한 동작이 보장되는 것은 아닙니다. |
| 공지사항 | 채팅, 이메일, 음성 채널 및 프로필 수준 브라우저/PWA 푸시. 공급자와 연락처를 직접 구성하십시오. | 기존 Opsgenie 서비스를 끄기 전에 모바일 앱 변경 사항 및 알림 설정을 검토하세요. |
| 사고 모델 | AlertGroups는 기술 페이징을 처리합니다. 별도의 사고가 운영 워크플로를 조정합니다. | 사고 대응은 Jira Service Management으로 이동합니다. 현재 프로세스와 비교하여 기능 변경 사항을 확인하세요. |
Atlassian 경로에 대해서는 마이그레이션 일정 및 Cloud/Data 센터 지침과 기능 변경 체크리스트를 읽어보세요. 이 페이지에서는 해당 경로를 IR과 비교합니다. Opsgenie와 Jira Service Management를 동일한 제품으로 취급하지 않습니다.
IR로의 이동은 테넌트 가져오기가 아닌 재구축입니다.
IR v2.3.1에는 Opsgenie용 가져오기 도구가 없습니다. 이 릴리스의 마이그레이션 도구는 PagerDuty와 Grafana OnCall OSS를 지원합니다. 해당 도구의 가져오기 보장 범위를 Opsgenie 내보내기 파일에 적용해서는 안 됩니다.
- 사람 및 일정: 팀, 멤버십, 순환, 시간 제한 및 재정의를 다시 만듭니다. 주말 및 일광 절약 시간제 변경을 포함하여 전체 주기에 걸쳐 실제 할당된 응답자를 비교합니다.
- 통합 및 중복 제거: 각 발신자, 인증 및 알림 ID를 조사합니다. 지원되는 IR 통합을 사용하거나 이벤트를 일반 웹훅 계약에 매핑하세요. Opsgenie API 키 또는 페이로드는 IR에서 자동으로 유효하지 않습니다.
- 정책 및 전달: 라우팅 및 에스컬레이션을 의도적으로 재구성합니다. 새로운 비밀, 사용자 연락처 세부 정보 및 알림 채널을 구성합니다. 복사된 일정이 누구에게나 알릴 수 있다고 가정하지 마십시오.
- 기록 및 자동화: 필요한 기록과 인벤토리 스크립트, API 클라이언트, 티켓 링크 및 대응 작업을 별도로 보존합니다. 구성 재생성은 사고 기록을 가져오거나 Opsgenie API 호환성을 제공하지 않습니다.
IR 2.3은 기술적인 AlertGroup을 운영 사고와 분리합니다. 하나의 사건은 기술 기록을 병합하지 않고도 여러 AlertGroup을 연결할 수 있습니다. 승인 및 에스컬레이션은 여전히 AlertGroup의 관심사입니다. 대응자와 이해관계자는 이번 릴리스에서도 여전히 AlertGroup 범위에 속합니다. 기존 대응 프로세스를 매핑하기 전에 사고 관리 경계를 읽어보세요.
명시적인 롤백 지점이 있는 파일럿
- Opsgenie 기한, 마이그레이션 소유자 및 필수 내보내기 기록을 기록하세요. Atlassian 마이그레이션도 예약하는 경우 병렬 액세스 기간을 고려하세요. 최종 제품이 종료될 때까지 이전 테넌트를 계속 사용할 수 있다고 가정하지 마십시오.
- 테스트 IR 배포에서 하나의 대표 팀을 구성합니다. 전체 순환 주기, 재정의, 에스컬레이션 지연 및 최초 대응자가 확인하지 않을 때의 동작을 비교합니다.
- 삭제된 실행, 복제 및 복구 이벤트를 재생합니다. 선택한 팀, 그룹화 키, 서비스, 알림 채널을 확인하세요. 파일럿 중에 승인을 소유한 시스템을 결정합니다.
- 근무 시간 이후 조건을 포함하여 실제 응답자 장치에서 테스트 전달을 수행합니다. 통화 중 상태를 사용하고 메시지와 전화가 실제로 도착하는지 확인하세요.
- 위험도가 낮은 발신자 한 명을 바꾸십시오. Opsgenie이(가) 활성 상태인 동안 이전 구성을 사용 가능하게 유지하고 중복 프로덕션 알림을 방지하세요. 통화 주기를 관찰한 후에만 확장하세요.
삭제된 테넌트에 따라 롤백을 수행하지 마세요.
Atlassian은 Opsgenie를 끄는 것은 되돌릴 수 없다고 말합니다. 또한 더 일찍 끄지 않으면 Atlassian 마이그레이션 후 120일이 지나면 자동으로 종료됩니다. 해당 기간은 무기한 대체를 약속하지 않습니다. 종료 전에 검증을 완료하고 필요한 기록을 보존하십시오. Opsgenie이(가) 꺼지면 어떻게 되는지 알아보세요.
테스트 배포부터 시작하세요. 필요한 워크플로우를 재현할 수 없거나 대상을 작동할 수 있는 사람이 없는 경우 프로덕션 발신자를 변경하기 전에 해당 격차를 해결하십시오.
Opsgenie 및 Jira Service Management은 Atlassian 제품입니다. IncidentRelay은(는) Atlassian과 제휴하지 않습니다.