2月9日 GitHub 确实出现了一波通知延迟，并且伴随多个核心服务的性能降级：包括 Actions、Git Operations、Issues、Pull Requests、Webhooks、Packages、Pages、Codespaces，甚至还波及到 Copilot、Dependabot 等相关能力。最后官方宣布恢复正常，并表示后续会发布更详细的 RCA（根因分析）。官方事件报告如下：
- 通知延迟事件报告
- 涉及问题、操作和Git操作的事件报告
好，信息面上就这些，但小D作为每天在 GitHub 上“搬砖”的工程师，真正关心的通常是三件事：
1）到底发生了什么，会影响我哪些流程？
2）我现在遇到的问题，是 GitHub 的锅还是我的锅？
3）怎么快速自救，避免今晚继续加班？
1）这次异常的两条主线：通知慢 + 服务抖成筛子
A. 通知延迟（Notifications are delayed）
GitHub 官方描述很直白：通知出现积压，平均延迟从约 50 分钟一路飙到约 1 小时 20 分钟，随后逐步回落到约 1 小时 → 30 分钟 → 15 分钟，最终宣布完全恢复。
人话：你的通知确实可能“晚到”，但不是不到。更扎心的是——通知这种东西晚到就等于失效。
- PR reviewer 迟迟收不到提醒，review 节奏断了
- code owner 迟到半小时才看到变更，合并窗口错过
- oncall 收到告警关联通知晚一拍，排障黄金时间直接蒸发
B. 多服务降级（Issues / Actions / Git 操作等）
另一条线更“硬核”：一堆核心服务出现 degraded performance / degraded availability。官方过程里提到的影响包括：
- 请求变慢、失败率上升
- Actions 任务延迟、排队
- 多个产品线（Actions、Issues、PR、Webhooks 等）不同程度受影响
后续官方声明服务恢复正常。
一句人话总结：不只是“通知慢”，而是“系统整体有点喘不过气”。[惊恐]
2）最容易踩的坑
你以为是流程问题，其实是平台波动
这类事故最烦人的地方在于：它不会把你电脑蓝屏，也不会直接报一个“GitHub 崩了”。
- PR 已合并，但通知迟迟不到 → 你以为 webhook/机器人挂了
- Actions 状态卡住不动 → 你以为 YAML 写炸了，开始疯狂改 pipeline
- Issue 评论发出去了，但订阅者没收到提醒 → 你以为权限/订阅设置有问题
- git push 偶发失败或慢 → 你以为公司网络抖了，开始怀疑人生
于是，程序猿最经典的场景也是最擅长的事情出现了：
平台抖 1 小时，你排查 3 小时。（加班就是这么来的😭）
3）一份“自救排查清单”
当你发现 GitHub “不太对劲”，建议按这个顺序来——能省命：
✅ Step 1：先看 Status Page（别自虐）
先打开：
- https://www.githubstatus.com/
如果状态页正在 Investigating / Identified / Monitoring，恭喜：你可以先把“自责模式”关掉。
✅ Step 2：判断影响面（通知 vs 业务链路）
- 只是通知慢：PR/Issue 可能还能用，只是“提醒晚到”
- Actions/Git 操作也慢：CI/CD、合并、发版链路可能整体变慢或失败
这一步很关键：
通知慢 → 别急着改系统
链路慢/失败 → 先保交付，别做大手术
✅ Step 3：把“重试”变聪明
事故期间最怕的不是失败，而是“你和平台一起抽风式重试”，把积压越堆越大：
- Actions：避免手动狂点 Re-run all jobs（尤其是高并发仓库）
- Webhooks：如果你有自建 webhook consumer，确认重试策略是指数退避（exponential backoff），别 1 秒 1 次硬刚
- Bot/Automation：临时降低触发频率或加熔断（例如只处理关键事件）
✅ Step 4：关键业务兜底（临时“人工模式”）
当自动化链路不稳定时，短期最有效的是“降级”：
- 重要发布：临时人工确认 PR 状态、手动触发必要任务
- 关键告警：别完全依赖 GitHub 通知，转到 Slack/邮件/监控系统的主通道
- 依赖更新（Dependabot）：如果受影响，先暂停自动合并，避免“卡住时乱合”
✅ Step 5：事故恢复后做一次“事后清算”
官方说会出 RCA，但团队内部也建议做两件事：
回看事故窗口内的失败任务/遗漏通知（尤其是 oncall / 安全相关）
把“平台波动”纳入你的工程弹性设计：
- webhook 事件幂等
- 重试退避 + 死信队列
- 关键流程可手动兜底
- 不把单点平台当永远 100% 可用（这点很重要）
4）结语
GitHub 抖动不是罕见事件，罕见的是你没准备
平台级服务再稳，也会有“咳嗽”的时候。真正决定你今晚能不能准点下班的，不是平台有没有事故，而是你的系统有没有“抗事故的姿势”：
- 你有没有把通知当成唯一信号？
- 你有没有把 CI 当成唯一门禁？
- 你有没有把 webhook 当成永不丢的消息？
- 你有没有给自动化加退避、熔断、幂等、降级？
这些看起来像“架构洁癖”，但事故来时，它就是救命稻草。
下次再遇到“PR 没人回、CI 卡住、通知消失”，先别慌，先看状态页，再决定要不要开干——工程师的体力要用在刀刃上，不要用在跟平台对线🤝
喜欢就奖励一个“👍”和“在看”呗~
