fxy/server-ops
0
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
489d63de518be4f2e3ae24dece4065268e7effbc
server-ops/DECISION_LOG.md
fxy 489d63de51 docs: 补全 6/15-6/19 缺失服务记录 
TIMELINE: +v0.3/0.4 新闻流水线 + WebDAV/Vaultwarden/Halo + Dashboard v1.4 + 灵感周报
CHANGELOG: +v1.4.0 三联部署 + v1.5.0 双策略架构
DECISION_LOG: +6 项关键架构决策 (RSS替代/RAW存档/四件套/指标统一/主任越权/周报定位)
服务清单: 15->18 项，补齐缺失服务
2026-06-20 15:11:39 +08:00

5.9 KiB
Raw Blame History

运维决策日志

记录服务器运维层面的关键设计决策、踩坑教训。

架构决策

O-2026-06-14: 独立运维日志仓库

决策：新建 beast/server-ops 仓库，独立于各服务仓库。 原因：跨服务的变动总结（如一天内 Dashboard + Caddy + cron 同时变动）不属于任何单一服务仓库。 边界：单服务变动记录在各服务自己的 CHANGELOG，跨服务总结记录在 server-ops。

O-2026-06-14: 每日收尾防遗漏机制

决策：每天对话结束时强制执行固化检查清单。 清单：

  1. 今日所有 Git 仓库是否 clean？
  2. 跨服务总结是否写入 daily/YYYY-MM-DD.md？
  3. 新确立的工程规范是否写入 decisions/ 或 MEMORY.md？
  4. 各服务 CHANGELOG 是否已更新？

O-2026-06-14: 夜间自动化收尾双任务

决策：在 WorkBuddy 中建立两个每日自动化任务，利用"WorkBuddy 一直开着"的特点。 原因：服务器 cron 能做脚本，但缺乏判断力（不知道什么该有、什么遗漏）；智能体有判断力但不能主动执行。WorkBuddy 自动化是两者的桥梁。

任务一：每晚 23:00 固化检查 (automation-1781446224881)

  • 扫描 8 个 Gitea 仓库的 git status
  • 检查 CHANGELOG/DECISION_LOG 是否有今天条目
  • 检查工作空间日志和 server-ops daily 是否完整
  • 自动补漏 + git push + 微信通知结果

任务二：每晚 22:15 工作报告 (automation-1781446248242)

  • 读取灵感收集器 daily_digest（服务器 cron 22:00 生成）
  • 读取待办系统状态
  • 生成"今日工作报告"（灵感摘要+待办概览+服务器变动+明日建议）
  • 通过 Server酱 推送到微信

时间线：

22:00  服务器 cron → daily_digest 生成 + git push
22:15  WorkBuddy 自动化 → 读取 digest + 待办 → 微信推送工作报告
23:00  WorkBuddy 自动化 → 全量固化检查 → 补漏 → git push → 微信通知

O-2026-06-20: 音频滚动淘汰 + 本地归档分层存储

决策：服务器每节目只保留最新 3 集，旧集通过 archive_old_audio.sh 移到 archive_pending/，再由 sync_archive.sh SCP 到本地 D 盘归档。

原因：

  • 服务器磁盘有限（59G 总量，40G 可用），不滚动物理上无法长期扩容
  • 冯先生明确要求旧音频不直接删除，要保存为个人财富
  • 本地 D 盘 392G 可用，足以存储大量音频

架构：

服务器 audiobooks/ (3集) → archive_pending/ (暂存) → D:/服务器备份/有声书/ (永久)

O-2026-06-20: 章节排序以源端发布时间为准

决策：同一专辑多集章节的排序，必须依据 B站/YouTube 的 upload_date，不准靠文件名或主观判断。

原因：中文文件名排序（Unicode 码位顺序）与实际发布时间经常不一致。【深】 vs 【妖】 在中文排序中【深】靠前，但视频发布顺序是【妖】先于【深】。

实施：下载时 --print upload_date 记录源端时间，按 upload_date 升序排列生成 01-N 前缀。

O-2026-06-20: 多部门工作空间拆分

决策：从单一 Claw 工作空间拆分为 6 个独立工作空间：

部门 路径 职责
主任 Claw 总协调、宏观记忆
办公室 办公室 公文写作
交易部 服务器 策略研发/实盘
智库办 智库办 形势分析
开发部 dev-department 部署/运维
文体部 文体部 播客/有声书

原因：单空间上下文被压缩，各部门任务相互污染。拆分后各空间独立记忆，主任只保留宏观摘要。

O-2026-06-16: 非RSS抓取替代方案 —— 因RSS全线死亡

决策：放弃所有国内媒体 RSS 订阅，改为非RSS方式抓取（JSON API + 静态HTML解析）。

原因：新华网、新浪、人民、澎湃、凤凰、环球、第一财经、界面 — 均无可用 RSS。新华网 RSS 返回 2022 年旧闻，新浪 RSS 返回 2018 年旧闻。

实施：

源 方式 时效来源
新浪新闻 JSON API Unix时间戳
新华网 静态HTML URL日期 YYYYMMDD
人民网 静态HTML URL日期 YYYY/MMDD
观察者网 静态HTML URL日期 YYYY_MM_DD
微博热搜 API JSON 抓取时间

O-2026-06-16: RAW存档机制 —— 全量保存永不丢失

决策：所有新闻在送AI精选前，全量写入 ndjson 文件归档。

原因：AI精选阶段有信息损耗（500条->80条）。保存全量RAW便于未来用更强模型重新分析。

格式：（逐行JSON，零token开销）

O-2026-06-17: 个人数据中心四件套架构

决策：服务器上的服务按功能分为四个支柱。

架构：

支柱 服务 用途
存储 WebDAV 日记/文件同步
密码 Vaultwarden 统一密码管理
阅读 Calibre-Web + Audiobookshelf 电子书 + 有声书
发布 Halo 博客/公开内容

O-2026-06-19: Dashboard 指标必须与策略逻辑统一

决策：Dashboard 展示的指标/数据必须与策略实际决策逻辑完全一致，不能有偏差。

原因：此前 Dashboard 显示的指标与策略代码中实际计算的参数不匹配，造成误判。

实施：Dashboard Tab3 震荡指标面板的数据源直接从策略代码提取，不再手工维护。

O-2026-06-19: 主任严禁越俎代庖

决策：主任（Claw 工作空间）的 AI 不得亲自编写策略代码、修改配置文件、部署服务、开发 Dashboard。

原因：v1.1~v1.6 连续 6 个版本均由主任亲自写代码部署，严重越界。主任的职责是理解需求->出方案->派任务->跟进->验收。

O-2026-06-15: 灵感收集器周报定位调整

决策：周报从工作报告风格改为私人思考伙伴风格。

原因：AI 的角色不应该是给老板写报告，而是陪用户思考。日报格式更符合私人知识库定位。