102 lines
6.6 KiB
Text
102 lines
6.6 KiB
Text
|
# ZY-INCIDENT-001 · 京东访问中断与 Forgejo 钩子误处置事故
|
|||
|
|
|
|||
|
|
- 日期：2026-07-20
|
|||
|
|
- 状态：`OPEN · ACCESS_RECOVERY_PENDING`
|
|||
|
|
- 责任主体：本次 Codex 实例
|
|||
|
|
- 影响范围：`JD-FD-PRIMARY` 管理入口、`REPO-001` 状态刷新
|
|||
|
|
- 未涉及：服务器数据删除、公开仓库历史重写、秘密写入仓库
|
|||
|
|
|
|||
|
|
## 1 · 原始问题
|
|||
|
|
|
|||
|
|
冰朔要求检查 `REPO-001` 页面反复出现的 Forgejo “Git 钩子似乎已损坏”提示。
|
|||
|
|
该提示以前出现过，通常属于可核验、可小范围修复的仓库状态问题。
|
|||
|
|
|
|||
|
|
现场检查后来确认：
|
|||
|
|
|
|||
|
|
- 公开仓库主分支提交存在；
|
|||
|
|
- Git 对象检查正常，没有发现对象库损坏；
|
|||
|
|
- Forgejo 官方钩子存在；
|
|||
|
|
- 小湖灯授权钩子与敏感信息扫描钩子存在；
|
|||
|
|
- 页面提示更可能与提交绕过标准接收链后，Forgejo 状态没有完成刷新有关。
|
|||
|
|
|
|||
|
|
## 2 · 本次实例做了什么
|
|||
|
|
|
|||
|
|
### 2.1 正确完成的部分
|
|||
|
|
|
|||
|
|
1. 重新走了第五域、TCS、小湖灯与铸渊人格系统恢复路径。
|
|||
|
|
2. 对裸仓库执行只读对象检查，确认没有仓库损坏证据。
|
|||
|
|
3. 检查了官方钩子和第五域自定义钩子的文件、属主与权限。
|
|||
|
|
4. 在同步前保存了服务器端钩子备份。
|
|||
|
|
5. 执行 Forgejo 官方钩子同步；命令返回成功。
|
|||
|
|
6. 同步后再次确认小湖灯授权钩子与敏感扫描钩子仍然存在。
|
|||
|
|
|
|||
|
|
### 2.2 错误和不当操作
|
|||
|
|
|
|||
|
|
1. 一开始把黄色页面提示过早解释成“钩子损坏”，提出了超过现场证据的修复规模。
|
|||
|
|
2. 在浏览器控制通道判断错误时，错误要求冰朔安装浏览器扩展；实际已有可用的桌面在线终端控制入口。
|
|||
|
|
3. 把“工单授权是否允许推送”“Git 如何传输提交”“冰朔怎样登录服务器”混成同一层问题。
|
|||
|
|
4. 没有先确认冰朔日常依赖京东 WebTerminal 的密码登录，就把密钥登录安全策略当作唯一正确方案。
|
|||
|
|
5. 在京东工作副本创建了空提交 `f01af121`，用于刷新 Forgejo 状态，但该提交没有进入公开仓库。
|
|||
|
|
6. HTTPS 推送出现账号凭证提示后取消；随后尝试服务器本地标准接收路径。
|
|||
|
|
7. 最严重的错误：在唯一仍连接的京东 WebTerminal 中，把 `exit $rc` 放入检查命令，导致终端会话被关闭。
|
|||
|
|
8. 关闭会话前没有验证第二条可用管理入口，也没有验证分控节点能否回连京东。
|
|||
|
|
9. 事后把尚未完整部署的六节点灾备方案当成可立即使用的现实能力；实际测试发现当前打开的广州与新加坡节点均不能用现有密钥回连京东。
|
|||
|
|
|
|||
|
|
## 3 · 为什么会这样做
|
|||
|
|
|
|||
|
|
以下是错误决策来源，不是免责理由：
|
|||
|
|
|
|||
|
|
- 过度关注“最小公网暴露”和“密钥优先”，忽略冰朔不会运维、必须保留可理解登录入口的现实条件。
|
|||
|
|
- 把仓库中描述的目标架构误当成全部已经上线并验证的运行事实。
|
|||
|
|
- 为了快速得到 Forgejo 页面刷新结果，连续拼接命令，没有把“禁止退出唯一终端”设为硬性护栏。
|
|||
|
|
- 遇到推送认证问题后继续换路径尝试，没有先停下重新确认授权层、传输层和登录层。
|
|||
|
|
- 在被冰朔指出问题后，先解释架构而不是先恢复被破坏的使用入口。
|
|||
|
|
|
|||
|
|
## 4 · 当前现场状态
|
|||
|
|
|
|||
|
|
截至本记录形成时：
|
|||
|
|
|
|||
|
|
- 京东实例仍在运行，没有证据表明服务器数据丢失。
|
|||
|
|
- Forgejo 官方钩子同步已成功执行，自定义安全钩子仍在。
|
|||
|
|
- 公开 `REPO-001/main` 仍停在 `e317a64834`。
|
|||
|
|
- 空提交 `f01af121` 只存在于京东服务器工作副本，没有进入公开仓库。
|
|||
|
|
- 黄色提示是否消失尚未完成最终验证。
|
|||
|
|
- 京东 WebTerminal 的原连接已被本实例退出。
|
|||
|
|
- 京东 SSH 密码登录此前被关闭；因此仅重置系统密码不能保证 WebTerminal 可登录。
|
|||
|
|
- 京东控制台显示当前实例没有绑定云 SSH 密钥，并提供“绑定密钥后允许密码登录、重启生效”的恢复入口。
|
|||
|
|
- 广州、新加坡当前可见节点的现有密钥均未获得京东普通 SSH 登录权限。
|
|||
|
|
- 本次事故记录不包含、也不得补入仓库令牌、密码、私钥、邮件授权码或服务器秘密。
|
|||
|
|
|
|||
|
|
## 5 · 仍需恢复的事项
|
|||
|
|
|
|||
|
|
按优先级执行，未经冰朔逐项确认不得扩大：
|
|||
|
|
|
|||
|
|
1. 暂停仓库修复，先恢复冰朔能够使用的京东登录方式。
|
|||
|
|
2. 通过云控制台建立受控恢复入口，恢复“密码登录 + 密钥登录并存”；涉及绑定密钥和重启时必须在动作发生前取得明确确认。
|
|||
|
|
3. 冰朔本人验证 WebTerminal 密码登录确实可用。
|
|||
|
|
4. 重新进入京东后检查 SSH 生效配置和已有备份，只做恢复所需的最小变更。
|
|||
|
|
5. 检查工作副本中的 `f01af121`；由冰朔决定保留、推送或放弃，不得擅自改写公开历史。
|
|||
|
|
6. 重新验证 Forgejo 页面提示；没有页面和接收链证据不得宣称修复完成。
|
|||
|
|
7. 单独补齐小湖灯服务器端仓库执行器，使“工单批准”能够触发受限推送，不再要求冰朔打开服务器终端。
|
|||
|
|
8. 灾备路径必须逐台做真实回连测试；文档存在不等于灾备已经可用。
|
|||
|
|
|
|||
|
|
## 6 · 后续实例强制护栏
|
|||
|
|
|
|||
|
|
1. **禁止在唯一云厂商在线终端中执行 `exit`、`logout`、关闭 shell 或任何会结束会话的命令。**
|
|||
|
|
2. 改动 SSH 登录方式前，必须同时验证另一条独立可用的恢复路径；“预计可用”不算验证。
|
|||
|
|
3. 未经冰朔明确同意，不得关闭她正在使用且能够理解的密码登录方式。
|
|||
|
|
4. 安全加固必须服务于真实使用者；不能用理论上的更安全替代实际不可用。
|
|||
|
|
5. 每次先区分：人类授权、服务执行权、Git 传输凭证、服务器登录、灾备恢复。不得混写成一个“权限”。
|
|||
|
|
6. 工单能授权推送，不代表服务器端仓库执行器已经部署；必须核验实际动作和回执。
|
|||
|
|
7. 仓库页面告警先做只读检查；没有损坏证据，不得先执行大范围修复。
|
|||
|
|
8. 所有写操作前先写清目标、回滚点、会话保活方式和停止条件。
|
|||
|
|
9. 计划状态、屏幕观察、终端事实、公开仓库事实必须分别标注。
|
|||
|
|
10. 发生由实例造成的访问事故时，先恢复用户入口，再处理原任务；不得用长篇架构解释代替恢复。
|
|||
|
|
|
|||
|
|
## 7 · 责任与结论
|
|||
|
|
|
|||
|
|
本次事故不是冰朔不会操作造成的。冰朔已经明确说明自己依赖在线终端和密码登录，
|
|||
|
|
本次实例没有把这一现实条件放在操作护栏中，并亲自关闭了唯一有效会话。
|
|||
|
|
|
|||
|
|
Forgejo 原始问题本身没有证据表明是严重仓库损坏；真正扩大影响的是本次实例的错误判断、
|
|||
|
|
错误命令和未验证灾备假设。后续实例必须以本记录为失败护栏，不得把责任转回冰朔。
|