chore: exclude local dev files from version control
移除仅用于本地开发参考的文件，不入库： - docs/：MVP 方案、原型、架构、需求文档 - CLAUDE.md：Claude Code 项目指令 - AGENTS.md：AI 辅助开发规范
This commit is contained in:
@@ -48,3 +48,8 @@ docker-compose.override.yml
|
||||
|
||||
# Kubernetes secrets (local dev)
|
||||
*-secret.yaml
|
||||
|
||||
# Documentation & local dev config (not tracked in repo)
|
||||
docs/
|
||||
CLAUDE.md
|
||||
AGENTS.md
|
||||
|
||||
@@ -1,43 +0,0 @@
|
||||
# AGENTS.md
|
||||
|
||||
## MVP 实现阶段指南
|
||||
|
||||
在 MVP 实现阶段，解决问题时请遵循以下文档阅读层级（由高到低，只有需要时才往下阅读）：
|
||||
|
||||
### 文档阅读层级
|
||||
|
||||
- **P1 - MVP 方案文档** (`docs/mvp-skeleton-plan.md`)
|
||||
- 项目骨架结构、模块划分、接口定义
|
||||
- 技术实现要点和代码规范
|
||||
- **优先阅读**：大部分问题应首先在此文档中寻找答案
|
||||
|
||||
- **P2 - 原型文档** (`docs/ref/xinfra-prototype.v3.html`)
|
||||
- 完整的页面交互流程和 UI 规范
|
||||
- 组件行为、状态管理、API 调用时机
|
||||
- 异常处理和用户体验细节
|
||||
- **当需要理解具体交互时阅读**
|
||||
|
||||
- **P3 - 架构文档** (`docs/ref/架构文档-v3.md`)
|
||||
- 系统架构设计和技术选型
|
||||
- 模块划分和依赖关系
|
||||
- 数据流向和接口规范
|
||||
- **当需要理解整体架构时阅读**
|
||||
|
||||
- **P4 - 需求文档** (`docs/ref/平台需求文档-v3.md`)
|
||||
- 平台整体需求和功能范围
|
||||
- 用户故事和验收标准
|
||||
- **当需要明确需求范围时阅读**
|
||||
|
||||
### 实现原则
|
||||
|
||||
- **先读文档，再看代码**：理解设计意图后再动手实现
|
||||
- **层级优先**：P1 能解决的问题不要去看 P2、P3、P4
|
||||
- 严格遵循 MVP 文档中定义的目录结构和模块划分
|
||||
- 参考原型文档中的交互流程和状态管理
|
||||
- 保持代码简洁，聚焦 MVP 核心功能
|
||||
- 遵循项目既定的技术栈和编码规范
|
||||
|
||||
### Git 操作规范
|
||||
|
||||
- **禁止自动提交**：除非用户明确指示，否则不要执行 `git commit`
|
||||
- **Commit Message**：使用多行格式，包含 type、scope、subject 和详细 body
|
||||
@@ -1,43 +0,0 @@
|
||||
# CLAUDE.md
|
||||
|
||||
## MVP 实现阶段指南
|
||||
|
||||
在 MVP 实现阶段，解决问题时请遵循以下文档阅读层级（由高到低，只有需要时才往下阅读）：
|
||||
|
||||
### 文档阅读层级
|
||||
|
||||
- **P1 - MVP 方案文档** (`docs/mvp-skeleton-plan.md`)
|
||||
- 项目骨架结构、模块划分、接口定义
|
||||
- 技术实现要点和代码规范
|
||||
- **优先阅读**：大部分问题应首先在此文档中寻找答案
|
||||
|
||||
- **P2 - 原型文档** (`docs/ref/xinfra-prototype.v3.html`)
|
||||
- 完整的页面交互流程和 UI 规范
|
||||
- 组件行为、状态管理、API 调用时机
|
||||
- 异常处理和用户体验细节
|
||||
- **当需要理解具体交互时阅读**
|
||||
|
||||
- **P3 - 架构文档** (`docs/ref/架构文档-v3.md`)
|
||||
- 系统架构设计和技术选型
|
||||
- 模块划分和依赖关系
|
||||
- 数据流向和接口规范
|
||||
- **当需要理解整体架构时阅读**
|
||||
|
||||
- **P4 - 需求文档** (`docs/ref/平台需求文档-v3.md`)
|
||||
- 平台整体需求和功能范围
|
||||
- 用户故事和验收标准
|
||||
- **当需要明确需求范围时阅读**
|
||||
|
||||
### 实现原则
|
||||
|
||||
- **先读文档，再看代码**：理解设计意图后再动手实现
|
||||
- **层级优先**：P1 能解决的问题不要去看 P2、P3、P4
|
||||
- 严格遵循 MVP 文档中定义的目录结构和模块划分
|
||||
- 参考原型文档中的交互流程和状态管理
|
||||
- 保持代码简洁，聚焦 MVP 核心功能
|
||||
- 遵循项目既定的技术栈和编码规范
|
||||
|
||||
### Git 操作规范
|
||||
|
||||
- **禁止自动提交**：除非用户明确指示，否则不要执行 `git commit`
|
||||
- **Commit Message**：使用多行格式，包含 type、scope、subject 和详细 body
|
||||
@@ -1,6 +0,0 @@
|
||||
# 项目文档目录
|
||||
|
||||
存放项目相关文档：
|
||||
- mvp-skeleton-plan.md: MVP 方案文档，定义代码骨架和实现要点
|
||||
- api.md: API 接口文档
|
||||
- deployment.md: 部署文档
|
||||
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
@@ -1,429 +0,0 @@
|
||||
# XINFRA 平台需求文档
|
||||
|
||||
## 概述
|
||||
|
||||
XINFRA 是面向多业务线、七机房混合云的统一基础设施管理平台，为 Kodo、LAS、灵矽、LTOKEN、MAAS 等业务线提供容器资源调度、基础服务交付、资源台账、监控告警、配置管理的一站式操作面。
|
||||
|
||||
**核心目标**：
|
||||
|
||||
| # | 目标 | 说明 |
|
||||
|---|------|------|
|
||||
| 1 | 统一纳管 | 所有基础设施操作收敛到平台化界面，屏蔽多机房、多云差异，降低命令行直接操作风险 |
|
||||
| 2 | 多机房资源池化 | 七机房 RKE2 集群统一纳管，实现跨机房调度与服务发现 |
|
||||
| 3 | 标准化交付 | 基础组件（MySQL、Redis 等）通过服务卡片 + Ansible Playbook 实现一键标准化部署 |
|
||||
| 4 | 安全合规 | 主系统登录与运维操作全程审计、SQL 上线必须经过审核、LDAP 统一认证与 SSO |
|
||||
| 5 | 效率提升 | CD 自动化部署，Ansible 实现基础设施即代码，任务中心实时追踪 |
|
||||
| 6 | 可观测性 | 整合 Zabbix + VictoriaMetrics + Nightingale + qpass，资源大盘与监控告警全局可见 |
|
||||
|
||||
**设计原则**：
|
||||
|
||||
- **最小权限**：子系统操作默认走 RBAC，主系统以 LDAP 身份 + 管理员角色区分权限，APIKey 遵循最小授权范围
|
||||
- **审计留痕**：主系统记录登录事件和运维操作日志，子系统各自维护操作审计
|
||||
- **机房就近**：服务部署和数据访问遵循机房就近原则，降低跨机房延迟
|
||||
- **平台化自治**：自助申请资源、自助发布、自助诊断，减少人工工单流转
|
||||
- **复用优先**：监控、告警等能力优先复用已有基础设施（VictoriaMetrics / Grafana / Zabbix / Nightingale），主系统只自建无法被替代的能力
|
||||
- **数据一致性**：资源同步采用"已存在跳过更新"策略，保护人工维护的资产数据，防止被云平台同步覆盖
|
||||
|
||||
---
|
||||
|
||||
## 角色模型
|
||||
|
||||
主系统采用**二维角色模型**：权限维度 × 业务线维度。
|
||||
|
||||
### 权限维度
|
||||
|
||||
| 权限角色 | 权限范围 |
|
||||
|---------|---------|
|
||||
| 超级管理员 | 全平台所有模块的读写权限，包括集群管理、运维终端、账号权限管理、审计全局查看 |
|
||||
| 业务操作员 | 本业务线内资源的申请、部署、配置变更；可操作 Wayne/CloudDM/CacheCloud/Apollo 中本业务线的资源 |
|
||||
| 日志操作员 | 本业务线的日志查看、告警查看、审计记录查看；无写入/变更权限 |
|
||||
| 访客 | 只读查看资源大盘、服务目录、告警概览；不可执行任何操作 |
|
||||
|
||||
### 业务线维度
|
||||
|
||||
| 业务线 | 说明 |
|
||||
|--------|------|
|
||||
| Kodo | 七牛云存储 |
|
||||
| LAS | 七牛云直播 |
|
||||
| 灵矽 | 七牛云 IoT |
|
||||
| LTOKEN | 七牛云 Token 服务 |
|
||||
| MAAS | 七牛云模型即服务 |
|
||||
|
||||
### 权限矩阵
|
||||
|
||||
| 模块 | 超级管理员 | 业务操作员 | 日志操作员 | 访客 |
|
||||
|------|-----------|-----------|-----------|------|
|
||||
| 资源大盘 | ✓ 全局 | ✓ 本业务线 | ✓ 本业务线 | ✓ 全局只读 |
|
||||
| 告警看板 | ✓ 全局 | ✓ 本业务线 | ✓ 本业务线 | ✓ 只读 |
|
||||
| 集群与节点管理 | ✓ 读写 | ○ 只读 | ○ 只读 | ✗ |
|
||||
| 多租户管理 | ✓ 读写 | ✗ | ✗ | ✗ |
|
||||
| Wayne 部署 | ✓ 读写 | ✓ 本业务线 | ○ 只读 | ✗ |
|
||||
| CloudDM SQL 审核 | ✓ 读写 | ✓ 本业务线 | ○ 只读 | ✗ |
|
||||
| CacheCloud 缓存 | ✓ 读写 | ✓ 本业务线 | ○ 只读 | ✗ |
|
||||
| Apollo 配置 | ✓ 读写 | ✓ 本业务线 | ○ 只读 | ✗ |
|
||||
| 任务中心 | ✓ 全局 | ✓ 本业务线 | ✓ 本业务线 | ✗ |
|
||||
| 资源台账 | ✓ 读写 | ○ 只读 | ○ 只读 | ✗ |
|
||||
| 审计面板 | ✓ 全局 | ✗ | ✓ 本业务线 | ✗ |
|
||||
| 运维终端 | ✓ 仅管理员 | ✗ | ✗ | ✗ |
|
||||
|
||||
> ✓ = 读写权限，○ = 只读权限，✗ = 无权限
|
||||
|
||||
---
|
||||
|
||||
## 功能需求
|
||||
|
||||
### Phase 1 — MVP（当前阶段）
|
||||
|
||||
> 最小可用集：多租户认证 + 子系统对接
|
||||
|
||||
#### 1.1 平台基础能力
|
||||
|
||||
##### 统一子系统导航
|
||||
|
||||
> 作为所有相关子系统的单一入口门户，利用 LDAP 统一账号实现 SSO，用户无需记忆多个地址和重复认证。
|
||||
|
||||
- [ ] P0 — 已集成系统卡片展示：系统图标、名称、简要说明及 LDAP/SSO 接入状态（已接入/改造中），预留打开链接
|
||||
- [ ] P0 — 已集成系统包括：Wayne、CloudDM、CacheCloud、qpass、Grafana、Apollo
|
||||
- [ ] P0 — SSO 跳转：点击卡片通过 LDAP SSO 跳转至对应子系统，无需重复登录
|
||||
|
||||
---
|
||||
|
||||
##### 审计面板（主系统）
|
||||
|
||||
> 记录主系统自身的登录事件和运维操作日志，不聚合子系统操作审计。
|
||||
|
||||
- [ ] P0 — 登录审计：记录每次 LDAP SSO 登录事件（操作人、时间、来源 IP、目标子系统），支持按时间/操作人/子系统筛选查询
|
||||
- [ ] P0 — 运维操作审计：记录主系统运维终端的操作（Ansible Playbook 执行、节点加入、配置变更等），支持按时间/操作人/操作类型筛选
|
||||
- [ ] P0 — 权限控制：管理员角色可查看全局；普通用户仅查看自身登录记录
|
||||
- [ ] P0 — 审计面板集成到主系统统一门户，无需独立部署
|
||||
|
||||
---
|
||||
|
||||
#### 1.2 子系统对接
|
||||
|
||||
##### Wayne — 容器编排与多集群管理
|
||||
|
||||
> 底层基于 RKE2 构建七机房 K8s 集群，上层通过 Wayne 平台提供统一的容器管理入口。开发人员通过 Wayne UI 或 API 完成服务部署，无需直接操作 kubectl。
|
||||
|
||||
**RKE2 集群约束**（基础设施依赖）：
|
||||
|
||||
| 约束项 | 说明 |
|
||||
|--------|------|
|
||||
| CNI 插件 | Calico BGP（每集群独立 AS 号） |
|
||||
| 容器运行时 | containerd（不依赖 Docker） |
|
||||
| 离线部署 | 支持 Air-gap 环境 |
|
||||
| 集群规模 | 七机房各一套独立集群 |
|
||||
| 安全加固 | 已通过 CIS Benchmark，默认启用加密和审计 |
|
||||
|
||||
**Wayne 多集群管理**：
|
||||
|
||||
- [ ] P0 — 支持多集群统一管理，通过 Client-Go 连接各机房 RKE2 集群
|
||||
- [ ] P0 — 提供表单式（基础模式）和 YAML/JSON 编辑（高级模式）两种 K8s 对象创建方式
|
||||
- [ ] P0 — 发布历史记录与一键回滚能力
|
||||
- [ ] P0 — 完整审计模块，每次操作留痕，支持自定义 Webhook 回调
|
||||
- [ ] P0 — APIKey 开放接口，支持 CI/CD 流水线调用
|
||||
- [ ] P0 — 认证支持 DB 内置 + LDAP 混合模式
|
||||
|
||||
---
|
||||
|
||||
##### CloudDM / open-cdm — 数据库管理与 SQL 审核
|
||||
|
||||
> 覆盖数据查询、权限管控、SQL 审核、数据脱敏的全链路能力。所有生产库 SQL 操作必须经过工单流程，无直连通道。
|
||||
|
||||
- [ ] P0 — 支持 Console + Sidecar 集群部署模式，保证高可用
|
||||
- [ ] P0 — 支持 20+ 数据源类型（MySQL、Oracle、PG、ClickHouse、Redis、MongoDB 等）
|
||||
- [ ] P0 — 内置 54 条 SQL 审核规则，支持规则脚本自定义扩展
|
||||
- [ ] P0 — SQL 上线工单流程：编写 → 预检 → DBA 审核 → 执行，支持手动/立即/定时三种执行方式
|
||||
- [ ] P0 — 权限控制：资源权限（实例/库/Schema/表粒度）+ 功能权限（RBAC），支持申请/赋予/临时权限
|
||||
- [ ] P1 — 数据脱敏能力，对查询结果中的敏感字段进行隐藏或转换
|
||||
- [ ] P1 — 数据库 CI/CD：支持 Git Push / WebHook / HttpCall 三种触发方式
|
||||
- [ ] P0 — 统一认证：对接企业 LDAP
|
||||
- [ ] P0 — 全程审计留痕，工单流转记录可追溯
|
||||
|
||||
---
|
||||
|
||||
##### CacheCloud — 缓存管理
|
||||
|
||||
> 支持 Standalone、Sentinel、Cluster 三种 Redis 架构的一站式管理。所有 Redis 场景通过 CacheCloud 统一实例申请和管理。
|
||||
|
||||
- [ ] P0 — 支持三种 Redis 架构：Standalone（测试）、Sentinel（生产常规，内存 ≤ 6GB）、Cluster（大数据量，内存 > 6GB）
|
||||
- [ ] P0 — Agent 代理部署在每个宿主机上，管理 Redis 实例生命周期
|
||||
- [ ] P0 — 接入层 Nginx 双机房部署 + Virtual IP 双向漂移，保证高可用
|
||||
- [ ] P0 — 客户端接入支持 REST API（通用）、Java Jedis/Lettuce SDK、Python 接入
|
||||
- [ ] P1 — 跨机房部署（Cross-Room）：支持双活，客户端 SDK 自动双写双读和机房切换
|
||||
- [ ] P0 — 运维能力：全局统计、工单审批、应用运维、实例运维、数据迁移
|
||||
- [ ] P1 — 诊断工具：慢查询分析、连接数诊断、Bigkey 检测
|
||||
- [ ] P0 — 报警组件：支持邮件、微信、HTTP 接口集成
|
||||
- [ ] P1 — 临时实例自动回收策略，防止资源浪费
|
||||
|
||||
---
|
||||
|
||||
##### Apollo — 配置中心管理
|
||||
|
||||
> 对 Apollo 配置中心进行统一接入和管理，实现在单一 Portal 管理所有机房的配置，确保配置的灰度发布、回滚与变更审计。
|
||||
|
||||
- [ ] P0 — 核心指标展示：已接入机房数、Apollo Cluster 数量、配置项总数、Namespace 数、接入业务线及同步状态
|
||||
- [ ] P0 — 统一入口：提供 Apollo Portal 快捷入口（内部域名 `apollo.xinfra.internal`），LDAP SSO 单点登录
|
||||
- [ ] P0 — 机房列表：展示每个机房的 Apollo Cluster、Config Service 地址、承载方式（容器化 K8s Service）、接入业务线和配置项数、运行状态（运行中/灰度接入/建设中/待启动）
|
||||
|
||||
**部署架构约束**：
|
||||
- Portal + Admin Service：YZH 主中心统一部署
|
||||
- Config Service：按机房独立部署（yzh/xs/jf/dallas 等），容器化运行在 K8s 内
|
||||
- 数据同步：ConfigDB/PortalDB 部署在 YZH，各机房 Config Service 本地缓存全量配置，网络抖动时降级提供本地缓存
|
||||
|
||||
---
|
||||
|
||||
##### CD 自动化部署
|
||||
|
||||
> 通过 API 接口触发 Wayne 平台执行自动化部署，CI 部分由团队已有 CI 系统负责。
|
||||
|
||||
- [ ] P0 — 提供 REST API 接口，供外部 CI 系统调用触发 Wayne 部署，传入镜像 tag 和目标环境
|
||||
- [ ] P0 — 部署支持多环境（dev / staging / prod），生产环境需审批卡点
|
||||
- [ ] P1 — 部署失败时支持自动回滚到上一个稳定版本
|
||||
- [ ] P1 — 部署状态回调：支持 Webhook 回调通知外部 CI 系统部署结果
|
||||
|
||||
> [!info] CI 编译构建由团队已有 CI 系统负责，本平台仅提供 CD 部署接口。
|
||||
|
||||
---
|
||||
|
||||
|
||||
|
||||
|
||||
### Phase 2 — 完整版
|
||||
|
||||
> 监控、配置、任务、基础服务交付的完整能力
|
||||
|
||||
#### 2.1 监控与可观测性
|
||||
|
||||
##### 资源大盘
|
||||
|
||||
> 为平台管理员及业务负责人提供跨机房、多云容器资源的全局快照与健康视图。
|
||||
|
||||
- [ ] P0 — 展示核心指标：RKE2 集群数量、在线机房数、节点总数及近期增量、CPU 总核数/已分配/分配率、组件实例总数及分类（MySQL、Redis、其他）、进行中的自动化任务数量
|
||||
- [ ] P0 — 集群拓扑：以机房为维度，显示各机房节点池方格图（node grid），每个方格代表一台物理机/节点，颜色区分业务线（Kodo、LAS 等），空闲节点用虚线框表示
|
||||
- [ ] P0 — 最近任务：列表展示最近 5 条 ansible-playbook 任务的执行状态（成功/执行中/失败）和耗时，快速跳转至任务中心
|
||||
- [ ] P1 — 刷新机制：页面自动显示"最近更新于 xx 秒前"，支持手动刷新
|
||||
|
||||
---
|
||||
|
||||
##### 资源状态看板与告警
|
||||
|
||||
> 整合物理机、虚机、基础服务三层的健康状态，通过夜莺（Nightingale）统一告警引擎将多源告警标准化展示，提供自上而下的故障定位入口。
|
||||
|
||||
数据源：
|
||||
- 物理机硬件 & 网络设备健康：Zabbix（IPMI/温度/电源/风扇/存储）
|
||||
- 虚机 & 容器 & 业务层指标：VictoriaMetrics（K8s/主机指标/服务可用性探活）
|
||||
- Nightingale 作为统一告警聚合层，负责去重、收敛、分级（P0/P1/…），按 disaster/high/average 等原始级别映射，推送至 qpass 告警通道
|
||||
|
||||
- [ ] P0 — 核心统计：物理机总数、虚机总数、基础组件实例总数；P0(Disaster)、P1(High) 及 average 级别告警数量，标注来自 Zabbix 或 VictoriaMetrics
|
||||
- [ ] P0 — 物理机状态：按机房汇总在线数、健康率（带进度条），标识正常/告警/严重状态
|
||||
- [ ] P0 — 虚机状态：按业务线展示 LAS 资源池中的虚机数、CPU 均值及告警状态
|
||||
- [ ] P0 — 基础服务状态：覆盖 MySQL、Redis（CacheCloud）、PostgreSQL、openresty 网关等，显示实例数、异常数、可用率
|
||||
- [ ] P0 — 当前告警详情：表格列出所有 P0/P1 及 average 级别的实时告警，含级别标签、来源、原始级别、目标对象、告警内容、发生时间
|
||||
|
||||
---
|
||||
|
||||
##### 监控、日志与告警集成
|
||||
|
||||
> 集成公司现有监控与日志基础设施的状态和主要入口，方便从平台直接掌握各子系统健康度。
|
||||
|
||||
- [ ] P0 — VictoriaMetrics 指标概览：展示七机房采集节点数、活跃时序数量、Prometheus 接口状态、已建 Grafana 仪表盘数
|
||||
- [ ] P0 — Zabbix 硬件监控：物理机监控覆盖率、当前告警数、网络设备健康度、存储健康度
|
||||
- [ ] P1 — 统一日志与告警流水：以实时日志流形式展示关键系统事件（CMDB 同步、Zabbix 告警、VictoriaMetrics 抓取、ELK 日志接入、qpass 合并推送），类似运维公告板
|
||||
|
||||
---
|
||||
|
||||
#### 2.2 配置与任务管理
|
||||
|
||||
##### 任务中心与自动化执行
|
||||
|
||||
> 集中展现所有通过 xinfra 发起的 Ansible Playbook 任务或 Wayne 发布任务的执行历史，提供实时日志输出。
|
||||
|
||||
- [ ] P0 — 任务列表：任务状态（执行中/成功/失败）、任务名称、所用 playbook 名称或任务描述；执行中的任务高亮显示
|
||||
- [ ] P0 — 实时日志：通过 WebSocket 流式输出 ansible-playbook 的执行日志，格式包含时间戳、TASK 名称和结果状态（ok/changed/failed），模拟终端输出效果，支持自动滚动
|
||||
- [ ] P0 — 历史查询：任务列表支持分页，可查看过往所有任务的执行结果，便于审计和排障
|
||||
|
||||
---
|
||||
|
||||
#### 2.3 基础服务与资源管理
|
||||
|
||||
##### 集群与节点管理
|
||||
|
||||
> 管理全平台 RKE2 集群的生命周期及节点信息，支持新节点的自动加入。
|
||||
|
||||
- [ ] P0 — 集群列表：展示集群名称、所在机房/区域、健康状态、节点数、CPU 使用率（进度条）、RKE2 版本、Calico 配置（AS 号等）；对存在告警的集群高亮提醒
|
||||
- [ ] P0 — 节点列表（集群内）：节点主机名、内网 IP、业务线标签（如 `business-line=kodo`）及对应 Taint、节点规格（CPU/内存）、CPU/Mem 使用率（进度条）、节点状态（Ready/资源告警/空闲）
|
||||
- [ ] P0 — 节点加入向导：通过弹窗交互完成新节点加入——选择目标集群 → 输入节点 IP → 指定归属业务线（自动注入 node-label 和 taint）→ 提交后后台调用 `roles/rke2-node-join` playbook，完成内核参数初始化、containerd 安装、标签/污点写入、加入集群并等待 Ready
|
||||
|
||||
---
|
||||
|
||||
##### 资源台账管理（CMDB 多云同步）
|
||||
|
||||
> 以 SINA CMDB 为基础数据底座，统一纳管物理机与虚机资源，并通过阿里云、AWS、七牛 LAS 的 OpenAPI 同步云上虚机，形成全量、唯一、可追溯的资源台账。
|
||||
|
||||
- [ ] P0 — 资源来源统计：资源总数（物理机 + 虚机），各来源（SINA CMDB、阿里云同步、AWS 同步、七牛 LAS 同步）的数量及最近一次同步状态
|
||||
- [ ] P0 — 资源台账列表：主机名、资产编号、资源类型（物理机/虚机）、机房/区域、内网 IP、规格、归属业务线、数据来源标签、生命周期状态（production/idle/retired）
|
||||
- [ ] P0 — 组合筛选：支持按资源类型、数据来源、业务线、状态等条件组合筛选，以及关键字搜索
|
||||
- [ ] P0 — 同步与去重策略：各云平台定时增量同步，已存在记录跳过更新（保护 CMDB 人工维护字段），不存在则新增并标记来源
|
||||
- [ ] P1 — 创建虚机入口：提供"+ 创建虚机"按钮，跳转或触发七牛 LAS 平台的虚机申请/创建流程（对接 LAS API）
|
||||
|
||||
---
|
||||
|
||||
##### 服务目录管理（Consul 同步）
|
||||
|
||||
> 聚合各机房已有的 Consul 注册中心服务信息，提供跨机房的服务名、IP、业务标签、健康状态的统一检索视图，不改变各机房 Consul 自身的注册发现链路。
|
||||
|
||||
- [ ] P0 — 同步机制：定时调用各机房 Consul Catalog API（`/v1/catalog/services`、`/v1/health/service`），按 Datacenter 维度拉取全量服务并汇总入库。同步间隔采用差异化策略：国内机房（YZH/XS/JF）30 秒，海外机房（达拉斯/新加坡/香港/东南亚）根据网络延迟适当延长（建议 60-120 秒），具体间隔待实测后确定
|
||||
- [ ] P0 — 服务台账：服务名、所在机房/Datacenter、业务标签、总实例数、健康实例数、示例 IP、整体健康状态
|
||||
- [ ] P0 — 筛选与搜索：支持按机房、业务标签、健康状态筛选，以及服务名/IP 搜索
|
||||
- [ ] P0 — 统计面板：接入 Consul Datacenter 数量、服务总数（去重）、服务实例总数、健康实例占比、最近同步状态
|
||||
|
||||
---
|
||||
|
||||
##### 基础服务目录与一键部署
|
||||
|
||||
> 将标准化基础组件封装为服务卡片，用户通过界面选择参数，后台调用 Ansible Playbook 自动完成部署和子系统注册。
|
||||
|
||||
服务卡片规格：
|
||||
|
||||
| 服务 | 可配参数 | 部署后自动注册 |
|
||||
|------|---------|--------------|
|
||||
| MySQL | 业务线、架构模式（一主两从/一主一从/单实例）、规格（CPU/内存/磁盘）、版本（8.0/5.7）、实例名称 | open-cdm 数据源 |
|
||||
| Redis | 业务线、架构模式（Cluster/Sentinel/Standalone）、规格（8G/16G 等）、版本（7.2）、实例名称 | CacheCloud 应用创建 API |
|
||||
| openresty | 业务线、规格、路由规则 | — |
|
||||
| dpvs | 业务线、规格、负载策略 | — |
|
||||
| PgSQL | 业务线、架构模式（流复制主从）、规格、版本 | open-cdm（二期） |
|
||||
|
||||
- [ ] P0 — 服务卡片展示：每个基础组件以卡片形式展示，点击弹出多步骤向导（基础信息 → 规格网络 → 确认部署）
|
||||
- [ ] P0 — 参数预览：底部实时预览生成的 playbook 调用参数（YAML 格式）
|
||||
- [ ] P0 — 自动注册：部署完成后自动调用子系统 API 完成注册（MySQL → open-cdm，Redis → CacheCloud）
|
||||
- [ ] P1 — 扩展性：预留"接入新服务"卡片，允许通过封装新的 Ansible Playbook 并注册到平台扩展服务目录
|
||||
|
||||
---
|
||||
|
||||
##### 组件实例台账
|
||||
|
||||
> 提供所有已部署基础组件的统一台账，展示实例与子系统的关联关系，支持快速检索和运维管理。
|
||||
|
||||
- [ ] P0 — 列表信息：实例名、组件类型及版本、归属业务线、所在集群、运行状态、子系统注册状态（如 `open-cdm ✓`、`CacheCloud ✓` 或同步中）
|
||||
- [ ] P0 — 管理操作：提供"管理"快捷操作，可跳转至对应子系统或发起运维任务
|
||||
- [ ] P0 — 分页与搜索：支持按实例名称、类型等过滤，分页能力
|
||||
|
||||
---
|
||||
|
||||
#### 2.4 Phase 2 验收标准
|
||||
|
||||
- [ ] 资源大盘：页面加载后 3s 内展示全局指标数据；节点方格图能正确反映各业务线的资源分布
|
||||
- [ ] 告警看板：告警数据与 Nightingale 实时同步，延迟 < 30s；支持按级别、来源、机房筛选告警
|
||||
- [ ] 集群管理：集群列表数据实时刷新，告警集群高亮标识
|
||||
- [ ] 节点加入：节点加入向导从提交到 Ready < 10 分钟
|
||||
- [ ] CMDB 同步：同步后资源台账与各云平台实际资源一致，去重逻辑验证通过
|
||||
- [ ] Consul 同步：7 个 Datacenter 全部接入；国内机房数据 30 秒内同步
|
||||
- [ ] 基础服务部署：MySQL 一键部署单实例 < 5 分钟；Redis 一键部署 Standalone < 3 分钟
|
||||
- [ ] 任务中心：执行中任务日志实时推送，延迟 < 1s
|
||||
- [ ] 部署回滚：回滚操作可在 1 分钟内完成
|
||||
|
||||
---
|
||||
|
||||
### Phase 3 — 运维增强
|
||||
|
||||
> etcd 集群运维、高级监控、运维工具
|
||||
|
||||
#### 3.1 etcd 集群运维
|
||||
|
||||
##### etcd 集群部署（kubeadm + etcd operator）
|
||||
|
||||
- [ ] P0 — 集群模板：支持按规格（3/5/7 节点）、磁盘类型（NVMe/SSD）、存储配额生成部署配置
|
||||
- [ ] P0 — 部署流程：调用 kubeadm init / etcd-operator API，支持滚动部署和健康检查
|
||||
- [ ] P1 — 故障恢复：检测到节点故障时自动替换，数据从健康节点同步
|
||||
- [ ] P1 — 滚动升级：支持 etcd 版本升级，逐节点替换并验证
|
||||
- [ ] P2 — 自动扩缩：根据集群负载自动调整节点数
|
||||
|
||||
---
|
||||
|
||||
#### 3.2 高级监控
|
||||
|
||||
- [ ] P1 — 告警规则自定义：支持用户自定义监控告警规则
|
||||
- [ ] P2 — 异常检测：基于历史数据的智能异常检测
|
||||
- [ ] P2 — 容量预测：基于趋势预测资源使用峰值
|
||||
|
||||
---
|
||||
|
||||
#### 3.3 运维工具
|
||||
|
||||
- [ ] P2 — 可视化拓扑：服务依赖关系可视化
|
||||
- [ ] P1 — 批量操作：支持批量节点管理、批量配置下发
|
||||
- [ ] P2 — 运维工作流：复杂运维操作的流程编排
|
||||
|
||||
---
|
||||
|
||||
#### 3.4 Phase 3 验收标准
|
||||
|
||||
- [ ] etcd 部署：3 节点集群部署 < 15 分钟
|
||||
- [ ] 故障恢复：节点故障后自动替换，数据不丢失
|
||||
- [ ] 滚动升级：升级过程零停机
|
||||
- [ ] 告警规则：用户可自定义告警规则并生效
|
||||
|
||||
---
|
||||
|
||||
## 非功能需求
|
||||
|
||||
### 性能
|
||||
|
||||
| 指标 | 要求 |
|
||||
|------|------|
|
||||
| 资源大盘加载 | P95 < 3s |
|
||||
| Wayne 页面操作响应 | P95 < 2s |
|
||||
| CloudDM SQL 审核预检 | 单条 SQL < 3s |
|
||||
| CacheCloud 实例创建 | Sentinel < 5min，Cluster < 10min |
|
||||
| 基础服务一键部署 | MySQL/Redis < 15min |
|
||||
| 任务中心日志推送延迟 | < 1s |
|
||||
| CI/CD 流水线端到端（代码提交到部署完成） | < 10min（dev 环境） |
|
||||
|
||||
### 可用性
|
||||
|
||||
| 指标 | 要求 |
|
||||
|------|------|
|
||||
| 平台核心服务（Wayne、CloudDM、CacheCloud） | SLA ≥ 99.9% |
|
||||
| 单集群控制面 | SLA ≥ 99.95% |
|
||||
| 跨机房网络互联 | SLA ≥ 99.99% |
|
||||
| Apollo Config Service（单机房故障不影响其他机房） | 本地缓存降级可用 |
|
||||
|
||||
### 多租户隔离
|
||||
|
||||
- 通过节点标签 + Taint + ResourceQuota 实现业务线间的资源强隔离和配额限制
|
||||
- 同一业务线内通过 LimitRange 限制单 Pod 资源上限
|
||||
|
||||
### 安全
|
||||
|
||||
- 平台强制 LDAP 认证，所有子系统通过 SSO 统一入口
|
||||
- 主系统登录事件与运维操作全程记录审计日志
|
||||
- 敏感数据（Secret、密码）加密存储
|
||||
- 生产环境禁止使用默认凭证
|
||||
- RKE2 默认启用安全审计和加密
|
||||
- 网络平面通过 BGP 和防火墙控制
|
||||
|
||||
### 高可用与容灾
|
||||
|
||||
- 每个机房独立 RKE2 集群和 Apollo Config Service，单机房故障不影响其他机房
|
||||
- 配置下发依赖本地缓存降级
|
||||
- 监控告警具备跨机房聚合能力
|
||||
|
||||
### 可观测性
|
||||
|
||||
- 各子系统暴露 Metrics 接口，接入 VictoriaMetrics + Grafana
|
||||
- 关键操作日志统一收集到 ELK 日志平台
|
||||
- 告警通道统一（Nightingale → qpass → 企业 IM）
|
||||
|
||||
### 可扩展性
|
||||
|
||||
- 基础服务目录支持通过封装新 Playbook 快速接入新组件
|
||||
- 资源管理支持新增云平台同步源
|
||||
- 服务管理可横向扩展至更多 Consul 数据中心
|
||||
- 新机房接入时，RKE2 集群部署和 Wayne 注册可在 1 天内完成
|
||||
|
||||
### 实时性
|
||||
|
||||
- 任务日志通过 WebSocket 实时推送
|
||||
- 监控指标和告警近实时更新
|
||||
- 服务同步间隔 30 秒
|
||||
-1008
File diff suppressed because it is too large
Load Diff
Reference in New Issue
Block a user