From a8f73b04f965a86cd8431bdee60b285f8ef0e298 Mon Sep 17 00:00:00 2001 From: hezhaohui Date: Thu, 16 Jul 2026 15:38:52 +0800 Subject: [PATCH] vault backup: 2026-07-16 15:38:52 --- weekly/daily/2026-07-15-daily.md | 41 +++ xinfra/requirements.md | 531 +++++++++---------------------- 2 files changed, 191 insertions(+), 381 deletions(-) create mode 100644 weekly/daily/2026-07-15-daily.md diff --git a/weekly/daily/2026-07-15-daily.md b/weekly/daily/2026-07-15-daily.md new file mode 100644 index 0000000..0a2e3fd --- /dev/null +++ b/weekly/daily/2026-07-15-daily.md @@ -0,0 +1,41 @@ +--- +tags: [daily] +create time: 2026-07-15 17:51 +--- + +# 2026-07-15 日报 + +## 今日完成 +1. 实现后端统一 JSON 响应格式与业务错误码体系，新增 recovery/logger 中间件；前端对接泛型类型，请求拦截器自动映射错误码为中文提示（PR#55） +2. 集成 Swagger API 文档并配置动态 host，重构路由至独立 router 包，新增 make swagger 命令（PR#57） +3. 配合推进 authserver 合并（PR#67） +4. 前端代码清理：移除已废弃的 baseUrl 配置（PR#58）及 useTheme 中未使用的 watch 导入（PR#76） + +## GitHub Issues +当日无关联 Issue + +## GitHub PR +已合并： +- PR#55 feat: 实现后端统一响应格式与前端错误处理增强 +- https://github.com/1024XEngineer/xinfra/pull/55 + +- PR#57 feat(server): 集成 Swagger API 文档，重构路由模块 +- https://github.com/1024XEngineer/xinfra/pull/57 + +- PR#67 feat: 前端主题系统重构与后端 authserver 合并 +- https://github.com/1024XEngineer/xinfra/pull/67 + +- PR#58 fix(frontend): 移除已弃用的 baseUrl 配置 +- https://github.com/1024XEngineer/xinfra/pull/58 + +- PR#76 fix(frontend): 移除 useTheme 中未使用的 watch 导入 +- https://github.com/1024XEngineer/xinfra/pull/76 + +## 卡点 / 阻塞 +当前无卡点 + +## 明日计划 +1. 待确认 + +## 备注 +无 diff --git a/xinfra/requirements.md b/xinfra/requirements.md index 0b18585..e611600 100644 --- a/xinfra/requirements.md +++ b/xinfra/requirements.md @@ -7,468 +7,237 @@ create time: 2026-07-08 13:54 ## 概述 -XINFRA 是面向多业务线、七机房混合云的统一基础设施管理平台，为 Kodo、LAS、灵矽、LTOKEN、MAAS 等业务线提供容器资源调度、基础服务交付、资源台账、监控告警、配置管理的一站式操作面。 +XINFRA 是计划建设的面向 SRE 团队的统一基础设施管理平台，覆盖 Kodo、LAS、灵矽、LTOKEN、MAAS 五条业务线。 -**核心目标**： +```mermaid +mindmap + root((XINFRA)) + 统一入口 + 门户与登录 + 资源 + CMDB多云同步 + 集群管理 + 资源大盘 + 数据存储 + 数据库审核与脱敏 + 缓存监控与诊断 + 运维 + 容器编排 + 配置下发 + 标准化部署 + 任务中心 + 监控 + 健康状态看板 + 告警 + 统一告警 +``` -| # | 目标 | 说明 | -|---|------|------| -| 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），主系统只自建无法被替代的能力 -- **数据一致性**：资源同步采用"已存在跳过更新"策略，保护人工维护的资产数据，防止被云平台同步覆盖 +本文档从 SRE 日常工作中的痛点出发，说明 XINFRA 计划如何通过一站式平台解决这些问题。 --- -## 角色模型 +## 痛点 1：多系统来回切换，登录疲劳 -主系统采用**二维角色模型**：权限维度 × 业务线维度。 +SRE 日常工作涉及 6+ 个系统，每个系统有独立地址和账号，每天在不同系统间反复切换登录。 -### 权限维度 +| | 不使用 XINFRA | 使用 XINFRA | +|------|--------------|------------| +| 登录 | 每天在 6+ 个系统间切换，每个系统一套账号密码 | 一个入口，登录一次，所有系统直接进 | -| 权限角色 | 权限范围 | -|---------|---------| -| 超级管理员 | 全平台所有模块的读写权限，包括集群管理、运维终端、账号权限管理、审计全局查看 | -| 业务操作员 | 本业务线内资源的申请、部署、配置变更；可操作 Wayne/CloudDM/CacheCloud/Apollo 中本业务线的资源 | -| 日志操作员 | 本业务线的日志查看、告警查看、审计记录查看；无写入/变更权限 | -| 访客 | 只读查看资源大盘、服务目录、告警概览；不可执行任何操作 | +### 我们怎么解决 -### 业务线维度 +提供统一门户，所有子系统以卡片形式集中展示，一次登录、全系统通行。 -| 业务线 | 说明 | -|--------|------| -| Kodo | 七牛云存储 | -| LAS | 七牛云直播 | -| 灵矽 | 七牛云 IoT | -| LTOKEN | 七牛云 Token 服务 | -| MAAS | 七牛云模型即服务 | - -### 权限矩阵 - -| 模块 | 超级管理员 | 业务操作员 | 日志操作员 | 访客 | -|------|-----------|-----------|-----------|------| -| 资源大盘 | ✓ 全局 | ✓ 本业务线 | ✓ 本业务线 | ✓ 全局只读 | -| 告警看板 | ✓ 全局 | ✓ 本业务线 | ✓ 本业务线 | ✓ 只读 | -| 集群与节点管理 | ✓ 读写 | ○ 只读 | ○ 只读 | ✗ | -| 多租户管理 | ✓ 读写 | ✗ | ✗ | ✗ | -| Wayne 部署 | ✓ 读写 | ✓ 本业务线 | ○ 只读 | ✗ | -| CloudDM SQL 审核 | ✓ 读写 | ✓ 本业务线 | ○ 只读 | ✗ | -| CacheCloud 缓存 | ✓ 读写 | ✓ 本业务线 | ○ 只读 | ✗ | -| Apollo 配置 | ✓ 读写 | ✓ 本业务线 | ○ 只读 | ✗ | -| 任务中心 | ✓ 全局 | ✓ 本业务线 | ✓ 本业务线 | ✗ | -| 资源台账 | ✓ 读写 | ○ 只读 | ○ 只读 | ✗ | -| 审计面板 | ✓ 全局 | ✗ | ✓ 本业务线 | ✗ | -| 运维终端 | ✓ 仅管理员 | ✗ | ✗ | ✗ | - -> ✓ = 读写权限，○ = 只读权限，✗ = 无权限 +> **用户故事**：SRE 小王早上打开 XINFRA，看到所有子系统的卡片和接入状态。点击 CacheCloud 卡片，直接跳转过去，无需再次输入密码。新入职的 SRE 小李只需记住 XINFRA 一个地址，就能找到所有运维相关系统。 --- -## 功能需求 +## 痛点 2：出了问题，不知道谁操作过 -### Phase 1 — MVP（当前阶段） +某台机器配置被改了、某个服务被重启了，事后无法追溯是誰在什么时间做的操作。 -> 最小可用集：多租户认证 + 子系统对接 +| | 不使用 XINFRA | 使用 XINFRA | +|------|--------------|------------| +| 责任追溯 | 出了问题不知道谁操作过，排查全靠问人 | 每次操作自动记录，谁、什么时间、做了什么，一查便知 | -#### 1.1 平台基础能力 +### 我们怎么解决 -##### 多租户与认证 +主系统内置审计面板，记录每一次登录事件和运维操作，支持按时间、操作人、操作类型筛选查询。 -> 基于 LDAP 组织信息自动生成业务线租户，为每个业务线分配独立的命名空间和资源配额，结合节点亲和性与 ResourceQuota 实现双重隔离。 - -- [ ] P0 — 业务线列表：业务线标识/名称、对应的 LDAP 部门 DN、归属的物理节点数、CPU 总配额及已用比例（进度条）、绑定的 Kubernetes 命名空间、负责人信息 -- [ ] P0 — 隔离策略：通过节点标签（`business-line=xxx`）配合 NodeAffinity 和 Taint，确保 Pod 只能调度到本业务线的物理节点上 -- [ ] P0 — 配额管理：在命名空间内施加 ResourceQuota / LimitRange，避免单一业务线无限占用资源 +> **用户故事**：SRE 小王发现昨天有人在运维终端执行了节点操作，打开审计面板按时间筛选，立刻定位到具体操作人和操作内容。普通操作员 SRE 小张只能看到自己的登录记录，管理员老刘则能查看全局审计日志。 --- -##### 统一子系统导航 +## 痛点 3：容器部署依赖手工操作，出了错难回滚 -> 作为所有相关子系统的单一入口门户，利用 LDAP 统一账号实现 SSO，用户无需记忆多个地址和重复认证。 +部署服务需要手动操作，操作过程没有记录，出了问题回滚慢、靠经验。七个机房的集群各自管理，缺乏统一视图。 -- [ ] P0 — 已集成系统卡片展示：系统图标、名称、简要说明及 LDAP/SSO 接入状态（已接入/改造中），预留打开链接 -- [ ] P0 — 已集成系统包括：Wayne、open-cdm、CacheCloud、qpass、Grafana、Apollo -- [ ] P0 — SSO 跳转：点击卡片通过 LDAP SSO 跳转至对应子系统，无需重复登录 +| | 不使用 XINFRA | 使用 XINFRA | +|------|--------------|------------| +| 发布服务 | 手动操作，过程没记录，出问题回滚慢、靠经验 | 界面上点几下完成发布，有历史记录，一键回滚 | + +### 我们怎么解决 + +通过 Wayne 平台提供容器部署的统一操作面：界面化部署、发布历史与一键回滚、API 对接自动化部署、生产环境部署增加审批卡点。 + +> **用户故事**：SRE 小王需要部署新服务到 Kodo 的集群，在 Wayne 界面选择集群、填写镜像 tag 和副本数，一键完成部署。上线后发现有异常，在发布历史中找到上一个稳定版本，一键回滚。生产环境的部署请求自动流转给老刘审批。 --- -##### 审计面板（主系统） +## 痛点 4：生产数据库操作缺少审核，风险高 -> 记录主系统自身的登录事件和运维操作日志，不聚合子系统操作审计。 +当前可以直连线上数据库操作，没有审核流程，改错了直接影响用户。 -- [ ] P0 — 登录审计：记录每次 LDAP SSO 登录事件（操作人、时间、来源 IP、目标子系统），支持按时间/操作人/子系统筛选查询 -- [ ] P0 — 运维操作审计：记录主系统运维终端的操作（Ansible Playbook 执行、节点加入、配置变更等），支持按时间/操作人/操作类型筛选 -- [ ] P1 — 安全事件面板：异常登录检测、敏感操作告警 -- [ ] P0 — 权限控制：管理员角色可查看全局；普通用户仅查看自身登录记录 -- [ ] P0 — 审计面板集成到主系统统一门户，无需独立部署 +| | 不使用 XINFRA | 使用 XINFRA | +|------|--------------|------------| +| 数据库安全 | 直接连线上数据库操作，改错了直接影响用户 | 所有线上改动必须经过审核，不允许直接操作 | + +### 我们怎么解决 + +通过 CloudDM 管理所有数据库操作，所有线上改动必须经过工单审核流程，禁止直连。查询结果中的敏感字段自动脱敏。 + +> **用户故事**：SRE 小王需要在生产 MySQL 执行一条线上变更，在 CloudDM 提交工单，系统自动预检风险，通过后等待 DBA 审核，审核通过后自动执行。SRE 小张需要查询业务库数据做排查，在 CloudDM 申请临时查询权限，在线查询时敏感字段自动脱敏。出了问题，管理员老刘可以通过审计记录追溯完整的操作链路。 --- -#### 1.2 子系统对接 +## 痛点 5：缓存实例散落各处，运维靠记忆 -##### Wayne — 容器编排与多集群管理 +各业务线的缓存实例分散部署，全貌看不见。哪个业务线有多少实例、内存用了多少、有没有异常，需要逐个登录机器查看。 -> 底层基于 RKE2 构建七机房 K8s 集群，上层通过 Wayne 平台提供统一的容器管理入口。开发人员通过 Wayne UI 或 API 完成服务部署，无需直接操作 kubectl。 +| | 不使用 XINFRA | 使用 XINFRA | +|------|--------------|------------| +| 缓存管理 | 各业务线自己管自己的缓存，全貌看不见 | 统一管理，整体状况一个页面看清，异常自动发现 | -**RKE2 集群约束**（基础设施依赖）： +### 我们怎么解决 -| 约束项 | 说明 | -|--------|------| -| CNI 插件 | Calico BGP（每集群独立 AS 号） | -| 容器运行时 | containerd（不依赖 Docker） | -| 离线部署 | 支持 Air-gap 环境 | -| 集群规模 | 七机房各一套独立集群 | -| 安全加固 | 已通过 CIS Benchmark，默认启用加密和审计 | +通过 CacheCloud 统一管理所有缓存实例的申请、部署、监控和回收。提供诊断工具，临时实例到期自动回收。 -**Wayne 多集群管理**： - -- [ ] P0 — 支持多集群统一管理，通过 Client-Go 连接各机房 RKE2 集群 -- [ ] P0 — RBAC 权限管理，部门角色与项目角色分离（Project → Environment → Namespace 三级结构） -- [ ] P0 — 提供表单式（基础模式）和 YAML/JSON 编辑（高级模式）两种 K8s 对象创建方式 -- [ ] P0 — 发布历史记录与一键回滚能力 -- [ ] P0 — 完整审计模块，每次操作留痕，支持自定义 Webhook 回调 -- [ ] P1 — Web Shell 远程终端（基于权限校验的 Pod Exec） -- [ ] P1 — 资源报表（资源使用占比、上线频次图表） -- [ ] P0 — APIKey 开放接口，支持 CI/CD 流水线调用 -- [ ] P0 — 认证支持 DB 内置 + LDAP 混合模式 -- [ ] P1 — YAML 模板版本锁定，纳入代码仓库管理 +> **用户故事**：SRE 小王需要为 Kodo 申请缓存集群，在 CacheCloud 选择架构模式和内存规格，提交后自动创建并注册。SRE 小张发现某实例响应变慢，用 CacheCloud 的诊断工具定位到一个大 Key。SRE 小李之前申请的测试实例到期后被自动回收，不再需要手动清理。 --- -##### CloudDM / open-cdm — 数据库管理与 SQL 审核 +## 痛点 6：多机房配置变更靠逐台操作 -> 覆盖数据查询、权限管控、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 — 全程审计留痕，工单流转记录可追溯 +| | 不使用 XINFRA | 使用 XINFRA | +|------|--------------|------------| +| 配置变更 | 7 个机房逐个改，改漏一个就出故障，没法撤回 | 改一次自动下发所有机房，改错了能立刻回滚 | + +### 我们怎么解决 + +通过 Apollo 配置中心实现所有机房配置的统一管理，在一个入口修改后统一下发各机房，支持灰度发布和版本回滚。 + +> **用户故事**：SRE 小王需要修改某个服务在所有机房的配置，在 Apollo Portal 统一修改后发布，无需逐机房操作。发布后发现配置有问题，快速回滚到上一版本。SRE 小张在 XINFRA 上查看各机房 Apollo 的接入状态，掌握配置中心整体情况。 --- -##### CacheCloud — 缓存管理 +## 痛点 7：资源台账散落在多个平台 -> 支持 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 — 临时实例自动回收策略，防止资源浪费 +| | 不使用 XINFRA | 使用 XINFRA | +|------|--------------|------------| +| 资源台账 | 服务器信息散在好几个平台，查一台机器要登录好几个地方 | 一个页面查到所有服务器，按业务线、机房随便筛 | + +### 我们怎么解决 + +以 CMDB 为基础数据底座，定时从各云平台同步虚机信息，形成统一的资源台账。支持按资源类型、来源、业务线、机房等条件组合筛选。同步不会覆盖 CMDB 中人工维护的数据。 + +> **用户故事**：SRE 小王打开资源台账，看到所有资源的来源统计和最近同步状态。需要查找某台机器时，按业务线和机房筛选，快速定位。SRE 小张发现某台虚机信息需要补充，在台账中标记为人工维护，后续云同步不会覆盖这些字段。需要申请新虚机时，通过台账的「创建虚机」入口直接跳转。 --- -##### Apollo — 配置中心管理 +## 痛点 8：服务注册信息分散，跨机房查找困难 -> 对 Apollo 配置中心进行统一接入和管理，实现在单一 Portal 管理所有机房的配置，确保配置的灰度发布、回滚与变更审计。 +各机房的服务注册中心独立运行，想知道某个服务在哪些机房部署了、健康状态如何，需要逐个登录各机房查看。 -- [ ] P0 — 核心指标展示：已接入机房数、Apollo Cluster 数量、配置项总数、Namespace 数、接入业务线及同步状态 -- [ ] P0 — 统一入口：提供 Apollo Portal 快捷入口（内部域名 `apollo.xinfra.internal`），LDAP SSO 单点登录 -- [ ] P0 — 机房列表：展示每个机房的 Apollo Cluster、Config Service 地址、承载方式（容器化 K8s Service）、接入业务线和配置项数、运行状态（运行中/灰度接入/建设中/待启动） +| | 不使用 XINFRA | 使用 XINFRA | +|------|--------------|------------| +| 服务查找 | 逐个机房登录查服务，找一个服务要登好几个地方 | 一个页面搜到所有机房的服务，健康状态一目了然 | -**部署架构约束**： -- Portal + Admin Service：YZH 主中心统一部署 -- Config Service：按机房独立部署（yzh/xs/jf/dallas 等），容器化运行在 K8s 内 -- 数据同步：ConfigDB/PortalDB 部署在 YZH，各机房 Config Service 本地缓存全量配置，网络抖动时降级提供本地缓存 +### 我们怎么解决 + +定时从各机房同步服务信息，提供跨机房的服务统一检索视图，支持按机房、业务标签、健康状态筛选。 + +> **用户故事**：SRE 小王在服务目录中搜索某个服务名，看到该服务在 4 个机房有注册，其中 1 个机房有 2 个实例不健康，立即定位到问题机房。SRE 小张通过业务标签筛选，快速获取某业务线接入的所有服务清单。 --- -##### CD 自动化部署 +## 痛点 9：基础组件部署没有标准，各凭经验 -> 通过 API 接口触发 Wayne 平台执行自动化部署，CI 部分由团队已有 CI 系统负责。 +谁部署谁的风格，配置五花八门，部署完还要手动注册。 -- [ ] P0 — 提供 REST API 接口，供外部 CI 系统调用触发 Wayne 部署，传入镜像 tag 和目标环境 -- [ ] P0 — 部署支持多环境（dev / staging / prod），生产环境需审批卡点 -- [ ] P1 — 部署失败时支持自动回滚到上一个稳定版本 -- [ ] P1 — 部署状态回调：支持 Webhook 回调通知外部 CI 系统部署结果 +| | 不使用 XINFRA | 使用 XINFRA | +|------|--------------|------------| +| 组件部署 | 谁部署谁的风格，配置五花八门，部署完还要手动注册 | 标准化流程，所有人部署出来一样，部署完自动注册 | -> [!info] CI 编译构建由团队已有 CI 系统负责，本平台仅提供 CD 部署接口。 +### 我们怎么解决 + +将标准化基础组件封装为服务卡片，SRE 通过界面选择业务线、架构模式、规格等参数，后台自动完成标准化部署，部署完成后自动注册到对应子系统。 + +> **用户故事**：SRE 小王需要为 Kodo 部署 MySQL，在服务目录选择 MySQL 卡片，填写业务线、架构模式、规格等参数，确认后自动部署。部署完成后，实例自动注册到 CloudDM。不同 SRE 部署出来的配置完全一致，不再依赖个人经验。 --- -#### 1.3 MVP 验收标准 +## 痛点 10：运维任务执行后无法追踪 -- [ ] 多租户：新业务线可在平台自助创建，自动完成 Namespace + 标签 + Taint + ResourceQuota 配置 -- [ ] 隔离：跨业务线 Pod 调度隔离验证通过 -- [ ] 配额：配额超限告警正常触发 -- [ ] SSO：所有已集成系统卡片正确展示，SSO 跳转正常；未接入系统标注"改造中"状态 -- [ ] 审计：登录事件和运维操作实时记录，查询延迟 < 5s -- [ ] Wayne：开发人员可在 Wayne 中选择目标集群完成服务部署；CI/CD 流水线可通过 APIKey 调用 Wayne API 触发部署 -- [ ] CloudDM：所有生产库 SQL 操作必须经工单流程，无直连通道 -- [ ] CacheCloud：三种 Redis 架构均可正常创建和访问 -- [ ] Apollo：YZH、XS 机房正式运行，JF 灰度接入；配置变更支持灰度发布和一键回滚 -- [ ] CD：外部 CI 系统可通过 API 触发 Wayne 部署；prod 环境部署必须经过审批 +运维任务执行过程中无法实时查看进度，事后排查也找不到完整日志。 + +| | 不使用 XINFRA | 使用 XINFRA | +|------|--------------|------------| +| 任务追踪 | 任务执行了不知道进度，出了问题找不到日志 | 实时查看执行进度，所有历史日志随时翻查 | + +### 我们怎么解决 + +任务中心集中展示所有运维任务的执行记录，实时流式输出执行日志，支持历史查询。 + +> **用户故事**：SRE 小王提交了一个节点加入任务后，在任务中心看到任务状态为「执行中」，实时查看每一步的执行日志，发现某步卡住时及时介入。一周后需要排查某次部署失败的原因，在任务中心的历史记录中找到该任务，查看完整日志定位问题。 --- -### Phase 2 — 完整版 +## 痛点 11：监控告警分散在多个系统 -> 监控、配置、任务、基础服务交付的完整能力 +三套监控系统来回看，告警分散，容易漏掉。某个机房的物理机出问题，可能要等用户报障才发现。 -#### 2.1 监控与可观测性 +| | 不使用 XINFRA | 使用 XINFRA | +|------|--------------|------------| +| 监控告警 | 三套监控系统来回看，告警分散，容易漏掉 | 一个看板看全貌，告警按严重程度排列，发现即定位 | -##### 资源大盘 +### 我们怎么解决 -> 为平台管理员及业务负责人提供跨机房、多云容器资源的全局快照与健康视图。 +提供资源状态看板，整合物理机、虚机、基础服务三层的健康状态。统一展示告警，按严重程度分类，标注来源。 -- [ ] P0 — 展示核心指标：RKE2 集群数量、在线机房数、节点总数及近期增量、CPU 总核数/已分配/分配率、组件实例总数及分类（MySQL、Redis、其他）、进行中的自动化任务数量 -- [ ] P0 — 集群拓扑：以机房为维度，显示各机房节点池方格图（node grid），每个方格代表一台物理机/节点，颜色区分业务线（Kodo、LAS 等），空闲节点用虚线框表示 -- [ ] P0 — 最近任务：列表展示最近 5 条 ansible-playbook 任务的执行状态（成功/执行中/失败）和耗时，快速跳转至任务中心 -- [ ] P1 — 刷新机制：页面自动显示"最近更新于 xx 秒前"，支持手动刷新 +> **用户故事**：SRE 小王打开告警看板，看到当前所有高级别告警，按来源区分是硬件告警还是业务告警，快速判断故障范围。SRE 小张发现某个机房物理机健康率下降，通过看板看到具体告警信息后联系机房运维。SRE 小王还发现 Kodo 的 MySQL 有 2 个实例异常，直接从看板跳转排查。 --- -##### 资源状态看板与告警 +## 痛点 12：不知道全局资源还有多少余量 -> 整合物理机、虚机、基础服务三层的健康状态，通过夜莺（Nightingale）统一告警引擎将多源告警标准化展示，提供自上而下的故障定位入口。 +各机房的资源使用情况分散在不同系统中，做容量规划时缺乏全局视角。 -数据源： -- 物理机硬件 & 网络设备健康：Zabbix（IPMI/温度/电源/风扇/存储） -- 虚机 & 容器 & 业务层指标：VictoriaMetrics（K8s/主机指标/服务可用性探活） -- Nightingale 作为统一告警聚合层，负责去重、收敛、分级（P0/P1/…），按 disaster/high/average 等原始级别映射，推送至 qpass 告警通道 +| | 不使用 XINFRA | 使用 XINFRA | +|------|--------------|------------| +| 资源余量 | 资源使用情况散在各处，做规划全凭感觉 | 一个页面看全貌，哪个业务线用了多少、哪里还有空闲，一目了然 | -- [ ] P0 — 核心统计：物理机总数、虚机总数、基础组件实例总数；P0(Disaster)、P1(High) 及 average 级别告警数量，标注来自 Zabbix 或 VictoriaMetrics -- [ ] P0 — 物理机状态：按机房汇总在线数、健康率（带进度条），标识正常/告警/严重状态 -- [ ] P0 — 虚机状态：按业务线展示 LAS 资源池中的虚机数、CPU 均值及告警状态 -- [ ] P0 — 基础服务状态：覆盖 MySQL、Redis（CacheCloud）、PostgreSQL、openresty 网关等，显示实例数、异常数、可用率 -- [ ] P0 — 当前告警详情：表格列出所有 P0/P1 及 average 级别的实时告警，含级别标签、来源、原始级别、目标对象、告警内容、发生时间 +### 我们怎么解决 + +资源大盘提供跨机房资源的全局快照：集群数、节点总数、资源分配率、实例总数。以机房为维度展示节点分布，空闲节点一目了然。 + +> **用户故事**：SRE 小王每天早上打开资源大盘，一眼看到七个机房的集群数、资源分配率和实例总数。通过节点分布图直观看到各业务线在各机房的节点分布和空闲节点，为扩容计划提供数据依据。 --- -##### 监控、日志与告警集成 +## 痛点 13：集群和节点管理操作繁琐 -> 集成公司现有监控与日志基础设施的状态和主要入口，方便从平台直接掌握各子系统健康度。 +新节点加入集群需要手动执行一系列操作，不同集群的信息也需要逐个登录查看。 -- [ ] P0 — VictoriaMetrics 指标概览：展示七机房采集节点数、活跃时序数量、Prometheus 接口状态、已建 Grafana 仪表盘数 -- [ ] P0 — Zabbix 硬件监控：物理机监控覆盖率、当前告警数、网络设备健康度、存储健康度 -- [ ] P1 — 统一日志与告警流水：以实时日志流形式展示关键系统事件（CMDB 同步、Zabbix 告警、VictoriaMetrics 抓取、ELK 日志接入、qpass 合并推送），类似运维公告板 +| | 不使用 XINFRA | 使用 XINFRA | +|------|--------------|------------| +| 集群管理 | 加入一个节点要手动操作好几步，集群信息逐个登录查看 | 填几个信息提交，自动完成加入；所有集群一个页面看完 | ---- +### 我们怎么解决 -#### 2.2 配置与任务管理 +提供集群列表和节点列表的统一视图，以及节点加入向导——选择目标集群、输入节点 IP、指定业务线，提交后后台自动完成所有加入步骤。 -##### 任务中心与自动化执行 - -> 集中展现所有通过 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 秒 - ---- - -## 关联笔记 - -- [[architecture]] -- [[mvp-plan]] -- [[technical/xinfra-preview]] -- [[technical/xinfra-preview/k8s-rke2-fundamentals]] -- [[technical/xinfra-preview/wayne-overview]] -- [[technical/xinfra-preview/cloud-dm-overview]] -- [[technical/xinfra-preview/cachecloud-overview]] -- [[technical/xinfra-preview/ansible-playbook-basics]] +> **用户故事**：SRE 小张需要为 LAS 扩容一个节点，通过节点加入向导选择目标集群、输入节点 IP、指定业务线，提交后后台自动完成节点加入全流程。SRE 小王在集群列表中看到所有机房的集群健康状态和资源使用率，对存在告警的集群一眼识别。