• 时间:
  • 分类:

2月9日 GitHub 确实出现了一波 通知延迟，并且伴随 多个核心服务的性能降级：包括 Actions、Git Operations、Issues、Pull Requests、Webhooks、Packages、Pages、Codespaces，甚至还波及到 Copilot、Dependabot 等相关能力。最后官方宣布恢复正常，并表示后续会发布更详细的 RCA（根因分析）。官方事件报告如下：
image

好，信息面上就这些，但小D作为每天在 GitHub 上“搬砖”的工程师，真正关心的通常是三件事：

1）到底发生了什么，会影响我哪些流程？
2）我现在遇到的问题，是 GitHub 的锅还是我的锅？
3）怎么快速自救，避免今晚继续加班？

1）这次异常的两条主线：通知慢 + 服务抖成筛子

A. 通知延迟（Notifications are delayed）

GitHub 官方描述很直白：通知出现积压，平均延迟从 约 50 分钟一路飙到 约 1 小时 20 分钟，随后逐步回落到 约 1 小时 → 30 分钟 → 15 分钟，最终宣布完全恢复。

image

人话：你的通知确实可能“晚到”，但不是不到。更扎心的是——通知这种东西晚到就等于失效。

  • 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（别自虐）

先打开：

如果状态页正在 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 卡住、通知消失”，先别慌，先看状态页，再决定要不要开干——工程师的体力要用在刀刃上，不要用在跟平台对线🤝

喜欢就奖励一个“👍”和“在看”呗~

image

标签: none

添加新评论