Qiniu/xinfra/requirements.md

tags, create time

tags	create time
xinfra requirements infra	2026-07-08 13:54

XINFRA 平台需求文档

概述

XINFRA 是计划建设的面向 SRE 团队的统一基础设施管理平台，覆盖 Kodo、LAS、灵矽、LTOKEN、MAAS 五条业务线。

mindmap
  root((XINFRA))
    统一入口
      门户与登录
    资源
      CMDB多云同步
      集群管理
      资源大盘
    数据存储
      数据库审核与脱敏
      缓存监控与诊断
    运维
      容器编排
      配置下发
      标准化部署
      任务中心
    监控
      状态看板
    告警
      统一告警

本文档从 SRE 日常工作中的痛点出发，说明 XINFRA 计划如何通过一站式平台解决这些问题。

---

痛点 1：多系统来回切换，登录疲劳

SRE 日常工作涉及 6+ 个系统，每个系统有独立地址和账号，每天在不同系统间反复切换登录。

	不使用 XINFRA	使用 XINFRA
登录	每天在 6+ 个系统间切换，每个系统一套账号密码	一个入口，登录一次，所有系统直接进

我们怎么解决

提供统一门户，所有子系统以卡片形式集中展示，一次登录、全系统通行。

用户故事：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 对接自动化部署、生产环境部署增加审批卡点。

用户故事：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 的写入能力。原因：

维度	在 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
任务追踪	任务执行了不知道进度，出了问题找不到日志	实时查看执行进度，所有历史日志随时翻查

我们怎么解决

任务中心集中展示主系统中产生的运维任务执行记录，实时流式输出执行日志，支持历史查询。

用户故事：SRE 小王提交了一个节点加入任务后，在任务中心看到任务状态为「执行中」，实时查看每一步的执行日志，发现某步卡住时及时介入。一周后需要排查某次部署失败的原因，在任务中心的历史记录中找到该任务，查看完整日志定位问题。

---

痛点 11：监控告警分散在多个系统

三套监控系统来回看，告警分散，容易漏掉。某个机房的物理机出问题，可能要等用户报障才发现。

	不使用 XINFRA	使用 XINFRA
监控告警	三套监控系统来回看，告警分散，容易漏掉	一个看板看全貌，告警按严重程度排列，发现即定位

我们怎么解决

提供资源状态看板，整合物理机、虚机、基础服务三层的健康状态。统一展示告警，按严重程度分类，标注来源。

用户故事：SRE 小王打开告警看板，看到当前所有高级别告警，按来源区分是硬件告警还是业务告警，快速判断故障范围。SRE 小张发现某个机房物理机健康率下降，通过看板看到具体告警信息后联系机房运维。SRE 小王还发现 Kodo 的 MySQL 有 2 个实例异常，直接从看板跳转排查。

---

痛点 12：不知道全局资源还有多少余量

各机房的资源使用情况分散在不同系统中，做容量规划时缺乏全局视角。

	不使用 XINFRA	使用 XINFRA
资源余量	资源使用情况散在各处，做规划全凭感觉	一个页面看全貌，哪个业务线用了多少、哪里还有空闲，一目了然

我们怎么解决

资源大盘提供跨机房资源的全局快照：集群数、节点总数、资源分配率、实例总数。以机房为维度展示节点分布，空闲节点一目了然。

用户故事：SRE 小王每天早上打开资源大盘，一眼看到七个机房的集群数、资源分配率和实例总数。通过节点分布图直观看到各业务线在各机房的节点分布和空闲节点，为扩容计划提供数据依据。

---

痛点 13：集群和节点管理操作繁琐

新节点加入集群需要手动执行一系列操作，不同集群的信息也需要逐个登录查看。

	不使用 XINFRA	使用 XINFRA
集群管理	加入一个节点要手动操作好几步，集群信息逐个登录查看	填几个信息提交，自动完成加入；所有集群一个页面看完

我们怎么解决

提供集群列表和节点列表的统一视图，以及节点加入向导——选择目标集群、输入节点 IP、指定业务线，提交后后台自动完成所有加入步骤。

用户故事：SRE 小张需要为 LAS 扩容一个节点，通过节点加入向导选择目标集群、输入节点 IP、指定业务线，提交后后台自动完成节点加入全流程。SRE 小王在集群列表中看到所有机房的集群健康状态和资源使用率，对存在告警的集群一眼识别。