해결됨: 최고의 OpsGenie 대안은? sunset 때문에 마이그레이션이 강제되고, 50명 엔지니어링 팀

Source: Dev.to

도전 과제: OpsGenie 서비스 종료와 마이그레이션 어려움

기한이 있는 강제 마이그레이션은 단순히 기능 교체를 넘어서는 다양한 문제들을 드러냅니다. 이러한 증상을 이해하는 것이 성공적인 전환을 위한 첫 번째 단계입니다.

강제 마이그레이션의 증상

• 핵심 기능 손실 – 온콜 순환, 알림 라우팅, 사고 커뮤니케이션 워크플로우가 중단됩니다.
• 긴급 일정 – 서비스 종료는 보통 몇 년 전 통보가 없으며, 평가, 선택, 마이그레이션 및 교육을 위한 압축된 일정이 필요합니다.
• 기능 동등성 요구 – 팀은 OpsGenie의 기능(복잡한 에스컬레이션 정책, 다채널 알림, 광범위한 통합)을 충족하거나 능가하는 대체 솔루션이 필요합니다.
• 비용 민감도 – 새로운 가격 모델은 신중한 예산 검토와 정당화가 필요합니다.
• 통합 과부하 – 수십 개의 모니터링 도구(Prometheus, Grafana, Datadog), 로깅 플랫폼(ELK, Splunk), 커뮤니케이션 도구(Slack, Teams)와의 통합을 복제하는 것은 큰 작업입니다.
• 사용자 채택 및 교육 – 새로운 UI와 워크플로우는 학습 곡선을 만들며 초기에는 사고 대응 시간에 영향을 줄 수 있습니다.
• 데이터 마이그레이션 복잡성 – 기존 온콜 일정, 에스컬레이션 정책 및 과거 사고 데이터(원할 경우)를 이전하는 것은 간단하지 않을 수 있습니다.

Source: …

Solution 1: PagerDuty – 업계 표준

PagerDuty는 인시던트 관리 분야에서 금본위제로 여겨지며, 온콜 스케줄링, 인시던트 라우팅, 정교한 자동화 기능을 갖춘 성숙하고 견고한 플랫폼을 제공합니다.

개요 및 주요 기능

PagerDuty는 사실상 모든 소스에서 알림을 중앙집중화하고, 서비스와 긴급도에 따라 지능형 라우팅을 적용하여 인시던트가 적시에 적절한 사람에게 전달되도록 합니다. 주요 강점은 다음과 같습니다:

• 고급 온콜 스케줄링 – 복잡한 로테이션, 오버라이드 및 핸드오프 지원.
• 풍부한 에스컬레이션 정책 – 인시던트가 확인될 때까지 다단계·다채널 알림 제공.
• 광범위한 통합 – 수백 개의 즉시 사용 가능한 통합과 강력한 API 제공.
• 인시던트 대응 자동화 – 런북, 자동화 액션, 사후 인시던트 분석 도구.
• 분석 및 보고 – 인시던트 발생 빈도, 해결 시간, 팀 성과에 대한 상세 메트릭 제공.

마이그레이션 고려 사항

PagerDuty로 마이그레이션할 때 일반적으로 수행하는 작업:

1. 온콜 스케줄 및 에스컬레이션 정책 재구성.
2. PagerDuty Events API 또는 기본 제공 통합을 통해 모니터링 도구 연동.
3. 강력한 API를 호출하는 스크립트를 사용해 대량 작업 자동화.

역사적 인시던트 데이터는 API를 통해 가져올 수 있지만, 강제 마이그레이션 시에는 종종 우선순위가 낮아집니다.

예시 구성: Prometheus Alertmanager와 연동

# alertmanager.yml configuration snippet
route:
  receiver: 'default-pagerduty'

receivers:
  - name: 'default-pagerduty'
    pagerduty_configs:
      - service_key: 'YOUR_PAGERDUTY_INTEGRATION_KEY'  # Generated in PagerDuty for a specific service.
        severity: '{{ .CommonLabels.severity | title }}'
        details:
          instance: '{{ .CommonLabels.instance }}'
          alertname: '{{ .CommonLabels.alertname }}'
          description: '{{ .CommonAnnotations.description }}'
          summary: '{{ .CommonAnnotations.summary }}'
        group: '{{ .CommonLabels.alertname }}'
        class: '{{ .CommonLabels.job }}'
        component: '{{ .CommonLabels.component }}'
        client: 'Prometheus Alertmanager'
        client_url: 'http://alertmanager.example.com'

1. PagerDuty에서 서비스를 생성하고 Prometheus 통합을 추가합니다.
2. 통합 과정에서 위에 사용된 YOUR_PAGERDUTY_INTEGRATION_KEY가 생성됩니다.
3. 해당 서비스를 에스컬레이션 정책 및 온콜 스케줄에 할당합니다.

장단점

Solution 2: Splunk On‑Call (formerly VictorOps) – The Incident Hub

Splunk On‑Call, previously VictorOps, positions itself as a real‑time incident management platform focused on the entire incident lifecycle, emphasizing collaboration and communication across the engineering team.

Overview & Key Features

• Visual Incident Timeline – 알림, 확인, 해결을 연대기적으로 보여주는 뷰.
• Rich Chat & Collaboration – Slack, Microsoft Teams 등 다양한 채팅 플랫폼과의 네이티브 통합을 통해 실시간 커뮤니케이션 지원.
• Automated Routing & Escalations – 정책 기반 라우팅 및 다중 채널 알림.
• Runbooks & Playbooks – 알림에서 직접 트리거할 수 있는 내장 런북.
• Post‑Incident Reporting – 자동화된 사후 분석 및 메트릭 대시보드.

Migration Considerations

PagerDuty와 마찬가지로 마이그레이션 시 온콜 일정, 에스컬레이션 정책을 설정하고 기존 모니터링 도구와 연동해야 합니다. Splunk On‑Call은 Generic API와 이메일 연동을 제공하며 매우 유연합니다. Transmogrifier는 마이그레이션 중 다양한 소스에서 들어오는 알림을 정규화하는 데 큰 도움이 될 수 있습니다.

Example Configuration: Sending Alerts via Generic API

# Example using curl to send a critical alert to Splunk On‑Call's Generic REST Endpoint
# Replace YOUR_ROUTING_KEY with the key found in your Splunk On‑Call integrations setup.
# The routing key determines which team/service receives the alert.

curl -X POST -H "Content-Type: application/json" -d '{
  "message_type": "CRITICAL",
  "entity_id": "server-001/cpu_usage",
  "state_message": "CPU usage on server-001 is 95% for 5 minutes",
  "monitoring_tool": "Custom Monitor",
  "host": "server-001",
  "description": "High CPU utilization detected.",
  "check": "cpu_usage",
  "alert_url": "http://dashboard.example.com/server-001"
}' "https://alert.victorops.com/integrations/generic/20131114/alert/YOUR_ROUTING_KEY"

# For a recovery message, change message_type to "RECOVERY"
curl -X POST -H "Content-Type: application/json" -d '{
  "message_type": "RECOVERY",
  "entity_id": "server-001/cpu_usage",
  "state_message": "CPU usage on server-001 has returned to normal (30%)",
  "monitoring_tool": "Custom Monitor",
  "host": "server-001",
  "description": "High CPU utilization resolved.",
  "check": "cpu_usage"
}' "https://alert.victorops.com/integrations/generic/20131114/alert/YOUR_ROUTING_KEY"

이와 같은 유연성 덕분에 네이티브 연동이 없는 커스텀 스크립트나 레거시 모니터링 시스템과도 손쉽게 통합할 수 있습니다.

Pros & Cons

Pros

• 실시간 인시던트 커뮤니케이션 및 협업에 뛰어남.
• Transmogrifier를 통한 강력한 알림 처리 및 정규화 기능.
• 전체 인시던트 라이프사이클에 집중.
• 기능과 사용 편의성의 좋은 균형.

Cons

• 일부 대안에 비해 비용이 높을 수 있으며, 특히 고급 기능을 사용할 경우 비용이 크게 증가.
• UI가 PagerDuty에 비해 다소 다듬어지지 않은 느낌을 줄 수 있음.
• 통합 생태계가 견고하지만 PagerDuty만큼 방대하지는 않음.

솔루션 3: Grafana OnCall – 통합 오픈‑소스 친화적 옵션

Grafana OnCall은 비교적 최신 진입자이지만, 특히 이미 Grafana를 모니터링 및 가시성에 많이 활용하고 있는 팀들 사이에서 빠르게 인기를 얻고 있습니다. Grafana 생태계 내에서 온‑콜 관리 기능을 직접 통합해서 제공합니다.

개요 및 주요 기능

• 네이티브 Grafana 통합 – Grafana Alerting, 대시보드, 데이터 소스와 원활하게 연결됩니다.
• 온‑콜 일정 및 에스컬레이션 체인 – 복잡한 순환 및 알림 경로를 직관적으로 설정할 수 있습니다.
• 알림 그룹 – 관련 알림을 자동으로 그룹화해 잡음을 줄여줍니다.
• ChatOps 통합 – Slack, Microsoft Teams와 연동해 사고 커뮤니케이션을 지원합니다.
• 공개 API – 자동화 및 맞춤형 통합을 위한 API를 제공합니다.
• 오픈‑소스 코어(셀프‑호스팅 가능) – 관리형 Grafana Cloud 서비스도 존재하지만, 오픈‑소스 버전을 사용하면 자체 호스팅이 가능합니다.

마이그레이션 고려 사항

이미 Grafana를 모니터링에 사용하고 있는 팀이라면 마이그레이션 경로가 크게 간소화됩니다. 온‑콜 일정을 정의하고, 에스컬레이션 체인을 만들며, Grafana Alerting 연락 지점을 Grafana OnCall에 연결하는 데 집중하면 됩니다. 일정이 매우 복잡한 경우 API를 활용해 데이터를 가져와야 할 수도 있습니다.

예시 구성: 기본 온‑콜 그룹 및 알림 라우트 설정

Grafana Alerting을 사용하고 있다고 가정합니다.

1. 온‑콜 팀 생성 – Grafana OnCall에서 팀을 생성합니다(예: “SRE 팀”).
2. 사용자 및 일정 정의 – 팀에 엔지니어를 추가하고 온‑콜 일정을 설정합니다(예: 주간 순환).
3. 에스컬레이션 체인 생성 – 알림이 어떻게 에스컬레이션되는지 정의합니다(예: 현재 온‑콜 담당자 → 팀 리드 → 전체 팀에게 Slack 알림).
4. Grafana Alerting 연락 지점 구성 – Grafana Alerting을 OnCall 통합에 연결합니다.

# Conceptual steps in Grafana UI or via Terraform for Grafana Alerting

# 1. Create OnCall User Group in Grafana OnCall (UI)
#    - Group Name: "Primary SRE On-Call"
#    - Add Members: UserA, UserB, UserC
#    - Define Weekly Rotation Schedule

# 2. Create Escalation Chain in Grafana OnCall (UI)
#    - Chain Name: "Critical SRE Escalation"
#    - Step 1: Notify "Primary SRE On-Call" via Mobile App, SMS (after 0 min)
#    - Step 2: Notify "Primary SRE On-Call" via Phone Call (after 5 min)
#    - Step 3: Notify "SRE Managers" (another OnCall group) via Slack (after 10 min)

# 3. Create a Contact Point in Grafana Alerting (UI or Terraform)
#    - Name: "OnCall SRE Critical"
#    - Type: "Grafana OnCall"
#    - OnCall URL: (auto‑populated if using the managed service)

위 단계들은 Grafana 기반 모니터링을 완전한 온‑콜 및 사고 대응 시스템으로 확장하는 일반적인 워크플로우를 보여줍니다.

Grafana OnCall 통합 예시

아래는 Grafana 알림을 Grafana OnCall 연락 지점 및 에스컬레이션 체인에 연결하는 간결한 단계별 안내입니다.

1. OnCall 에스컬레이션 체인 만들기

resource "grafana_oncall_escalation" "critical_sre" {
  name = "Critical SRE Escalation"
  # … define steps, users, and rules here …
}

2. 에스컬레이션을 사용하는 연락 지점 정의

resource "grafana_contact_point" "oncall_sre_critical" {
  name = "OnCall SRE Critical"

  grafana_managed_alert {
    type = "oncall"
    settings = {
      escalation_id = grafana_oncall_escalation.critical_sre.id   # reference the escalation above
      # Additional settings (message templates, etc.) can be added here
    }
  }
}

3. 연락 지점을 알림 정책에 연결

1. Grafana 알림 규칙을 엽니다 (예: “High CPU Usage”).
2. Contact Point 드롭다운에서 “OnCall SRE Critical.” 을 선택합니다.

이 긴밀한 통합을 통해 Grafana에서 생성된 알림이 OnCall 시스템으로 직접 전달되며, 정의된 모든 일정 및 에스컬레이션 경로를 활용합니다.

비교 분석: PagerDuty vs. Splunk On‑Call vs. Grafana OnCall

마이그레이션을 위한 주요 고려 사항

기능 동등성 및 필수 요소

• Critical Alerting: 라우팅, 중복 제거, 억제에 대한 필수 조건.
• On‑Call Logic: 복잡한 로테이션, 단계별 에스컬레이션, 지역별 오버라이드가 필요합니까?
• Communication Channels: 필요한 방법(SMS, 음성, 푸시, Slack, Teams).
• Incident Automation: 의존하는 런북 자동화 또는 자동 복구 기능.

비용 분석

• Licensing Model: 사용자당 비용, 티어 제한, 통화/SMS 추가 요금.
• Hidden Costs: 구현 서비스, 교육, 통합 개발.
• ROI: 장기 가치—사고 해결 시간 절감, 효율성 향상.

통합 생태계

• Existing Monitoring: 도구 목록(Prometheus, Datadog, New Relic 등) 및 기본 통합 확인.
• Communication Tools: Slack, Microsoft Teams 등 플랫폼과의 원활한 통합 보장.
• Ticketing & Project Management: 사고 추적을 위한 Jira, ServiceNow, Pendo 등 통합 확인.

마이그레이션 용이성 및 데이터 가져오기

• API Capabilities: 일정, 사용자, 통합 자동 전송을 위한 강력한 API.
• Migration Tools: 전환을 돕는 공급업체 또는 커뮤니티 스크립트/도구.
• Historical Data: 과거 사고를 마이그레이션할지 새로 시작할지 결정.

팀 친숙도 및 교육

• User Experience: 소규모 팀으로 시험 운영하여 UI/UX 평가.
• Training Resources: 문서, 튜토리얼, 지원 여부.
• Change Management: 원활한 도입을 위한 내부 커뮤니케이션 및 교육 세션 계획.

결론

OpsGenie에서 강제 마이그레이션은 인시던트 관리 전략을 재평가하고 최적화할 수 있는 기회입니다. PagerDuty, Splunk On‑Call, Grafana OnCall 각각이 매력적인 대안을 제공하지만, “최선” 선택은 다음에 달려 있습니다:

• 팀의 구체적인 요구 사항
• 기존 기술 스택
• 예산 제약
• 원하는 기능 세트

구조화된 접근 방식을 권장합니다: 현재 프로세스에 대한 철저한 내부 감사를 수행하고, 후보 솔루션에 대해 파일럿 평가를 진행한 뒤, 위에서 제시한 트레이드‑오프를 비교하여 마이그레이션 경로를 결정하십시오.

OpsGenie 사용: 반드시 가져야 할 기능 우선순위

세 솔루션을 깊이 있게 평가하고, 50인 규모의 엔지니어링 팀에 대한 통합 용이성 및 사용자 채택을 고려하여 시험 운영해 보세요. 체계적인 접근 방식을 취하면 이 도전을 인시던트 대응 역량 및 운영 회복력을 강화할 수 있는 기회로 전환할 수 있습니다.