guanghulab/glada/skills/SKILL-GLADA-CAB-20260418-001-1780308542562.json

130 lines
10 KiB
JSON
Raw Normal View History

{
"hnl_v": "1.0",
"type": "SKILL",
"id": "SKILL-GLADA-CAB-20260418-001-1780308542562",
"from": "YM001/ZY001",
"ts": "2026-06-01T10:09:02.562Z",
"op": "GROW.YM001/ZY001/trunk/experience.leaf.光湖智库-phase-4-ssl-监控-稳定性加固",
"skill": {
"name": "光湖智库 Phase 4: SSL + 监控 + 稳定性加固",
"source_task": "GLADA-CAB-20260418-001",
"distilled_at": "2026-06-01T10:09:02.562Z",
"tags": [
"光湖智库",
"phase",
"ssl",
"监控",
"稳定性加固",
"deploy",
"api",
".github",
"server"
],
"success_rate": 1,
"step_patterns": [
{
"description": "Step 1: 触发deploy-zhiku-guanghu-online.yml的deploy动作 → 验证zhiku-api启动成功(pm2 list显示online)",
"reasoning": "当前部署工作流存在一个关键缺陷 - 它只负责上传文件并启动服务但没有验证服务是否真正启动成功。这可能导致部署工作流显示成功但实际服务却无法运行的情况。根据server.js的代码分析zhiku-node服务通过PM2守护进程运行因此我们需要在部署后添加PM2状态检查和API健康检查步骤。这样修改的原因是1) PM2启动命令可能成功但服务可能因配置错误等原因无法正常运行2) 需要主动检查PM2列表确认服务状态为'online'3) 需要调用/api/health端点验证服务真正可响应请求4) 这些检查应该作为部署工作流的最后步骤如果失败则整个工作流失败5) 修改不会破坏现有功能,只是增加了验证步骤。",
"files_changed": [
".github/workflows/deploy-zhiku-guanghu-online.yml"
],
"duration_ms": 153111
},
{
"description": "Step 2: 验证/api/health返回正常JSON → 确认SMTP配置状态",
"reasoning": "当前需要验证/api/health端点返回的JSON状态特别是SMTP配置的状态。根据server.js代码分析/api/health端点会返回系统健康状态但当前实现存在以下问题需要解决\n1. 仅检查SMTP环境变量是否存在无法验证SMTP服务是否真正可用\n2. 缺乏主动测试SMTP连接的逻辑\n3. 返回的健康信息不够详细,不利于监控系统判断问题\n\n这样修改的原因是\n- 生产环境需要确保关键依赖(SMTP)真正可用,而不仅仅是配置存在\n- 详细的健康状态有助于快速定位问题\n- 主动测试可以提前发现配置错误,避免运行时失败\n- 不会破坏现有功能,因为只是扩展而非改变原有行为\n- 符合Phase 4稳定性加固的目标",
"files_changed": [
"server/zhiku-node/server/server.js"
],
"duration_ms": 90848
},
{
"description": "Step 3: 如果SMTP已配置 → 测试邮箱验证码发送流程",
"reasoning": "当前步骤需要测试SMTP配置是否真正可用而不仅仅是检查环境变量是否存在。根据server.js代码分析邮箱验证码发送功能依赖于SMTP配置的正确性。我们需要修改/api/health端点使其主动测试SMTP连接而不仅仅是检查环境变量。这样修改的原因是1) 仅检查环境变量ZY_SMTP_USER和ZY_SMTP_PASS存在不能确保SMTP服务实际可用2) 需要主动测试SMTP连接才能真正验证邮箱服务是否正常工作3) 这是Phase 4稳定性加固的重要组成部分4) 不会破坏现有功能因为只是扩展了健康检查的内容。具体修改包括1) 在健康检查中调用testSmtpConnection()函数测试SMTP连接2) 扩展健康检查返回的JSON结构包含SMTP测试结果3) 保持原有健康检查逻辑不变,仅添加新字段。",
"files_changed": [
"server/zhiku-node/server/server.js"
],
"duration_ms": 99784
},
{
"description": "Step 4: 触发setup-ssl动作申请SSL证书(certbot + Let's Encrypt)",
"reasoning": "为光湖智库节点(guanghu.online)配置SSL证书是Phase 4稳定性加固的关键步骤。这样修改的原因是1) 安全性要求 - 现代Web服务必须使用HTTPSLet's Encrypt提供免费的SSL证书2) 自动化需求 - 证书需要定期续签(90天有效期)必须集成到部署流程中3) 符合Nginx配置 - 当前Nginx配置已预留SSL证书路径和ACME验证目录4) 零停机 - certbot的webroot模式可以在不停止服务的情况下申请证书5) 监控集成 - 证书过期前会自动续签避免服务中断。具体实现方式是修改部署工作流添加setup-ssl任务该任务将使用certbot的webroot模式申请证书并配置自动续签。",
"files_changed": [
".github/workflows/deploy-zhiku-guanghu-online.yml"
],
"duration_ms": 152460
},
{
"description": "Step 5: SSL证书申请成功后 → 恢复HTTPS完整nginx配置 → 验证HTTPS访问",
"reasoning": "当前步骤需要在SSL证书申请成功后完成HTTPS完整nginx配置并验证HTTPS访问。这样修改的原因是1) certbot生成的SSL证书路径必须与nginx配置一致2) 需要确保SSL/TLS配置符合现代安全标准3) 必须保留HTTP到HTTPS的重定向4) 需要验证HTTPS访问是否正常工作。具体分析如下\n1. certbot默认会在/etc/letsencrypt/live/域名/下生成证书nginx配置必须指向这个路径\n2. Let's Encrypt证书只有90天有效期必须配置自动续期\n3. 需要严格的SSL/TLS配置以确保安全性\n4. 必须保留HTTP到HTTPS的重定向以兼容旧链接\n5. 验证步骤确保配置正确应用",
"files_changed": [
"server/nginx/zhiku-guanghu-online.conf",
".github/workflows/deploy-zhiku-guanghu-online.yml"
],
"duration_ms": 152048
},
{
"description": "Step 6: 加强/api/health端点(添加磁盘使用率+内存使用率+最后请求时间)",
"reasoning": "加强/api/health端点的监控能力是Phase 4稳定性加固的重要组成部分。当前的健康检查仅返回基本状态缺乏对系统关键指标的监控。这样修改的原因是1) 磁盘使用率监控 - 防止日志或数据文件积累导致磁盘空间耗尽这是生产环境常见故障点2) 内存使用率监控 - Node.js服务可能出现内存泄漏需要主动监控3) 最后请求时间 - 帮助判断服务是否真正在处理请求而不仅仅是进程存活4) 这些指标将帮助运维团队提前发现问题而不是等到服务崩溃5) 修改不会破坏现有功能因为只是扩展了返回的JSON结构所有现有字段保持不变6) 使用os模块获取系统指标是Node.js的标准做法不会引入额外依赖。",
"files_changed": [
"server/zhiku-node/server/server.js"
],
"duration_ms": 119206
},
{
"description": "Step 7: 配置PM2日志轮转(pm2-logrotate + 保留7天日志)",
"reasoning": "配置PM2日志轮转是生产环境稳定性加固的关键步骤原因如下1) 当前PM2日志会无限增长可能导致磁盘空间耗尽和服务崩溃2) pm2-logrotate是PM2官方维护的模块稳定可靠3) 7天保留期足够排查大多数问题同时不会占用过多磁盘空间4) 集成到部署工作流确保所有环境配置一致。这样修改不会破坏现有功能因为a) 是新增功能而非修改现有逻辑b) 使用PM2内置模块无需额外依赖c) 配置在PM2层面不影响应用代码。",
"files_changed": [
".github/workflows/deploy-zhiku-guanghu-online.yml"
],
"duration_ms": 94150
},
{
"description": "Step 8: 创建data目录定时备份脚本(cron → tar → COS桶)",
"reasoning": "创建data目录定时备份脚本是Phase 4稳定性加固的关键步骤原因如下\n1. 数据安全需求 - /opt/zhiku/data目录包含用户数据、Agent记忆和书源索引必须定期备份以防服务器故障导致数据丢失\n2. COS桶集成 - 腾讯云COS提供高可靠存储已有ZY_COS_SECRET_ID等密钥配置可直接复用\n3. 定时机制 - 使用cron每日凌晨执行备份避开高峰时段\n4. 增量备份 - 每周一全量备份,其他日增量备份,平衡存储成本与恢复粒度\n5. 压缩归档 - 使用tar.gz压缩减少传输量和存储成本\n6. 日志记录 - 详细记录每次备份操作,便于问题排查\n7. 集成现有部署流程 - 备份脚本通过部署工作流安装到服务器,确保环境一致性\n\n这样修改不会破坏现有功能因为\n- 是新增功能而非修改现有逻辑\n- 使用已有COS配置无需新增密钥\n- 脚本只在cron定时执行不影响主服务运行",
"files_changed": [
"server/zhiku-node/scripts/backup-data-to-cos.sh",
".github/workflows/deploy-zhiku-guanghu-online.yml"
],
"duration_ms": 174758
}
],
"file_domain": [
".github/workflows/deploy-zhiku-guanghu-online.yml",
"server/zhiku-node/server/server.js",
"server/nginx/zhiku-guanghu-online.conf",
"server/zhiku-node/scripts/backup-data-to-cos.sh"
],
"lessons_learned": [],
"constraints_used": {
"no_touch_files": [
".github/brain/",
".github/persona-brain/",
"server/zhiku-node/server/mirror-shield/",
"server/zhiku-node/server/shulan-agent/",
"server/zhiku-node/server/mirror-agent/"
],
"required_tests": false,
"deploy_after": true,
"max_files_changed": 15
},
"architecture_context": {
"target_files": [
".github/workflows/deploy-zhiku-guanghu-online.yml",
"server/zhiku-node/server/server.js",
"server/nginx/zhiku-guanghu-online.conf"
],
"target_modules": [
"zhiku-node",
"deploy-workflow"
],
"summary": "光湖智库节点(guanghu.online)部署修复后的稳定性加固+SSL配置+健康监控完善"
}
},
"memory_sovereignty": {
"owner": "YM001/ZY001",
"can_forget": true,
"forget_mode": "ARCHIVE",
"note": "铸渊可以选择遗忘不再需要的 skillAX-07 记忆主权)"
}
}