> ## Documentation Index
> Fetch the complete documentation index at: https://docs.flashduty.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Flashduty vs Opsgenie
> 对比 Flashduty 与 Opsgenie：停服时间线与官方迁移路径、On-call 功能、状态页、AI 能力与计费模型全解析，以及什么时候更该留在 Atlassian 体系
## 前言
***
Atlassian 已经给 Opsgenie 画出了明确的终点：**2025 年 6 月 4 日停止新购**，现有客户可继续使用至 **2027 年 4 月 5 日停止支持**，到期后 Opsgenie 关闭访问，未迁出的客户数据将被删除（见 [Atlassian Opsgenie Licensing FAQ](https://www.atlassian.com/licensing/opsgenie)）。
对仍在使用 Opsgenie 的团队来说，真正要回答的问题不是「要不要继续用 Opsgenie」，而是 **值班与升级策略的下一个平台是什么**。
本页对比两条主要路径：
通过官方应用内迁移工具迁入 **Jira Service Management（JSM）** 或 Compass，工单与告警来自同一家供应商，迁移摩擦最低
以 Flashduty 为例：排班、升级与故障协作独立于 JSM 套餐运行，License 按实际处理人计费，原生支持飞书/钉钉/企业微信
本页功能与价格信息**截至 2026 年 9 月**，以各厂商官网最新公布为准。
***
## 停服时间线与官方迁移路径
***
### 关键日期
| 日期 | 事件 | 影响 |
| -------------- | ------------- | ----------------------------------- |
| **2025-06-04** | Opsgenie 停止新购 | 新客无法购买；存量客户套餐升降级关闭，续订仅限订阅期在停止支持日前结束 |
| **2027-04-05** | Opsgenie 停止支持 | 服务关闭访问，未迁入 Atlassian 目标产品的客户数据被删除 |
### Atlassian 官方迁移路径
Atlassian 引导团队通过**应用内迁移工具**迁入 Jira Service Management（故障/事件管理）或 Compass（告警/On-call）。关键约束：
* 迁移需由 **Opsgenie Owner**（通常还需站点管理员权限）发起；
* 迁移日期必须**至少提前 7 天**预约；
* 完成 JSM 迁移后，Opsgenie 保留 **120 天**复核期，随后永久关闭；
* 多数配置可自动同步，但**目标套餐差异与部分配置仍需手动跟进**（例如 Alert actions、Incident rules、Responder 角色与 Stakeholder 过滤等字段不会自动迁移，需要在目标产品中复核重建）。
对已经标准化在 Jira、Confluence、JSM 上的组织，这是阻力最小的路径。对希望值班体系独立运行的团队，则需要评估独立 On-call 平台。
***
## 产品功能对比
***
### On-call
On-call 解决「告警找到对的人」：先降噪，再按排班和升级策略通知到人。
#### 值班管理
| 值班功能 | 功能要求 | 对比 |
| -------- | ---------------- | ------------------------------------------ |
| **轮换周期** | 按天、周或自定义周期轮换 | ✅ 两者均支持 |
| **时间限定** | 限定轮换周期内的值班时间 | ✅ 两者均支持 |
| **临时调班** | 设置临时调班（Override） | ✅ 两者均支持 |
| **值班角色** | 设置主备值班等角色 | ✅ **Flashduty 独有** |
| **多人值班** | 同时多人值班并一起轮换 | ✅ **Flashduty 独有** |
| **公平轮换** | 避免固定人员在特定时间值班 | ✅ **Flashduty 独有**（解决 7 人按天轮换时某人永远周日值班的问题） |
| **轮换通知** | 换班提前通知、定时通知 | ✅ 两者均支持，Flashduty 支持更多通知方式 |
#### 分派与升级
| 分派能力 | 功能详情 | 对比 |
| ------------------------------------------------------ | ---------------------------------------------------- | ------------------------------------- |
| **[策略分派](/zh/on-call/channel/escalation-rule)** | 分派给值班、团队或个人，同时设定通知方式 | ✅ 两者均支持；Flashduty 额外支持分派到团队并逐策略设定通知方式 |
| **自动升级** | 故障超时未解决自动升级 + 手动升级 | ✅ 两者均支持 |
| **[动态分派](/zh/on-call/advanced/dynamic-notifications)** | 根据标签动态替换或**追加**分派人员、团队与群聊（可结合 CMDB/CSV 映射数据自动生成分派对象） | ✅ **Flashduty 独有**，大幅降低系统打通和配置维护成本 |
#### 通知渠道
| 通知方式 | 说明 | 对比 |
| ------------------------------------------------ | --------------------------------- | ----------------------------------------------------------------------------------- |
| **语音/短信/邮件** | 电话、短信、邮件通知 | ✅ 两者均支持；Flashduty 提供**固定显号**，语音号码可同步至手机通讯录白名单 |
| **中国大陆 IM** | 飞书、钉钉、企业微信协同 | ✅ **Flashduty 独有**：应用集成**含飞书/钉钉私有化版本**；Opsgenie 需桥接或 Webhook 旁路 |
| **国际化 IM** | Slack、Microsoft Teams 等 | ✅ 两者均支持；Flashduty 额外支持 Zoom、Telegram 机器人 |
| **移动端** | 移动 App | ✅ 两者均支持；Flashduty iOS 基于 Apple Critical Alerts 协议**突破勿扰模式**，Android 独立适配国内主流厂商系统级推送 |
| **[自定义模板](/zh/on-call/configuration/templates)** | 全渠道自定义通知模板，**含语音通知模板**，支持历史故障预览调试 | Flashduty 支持丰富的模板语法；Opsgenie 通知内容定制空间有限 |
#### 告警降噪
| 降噪能力 | 功能说明 | 对比 |
| ----------------------------------------------- | ---------------------------- | ------------------------------------------------------------------------------------------------- |
| **告警聚合** | 将相似告警聚合处理，减少告警疲劳 | ✅ 两者均支持（Opsgenie 为去重与 Alert Policies；Flashduty 为规则聚合与[智能聚合](/zh/on-call/channel/noise-reduction)） |
| **[故障抑制](/zh/on-call/channel/noise-reduction)** | 宿主机故障时，自动抑制相关 pod 故障 | ✅ **Flashduty 独有** |
| **[风暴预警](/zh/on-call/channel/noise-reduction)** | 聚合告警数量过多时再次通知提升响应力度，支持多级阶梯阈值 | ✅ **Flashduty 独有** |
| **抖动收敛** | 相同故障频繁发生与恢复时，适当减少通知 | ✅ **Flashduty 独有** |
| **延迟通知** | 延后窗口通知，过滤立即自动恢复的故障 | ✅ 两者均支持 |
### Response
Response 解决「找到人之后怎么快速闭环」：一条时间线、一间作战室，处理、协同、复盘不丢上下文。
| 处理功能 | 功能说明 | 对比 |
| ------------------------------------------------------- | -------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------- |
| **基础操作** | 创建、认领、关闭、评论、暂缓、合并、批量分派故障 | ✅ 两者均支持 |
| **故障管理归属** | 独立的故障管理产品形态 | Flashduty 内置完整故障生命周期；Opsgenie 的 Incident Command Center 已被 Atlassian 弃用，故障能力并入 JSM |
| **[作战室](/zh/on-call/advanced/war-room)** | 一键创建飞书/钉钉/企微/Slack 群聊，自动邀请处理人，故障卡片置顶实时更新，群内操作同步回平台 | ✅ **Flashduty 独有** |
| **[故障复盘](/zh/on-call/post-mortem/what-is-post-mortem)** | 完整复盘报告：时间线沉淀、协同编辑、权限管控，支持 [AI 自动生成复盘](/zh/on-call/post-mortem/ai-generate-post-mortem) | ✅ **Flashduty 独有**；Opsgenie 无对等复盘能力（Atlassian 体系内需结合 JSM/Confluence 手工完成） |
| **自定义操作** | 添加自定义操作（如触发主机重启），执行前二次确认 | ✅ 两者均支持（Opsgenie 为 Alert Actions，不随官方迁移自动搬迁） |
### Status Pages
| 维度 | Flashduty | Opsgenie |
| ---------------- | ------------------------------------------------------------------------------------------- | ----------------------------------------- |
| **提供方式** | [状态页](/zh/on-call/statuspage/statuspage)随 On-call 产品提供，免费版起即含公开状态页且**功能全量不分档**，公开 + 内部状态页一体 | 无原生状态页；Atlassian Statuspage 为**独立产品单独付费** |
| **订阅费用** | ✅ 订阅者免费、无需账号 | Statuspage 订阅按套餐与订阅量分层计费 |
| **订阅粒度与方式** | 全量/组件/事件三级订阅，邮件 + RSS 2.0 / Atom 1.0 免确认订阅 | 依赖 Statuspage 自身能力 |
| **Atlassian 迁移** | **兼容订阅地址**（`history.rss` / `history.atom`）+ CLI 一键迁移组件、事件与订阅者 | — |
### AI 能力
| 维度 | Flashduty | Opsgenie |
| -------------- | -------------------------------------------------------------------------------------------------------- | -------- |
| **AI 摘要与复盘** | 内置 AI 故障摘要、AI 一键生成复盘 | 无对等能力 |
| **自治排障 Agent** | [AI SRE](/zh/ai-sre)：接入真实环境的自治 Agent loop，云端沙箱 + 自托管 Runner 动态执行诊断命令，可通过 Skills、MCP、Subagent 与 A2A 无上限扩展 | 无对等能力 |
| **IM 原生排障** | 飞书/钉钉/企微/Slack [群聊 @ 召唤、私聊排障](/zh/ai-sre/im)，作战室创建后自动发起初步诊断 | 无对等能力 |
| **计费** | **公测期间免费**，正式商用后按 credits 用量计费 | — |
### 平台与集成
| 核心能力 | Flashduty | Opsgenie |
| -------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------- |
| **告警集成** | 60+ 集成源，国内云与监控生态全覆盖（阿里云、腾讯云、华为云等），兼容 PagerDuty 协议 | 200+ 集成，海外生态成熟 |
| **心跳监控** | 监控类心跳由 [Monitors 引擎失联告警](/zh/monitors/engine/engine-lost-alert)覆盖，On-call 侧无独立的定时任务心跳能力 | ✅ Heartbeats 是 Opsgenie 的成熟能力，Cron/定时任务场景迁出前请单独评估替代方案 |
| **告警流水线与标签增强** | 路由、过滤、等级重设、正则提取、[数据映射](/zh/on-call/integration/alert-integration/label-enhancement)（导入 CMDB 表格动态生成标签） | Alert Policies 支持基础的过滤与字段修改 |
| **洞察报表** | MTTA/MTTR、人员工作量、频发分析、**时段分析**（工作/休息/睡眠） | 基础报表 |
| **私有化部署** | ✅ 支持 | ❌ 仅 Cloud |
| **开放生态** | [Open API](/zh/openapi/api-catalog) 330+ 接口、[CLI](/zh/developer/cli)、[Go SDK](/zh/developer/go-sdk)、[Terraform Provider](/zh/developer/terraform)、[MCP Server](/zh/developer/mcp-server) | REST API 成熟；无官方 Terraform Provider（社区维护） |
***
## 价格对比
***
| 对比维度 | Flashduty | Opsgenie / JSM 路径 |
| --------- | ----------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ |
| **收费模式** | License 费 + 超额通信费用 | 按用户席位；迁入 JSM 后按 JSM 套餐计费 |
| **版本定价** | **专业版 ¥199/人/月**，含智能聚合、AI 摘要、AI 复盘；AI SRE 公测期免费 | Opsgenie 历史定价（1–25 人年付档）：Essentials 约 \$9.45、Standard 约 \$19.95、Enterprise 约 \$31.90/用户/月；JSM 另有 Free/Standard/Premium/Enterprise 套餐 |
| **计费对象** | ✅ **仅对活跃用户收费**——只有查看和处理故障的成员需要 License，通知接收者免费 | Responder 计入付费席位；Stakeholder（仅通知）在 Enterprise 档免费，其余档需评估 |
| **状态页订阅** | ✅ 免费、无需账号 | 需单独购买 Atlassian Statuspage |
| **免费试用** | 专业版 14 天免费，可申请延长 | 已停止新购，无法新签试用 |
### 计费模式差异示例
以 100 人技术团队、其中 15 人日常参与故障处理为例：
| 费用项 | Flashduty 专业版 | Opsgenie Standard（历史价） |
| --------------- | ------------------------ | -------------------------------------- |
| 需购买席位/License 数 | **15 个** License | 按 Responder 席位计，假设 15 人 |
| 月费用 | 15 × ¥199 = **¥2,985/月** | 15 × \$19.95 ≈ **\$299/月** |
| 通知覆盖人数 | **100 人**（全员可接收通知，免费） | 超出 Responder 的通知对象需评估 Stakeholder 席位规则 |
Opsgenie 席位单价不高，但它已是停服产品——真正的成本比较应发生在「Flashduty vs 迁移目标产品」之间。如果迁移目标是 JSM，请把 JSM 套餐价、Atlassian Statuspage 订阅费与潜在的席位扩张一起计入总成本。
***
## 迁移路径对比
***
### 路径一：迁入 Jira Service Management（留在 Atlassian）
适合已经标准化在 Atlassian 套件上的组织。官方应用内迁移工具会把大部分配置同步到选定的 JSM 套餐，但请注意：
* Alert actions、Incident rules 等自动化配置**不会自动迁移**，需要用 Jira Automation 重建；
* Responder 角色、Stakeholder 过滤等字段需要在迁后复核；
* 聊天集成需要重新配置认证；
* 迁移日期至少提前 7 天预约，完成后有 120 天复核期。
### 路径二：切到 Flashduty（独立 On-call）
适合希望值班体系独立于 JSM 套餐运行的团队。请知悉：**不存在从 Opsgenie 到 Flashduty 的一键导入工具**——Flashduty 专家会协助您制定切流计划，团队按计划重建值班表、升级策略、服务、路由与集成。换来的是告警平台不再依赖 Atlassian 的打包方式与席位计费。
### 迁移步骤建议
梳理值班表与轮换规则、升级策略、集成端点、告警路由规则与通知模板
先接入一个真实告警源，配置排班与升级策略，跑通短信、电话、IM、升级与闭环全流程
新旧响应路径并行一段时间，与真实响应人一起测试认领与升级
确认工作流跑通后确定切流窗口；迁出数据，避免停服日后数据被删除
无论选择哪条路径，都请**在 2027 年 4 月 5 日之前完成迁移并导出需要留存的数据**——停服后未迁出的数据将被删除。
***
## 如何选择
***
* 需要一个不依赖 Atlassian 合并路径、可长期运行的 On-call / 故障响应产品
* 希望 License 只按实际处理故障的成员计费，通知接收者零成本
* 日常协作依赖飞书/钉钉/企业微信，需要原生支持（含私有化版本）
* 需要内置状态页、作战室、AI 复盘与 AI SRE 自治排障
* 需要私有化部署
* 组织已标准化在 Jira、Confluence、Jira Service Management 上
* 希望使用 Atlassian 应用内自动迁移，迁移摩擦最低
* 更看重工单与告警来自同一家供应商，而不是独立的 On-call 产品
还在比较其他厂商？参见 [Flashduty vs PagerDuty 深度对比](/zh/on-call/comparison/vs-pagerduty)。
***
## 总结
***
Opsgenie 曾是一款优秀的告警与值班产品，但它的产品周期已经进入倒计时。对存量用户来说，2027 年 4 月 5 日是一个确定的规划边界：**迁移不是要不要做的问题，而是迁到哪里的问题**。
* 如果您的组织已经运行在 Atlassian 体系内，JSM 是摩擦最低的官方路径；
* 如果您希望借这次迁移重建一套独立、可持续的 On-call 体系——License 按处理人计费、原生中国 IM 协作、内置状态页与 AI 能力——Flashduty 值得一次完整的试用评估。
建议用真实业务场景做 14 天试用：接入一个告警源、配置排班与升级策略、跑通通知与闭环，再做最终决定。