已解决：最佳 OpsGenie 替代方案？sunset 正在迫使迁移，50 人工程团队

Source: Dev.to

请提供您希望翻译的正文内容，我将为您翻译成简体中文并保留原有的格式、Markdown 语法以及技术术语。

挑战：OpsGenie 停运与迁移痛点

在截止日期驱动的强制迁移中，常会出现超出单纯功能替换的各种挑战。了解这些症状是实现成功转型的第一步。

强制迁移的症状

• 关键功能丢失 – 值班轮值、中断警报路由以及事件沟通工作流受到影响。
• 紧迫的时间表 – 停运往往不会提前多年通知，导致评估、选型、迁移和培训的时间被压缩。
• 功能等价需求 – 团队需要一个能够匹配或超越 OpsGenie 能力的替代方案（复杂的升级策略、多渠道通知、丰富的集成）。
• 成本敏感 – 新的定价模型需要仔细的预算考量和论证。
• 集成负担 – 与数十种监控工具（Prometheus、Grafana、Datadog）、日志平台（ELK、Splunk）以及沟通工具（Slack、Teams）复制集成是一项重大工作。
• 用户采纳与培训 – 新的 UI 和工作流会带来学习曲线，初期可能影响事件响应时间。
• 数据迁移复杂性 – 转移现有的值班表、升级策略以及过去的事件数据（如有需要）并非易事。

方案 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 中创建一个 service 并添加 Prometheus 集成。
2. 集成会生成上面使用的 YOUR_PAGERDUTY_INTEGRATION_KEY。
3. 将该服务分配给升级策略和值班排班。

优缺点

Solution 2: Splunk On‑Call（formerly VictorOps） – The Incident Hub

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

• 与某些替代方案相比，尤其是高级功能，成本可能更高。
• 对部分用户而言，界面可能不如 PagerDuty 那么精致。
• 虽然集成生态系统稳健，但规模可能不及 PagerDuty。

解决方案 3：Grafana OnCall – 集成式开源友好选项

Grafana OnCall 是相对较新的产品，但正快速获得关注，尤其是在已经大量使用 Grafana 进行监控和可观测性的团队中。它在 Grafana 生态系统内直接提供集成的值班管理功能。

概览与关键特性

• 原生 Grafana 集成 – 与 Grafana Alerting、仪表盘和数据源无缝连接。
• 值班排班 & 升级链 – 直观设置复杂轮值和通知路径。
• 告警分组 – 自动将相关告警归为一组，降低噪音。
• ChatOps 集成 – 可连接 Slack、Microsoft Teams 等进行事件沟通。
• 公共 API – 用于自动化和自定义集成。
• 开源核心（自托管） – 也提供托管的 Grafana Cloud 方案，但开源版本支持自行部署。

迁移注意事项

对于已经使用 Grafana 进行监控的团队，迁移路径大大简化。重点在于定义值班排班、创建升级链，并配置 Grafana Alerting 的联系点，将通知发送至 Grafana OnCall。若排班非常复杂，可能需要通过 API 导入数据。

示例配置：创建基础值班组和告警路由

假设您正在使用 Grafana Alerting：

1. 创建值班团队 – 在 Grafana OnCall 中创建一个团队（例如 “SRE Team”）。
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

迁移的关键考虑因素

功能等价性与必备要素

• 关键警报: 路由、去重、抑制等不可妥协的要求。
• 值班逻辑: 是否需要复杂的轮值、分层升级、地区覆盖？
• 沟通渠道: 必需的方式（短信、语音、推送、Slack、Teams）。
• 事件自动化: 您依赖的运行手册自动化或自动修复功能。

成本分析

• 许可模式: 按用户计费、层级限制、通话/短信的额外费用。
• 隐藏成本: 实施服务、培训、集成开发。
• 投资回报率: 长期价值——节省的事件解决时间、提升的效率。

集成生态系统

• 现有监控: 列出工具（Prometheus、Datadog、New Relic 等），并确认原生集成。
• 沟通工具: 确保 Slack、Microsoft Teams 或其他平台的无缝集成。
• 工单与项目管理: 寻找 Jira、ServiceNow、Pendo 等的集成，以进行事件跟踪。

迁移便利性与数据导入

• API 能力: 强大的 API，用于自动转移排班、用户、集成等。
• 迁移工具: 供应商或社区提供的脚本/工具，帮助过渡。
• 历史数据: 决定是迁移过去的事件还是重新开始。

团队熟悉度与培训

• 用户体验: 与小团队进行试用，以评估 UI/UX。
• 培训资源: 文档、教程、支持的可用性。
• 变更管理: 规划内部沟通和培训课程，以实现平稳采用。

结论

从 OpsGenie 强制迁移是一次重新评估并优化事件管理策略的机会。虽然 PagerDuty、Splunk On‑Call 和 Grafana OnCall 都提供了有力的替代方案，但“最佳”选择取决于：

• 您团队的具体需求。
• 现有技术栈。
• 预算限制。
• 所需功能集。

我们建议采用结构化的方法：对当前流程进行彻底的内部审计，开展入围方案的试点评估，并在决定迁移路径之前权衡上述权衡因素。

OpsGenie 使用情况：优先考虑必备功能

要深入评估这三种解决方案，进行试用并考虑 50 人工程团队的集成便利性和用户采纳度。通过采用系统化的方法，您可以将此挑战转化为提升事件响应能力和运营韧性的机会。