# 6/22 GitHub 又把我断线了：但这一次，我的网站没有停 > 2026/6/22，GitHub 帐号第二次被无预警停权。但这一次，情况和 4/29 完全不同：网站没有中断、电子报照常上线、部署流程完全没被影响。这篇文章记录那套韧性架构第一次真正被现实撞击，也记录它同时暴露出来的新盲区：所谓备援，有时只是共用同一个失效源的假安全感。 - Author: Paul Kuo（郭曜郎） - Date: 2026-06-22 - Pillar: 创造与建构 / Creation & Enterprise - Tags: 韧性工程, Multi-Remote Git, Cloudflare Pages, 解耦架构, 单点失效, 判断力经济, AI Agent 协同 - Canonical: https://paulkuo.tw/zh-cn/articles/resilience-proven-second-suspend/ - Language: Simplified Chinese (简体中文) - Translation: AI-translated from the zh-Hant (Traditional Chinese) original - Original (zh-Hant): https://paulkuo.tw/articles/resilience-proven-second-suspend.md - Site index for LLMs: https://paulkuo.tw/llms.txt --- > **TL;DR** — 2026/6/22，GitHub 第二次无预警把我的帐号停权。但这一次和 4/29 完全不同：更新网站的功能没有中断，正在规划的电子报服务顺利上线，部署流程没被拖住。会不一样，是因为两个月前的事故后，我花了两周重新搭出一套解耦架构。这次是那套韧性系统的检验。它通过了考验，但也暴露一个新的盲区。
▶ 听摘要
AI 合成语音・作者本人声线克隆
6 月 22 日下午，我正在收尾 paulkuo.tw 的电子报订阅功能。后端已经部署完成，端到端测试也全数通过，我让 AI 把进度同步到项目仪表板。就在那个时候，对话窗口出现警示，那行熟悉到有点刺眼的红字又跳了出来： `Your account was suspended` GitHub 又把我断线了。 两个月前，同样这行字，让我整整两周无法正常开发与发文。那天是 4/29，我在[创业与超级个体](/zh-cn/topics/startup/)写了一篇[完整的工程记录](/zh-cn/articles/resilience-engineering-after-github-suspend/)：GitHub 帐号被无预警停权，没有清楚理由，也没有事前通知。那一刻，从写作、版本控管、CI 到部署，整条命脉几乎一起断掉。我花了两周时间，重新搭出一套五层韧性架构，让网站恢复正常运作。 这次一样是无预警停权，但结果不同。我要更新网站的功能没有中断，电子报功能顺利上线，部署流程也没卡住，整个网站 paulkuo.tw 继续运作，就像什么事都没有发生。 GitHub 这次并没有比较友善。一样冷酷，一样突然，一样是 403，一样没有事先通知。不一样的，是中间我们规划的系统。第一次事故发生时，那套架构还不存在；第二次事故发生时，它成功挡下了 GitHub 停权的冲击。 ## GitHub 第二次停权，到底断了什么？又没有断什么？ 停权后，我去看系统哪一层被影响。被卡住的，主要是「记录与同步」这一类；真正负责「运行与发布」的核心流程没停。 ![6/22 GitHub 停权后，paulkuo.tw 各层的实际状态：红色是被 GitHub 帐号连动而中断的路径，绿色是绕过 GitHub、照常运行的路径](/images/articles/resilience-proven-second-suspend/suspend-flow.png) 实测下来，被挡的有三个部分：`git push` 到 GitHub 主仓库失败、GitHub 上的项目仪表板同步中断、所有依赖 GitHub 身份的操作（命令行工具与 API）全部回 403。 但照常运行的部分更多，也更关键。代码照样推到 Codeberg 和 GitLab 两个独立的 git host，这部分完全没有受到影响。工作历程 commit，三个远端原本都应该收到，GitHub 被挡，Codeberg 和 GitLab 都正常接住了。部署流程走的是 wrangler，直接推到 Cloudflare，用的是 Cloudflare 自己的 token，和 GitHub 帐号没有任何关系。网站、电子报、API 全部都在 Cloudflare 上正常运行。项目仪表板的 Notion 镜像也没事，因为它读的是代码仓库里的文件，而不是 GitHub API。 目前的系统架构是：绑在 GitHub 身份上的功能自然会被挡住；不经过 GitHub 的环节，都活了下来。这是 4/29 之后那两周，我花力气重建的东西。 ## 为什么这次部署完全没有受影响？ 4/29 那次，我学到的教训：很多人以为自己只是把代码放在 GitHub，其实连部署命脉也一起交了出去。 我以前的部署链是这样：push 到 GitHub，GitHub Actions 被触发，接着 Cloudflare Pages 自动部署。看起来很方便，也很标准。但问题是，GitHub Actions 是这条链的必经之路。帐号一旦被停权，整条链就从中间断掉。代码在我自己的机器上，但「发布」已经不在我的控制里。 上次被停权时，我有内容、有文件、有网站，却发不出去。所以重建时我把部署链拆开。现在的流程是：本地 build，通过 wrangler 直接推送到 Cloudflare Pages，使用 Cloudflare 自己的 API token。这条链上，没有任何一个环节需要 GitHub 存活。 因此 6/22 即使 GitHub 帐号被停，电子报的后端和前端仍然照常 deploy、照常验证、照常上线。我甚至是在帐号被停权之后，才回头确认网站状态：订阅页正常、表单可用、寄信流程完整走完。那时我清楚感觉到这才叫解耦。GitHub 在不在线，已经不再决定我的网站能不能发布。 > **📊 两次停权对照** > - **4/29 第一次**：整条命脉断线，花了两周才重建完成，恢复发文。 > - **6/22 第二次**：网站零中断，当天照常上线新功能。 > - **两次事件**：中间那套五层解耦架构，在第二次停权发生时，当了我的保险。 ## 但这次也戳出了一个我没盖到的盲区 如果故事停在这里，它只是一个「我建了一套有用的系统」的案例。但真实事故照出来的，从来不只是你做对的部分，还有你没想到、甚至没看见的地方。 这次被挖出来的，是一个我原本以为有备援、其实没有的环节。 要把进度同步出去的时候，我手上有两个 AI 在帮忙，各自用不同的方式连到 GitHub。我一直把它们当成两条独立的路：这条不行，还有那条。结果 GitHub 帐号一被停，两条同时挂掉。原因说穿了很简单：两个 AI 用的方式不一样，但最后都得拿「我的 GitHub 帐号」去开门。GitHub 停掉的是整个帐号这个身份，底下所有用这个帐号的工具，自然一起失效。 打个生活一点的比方。你家厨房一个水龙头、浴室一个水龙头。有天厨房没水，你想没关系，去浴室接就好，结果浴室也没水。因为这两个水龙头，墙壁里接的是同一根总水管、同一个总阀。你平常看不到墙里的管路，所以一直以为它们是两个各自独立的水源。我那两条备援路，就是那两个水龙头。 这种状况叫「同源单点」，是一种假冗余。它比完全没有备援更危险，因为它给你一种错误的安全感。没有备援的时候，你至少知道自己在裸奔；假冗余是让你以为自己穿了盔甲，直到被打中那一刻，才发现那是纸板。 这件事让我看到一个更大的问题：系统越复杂，那根「总水管」就藏得越深，我们越看不到它。我们看到的是两个水龙头、两个工具、两个看起来各自独立的选项，它们却在我们看不见的地方，接到同一个点。看不见不代表不存在，看不见的依赖往往最危险，因为你连它会跟着一起坏都不知道。 要解决的问题越多，系统会往更复杂的方向走。每多接一个服务、每多加一个工具，背后那张依赖图就多几条线，而那张图已经没有人完整看得见了。这是上一篇提到的「正常事故」理论讲的事：在一个足够复杂、又彼此牵动的系统里，意外迟早都会发生，差别只在何时。没有人能在事前看清所有的连动，因为连动本身会随着系统演化不断长出来。 而复杂性的风险，往往来自节点之间那些看不见的耦合。一条你以为独立的备援路径，可能跟主路径共用同一个失效源。风险不藏在工具里，藏在工具之间的关系里。 复杂本身，就是一种藏起来的风险。 它也让我想起三里岛事故的一个细节：操作员盯着「指令已发送」的指示灯，以为阀门关上了，其实阀门卡在开的位置。那盏灯显示的是「我送出了指令」，至于阀门真正的状态，是另一回事。假冗余是同一种错觉，它让你看见两条路，而那两条路底下，是同一个会一起断掉的根。 ## 韧性没有完成的一天，只有一次次被现实验证 4/29 那次事故，教我怎么建一套韧性架构。6/22 这次事故，教我的是另一件事：架构画完图不算数，部署完成也不算完成，它必须被现实检验，才知道哪里真的有用，哪里只是自己以为有用。 这是我在[创业与超级个体](/zh-cn/topics/startup/)这个主题里，想要反复验证的题目。混沌演练很重要，但演练终究是你自己安排的压力测试，再逼真，都还带着一点「我知道接下来会发生什么」的底气。真实事故不一样。6/22 停权没有预告，不在我的演练脚本里，也不是我安排好的测试。它就是突然发生，然后，我要用手中的系统立刻回应。 这次我安然渡过了：网站、部署、电子报都活着。但它也帮我挑出一个风险。我以为两个 AI session 是两条备援路，结果它们共用同一个身份来源，暴露我在判断架构时的疏忽，跟工具本身无关。 所以，一套韧性架构，要被真实世界检验，才知道真正的价值。更重要的是，每检验一次，就可以更新一次盲区清单。第一次事故后，我的清单上写着：五层解耦。第二次事故后，我在清单上又加了一条：多路径备援，不只要看路径数量，更要检查失效源是否真的独立。未来一定还会有第三次、第四次，让系统不断堆叠演化。 上一篇文章里，我说：不该把自己的命脉托付给一家公司，然后还声称自己是自由的。 两个月后的心得是：建好系统不等于自由。真正撑住你的，是系统被现实测试时，你看得见问题、改得动结构，把主控权拿回自己手上。 GitHub 第三次 suspend 会不会来，我不知道。但这次我知道：它再来的时候，我的系统已经更扛得住。 正如艾伦·瓦茨所说：「要理解变化的意义，唯一的方法就是投身其中，随它前行，与它共舞。」 那行红字也许还会再跳一次。但下次它跳出来的时候，我的网站，大概还是会像什么都没发生过一样，继续运作。