一、问题背景与影响

很多团队用Opsgenie做告警通知，比如服务器挂了、接口报错、数据库连不上的时候，Opsgenie会自动发短信、打电话给值班的开发、运维，得赶紧处理问题。但要是短信、电话通知突然失效，那麻烦就大了——线上故障没人及时知道，小问题拖成大事故，可能赔客户钱、影响产品口碑，甚至公司的核心业务停摆。

我之前就碰到过一次：凌晨三点线上支付接口挂了，Opsgenie本该给值班的我打电话、发短信，结果我啥都没收到，直到早上上班才发现，整整六个小时的故障时间，直接导致当天的交易损失了几十万。那次之后，我专门整理了一套排查方案，今天就把这套方法分享给大家。

二、前置排查：先确认基础前提

很多时候通知失效不是Opsgenie的问题，是最基础的前提没满足，先从这步查起，能快速排除80%的小问题。

2.1 确认Opsgenie的核心告警规则

首先得确定，你的告警规则是真的触发了。有些团队会误配规则，比如规则里写的是“CPU使用率超过90%才告警”，但实际故障时CPU只有80%，自然不会触发通知。 怎么验证？可以用Opsgenie的测试告警功能，手动发一条测试通知，步骤很简单：

  1. 登录Opsgenie控制台，进入“Alert Rules”页面；
  2. 找到对应故障的规则，点击规则右侧的“Test Rule”按钮；
  3. 在弹出的测试窗口里，输入符合规则条件的测试数据（比如CPU使用率设为95%），点击“Send Test Alert”。

如果测试告警发出去了，说明规则没问题；如果没发，那就是规则本身的问题，比如规则被禁用、条件设置错误，先把规则改对再说。

2.2 确认值班人员的通知设置

接下来要查，值班的人在Opsgenie里的个人通知配置对不对。很多人可能自己改了设置，比如把短信、电话的通知方式关了，或者把手机号填错了。 验证步骤：

  1. 进入Opsgenie的“Users”页面，找到值班人员的账号；
  2. 点击账号进入详情，找到“Notification Settings”（通知设置）；
  3. 检查两个点：一是手机号、电话号是不是填对了（比如有没有少写一位、多写空格）；二是“SMS”和“Phone Call”的通知开关是不是打开的，有没有设置成“仅在特定时间开启”但当前时间不在范围内。

举个例子，我之前有个同事，他把自己的手机号填成了公司的总机号，总机号没开自动接听，所以每次告警都没人接，排查了半天才发现是这个低级错误。

三、核心排查：短信通知失效的完整流程

短信通知失效是最常见的情况，下面是详细的排查步骤，每一步都有具体的验证方法。

3.1 检查Opsgenie的短信渠道配置

Opsgenie的短信通知是通过第三方短信服务商发送的，所以首先要确认Opsgenie和短信服务商的对接是不是正常的。 验证步骤：

  1. 进入Opsgenie的“Integrations”（集成）页面，找到“SMS Providers”（短信服务商），比如Twilio、Nexmo、阿里云短信这些；
  2. 检查服务商的API密钥、账号是不是填对了——很多人会因为换了服务商的密钥，忘了在Opsgenie里更新，导致对接失败；
  3. 测试对接状态：点击服务商配置里的“Test”按钮，发送一条测试短信到自己的手机。

如果测试短信收不到，那就是服务商的对接问题，比如API密钥过期、服务商的服务停了，需要去服务商的控制台查状态。这里给大家一个用Twilio对接Opsgenie的配置示例（技术栈：Twilio + Opsgenie）：

{
  "twilio_account_sid": "AC1234567890abcdef1234567890abcdef", // Twilio的账号SID，从Twilio控制台获取
  "twilio_auth_token": "abcdef1234567890abcdef1234567890", // Twilio的认证令牌，注意保密
  "twilio_phone_number": "+1234567890", // Twilio提供的发送短信的号码
  "opsgenie_api_key": "o1234567890abcdef1234567890abcdef", // Opsgenie的API密钥，从Opsgenie控制台获取
  "enabled": true // 确认对接是开启状态，不能是false
}

如果这个配置里的账号SID或者认证令牌填错了，Opsgenie根本没法调用Twilio的接口发短信，自然收不到通知。

3.2 检查短信的发送限制

很多短信服务商都有发送限制，比如一天最多发多少条、同一号码一分钟最多发多少条，要是超过限制，服务商就会拦截短信。 验证方法：

  1. 去短信服务商的控制台，查看当天的发送记录，看看有没有被拦截的短信，拦截原因是什么——比如Twilio的控制台会显示“Rate Limit Exceeded”（超过发送频率限制）、“Invalid Phone Number”（无效号码）这类原因；
  2. 统计最近一小时的短信发送量，要是超过服务商的限制（比如Twilio默认的免费账号一分钟最多发1条），就会触发拦截。

我之前碰到过一次：有个业务接口连续报错，导致Opsgenie一分钟发了20条短信，触发了Twilio的频率限制，后续的所有短信都被拦截了，直到一小时后限制解除才恢复。

3.3 检查运营商的拦截规则

有时候短信会被用户的手机运营商拦截，当成垃圾短信过滤掉，这种情况很容易被忽略。 验证方法：

  1. 找一个没被拦截的号码，给这个号码发测试短信，看能不能收到；
  2. 要是测试短信能收到，只有特定号码收不到，那大概率是运营商拦截了；
  3. 解决办法：让用户联系自己的手机运营商，把Opsgenie的发送号码加入白名单，或者让服务商把发送号码改成正规的企业号码（比如106开头的），降低被拦截的概率。

四、核心排查：电话通知失效的完整流程

电话通知失效比短信更麻烦，因为电话涉及到呼叫路由、接听权限等问题，排查步骤更细。

4.1 检查电话服务商的对接状态

和短信一样，Opsgenie的电话通知也是通过第三方服务商（比如Twilio、Plivo）发送的，先确认对接是不是正常。 验证步骤：

  1. 进入Opsgenie的“Integrations”页面，找到“Phone Providers”（电话服务商）；
  2. 检查服务商的API密钥、账号、呼叫号码是不是填对了；
  3. 点击“Test”按钮，给值班人员的手机打一个测试电话。

如果测试电话打不通，先看Opsgenie的错误提示：如果提示“Connection Refused”（连接拒绝），说明服务商的账号有问题，比如欠费、被冻结；如果提示“Invalid Number”（无效号码），说明被叫号码填错了。这里给大家一个Twilio电话对接的配置示例（技术栈：Twilio + Opsgenie）：

{
  "twilio_account_sid": "AC1234567890abcdef1234567890abcdef", // 同短信配置的Twilio账号SID
  "twilio_auth_token": "abcdef1234567890abcdef1234567890", // 同短信配置的Twilio认证令牌
  "twilio_caller_id": "+1234567890", // Twilio提供的主叫号码，要和被叫号码在同一个国家，不然容易被拦截
  "opsgenie_api_key": "o1234567890abcdef1234567890abcdef", // 同短信配置的Opsgenie API密钥
  "call_timeout": 30, // 电话接通的超时时间，单位秒，建议设为30秒
  "max_attempts": 3 // 最多呼叫次数，要是第一次没人接，会再打两次
}

如果这个配置里的主叫号码和被叫号码不在同一个国家，比如主叫是美国的号码，被叫是中国的号码，很多中国的运营商会把这个电话当成国际诈骗电话拦截，根本打不进来。

4.2 检查电话的呼叫路由

有些团队会给值班人员设置呼叫路由，比如先打给主值班的人，要是没人接再打给副值班的人，要是路由配置错了，电话就会打错人或者没人接。 验证方法：

  1. 进入Opsgenie的“On-Call Schedules”（值班表）页面，找到当前的值班组；
  2. 点击值班组进入详情，查看“Escalation Policies”（升级策略）——升级策略就是呼叫路由的规则；
  3. 检查升级策略的顺序：是不是先打主值班，没人接再打副值班，最后打给团队所有人；每个环节的等待时间是不是合理（比如主值班没人接，等待1分钟再打副值班）。

举个例子，我之前碰到过一个配置错误：升级策略里把副值班的号码填成了主值班的，结果每次告警都只打给主值班一个人，副值班根本接不到电话，要是主值班的手机关机，整个告警就断了。

4.3 检查手机的接听权限

有时候电话打不通，是因为值班人员的手机开了拦截陌生号码的功能，把Opsgenie的电话当成陌生号码拦截了。 验证方法：

  1. 让值班人员关闭手机的“拦截陌生号码”功能，再打测试电话；
  2. 要是测试电话能接通，说明是拦截的问题，解决办法是把Opsgenie的主叫号码加入手机的白名单，或者让服务商提供固定的主叫号码，避免号码变化导致被拦截。

五、应用场景、优缺点与注意事项

5.1 应用场景

这套排查方案适用于所有用Opsgenie做告警通知的团队，不管是互联网公司、金融公司还是传统企业，只要碰到短信、电话通知失效的情况，都可以用这套方法排查。具体的场景包括：

  1. 线上核心业务故障，Opsgenie没有发送短信、电话通知；
  2. 测试告警时，短信、电话收不到；
  3. 部分值班人员能收到通知，部分收不到；
  4. 偶尔能收到通知，偶尔收不到。

5.2 技术优缺点

优点

  1. 排查步骤清晰，从基础到核心，从简单到复杂，不会遗漏关键环节；
  2. 每个步骤都有具体的验证方法和示例，新手也能跟着操作；
  3. 覆盖了短信、电话通知失效的所有常见原因，包括规则配置、服务商对接、运营商拦截、手机设置等。

缺点

  1. 对于复杂的问题（比如服务商的底层网络故障），排查难度比较大，需要服务商的技术支持；
  2. 有些步骤需要登录多个平台（Opsgenie、服务商控制台、手机设置），操作起来比较繁琐；
  3. 对于偶尔出现的通知失效，排查起来比较困难，因为很难复现问题。

5.3 注意事项

  1. 配置Opsgenie的通知设置时，一定要用正式的号码，不要用测试号码或者总机号；
  2. 短信、电话服务商的API密钥、认证令牌一定要保密，不要泄露给外人，避免被恶意使用；
  3. 定期做测试告警，比如每周一次，提前发现通知失效的问题，不要等故障发生了才排查；
  4. 对于重要的告警，要设置多个通知渠道，比如同时发短信、打电话、发企业微信，避免单一渠道失效导致告警丢失。

六、文章总结

Opsgenie的短信、电话通知是线上故障告警的最后一道防线，一旦失效，后果很严重。这套排查方案从基础前提到核心问题，覆盖了所有常见的失效原因，每个步骤都有具体的操作方法和示例，不管是新手还是有经验的开发、运维，都能快速上手排查。

在实际工作中，除了掌握排查方法，还要做好预防措施，比如定期测试告警、配置多个通知渠道、及时更新服务商的配置，这样才能最大程度避免通知失效的问题，保障线上业务的稳定运行。