From f3b902722041c2e6747a1c36b73ff866e3a803f4 Mon Sep 17 00:00:00 2001 From: hezhaohui Date: Fri, 17 Jul 2026 23:43:23 +0800 Subject: [PATCH] docs: add pain point analysis before each user story scenario --- decks/xinfra/slides.md | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/decks/xinfra/slides.md b/decks/xinfra/slides.md index 07d0ab2..c0402c2 100644 --- a/decks/xinfra/slides.md +++ b/decks/xinfra/slides.md @@ -188,6 +188,8 @@ layout: center
+**痛点**：资源数据分散在 CMDB、云平台、K8s 集群等多个渠道，运维人员需要逐个系统登录查看，缺乏统一视图，无法快速掌握全量资源分布和容量状况。 + **场景**：运维人员登录 XINFRA 后，直接看到全量资源分布、业务线归属、节点状态和容量概览，不需要在多个 CMDB 和云平台之间来回切换。 **链路**：业务 SRE 登录 XINFRA → 选择业务线 → 平台同步 CMDB / 云平台 / RKE2 数据 → 展示全量资源大盘 @@ -223,6 +225,8 @@ sequenceDiagram
+**痛点**：业务交付涉及 Wayne、CloudDM、Apollo、Superset 等多个子系统，入口分散、各自独立认证，操作记录无法统一审计，新人不知道该用哪个系统。 + **场景**：业务 SRE 在 XINFRA 中进入"业务交付"，选择对应业务线后跳转到 Wayne、CloudDM、Apollo 或 Superset 完成实际操作，平台保留入口、上下文和审计。 **链路**：业务 SRE 登录 → 进入业务交付 → 选择业务线 → 展示子系统入口 → SSO 跳转至目标系统 → 记录审计日志 @@ -257,6 +261,8 @@ sequenceDiagram
+**痛点**：基础服务交付依赖人工操作，命令行门槛高、操作方式因人而异、缺少标准化流程，部署过程不可见，排障困难且效率低下。 + **场景**：运维人员在 XINFRA 中提交 MySQL、Redis 等基础服务交付任务，平台调用 Ansible 控制中心执行标准化部署，并在任务中心查看日志和结果。 **链路**：运维人员登录 → 选择服务卡片 → 填写业务线和规格 → 提交任务 → Ansible 执行部署 → 自动注册至子系统 → 部署完成通知 @@ -296,6 +302,8 @@ sequenceDiagram
+**痛点**：SQL 变更缺乏统一的审批流程，执行记录分散，难以追溯谁在什么时候改了什么，线下沟通成本高、手工操作易出错。 + **场景**：开发或运维提交 SQL 工单后，审核人可以在 XINFRA 中完成审批、查看执行记录和审计信息，减少线下沟通和手工操作。 **链路**：开发/运维提交 SQL 工单 → 转发至 CloudDM → 审核人审批 → 执行变更 → Sidecar 代理执行 SQL → 审计记录 → 通知完成 @@ -332,6 +340,8 @@ sequenceDiagram
+**痛点**：各系统权限按各自维度管理，缺乏统一的业务线隔离视角，运维人员无法聚焦自己负责的业务线，也无法按需切换查看跨业务线数据。 + **场景**：XINFRA 以业务线作为核心隔离维度，不同角色登录后默认看到自己负责的业务线数据，支持一键切换。系统运维可查看全局，业务 SRE 聚焦本业务线，只读用户仅能查看授权范围。 **角色**：系统运维（全局视角）、业务 SRE（本业务线）、跨业务线运维（按需切换）、只读用户（受限查看）