Opsgenie 停服倒计时：2027 年关闭时间与替代方案

Opsgenie 将于 2027 年 4 月 5 日正式关闭。届时产品将无法访问，现有集成和 REST API 会停止工作，未完成迁移的客户数据也将被删除。

对大多数团队来说，迁移到 Jira Service Management 是最稳妥的完整替代方案。但如果你主要把 Opsgenie 用来将监控事件变成高优先级手机告警，现在也正是重新判断需求的好时机：你需要的是完整的事件管理平台，还是一个更轻量的通知层？

本文梳理停服时间、受影响功能和迁移选项，帮助你在值班链路出现空档前完成切换。

Opsgenie 停售与停服时间表

日期	变化
2025 年 3 月 4 日	Atlassian 宣布 Opsgenie 停售和终止支持计划。
2025 年 6 月 4 日	Opsgenie 停止新销售，无法再升级、降级套餐或新增站点。
2027 年 4 月 5 日	Opsgenie 关闭，产品无法访问，未迁移数据被删除。

现有客户在最终关闭前仍可继续使用，但把迁移留到最后几周会带来不必要的风险。最新时间以 Opsgenie 官方迁移页面和 Opsgenie 许可 FAQ 为准。

2027 年 4 月 5 日之后哪些功能会失效？

Opsgenie 关闭后，所有仍依赖它的链路都会中断，包括：

Opsgenie 告警和值班工作流
Opsgenie 移动应用
尚未迁移的集成
Opsgenie REST API
未迁移的数据和配置

风险并不只在管理后台。监控工具可能仍能发现故障，但旧 Opsgenie 集成会变成没有接收方的死链。Atlassian 在停用 Opsgenie 后会发生什么一文中明确建议先迁移全部告警和值班工作流。

官方替代方案：Jira Service Management

如果你需要保留 Opsgenie 的完整运行模式——告警、排班、升级策略、事件流程和历史数据——Jira Service Management 是默认选择。

Opsgenie 所有者可以进入 Settings → Plan your move，查看推荐的 Jira Service Management 套餐并安排迁移。确定目标套餐后，大部分数据和配置可由 Atlassian 自动同步。

但不要假设所有功能都会原样迁移。Atlassian 的功能变化与弃用清单列出了受套餐限制的联系方式、已弃用功能、需要手动重配的集成，以及必须更新的 API 端点。

另一个重要限制是：内置迁移工具只支持 Atlassian Cloud，不支持直接迁移到 Jira Service Management Data Center。准备继续使用 Data Center 的团队需要另外评估路径，详见官方迁移安排指南。

什么时候适合选择轻量级 Opsgenie 替代方案？

并非每个 Opsgenie 账户都在使用轮班、升级树、事件时间线和分析报表。一些小团队实际只需要三步：

监控工具发现严重事件；
集成把事件转发出去；
手机发出足够明显的提醒，让值班人员及时处理。

如果你的使用方式就是这样，迁移整个平台可能带来超出实际需求的流程成本。Echobell 是一个专注于送达的通知层，通过 Webhook 或邮件触发普通、时效性或来电式手机告警。

Echobell 不是 Opsgenie 的一比一替代品。它不替代高级值班排班、升级策略、事件指挥或事后报告。如果这些流程不可缺少，应选择 Jira Service Management 或其他完整的事件管理平台。

以下情况更适合 Echobell：

监控源已经能判断哪些事件属于 critical；
由一个人数少且稳定的团队共同值班；
希望保留现有监控，只替换 Webhook 到手机的送达链路；
需要分别处理严重、警告和信息类事件；
希望先独立验证通知效果，再调整其余系统。

可阅读 Echobell 与 Opsgenie 对比，进一步判断产品边界。

在 Opsgenie 关闭前试运行 Echobell

最安全的做法是并行验证，而不是在截止日期一次性切换。

1. 选择一个关键告警源

从责任人清晰、告警量可预期的生产服务开始，不要一次迁移所有集成。

2. 创建 Echobell 频道

为该服务创建频道，并分享给需要响应的成员。每位订阅者都可以在自己的设备上选择合适的通知方式。

3. 增加第二个 Webhook 目标

保留现有 Opsgenie 链路，同时把 Echobell 频道 Webhook 加到监控源。基本测试请求如下：

curl -X POST https://hook.echobell.one/t/<channel-token> \
  -H "Content-Type: application/json" \
  -d '{
    "title": "生产 API 已宕机",
    "body": "us-east-1 健康检查失败",
    "severity": "critical",
    "externalLink": "https://status.example.com/incidents/123"
  }'

脚本和密钥管理器中应使用占位符，不要把真实频道 Webhook 地址提交到代码仓库。Webhook 文档介绍了变量和模板配置。如果来源只支持邮件，可改用邮件触发。

4. 谨慎映射紧急程度

只有必须立即处理的事件才使用来电式告警；重要警告使用时效性通知，信息事件使用普通通知。这样才能避免把告警疲劳带到新工具中。

5. 在真实值班周期中并行运行

比较两条链路的送达时间、信息清晰度、误报和响应行为。除了故障告警，也要测试恢复通知。

6. 记录 Echobell 不负责的部分

移除某个服务的 Opsgenie 链路前，明确排班、升级、确认、审计和报表由谁负责。如果这些能力是硬性要求，就应继续放在完整的事件管理系统中。

Opsgenie 迁移检查清单

盘点所有入站集成、Heartbeat、API 客户端和邮件集成；
导出或迁移必须保留的历史数据；
记录排班、升级策略、通知规则和负责人；
找出需要手动替换的弃用功能和集成；
更新仍在调用 opsgenie.com 或 opsgenie.net 的脚本；
测试告警、恢复、确认和非工作时间送达；
至少并行运行一个有代表性的值班周期；
只有在响应人员确认新链路可靠后，才移除旧链路。

在 App Store 下载 Echobell或前往 Google Play，在现有 Opsgenie 链路仍然有效时先试运行一个生产告警。