348 lines
18 KiB
Markdown
348 lines
18 KiB
Markdown
---
|
||
tags: [xinfra, requirements, infra]
|
||
create time: 2026-07-08 13:54
|
||
---
|
||
|
||
# XINFRA 平台需求文档
|
||
|
||
## 概述
|
||
|
||
XINFRA 是计划建设的面向 SRE 团队的统一基础设施管理平台，覆盖 Kodo、LAS、灵矽、LTOKEN、MAAS 五条业务线。
|
||
|
||
```mermaid
|
||
mindmap
|
||
root((XINFRA))
|
||
统一入口
|
||
门户与登录
|
||
资源
|
||
CMDB多云同步
|
||
集群管理
|
||
资源大盘
|
||
数据存储
|
||
数据库审核与脱敏
|
||
缓存监控与诊断
|
||
运维
|
||
容器编排
|
||
配置下发
|
||
标准化部署
|
||
任务中心
|
||
监控
|
||
状态看板
|
||
告警
|
||
统一告警
|
||
```
|
||
|
||
本文档从 SRE 日常工作中的痛点出发，说明 XINFRA 计划如何通过一站式平台解决这些问题。
|
||
|
||
---
|
||
|
||
## 痛点 1：多系统来回切换，登录疲劳
|
||
|
||
SRE 日常工作涉及 6+ 个系统，每个系统有独立地址和账号，每天在不同系统间反复切换登录。
|
||
|
||
| | 不使用 XINFRA | 使用 XINFRA |
|
||
|------|--------------|------------|
|
||
| 登录 | 每天在 6+ 个系统间切换，每个系统一套账号密码 | 一个入口，登录一次，所有系统直接进 |
|
||
|
||
### 我们怎么解决
|
||
|
||
提供统一门户，所有子系统以卡片形式集中展示，一次登录、全系统通行。
|
||
|
||
### 做什么 / 不做什么
|
||
|
||
- ✅ SSO 单点登录，主系统顶部导航栏常驻，子系统以卡片形式集中展示
|
||
- ✅ 子系统以 iframe 方式嵌入，提供统一访问入口
|
||
- ❌ 不改造子系统的登录系统，不存储子系统的账号密码
|
||
|
||
> **用户故事**：SRE 小王早上打开 XINFRA，看到所有子系统的卡片和接入状态。点击 CacheCloud 卡片，直接跳转过去，无需再次输入密码。新入职的 SRE 小李只需记住 XINFRA 一个地址，就能找到所有运维相关系统。
|
||
|
||
---
|
||
|
||
## 痛点 2：出了问题，不知道谁操作过
|
||
|
||
某台机器配置被改了、某个服务被重启了，事后无法追溯是谁在什么时间做的操作。
|
||
|
||
| | 不使用 XINFRA | 使用 XINFRA |
|
||
| ---- | ------------------ | ------------------------- |
|
||
| 责任追溯 | 出了问题不知道谁操作过，排查全靠问人 | 每次操作自动记录，谁、什么时间、做了什么，一查便知 |
|
||
|
||
### 我们怎么解决
|
||
|
||
主系统内置审计面板，记录**谁在什么时间进入了哪个子系统**，以及**在主系统本身执行的操作**（如节点加入向导、配置查看等），支持按时间、操作人、操作类型筛选查询。
|
||
|
||
### 做什么 / 不做什么
|
||
|
||
- ✅ 统一审计面板，记录主系统内所有操作（谁、什么时间、做了什么）
|
||
- ✅ 记录用户进出子系统的入口跳转事件
|
||
- ❌ 不侵入子系统内部，子系统操作详情由各子系统自行记录
|
||
- ❌ 不负责跨子系统的操作关联和链路拼接
|
||
|
||
**注意**：子系统内部的操作详情（如 Wayne 里的部署动作、CacheCloud 里的配置变更）由各子系统自行记录。主系统提供从审计面板跳转到对应子系统审计日志的入口，便于链路追溯。
|
||
|
||
### 战略决策：为什么不将子系统操作统一纳入主系统审计？
|
||
|
||
统一审计听起来更完整，但在当前阶段既不现实也不划算：
|
||
|
||
| 维度 | 统一采集（主系统接管所有子系统操作日志） | 分级审计（各子系统自行记录，主系统提供跳转入口） |
|
||
|------|------|------|
|
||
| 可行性 | Wayne、CacheCloud、CloudDM 等子系统是独立平台，不暴露标准化审计接口，主系统无法侵入实现去拦截操作 | 无需侵入子系统，利用各子系统已有的审计能力即可 |
|
||
| 成本收益 | 需与每个子系统逐一对接审计事件采集协议，开发维护成本高；子系统已有审计记录，重复采集无增量价值 | 几乎零额外开发成本，主系统只管自己能掌控的部分 |
|
||
| 职责边界 | 主系统越界接管子系统内部事务，耦合度高，后续子系统变更会直接影响主系统 | 主系统负责「谁进了哪里」+「在主系统做了什么」，子系统各管各的，边界清晰 |
|
||
| 可演进性 | 架构一次到位但改动面大，后续子系统升级可能需要重做对接 | 当前跳转方案够用；未来子系统开放审计 API 后可按需接入聚合，渐进演进 |
|
||
|
||
> **用户故事**：SRE 小王发现昨天有人进入了运维终端，打开审计面板按时间筛选，看到某人在 14:32 跳转进入了 Wayne 并在主系统执行了节点加入操作。需要进一步查看该人员在 Wayne 内部的具体部署动作时，从审计面板直接跳转到 Wayne 的审计日志。普通操作员 SRE 小张只能看到自己的记录，管理员老刘则能查看全局审计日志。
|
||
|
||
---
|
||
|
||
## 痛点 3：容器部署依赖手工操作，出了错难回滚
|
||
|
||
部署服务需要手动操作，操作过程没有记录，出了问题回滚慢、靠经验。七个机房的集群各自管理，缺乏统一视图。
|
||
|
||
| | 不使用 XINFRA | 使用 XINFRA |
|
||
|------|--------------|------------|
|
||
| 发布服务 | 手动操作，过程没记录，出问题回滚慢、靠经验 | 界面上点几下完成发布，有历史记录，一键回滚 |
|
||
|
||
### 我们怎么解决
|
||
|
||
通过 Wayne 平台提供容器部署的统一操作面：界面化部署、发布历史与一键回滚、API 对接自动化部署、生产环境部署增加审批卡点。
|
||
|
||
### 做什么 / 不做什么
|
||
|
||
- ✅ 统一部署界面，支持配置镜像、副本数等参数，一键完成部署
|
||
- ✅ 发布历史记录和一键回滚能力
|
||
- ❌ 复杂编排操作（扩缩容策略、HPA、滚动更新等高级 K8s 操作）仍通过跳转 Wayne 完成
|
||
|
||
> **用户故事**：SRE 小王需要部署新服务到 Kodo 的集群，在 Wayne 界面选择集群、填写镜像 tag 和副本数，一键完成部署。上线后发现有异常，在发布历史中找到上一个稳定版本，一键回滚。生产环境的部署请求自动流转给老刘审批。
|
||
|
||
---
|
||
|
||
## 痛点 4：生产数据库操作缺少审核，风险高
|
||
|
||
当前可以直连线上数据库操作，没有审核流程，改错了直接影响用户。
|
||
|
||
| | 不使用 XINFRA | 使用 XINFRA |
|
||
|------|--------------|------------|
|
||
| 数据库安全 | 直接连线上数据库操作，改错了直接影响用户 | 所有线上改动必须经过审核，不允许直接操作 |
|
||
|
||
### 我们怎么解决
|
||
|
||
通过 CloudDM 管理所有数据库操作，所有线上改动必须经过工单审核流程，禁止直连。查询结果中的敏感字段自动脱敏。
|
||
|
||
### 做什么 / 不做什么
|
||
|
||
- ✅ 主要做入口接入
|
||
- ❌ SQL 执行/变更操作本身由 CloudDM 处理，XINFRA 不直接执行数据库操作
|
||
|
||
> **用户故事**：SRE 小王需要在生产 MySQL 执行一条线上变更，在 CloudDM 提交工单，系统自动预检风险，通过后等待 DBA 审核，审核通过后自动执行。SRE 小张需要查询业务库数据做排查，在 CloudDM 申请临时查询权限，在线查询时敏感字段自动脱敏。出了问题，管理员老刘可以通过审计记录追溯完整的操作链路。
|
||
|
||
---
|
||
|
||
## 痛点 5：缓存实例散落各处，运维靠记忆
|
||
|
||
各业务线的缓存实例分散部署，全貌看不见。哪个业务线有多少实例、内存用了多少、有没有异常，需要逐个登录机器查看。
|
||
|
||
| | 不使用 XINFRA | 使用 XINFRA |
|
||
|------|--------------|------------|
|
||
| 缓存管理 | 各业务线自己管自己的缓存，全貌看不见 | 统一管理，整体状况一个页面看清，异常自动发现 |
|
||
|
||
### 我们怎么解决
|
||
|
||
通过 CacheCloud 统一管理所有缓存实例的申请、部署、监控和回收。提供诊断工具，临时实例到期自动回收。
|
||
|
||
### 做什么 / 不做什么
|
||
|
||
- ✅ 集群指标聚合监控、诊断分析（命中率、热点 Key 等），为优化提供数据支撑
|
||
- ❌ 缓存实例的具体操作（删除、过期策略调整等）由 CacheCloud 处理，XINFRA 不直接执行缓存操作
|
||
|
||
> **用户故事**：SRE 小王需要为 Kodo 申请缓存集群，在 CacheCloud 选择架构模式和内存规格，提交后自动创建并注册。SRE 小张发现某实例响应变慢，用 CacheCloud 的诊断工具定位到一个大 Key。SRE 小李之前申请的测试实例到期后被自动回收，不再需要手动清理。
|
||
|
||
---
|
||
|
||
## 痛点 6：服务配置变更管理分散
|
||
|
||
服务配置分散在各机房，变更时需要逐机房登录修改，改漏一个就出故障，没法撤回。
|
||
|
||
| | 不使用 XINFRA | 使用 XINFRA |
|
||
| ---- | --------------------- | -------------------- |
|
||
| 配置变更 | 多个机房逐个改，改漏一个就出故障，没法撤回 | 改一次自动下发所有机房，改错了能立刻回滚 |
|
||
|
||
### 我们怎么解决
|
||
|
||
通过 Apollo 配置中心实现所有机房配置的统一管理，在一个入口修改后统一下发各机房，支持灰度发布和版本回滚。
|
||
|
||
### 做什么 / 不做什么
|
||
|
||
- ✅ 配置信息汇总展示、简单配置项查看与修改
|
||
- ❌ 复杂配置模板、多环境同步、版本管理等高级功能仍通过跳转 Apollo 完成
|
||
|
||
> **用户故事**：SRE 小王需要修改某个服务在所有机房的配置，在 Apollo Portal 统一修改后发布，无需逐机房操作。发布后发现配置有问题，快速回滚到上一版本。SRE 小张在 XINFRA 上查看各机房 Apollo 的接入状态，掌握配置中心整体情况。
|
||
|
||
---
|
||
|
||
## 痛点 7：机器（物理机/虚机）信息存储在 CMDB 平台
|
||
|
||
服务器信息散落在内部 CMDB，查看机器信息不包含有机器情况的信息。
|
||
|
||
| | 不使用 XINFRA | 使用 XINFRA |
|
||
|------|--------------|------------|
|
||
| 资源查找 | 服务器信息散落在 CMDB 和多个云平台，各平台数据格式不统一，查一台机器要逐个平台查看、手动拼凑 | 一个页面聚合所有平台的服务器信息，按业务线、机房统一筛选 |
|
||
|
||
### 我们怎么解决
|
||
|
||
以 CMDB 为基础数据底座，定时从各云平台同步虚机信息，形成统一的资源台账。支持按资源类型、来源、业务线、机房等条件组合筛选。同步不会覆盖 CMDB 中人工维护的数据。
|
||
|
||
> **用户故事**：SRE 小王打开资源台账，看到所有资源的来源统计和最近同步状态。需要查找某台机器时，按业务线和机房筛选，快速定位。SRE 小张发现某台虚机信息需要补充，在台账中标记为人工维护，后续云同步不会覆盖这些字段。需要申请新虚机时，通过台账的「创建虚机」入口直接跳转。
|
||
|
||
### 战略决策：为什么不直接在 XINFRA 上做 CMDB 的增改查？
|
||
|
||
XINFRA 只做查找和展示，不替代 CMDB 的写入能力。
|
||
|
||
**做什么**：
|
||
- 聚合各平台服务器信息，提供统一的只读查询视图
|
||
- 从各云平台单向同步虚机数据，不覆盖 CMDB 中人工维护的字段
|
||
- 提供跳转到 CMDB / 各云平台的入口，便于后续操作
|
||
|
||
**不做什么**：
|
||
- 不替代 CMDB 做资产增改，CMDB 仍是唯一写入源
|
||
- 不做双向同步，避免写入冲突和脏数据
|
||
|
||
**为什么**：
|
||
|
||
| 维度 | 在 XINFRA 上做完整 CRUD | 只做查找与展示 |
|
||
|------|------|------|
|
||
| 数据源头 | 需要在 XINFRA 与多个 CMDB 之间做双向同步，写入冲突难以仲裁 | CMDB 仍是唯一写入源，XINFRA 只读同步，不存在一致性问题 |
|
||
| 职责边界 | XINFRA 变成"超级 CMDB"，和各平台职责重叠，运维人员不知道该在哪改数据 | XINFRA 是聚合查询入口，CMDB 是数据维护入口，各有分工 |
|
||
| 开发成本 | 每对接一个 CMDB 都要实现完整的读写逻辑和权限校验，开发量随平台数线性增长 | 只对接读取接口，成本低、上线快 |
|
||
| 数据正确性 | 多写入源必然引入脏数据风险，需要额外的冲突检测和修正机制 | 单一写入源，数据正确性由 CMDB 自身保障 |
|
||
|
||
---
|
||
|
||
## 痛点 8：服务注册信息分散，跨机房查找困难
|
||
|
||
各机房的服务注册中心独立运行，想知道某个服务在哪些机房部署了、健康状态如何，需要逐个登录各机房查看。
|
||
|
||
| | 不使用 XINFRA | 使用 XINFRA |
|
||
|------|--------------|------------|
|
||
| 服务查找 | 逐个机房登录查服务，找一个服务要登好几个地方 | 一个页面搜到所有机房的服务，健康状态一目了然 |
|
||
|
||
### 我们怎么解决
|
||
|
||
定时从各机房同步服务信息，提供跨机房的服务统一检索视图，支持按机房、业务标签、健康状态筛选。
|
||
|
||
### 做什么 / 不做什么
|
||
|
||
- ✅ 跨机房服务信息聚合，统一检索视图
|
||
- ✅ 按机房、业务标签、健康状态筛选
|
||
- ❌ 不管理服务注册本身的生命周期（注册、注销），由各机房注册中心自行处理
|
||
|
||
> **用户故事**：SRE 小王在服务目录中搜索某个服务名，看到该服务在 4 个机房有注册，其中 1 个机房有 2 个实例不健康，立即定位到问题机房。SRE 小张通过业务标签筛选，快速获取某业务线接入的所有服务清单。
|
||
|
||
---
|
||
|
||
## 痛点 9：基础组件部署没有标准，各凭经验
|
||
|
||
谁部署谁的风格，配置五花八门，部署完还要手动注册。
|
||
|
||
| | 不使用 XINFRA | 使用 XINFRA |
|
||
|------|--------------|------------|
|
||
| 组件部署 | 谁部署谁的风格，配置五花八门，部署完还要手动注册 | 标准化流程，所有人部署出来一样，部署完自动注册 |
|
||
|
||
### 我们怎么解决
|
||
|
||
将标准化基础组件封装为服务卡片，SRE 通过界面选择业务线、架构模式、规格等参数，后台自动完成标准化部署，部署完成后自动注册到对应子系统。
|
||
|
||
### 做什么 / 不做什么
|
||
|
||
- ✅ 基础服务标准化流程部署，基于 Ansible Playbook 自动完成部署，部署后自动注册
|
||
- ❌ 复杂编排操作（回滚、扩缩容、HPA 等高级 K8s 操作）仍通过跳转 Wayne 完成
|
||
|
||
> **用户故事**：SRE 小王需要为 Kodo 部署 MySQL，在服务目录选择 MySQL 卡片，填写业务线、架构模式、规格等参数，确认后自动部署。部署完成后，实例自动注册到 CloudDM。不同 SRE 部署出来的配置完全一致，不再依赖个人经验。
|
||
|
||
---
|
||
|
||
## 痛点 10：运维任务执行后无法追踪
|
||
|
||
运维任务执行过程中无法实时查看进度，事后排查也找不到完整日志。
|
||
|
||
| | 不使用 XINFRA | 使用 XINFRA |
|
||
|------|--------------|------------|
|
||
| 任务追踪 | 任务执行了不知道进度，出了问题找不到日志 | 实时查看执行进度，所有历史日志随时翻查 |
|
||
|
||
### 我们怎么解决
|
||
|
||
任务中心集中展示主系统中产生的运维任务执行记录，实时流式输出执行日志，支持历史查询。
|
||
|
||
### 做什么 / 不做什么
|
||
|
||
- ✅ 主系统运维任务的执行记录和实时日志查看
|
||
- ✅ 历史任务查询和日志回溯
|
||
- ❌ 子系统内部的任务调度和执行（如 Wayne 的发布流水线）由各子系统自行管理
|
||
|
||
> **用户故事**：SRE 小王提交了一个节点加入任务后，在任务中心看到任务状态为「执行中」，实时查看每一步的执行日志，发现某步卡住时及时介入。一周后需要排查某次部署失败的原因，在任务中心的历史记录中找到该任务，查看完整日志定位问题。
|
||
|
||
---
|
||
|
||
## 痛点 11：监控告警分散在多个系统
|
||
|
||
三套监控系统来回看，告警分散，容易漏掉。某个机房的物理机出问题，可能要等用户报障才发现。
|
||
|
||
| | 不使用 XINFRA | 使用 XINFRA |
|
||
|------|--------------|------------|
|
||
| 监控告警 | 三套监控系统来回看，告警分散，容易漏掉 | 一个看板看全貌，告警按严重程度排列，发现即定位 |
|
||
|
||
### 我们怎么解决
|
||
|
||
提供资源状态看板，整合物理机、虚机、基础服务三层的健康状态。统一展示告警，按严重程度分类，标注来源。
|
||
|
||
### 做什么 / 不做什么
|
||
|
||
- ✅ 资源状态看板，聚合三层健康状态
|
||
- ✅ 统一告警展示，按严重程度分类，标注来源系统
|
||
- ❌ 不负责告警规则引擎和数据采集，底层仍由各监控系统独立运行
|
||
|
||
> **用户故事**：SRE 小王打开告警看板，看到当前所有高级别告警，按来源区分是硬件告警还是业务告警，快速判断故障范围。SRE 小张发现某个机房物理机健康率下降，通过看板看到具体告警信息后联系机房运维。SRE 小王还发现 Kodo 的 MySQL 有 2 个实例异常，直接从看板跳转排查。
|
||
|
||
---
|
||
|
||
## 痛点 12：不知道全局资源还有多少余量
|
||
|
||
各机房的资源使用情况分散在不同系统中，做容量规划时缺乏全局视角。
|
||
|
||
| | 不使用 XINFRA | 使用 XINFRA |
|
||
|------|--------------|------------|
|
||
| 资源余量 | 资源使用情况散在各处，做规划全凭感觉 | 一个页面看全貌，哪个业务线用了多少、哪里还有空闲，一目了然 |
|
||
|
||
### 我们怎么解决
|
||
|
||
资源大盘提供跨机房资源的全局快照：集群数、节点总数、资源分配率、实例总数。以机房为维度展示节点分布，空闲节点一目了然。
|
||
|
||
### 做什么 / 不做什么
|
||
|
||
- ✅ 跨机房资源全局快照，提供容量规划的数据依据
|
||
- ✅ 以机房为维度展示资源分配率和空闲节点
|
||
- ❌ 不做自动扩缩容决策，资源规划仍由 SRE 团队根据数据判断
|
||
|
||
> **用户故事**：SRE 小王每天早上打开资源大盘，一眼看到七个机房的集群数、资源分配率和实例总数。通过节点分布图直观看到各业务线在各机房的节点分布和空闲节点，为扩容计划提供数据依据。
|
||
|
||
---
|
||
|
||
## 痛点 13：集群和节点管理操作繁琐
|
||
|
||
新节点加入集群需要手动执行一系列操作，不同集群的信息也需要逐个登录查看。
|
||
|
||
| | 不使用 XINFRA | 使用 XINFRA |
|
||
|------|--------------|------------|
|
||
| 集群管理 | 加入一个节点要手动操作好几步，集群信息逐个登录查看 | 填几个信息提交，自动完成加入；所有集群一个页面看完 |
|
||
|
||
### 我们怎么解决
|
||
|
||
提供集群列表和节点列表的统一视图，以及节点加入向导——选择目标集群、输入节点 IP、指定业务线，提交后后台自动完成所有加入步骤。
|
||
|
||
### 做什么 / 不做什么
|
||
|
||
- ✅ 集群列表和节点列表统一视图，所有机房一个页面看完
|
||
- ✅ 节点加入向导，后台自动完成加入全流程
|
||
- ❌ 不做 K8s 集群内部的高级操作（节点驱逐、集群扩缩容等），仍通过跳转 Wayne 完成
|
||
|
||
> **用户故事**：SRE 小张需要为 LAS 扩容一个节点，通过节点加入向导选择目标集群、输入节点 IP、指定业务线，提交后后台自动完成节点加入全流程。SRE 小王在集群列表中看到所有机房的集群健康状态和资源使用率，对存在告警的集群一眼识别。
|