docs: add pain point analysis before each user story scenario

decks/xinfra/slides.md

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