前言
Atlassian 已经给 Opsgenie 画出了明确的终点：2025 年 6 月 4 日停止新购，现有客户可继续使用至 2027 年 4 月 5 日停止支持，到期后 Opsgenie 关闭访问，未迁出的客户数据将被删除（见 Atlassian Opsgenie Licensing FAQ）。仍在使用 Opsgenie 的团队需要决定：值班与升级策略迁到哪个平台。
留在 Atlassian 体系
通过官方应用内迁移工具迁入 Jira Service Management（JSM） 或 Compass，工单与告警来自同一家供应商，迁移摩擦最低
迁到独立的 On-call 平台
以 Flashduty 为例：排班、升级与故障协作独立于 JSM 套餐运行，License 按实际处理人计费，原生支持飞书/钉钉/企业微信
本页功能与价格信息截至 2026 年 9 月，以各厂商官网最新公布为准。
停服时间线与官方迁移路径
关键日期
Atlassian 官方迁移路径
Atlassian 引导团队通过应用内迁移工具迁入 Jira Service Management（故障/事件管理）或 Compass（告警/On-call）。关键约束：- 迁移需由 Opsgenie Owner（通常还需站点管理员权限）发起；
- 迁移日期必须至少提前 7 天预约；
- 完成 JSM 迁移后，Opsgenie 保留 120 天复核期，随后永久关闭；
- 多数配置可自动同步，但目标套餐差异与部分配置仍需手动跟进（例如 Alert actions、Incident rules、Responder 角色与 Stakeholder 过滤等字段不会自动迁移，需要在目标产品中复核重建）。
产品功能对比
On-call
On-call 解决「告警找到对的人」：先降噪，再按排班和升级策略通知到人。值班管理
分派与升级
通知渠道
告警降噪
Response
Response 解决「找到人之后怎么快速闭环」：一条时间线、一间作战室，处理、协同、复盘不丢上下文。Status Pages
AI 能力
平台与集成
价格对比
计费模式差异示例
以 100 人技术团队、其中 15 人日常参与故障处理为例：迁移路径对比
路径一：迁入 Jira Service Management（留在 Atlassian）
适合已经标准化在 Atlassian 套件上的组织。官方应用内迁移工具会把大部分配置同步到选定的 JSM 套餐，但请注意：- Alert actions、Incident rules 等自动化配置不会自动迁移，需要用 Jira Automation 重建；
- Responder 角色、Stakeholder 过滤等字段需要在迁后复核；
- 聊天集成需要重新配置认证。
路径二：切到 Flashduty（独立 On-call）
适合希望值班体系独立于 JSM 套餐运行的团队。请注意：Opsgenie 到 Flashduty 没有一键导入工具。Flashduty 专家会协助您制定切流计划，团队按计划重建值班表、升级策略、服务、路由与集成。完成后，告警平台不再依赖 Atlassian 的套餐打包与席位计费。迁移步骤建议
1
盘点现有配置
梳理值班表与轮换规则、升级策略、集成端点、告警路由规则与通知模板
2
在目标平台重建核心链路
先接入一个真实告警源，配置排班与升级策略，跑通短信、电话、IM、升级与闭环全流程
3
并行运行核验
新旧响应路径并行一段时间，与真实响应人一起测试认领与升级
4
切流并关闭旧平台
确认工作流跑通后确定切流窗口；迁出数据，避免停服日后数据被删除
如何选择
选择 Flashduty 的情况
- 需要一个不依赖 Atlassian 合并路径、可长期运行的 On-call / 故障响应产品
- 希望 License 只按实际处理故障的成员计费，通知接收者零成本
- 日常协作依赖飞书/钉钉/企业微信，需要原生支持（含私有化版本）
- 需要内置状态页、作战室、AI 复盘与 AI SRE 自治排障
- 需要私有化部署
留在 Atlassian 路径的情况
- 组织已标准化在 Jira、Confluence、Jira Service Management 上
- 希望使用 Atlassian 应用内自动迁移，迁移摩擦最低
- 更看重工单与告警来自同一家供应商，而不是独立的 On-call 产品