# 京东主控与六节点灾备

完整项目认知、文件关系、当前运行态与维护规则先读：`INDEX.hdlp`（编号 `JD-DR-001`）。

京东 `JD-FD-PRIMARY` 是日常主控，不是唯一恢复入口。六台个人节点分别持有独立、服务器端保存的恢复身份；Mac、浏览器和个人本地磁盘不保存恢复私钥。

## 两级故障

1. 京东授权服务损坏但 SSH 仍在线：从任一分控节点发起节点本地邮件授权，批准后使用受限恢复密钥调用京东固定恢复动作。
2. 京东主机完全离线：从至少两个不同云厂商保存的加密控制面备份重建京东，再轮换全部恢复密钥。SSH 反向恢复不能替代云厂商控制台重建。

## 强制边界

- 每个节点一把独立密钥，禁止六节点共用密钥。
- 京东 `authorized_keys` 对恢复密钥使用来源地址限制、`restrict` 和 forced-command。
- forced-command 仅允许 `health-check`、`restore-authz`、`restore-navigation-map`、`rollback-last-deploy`。
- 每次恢复必须先由发起节点向预登记邮箱发送工单；批准只产生一次性、短时恢复收据。
- 企业 `AW-GZ-001` 不属于六节点灾备组，不持有京东恢复私钥。
- 语言协议、零点原核频道和公开导航互通不扩大服务器权限。
- 所有恢复事件写入 root 所有的追加日志，并由独立审计密钥签名。

## 六个分控节点

`BS-GZ-006`、`BS-SG-001`、`BS-SG-002`、`BS-SG-003`、`BS-SH-005`、`ZY-SG-006`。

部署前必须逐台确认：当前导航图、节点身份、固定出口地址、邮件发送能力、恢复公钥指纹和加密备份状态。仓库收据不能替代现场检查。

## 六节点引导

从云控制台确认京东实例自己的公网 IPv4，再作为临时环境变量执行引导。不得把登录来源地址或云元数据错误正文当作实例地址：

```bash
JD_PUBLIC_IP='<verified-console-address>' \
  RECOVERY_PACKAGE=/tmp/jd-recovery-controller.tgz \
  bash bootstrap-six-node-recovery.sh
```

地址只写入服务器端 SSH 配置，不写入仓库。脚本验证 IPv4 格式，并以远端固定命令的退出码作为闭环成功依据。

## 现场状态（2026-07-20）

六个分控节点的反向健康检查均已验证为 `active / active`。上海节点另经云厂商自动化助手确认灾备配置存在、服务端口监听、反向检查成功。无地址或凭据写入仓库。

已知缺口：小湖灯中央授权服务曾无法读取 `BS-SH-005` 的实时导航图。该问题与上海灾备通道本身分离，后续须使用 `restore-navigation-map` 固定动作修复并新增回执。