很多团队开始搜索 Opsgenie 或 PagerDuty 替代方案，并不是因为它们完全不能用。
更常见的原因有三类。
第一，成本越来越难解释。团队人数和通知对象在涨，但真正每天登录平台处理故障的人并没有那么多。如果所有被通知的人都占用付费席位，预算会很快膨胀。
第二，协作方式不匹配。国内团队的故障协同经常发生在飞书、钉钉、企业微信里，关键故障还依赖国内语音、短信和 App 推送兜底。如果 On-call 工具主要适配海外协作生态，落到国内团队就会多很多摩擦。
第三，产品路线变化。Opsgenie 用户尤其要关注这一点。Atlassian 官方已经说明，Opsgenie 新销售在 2025 年 6 月 4 日结束，Opsgenie 支持将在 2027 年 4 月 5 日结束，客户需要在此之前迁移到 Jira Service Management 或其他路径。
所以，选替代方案时不要只问“哪个工具功能最多”，而要问：
能不能接住现有告警源？
能不能减少无效打扰？
能不能把故障自动分派给正确的人？
能不能适配 IM、电话、短信和 App 推送？
没人响应时能不能自动升级？
故障处理过程能不能留下时间线？
管理者能不能看到 MTTA、MTTR、响应比例和人员负载？
迁移成本和长期使用成本是否可控？
On-call 平台替换，不是换一个告警通知入口。它本质上是在重建一条故障响应链路。
先判断：你要替代的到底是什么
很多团队说要替代 PagerDuty 或 Opsgenie，但真实诉求并不一样。
有的团队只是觉得贵。现有流程能跑，值班表、升级策略、告警接入和复盘机制都比较成熟，只是希望降低采购成本。这类团队最应该算清楚 License、席位、通知额度和实际处理人数，不要为了省钱牺牲关键通知覆盖。
有的团队是协作不顺。告警能发出来，但国内 IM 里不能方便认领和处理，电话短信不稳定，故障期间还要人工拉群、人工同步状态、人工整理复盘。这类团队应该重点看本土 IM、通知触达、作战室、状态页和复盘能力。
有的团队是告警太吵。Prometheus、Zabbix、云监控、夜莺、自研平台各发各的，PagerDuty 或 Opsgenie 也许能通知，但重复告警、抖动告警、告警风暴没有真正治理。这类团队应该先看聚合、抑制、静默、延迟通知、风暴预警和告警压缩率。
还有一类是 Opsgenie 路线变化带来的迁移压力。Jira Service Management 是 Atlassian 官方推荐迁移方向，但它更像 ITSM 和服务管理平台，On-call 是其中一部分。如果核心诉求是告警响应、值班、升级、降噪和国内协同，就应该把 JSM 和其他 On-call 平台一起评估，而不是默认原地迁移。
先把诉求讲清楚，后面的选型才不会跑偏。
Opsgenie 用户：不要只做“平台内迁移”
Opsgenie 用户现在通常有三条路。
第一条路，迁到 Jira Service Management。这是 Atlassian 官方路径，好处是迁移工具和文档相对完整。如果公司已经重度使用 Jira、Confluence、Jira Service Management，这条路的组织阻力可能最低。
但要提前确认：迁移后哪些功能会变化？原来的告警策略、通知策略、维护窗口、报表、移动端体验是否等价？Slack、Microsoft Teams、API Key、REST API、Incident Command Center 这类能力是否需要重新配置或替代？从相对独立的 On-call 工具迁到更大的 ITSM 平台后，值班团队日常操作是否变复杂？
自动迁移解决的是数据搬过去，不保证响应效率不下降。
第二条路，迁到 PagerDuty。如果团队主要在海外，使用 Slack、Microsoft Teams，采购体系接受海外 SaaS，PagerDuty 仍然是成熟选择。但国内团队要额外评估成本、通知触达、国内 IM、服务支持和合规部署方式。很多团队从 Opsgenie 迁出，本来就是想降低复杂度和成本，如果迁到另一个更重、更贵的海外体系，未必真正解决问题。
第三条路，迁到更适合国内团队的 On-call 平台。这类迁移的重点不是复制每一条旧配置，而是重新梳理告警响应链路：哪些告警源要接入，哪些标签要规范，哪些告警要降噪，哪些服务要独立协作空间，哪些人负责第一响应，哪些场景要自动升级。
如果已经有 PagerDuty 协议的告警发送能力，Flashduty 的一个优势是兼容 PagerDuty Events API。对已经支持推送到 PagerDuty 的告警系统，很多场景只需要调整推送地址，就可以把告警事件送到 Flashduty On-call，再继续做降噪、分派和升级。
迁移价值不在“地址改了”，而在于改完之后，团队能不能把告警响应做得更可控。
PagerDuty 用户：替代方案不要只看价格
PagerDuty 用户找替代方案，最常见的理由是成本。
On-call 平台覆盖多个团队后，席位、附加能力、通知对象和数据保留都会影响总拥有成本。大团队里，真正处理故障的人可能只有 10% 到 20%，但需要接收通知的人可能覆盖大部分研发、运维、DBA、业务负责人和外部协作方。
只看单价不够，要按真实使用方式算：
多少人需要登录平台查看和处理故障？
多少人只是被动接收通知？
多少人只在重大故障时被同步？
是否需要给管理层、业务方、外部供应商开放通知或状态信息？
短信、电话、邮件、App 推送的额度和超额费用怎么算？
AI、复盘、状态页、工单集成、分析报表是否需要额外付费？
Flashduty 的 License 模式对这类团队比较友好：只有需要查看和处理故障的成员需要 License，只接收通知的成员不需要 License，也可以通过邮件、短信、电话和 IM 被动接收通知。
这不是单纯便宜一点，而是成本结构不同。团队不必为了省席位而缩小通知范围，也不必为大量偶尔被通知的人购买完整处理权限。
当然，价格只是一个维度。如果替代方案便宜，但告警接不进来、夜间通知不到、没人响应不能升级、故障结束后没有数据，那便宜没有意义。
第一条标准：能不能接住现有告警源
替代 On-call 平台时，第一步不是配置值班表，而是接告警。
国内团队的告警源通常很杂：Prometheus Alertmanager、Zabbix、Nightingale / 夜莺、Grafana、云监控、日志告警、APM 告警、自研监控、邮件、Webhook，以及过去已经配置成 PagerDuty Events API 的告警系统。
一个合格的替代方案，必须允许你“不替换监控系统，先统一告警响应”。
Flashduty 支持专属集成和共享集成两种模式。专属集成适合单个业务或试点场景，告警进入某个协作空间，直接生成故障并按空间内策略分派。共享集成适合公司级统一接入，告警先进入集成中心，再根据 service、team、env、severity 等标签路由到不同协作空间。
试用早期，不要一上来做全公司大一统。先选一个真实业务，用专属集成跑通；等验证了接入、降噪、分派、通知和升级，再考虑共享集成和统一路由。
第二条标准：降噪要发生在“告警到故障”之间
很多工具都说自己支持告警降噪，但要看它降的是哪里。
在 Flashduty 的模型里，监控系统上报的是事件，事件生成告警，相似告警再聚合成故障。真正处理和通知的对象是故障。
这件事很重要。值班人不应该被每一次原始事件打扰。一台服务器宕机，可能同时触发 CPU、内存、磁盘、进程、端口、接口错误率等一堆告警。如果每条都打电话，响应只会更慢。
合理方式是把相似告警合并为一个可处理的故障，统一分派、通知、认领、关闭。
评估替代方案时，至少要看这些能力：
规则聚合：相同服务、资源、检查项的告警合成一条故障。
智能聚合：规则不完美时识别语义相似告警。
静默：维护窗口或计划变更期间停止无效通知。
抑制：宿主机故障时减少相关 Pod 告警重复打扰。
抖动检测：识别频繁触发和恢复的告警。
延迟通知：让短暂自愈故障不再打扰人。
风暴预警：合入告警数量异常增多时提高响应力度。
降噪不是把告警藏起来。好的降噪是减少重复打扰，同时保留关键故障的触达能力。POC 时不要只看告警数量下降了多少，还要看 Critical 响应比例有没有下降，夜间中断次数有没有下降，MTTA 有没有改善，误聚合和漏通知是否可控。
第三条标准：分派和值班不能只是“有排班日历”
值班表是 On-call 的基础，但只会排班还不够。
生产故障发生时，系统必须知道：故障属于哪个团队，当前谁是主值班，是否要通知备值班，白天和夜间是否走不同策略，Critical 和 Warning 是否走不同通道，没人认领时多久升级，未关闭时是否继续升级，是否同步群聊。
Flashduty 的分派策略围绕六个要素展开：触发条件、通知对象、通知方式、延迟窗口、通知模板和升级规则。
比如一条支付系统生产 Critical 告警，可以这样设计：
触发条件：service=payment，env=production，severity=Critical
第一环节：通知支付 SRE 主值班，App + IM + 语音
5 分钟未认领：升级给备值班
15 分钟未关闭且未认领：升级给支付研发负责人
30 分钟未关闭：升级给技术负责人，并创建作战室
群聊同步：支付故障响应群
值班表也要看细节：是否支持按天、按周、自定义周期轮换，是否支持白班、夜班、周末不同规则，是否支持主备角色、临时调班、公平轮换和换班通知。
临时靠群公告和 Excel 也能值班，但团队一大，靠人工记忆的值班机制一定会出问题。
第四条标准：通知触达要按国内真实场景测
很多 On-call 工具演示时都能发通知，生产环境真正要验证的是：凌晨 Critical 告警能不能叫醒人，IM 消息是否送到正确的人，App 推送是否稳定，语音和短信是否可用，无人响应时是否继续升级，通知失败是否能在时间线里查到，无 License 成员是否能被动接收通知。
国内团队还要特别看飞书、钉钉、企业微信。如果工具只支持机器人推群，通常不够。机器人能把消息发出去，但很难保证责任闭环：谁认领了，谁处理了，是否升级，故障状态是否更新，这些都容易丢。
更好的方式是在 IM 应用里支持故障消息卡片，让值班人可以直接认领、关闭、暂缓、查看详情，重大故障还能拉起作战室。Flashduty 支持飞书、钉钉、企业微信、Slack、Microsoft Teams，以及电话、短信、邮件、App 推送和群机器人；单聊负责触达个人，群聊负责同步团队。
POC 时一定要让真实值班人参与。真实 On-call 往往发生在手机、IM、电话和半夜，这些路径不测，选型结果就会过于理想化。
第五条标准：故障闭环要覆盖协同、沟通和复盘
On-call 平台的价值不应该停在“已通知”。故障结束后，至少要能回答：谁认领、何时认领、通知是否送达、升级过几次、哪些人参与、是否同步业务方、何时恢复、复盘改进项是什么。
这就是为什么故障时间线很重要。
Flashduty 的故障时间线会记录触发、分派、通知、认领、关闭等关键动作。通知结果也可以在时间线里查看，方便排查“为什么没收到”。
重大故障还需要协同空间。Flashduty 作战室可以围绕活跃故障在飞书、钉钉、企业微信或 Slack 中创建专属沟通群，处理人变化时自动同步成员，操作记录进入时间线。
对外或跨部门沟通，可以用状态页。公开状态页面同步客户或合作伙伴，内部状态页面同步组织内部，减少故障期间反复解释。
故障结束后，还要复盘。Flashduty 专业版支持故障复盘和 AI 故障摘要，可以基于关联故障、告警数据、处理时间线和作战室讨论记录生成复盘初稿。
这些能力不一定第一天都要用，但选型时要确认平台能不能从告警、响应、协同、沟通一路走到复盘。
第六条标准：数据指标要能指导治理
替代方案上线后，管理者不能只看“大家觉得好不好用”，要看数据。
至少要看：
MTTA：故障从发生到被认领用了多久。
MTTR：故障从发生到关闭或恢复用了多久。
响应比例：多少故障真的被人认领。
中断次数：短信、语音、App 推送真正打扰了人多少次。
响应投入：团队把多少时间花在故障处理上。
告警 TOP：哪些检查项、哪些对象贡献了最多噪音。
这些指标可以告诉你问题到底在哪里。MTTA 高，可能是分派不准、通知不到、值班表轮空或升级策略太慢。MTTR 高，可能是服务复杂、缺少预案、依赖外部系统或恢复动作太慢。中断次数高，说明值班体验在恶化，尤其要看睡眠时间打扰。告警 TOP 长期集中在少数检查项，说明源头规则需要治理。
Flashduty 分析看板支持按团队、协作空间、个人等维度统计，也能按工作时间、休息时间、睡眠时间拆分指标，并支持导出。
迁移不是目标，迁移后响应效率变好才是目标。
四类替代方案怎么取舍
常见选择可以分成四类。
Jira Service Management
适合已经深度使用 Atlassian 体系的团队。如果工单、服务台、知识库、变更管理和研发协作都在 Atlassian 里，迁到 JSM 可以减少系统割裂，也能利用官方迁移路径。
但要注意，它是一个更大的服务管理平台。你需要确认 On-call 团队的日常操作是否足够轻，国内 IM 和通知触达是否满足需求，迁移后哪些功能变化需要重新配置。
PagerDuty
适合海外业务和全球化团队。如果主要协作工具是 Slack、Microsoft Teams，团队分布在海外，采购体系适应美元 SaaS，PagerDuty 仍然是成熟选择。
但国内团队要重点评估总拥有成本、国内通知触达、飞书/钉钉/企业微信协同、本地支持和私有化部署需求。
自研或开源方案
适合有强平台工程能力、需求非常特殊、愿意长期维护的团队。
自研的好处是可控，坏处是能力边界容易被低估。告警接入、去重、值班、升级、通知、审计、移动端、报表、工单、复盘、权限、安全、运维和高可用，都需要持续投入。
如果只是为了省 License，通常不划算。如果自研平台已经存在，更现实的路径是保留现有监控和部分内部系统，把告警响应、值班和升级交给专业 On-call 平台。
Flashduty
适合国内团队先统一告警响应，再逐步建设 On-call 闭环。
它的优势主要在几个方面：
不要求替换现有监控系统，可以先接入 Prometheus、Zabbix、夜莺、云监控、Webhook 和 PagerDuty 协议告警。
支持聚合、抑制、静默、抖动检测、延迟通知和风暴预警。
支持值班表、主备角色、临时调班、服务日历、多级升级和动态分派。
支持飞书、钉钉、企业微信、Slack、Teams、电话、短信、邮件和 App 推送。
License 模式把故障处理权限和通知接收能力解耦。
支持故障时间线、作战室、状态页、工单集成、AI 摘要和故障复盘。
如果主要问题是国内协作、告警噪音、值班升级和成本结构，Flashduty 应该进入 shortlist。
迁移不要一次性切全量
替代 On-call 平台最忌讳一口气切全公司。更稳妥的方式是分四步。
第一步，盘点告警源。列出 Prometheus、Zabbix、云监控、夜莺、自研系统、邮件、Webhook、PagerDuty Events API 等来源，标出生产 Critical 和低优提醒。
第二步，选一个试点业务。不要选最边缘的测试业务，也不要一开始选全公司最复杂业务。选一个真实、重要、范围可控的系统，比如支付、订单、核心 API 或某个基础设施团队。
第三步，并行运行。旧平台继续工作，同一批告警接入新平台，观察是否丢失、标签是否正确、聚合是否合理、分派是否命中、通知是否稳定。
第四步，切换响应链路。新平台能稳定接收告警、通知值班人、处理认领、自动升级，并在分析看板看到数据后，再切正式响应链路。
迁移时尤其要保留回滚方案。On-call 平台管理的是生产故障，不是普通办公软件，任何切换都要保证关键告警不会因为配置失误被丢掉。
POC 时至少验证这 10 件事
如果正在评估 Opsgenie 或 PagerDuty 替代方案，建议把 POC 设计成真实演练，而不是功能演示。
至少验证 10 件事：
1. 接入一个真实告警源，而不是只创建手工测试故障。
2. 用生产级标签验证路由，例如 service、env、team、severity、resource。
3. 触发一组重复告警，观察是否聚合为可处理故障。
4. 触发一条 Critical 告警，验证当前值班人是否收到通知。
5. 让值班人在 IM、App 或电话路径中认领一次。
6. 故意不认领，验证是否按规则升级到备值班或负责人。
7. 检查故障时间线，确认通知、认领、升级、关闭都有记录。
8. 创建一次重大故障协同，验证作战室或群聊同步是否顺畅。
9. 故障关闭后生成复盘材料，确认时间线和行动项是否可追溯。
10. 看分析看板，确认 MTTA、MTTR、响应比例、中断次数和告警 TOP 是否能用于治理。
POC 成功的标准不是“功能都能点开”，而是这条链路真的能跑：
告警触发 -> 接入 -> 路由 -> 降噪 -> 分派 -> 通知 -> 认领 -> 升级 -> 协同 -> 关闭 -> 分析 -> 复盘
如果这条链路跑不通，再便宜、再有名、再多功能都没有意义。
最后：替代方案的核心是适配你的响应体系
Opsgenie/PagerDuty 替代方案怎么选？不要从竞品表开始，先从自己的故障响应体系开始。
你有哪些告警源？哪些告警是真正需要叫醒人的？哪些团队需要值班？谁是一线响应，谁是升级兜底？国内 IM、语音、短信和 App 推送是否可靠？管理者要看哪些指标？故障结束后是否需要复盘和状态沟通？预算到底应该覆盖处理人，还是覆盖所有被通知人？
这些问题回答清楚以后，工具选择会简单很多。如果团队在国内，有多套监控系统，告警噪音高，值班升级靠人工，协作主要发生在飞书、钉钉或企业微信里，同时又希望控制大团队 On-call 成本，Flashduty 值得认真评估。
最好的方式不是看一张对比表，而是拿一个真实业务试 14 天。接入一个告警源，配置一张值班表，跑一条 Critical 分派策略，让值班人真正认领一次，再看 MTTA、响应比例、中断次数和告警压缩效果。
如果这条链路跑通了，你就不是“换了一个通知工具”，而是在把告警响应变成一套可管理、可升级、可复盘、可持续优化的机制。
资料依据：Atlassian 官方 Opsgenie 迁移说明 和 迁移路径文档 说明，Opsgenie 新销售在 2025 年 6 月 4 日结束，支持在 2027 年 4 月 5 日结束；具体迁移功能变化以 Atlassian 支持文档为准。
