12 KiB
tags, create time
| tags | create time | |||
|---|---|---|---|---|
|
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 | |
|---|---|---|
| 责任追溯 | 出了问题不知道谁操作过，排查全靠问人 | 每次操作自动记录，谁、什么时间、做了什么，一查便知 |
我们怎么解决
主系统内置审计面板，记录每一次登录事件和运维操作，支持按时间、操作人、操作类型筛选查询。
用户故事：SRE 小王发现昨天有人在运维终端执行了节点操作，打开审计面板按时间筛选，立刻定位到具体操作人和操作内容。普通操作员 SRE 小张只能看到自己的登录记录，管理员老刘则能查看全局审计日志。
痛点 3：容器部署依赖手工操作，出了错难回滚
部署服务需要手动操作，操作过程没有记录，出了问题回滚慢、靠经验。七个机房的集群各自管理，缺乏统一视图。
| 不使用 XINFRA | 使用 XINFRA | |
|---|---|---|
| 发布服务 | 手动操作，过程没记录，出问题回滚慢、靠经验 | 界面上点几下完成发布，有历史记录，一键回滚 |
我们怎么解决
通过 Wayne 平台提供容器部署的统一操作面：界面化部署、发布历史与一键回滚、API 对接自动化部署、生产环境部署增加审批卡点。
用户故事：SRE 小王需要部署新服务到 Kodo 的集群，在 Wayne 界面选择集群、填写镜像 tag 和副本数，一键完成部署。上线后发现有异常，在发布历史中找到上一个稳定版本，一键回滚。生产环境的部署请求自动流转给老刘审批。
痛点 4：生产数据库操作缺少审核，风险高
当前可以直连线上数据库操作，没有审核流程，改错了直接影响用户。
| 不使用 XINFRA | 使用 XINFRA | |
|---|---|---|
| 数据库安全 | 直接连线上数据库操作，改错了直接影响用户 | 所有线上改动必须经过审核，不允许直接操作 |
我们怎么解决
通过 CloudDM 管理所有数据库操作，所有线上改动必须经过工单审核流程，禁止直连。查询结果中的敏感字段自动脱敏。
用户故事：SRE 小王需要在生产 MySQL 执行一条线上变更，在 CloudDM 提交工单，系统自动预检风险，通过后等待 DBA 审核，审核通过后自动执行。SRE 小张需要查询业务库数据做排查，在 CloudDM 申请临时查询权限，在线查询时敏感字段自动脱敏。出了问题，管理员老刘可以通过审计记录追溯完整的操作链路。
痛点 5：缓存实例散落各处，运维靠记忆
各业务线的缓存实例分散部署，全貌看不见。哪个业务线有多少实例、内存用了多少、有没有异常，需要逐个登录机器查看。
| 不使用 XINFRA | 使用 XINFRA | |
|---|---|---|
| 缓存管理 | 各业务线自己管自己的缓存，全貌看不见 | 统一管理，整体状况一个页面看清，异常自动发现 |
我们怎么解决
通过 CacheCloud 统一管理所有缓存实例的申请、部署、监控和回收。提供诊断工具，临时实例到期自动回收。
用户故事：SRE 小王需要为 Kodo 申请缓存集群，在 CacheCloud 选择架构模式和内存规格，提交后自动创建并注册。SRE 小张发现某实例响应变慢，用 CacheCloud 的诊断工具定位到一个大 Key。SRE 小李之前申请的测试实例到期后被自动回收，不再需要手动清理。
痛点 6：多机房配置变更靠逐台操作
服务配置分散在各机房，变更时需要逐机房登录修改，改漏一个就出故障，没法撤回。
| 不使用 XINFRA | 使用 XINFRA | |
|---|---|---|
| 配置变更 | 7 个机房逐个改，改漏一个就出故障，没法撤回 | 改一次自动下发所有机房，改错了能立刻回滚 |
我们怎么解决
通过 Apollo 配置中心实现所有机房配置的统一管理，在一个入口修改后统一下发各机房，支持灰度发布和版本回滚。
用户故事：SRE 小王需要修改某个服务在所有机房的配置，在 Apollo Portal 统一修改后发布，无需逐机房操作。发布后发现配置有问题，快速回滚到上一版本。SRE 小张在 XINFRA 上查看各机房 Apollo 的接入状态，掌握配置中心整体情况。
痛点 7：资源台账散落在多个平台
服务器信息散在好几个平台，查一台机器要登录好几个地方。
| 不使用 XINFRA | 使用 XINFRA | |
|---|---|---|
| 资源台账 | 服务器信息散在好几个平台，查一台机器要登录好几个地方 | 一个页面查到所有服务器，按业务线、机房随便筛 |
我们怎么解决
以 CMDB 为基础数据底座，定时从各云平台同步虚机信息，形成统一的资源台账。支持按资源类型、来源、业务线、机房等条件组合筛选。同步不会覆盖 CMDB 中人工维护的数据。
用户故事：SRE 小王打开资源台账，看到所有资源的来源统计和最近同步状态。需要查找某台机器时，按业务线和机房筛选，快速定位。SRE 小张发现某台虚机信息需要补充，在台账中标记为人工维护，后续云同步不会覆盖这些字段。需要申请新虚机时，通过台账的「创建虚机」入口直接跳转。
痛点 8：服务注册信息分散，跨机房查找困难
各机房的服务注册中心独立运行，想知道某个服务在哪些机房部署了、健康状态如何，需要逐个登录各机房查看。
| 不使用 XINFRA | 使用 XINFRA | |
|---|---|---|
| 服务查找 | 逐个机房登录查服务，找一个服务要登好几个地方 | 一个页面搜到所有机房的服务，健康状态一目了然 |
我们怎么解决
定时从各机房同步服务信息，提供跨机房的服务统一检索视图，支持按机房、业务标签、健康状态筛选。
用户故事：SRE 小王在服务目录中搜索某个服务名，看到该服务在 4 个机房有注册，其中 1 个机房有 2 个实例不健康，立即定位到问题机房。SRE 小张通过业务标签筛选，快速获取某业务线接入的所有服务清单。
痛点 9：基础组件部署没有标准，各凭经验
谁部署谁的风格，配置五花八门，部署完还要手动注册。
| 不使用 XINFRA | 使用 XINFRA | |
|---|---|---|
| 组件部署 | 谁部署谁的风格，配置五花八门，部署完还要手动注册 | 标准化流程，所有人部署出来一样，部署完自动注册 |
我们怎么解决
将标准化基础组件封装为服务卡片，SRE 通过界面选择业务线、架构模式、规格等参数，后台自动完成标准化部署，部署完成后自动注册到对应子系统。
用户故事：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 小王在集群列表中看到所有机房的集群健康状态和资源使用率，对存在告警的集群一眼识别。