什么时候启动恢复路径？
| 场景 | 风险 | 做什么 |
|---|---|---|
| 成员换手机 | 无法登录个人账号 | 用 recovery code 或备用 2FA |
| owner 丢设备 | 组织无人管理 | 另一 owner 接管权限 |
| 外包离职 | 代码和 CI 泄露 | 移除权限并轮换密钥 |
| 强制 2FA 后掉线 | 成员被踢出组织 | 按名单逐个恢复邀请 |
我会把 GitHub 当成公司资产，而不是个人账号集合。独立开发者早期偷懒，最容易在第一个外包、第一台丢失的手机、第一次出差换卡时付学费。
标准 SOP 怎么写？
先确认组织至少有两个 owner。两个人不要共用同一个邮箱、手机和密码管理器主密钥。
每个 owner 下载 recovery codes，放进团队密码管理器的应急保险库，另存一份离线加密文件由创始人保管。
开启 passkeys 或硬件安全密钥作为备用。短信只做低优先级备份，不要当成唯一方案。
强制组织成员启用 2FA。执行前发通知，列出截止时间、恢复码保存方法和无法登录时找谁。
给外包协作者最小权限。能给单仓库就不给组织级，能给 read 就不给 write，能用 fine-grained token 就不用长期 classic PAT。
事故当天怎么处理？
如果成员丢了手机，让他先找 recovery codes、passkey、已登录设备。不要让别人代登他的账号。账号恢复完成后，重新生成 2FA 恢复码，并把旧设备会话全部登出。
如果 owner 丢了所有 2FA 方法，由另一 owner 先冻结风险：移除可疑 token、检查近期成员变更、确认 billing 和关键仓库权限。GitHub 的账户恢复政策对「所有恢复方式都丢失」非常严格，所以别把希望放在临时申诉上。
如果外包离职后联系不上，从组织移除，再轮换 GitHub Actions secrets、部署平台 token、npm token、Cloudflare token 和数据库只读账号。很多事故不是 GitHub 账号本身，而是 CI 里还留着旧密钥。
远程协作还有哪些细节？
跨时区团队需要一份「谁能在 30 分钟内接管」名单。名单里写 owner、billing 管理、CI 管理、域名管理，不要只写 Slack 昵称。
远程登录 GitHub、Cloudflare、收款后台时，我会固定设备和网络环境，避免频繁验证打断发布。团队如果经常在旅途中处理 CI、DNS 和仓库权限，可以准备海外服务跑 GitHub Actions / Cloudflare 的稳定线路，减少关键时刻的环境变量。
每季度检查表
- owner 是否仍是两人以上
- recovery codes 是否能找到
- 外包账号是否全部清理
- deploy key 是否有仓库归属说明
- GitHub Apps 是否仍需要访问
- CI secrets 是否有负责人和轮换日期
权限表应该怎么维护？
我会建一张很朴素的权限表，列出成员、角色、仓库、到期时间、审批人和备注。不要等公司很大才做这件事。远程团队最大的风险不是黑客电影里的入侵，而是「去年帮忙修过一次 bug 的外包」还留着 write 权限。
权限表每次项目结束都要更新。比如设计师只需要访问 issue 和 figma 链接，就不要给代码仓库；临时 DevOps 只需要一个月，就写到期时间。GitHub 组织里的 outside collaborator 很容易被遗忘，季度检查时要逐个点开看。
我还会把 2FA 恢复演练做成一次真实操作：新设备登录、找到恢复码、确认备用 owner 能进入 billing 和 secrets 页面。演练不需要真的禁用账号，但要证明材料找得到。很多团队写了 SOP，却没人知道保险库密码在谁手里，这和没有 SOP 差不多。