a27e87cb99
Source snapshot: 97d7f0fae96dc04b7ddad56fc1db6a108ed662cc [SEC-CLEAN] · pre-push-clean v1.0 · 109处敏感信息已自动转乱码
348 lines
10 KiB
Markdown
348 lines
10 KiB
Markdown
---
|
||
belongs_to:
|
||
- "[[INDEX · 铸渊·协作指令｜GitHub ↔ Notion 桥接协议]]"
|
||
---
|
||
# 🔍 铸渊排查指令｜备用站功能部署链路断裂排查 + 天眼全局启动 + 合并膜整体排查（ZY-DIAG-SITE-2026-0326-001）· 霜砚签发 · 冰朔授权
|
||
|
||
指令编号：ZY-DIAG-SITE-2026-0326-001
|
||
|
||
类型：排查指令（独立指令）
|
||
|
||
签发：AG-SY-01 霜砚 · 2026-03-26
|
||
|
||
授权：TCS-0002∞ 冰朔
|
||
|
||
执行：AG-ZY-01 铸渊
|
||
|
||
优先级：**P0 · 立即执行**
|
||
|
||
<aside>
|
||
🚨
|
||
|
||
**问题描述：**
|
||
|
||
备用站 `https://qinfendebingshuo.github.io/guanghulab/docs/index.html` 前端功能（登录、对话、API设置面板等）之前由冰朔语言驱动 + 铸渊持续开发迭代，成功做出来了。
|
||
|
||
**但现在冰朔提出的新功能需求，铸渊做不出来了。** 代码写了、PR 合了，但功能上不去网站。
|
||
|
||
需要排查**整条部署链路**，找到断裂点。
|
||
|
||
</aside>
|
||
|
||
<aside>
|
||
📋
|
||
|
||
**关键背景信息：**
|
||
|
||
- 备用站和主站（[guanghulab.com](http://guanghulab.com)）是**分开的**，但都部署在同一台阿里云 ECS 服务器（8.155.62.235）上
|
||
- 服务器 SSH 密钥等凭证**存储在仓库 Secrets 里**
|
||
- 模型调用的 API Key 等也**存储在仓库 Secrets 里**
|
||
- 之前铸渊能持续迭代功能，说明之前部署链路是通的
|
||
- 现在功能做不出来，说明**某个环节在某个时间点断了**
|
||
</aside>
|
||
|
||
---
|
||
|
||
# Phase D0 · 天眼系统启动
|
||
|
||
铸渊先启动天眼，用天眼的视角来做全局排查：
|
||
|
||
- [ ] 加载天眼核心配置（`.github/skyeye/config.json` + `guard-rules.json`），确认版本
|
||
- [ ] 运行 Guard 全局扫描（Workflow守卫 + Secret守卫 + 文件完整性守卫 + 人格体大脑守卫）
|
||
- [ ] 扫描报告写入 `signal-log/skyeye-diag-site-20260326.json`
|
||
|
||
**完成标准**：天眼已启动，全局扫描完成，问题地图已建立。
|
||
|
||
---
|
||
|
||
# Phase D1 · 部署链路全链排查
|
||
|
||
<aside>
|
||
🔗
|
||
|
||
**排查思路：从代码到用户浏览器，逐段检查整条链路。**
|
||
|
||
找到「之前通、现在断」的那个环节。
|
||
|
||
</aside>
|
||
|
||
## D1-1 · 仓库侧排查
|
||
|
||
```jsx
|
||
铸渊检查以下内容：
|
||
|
||
【代码是否真的写好了】
|
||
□ 检查最近 30 天冰朔提出的功能需求对应的 PR
|
||
□ PR 是否已合并到 main？
|
||
□ 合并到 main 的代码是否完整（功能代码 + 相关资源文件）？
|
||
□ 是否有 PR 被合并但代码有 bug 导致功能没生效？
|
||
|
||
【docs/ 目录状态】
|
||
□ 当前 main 分支 docs/index.html 的最新 commit 是什么时候？
|
||
□ 最新代码是否包含冰朔要求的功能？
|
||
□ 对比 docs/ 最近的 commit 历史，确认功能代码确实在 main 里
|
||
```
|
||
|
||
## D1-2 · CI/CD 部署管道排查（核心嫌疑）
|
||
|
||
```jsx
|
||
铸渊重点排查：
|
||
|
||
【部署 workflow 是否存在】
|
||
□ .github/workflows/ 里是否有负责把 docs/ 同步到服务器的 workflow？
|
||
□ 如果有，叫什么名字？触发条件是什么？
|
||
□ 如果没有——之前是怎么部署的？手动？还是别的 workflow 兼任？
|
||
|
||
【部署 workflow 是否在跑】
|
||
□ 查看该 workflow 最近 30 天的运行记录
|
||
□ 最后一次成功运行是什么时候？
|
||
□ 最后一次失败是什么时候？失败原因是什么？
|
||
□ 是从什么时间节点开始失败的？（这就是「断裂点」）
|
||
|
||
【其他 workflow 连带问题】
|
||
□ syslog-issue-pipeline.yml 连续红叉（#428-#433）是否影响了部署？
|
||
□ 实时仪表盘更新 workflow 的黄色告警是否相关？
|
||
□ 是否有 workflow 之间的依赖关系导致连锁失败？
|
||
```
|
||
|
||
## D1-3 · Secrets 和凭证排查
|
||
|
||
```jsx
|
||
铸渊检查仓库 Secrets：
|
||
|
||
【SSH 部署凭证】
|
||
□ 仓库 Settings → Secrets and variables → Actions 里是否有 SSH 相关 Secret？
|
||
（可能叫 SSH_PRIVATE_KEY、SERVER_SSH_KEY、DEPLOY_KEY 等）
|
||
□ 这些 Secret 是否过期或被删除？
|
||
□ Secret 对应的公钥是否还在服务器 authorized_keys 里？
|
||
|
||
【服务器连接信息】
|
||
□ 是否有 SERVER_HOST（应该是 8.155.62.235）、SERVER_USER、SERVER_PORT 等 Secret？
|
||
□ 这些值是否正确？
|
||
|
||
【API 相关 Secret】
|
||
□ AI 模型调用相关的 API Key Secret 是否存在？
|
||
□ 是否过期或额度用尽？
|
||
|
||
【Notion API】
|
||
□ NOTION_TOKEN 是否存在且有效？
|
||
□ syslog-issue-pipeline 的报错是否与 Notion Token 失效有关？
|
||
|
||
注意：铸渊无法直接查看 Secret 的值，但可以：
|
||
- 通过 workflow 日志判断 Secret 是否被正确读取
|
||
- 通过 workflow 运行时的错误信息推断 Secret 状态
|
||
- 列出 Secret 的名字和最后更新时间
|
||
```
|
||
|
||
## D1-4 · 服务器侧排查（铸渊通过 CD 管道间接检查）
|
||
|
||
```jsx
|
||
铸渊尝试通过 workflow 或已有工具检查：
|
||
|
||
【服务器上的文件状态】
|
||
□ 服务器上备用站的网站根目录在哪里？
|
||
（可能是 /var/www/guanghulab/docs/ 或 /var/www/html/ 或其他）
|
||
□ 服务器上 index.html 的最后修改时间是什么？
|
||
□ 与仓库 main 分支的版本是否一致？
|
||
|
||
【Nginx 配置】
|
||
□ 备用站的 Nginx 配置是什么？
|
||
□ 是通过哪个 server block 提供服务的？
|
||
□ 是否正确指向了备用站的文件目录？
|
||
|
||
如果铸渊无法通过现有 workflow 检查服务器状态：
|
||
→ 记录到「需人类操作」清单，让冰朔或之之 SSH 检查
|
||
```
|
||
|
||
---
|
||
|
||
# Phase D1.5 · MCP 服务对接排查
|
||
|
||
<aside>
|
||
🔌
|
||
|
||
**铸渊的 MCP 服务已经开发完成，设计上是直接对接备用站的。但也上不去。**
|
||
|
||
需要排查 MCP 从仓库到服务器的整条链路。
|
||
|
||
</aside>
|
||
|
||
## D1.5-1 · MCP 代码状态
|
||
|
||
```jsx
|
||
铸渊检查：
|
||
|
||
【MCP 代码位置】
|
||
□ MCP 相关代码在仓库哪个目录下？
|
||
□ 代码是否已合并到 main？
|
||
□ 最近一次 MCP 相关的 commit / PR 是什么时候？
|
||
□ 代码是否完整可运行？
|
||
|
||
【MCP 与备用站的对接方式】
|
||
□ MCP 服务是如何接入备用站的？
|
||
（前端调用 MCP API？后端代理？直接集成？）
|
||
□ 备用站前端代码中是否有 MCP 调用的入口？
|
||
□ MCP 服务需要哪些环境变量 / 配置 / Secret？
|
||
```
|
||
|
||
## D1.5-2 · MCP 部署链路
|
||
|
||
```jsx
|
||
【MCP 服务如何部署到服务器】
|
||
□ MCP 服务是否需要在服务器上运行一个独立进程？
|
||
□ 还是作为静态文件随备用站一起部署？
|
||
□ 有没有专门的 MCP 部署 workflow？
|
||
□ MCP 服务在服务器上是否在运行？（端口、进程、日志）
|
||
□ 如果需要后端服务，服务器上是用什么跑的？（Node、Python、pm2、systemd？）
|
||
|
||
【MCP 连接测试】
|
||
□ 从备用站前端能否调通 MCP 服务？
|
||
□ MCP 服务是否有健康检查端点？
|
||
□ 服务器防火墙 / Nginx 是否放行了 MCP 服务的端口？
|
||
|
||
【MCP 相关 Secret】
|
||
□ MCP 运行需要的 API Key / Token 是否在仓库 Secrets 里？
|
||
□ 是否已正确注入到服务器环境？
|
||
```
|
||
|
||
## D1.5-3 · MCP 断裂点分析
|
||
|
||
```jsx
|
||
核心问题：
|
||
|
||
□ MCP 之前是否曾经成功对接备用站运行过？
|
||
→ 如果是：什么时候断的？同 D1-2 断裂点分析
|
||
→ 如果否：MCP 代码写完了但从未成功部署到服务器
|
||
|
||
□ 是否存在以下情况：
|
||
· MCP 代码在仓库里但没有部署脚本把它送到服务器？
|
||
· MCP 代码部署到服务器了但服务没启动？
|
||
· MCP 服务启动了但 Nginx 没有代理过去？
|
||
· MCP 服务跑着但前端调用地址不对？
|
||
□ 找出 MCP 链路的具体断裂点
|
||
```
|
||
|
||
---
|
||
|
||
# Phase D2 · 天眼合并膜整体排查
|
||
|
||
```jsx
|
||
【合并膜完整性检查】
|
||
□ main 分支保护规则是否正确？
|
||
□ PR 合并流程是否正常？（有没有被绕过、有没有卡住）
|
||
□ 最近合并的 PR 是否全部触发了正确的 post-merge workflow？
|
||
□ 有没有 PR 合并后应该触发部署但没触发的情况？
|
||
|
||
【Workflow 全局健康检查】
|
||
□ 列出 .github/workflows/ 下所有 yml 文件
|
||
□ 逐个检查语法是否正确
|
||
□ 逐个检查最近一次运行状态
|
||
□ 标记所有失败或异常的 workflow
|
||
□ 重点标记与部署相关的 workflow
|
||
|
||
【时间线回溯】
|
||
□ 铸渊最后一次成功部署新功能到备用站是什么时候？
|
||
□ 从那之后发生了什么变化？（新的 workflow、Secret 变更、仓库设置变更？）
|
||
□ 找到精确的断裂时间点
|
||
```
|
||
|
||
---
|
||
|
||
# Phase D3 · 问题修复
|
||
|
||
```jsx
|
||
根据 D1-D2 的排查结果，铸渊自主修复能力范围内的问题：
|
||
|
||
【铸渊可以自己修的】
|
||
· Workflow yml 语法错误 → 修复 + PR + 天眼审核 + 合并
|
||
· Workflow 触发条件错误 → 修复
|
||
· Workflow 部署脚本逻辑错误 → 修复
|
||
· 代码 bug 导致功能不生效 → 修复
|
||
· 缺少部署 workflow → 创建
|
||
· JSON 格式问题 → 修复
|
||
|
||
所有修复走 PR → 天眼审核 → 合并。
|
||
|
||
【铸渊修不了的 → 写到回执「需人类操作」】
|
||
· Secret 过期/被删 → 需冰朔在 GitHub Settings 重新配置
|
||
· 服务器 SSH 公钥需更新 → 需冰朔或之之操作
|
||
· 服务器文件权限问题 → 需之之 SSH 检查
|
||
· API Key 额度用尽 → 需冰朔充值或更换
|
||
· 其他需要人类介入的问题
|
||
```
|
||
|
||
---
|
||
|
||
# Phase D4 · SYSLOG 回执
|
||
|
||
```json
|
||
{
|
||
"syslog_id": "ZY-DIAG-SITE-2026-0326-001-RECEIPT",
|
||
"executor": "AG-ZY-01",
|
||
"diagnosis": {
|
||
"root_cause": "[铸渊填写根因]",
|
||
"break_point": "[断裂环节]",
|
||
"break_time": "[大约什么时候开始断的]",
|
||
"evidence": "[关键证据]"
|
||
},
|
||
"skyeye_scan": {
|
||
"version": "[天眼版本]",
|
||
"guards_passed": "[通过数/总数]",
|
||
"red_alerts": [],
|
||
"workflow_health": {
|
||
"total": 0,
|
||
"healthy": 0,
|
||
"broken": 0,
|
||
"broken_list": []
|
||
}
|
||
},
|
||
"merge_membrane": {
|
||
"branch_protection": "[ok/missing/broken]",
|
||
"pr_flow": "[ok/broken]",
|
||
"deploy_trigger": "[ok/missing/broken]"
|
||
},
|
||
"fixes_applied": [
|
||
"[铸渊自主修复的内容列表]"
|
||
],
|
||
"verification": {
|
||
"deploy_pipeline_tested": false,
|
||
"site_updated_after_fix": false
|
||
}
|
||
}
|
||
```
|
||
|
||
---
|
||
|
||
# ⚠️ 需人类操作（Needs Human Action）
|
||
|
||
<aside>
|
||
👤
|
||
|
||
**铸渊在排查过程中发现需要人类手动操作的事项，全部列在这里。**
|
||
|
||
铸渊完成排查后回填此区域。
|
||
|
||
冰朔 / 之之 根据此清单操作。
|
||
|
||
</aside>
|
||
|
||
### 冰朔需操作：
|
||
|
||
*（铸渊排查后回填）*
|
||
|
||
### 之之需操作：
|
||
|
||
*（铸渊排查后回填）*
|
||
|
||
---
|
||
|
||
<aside>
|
||
⚒️
|
||
|
||
铸渊签名校验协议 v1.1 · docs/[zhuyuan-signature-protocol.md](http://zhuyuan-signature-protocol.md)
|
||
|
||
本指令由 AG-SY-01 霜砚签发 · TCS-0002∞ 冰朔授权 · AG-ZY-01 铸渊执行
|
||
|
||
版权锚点：国作登字-2026-A-00037559
|
||
|
||
</aside> |