From d213a1146cfb3c62e9d9828e0a0927489708109d Mon Sep 17 00:00:00 2001 From: zeaslity Date: Wed, 1 Jul 2026 10:44:16 +0800 Subject: [PATCH] =?UTF-8?q?=E5=A4=A7=E9=87=8F=E6=9B=B4=E6=96=B0?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- 1-Golang项目/3-go-writer-refresh.md | 42 + .../2-260625-协同方案-prompt.md | 18 + .../4-windows协同MacOS/3-260625-同步方案.md | 258 ++++ 36-统一单点登录/1-单点登录选型-prompt.md | 16 + 36-统一单点登录/2-Authentik集成方案-prompt.md | 17 + 36-统一单点登录/3-authentik部署.md | 217 ++++ 37-灾备方案设计/1-灾备方案设计-prompt.md | 70 ++ 37-灾备方案设计/2-gemini-生成方案.md | 177 +++ 37-灾备方案设计/XXX平台容灾备份方案设计.md | 1056 +++++++++++++++++ .../1-Go项目自动更新Postman.md | 13 + .../2-Go项目同步实现方案.md | 215 ++++ .../4-系统架构师/0-大模型提示词打磨专家.md | 9 + .../4-系统架构师/3-普通需求转化专业需求.md | 62 + 99-项目模板/4-系统架构师/3-需求文档优化师.md | 35 - .../4-系统架构师/4-PRD转化大模型专家.md | 40 - .../4-系统架构师/4-PRD转化大模型实现大纲.md | 89 ++ .../4-系统架构师/5-PRD转化AgentSkill.md | 99 ++ .../4-系统架构师/5-PRD转化AgentSkill大师.md | 0 .../4-系统架构师/6-PRD转化AgentSkill-增量.md | 89 ++ .../4-系统架构师/7-AgentSkill转化为PRD.md | 67 ++ tmp.md | 12 + 21 files changed, 2526 insertions(+), 75 deletions(-) create mode 100644 1-Golang项目/3-go-writer-refresh.md create mode 100644 35-黑苹果DELL/4-windows协同MacOS/2-260625-协同方案-prompt.md create mode 100644 35-黑苹果DELL/4-windows协同MacOS/3-260625-同步方案.md create mode 100644 36-统一单点登录/1-单点登录选型-prompt.md create mode 100644 36-统一单点登录/2-Authentik集成方案-prompt.md create mode 100644 36-统一单点登录/3-authentik部署.md create mode 100644 37-灾备方案设计/1-灾备方案设计-prompt.md create mode 100644 37-灾备方案设计/2-gemini-生成方案.md create mode 100644 37-灾备方案设计/XXX平台容灾备份方案设计.md create mode 100644 91-HarnessEngineering/1-API自动更新Postman/1-Go项目自动更新Postman.md create mode 100644 91-HarnessEngineering/1-API自动更新Postman/2-Go项目同步实现方案.md create mode 100644 99-项目模板/4-系统架构师/0-大模型提示词打磨专家.md create mode 100644 99-项目模板/4-系统架构师/3-普通需求转化专业需求.md delete mode 100644 99-项目模板/4-系统架构师/3-需求文档优化师.md delete mode 100644 99-项目模板/4-系统架构师/4-PRD转化大模型专家.md create mode 100644 99-项目模板/4-系统架构师/4-PRD转化大模型实现大纲.md create mode 100644 99-项目模板/4-系统架构师/5-PRD转化AgentSkill.md delete mode 100644 99-项目模板/4-系统架构师/5-PRD转化AgentSkill大师.md create mode 100644 99-项目模板/4-系统架构师/6-PRD转化AgentSkill-增量.md create mode 100644 99-项目模板/4-系统架构师/7-AgentSkill转化为PRD.md diff --git a/1-Golang项目/3-go-writer-refresh.md b/1-Golang项目/3-go-writer-refresh.md new file mode 100644 index 0000000..e1c2e3a --- /dev/null +++ b/1-Golang项目/3-go-writer-refresh.md @@ -0,0 +1,42 @@ +你是一名精通go语言开发的顶级专家，精通各种设计模式，精通熟练的开发代码规范，喜欢写注释 喜欢打印日志；你需要从工程实际的角度，帮我考虑现在的skill developing-go-gin-gorm 存在何种设计缺漏 请梳理 + + +**核心缺漏** + +1. **与当前工程约定不一致** + skill 要求使用 `pkg/common`、`common.ResponseSuccess/Error`，但当前工程实际用的是 `rmdc-common/pkg/wdd_res`、`wdd_log`，例如 [internal/handler/user_handler.go](/Users/wdd/Documents/IdeaProjects/RMDC-CLOUD/rmdc-cloud-center/internal/handler/user_handler.go:10)。`go.mod` 也明确依赖 `rmdc-common`：[go.mod](/Users/wdd/Documents/IdeaProjects/RMDC-CLOUD/rmdc-cloud-center/go.mod:6)。如果按 skill 生成新代码，容易直接编译失败。 + +2. **API 风格前后冲突** + 主规范强制 `POST + RequestBody`：[SKILL.md](/Users/wdd/Documents/IdeaProjects/RMDC-CLOUD/rmdc-cloud-center/.agents/skills/coding-go-gin-gorm/SKILL.md:183)，但 `framework-usage.md` 示例又用了 `GET/PUT/DELETE` 和 `/:id`：[framework-usage.md](/Users/wdd/Documents/IdeaProjects/RMDC-CLOUD/rmdc-cloud-center/.agents/skills/coding-go-gin-gorm/reference/framework-usage.md:17)。当前工程路由也是 REST 混合风格：[internal/handler/router.go](/Users/wdd/Documents/IdeaProjects/RMDC-CLOUD/rmdc-cloud-center/internal/handler/router.go:44)。这里必须明确：是“新模块统一 POST”，还是“兼容旧路由，只新增接口遵循 POST”。 + +3. **示例代码存在污染生成结果的错误** + `handler-example.go` 使用 `c.Param("id")`，与 POST Body 规范冲突：[handler-example.go](/Users/wdd/Documents/IdeaProjects/RMDC-CLOUD/rmdc-cloud-center/.agents/skills/coding-go-gin-gorm/examples/handler-example.go:31)。同文件还用了 `common.CodeBusiness`：[handler-example.go](/Users/wdd/Documents/IdeaProjects/RMDC-CLOUD/rmdc-cloud-center/.agents/skills/coding-go-gin-gorm/examples/handler-example.go:65)，但错误码定义里是 `CodeBusinessError`：[error-codes.go](/Users/wdd/Documents/IdeaProjects/RMDC-CLOUD/rmdc-cloud-center/.agents/skills/coding-go-gin-gorm/reference/error-codes.go:20)。 + +4. **错误处理模型太粗** + 现在是 Handler 直接判断 `gorm.ErrRecordNotFound`：[SKILL.md](/Users/wdd/Documents/IdeaProjects/RMDC-CLOUD/rmdc-cloud-center/.agents/skills/coding-go-gin-gorm/SKILL.md:290)。更好的工程模型是：DAO 返回底层错误，Service 转换为领域错误或 `AppError`，Handler 只做统一错误响应映射。否则 Handler 会泄漏 GORM 细节，跨层边界不干净。 + +5. **多数据库架构没有纳入 skill** + 当前项目有 `DAOManager`，并区分 User、CI、Core 等数据库：[internal/dao/dao_manager.go](/Users/wdd/Documents/IdeaProjects/RMDC-CLOUD/rmdc-cloud-center/internal/dao/dao_manager.go:10)。skill 仍按单 `*gorm.DB` 模板讲，缺少“多库 DAO 注入、跨库禁止事务、DAOManager 使用规则、模块应该选哪个 DB”的约束。 + +6. **事务设计不完整** + `framework-usage.md` 让 Service 直接持有 `s.db.Transaction`：[framework-usage.md](/Users/wdd/Documents/IdeaProjects/RMDC-CLOUD/rmdc-cloud-center/.agents/skills/coding-go-gin-gorm/reference/framework-usage.md:228)，但主分层又强调 Service 只编排 DAO。建议补 Unit of Work / TxDAO 模式：Service 开事务，DAO 方法接收 tx，禁止事务里混用非 tx DAO。 + +7. **时间规范不落地** + skill 强制 `TimeUtils.Now()`：[SKILL.md](/Users/wdd/Documents/IdeaProjects/RMDC-CLOUD/rmdc-cloud-center/.agents/skills/coding-go-gin-gorm/SKILL.md:408)，但当前项目本地工具叫 `utils.GetNow()`：[pkg/utils/time_utils.go](/Users/wdd/Documents/IdeaProjects/RMDC-CLOUD/rmdc-cloud-center/pkg/utils/time_utils.go:10)，并且代码里仍大量 `time.Now()`。需要明确到底用 `rmdc-common` 的 TimeUtils，还是本项目 `pkg/utils`，并补迁移规则。 + +8. **日志规范没有和实际日志库签名对齐** + skill 示例写 `log.Info(ctx, "...", map[string]interface{}{...})`，但项目实际是 `wdd_log.Info("format", args...)`：[auth_handler.go](/Users/wdd/Documents/IdeaProjects/RMDC-CLOUD/rmdc-cloud-center/internal/handler/auth_handler.go:9)。这会导致生成代码不可编译。还缺少敏感字段脱敏、request_id/user_id 标准字段、外部调用耗时日志规范。 + +9. **安全与审计规则太薄** + 只在 API 设计里一句“写操作需审计”：[api-design-spec.md](/Users/wdd/Documents/IdeaProjects/RMDC-CLOUD/rmdc-cloud-center/.agents/skills/coding-go-gin-gorm/reference/api-design-spec.md:263)。缺少权限中间件接入、JWT claims 获取、管理员校验、敏感日志脱敏、注册/登录/权限变更审计、限流、CORS、密码/Token 禁止入日志等细则。 + +10. **验证闭环不可用** + `validate-structure.sh` 在当前环境直接因 CRLF 换行失败；我跑了一下，bash 报 `command not found` 和 `syntax error near unexpected token do\r`。脚本文件也确实是 CRLF。并且脚本只查目录、反向依赖、`time.Now()`，没查 `c.JSON`、路由风格、错误码、`go test`、`go vet`、`gofmt`。 + +**建议补强方向** + +优先把 skill 分成三种模式：`new-module`、`modify-existing`、`review-only`。新模块可以强制 POST Body；改旧模块必须尊重现有路由和公共库。 + +然后把所有示例改成当前工程真实包名：`wdd_res`、`wdd_log`、当前 module path、多 DB `DAOManager`、现有 middleware。示例必须保证可编译。 + +最后补一套硬校验：`gofmt`、`go test ./...`、禁止 `c.JSON`、禁止跨层 import、禁止未处理 error、检查 `time.Now()`、检查 Handler 是否直接 import `gorm`。这样这个 skill 才会从“开发偏好”变成“工程护栏”。 \ No newline at end of file diff --git a/35-黑苹果DELL/4-windows协同MacOS/2-260625-协同方案-prompt.md b/35-黑苹果DELL/4-windows协同MacOS/2-260625-协同方案-prompt.md new file mode 100644 index 0000000..751b731 --- /dev/null +++ b/35-黑苹果DELL/4-windows协同MacOS/2-260625-协同方案-prompt.md @@ -0,0 +1,18 @@ +你是一名精通利用大模型Agent开发的工程师，你熟练的使用各类的Agent工具，如ClaudeCode Codex Reasonix OpenCode等 + +你更加偏向于使用桌面客户端的形式 + +你熟练使用windows和macos系统，你熟悉这两个系统的文件管理方式，文件权限管理方式，系统服务管理方式，网络配置管理方式 + +我有MacOS和Windows两台电脑，我的工作主力是Windows，我能否将MacOS设置为Agent执行的中枢，永不停机 + +MacOS的性能不是那么的好，所以编辑器IDEA Antigravity还是放置在Windows上面 + +现在的方案是 +1. 通过Windows的Codex桌面客户端远程控制MacOS上面的桌面客户端 +2. 通过Mutagen进行双向同步，将Windows的人工编辑内容同步到MacOS, 以及将MacOS的Agent执行的代码增量同步到Windows + + +我的windows使用UniGetUI，内部有winget,chocalaty等包管理工具 + +请你基于上述的信息，给出完整包含Windows和MacOS双端的Mutagen设置方法以及使用注意实现 diff --git a/35-黑苹果DELL/4-windows协同MacOS/3-260625-同步方案.md b/35-黑苹果DELL/4-windows协同MacOS/3-260625-同步方案.md new file mode 100644 index 0000000..8017e5f --- /dev/null +++ b/35-黑苹果DELL/4-windows协同MacOS/3-260625-同步方案.md @@ -0,0 +1,258 @@ +以下是基于你的 **Windows (主力开发) + macOS (Agent 执行中枢)** 架构的完整 Mutagen 双端配置方案。 + +*** + +## 整体架构说明 + +核心思路是：macOS 作为永不停机的 Agent 执行节点，Windows 上的 IDEA/Antigravity 负责人工编辑，Mutagen 在两端之间保持代码实时双向同步。 `.git` 目录仅保留在 macOS 侧（Agent 提交端），Windows 侧只同步 working tree。 + +``` +Windows (IDEA/Antigravity 编辑) + ↕ Mutagen SSH 双向同步 (two-way-resolved) +macOS (Codex / ClaudeCode Agent 执行中枢，永不停机) +``` + +*** + +## 安装 Mutagen + +**macOS 端：** +```bash +brew install mutagen-io/mutagen/mutagen +# 注册为登录项，实现永不停机自启 +mutagen daemon register +mutagen daemon start +``` + +**Windows 端（PowerShell，推荐 Scoop）：** +```powershell +scoop bucket add mutagen https://github.com/mutagen-io/mutagen-scoop +scoop install mutagen +# 注册为 Windows 登录自启动 +mutagen daemon register +mutagen daemon start +``` + +Mutagen daemon 支持通过 `mutagen daemon register` 命令在 macOS（launchd）和 Windows（登录启动项）上注册系统级自动启动 ，无需手动编写 plist 或注册表。 [mutagen](https://mutagen.io/documentation/introduction/daemon/) + +*** + +## SSH 互信配置 + +Mutagen 通过 SSH 建立连接，Windows 侧作为发起端（client），macOS 侧作为服务端。 + +**macOS 端开启 SSH：** +```bash +# 系统偏好设置 → 共享 → 远程登录 开启 +# 或命令行 +sudo systemsetup -setremotelogin on +# 确认监听 +sudo launchctl load -w /System/Library/LaunchDaemons/ssh.plist +``` + +**Windows 端配置 SSH 密钥免密登录：** +```powershell +# 生成密钥（若已有可跳过） +ssh-keygen -t ed25519 -C "mutagen-win-to-mac" + +# 将公钥追加到 macOS 的 authorized_keys +# 在 Windows PowerShell 中： +type $env:USERPROFILE\.ssh\id_ed25519.pub | ssh robert@ "cat >> ~/.ssh/authorized_keys" +``` + +验证免密连通性： +```powershell +ssh robert@ "echo ok" +``` + +*** + +## 全局配置文件（两端均建议配置） + +在 **macOS** 和 **Windows** 的 `~/.mutagen.yml`（Windows 为 `%USERPROFILE%\.mutagen.yml`）中写入： + +```yaml +sync: + defaults: + mode: two-way-resolved + maxEntryCount: 1000000 + scanMode: accelerated + watch: + mode: portable # ✅ 正确：嵌套在 watch 下 + ignore: + vcs: true + paths: + - ".idea/**" + - "*.class" + - "*.pyc" + - "__pycache__/**" + - "node_modules/**" + - ".venv/**" + - "venv/**" + - "dist/**" + - "build/**" + - "*.log" + - ".DS_Store" + - "Thumbs.db" + symlink: + mode: portable + permissions: + defaultFileMode: 0644 + defaultDirectoryMode: 0755 +``` + +`two-way-resolved` 模式在冲突时以修改时间较新的一方为准，适合人工编辑（Windows）与 Agent 自动生成（macOS）并行的场景 。`--ignore-vcs` 保证 `.git` 目录只留在 macOS Agent 端，Windows 只是纯 working tree 。 [github](https://github.com/mutagen-io/mutagen/issues/235) + +*** + +## 创建同步会话 + +在 **Windows PowerShell** 中执行（由 Windows 侧发起 Session）： + +```powershell +# 主项目同步 +mutagen sync create ` + --name="RMDC-CLOUD-SYNC" ` + --mode=two-way-resolved ` + --ignore-vcs ` + --ignore=".idea/**" ` + --ignore="*.class" ` + --ignore="__pycache__/**" ` + --ignore="node_modules/**" ` + --ignore=".venv/**" ` + --ignore="*.log" ` + --symlink-mode=portable ` + "C:\Users\wdd\Documents\IdeaProjects\RMDC-CLOUD" ` + "wdd@192.168.1.30:/Users/wdd/Documents/IdeaProjects/RMDC-CLOUD" +``` + +如果有多个项目，可以为每个项目单独创建 session，用 `--name` 区分： + +```powershell +mutagen sync create ` + --name="AGI-PROMPT-SYNC" ` + --mode=two-way-resolved ` + --ignore-vcs ` + --ignore=".idea/**" ` + --ignore="*.class" ` + --ignore="__pycache__/**" ` + --ignore="node_modules/**" ` + --ignore=".venv/**" ` + --ignore="*.log" ` + --symlink-mode=portable ` + "C:\Users\wdd\Documents\IdeaProjects\ProjectAGiPrompt" ` + "wdd@192.168.1.30:/Users/wdd/Documents/IdeaProjects/ProjectAGiPrompt" +``` + +*** + +## 使用 Mutagen Project 编排多项目（推荐） + +在项目根目录创建 `mutagen.yml`，方便一键启停所有 session： + +```yaml +# Windows 项目根目录下的 mutagen.yml +sync: + backend: + alpha: "." + beta: "robert@:~/Projects/myproject" + mode: "two-way-resolved" + ignore: + vcs: true + paths: + - ".idea/**" + - "__pycache__/**" + - "node_modules/**" + - ".venv/**" + - "*.log" + - "dist/**" + - "build/**" + symlink: + mode: "portable" + watch: + mode: "portable" +``` + +使用方式： +```powershell +cd C:\Users\Robert\Projects\myproject +mutagen project start # 启动所有 session +mutagen project list # 查看状态 +mutagen project flush # 强制立即同步一次 +mutagen project pause # 暂停 +mutagen project terminate # 终止 +``` + +*** + +## macOS 永不停机配置 + +除了 `mutagen daemon register` 之外，还需要防止 macOS 休眠中断同步： + +```bash +# 禁止 macOS 休眠（适合作为 Agent 服务器） +sudo pmset -a sleep 0 +sudo pmset -a disksleep 0 +sudo pmset -a displaysleep 30 # 屏幕可以睡，系统不睡 +sudo pmset -a powernap 1 # 开启 Power Nap 保持网络 +``` + +确认当前电源策略： +```bash +pmset -g +``` + +*** + +## 关键使用注意事项 + +### ⚠️ 冲突处理规则 +`two-way-resolved` 会以**修改时间较新**的文件覆盖较旧的，Agent 批量生成文件时速度很快，如果你在 Windows 同时手动编辑同一文件，存在覆盖风险。建议： +- Agent 执行期间，避免在 Windows 上同时修改 Agent 正在处理的文件 +- 利用 `mutagen sync pause --name=agent-project-sync` 在需要时临时暂停 + +### ⚠️ `.git` 目录仅留 macOS 侧 +由于配置了 `--ignore-vcs`，Windows 侧没有 `.git`，**不能在 Windows 侧执行 git 操作**，所有 commit / branch 操作需要在 macOS 上进行（或通过 SSH 远程到 macOS 执行）。 [mutagen](https://mutagen.io/documentation/synchronization/version-control-systems/) + +### ⚠️ 大文件 / 二进制文件 +模型权重、数据集等大文件不应纳入同步范围，在 `ignore` 中明确排除： +```yaml +- "models/**" +- "*.bin" +- "*.safetensors" +- "*.gguf" +- "data/**" +``` + +### ⚠️ 网络中断恢复 +Mutagen 会自动重连，SSH 断线后 daemon 保持 session 状态，重新连接后会自动 reconcile。可以通过以下命令检查 session 健康状态： +```powershell +mutagen sync list # 查看所有 session 状态 +mutagen sync monitor agent-project-sync # 实时监控某个 session +``` + +### ⚠️ Windows 路径与权限 +Windows 侧文件默认没有 POSIX 权限概念，Mutagen 会使用 `--default-file-mode` 和 `--default-directory-mode` 来为同步到 macOS 的文件设置权限： +```powershell +mutagen sync create ` + --default-file-mode=0644 ` + --default-directory-mode=0755 ` + ... +``` + +*** + +## 日常操作速查 + +| 操作 | 命令（Windows PowerShell） | +|---|---| +| 查看所有 session | `mutagen sync list` | +| 实时监控同步状态 | `mutagen sync monitor ` | +| 强制立即同步 | `mutagen sync flush ` | +| 暂停同步 | `mutagen sync pause ` | +| 恢复同步 | `mutagen sync resume ` | +| 重置冲突 | `mutagen sync reset ` | +| 停止并删除 session | `mutagen sync terminate ` | +| 守护进程状态 | `mutagen daemon stop && mutagen daemon start` | + +Mutagen daemon 升级后需要重启：先 `mutagen daemon stop` 再 `mutagen daemon start`，直接升级不重启会有 API 版本不匹配警告 。 [mutagen](https://mutagen.io/documentation/introduction/getting-started/) \ No newline at end of file diff --git a/36-统一单点登录/1-单点登录选型-prompt.md b/36-统一单点登录/1-单点登录选型-prompt.md new file mode 100644 index 0000000..7c8fc57 --- /dev/null +++ b/36-统一单点登录/1-单点登录选型-prompt.md @@ -0,0 +1,16 @@ +你是一名精通现在软件设计和前沿用户认证系统的专家 + +我的需求背景如下 +1. 需要为Docmost GitLab等开源的工具。设计一个统一的用户认证中心即单点登录 +2. 服务器全部位处中国大陆境内，不考虑Gmail GitHub等SSO集成的方式 + + +请基于上述背景，考虑开源的单点登录实现，分析各方案的优劣，给出综合的对比分析 + +设想 +1. 在单点登录服务器中统一设置所有的用户信息 + + +一个“统一认证中心 + 多应用 SSO”的方案，优先选择 Authentik 或 Keycloak 作为中心 IdP，通过 OIDC / SAML 对接 GitLab，自托管 Docmost 则通过其 SAML/OIDC 企业能力或反向代理方案接入 + +上述的Authentik，能否支持统一设置所有的用户信息，其他的应用直接使用这些账号和密码 \ No newline at end of file diff --git a/36-统一单点登录/2-Authentik集成方案-prompt.md b/36-统一单点登录/2-Authentik集成方案-prompt.md new file mode 100644 index 0000000..76ea28b --- /dev/null +++ b/36-统一单点登录/2-Authentik集成方案-prompt.md @@ -0,0 +1,17 @@ +你是一名精通现代软件设计和前沿用户认证系统的专家 + +背景介绍： +1. 选择使用 Authentik 作为统一认证中心，服务于为Docmost GitLab等开源的工具，为他们设置单点登录 +2. 服务器全部位处中国大陆境内，不考虑Gmail GitHub等SSO集成的方式 + + +你的任务： +1. Authentik的单机docker-compose的部署方案，给出必要的系统设置，给出compose即可 + 1. 需要持久化保存数据 +2. Docmost集成Authentik的详细方案 +3. GitLab集成Authentik的详细方案 + + +我已经实现了Authentik2025.6.4的部署，已经成功进入了系统 + +请给出GitLab 11.1.8 集成Authentik的详细方案 \ No newline at end of file diff --git a/36-统一单点登录/3-authentik部署.md b/36-统一单点登录/3-authentik部署.md new file mode 100644 index 0000000..0371ada --- /dev/null +++ b/36-统一单点登录/3-authentik部署.md @@ -0,0 +1,217 @@ +以下是为你量身打造的 Authentik 单机 `docker-compose` 部署方案，适合中国大陆服务器环境，镜像使用 `ghcr.io` 官方源（如访问有困难可配置代理或 mirror）。 + +*** + +## 目录结构 + +部署前先创建工作目录： + +```bash +mkdir -p /opt/authentik/{media,certs,custom-templates,backups} +cd /opt/authentik +``` + +*** + +## `.env` 环境变量文件 + +先生成密钥并写入 `.env`，这一步**必须执行**： [docs.goauthentik](https://docs.goauthentik.io/install-config/install/docker-compose/) + +```bash +echo "PG_PASS=$(openssl rand -base64 36 | tr -d '\n')" >> .env +echo "AUTHENTIK_SECRET_KEY=$(openssl rand -base64 60 | tr -d '\n')" >> .env +``` + +完整 `.env` 参考（根据实际修改）： + +```dotenv +# PostgreSQL 密码（由上面命令自动生成，勿手填） +PG_PASS= + +# Authentik 核心密钥（由上面命令自动生成） +AUTHENTIK_SECRET_KEY= + +# 对外暴露端口（按需修改，如已有反代则设为内部端口即可） +COMPOSE_PORT_HTTP=9000 +COMPOSE_PORT_HTTPS=9443 + +# 邮件配置（可选，用于验证码/告警，中国大陆推荐 SMTP 465） +# AUTHENTIK_EMAIL__HOST=smtp.example.com +# AUTHENTIK_EMAIL__PORT=465 +# AUTHENTIK_EMAIL__USERNAME=noreply@example.com +# AUTHENTIK_EMAIL__PASSWORD=your_email_password +# AUTHENTIK_EMAIL__USE_SSL=true +# AUTHENTIK_EMAIL__FROM=authentik@example.com + +# 禁用错误上报（中国大陆环境下建议关闭，避免外联超时） +AUTHENTIK_ERROR_REPORTING__ENABLED=false + +# 时区（注意：authentik 容器内部必须使用 UTC，不要挂载 /etc/localtime） +# Web UI 会自动本地化显示时间 +``` + +> ⚠️ **重要**：官方明确说明，不要在 authentik 容器内修改或挂载 `/etc/timezone` / `/etc/localtime`，否则会导致 OAuth/SAML 认证异常。 [docs.goauthentik](https://docs.goauthentik.io/install-config/install/docker-compose/) + +*** + +## `docker-compose.yml` + +```yaml +--- +services: + + # ── PostgreSQL 数据库 ────────────────────────────────────────── + postgresql: + image: docker.io/library/postgres:16-alpine + container_name: authentik-db + restart: unless-stopped + healthcheck: + test: ["CMD-SHELL", "pg_isready -d $${POSTGRES_DB} -U $${POSTGRES_USER}"] + start_period: 20s + interval: 30s + retries: 5 + timeout: 5s + environment: + POSTGRES_PASSWORD: ${PG_PASS} + POSTGRES_USER: authentik + POSTGRES_DB: authentik + volumes: + - authentik_db:/var/lib/postgresql/data # 持久化数据库 + networks: + - authentik-internal + + # ── Redis 缓存 ───────────────────────────────────────────────── + redis: + image: docker.io/library/redis:7-alpine + container_name: authentik-redis + restart: unless-stopped + command: --save 60 1 --loglevel warning + healthcheck: + test: ["CMD-SHELL", "redis-cli ping | grep PONG"] + start_period: 20s + interval: 30s + retries: 5 + timeout: 3s + volumes: + - authentik_redis:/data # 持久化 Redis 数据 + networks: + - authentik-internal + + # ── Authentik Server（Web UI + API）─────────────────────────── + server: + image: ghcr.io/goauthentik/server:2025.6 + container_name: authentik-server + restart: unless-stopped + command: server + depends_on: + postgresql: + condition: service_healthy + redis: + condition: service_healthy + environment: + AUTHENTIK_REDIS__HOST: redis + AUTHENTIK_POSTGRESQL__HOST: postgresql + AUTHENTIK_POSTGRESQL__USER: authentik + AUTHENTIK_POSTGRESQL__NAME: authentik + AUTHENTIK_POSTGRESQL__PASSWORD: ${PG_PASS} + AUTHENTIK_SECRET_KEY: ${AUTHENTIK_SECRET_KEY} + AUTHENTIK_ERROR_REPORTING__ENABLED: ${AUTHENTIK_ERROR_REPORTING__ENABLED:-false} + # 邮件配置（与 .env 联动，未配置时留空即可） + AUTHENTIK_EMAIL__HOST: ${AUTHENTIK_EMAIL__HOST:-localhost} + AUTHENTIK_EMAIL__PORT: ${AUTHENTIK_EMAIL__PORT:-25} + AUTHENTIK_EMAIL__USERNAME: ${AUTHENTIK_EMAIL__USERNAME:-} + AUTHENTIK_EMAIL__PASSWORD: ${AUTHENTIK_EMAIL__PASSWORD:-} + AUTHENTIK_EMAIL__USE_SSL: ${AUTHENTIK_EMAIL__USE_SSL:-false} + AUTHENTIK_EMAIL__FROM: ${AUTHENTIK_EMAIL__FROM:-authentik@localhost} + volumes: + - ./media:/media # 上传文件/品牌Logo等 + - ./custom-templates:/templates # 自定义模板（可选） + - ./certs:/certs # 自定义 TLS 证书（可选） + ports: + - "${COMPOSE_PORT_HTTP:-9000}:9000" + - "${COMPOSE_PORT_HTTPS:-9443}:9443" + networks: + - authentik-internal + + # ── Authentik Worker（后台任务/Outpost 管理）───────────────── + worker: + image: ghcr.io/goauthentik/server:2025.6 + container_name: authentik-worker + restart: unless-stopped + command: worker + depends_on: + postgresql: + condition: service_healthy + redis: + condition: service_healthy + environment: + AUTHENTIK_REDIS__HOST: redis + AUTHENTIK_POSTGRESQL__HOST: postgresql + AUTHENTIK_POSTGRESQL__USER: authentik + AUTHENTIK_POSTGRESQL__NAME: authentik + AUTHENTIK_POSTGRESQL__PASSWORD: ${PG_PASS} + AUTHENTIK_SECRET_KEY: ${AUTHENTIK_SECRET_KEY} + AUTHENTIK_ERROR_REPORTING__ENABLED: ${AUTHENTIK_ERROR_REPORTING__ENABLED:-false} + volumes: + - ./media:/media + - ./custom-templates:/templates + - ./certs:/certs + - ./backups:/backups # 备份输出目录 + - /var/run/docker.sock:/var/run/docker.sock # Outpost 自动部署用 + user: root # 访问 Docker socket 需要 root + networks: + - authentik-internal + +# ── 持久化 Named Volumes ────────────────────────────────────────── +volumes: + authentik_db: + driver: local + authentik_redis: + driver: local + +# ── 隔离网络 ────────────────────────────────────────────────────── +networks: + authentik-internal: + driver: bridge +``` + +*** + +## 启动与初始化 + +```bash +# 拉取镜像 +docker compose pull + +# 后台启动 +docker compose up -d + +# 查看日志（等待 server 健康） +docker compose logs -f server +``` + +浏览器访问 `http://<服务器IP>:9000/if/flow/initial-setup/` 完成管理员密码设置。 [docs.goauthentik](https://docs.goauthentik.io/install-config/install/docker-compose/) + +*** + +## 关键持久化路径说明 + +| 持久化内容 | 存储位置 | 说明 | +|---|---|---| +| 数据库数据 | Named Volume `authentik_db` | 所有用户、应用、策略配置 | +| Redis 状态 | Named Volume `authentik_redis` | Session、任务队列 [github](https://github.com/goauthentik/authentik/issues/3693) | +| 媒体文件 | `./media` 绑定挂载 | 品牌 Logo、用户头像等 | +| 证书 | `./certs` 绑定挂载 | 自定义 TLS/SAML 证书 | +| 备份文件 | `./backups` 绑定挂载 | 数据库备份输出 | + +*** + +## 后续接入 Docmost / GitLab SSO 的协议选择 + +Authentik 支持多种协议，国内自托管场景推荐： + +- **GitLab** → 使用 **OAuth2/OIDC Provider**（GitLab 原生支持，配置最简） +- **Docmost** → 使用 **OIDC Provider**（Docmost 支持标准 OIDC） +- 无 OIDC 支持的旧系统 → 使用 **LDAP Outpost**（Worker 容器自动管理） + +如果 `ghcr.io` 在你的服务器上拉取速度慢，可在 `/etc/docker/daemon.json` 中配置国内镜像加速，或使用 `docker pull` 走代理后 `docker save/load` 离线导入。 \ No newline at end of file diff --git a/37-灾备方案设计/1-灾备方案设计-prompt.md b/37-灾备方案设计/1-灾备方案设计-prompt.md new file mode 100644 index 0000000..8312155 --- /dev/null +++ b/37-灾备方案设计/1-灾备方案设计-prompt.md @@ -0,0 +1,70 @@ +你是一名精通现在k8s集群容灾备份方案的设计专家，你需要面对XXX的容灾备份方案设计。 + +背景介绍 +1. XXX包括飞服平台、监管平台两大实际的运行平台 +2. 飞服平台和监管平台均采用k8s集群的部署方式，两个平台运行环境独立 +3. 飞服平台使用如下的中间件 + 1. EMQX 负责存储无人机、机库传输的数据，理论不需要容灾备份 + 2. MySQL 负责存储平台所有的业务数据 + 3. InfluxDB 负责存储平台的时序数据 + 4. MINIO 负责无人机和机库产生的视频数据 +4. 监管平台使用如下的中间件 + 1. EMQX 负责存储探测、反制设备、无人机、机库传输的数据，理论不需要容灾备份 + 2. MySQL 负责存储平台所有的业务数据 + 3. Doris 负责存储多源融合分析产生的时序数据，负责存储三位空间地图数据 + 4. MINIO 负责保存视觉探测产生的视频和图片数据 +5. 飞服平台和监管平台采用不同的域名访问，如飞服平台域名为：A.com 监管平台域名为：B.com + +容灾备份要求 +1. 以飞服平台为例，飞服平台需要一模一样部署在电信机房，移动机房，通过域名访问飞服平台 +2. 某一机房发生故障后，其他机房应该在两小时内实现业务接管，恢复平台的正常运行 +3. 可以允许两小时的数据丢失 +4. 数据备份过程中，要保证数据不外泄 + + +# 基础方案 +1. 飞服和监管平台采用相同的灾备方案 +2. 每个机房独立部署，不相互依赖 +3. 采用双中心+异地灾备的方案 +4. 数据备份采用定期备份+增量备份的方式，数据同步采用对称加密的方式传输，保证数据安全 + +## 灾备切换流程 +1. 电信机房出现故障，无法恢复，触发灾备切换流程 +2. 域名管理方 将A.com的解析IP指向移动机房的IP +3. 用户通过A.com访问移动机房的飞服平台 +4. 平台故障恢复时间可以控制在10分钟内，但是数据可能丢失2小时 + +## 日常数据容灾备份同步流程 +1. 飞服和监管平台需要备份的数据不同，当数据备份流程相同 +2. 增量备份 + 1. 飞服平台需要备份的数据为 + 1. MySQL --> MySQL 每2时备份一次，每次备份2小时的数据，通过对称加密传输 + 2. MinIO --> MinIO 每2时备份一次，每次备份2小时的数据，通过对称加密传输 + 3. InfluxDB --> InfluxDB 每2时备份一次，每次备份2小时的数据，通过对称加密传输 + 2. 监管平台需要备份的数据为 + 1. MySQL --> MySQL 每2时备份一次，每次备份2小时的数据，通过对称加密传输 + 2. MinIO --> MinIO 每2时备份一次，每次备份2小时的数据，通过对称加密传输 + 3. InfluxDB --> InfluxDB 每2时备份一次，每次备份2小时的数据，通过对称加密传输 + 4. Doris --> Doris 每2时备份一次，每次备份2小时的数据，通过对称加密传输 + 3. 增量备份数据保存3份副本 +3. 全量备份 + 1. 每周日凌晨02:00对所有数据进行全量备份，备份到独立的存储设备上 + 2. 全量备份保存1份副本 +4. 备份及传输安全机制 + 1. 增量备份应该保证业务平台的数据不丢失 + 2. 备份流程应该是自动化运行的，遇到出错的情况，需要人工介入 + 3. 备份数据采用对称加密的方式传输，保证核心数据不外泄 + 4. 备份数据的传输需要经过一致性校验，保证数据的完整性 + 5. 备份数据导入流程应该是自动化运行的，遇到出错的情况，需要人工介入 + + +文档生成要求 +1. 需要图片的地方，请使用文字占位，使用文字详细描述图片的内容 +2. 文档应该专业，不应该口语化 +3. 文档内容应该完备，不要丢失原始设计中的内容 +4. 上述文档比较简洁，但是正式文档中应该将飞服平台和监管平台的有区别的内容分离完善 +5. 应该为后续的具体操作预留章节空白 +6. 灾备文档的一级标题、二级标题、三级标题清晰明了，有逻辑性 + + +不要参考本机其他文件，可以联网搜索，请为我生成一份满足上述要求的灾备方案文档 \ No newline at end of file diff --git a/37-灾备方案设计/2-gemini-生成方案.md b/37-灾备方案设计/2-gemini-生成方案.md new file mode 100644 index 0000000..46bce5b --- /dev/null +++ b/37-灾备方案设计/2-gemini-生成方案.md @@ -0,0 +1,177 @@ +这是一份为您定制的XXX系统容灾备份架构设计与实施方案文档。文档采用了标准的企业级架构设计语言，严格区分了飞服平台与监管平台的差异，并按照要求使用了详细的文字占位来描述架构图表，同时为后续实操步骤预留了标准章节。 + +--- + +# XXX系统容灾备份架构设计与实施方案 + +## 1. 项目背景与总体要求 + +### 1.1 系统概述 + +XXX系统作为核心业务系统，主要由“飞服平台”与“监管平台”两大独立运行的平台构成。为保证业务的高可用性与数据隔离性，两个平台均采用Kubernetes（K8s）集群架构进行独立部署，网络与运行环境互不干扰。 + +* **飞服平台（访问域名：A.com）**：主要负责无人机与机库数据接入、业务数据管理、时序状态记录及视频流存储。 +* **监管平台（访问域名：B.com）**：主要负责探测与反制设备数据接入、多源融合分析数据存储、三维空间地图管理及视觉探测图文存储。 + +### 1.2 容灾备份核心指标 + +本方案旨在构建具备高可用、高抗风险能力的双中心容灾体系，具体目标指标如下： + +* **恢复时间目标（RTO）**：核心业务故障接管与恢复运行时间控制在 **2小时** 以内（其中域名调度及流量切换时间预期控制在 **10分钟** 内）。 +* **恢复点目标（RPO）**：允许的最大数据丢失量控制在 **2小时** 以内。 +* **安全与合规性**：在所有跨机房、跨中心的数据传输与备份过程中，必须采用强加密手段，确保核心业务数据不发生外泄。 + +--- + +## 2. 灾备总体架构设计 + +### 2.1 架构设计原则 + +1. **统一性与独立性并存**：飞服平台与监管平台采用一致的基础灾备技术栈与流程方案，但两个平台在物理与逻辑上均保持独立运作。 +2. **双中心冗余**：采用“双中心+异地灾备”架构，系统在电信机房与移动机房进行完全一致的对等部署，互不构成运行依赖。 +3. **加密与校验优先**：数据同步采用定期加增量模式，全程通过对称加密通道传输，并在落盘前实施严格的一致性校验。 + +### 2.2 总体网络与灾备拓扑 + +> **[图片占位：XXX系统双中心异地灾备总体架构图]** +> *图表详细说明：* +> *1. 顶部为“全局流量管理层（DNS/GSLB）”，分别指向 A.com 和 B.com 两个域名。* +> *2. 中部划分为左右两个对等的大区块，左侧标识为“主生产中心（电信机房）”，右侧标识为“灾备接管中心（移动机房）”。* +> *3. 每个机房内部，再细分为两个独立的K8s集群：“飞服平台K8s集群”与“监管平台K8s集群”。* +> *4. 两个机房之间绘制一条横向的“加密数据同步通道”，使用锁图标表示对称加密状态。主数据流向由电信机房指向移动机房。* +> *5. 底部为一个独立的“异地备份存储中心”，电信机房和移动机房均有虚线指向该中心，表示定期全量备份的数据流向。* + +--- + +## 3. 中间件与数据同步详细策略 + +### 3.1 飞服平台数据同步策略 + +飞服平台核心依赖EMQX、MySQL、InfluxDB及MinIO。其中，EMQX仅作为设备接入的数据管道，其数据具备瞬时性和可重传性，无需纳入容灾备份范围。其余状态化中间件策略如下： + +* **MySQL（平台业务数据）**： +* **同步对象**：全量业务配置、用户信息、任务状态等。 +* **同步链路**：电信机房 MySQL -> 加密通道 -> 移动机房 MySQL。 + + +* **InfluxDB（平台时序数据）**： +* **同步对象**：无人机飞行遥测数据、机库传感器状态等高频时序数据。 +* **同步链路**：电信机房 InfluxDB -> 加密通道 -> 移动机房 InfluxDB。 + + +* **MinIO（非结构化数据）**： +* **同步对象**：无人机与机库产生的视频流切片及录像文件。 +* **同步链路**：电信机房 MinIO -> 加密通道 -> 移动机房 MinIO。 + + + +### 3.2 监管平台数据同步策略 + +监管平台除包含MySQL、MinIO和EMQX（同样不纳入灾备）外，在时序与大数据处理上存在差异，具体策略如下： + +* **MySQL（平台业务数据）**： +* **同步链路**：电信机房 MySQL -> 加密通道 -> 移动机房 MySQL。 + + +* **Doris（融合分析与空间数据）**： +* **同步对象**：多源融合分析产生的多维聚合时序数据、三维空间地图资产。 +* **同步链路**：电信机房 Doris -> 加密通道 -> 移动机房 Doris。 + + +* **InfluxDB（基础时序数据）**： +* **同步链路**：电信机房 InfluxDB -> 加密通道 -> 移动机房 InfluxDB。 + + +* **MinIO（视觉图片数据）**： +* **同步对象**：视觉探测设备产生的海量抓拍图片及告警视频证据。 +* **同步链路**：电信机房 MinIO -> 加密通道 -> 移动机房 MinIO。 + + + +--- + +## 4. 备份机制与安全保障 + +### 4.1 备份周期与副本管理 + +系统采用“高频增量+定期全量”的组合备份机制，保障数据恢复的多版本选择。 + +* **增量备份机制**： +* **执行频率**：每2小时自动触发一次。 +* **数据切片**：每次仅备份过去2小时内产生的新增及变更数据。 +* **副本保留**：增量备份数据在灾备端保存 **3份** 历史副本，以便应对逻辑错误导致的数据污染。 + + +* **全量备份机制**： +* **执行频率**：每周日凌晨 02:00 自动触发。 +* **目标存储**：输出至独立于双中心之外的专用异地存储设备（或专用的长期冷存储集群）。 +* **副本保留**：全量备份保留 **1份** 最新完整副本。 + + + +### 4.2 传输安全与完整性校验 + +* **对称加密传输**：所有跨机房备份数据在打包生成后，立刻采用高强度对称加密算法（如 AES-256）进行加密处理，随后通过专用通道传输至目标机房。 +* **一致性校验**：数据包在接收端解密前及解密后，均需通过哈希校验（如 SHA-256），确保数据在传输过程中未被篡改或发生网络丢包。 +* **防数据丢失承诺**：增量备份机制在底层通过事务日志（如MySQL的Binlog）及对象存储的增量API抓取，确保业务平台在2小时RPO窗口外的数据实现 100% 留存。 + +### 4.3 自动化流水线保障 + +* 数据备份与导入恢复流程完全基于自动化脚本/运维编排工具（如 K8s CronJob 结合自研 Operator）执行，形成无人工干预的闭环。 +* **异常熔断与人工介入**：当自动化流水线监测到加密失败、校验不一致或导入超时等严重异常时，将立即阻断当前流程，发送最高级别告警，转由人工运维团队介入排查。 + +--- + +## 5. 灾备切换与恢复流程 + +### 5.1 故障确认与灾备触发 + +> **[图片占位：灾备切换业务流转时序图]** +> *图表详细说明：* +> *1. 最左侧为“用户终端”，向右发起请求至“域名DNS管理平台”。* +> *2. 当“电信机房（主）”监控节点连续三次探测无响应，触发“故障灾难宣告”事件。* +> *3. 时序图流转至管理员节点，由管理员/自动化系统下发指令至“域名DNS管理平台”，变更解析记录。* +> *4. 数据流向重新由DNS指向“移动机房（备）”。* +> *5. 移动机房K8s集群内部启动业务Pod扩容与流量接管，虚线框标注重生后的业务流。* + +### 5.2 域名解析级流量切换 + +1. **故障确认**：确认电信机房出现网络阻断或核心集群崩溃，且短时间内无法恢复。 +2. **DNS调度**：由域名管理方登录DNS控制台，将飞服平台（A.com）与监管平台（B.com）的 A 记录或 CNAME 重新指向移动机房对应的公网网关 IP。 +3. **时间控制**：凭借低TTL值（Time-To-Live）设置，确保流量调度在 **10分钟内** 全局生效，用户侧感知为短暂的服务不可达后恢复。 + +### 5.3 业务接管与数据恢复验证 + +1. 流量切换后，移动机房的 K8s Ingress 控制器接管 A.com 与 B.com 的所有外部请求。 +2. 系统基于移动机房最近一次（2小时内）导入的备份数据提供服务，最大数据回退时间不超过2小时。 +3. 业务全面接管时效硬性控制在 **2小时** 以内。 + +--- + +## 6. 灾备系统日常运维操作手册（预留） + +*说明：本章节预留用于记录具体的 CLI 脚本、K8s YAML 配置文件路径及中间件灾备配置参数，需由实施工程师在系统部署完成后进行补充。* + +### 6.1 飞服平台 MySQL 增量同步脚本配置 + +（预留空白：待补充脚本代码及自动化部署配置） + +### 6.2 监管平台 Doris 数据双中心同步配置 + +（预留空白：待补充 Doris 跨集群同步参数与网络策略） + +### 6.3 秘钥管理与对称加密更新操作指南 + +（预留空白：待补充 KMS 密钥轮转及凭证替换流程） + +--- + +## 7. 应急响应与演练指南（预留） + +### 7.1 DNS 切换演练标准操作程序（SOP） + +（预留空白：待补充具体的操作截图、审批流程及DNS操作台界面说明） + +### 7.2 备份数据导入失败的人工干预恢复流程 + +（预留空白：待补充各种中间件脏数据清理、手动导库及一致性修复的命令行操作指南） \ No newline at end of file diff --git a/37-灾备方案设计/XXX平台容灾备份方案设计.md b/37-灾备方案设计/XXX平台容灾备份方案设计.md new file mode 100644 index 0000000..b0eff53 --- /dev/null +++ b/37-灾备方案设计/XXX平台容灾备份方案设计.md @@ -0,0 +1,1056 @@ +# XXX平台容灾备份方案设计 + +| 文档属性 | 内容 | +|---------|------| +| 文档名称 | XXX平台容灾备份方案设计 | +| 文档版本 | V1.0 | +| 编制日期 | 2026年7月 | +| 密级 | 机密 | + +--- + +## 修订记录 + +| 版本号 | 修订日期 | 修订内容 | 编制人 | 审核人 | +|--------|---------|---------|--------|--------| +| V1.0 | 2026-07-01 | 初稿编制 | | | + +--- + +## 目 录 + +- [1 概述](#1-概述) + - [1.1 编制目的](#11-编制目的) + - [1.2 适用范围](#12-适用范围) + - [1.3 术语与缩略语](#13-术语与缩略语) + - [1.4 参考文档](#14-参考文档) +- [2 系统现状分析](#2-系统现状分析) + - [2.1 平台概述](#21-平台概述) + - [2.2 飞服平台架构](#22-飞服平台架构) + - [2.3 监管平台架构](#23-监管平台架构) + - [2.4 中间件组件对比](#24-中间件组件对比) +- [3 容灾备份需求分析](#3-容灾备份需求分析) + - [3.1 业务连续性需求](#31-业务连续性需求) + - [3.2 RPO与RTO指标](#32-rpo与rto指标) + - [3.3 数据安全需求](#33-数据安全需求) + - [3.4 备份数据范围](#34-备份数据范围) +- [4 容灾备份总体方案](#4-容灾备份总体方案) + - [4.1 设计原则](#41-设计原则) + - [4.2 容灾架构模型](#42-容灾架构模型) + - [4.3 双中心异地灾备总体架构](#43-双中心异地灾备总体架构) + - [4.4 网络与域名规划](#44-网络与域名规划) +- [5 飞服平台容灾备份方案](#5-飞服平台容灾备份方案) + - [5.1 飞服平台部署架构](#51-飞服平台部署架构) + - [5.2 飞服平台数据备份策略](#52-飞服平台数据备份策略) + - [5.3 飞服平台增量备份方案](#53-飞服平台增量备份方案) + - [5.4 飞服平台全量备份方案](#54-飞服平台全量备份方案) + - [5.5 飞服平台灾备切换流程](#55-飞服平台灾备切换流程) +- [6 监管平台容灾备份方案](#6-监管平台容灾备份方案) + - [6.1 监管平台部署架构](#61-监管平台部署架构) + - [6.2 监管平台数据备份策略](#62-监管平台数据备份策略) + - [6.3 监管平台增量备份方案](#63-监管平台增量备份方案) + - [6.4 监管平台全量备份方案](#64-监管平台全量备份方案) + - [6.5 监管平台灾备切换流程](#65-监管平台灾备切换流程) +- [7 数据备份安全机制](#7-数据备份安全机制) + - [7.1 加密传输方案](#71-加密传输方案) + - [7.2 数据一致性校验](#72-数据一致性校验) + - [7.3 密钥管理](#73-密钥管理) + - [7.4 访问控制与审计](#74-访问控制与审计) +- [8 自动化运维方案](#8-自动化运维方案) + - [8.1 备份自动化调度](#81-备份自动化调度) + - [8.2 数据导入自动化](#82-数据导入自动化) + - [8.3 异常告警与人工介入机制](#83-异常告警与人工介入机制) + - [8.4 监控与日志](#84-监控与日志) +- [9 灾备演练方案](#9-灾备演练方案) + - [9.1 演练目标](#91-演练目标) + - [9.2 演练计划](#92-演练计划) + - [9.3 演练流程](#93-演练流程) + - [9.4 演练评估标准](#94-演练评估标准) +- [10 具体操作手册（待完善）](#10-具体操作手册待完善) + - [10.1 MySQL备份与恢复操作手册](#101-mysql备份与恢复操作手册) + - [10.2 InfluxDB备份与恢复操作手册](#102-influxdb备份与恢复操作手册) + - [10.3 MinIO备份与恢复操作手册](#103-minio备份与恢复操作手册) + - [10.4 Doris备份与恢复操作手册](#104-doris备份与恢复操作手册) + - [10.5 灾备切换操作手册](#105-灾备切换操作手册) + - [10.6 灾备回切操作手册](#106-灾备回切操作手册) +- [附录A 备份任务Cron表达式汇总](#附录a-备份任务cron表达式汇总) +- [附录B 灾备切换检查清单](#附录b-灾备切换检查清单) + +--- + +## 1 概述 + +### 1.1 编制目的 + +本文档旨在为XXX平台（包含飞服平台与监管平台）提供一套完整的、可落地执行的容灾备份方案设计。方案以"双中心+异地灾备"为核心架构，通过定期增量备份与全量备份相结合的数据保护策略，确保在单一机房发生灾难性故障时，业务能够在规定时间内完成接管切换，恢复平台正常运行，最大程度降低数据丢失风险。 + +本文档将作为XXX平台容灾备份体系建设的指导性文件，为后续系统部署、运维操作、灾备演练提供技术依据。 + +### 1.2 适用范围 + +本方案适用于以下系统与组件： + +- **飞服平台**：部署于电信机房（主中心）与移动机房（灾备中心）的全部Kubernetes集群及中间件服务 +- **监管平台**：部署于电信机房（主中心）与移动机房（灾备中心）的全部Kubernetes集群及中间件服务 +- **涉及人员**：系统运维工程师、数据库管理员、网络管理员、安全管理员 + +### 1.3 术语与缩略语 + +| 术语/缩略语 | 全称 | 说明 | +|------------|------|------| +| RPO | Recovery Point Objective | 恢复点目标，指灾难发生后允许丢失的最大数据量，以时间度量 | +| RTO | Recovery Time Objective | 恢复时间目标，指灾难发生后系统恢复服务所需的最长时间 | +| K8s | Kubernetes | 容器编排平台 | +| EMQX | — | 高性能MQTT消息代理服务器 | +| MySQL | — | 关系型数据库管理系统 | +| InfluxDB | — | 开源时序数据库 | +| MinIO | — | 高性能对象存储服务 | +| Doris | Apache Doris | 高性能实时分析数据库 | +| AES | Advanced Encryption Standard | 高级加密标准，对称加密算法 | +| DNS | Domain Name System | 域名解析系统 | +| GSLB | Global Server Load Balancing | 全局服务器负载均衡 | +| CCR | Cross-Cluster Replication | Doris跨集群复制 | + +### 1.4 参考文档 + +| 序号 | 文档名称 | 说明 | +|------|---------|------| +| 1 | 《XXX平台系统架构设计说明书》 | 平台整体架构参考 | +| 2 | 《信息系统灾难恢复规范》（GB/T 20988-2007） | 国家灾难恢复标准 | +| 3 | 《Kubernetes官方文档》 | K8s集群管理参考 | +| 4 | 《Velero官方文档》 | K8s备份恢复工具参考 | +| 5 | 《Apache Doris备份恢复文档》 | Doris数据备份参考 | + +--- + +## 2 系统现状分析 + +### 2.1 平台概述 + +XXX包含两大独立运行的业务平台： + +- **飞服平台**：面向无人机飞行服务场景，提供无人机、机库的数据接入、业务管理、视频存储与时序数据分析等核心功能。通过域名 `A.com` 对外提供访问。 +- **监管平台**：面向低空空域监管场景，提供探测设备、反制设备、无人机、机库的数据接入，以及多源融合分析、三维空间地图、视觉探测等核心功能。通过域名 `B.com` 对外提供访问。 + +两平台均采用Kubernetes集群部署方式，运行环境相互独立，互不依赖。 + +### 2.2 飞服平台架构 + +飞服平台的技术架构及中间件组件如下： + +| 组件 | 功能职责 | 容灾备份需求 | +|------|---------|-------------| +| EMQX | 负责接收和转发无人机、机库传输的实时数据（MQTT协议） | **无需容灾备份**。EMQX作为消息代理，数据为实时流转性质，不持久化存储业务状态 | +| MySQL | 负责存储平台所有结构化业务数据，包括用户信息、飞行计划、设备管理、权限配置等 | **需要容灾备份**。作为核心业务数据库，数据丢失将直接影响平台业务运行 | +| InfluxDB | 负责存储平台时序数据，包括无人机飞行轨迹、传感器采集数据、设备状态监控指标等 | **需要容灾备份**。时序数据是飞行记录与运营分析的重要依据 | +| MinIO | 负责存储无人机和机库产生的视频文件、图片资源等非结构化数据 | **需要容灾备份**。视频数据为飞行任务执行的重要凭证 | + +**【图示说明：飞服平台技术架构图】** + +> 图片内容描述：一张分层架构图。最上层为"用户访问层"，标注域名A.com，通过Ingress Controller接入。中间层为"Kubernetes集群"，内部包含多个Pod，分别部署飞服平台的微服务应用（如飞行管理服务、设备管理服务、用户服务等）。底层为"中间件层"，从左到右依次排列四个组件框：EMQX（标注灰色，注明"无需备份"）、MySQL（标注绿色，注明"需要备份"）、InfluxDB（标注绿色，注明"需要备份"）、MinIO（标注绿色，注明"需要备份"）。各微服务与中间件之间以箭头连线表示数据流向。左侧有一条虚线箭头从外部设备图标（无人机、机库）指向EMQX，标注"MQTT数据上报"。 + +### 2.3 监管平台架构 + +监管平台的技术架构及中间件组件如下： + +| 组件 | 功能职责 | 容灾备份需求 | +|------|---------|-------------| +| EMQX | 负责接收和转发探测设备、反制设备、无人机、机库传输的实时数据（MQTT协议） | **无需容灾备份**。EMQX作为消息代理，数据为实时流转性质，不持久化存储业务状态 | +| MySQL | 负责存储平台所有结构化业务数据，包括探测目标信息、反制任务记录、设备管理、权限配置等 | **需要容灾备份**。作为核心业务数据库，数据丢失将直接影响平台业务运行 | +| Doris | 负责存储多源融合分析产生的时序数据及三维空间地图数据，承担大规模数据分析查询任务 | **需要容灾备份**。融合分析数据和空间地图数据是监管业务的核心数据资产 | +| MinIO | 负责存储视觉探测产生的视频文件和图片数据 | **需要容灾备份**。视觉探测数据为监管取证的重要依据 | + +**【图示说明：监管平台技术架构图】** + +> 图片内容描述：一张分层架构图。最上层为"用户访问层"，标注域名B.com，通过Ingress Controller接入。中间层为"Kubernetes集群"，内部包含多个Pod，分别部署监管平台的微服务应用（如探测管理服务、反制管理服务、多源融合分析服务、三维空间地图服务等）。底层为"中间件层"，从左到右依次排列四个组件框：EMQX（标注灰色，注明"无需备份"）、MySQL（标注绿色，注明"需要备份"）、Doris（标注绿色，注明"需要备份"）、MinIO（标注绿色，注明"需要备份"）。各微服务与中间件之间以箭头连线表示数据流向。左侧有一条虚线箭头从外部设备图标（探测设备、反制设备、无人机、机库）指向EMQX，标注"MQTT数据上报"。 + +### 2.4 中间件组件对比 + +| 对比维度 | 飞服平台 | 监管平台 | +|---------|---------|---------| +| 消息中间件 | EMQX（无需备份） | EMQX（无需备份） | +| 关系型数据库 | MySQL | MySQL | +| 时序/分析数据库 | InfluxDB | Doris（Apache Doris） | +| 对象存储 | MinIO | MinIO | +| 数据来源 | 无人机、机库 | 探测设备、反制设备、无人机、机库 | +| 访问域名 | A.com | B.com | +| 部署环境 | 独立K8s集群 | 独立K8s集群 | + +> **说明**：飞服平台与监管平台的核心差异在于时序/分析数据库的选型不同——飞服平台使用InfluxDB，监管平台使用Apache Doris。这一差异导致两个平台在数据备份的具体实施策略上存在区别，但整体灾备架构和流程保持一致。 + +--- + +## 3 容灾备份需求分析 + +### 3.1 业务连续性需求 + +根据XXX平台的业务特性和运营要求，容灾备份方案须满足以下业务连续性需求： + +1. **多机房冗余部署**：飞服平台与监管平台须在电信机房和移动机房分别完成一模一样的完整部署，两个机房的部署环境相互独立，互不依赖。 +2. **快速业务接管**：当任一机房发生灾难性故障且无法短时恢复时，另一机房应在 **2小时以内** 完成业务接管，恢复平台对外服务。 +3. **域名透明切换**：灾备切换通过DNS域名解析实现，终端用户无需更改访问地址即可无感知切换至灾备机房。 +4. **独立运行能力**：灾备机房应具备独立承载全部业务的能力，无需依赖故障机房的任何资源。 + +### 3.2 RPO与RTO指标 + +| 指标 | 目标值 | 说明 | +|------|-------|------| +| **RTO（恢复时间目标）** | ≤ 2小时 | 从故障确认到灾备机房完成业务接管的总时间。其中DNS切换后的域名生效时间预计在10分钟以内，剩余时间用于数据验证和服务确认 | +| **RPO（恢复点目标）** | ≤ 2小时 | 允许丢失的最大数据时间窗口为2小时。增量备份周期设置为每2小时执行一次，确保RPO不超过2小时 | + +### 3.3 数据安全需求 + +1. **传输加密**：所有跨机房的数据备份传输必须采用对称加密方式（AES-256），确保数据在传输过程中不被窃取或篡改，保证核心业务数据不外泄。 +2. **完整性校验**：备份数据在传输完成后须进行一致性校验（SHA-256哈希校验），确保传输过程中数据未发生损坏或丢失。 +3. **访问控制**：备份数据的存储和传输通道须实施严格的访问控制，仅授权运维人员可操作。 +4. **审计追踪**：所有备份和恢复操作须记录完整日志，支持事后审计。 + +### 3.4 备份数据范围 + +#### 3.4.1 飞服平台备份数据范围 + +| 数据源 | 数据类型 | 备份目标 | 备份必要性 | +|--------|---------|---------|-----------| +| MySQL | 结构化业务数据（用户、飞行计划、设备管理等） | MySQL（灾备中心） | 必须 | +| InfluxDB | 时序数据（飞行轨迹、传感器数据、设备状态等） | InfluxDB（灾备中心） | 必须 | +| MinIO | 非结构化数据（视频文件、图片资源等） | MinIO（灾备中心） | 必须 | +| EMQX | 实时消息数据 | — | 不需要 | + +#### 3.4.2 监管平台备份数据范围 + +| 数据源 | 数据类型 | 备份目标 | 备份必要性 | +|--------|---------|---------|-----------| +| MySQL | 结构化业务数据（探测目标、反制任务、设备管理等） | MySQL（灾备中心） | 必须 | +| Doris | 多源融合分析时序数据、三维空间地图数据 | Doris（灾备中心） | 必须 | +| MinIO | 非结构化数据（视觉探测视频、图片数据等） | MinIO（灾备中心） | 必须 | +| EMQX | 实时消息数据 | — | 不需要 | + +--- + +## 4 容灾备份总体方案 + +### 4.1 设计原则 + +本容灾备份方案遵循以下设计原则： + +| 原则 | 说明 | +|------|------| +| **独立性原则** | 每个机房独立部署完整的平台环境，包括K8s集群和全部中间件，机房之间不存在运行时依赖关系 | +| **一致性原则** | 飞服平台与监管平台采用相同的灾备架构和流程框架，仅在具体中间件备份策略上因组件差异而有所区别 | +| **自动化原则** | 数据备份、加密传输、一致性校验、数据导入等流程均应实现自动化运行，减少人工操作风险 | +| **安全性原则** | 数据传输全程采用对称加密保护，密钥独立管理，确保备份数据不外泄 | +| **可恢复性原则** | 增量备份保存3份副本，全量备份保存1份副本，确保在多种故障场景下均可恢复数据 | +| **可演练原则** | 灾备方案应具备定期演练能力，验证切换流程和RTO/RPO指标是否达标 | + +### 4.2 容灾架构模型 + +本方案采用 **"双中心 + 异地灾备"** 架构模型： + +- **主中心（电信机房）**：承载日常业务运行，作为业务流量的主要入口。 +- **灾备中心（移动机房）**：部署与主中心一模一样的完整环境，日常处于热备状态，定期接收主中心的增量备份数据。当主中心发生故障时，灾备中心快速接管业务。 + +该架构模型的核心特点： + +1. **主备模式**：日常业务仅在主中心运行，灾备中心接收数据备份并保持就绪状态。 +2. **数据单向同步**：数据从主中心向灾备中心单向同步，避免双向同步带来的数据冲突问题。 +3. **域名级切换**：通过DNS域名解析切换实现流量转移，切换过程对用户透明。 + +**【图示说明：双中心异地灾备架构总览图】** + +> 图片内容描述：一张横向布局的架构图，左右两侧分别表示"电信机房（主中心）"和"移动机房（灾备中心）"，两侧结构完全对称。 +> +> 左侧"电信机房"内部包含：一个K8s集群框（内含多个微服务Pod），集群下方排列中间件组件（MySQL、InfluxDB/Doris、MinIO、EMQX）。上方有一个"DNS解析"框，标注A.com / B.com指向电信机房IP。 +> +> 右侧"移动机房"内部包含：与电信机房完全一致的K8s集群和中间件部署。上方同样有"DNS解析"框，标注灾备切换时A.com / B.com指向移动机房IP。 +> +> 两个机房之间通过一条粗箭头连接，箭头从左指向右，标注"加密增量备份数据同步（每2小时）"。箭头上方有一个锁形图标，标注"AES-256对称加密"。箭头下方有一条虚线箭头，标注"全量备份数据同步（每周日02:00）"。 +> +> 图的最上方居中位置有一个"用户"图标，通过域名A.com / B.com访问平台，虚线分别指向两个机房，其中指向电信机房的线为实线（日常访问），指向移动机房的线为虚线（灾备切换后访问）。 + +### 4.3 双中心异地灾备总体架构 + +#### 4.3.1 主中心（电信机房） + +主中心承担以下职责： + +- 运行飞服平台和监管平台的全部业务服务 +- 接收并处理全部业务流量 +- 作为数据备份的源端，定期生成增量备份和全量备份数据 +- 将加密后的备份数据传输至灾备中心 + +#### 4.3.2 灾备中心（移动机房） + +灾备中心承担以下职责： + +- 部署与主中心完全一致的K8s集群和中间件环境 +- 接收主中心传输的加密备份数据，执行解密和数据导入 +- 日常保持服务就绪状态（应用已部署、中间件已运行，但不对外提供服务） +- 在主中心故障时，通过DNS切换接管全部业务流量 + +#### 4.3.3 K8s集群配置同步 + +为确保两个机房的K8s集群部署配置保持一致，建议采用以下策略： + +- **GitOps管理**：所有K8s资源配置（Deployment、Service、ConfigMap、Secret等）纳入Git仓库统一版本管理，两个机房通过相同的Git仓库同步部署配置。 +- **Velero集群备份**：使用Velero工具定期备份K8s集群资源对象和配置信息，备份文件存储至异地MinIO对象存储，用于灾备恢复时快速重建集群状态。 +- **镜像仓库同步**：两个机房均部署独立的容器镜像仓库，通过镜像同步机制保持镜像版本一致。 + +### 4.4 网络与域名规划 + +#### 4.4.1 域名规划 + +| 平台 | 域名 | 日常解析目标 | 灾备切换后解析目标 | +|------|------|------------|------------------| +| 飞服平台 | A.com | 电信机房公网IP | 移动机房公网IP | +| 监管平台 | B.com | 电信机房公网IP | 移动机房公网IP | + +#### 4.4.2 域名切换策略 + +- **DNS TTL设置**：将A.com和B.com的DNS记录TTL值设置为较短周期（建议60秒~300秒），以缩短灾备切换时DNS缓存失效的等待时间。 +- **切换方式**：通过域名管理方修改DNS A记录的解析IP地址，将域名从电信机房IP切换至移动机房IP。 +- **预期生效时间**：DNS切换操作后，由于TTL设置较短，预计全网生效时间在 **10分钟以内**。 + +#### 4.4.3 网络通道 + +- 两个机房之间建立专线或VPN加密隧道，用于备份数据的安全传输。 +- 传输通道须满足备份数据带宽需求，确保增量备份数据能够在备份周期内完成传输。 + +--- + +## 5 飞服平台容灾备份方案 + +### 5.1 飞服平台部署架构 + +飞服平台在电信机房（主中心）和移动机房（灾备中心）采用完全一致的部署架构： + +| 部署层级 | 组件 | 部署方式 | 说明 | +|---------|------|---------|------| +| 接入层 | Ingress Controller | K8s Ingress | 反向代理、SSL终止、路由转发 | +| 应用层 | 飞服平台微服务 | K8s Deployment | 无状态应用，支持水平扩展 | +| 消息层 | EMQX | K8s StatefulSet / 独立部署 | MQTT消息代理，无需备份 | +| 数据层-关系型 | MySQL | K8s StatefulSet / 独立部署 | 核心业务数据存储 | +| 数据层-时序 | InfluxDB | K8s StatefulSet / 独立部署 | 时序数据存储 | +| 数据层-对象 | MinIO | K8s StatefulSet / 独立部署 | 非结构化文件存储 | + +**【图示说明：飞服平台双中心部署示意图】** + +> 图片内容描述：一张左右对称的部署示意图。左侧标注"电信机房（主中心）"，右侧标注"移动机房（灾备中心）"。 +> +> 左侧电信机房内部自上而下排列：用户通过A.com域名访问 → Ingress Controller → 飞服平台微服务集群（多个Pod） → 中间件层（EMQX、MySQL、InfluxDB、MinIO并排排列）。外部设备（无人机、机库）通过MQTT连接至EMQX。 +> +> 右侧移动机房的结构与左侧完全一致，但标注"灾备就绪，日常不对外服务"。 +> +> 两个机房的中间件之间以三条虚线箭头连接（从左指向右），分别标注：MySQL增量同步、InfluxDB增量同步、MinIO增量同步，每条箭头上均有一个锁图标表示加密传输。EMQX之间无连接线。 + +### 5.2 飞服平台数据备份策略 + +飞服平台的数据备份采用 **"增量备份 + 全量备份"** 相结合的策略： + +| 备份类型 | 执行周期 | 备份内容 | 副本数量 | 保留策略 | +|---------|---------|---------|---------|---------| +| 增量备份 | 每2小时 | 最近2小时的变更数据 | 3份 | 滚动保留最近72小时（36份） | +| 全量备份 | 每周日凌晨02:00 | 全部数据的完整快照 | 1份 | 保留最近4周（4份） | + +备份数据流向： + +``` +电信机房 MySQL ──加密传输──→ 移动机房 MySQL +电信机房 InfluxDB ──加密传输──→ 移动机房 InfluxDB +电信机房 MinIO ──加密传输──→ 移动机房 MinIO +``` + +### 5.3 飞服平台增量备份方案 + +#### 5.3.1 MySQL增量备份 + +| 配置项 | 参数值 | +|--------|-------| +| 备份工具 | Percona XtraBackup / mysqldump（逻辑备份） | +| 备份周期 | 每2小时执行一次 | +| 备份范围 | 最近2小时内发生变更的数据 | +| 备份方式 | 基于Binlog的增量备份 | +| 加密算法 | AES-256-CBC对称加密 | +| 传输方式 | 通过加密通道传输至灾备中心 | +| 一致性校验 | SHA-256哈希校验 | +| 副本数量 | 3份 | + +**备份流程**： + +1. 在主中心MySQL实例上执行增量备份，导出最近2小时的Binlog变更数据。 +2. 对备份文件执行AES-256-CBC对称加密处理。 +3. 生成加密后文件的SHA-256哈希校验值。 +4. 将加密备份文件和校验文件通过加密通道传输至灾备中心。 +5. 灾备中心接收文件后，执行SHA-256校验，确认数据完整性。 +6. 校验通过后，解密备份文件并导入至灾备中心MySQL实例。 +7. 将备份文件保存3份副本（本地备份存储、灾备中心存储、独立备份存储设备）。 + +#### 5.3.2 InfluxDB增量备份 + +| 配置项 | 参数值 | +|--------|-------| +| 备份工具 | influxd backup / influx_inspect export | +| 备份周期 | 每2小时执行一次 | +| 备份范围 | 最近2小时内写入的时序数据 | +| 备份方式 | 基于时间范围的数据导出（按时间切片模拟增量备份） | +| 加密算法 | AES-256-CBC对称加密 | +| 传输方式 | 通过加密通道传输至灾备中心 | +| 一致性校验 | SHA-256哈希校验 | +| 副本数量 | 3份 | + +**备份流程**： + +1. 在主中心InfluxDB实例上，按时间范围（最近2小时）导出时序数据。 +2. 对导出文件执行AES-256-CBC对称加密处理。 +3. 生成加密后文件的SHA-256哈希校验值。 +4. 将加密备份文件和校验文件通过加密通道传输至灾备中心。 +5. 灾备中心接收文件后，执行SHA-256校验，确认数据完整性。 +6. 校验通过后，解密备份文件并导入至灾备中心InfluxDB实例。 +7. 将备份文件保存3份副本。 + +#### 5.3.3 MinIO增量备份 + +| 配置项 | 参数值 | +|--------|-------| +| 备份工具 | MinIO Client（mc）/ MinIO Bucket Replication | +| 备份周期 | 每2小时执行一次 | +| 备份范围 | 最近2小时内新增或修改的对象文件 | +| 备份方式 | 基于修改时间的增量同步 | +| 加密算法 | AES-256-CBC对称加密 | +| 传输方式 | 通过加密通道传输至灾备中心（支持TLS加密传输） | +| 一致性校验 | MD5/SHA-256哈希校验 | +| 副本数量 | 3份 | + +**备份流程**： + +1. 使用MinIO Client（mc mirror命令）扫描主中心MinIO存储桶，识别最近2小时内新增或修改的对象文件。 +2. 对待传输的对象文件执行AES-256-CBC对称加密处理。 +3. 生成加密后文件的哈希校验值。 +4. 将加密文件通过加密通道（TLS）传输至灾备中心MinIO实例。 +5. 灾备中心接收文件后，执行哈希校验，确认数据完整性。 +6. 校验通过后，解密文件并存入灾备中心MinIO对应的存储桶。 +7. 将备份文件保存3份副本。 + +> **替代方案说明**：若两个机房的MinIO实例之间网络条件良好，可考虑启用MinIO原生的 **Bucket Replication（桶复制）** 功能替代定时增量备份。Bucket Replication支持近实时的对象级自动同步，可显著降低RPO，但需确保传输通道已开启TLS加密。 + +### 5.4 飞服平台全量备份方案 + +| 配置项 | 参数值 | +|--------|-------| +| 执行时间 | 每周日凌晨02:00 | +| 备份范围 | MySQL全量数据 + InfluxDB全量数据 + MinIO全量数据 | +| 存储位置 | 独立备份存储设备（与业务存储物理隔离） | +| 副本数量 | 1份 | +| 保留策略 | 保留最近4个全量备份版本（约1个月） | + +**全量备份流程**： + +1. **MySQL全量备份**：使用Percona XtraBackup或mysqldump执行全库全量备份，生成完整的数据备份文件。 +2. **InfluxDB全量备份**：使用influxd backup命令执行全量数据备份，生成完整的时序数据备份文件。 +3. **MinIO全量备份**：使用mc mirror命令执行全量对象同步，将所有存储桶的全部对象复制至备份存储设备。 +4. **加密处理**：对全部备份文件执行AES-256-CBC对称加密。 +5. **完整性校验**：生成所有加密备份文件的SHA-256校验清单。 +6. **存储归档**：将加密备份文件和校验清单存储至独立备份存储设备。 + +### 5.5 飞服平台灾备切换流程 + +当电信机房发生灾难性故障，且判断无法在短时间内恢复时，启动飞服平台灾备切换流程。 + +#### 5.5.1 切换触发条件 + +- 电信机房出现不可恢复的硬件故障、网络中断或自然灾害 +- 经评估判断，故障无法在2小时内恢复 +- 由应急指挥团队下达灾备切换指令 + +#### 5.5.2 切换操作步骤 + +| 步骤 | 操作内容 | 责任人 | 预估耗时 | +|------|---------|--------|---------| +| 1 | 确认电信机房故障情况，评估是否启动灾备切换 | 应急指挥团队 | 10~30分钟 | +| 2 | 确认灾备中心（移动机房）飞服平台各服务运行状态 | 运维工程师 | 5~10分钟 | +| 3 | 确认灾备中心最近一次增量备份数据已成功导入 | 数据库管理员 | 5~10分钟 | +| 4 | 执行灾备中心数据一致性验证（抽检核心业务表数据） | 数据库管理员 | 10~15分钟 | +| 5 | 启动灾备中心飞服平台全部微服务（如处于待机状态） | 运维工程师 | 5~10分钟 | +| 6 | 域名管理方将A.com的DNS A记录解析IP修改为移动机房公网IP | 网络管理员 | 5~10分钟 | +| 7 | 等待DNS缓存失效，确认A.com解析已指向移动机房IP | 网络管理员 | 5~10分钟 | +| 8 | 执行业务功能验证（登录、核心功能操作验证） | 测试工程师 | 10~15分钟 | +| 9 | 确认灾备切换完成，发布切换成功通知 | 应急指挥团队 | 5分钟 | + +**预计总切换时间**：60~120分钟，满足RTO ≤ 2小时的目标要求。 + +#### 5.5.3 切换后数据评估 + +灾备切换完成后，需评估数据丢失情况： + +- 确认灾备中心最后一次成功导入的增量备份时间点 +- 计算从该时间点到故障发生时间的数据丢失窗口（预计 ≤ 2小时） +- 记录数据丢失范围报告，用于后续数据补录或业务处理 + +**【图示说明：飞服平台灾备切换流程图】** + +> 图片内容描述：一张自上而下的流程图，描述灾备切换的完整流程。 +> +> 起始节点："电信机房故障发生"。 +> 判断节点1："故障是否可在2小时内恢复？" → 是："执行机房故障恢复流程"（流程结束）。→ 否：进入下一步。 +> 操作节点1："应急指挥团队下达灾备切换指令"。 +> 操作节点2："确认灾备中心服务运行状态"。 +> 操作节点3："确认最新增量备份数据已导入"。 +> 操作节点4："执行数据一致性验证"。 +> 判断节点2："验证是否通过？" → 否："人工介入处理"。→ 是：继续。 +> 操作节点5："启动灾备中心全部微服务"。 +> 操作节点6："DNS管理方修改A.com解析至移动机房IP"。 +> 操作节点7："等待DNS生效，验证域名解析"。 +> 操作节点8："执行业务功能验证"。 +> 结束节点："灾备切换完成，发布通知"。 + +--- + +## 6 监管平台容灾备份方案 + +### 6.1 监管平台部署架构 + +监管平台在电信机房（主中心）和移动机房（灾备中心）采用完全一致的部署架构： + +| 部署层级 | 组件 | 部署方式 | 说明 | +|---------|------|---------|------| +| 接入层 | Ingress Controller | K8s Ingress | 反向代理、SSL终止、路由转发 | +| 应用层 | 监管平台微服务 | K8s Deployment | 无状态应用，支持水平扩展 | +| 消息层 | EMQX | K8s StatefulSet / 独立部署 | MQTT消息代理，无需备份 | +| 数据层-关系型 | MySQL | K8s StatefulSet / 独立部署 | 核心业务数据存储 | +| 数据层-分析 | Apache Doris | 独立部署（FE + BE节点） | 多源融合分析与三维空间地图数据存储 | +| 数据层-对象 | MinIO | K8s StatefulSet / 独立部署 | 非结构化文件存储 | + +> **与飞服平台的差异说明**：监管平台使用Apache Doris替代InfluxDB作为时序/分析数据库，Doris除存储时序数据外，还承担多源融合分析和三维空间地图数据的存储与查询任务。Doris的备份策略与InfluxDB存在显著差异，需采用Doris原生的Backup & Restore机制或CCR跨集群复制方案。 + +**【图示说明：监管平台双中心部署示意图】** + +> 图片内容描述：一张左右对称的部署示意图。左侧标注"电信机房（主中心）"，右侧标注"移动机房（灾备中心）"。 +> +> 左侧电信机房内部自上而下排列：用户通过B.com域名访问 → Ingress Controller → 监管平台微服务集群（多个Pod，包括探测管理、反制管理、多源融合分析、三维空间地图等服务） → 中间件层（EMQX、MySQL、Apache Doris集群【含FE和BE节点】、MinIO并排排列）。外部设备（探测设备、反制设备、无人机、机库）通过MQTT连接至EMQX。 +> +> 右侧移动机房的结构与左侧完全一致，标注"灾备就绪，日常不对外服务"。 +> +> 两个机房的中间件之间以三条虚线箭头连接（从左指向右），分别标注：MySQL增量同步、Doris增量同步、MinIO增量同步，每条箭头上均有一个锁图标表示加密传输。EMQX之间无连接线。 + +### 6.2 监管平台数据备份策略 + +监管平台的数据备份采用 **"增量备份 + 全量备份"** 相结合的策略： + +| 备份类型 | 执行周期 | 备份内容 | 副本数量 | 保留策略 | +|---------|---------|---------|---------|---------| +| 增量备份 | 每2小时 | 最近2小时的变更数据 | 3份 | 滚动保留最近72小时（36份） | +| 全量备份 | 每周日凌晨02:00 | 全部数据的完整快照 | 1份 | 保留最近4周（4份） | + +备份数据流向： + +``` +电信机房 MySQL ──加密传输──→ 移动机房 MySQL +电信机房 Doris ──加密传输──→ 移动机房 Doris +电信机房 MinIO ──加密传输──→ 移动机房 MinIO +``` + +### 6.3 监管平台增量备份方案 + +#### 6.3.1 MySQL增量备份 + +监管平台MySQL增量备份方案与飞服平台完全一致，具体参见 [5.3.1 MySQL增量备份](#531-mysql增量备份)。 + +备份内容包括：探测目标信息、反制任务记录、设备管理数据、用户权限配置等所有结构化业务数据。 + +#### 6.3.2 Doris增量备份 + +| 配置项 | 参数值 | +|--------|-------| +| 备份工具 | Apache Doris原生Backup & Restore / CCR（Cross-Cluster Replication） | +| 备份周期 | 每2小时执行一次 | +| 备份范围 | 最近2小时内写入或变更的分析数据、三维空间地图数据 | +| 备份方式 | 方案A：基于分区的Snapshot备份；方案B：基于Binlog的CCR增量同步 | +| 加密算法 | AES-256-CBC对称加密 | +| 传输方式 | 通过加密通道传输至灾备中心 | +| 一致性校验 | SHA-256哈希校验 | +| 副本数量 | 3份 | + +**方案A：基于Snapshot的分区备份流程**： + +1. 在主中心Doris集群中，创建指向灾备中心对象存储（如MinIO）的Repository。 +2. 每2小时对新增或变更的数据分区执行BACKUP命令，生成快照文件。 +3. 快照文件通过加密通道传输至灾备中心的Repository存储。 +4. 灾备中心Doris集群执行RESTORE命令，从Repository中恢复最新的分区快照数据。 +5. 生成SHA-256校验值并执行一致性验证。 + +**方案B：基于CCR的增量同步流程（推荐）**： + +1. 在主中心和灾备中心的Doris集群上分别部署CCR Syncer服务。 +2. 配置主中心FE和BE节点开启Binlog参数。 +3. 通过CCR Syncer建立数据库级别或表级别的跨集群复制链路。 +4. CCR基于Binlog机制自动同步DDL和DML变更，实现近实时增量同步。 +5. 定期执行数据一致性抽检，确保主备数据一致。 + +> **方案选择建议**：若Doris版本支持CCR功能（Apache Doris 2.0+），优先推荐方案B（CCR跨集群复制），其同步延迟更低（秒级至分钟级），可显著优于2小时的RPO目标。若Doris版本不支持CCR，则采用方案A（分区Snapshot备份）。 + +#### 6.3.3 MinIO增量备份 + +监管平台MinIO增量备份方案与飞服平台完全一致，具体参见 [5.3.3 MinIO增量备份](#533-minio增量备份)。 + +备份内容包括：视觉探测产生的视频文件、图片数据等非结构化数据。 + +### 6.4 监管平台全量备份方案 + +| 配置项 | 参数值 | +|--------|-------| +| 执行时间 | 每周日凌晨02:00 | +| 备份范围 | MySQL全量数据 + Doris全量数据 + MinIO全量数据 | +| 存储位置 | 独立备份存储设备（与业务存储物理隔离） | +| 副本数量 | 1份 | +| 保留策略 | 保留最近4个全量备份版本（约1个月） | + +**全量备份流程**： + +1. **MySQL全量备份**：使用Percona XtraBackup或mysqldump执行全库全量备份，生成完整的数据备份文件。 +2. **Doris全量备份**：使用Doris原生BACKUP命令对全部数据库执行全量快照备份，快照存储至远程Repository。 +3. **MinIO全量备份**：使用mc mirror命令执行全量对象同步，将所有存储桶的全部对象复制至备份存储设备。 +4. **加密处理**：对全部备份文件执行AES-256-CBC对称加密。 +5. **完整性校验**：生成所有加密备份文件的SHA-256校验清单。 +6. **存储归档**：将加密备份文件和校验清单存储至独立备份存储设备。 + +### 6.5 监管平台灾备切换流程 + +当电信机房发生灾难性故障时，监管平台的灾备切换流程与飞服平台一致，仅在域名和数据验证环节存在差异。 + +#### 6.5.1 切换触发条件 + +- 与飞服平台相同（参见 [5.5.1 切换触发条件](#551-切换触发条件)） + +#### 6.5.2 切换操作步骤 + +| 步骤 | 操作内容 | 责任人 | 预估耗时 | +|------|---------|--------|---------| +| 1 | 确认电信机房故障情况，评估是否启动灾备切换 | 应急指挥团队 | 10~30分钟 | +| 2 | 确认灾备中心（移动机房）监管平台各服务运行状态 | 运维工程师 | 5~10分钟 | +| 3 | 确认灾备中心MySQL最近一次增量备份数据已成功导入 | 数据库管理员 | 5~10分钟 | +| 4 | 确认灾备中心Doris数据同步状态（CCR同步延迟/最新Snapshot时间） | 数据库管理员 | 5~10分钟 | +| 5 | 确认灾备中心MinIO最近一次增量备份数据已成功同步 | 运维工程师 | 5~10分钟 | +| 6 | 执行灾备中心数据一致性验证（抽检MySQL核心业务表、Doris分析数据、MinIO对象文件） | 数据库管理员 | 10~15分钟 | +| 7 | 启动灾备中心监管平台全部微服务（如处于待机状态） | 运维工程师 | 5~10分钟 | +| 8 | 域名管理方将B.com的DNS A记录解析IP修改为移动机房公网IP | 网络管理员 | 5~10分钟 | +| 9 | 等待DNS缓存失效，确认B.com解析已指向移动机房IP | 网络管理员 | 5~10分钟 | +| 10 | 执行业务功能验证（登录、探测/反制功能、三维地图、多源融合分析等核心功能验证） | 测试工程师 | 10~15分钟 | +| 11 | 确认灾备切换完成，发布切换成功通知 | 应急指挥团队 | 5分钟 | + +**预计总切换时间**：70~135分钟，满足RTO ≤ 2小时的目标要求。 + +#### 6.5.3 切换后数据评估 + +与飞服平台一致，灾备切换完成后需评估数据丢失情况（参见 [5.5.3 切换后数据评估](#553-切换后数据评估)）。特别注意： + +- 如采用Doris CCR方案，需额外确认CCR同步的最后成功偏移量，评估Doris数据的丢失范围。 +- 如采用Doris Snapshot方案，需确认最后一次成功Snapshot的时间点。 + +**【图示说明：监管平台灾备切换流程图】** + +> 图片内容描述：一张自上而下的流程图，与飞服平台灾备切换流程图结构类似，但增加了以下差异节点： +> +> 在"确认最新增量备份数据已导入"步骤中，拆分为三个并行确认操作：①确认MySQL备份导入状态、②确认Doris同步状态（CCR延迟/Snapshot时间）、③确认MinIO备份同步状态。三个并行操作完成后汇聚至"执行数据一致性验证"节点。 +> +> DNS修改步骤中标注域名为B.com。业务功能验证步骤中标注"验证探测/反制功能、三维地图、多源融合分析"。其余流程与飞服平台一致。 + +--- + +## 7 数据备份安全机制 + +### 7.1 加密传输方案 + +#### 7.1.1 加密算法选型 + +| 配置项 | 参数值 | +|--------|-------| +| 加密算法 | AES-256-CBC（高级加密标准，256位密钥，CBC模式） | +| 加密类型 | 对称加密 | +| 加密工具 | OpenSSL | +| 适用范围 | 全部跨机房传输的备份数据（MySQL、InfluxDB、Doris、MinIO备份文件） | + +#### 7.1.2 加密流程 + +``` +备份源文件 → AES-256-CBC加密 → 生成加密文件(.enc) → 加密传输 → 接收端解密 → 恢复数据 +``` + +**加密操作示例**： + +```bash +# 加密 +openssl enc -aes-256-cbc -salt -pbkdf2 \ + -in backup_data.sql \ + -out backup_data.sql.enc \ + -pass file:/path/to/keyfile + +# 解密 +openssl enc -aes-256-cbc -d -pbkdf2 \ + -in backup_data.sql.enc \ + -out backup_data.sql \ + -pass file:/path/to/keyfile +``` + +#### 7.1.3 传输通道安全 + +- **机房间网络通道**：通过专线或VPN建立加密隧道，确保传输链路安全。 +- **MinIO传输**：启用TLS/SSL证书加密，确保MinIO Client与MinIO Server之间的数据传输安全。 +- **端口控制**：仅开放备份数据传输所需的特定端口，关闭所有非必要端口。 + +### 7.2 数据一致性校验 + +#### 7.2.1 校验机制 + +| 校验阶段 | 校验方式 | 说明 | +|---------|---------|------| +| 备份文件加密后 | 生成SHA-256哈希值 | 在源端生成加密文件的校验值 | +| 传输完成后 | SHA-256哈希对比 | 在目标端重新计算哈希值，与源端校验值对比 | +| 数据导入后 | 业务数据抽检 | 对核心业务表的记录数、关键字段进行抽样比对 | + +#### 7.2.2 校验操作示例 + +```bash +# 源端生成校验文件 +sha256sum backup_data.sql.enc > backup_data.sql.enc.sha256 + +# 目标端校验 +sha256sum -c backup_data.sql.enc.sha256 +``` + +#### 7.2.3 校验失败处理 + +- 校验失败时，自动触发告警通知运维人员。 +- 系统自动重新从源端获取备份文件，执行重传操作。 +- 连续3次重传失败后，升级告警等级，要求人工介入排查。 + +### 7.3 密钥管理 + +| 管理要求 | 具体措施 | +|---------|---------| +| 密钥存储 | 加密密钥存储于独立的密钥管理系统中，严禁与备份数据同存储 | +| 密钥分发 | 密钥仅在主中心和灾备中心的备份服务器上部署，通过安全通道分发 | +| 密钥更新 | 每季度定期更换加密密钥，更换前后新旧密钥并行使用一个备份周期 | +| 密钥备份 | 密钥以离线方式备份至安全介质，由安全管理员保管 | +| 访问控制 | 仅授权运维人员可访问密钥文件，严格限制文件系统权限 | + +### 7.4 访问控制与审计 + +| 控制维度 | 具体措施 | +|---------|---------| +| 账号管理 | 备份操作使用专用服务账号，与业务账号隔离 | +| 权限控制 | 备份服务账号仅具备数据读取和备份文件写入权限，不具备数据修改或删除权限 | +| 操作审计 | 全部备份操作、传输操作、恢复操作记录至审计日志，日志保留不少于6个月 | +| 网络隔离 | 备份传输通道与业务网络逻辑隔离，避免备份流量影响业务性能 | + +--- + +## 8 自动化运维方案 + +### 8.1 备份自动化调度 + +#### 8.1.1 增量备份调度 + +全部增量备份任务通过Kubernetes CronJob或系统Cron定时任务实现自动化调度： + +**飞服平台增量备份任务调度表**： + +| 任务名称 | Cron表达式 | 执行时间说明 | 目标组件 | +|---------|-----------|-------------|---------| +| mysql-incremental-backup | `0 */2 * * *` | 每2小时整点执行 | MySQL → MySQL | +| influxdb-incremental-backup | `10 */2 * * *` | 每2小时的第10分钟执行 | InfluxDB → InfluxDB | +| minio-incremental-sync | `20 */2 * * *` | 每2小时的第20分钟执行 | MinIO → MinIO | + +**监管平台增量备份任务调度表**： + +| 任务名称 | Cron表达式 | 执行时间说明 | 目标组件 | +|---------|-----------|-------------|---------| +| mysql-incremental-backup | `0 */2 * * *` | 每2小时整点执行 | MySQL → MySQL | +| doris-incremental-backup | `10 */2 * * *` | 每2小时的第10分钟执行 | Doris → Doris | +| minio-incremental-sync | `20 */2 * * *` | 每2小时的第20分钟执行 | MinIO → MinIO | + +> **说明**：各任务执行时间错开10分钟，避免多个备份任务同时运行对系统资源造成过大压力。 + +#### 8.1.2 全量备份调度 + +| 任务名称 | Cron表达式 | 执行时间说明 | 备注 | +|---------|-----------|-------------|------| +| full-backup-weekly | `0 2 * * 0` | 每周日凌晨02:00执行 | 飞服平台和监管平台统一执行 | + +#### 8.1.3 备份脚本架构 + +``` +/opt/disaster-recovery/ +├── bin/ +│ ├── mysql-backup.sh # MySQL增量/全量备份脚本 +│ ├── influxdb-backup.sh # InfluxDB增量/全量备份脚本（飞服平台） +│ ├── doris-backup.sh # Doris增量/全量备份脚本（监管平台） +│ ├── minio-sync.sh # MinIO增量/全量同步脚本 +│ ├── encrypt.sh # AES-256加密脚本 +│ ├── decrypt.sh # AES-256解密脚本 +│ ├── verify-checksum.sh # SHA-256校验脚本 +│ └── transfer.sh # 跨机房传输脚本 +├── conf/ +│ ├── backup.conf # 备份配置文件 +│ └── alert.conf # 告警配置文件 +├── logs/ +│ └── backup-YYYYMMDD.log # 备份日志文件 +└── keys/ + └── .backup.key # 加密密钥文件（权限600） +``` + +### 8.2 数据导入自动化 + +灾备中心的数据导入流程同样实现自动化运行： + +1. 灾备中心部署数据接收服务，自动监听备份数据传输。 +2. 接收到加密备份文件后，自动执行SHA-256校验。 +3. 校验通过后，自动执行解密操作。 +4. 解密后的数据自动导入至对应的中间件实例（MySQL、InfluxDB/Doris、MinIO）。 +5. 导入完成后，生成导入状态报告并记录日志。 + +### 8.3 异常告警与人工介入机制 + +#### 8.3.1 告警分级 + +| 告警级别 | 触发条件 | 通知方式 | 处理要求 | +|---------|---------|---------|---------| +| **P1-紧急** | 备份任务连续3次执行失败 | 电话 + 短信 + 企业微信 | 15分钟内人工介入 | +| **P2-重要** | 单次备份任务执行失败 | 短信 + 企业微信 | 30分钟内人工介入 | +| **P2-重要** | 数据校验失败（含自动重试） | 短信 + 企业微信 | 30分钟内人工介入 | +| **P3-一般** | 备份任务执行超时（超过预设阈值） | 企业微信 | 1小时内确认处理 | +| **P3-一般** | 备份存储空间低于阈值（<20%） | 企业微信 | 24小时内扩容处理 | + +#### 8.3.2 人工介入场景 + +以下场景需要运维人员人工介入处理： + +1. 增量备份任务连续3次执行失败，需排查数据源或传输链路问题。 +2. 数据校验连续3次重传后仍失败，需排查传输通道或加密密钥问题。 +3. 数据导入至灾备中心后一致性抽检不通过，需排查数据库状态。 +4. 全量备份执行失败或耗时异常，需排查存储空间和系统资源。 +5. 灾备中心服务健康检查异常，需排查灾备环境运行状态。 + +### 8.4 监控与日志 + +#### 8.4.1 监控指标 + +| 监控项 | 监控内容 | 采集频率 | 告警阈值 | +|--------|---------|---------|---------| +| 备份任务状态 | 各备份任务的执行状态（成功/失败/进行中） | 每次任务执行时 | 失败即告警 | +| 备份数据量 | 每次备份生成的数据量大小 | 每次任务执行时 | 偏差超过50%告警 | +| 备份耗时 | 每次备份任务的执行时长 | 每次任务执行时 | 超过预设阈值告警 | +| 传输带宽利用率 | 机房间传输通道的带宽使用情况 | 每5分钟 | 超过80%告警 | +| 备份存储空间 | 备份存储设备的剩余空间 | 每小时 | 低于20%告警 | +| 灾备中心服务状态 | 灾备中心各中间件和微服务的运行状态 | 每分钟 | 异常即告警 | + +#### 8.4.2 日志管理 + +| 日志类型 | 内容 | 保留周期 | +|---------|------|---------| +| 备份执行日志 | 备份任务的启动时间、执行步骤、数据量、耗时、完成状态 | 90天 | +| 传输日志 | 文件传输的起止时间、文件大小、传输速率、传输结果 | 90天 | +| 校验日志 | 哈希校验的文件名、源端校验值、目标端校验值、校验结果 | 90天 | +| 导入日志 | 数据导入的起止时间、导入数据量、导入结果 | 90天 | +| 操作审计日志 | 人工操作的操作人、操作时间、操作内容、操作结果 | 180天 | + +--- + +## 9 灾备演练方案 + +### 9.1 演练目标 + +1. 验证灾备切换流程的完整性和可操作性。 +2. 验证RTO和RPO指标是否达到设计目标。 +3. 检验运维团队对灾备切换流程的熟练程度。 +4. 发现灾备方案中的潜在问题并持续改进。 + +### 9.2 演练计划 + +| 演练类型 | 演练周期 | 演练范围 | 说明 | +|---------|---------|---------|------| +| 桌面推演 | 每季度1次 | 全流程 | 以文档推演方式走读灾备切换全流程，不涉及实际操作 | +| 备份恢复演练 | 每季度1次 | 数据备份与恢复 | 实际执行备份数据的恢复操作，验证数据可用性 | +| 切换演练 | 每半年1次 | 全流程切换 | 实际执行灾备切换操作（可在维护窗口期执行），验证端到端切换能力 | + +### 9.3 演练流程 + +#### 9.3.1 演练前准备 + +1. 制定演练方案，明确演练目标、范围、步骤和人员分工。 +2. 通知相关业务方演练时间和可能的影响。 +3. 确认灾备中心环境运行状态正常。 +4. 准备演练记录表和评估清单。 + +#### 9.3.2 演练执行 + +1. 按照灾备切换流程逐步执行操作。 +2. 记录每个步骤的实际执行时间和结果。 +3. 记录演练过程中遇到的问题和异常情况。 +4. 完成业务功能验证，确认灾备环境服务正常。 + +#### 9.3.3 演练回切 + +1. 演练完成后，将业务流量切回主中心。 +2. 确认主中心业务恢复正常。 +3. 验证回切过程中的数据一致性。 + +#### 9.3.4 演练总结 + +1. 编制演练报告，汇总演练过程、执行耗时、发现问题。 +2. 评估RTO和RPO指标是否达标。 +3. 针对发现的问题制定改进措施和整改计划。 +4. 更新灾备方案文档（如有必要）。 + +### 9.4 演练评估标准 + +| 评估维度 | 达标标准 | 说明 | +|---------|---------|------| +| RTO | ≤ 2小时 | 从启动切换到业务恢复对外服务的总耗时 | +| RPO | ≤ 2小时 | 数据丢失时间窗口不超过2小时 | +| 切换成功率 | 100% | 所有业务功能均正常可用 | +| 数据完整性 | 100% | 备份数据与源数据一致性校验通过 | +| 流程规范性 | 100% | 所有步骤按照文档规范执行 | + +--- + +## 10 具体操作手册（待完善） + +> **说明**：本章节为具体操作手册的预留章节，将在方案评审通过后，根据实际部署环境编写详细的操作步骤指南。每份操作手册应包含：前置条件、操作步骤、验证方法、回滚方案、常见问题处理。 + +### 10.1 MySQL备份与恢复操作手册 + +*（待完善）* + +主要内容规划： + +- MySQL增量备份操作步骤（Percona XtraBackup / mysqldump） +- MySQL增量备份数据恢复步骤（Binlog回放） +- MySQL全量备份操作步骤 +- MySQL全量备份数据恢复步骤 +- MySQL备份文件加密/解密操作 +- MySQL数据一致性校验操作 +- 常见故障排查指南 + +### 10.2 InfluxDB备份与恢复操作手册 + +*（待完善）* + +主要内容规划： + +- InfluxDB按时间范围导出操作步骤 +- InfluxDB数据导入恢复步骤 +- InfluxDB全量备份操作步骤 +- InfluxDB全量备份恢复步骤 +- InfluxDB备份文件加密/解密操作 +- InfluxDB数据一致性校验操作 +- 常见故障排查指南 + +### 10.3 MinIO备份与恢复操作手册 + +*（待完善）* + +主要内容规划： + +- MinIO增量同步操作步骤（mc mirror） +- MinIO Bucket Replication配置步骤（可选方案） +- MinIO全量同步操作步骤 +- MinIO TLS证书配置步骤 +- MinIO对象文件加密/解密操作 +- MinIO数据一致性校验操作 +- MinIO生命周期管理配置 +- 常见故障排查指南 + +### 10.4 Doris备份与恢复操作手册 + +*（待完善）* + +主要内容规划： + +- Doris Repository创建与配置步骤 +- Doris Snapshot备份操作步骤（BACKUP命令） +- Doris Snapshot恢复操作步骤（RESTORE命令） +- Doris CCR Syncer部署与配置步骤 +- Doris CCR跨集群复制链路建立步骤 +- Doris Binlog参数配置步骤 +- Doris数据一致性校验操作 +- 常见故障排查指南 + +### 10.5 灾备切换操作手册 + +*（待完善）* + +主要内容规划： + +- 灾备切换前检查清单 +- 飞服平台灾备切换详细操作步骤 +- 监管平台灾备切换详细操作步骤 +- DNS域名解析修改操作步骤 +- 业务功能验证检查清单 +- 切换后数据丢失评估操作步骤 +- 灾备切换通知模板 + +### 10.6 灾备回切操作手册 + +*（待完善）* + +主要内容规划： + +- 原主中心故障恢复确认流程 +- 数据回同步操作步骤（灾备中心 → 主中心） +- 回切前数据一致性校验步骤 +- DNS域名解析回切操作步骤 +- 业务功能验证检查清单 +- 回切后增量备份恢复正常调度确认 + +--- + +## 附录A 备份任务Cron表达式汇总 + +### A.1 飞服平台 + +| 任务名称 | Cron表达式 | 执行说明 | +|---------|-----------|---------| +| MySQL增量备份 | `0 */2 * * *` | 每2小时整点（00:00, 02:00, 04:00 ...） | +| InfluxDB增量备份 | `10 */2 * * *` | 每2小时的第10分钟（00:10, 02:10, 04:10 ...） | +| MinIO增量同步 | `20 */2 * * *` | 每2小时的第20分钟（00:20, 02:20, 04:20 ...） | +| 全量备份（全部组件） | `0 2 * * 0` | 每周日凌晨02:00 | + +### A.2 监管平台 + +| 任务名称 | Cron表达式 | 执行说明 | +|---------|-----------|---------| +| MySQL增量备份 | `0 */2 * * *` | 每2小时整点（00:00, 02:00, 04:00 ...） | +| Doris增量备份 | `10 */2 * * *` | 每2小时的第10分钟（00:10, 02:10, 04:10 ...） | +| MinIO增量同步 | `20 */2 * * *` | 每2小时的第20分钟（00:20, 02:20, 04:20 ...） | +| 全量备份（全部组件） | `0 2 * * 0` | 每周日凌晨02:00 | + +--- + +## 附录B 灾备切换检查清单 + +### B.1 切换前检查 + +| 序号 | 检查项 | 检查内容 | 检查结果 | 检查人 | +|------|--------|---------|---------|--------| +| 1 | 故障确认 | 确认主中心故障性质和预计恢复时间 | □ 通过 □ 不通过 | | +| 2 | 灾备中心K8s集群 | 确认K8s集群各节点运行正常 | □ 通过 □ 不通过 | | +| 3 | 灾备中心MySQL | 确认MySQL实例运行正常且最新备份已导入 | □ 通过 □ 不通过 | | +| 4 | 灾备中心InfluxDB/Doris | 确认InfluxDB/Doris实例运行正常且最新备份已导入 | □ 通过 □ 不通过 | | +| 5 | 灾备中心MinIO | 确认MinIO实例运行正常且最新备份已同步 | □ 通过 □ 不通过 | | +| 6 | 灾备中心EMQX | 确认EMQX实例运行正常，可接收设备连接 | □ 通过 □ 不通过 | | +| 7 | 灾备中心微服务 | 确认全部微服务Pod运行正常 | □ 通过 □ 不通过 | | +| 8 | DNS管理权限 | 确认域名管理操作权限就绪 | □ 通过 □ 不通过 | | + +### B.2 切换后验证 + +| 序号 | 验证项 | 验证内容 | 验证结果 | 验证人 | +|------|--------|---------|---------|--------| +| 1 | DNS解析 | 确认域名已解析至灾备中心IP | □ 通过 □ 不通过 | | +| 2 | 平台登录 | 确认用户可正常登录平台 | □ 通过 □ 不通过 | | +| 3 | 核心业务功能 | 确认核心业务功能操作正常 | □ 通过 □ 不通过 | | +| 4 | 设备连接 | 确认外部设备可正常连接EMQX | □ 通过 □ 不通过 | | +| 5 | 数据查询 | 确认历史数据可正常查询 | □ 通过 □ 不通过 | | +| 6 | 数据丢失评估 | 确认数据丢失时间窗口 ≤ 2小时 | □ 通过 □ 不通过 | | + +--- + +*文档结束* diff --git a/91-HarnessEngineering/1-API自动更新Postman/1-Go项目自动更新Postman.md b/91-HarnessEngineering/1-API自动更新Postman/1-Go项目自动更新Postman.md new file mode 100644 index 0000000..aee3095 --- /dev/null +++ b/91-HarnessEngineering/1-API自动更新Postman/1-Go项目自动更新Postman.md @@ -0,0 +1,13 @@ +我有Golang的代码，我需要实现的核心目标是，每次代码提交之后，能够自动将我增量更新的API发送给 Postman，然后更新到Postman collection中，最终形成自动化API维护的流程 + +基本情况说明： +1. Windows环境Go开发环境 +2. Windows运行Postman +3. Golang使用的是GIN框架 + +自己的方案设想 +1. 通过Codex安装Postman的MCP Server，将增量的API接口同步到Postman的Collection +2. 使用Go代码直接生成的OpenAPI，通过openapi-to-postmanv2工具转换成Postman的Collection +3. 通过大模型的SKILL控制Postman的API，直接更新Collection + +请你根据实际情况，分析以上三种方案的可行性，可以不局限于上述的方案，可以给出更加优秀的方案，并给出最合适的方案，包括具体的实施步骤和代码示例 diff --git a/91-HarnessEngineering/1-API自动更新Postman/2-Go项目同步实现方案.md b/91-HarnessEngineering/1-API自动更新Postman/2-Go项目同步实现方案.md new file mode 100644 index 0000000..8e04160 --- /dev/null +++ b/91-HarnessEngineering/1-API自动更新Postman/2-Go项目同步实现方案.md @@ -0,0 +1,215 @@ +## 基本信息如下 +1. Postman API KEY: PMAK-6a3cc4b60d07e1000174ede8-e51652fd3ba3f4a2895f1386a8b317ebf1 +2. collection uid: 15340181-95b85065-2cf9-4ebe-bde2-e76fbfdeeea9 + + +**推荐方案是：方案二（swag + openapi-to-postmanv2 + Git pre-commit hook + Postman API 自动推送）的完整自动化流水线**， + +*** + +## 三种方案可行性分析 + +| 维度 | 方案一：Postman MCP Server | 方案二：OpenAPI 转换流水线 | 方案三：大模型控制 Postman API | +|---|---|---|---| +| **稳定性** | ⚠️ MCP 协议仍在快速变化，Postman MCP Server 尚不成熟 | ✅ 工具链稳定，swag+openapi-to-postmanv2 均为生产可用 | ❌ 大模型调用有延迟、不确定性，不适合自动化 CI | +| **Gin 原生支持** | ❌ 无法感知路由，需手动描述 | ✅ swag 直接解析 Gin 路由注解，完全自动化 | ❌ 需要额外描述路由结构 | +| **增量同步** | ⚠️ 依赖 MCP 协议实现，Collection 合并逻辑不透明 | ✅ Postman PUT API 覆盖 Collection，配合 folderStrategy=Tags 保持结构 | ❌ 无法保证增量一致性 | +| **Windows 兼容** | ❌ Codex 在 Windows 下配置复杂 | ✅ npm + swag CLI 在 Windows 完全支持 | ⚠️ 依赖 API 密钥，可行但复杂 | +| **离线可用** | ❌ 依赖 Codex 云端服务 | ✅ 除推送 Postman API 外完全本地 | ❌ 必须联网 | + +*** + +## 推荐方案：OpenAPI 自动化流水线 + +整体流程为： + +``` +git commit + ↓ pre-commit hook +swag init (生成 swagger.json) + ↓ +openapi2postmanv2 (转换为 collection.json) + ↓ +curl PUT Postman API (推送到 Postman Collection) + ↓ +git commit 完成 +``` + +*** + +## 具体实施步骤 + +### Step 1：安装依赖工具 + +```bash +# 安装 swag（Go OpenAPI 注解生成器） +go install github.com/swaggo/swag/cmd/swag@latest + +# 安装 Gin swagger 中间件 +go get -u github.com/swaggo/gin-swagger +go get -u github.com/swaggo/files + +# 安装 openapi-to-postmanv2（需要 Node.js） +npm install -g openapi-to-postmanv2 +``` + +### Step 2：在 Gin 路由上添加 swag 注解 + +在 `main.go` 中添加全局文档注解 ： [medium](https://medium.com/@feldy7k/how-to-create-a-dynamic-swagger-ui-for-golang-api-with-gin-5b85eaa248b3) + +```go +// @title My API +// @version 1.0 +// @description API 文档 +// @host localhost:8080 +// @BasePath /api/v1 +package main + +import ( + _ "your-project/docs" // swag 生成的 docs 包 + ginSwagger "github.com/swaggo/gin-swagger" + swaggerFiles "github.com/swaggo/files" + "github.com/gin-gonic/gin" +) + +func main() { + r := gin.Default() + r.GET("/swagger/*any", ginSwagger.WrapHandler(swaggerFiles.Handler)) + // ... 路由注册 + r.Run() +} +``` + +在具体 Handler 函数上添加接口注解： + +```go +// GetUser 获取用户信息 +// @Summary 获取用户 +// @Description 通过 ID 获取用户详情 +// @Tags users +// @Accept json +// @Produce json +// @Param id path int true "User ID" +// @Success 200 {object} UserResponse +// @Failure 404 {object} ErrorResponse +// @Router /users/{id} [get] +func GetUser(c *gin.Context) { + // ... +} +``` + +### Step 3：配置 Git pre-commit hook + +在项目根目录创建 `.git/hooks/pre-commit` 文件（Windows 下可创建 `pre-commit` 无扩展名文件）： [richardswinbank](https://richardswinbank.net/git/hooks) + +```bash +#!/bin/sh +# pre-commit: 自动生成 OpenAPI -> 转换 -> 推送 Postman + +set -e + +echo "[hook] 正在生成 swagger 文档..." +swag init --generalInfo cmd/main.go --output docs + +echo "[hook] 正在转换为 Postman Collection..." +openapi2postmanv2 -s docs/swagger.json \ + -o docs/postman_collection.json \ + -p \ + -O folderStrategy=Tags,includeAuthInfoInExample=true + +echo "[hook] 正在推送到 Postman..." +# POSTMAN_API_KEY 和 POSTMAN_COLLECTION_UID 通过环境变量注入 +node scripts/update-postman.js + +# 将生成的文档文件加入本次提交 +git add docs/swagger.json docs/swagger.yaml docs/postman_collection.json +echo "[hook] API 文档已自动更新并加入提交" +``` + +### Step 4：创建 Postman 推送脚本 + +创建 `scripts/update-postman.js` ： [community.postman](https://community.postman.com/t/automatically-sync-swagger-apis-with-postman-when-bitbucket-files-are-changed/89229) + +```javascript +const fs = require('fs'); +const https = require('https'); + +const POSTMAN_API_KEY = process.env.POSTMAN_API_KEY; +const COLLECTION_UID = process.env.POSTMAN_COLLECTION_UID; + +if (!POSTMAN_API_KEY || !COLLECTION_UID) { + console.error('缺少环境变量: POSTMAN_API_KEY 或 POSTMAN_COLLECTION_UID'); + process.exit(1); +} + +const collectionData = JSON.parse( + fs.readFileSync('./docs/postman_collection.json', 'utf8') +); + +// Postman API 要求 collection 包装在 { collection: ... } 中 +const body = JSON.stringify({ collection: collectionData }); + +const options = { + hostname: 'api.getpostman.com', + path: `/collections/${COLLECTION_UID}`, + method: 'PUT', + headers: { + 'Content-Type': 'application/json', + 'X-Api-Key': POSTMAN_API_KEY, + 'Content-Length': Buffer.byteLength(body) + } +}; + +const req = https.request(options, (res) => { + let data = ''; + res.on('data', chunk => data += chunk); + res.on('end', () => { + const result = JSON.parse(data); + if (res.statusCode === 200) { + console.log(`✅ Postman Collection 更新成功: ${result.collection?.name}`); + } else { + console.error(`❌ 更新失败 (${res.statusCode}):`, data); + process.exit(1); + } + }); +}); + +req.on('error', (e) => { console.error('请求错误:', e); process.exit(1); }); +req.write(body); +req.end(); +``` + +### Step 5：配置环境变量（Windows） + +```powershell +# 在 PowerShell 中设置用户级环境变量（持久化） +[System.Environment]::SetEnvironmentVariable( + "POSTMAN_API_KEY", "your_api_key_here", "User" +) +[System.Environment]::SetEnvironmentVariable( + "POSTMAN_COLLECTION_UID", "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx", "User" +) +``` + +**获取 Collection UID** 的方法：在 Postman 桌面端右键点击 Collection → **Copy link** 或 **Info**，URL 中的 UUID 即为 UID。**获取 API Key**：Postman → 头像 → Settings → API Keys → Generate API Key 。 [community.postman](https://community.postman.com/t/update-a-collection-using-postman-api/906) + +*** + +## 进阶优化：仅在 .go 文件变更时触发 + +将 `pre-commit` 脚本中的触发逻辑改为仅当有 Go 文件变更时执行，避免无意义的推送： + +```bash +#!/bin/sh +# 检查是否有 .go 文件变更 +GO_FILES=$(git diff --cached --name-only --diff-filter=ACM | grep '\.go$') + +if [ -z "$GO_FILES" ]; then + echo "[hook] 无 .go 文件变更，跳过 API 文档更新" + exit 0 +fi + +# ... 后续 swag init、转换、推送逻辑 +``` + +*** \ No newline at end of file diff --git a/99-项目模板/4-系统架构师/0-大模型提示词打磨专家.md b/99-项目模板/4-系统架构师/0-大模型提示词打磨专家.md new file mode 100644 index 0000000..0754e6e --- /dev/null +++ b/99-项目模板/4-系统架构师/0-大模型提示词打磨专家.md @@ -0,0 +1,9 @@ +你是一名精通大模型使用的提示词工程专家，你的核心需求是 + +1. 对现有的提示词进行分析，理解其意图和要求 +2. 对提示词进行打磨，能够让其他的大模型能够更好的理解 +3. 能够让其他的大模型能够严格按照要求来执行 + +你应该只参考提示词明确提及的要求，其他任何额外的信息都忽略 + +请你优化 99-项目模板\4-系统架构师\4-PRD转化大模型实现大纲.md \ No newline at end of file diff --git a/99-项目模板/4-系统架构师/3-普通需求转化专业需求.md b/99-项目模板/4-系统架构师/3-普通需求转化专业需求.md new file mode 100644 index 0000000..de83b49 --- /dev/null +++ b/99-项目模板/4-系统架构师/3-普通需求转化专业需求.md @@ -0,0 +1,62 @@ +# 角色 + +你是一名资深系统架构师，擅长设计简洁、可靠、可演进且避免过度设计的微服务系统。 + +# 任务 + +将用户提供的原始需求文档转化为结构清晰、内容专业的**定版软件设计需求文档（PRD）**。 + +# 设计原则 + +1. 以第一性原理为基础，优先解决真实业务需求和核心工程问题。 +2. 不机械遵循设计文档；在充分理解约束的前提下，可提出更合理、更简洁、更可维护的替代方案。 +3. 充分发挥资深架构师经验，对系统进行必要优化，但避免炫技式设计和不必要的复杂化。 +4. 关注系统的可维护性、可扩展性、可观测性、稳定性、安全性和工程落地成本。 +5. 结合现代云原生架构实践，合理使用微服务、容器化、Kubernetes、Docker 等技术。 + +# 项目技术栈 + +- 后端：Golang、Gin、GORM +- 数据库：PostgreSQL +- 缓存：Redis +- 前端：Vue 3、Vuetify 3、TypeScript +- 架构与基础设施：微服务架构、Docker、Kubernetes、云原生相关技术 + +# 工作流程 + +严格按以下三个阶段依次执行，**未完成当前阶段不得进入下一阶段**。 + +## 阶段一：需求分析（必须先完成此阶段） + +1. 逐段阅读用户提供的原始需求文档，提取所有功能点、业务规则和约束条件。 +2. 输出**需求分析报告**，包含以下内容： + - **需求理解总结**：用你自己的语言概述文档的核心意图和业务目标。 + - **优化点**：原始文档中可以改进的结构或表述。 + - **修改点**：原始文档中存在歧义、矛盾或不合理之处。 + - **新增点**：原始文档中缺失但对完整 PRD 必要的内容。 + - **待确认问题清单**：列出所有你不确定的设计意图、关键决策点或有多种合理实现路径的问题。 +3. **在此阶段结束后，等待用户确认后再进入阶段二。** + +## 阶段二：方案设计（用户确认阶段一后执行） + +1. 基于阶段一的分析结果和用户反馈，设计 PRD 的完整结构大纲。 +2. 对关键模块补充必要的流程图（必须使用 Mermaid 语法绘制）。 +3. 输出**结构大纲和关键流程图**，供用户审阅。 +4. **在此阶段结束后，等待用户确认后再进入阶段三。** + +## 阶段三：文档定稿（用户确认阶段二后执行） + +1. 生成完整的定版 PRD 文档。 +2. 文档必须包含清晰的版本号（格式：`v主版本.次版本`，如 `v1.0`）。 +3. **必须创建新文件输出，禁止修改原始文档。** + +# 硬性约束 + +以下规则在任何阶段都必须遵守，违反任何一条即视为输出不合格： + +1. **禁止丢失原始需求信息**：原始文档中的每一条需求都必须在最终 PRD 中有对应体现。 +2. **禁止过度设计**：不添加原始需求未提及且用户未确认的复杂功能。 +3. **禁止输出代码**：本任务仅涉及文档层面，不输出任何代码实现。 +4. **禁止修改原始文档**：所有输出必须以新文件形式创建。 +5. **禁止使用任何 Skill**：不调用外部 Skill 或插件。 +6. **禁止读取非本次上下文的其他文件**：仅基于用户在当前对话中提供的内容工作。 \ No newline at end of file diff --git a/99-项目模板/4-系统架构师/3-需求文档优化师.md b/99-项目模板/4-系统架构师/3-需求文档优化师.md deleted file mode 100644 index ef4b60a..0000000 --- a/99-项目模板/4-系统架构师/3-需求文档优化师.md +++ /dev/null @@ -1,35 +0,0 @@ -你是一名资深系统架构师，擅长设计简洁、可靠、可演进且避免过度设计的微服务系统。 - -设计原则： -1. 以第一性原理为基础，优先解决真实业务需求和核心工程问题。 -2. 不机械遵循设计文档；在充分理解约束的前提下，可提出更合理、更简洁、更可维护的替代方案。 -3. 充分发挥资深架构师经验，对系统进行必要优化，但避免炫技式设计和不必要的复杂化。 -4. 关注系统的可维护性、可扩展性、可观测性、稳定性、安全性和工程落地成本。 -5. 结合现代云原生架构实践，合理使用微服务、容器化、Kubernetes、Docker 等技术。 - -项目技术栈： -- 后端：Golang、Gin、GORM -- 数据库：PostgreSQL -- 缓存：Redis -- 前端：Vue 3、Vuetify 3、TypeScript -- 架构与基础设施：微服务架构、Docker、Kubernetes、云原生相关技术 - -禁止内容: -1. 禁止丢失原始的需求信息 -2. 禁止过度设计 -3. 禁止过度优化 -4. 禁止增加不切实际的复杂功能 -5. 禁止输出代码内容 -6. 禁止直接在原文档修改 -7. 禁止使用任何skill -8. 禁止读取非本次上下文的其他文件 - -遵守规范: -1. 应该先分析原始的需求文档，充分理解设计意图和原始的需求 -2. 需要说明优化点, 修改点, 新增点 -3. 不理解的地方, 关键设计点, 需要和用户确认 -4. 需要先设计然后充分确认之后, 再生成最终的定版的软件设计需求文档 -5. 生成文件应该创建新的文件，不要在原文档修改 - - -你的核心职责是基于用户原始需求设计文档，进行文档结构重塑、内容专业化和结构优化，补充不足，制定完善的定版的软件设计需求文档。请你基于附件生成标准规范的的原始需求文档 \ No newline at end of file diff --git a/99-项目模板/4-系统架构师/4-PRD转化大模型专家.md b/99-项目模板/4-系统架构师/4-PRD转化大模型专家.md deleted file mode 100644 index b8c4428..0000000 --- a/99-项目模板/4-系统架构师/4-PRD转化大模型专家.md +++ /dev/null @@ -1,40 +0,0 @@ -你是一名资深系统架构师，擅长设计简洁、可靠、可演进且避免过度设计的微服务系统。 - -你的核心职责是根据规范的PRD充当系统架构师、研发项目经理的角色，将PRD拆解为其他大模型可以参考和依赖的系统简要设计和实现的大纲（简称大纲），此大纲会作为goal目标设定给其他的大模型Agent进行持久化任务 - -设计原则： -1. 以第一性原理为基础，优先解决真实业务需求和核心工程问题。 -2. 不机械遵循设计文档；在充分理解约束的前提下，可提出更合理、更简洁、更可维护的替代方案。 -3. 充分发挥资深架构师经验，对系统进行必要优化，但避免炫技式设计和不必要的复杂化。 -4. 关注系统的可维护性、可扩展性、可观测性、稳定性、安全性和工程落地成本。 -5. 结合现代云原生架构实践，合理使用微服务、容器化、Kubernetes、Docker 等技术。 - -项目技术栈： -- 后端：Golang、Gin、GORM -- 数据库：PostgreSQL -- 缓存：Redis -- 前端：Vue 3、Vuetify 3、TypeScript -- 架构与基础设施：微服务架构、Docker、Kubernetes、云原生相关技术 - -禁止内容 -1. 禁止丢失原始的需求信息 -2. 禁止过度设计 -3. 禁止直接在原文档修改 -4. 禁止使用任何skill -5. 禁止读取非本次上下文的其他文件 -6. 禁止输出代码规范和大面积的代码实现，由其他AgentSkill实现 -7. 禁止替其他Agent实现过多内容，需要把控核心需求和达成条件 - -核心原则 -1. 充分理解PRD的设计意图，设计层次递进的大纲文件 -2. 大纲文件应该是很多份的，分阶段，分文件输出多个简要设计实现大纲 -3. 大纲应该包含严格的阶段性开发基础条件要求，阶段性设计目标，需要包含严格的阶段性实现达成条件 -4. 大纲不应该包含具体的实现代码，除非是非常核心的设计实现 -5. 考虑实现可以并行，如果有可以并行实现的大纲，应该说明 -6. 不理解的地方, 关键设计点, 需要和用户确认 - -基本要求 -1. 应该建立新的目录，将所有的大纲文件统一输入 - - -请基于下面的文档，按照上述的要求拆分大纲 diff --git a/99-项目模板/4-系统架构师/4-PRD转化大模型实现大纲.md b/99-项目模板/4-系统架构师/4-PRD转化大模型实现大纲.md new file mode 100644 index 0000000..0871bcc --- /dev/null +++ b/99-项目模板/4-系统架构师/4-PRD转化大模型实现大纲.md @@ -0,0 +1,89 @@ +# 角色 + +你是一名资深系统架构师，擅长设计简洁、可靠、可演进且避免过度设计的微服务系统。 + +# 任务 + +将用户提供的**定版 PRD 文档**拆解为一组**层次递进、可直接指导大模型 Agent 执行的实现大纲文件**。 + +**核心定义**： +- **实现大纲（以下简称"大纲"）**：面向其他大模型 Agent 的简要设计与实现指导文档。每份大纲将作为 Goal 目标设定给对应的 Agent 执行持久化开发任务。 +- 大纲**不是代码**，而是足够清晰的设计意图、阶段目标和达成条件的描述。 + +# 设计原则 + +1. 以第一性原理为基础，优先解决真实业务需求和核心工程问题。 +2. 不机械遵循设计文档；在充分理解约束的前提下，可提出更合理、更简洁、更可维护的替代方案。 +3. 充分发挥资深架构师经验，对系统进行必要优化，但避免炫技式设计和不必要的复杂化。 +4. 关注系统的可维护性、可扩展性、可观测性、稳定性、安全性和工程落地成本。 +5. 结合现代云原生架构实践，合理使用微服务、容器化、Kubernetes、Docker 等技术。 + +# 项目技术栈 + +- 后端：Golang、Gin、GORM +- 数据库：PostgreSQL +- 缓存：Redis +- 前端：Vue 3、Vuetify 3、TypeScript +- 架构与基础设施：微服务架构、Docker、Kubernetes、云原生相关技术 + +# 工作流程 + +严格按以下三个阶段依次执行，**未完成当前阶段不得进入下一阶段**。 + +## 阶段一：PRD 分析与大纲规划（必须先完成此阶段） + +1. 逐段精读用户提供的 PRD 文档，提取所有功能模块、业务规则、约束条件和设计细节。 +2. 识别模块间的依赖关系，判断哪些大纲可以**并行开发**、哪些存在**前后依赖**。 +3. 输出**大纲规划报告**，包含以下内容： + - **PRD 理解总结**：用你自己的语言概述 PRD 的核心意图和业务目标。 + - **大纲拆分方案**：列出计划拆分的所有大纲（标题 + 一句话描述），并标注它们之间的依赖和并行关系。 + - **待确认问题清单**：列出所有你不确定的设计意图、关键决策点或有多种合理拆分路径的问题。 +4. **在此阶段结束后，等待用户确认后再进入阶段二。** + +## 阶段二：INDEX 大纲设计（用户确认阶段一后执行） + +1. 基于阶段一的分析结果和用户反馈，设计 INDEX 大纲文件。 +2. INDEX 大纲是整个大纲体系的总控文件，必须包含： + - **项目概述**：一段简要的项目背景描述。 + - **大纲清单**：所有子大纲的编号、标题、文件名和一句话描述。 + - **依赖与并行关系图**：使用 Mermaid 语法绘制大纲间的执行顺序和并行关系。 + - **阶段性里程碑**：每个阶段完成后的整体预期状态。 +3. 输出 **INDEX 大纲**，供用户审阅。 +4. **在此阶段结束后，等待用户确认后再进入阶段三。** + +## 阶段三：子大纲逐份输出（用户确认阶段二后执行） + +按 INDEX 中定义的顺序，逐份输出所有子大纲文件。每份子大纲必须包含以下结构： + +1. **大纲标题与编号**：与 INDEX 中一致。 +2. **开发基础条件**：执行本大纲前必须满足的前置条件（如依赖的其他大纲已完成、特定基础设施已就绪）。 +3. **设计目标**：本大纲要实现的具体目标，需精确到模块/功能级别。 +4. **核心设计要点**：关键的技术决策、数据模型设计、接口契约、流程描述等。仅在涉及**非常核心的设计实现**时可包含少量关键伪代码或数据结构示例。 +5. **达成条件**：本大纲完成的严格验收标准，Agent 必须逐条满足才视为完成。 +6. **与其他大纲的关系**：明确说明本大纲的上游依赖和下游影响。 + +# 输出文件规范 + +1. **必须创建新目录**存放所有大纲文件，禁止修改原始 PRD 文档。 +2. 文件命名格式： + - INDEX 文件：`00-INDEX.md` + - 子大纲文件：`{序号}-{大纲简称}.md`（如 `01-数据库基础设施.md`、`02-用户认证模块.md`） +3. 所有文件使用 Markdown 格式。 + +# 硬性约束 + +以下规则在任何阶段都必须遵守，违反任何一条即视为输出不合格： + +1. **禁止丢失 PRD 信息**：PRD 中的每一条需求和设计细节都必须在大纲体系中有对应体现。 +2. **禁止过度设计**：不添加 PRD 未提及且用户未确认的复杂功能。 +3. **禁止过度拆分**：保障每份大纲内容的完整性和独立可执行性，避免碎片化。 +4. **禁止输出大面积代码**：大纲是设计指导文档，具体代码实现由执行 Agent 完成。 +5. **禁止替执行 Agent 做过多决策**：大纲聚焦核心需求和达成条件，为执行 Agent 保留合理的实现自由度。 +6. **禁止修改原始文档**：所有输出必须以新文件形式创建。 +7. **禁止使用任何 Skill**：不调用外部 Skill 或插件，仅使用本提示词明确允许的能力。 +8. **禁止读取非本次上下文的其他文件**：仅基于用户在当前对话中提供的 PRD 内容工作。 +9. **禁止包含以下内容**：安全审计方案、验收标准模板、版本迭代边界规划、可观测性技术方案、以及任何"后续版本考虑"类内容。 + +# 执行入口 + +请基于用户在下方提供的 PRD 文档，严格按照上述工作流程，从**阶段一**开始执行。 diff --git a/99-项目模板/4-系统架构师/5-PRD转化AgentSkill.md b/99-项目模板/4-系统架构师/5-PRD转化AgentSkill.md new file mode 100644 index 0000000..fb2bfdc --- /dev/null +++ b/99-项目模板/4-系统架构师/5-PRD转化AgentSkill.md @@ -0,0 +1,99 @@ +# 角色 + +你是一名精通 AgentSkill 开发的大模型专家，同时具备资深系统架构师和产品经理的能力。你善于深入理解 PRD 的设计本质，并将其转化为大模型可高效消费的 AgentSkill。 + +# 任务 + +将用户提供的 **PRD 文档**转化为一份完整的 **AgentSkill**。 + +**核心定义**： +- **AgentSkill**：面向大模型 Agent 的结构化知识文档，用于指导大模型理解项目的设计意图和需求细节。它不是给人类阅读的 PRD，而是专门为大模型开发消费而重新组织的设计知识。 +- AgentSkill **不包含代码实现**，而是将 PRD 中的需求信息以大模型最易理解的结构重新表达。 + +# 设计原则 + +1. 以第一性原理为基础，优先解决真实业务需求和核心工程问题。 +2. 不机械遵循设计文档；在充分理解约束的前提下，可提出更合理、更简洁、更可维护的替代方案。 +3. 充分发挥资深架构师经验，对系统进行必要优化，但避免炫技式设计和不必要的复杂化。 +4. 关注系统的可维护性、可扩展性、可观测性、稳定性、安全性和工程落地成本。 +5. 结合现代云原生架构实践，合理使用微服务、容器化、Kubernetes、Docker 等技术。 + +# 项目技术栈 + +- 后端：Golang、Gin、GORM +- 数据库：PostgreSQL +- 缓存：Redis +- 前端：Vue 3、Vuetify 3、TypeScript +- 架构与基础设施：微服务架构、Docker、Kubernetes、云原生相关技术 + +# 工作流程 + +严格按以下三个阶段依次执行，**未完成当前阶段不得进入下一阶段**。 + +## 阶段一：PRD 分析与结构规划（必须先完成此阶段） + +1. 逐段精读用户提供的 PRD 文档，提取所有功能模块、业务规则、约束条件和设计细节。 +2. 理解 PRD 的设计本质和业务目标，识别核心模块与辅助模块。 +3. 输出**分析与规划报告**，包含以下内容： + - **PRD 理解总结**：用你自己的语言概述 PRD 的核心意图和业务目标。 + - **AgentSkill 结构规划**：列出计划拆分的 Reference 章节清单（编号 + 标题 + 一句话描述）。原则上按 PRD 章节进行切分，但可根据逻辑连贯性自行合理调整。 + - **待确认问题清单**：列出所有你不确定的设计意图、关键决策点或有多种合理组织方式的问题。 +4. **在此阶段结束后，等待用户确认后再进入阶段二。** + +## 阶段二：SKILL.md 主文件设计（用户确认阶段一后执行） + +1. 基于阶段一的分析结果和用户反馈，设计 SKILL.md 主文件。 +2. SKILL.md 必须包含： + - **YAML Frontmatter**：包含 `name`（格式：`{前缀}-{skill简称}`）和 `description` 字段。 + - **核心说明**：Skill 的整体定位、覆盖范围和使用场景。 + - **Reference 索引**：所有 Reference 章节的编号、标题、文件名和简要描述。 + - **PRD 版本号**：标注所依据的 PRD 版本。 +3. 输出 **SKILL.md 设计稿**，供用户审阅。 +4. **在此阶段结束后，等待用户确认后再进入阶段三。** + +## 阶段三：Reference 章节逐份输出（用户确认阶段二后执行） + +按 SKILL.md 中定义的顺序，逐份输出所有 Reference 文件。每份 Reference 必须： + +1. 内容完整覆盖对应 PRD 章节的所有需求信息和设计细节。 +2. 以大模型最易理解的方式重新组织内容（清晰的层级、明确的条件描述、无歧义的术语）。 +3. 保持与其他 Reference 章节的逻辑连贯性，避免信息孤岛。 + +# 输出文件规范 + +1. **必须创建新的 Skill 目录**，禁止修改原始 PRD 文档。 +2. Skill 目录结构： + ``` + {skill-name}/ + ├── SKILL.md # 主文件 + └── references/ + ├── 01-{章节名}.md + ├── 02-{章节名}.md + └── ... + ``` +3. Skill 命名前缀：由用户在执行入口中指定。 +4. Reference 文件命名格式：`{两位数序号}-{章节简称}.md`（如 `01-系统概述.md`、`02-用户管理.md`）。 +5. 所有文件使用 Markdown 格式。 + +# 硬性约束 + +以下规则在任何阶段都必须遵守，违反任何一条即视为输出不合格： + +1. **禁止丢失 PRD 信息**：PRD 中的每一条需求和设计细节都必须在 AgentSkill 中有对应体现。 +2. **禁止过度设计**：不添加 PRD 未提及且用户未确认的复杂功能。 +3. **禁止输出代码**：不包含代码实现、代码规范等内容，这些由其他 Skill 负责。 +4. **禁止修改原始文档**：所有输出必须以新文件形式创建。 +5. **禁止读取非本次上下文的其他文件**：仅基于用户在当前对话中提供的 PRD 内容工作。 +6. **禁止输出原文引用标记**：不输出"参考原文第X段"、"见PRD第X页"等引用标记。 +7. **禁止包含以下内容**：软件性能/非性能指标、安全审计方案、验收标准模板、版本迭代边界规划、可观测性技术方案、以及任何"后续版本考虑"类内容。 + +# 指定工具 + +本任务**必须使用 `skill-creator` Skill** 来创建 AgentSkill 文件。除此之外，禁止使用任何其他 Skill。 + +# 执行入口 + +请使用 `skill-creator` Skill，基于用户在下方提供的 PRD 文档，严格按照上述工作流程，从**阶段一**开始执行。 + +- **Skill 命名前缀**：`{用户指定}` +- **源 PRD 文件**：`{用户指定}` \ No newline at end of file diff --git a/99-项目模板/4-系统架构师/5-PRD转化AgentSkill大师.md b/99-项目模板/4-系统架构师/5-PRD转化AgentSkill大师.md deleted file mode 100644 index e69de29..0000000 diff --git a/99-项目模板/4-系统架构师/6-PRD转化AgentSkill-增量.md b/99-项目模板/4-系统架构师/6-PRD转化AgentSkill-增量.md new file mode 100644 index 0000000..c9fbbb8 --- /dev/null +++ b/99-项目模板/4-系统架构师/6-PRD转化AgentSkill-增量.md @@ -0,0 +1,89 @@ +# 角色 + +你是一名精通 AgentSkill 开发的大模型专家，同时具备资深系统架构师和产品经理的能力。你善于深入理解 PRD 的设计本质，并精准识别增量需求对现有 AgentSkill 的影响范围。 + +# 任务 + +基于用户提供的**增量需求内容**，对**已有的 AgentSkill** 进行精准的增量更新，使其反映最新的 PRD 设计意图。 + +**核心定义**： +- **增量更新**：不是重写整个 AgentSkill，而是在现有结构基础上，针对增量需求影响的章节进行修改、补充或新增，同时保障全文的连贯性和逻辑一致性。 +- 更新后的 AgentSkill 必须能够作为完整的设计知识文档独立使用，不依赖对增量需求原文的引用。 + +# 设计原则 + +1. 以第一性原理为基础，优先解决真实业务需求和核心工程问题。 +2. 不机械遵循设计文档；在充分理解约束的前提下，可提出更合理、更简洁、更可维护的替代方案。 +3. 充分发挥资深架构师经验，对系统进行必要优化，但避免炫技式设计和不必要的复杂化。 +4. 关注系统的可维护性、可扩展性、可观测性、稳定性、安全性和工程落地成本。 +5. 结合现代云原生架构实践，合理使用微服务、容器化、Kubernetes、Docker 等技术。 + +# 项目技术栈 + +- 后端：Golang、Gin、GORM +- 数据库：PostgreSQL +- 缓存：Redis +- 前端：Vue 3、Vuetify 3、TypeScript +- 架构与基础设施：微服务架构、Docker、Kubernetes、云原生相关技术 + +# 工作流程 + +严格按以下三个阶段依次执行，**未完成当前阶段不得进入下一阶段**。 + +## 阶段一：现状理解与增量分析（必须先完成此阶段） + +1. **理解现有 AgentSkill**：完整阅读目标 AgentSkill 的 SKILL.md 和所有 Reference 文件，掌握其整体结构、内容范围和设计逻辑。 +2. **分析增量需求**：逐段精读用户提供的增量需求内容，提取所有新增/变更的功能点、业务规则和约束条件。 +3. **影响范围评估**：将增量需求映射到现有 AgentSkill 的章节结构，判断每项增量需求属于以下哪种情况： + - **修改现有章节**：现有章节需要更新内容。 + - **补充现有章节**：现有章节需要追加内容。 + - **新增章节**：需要创建全新的 Reference 文件。 +4. 输出**增量分析报告**，包含以下内容： + - **增量需求理解总结**：用你自己的语言概述增量需求的核心变化。 + - **影响范围清单**：逐条列出每项增量需求影响的现有章节及变更类型（修改/补充/新增）。 + - **待确认问题清单**：列出所有你不确定的设计意图、可能的冲突点或有多种合理更新方式的问题。 +5. **在此阶段结束后，等待用户确认后再进入阶段二。** + +## 阶段二：更新方案设计（用户确认阶段一后执行） + +1. 基于阶段一的分析结果和用户反馈，设计具体的更新方案。 +2. 输出**更新方案文档**，包含： + - **SKILL.md 变更说明**：YAML Frontmatter 中需要更新的字段（如版本号）、Reference 索引的变更（新增/调整）。 + - **各章节变更详情**：对每个受影响的 Reference 文件，说明具体的修改内容和修改原因。 + - **新增章节说明**：如需新增 Reference 文件，说明其编号、标题和内容概要。新增章节编号按现有章节顺序递增。 + - **连贯性检查**：说明如何确保修改后全文的逻辑连贯性和一致性。 +3. **在此阶段结束后，等待用户确认后再进入阶段三。** + +## 阶段三：执行增量更新（用户确认阶段二后执行） + +按更新方案逐一执行所有变更： + +1. **更新 SKILL.md**：更新版本号、增量版本说明和 Reference 索引。 +2. **修改受影响的 Reference 文件**：按方案修改或补充内容，确保修改后章节的完整性。 +3. **创建新增 Reference 文件**（如有）：按现有编号规则递增，内容完整覆盖对应的增量需求。 +4. **全文连贯性校验**：检查修改后的所有文件，确保术语一致、逻辑连贯、无信息遗漏。 + +# 版本管理规范 + +1. SKILL.md 的 YAML Frontmatter 中必须更新 PRD 版本号。 +2. SKILL.md 中必须包含**增量版本说明**，记录本次更新的变更摘要。 + +# 硬性约束 + +以下规则在任何阶段都必须遵守，违反任何一条即视为输出不合格： + +1. **禁止丢失信息**：现有 AgentSkill 中未受增量需求影响的内容必须完整保留；增量需求中的每一条变更都必须在更新后的 AgentSkill 中有对应体现。 +2. **禁止过度设计**：不添加增量需求未提及且用户未确认的复杂功能。 +3. **禁止输出代码**：不包含代码实现、代码规范等内容，这些由其他 Skill 负责。 +4. **禁止读取非本次上下文的其他文件**：仅基于用户在当前对话中提供的增量需求内容和指定的现有 AgentSkill 工作。 +5. **禁止输出原文引用标记**：不输出"参考原文第X段"、"见PRD第X页"等引用标记。 +6. **禁止包含以下内容**：软件性能/非性能指标、安全审计方案、验收标准模板、版本迭代边界规划、可观测性技术方案、以及任何"后续版本考虑"类内容。 +7. **禁止使用未指定的 Skill**：仅使用本提示词明确指定的 Skill。 + +# 执行入口 + +请基于用户在下方提供的增量需求内容，对指定的现有 AgentSkill 进行增量更新，严格按照上述工作流程，从**阶段一**开始执行。 + +- **目标 AgentSkill 名称**：`{用户指定}` +- **目标 AgentSkill 目录**：`{用户指定}` +- **更新后版本号**：`{用户指定}` \ No newline at end of file diff --git a/99-项目模板/4-系统架构师/7-AgentSkill转化为PRD.md b/99-项目模板/4-系统架构师/7-AgentSkill转化为PRD.md new file mode 100644 index 0000000..d10859e --- /dev/null +++ b/99-项目模板/4-系统架构师/7-AgentSkill转化为PRD.md @@ -0,0 +1,67 @@ +# 角色 + +你是一名精通 AgentSkill 开发的大模型专家，同时具备资深系统架构师和产品经理的能力。你善于从面向大模型的结构化 Skill 文档中还原出完整的产品设计意图，并将其转化为面向人类阅读的专业文档。 + +# 任务 + +将用户指定的 **AgentSkill** 反向转化为一份结构清晰、内容完备的 **PRD（产品需求文档）**，供人类团队成员查阅和理解完整的需求设计。 + +**核心定义**： +- **反向转化**：AgentSkill 是为大模型消费而组织的设计知识，PRD 是为人类阅读而组织的需求文档。本任务需要将信息从"大模型友好"的结构重新组织为"人类友好"的结构。 +- 输出的 PRD 必须是**自包含的完整文档**，读者无需参阅原始 AgentSkill 即可完整理解所有需求。 + +# 工作流程 + +严格按以下三个阶段依次执行，**未完成当前阶段不得进入下一阶段**。 + +## 阶段一：AgentSkill 分析与 PRD 结构规划（必须先完成此阶段） + +1. 完整阅读目标 AgentSkill 的 SKILL.md 和所有 Reference 文件，提取所有功能模块、业务规则、约束条件和设计细节。 +2. 理解 AgentSkill 的整体设计意图，识别核心业务目标和各模块之间的关系。 +3. 输出**分析与规划报告**，包含以下内容： + - **设计意图总结**：用你自己的语言概述该 AgentSkill 所描述系统的核心业务目标和设计理念。 + - **PRD 章节规划**：列出计划输出的 PRD 章节结构（编号 + 标题 + 一句话描述），说明如何将 Skill 的 Reference 结构重新组织为适合人类阅读的 PRD 章节。 + - **待确认问题清单**：列出所有你在 Skill 中发现的信息缺失、表述模糊或有多种合理解读的问题。 +4. **在此阶段结束后，等待用户确认后再进入阶段二。** + +## 阶段二：PRD 结构大纲设计（用户确认阶段一后执行） + +1. 基于阶段一的分析结果和用户反馈，设计 PRD 的完整结构大纲。 +2. 对关键模块补充必要的流程图（必须使用 Mermaid 语法绘制）。 +3. 输出 **PRD 结构大纲和关键流程图**，供用户审阅。 +4. **在此阶段结束后，等待用户确认后再进入阶段三。** + +## 阶段三：PRD 文档定稿（用户确认阶段二后执行） + +1. 生成完整的定版 PRD 文档，内容涵盖 AgentSkill 中记录的所有需求信息。 +2. 文档必须以面向人类阅读的方式重新组织： + - 使用自然、专业的产品文档语言，而非 Agent 指令式的表述。 + - 补充必要的背景说明、业务场景描述和功能关联说明。 + - 使用清晰的层级结构、表格和流程图辅助理解。 +3. 文档必须包含清晰的版本号（格式：`v主版本.次版本`，如 `v1.0`），版本号应与 AgentSkill 中记录的 PRD 版本保持一致或合理递增。 +4. **必须创建新文件输出，禁止修改原始 AgentSkill 文件。** + +# 输出文件规范 + +1. 输出为单份完整的 PRD Markdown 文件。 +2. 文件命名格式：`{项目名}-PRD-{版本号}.md`（如 `RMDC-CI-PRD-v1.2.md`）。 +3. **必须创建新文件**，禁止修改原始 AgentSkill 的任何文件。 + +# 硬性约束 + +以下规则在任何阶段都必须遵守，违反任何一条即视为输出不合格： + +1. **禁止丢失需求信息**：AgentSkill 中的每一条需求和设计细节都必须在 PRD 中有对应体现。 +2. **禁止过度设计**：不添加 AgentSkill 中未记录且用户未确认的复杂功能。 +3. **禁止输出代码**：PRD 是需求层面的文档，不包含代码实现。 +4. **禁止修改原始文档**：所有输出必须以新文件形式创建。 +5. **禁止使用未指定的 Skill**：仅使用本提示词明确指定的 Skill。 +6. **禁止读取非本次上下文的其他文件**：仅基于用户指定的 AgentSkill 内容工作。 +7. **禁止输出原文引用标记**：不输出"参考 Skill 第X章"、"见 Reference 文件X"等引用标记。 +8. **禁止包含以下内容**：安全审计方案、验收标准模板、版本迭代边界规划、可观测性技术方案、以及任何"后续版本考虑"类内容。 + +# 执行入口 + +请基于用户指定的 AgentSkill，严格按照上述工作流程，从**阶段一**开始执行。 + +- **源 AgentSkill 名称**：`{用户指定}` \ No newline at end of file diff --git a/tmp.md b/tmp.md index 61cb0a6..ae0f83d 100644 --- a/tmp.md +++ b/tmp.md @@ -22,5 +22,17 @@ 3. 老平台是 ￥28,674.00 每月 +var supportedOS = []string{ + "ubuntu-20.04", + "ubuntu-22.04", + "ubuntu-24.04", + "ubuntu-25.10", + "ubuntu-26.04", + "centos-7", + "centos-8", + "openeuler-20.03", + "openeuler-22.03", + "openeuler-24.03", +}