vault backup: 2026-07-16 17:30:07
This commit is contained in:
+65
-5
@@ -48,6 +48,12 @@ SRE 日常工作涉及 6+ 个系统，每个系统有独立地址和账号，每
|
||||
|
||||
提供统一门户，所有子系统以卡片形式集中展示，一次登录、全系统通行。
|
||||
|
||||
### 做什么 / 不做什么
|
||||
|
||||
- ✅ SSO 单点登录，主系统顶部导航栏常驻，子系统以卡片形式集中展示
|
||||
- ✅ 子系统以 iframe 方式嵌入，提供统一访问入口
|
||||
- ❌ 不改造子系统的登录系统，不存储子系统的账号密码
|
||||
|
||||
> **用户故事**：SRE 小王早上打开 XINFRA，看到所有子系统的卡片和接入状态。点击 CacheCloud 卡片，直接跳转过去，无需再次输入密码。新入职的 SRE 小李只需记住 XINFRA 一个地址，就能找到所有运维相关系统。
|
||||
|
||||
---
|
||||
@@ -64,6 +70,13 @@ SRE 日常工作涉及 6+ 个系统，每个系统有独立地址和账号，每
|
||||
|
||||
主系统内置审计面板，记录**谁在什么时间进入了哪个子系统**，以及**在主系统本身执行的操作**（如节点加入向导、配置查看等），支持按时间、操作人、操作类型筛选查询。
|
||||
|
||||
### 做什么 / 不做什么
|
||||
|
||||
- ✅ 统一审计面板，记录主系统内所有操作（谁、什么时间、做了什么）
|
||||
- ✅ 记录用户进出子系统的入口跳转事件
|
||||
- ❌ 不侵入子系统内部，子系统操作详情由各子系统自行记录
|
||||
- ❌ 不负责跨子系统的操作关联和链路拼接
|
||||
|
||||
**注意**：子系统内部的操作详情（如 Wayne 里的部署动作、CacheCloud 里的配置变更）由各子系统自行记录。主系统提供从审计面板跳转到对应子系统审计日志的入口，便于链路追溯。
|
||||
|
||||
### 战略决策：为什么不将子系统操作统一纳入主系统审计？
|
||||
@@ -93,6 +106,12 @@ SRE 日常工作涉及 6+ 个系统，每个系统有独立地址和账号，每
|
||||
|
||||
通过 Wayne 平台提供容器部署的统一操作面：界面化部署、发布历史与一键回滚、API 对接自动化部署、生产环境部署增加审批卡点。
|
||||
|
||||
### 做什么 / 不做什么
|
||||
|
||||
- ✅ 统一部署界面，支持配置镜像、副本数等参数，一键完成部署
|
||||
- ✅ 发布历史记录和一键回滚能力
|
||||
- ❌ 复杂编排操作（扩缩容策略、HPA、滚动更新等高级 K8s 操作）仍通过跳转 Wayne 完成
|
||||
|
||||
> **用户故事**：SRE 小王需要部署新服务到 Kodo 的集群，在 Wayne 界面选择集群、填写镜像 tag 和副本数，一键完成部署。上线后发现有异常，在发布历史中找到上一个稳定版本，一键回滚。生产环境的部署请求自动流转给老刘审批。
|
||||
|
||||
---
|
||||
@@ -109,7 +128,7 @@ SRE 日常工作涉及 6+ 个系统，每个系统有独立地址和账号，每
|
||||
|
||||
通过 CloudDM 管理所有数据库操作，所有线上改动必须经过工单审核流程，禁止直连。查询结果中的敏感字段自动脱敏。
|
||||
|
||||
**做什么 / 不做什么**
|
||||
### 做什么 / 不做什么
|
||||
|
||||
- ✅ 主要做入口接入
|
||||
- ❌ SQL 执行/变更操作本身由 CloudDM 处理，XINFRA 不直接执行数据库操作
|
||||
@@ -130,7 +149,7 @@ SRE 日常工作涉及 6+ 个系统，每个系统有独立地址和账号，每
|
||||
|
||||
通过 CacheCloud 统一管理所有缓存实例的申请、部署、监控和回收。提供诊断工具，临时实例到期自动回收。
|
||||
|
||||
**做什么 / 不做什么**
|
||||
### 做什么 / 不做什么
|
||||
|
||||
- ✅ 集群指标聚合监控、诊断分析（命中率、热点 Key 等），为优化提供数据支撑
|
||||
- ❌ 缓存实例的具体操作（删除、过期策略调整等）由 CacheCloud 处理，XINFRA 不直接执行缓存操作
|
||||
@@ -151,7 +170,7 @@ SRE 日常工作涉及 6+ 个系统，每个系统有独立地址和账号，每
|
||||
|
||||
通过 Apollo 配置中心实现所有机房配置的统一管理，在一个入口修改后统一下发各机房，支持灰度发布和版本回滚。
|
||||
|
||||
**做什么 / 不做什么**
|
||||
### 做什么 / 不做什么
|
||||
|
||||
- ✅ 配置信息汇总展示、简单配置项查看与修改
|
||||
- ❌ 复杂配置模板、多环境同步、版本管理等高级功能仍通过跳转 Apollo 完成
|
||||
@@ -176,7 +195,18 @@ SRE 日常工作涉及 6+ 个系统，每个系统有独立地址和账号，每
|
||||
|
||||
### 战略决策：为什么不直接在 XINFRA 上做 CMDB 的增改查？
|
||||
|
||||
XINFRA 只做查找和展示，不替代 CMDB 的写入能力。原因：
|
||||
XINFRA 只做查找和展示，不替代 CMDB 的写入能力。
|
||||
|
||||
**做什么**：
|
||||
- 聚合各平台服务器信息，提供统一的只读查询视图
|
||||
- 从各云平台单向同步虚机数据，不覆盖 CMDB 中人工维护的字段
|
||||
- 提供跳转到 CMDB / 各云平台的入口，便于后续操作
|
||||
|
||||
**不做什么**：
|
||||
- 不替代 CMDB 做资产增改，CMDB 仍是唯一写入源
|
||||
- 不做双向同步，避免写入冲突和脏数据
|
||||
|
||||
**为什么**：
|
||||
|
||||
| 维度 | 在 XINFRA 上做完整 CRUD | 只做查找与展示 |
|
||||
|------|------|------|
|
||||
@@ -199,6 +229,12 @@ XINFRA 只做查找和展示，不替代 CMDB 的写入能力。原因：
|
||||
|
||||
定时从各机房同步服务信息，提供跨机房的服务统一检索视图，支持按机房、业务标签、健康状态筛选。
|
||||
|
||||
### 做什么 / 不做什么
|
||||
|
||||
- ✅ 跨机房服务信息聚合，统一检索视图
|
||||
- ✅ 按机房、业务标签、健康状态筛选
|
||||
- ❌ 不管理服务注册本身的生命周期（注册、注销），由各机房注册中心自行处理
|
||||
|
||||
> **用户故事**：SRE 小王在服务目录中搜索某个服务名，看到该服务在 4 个机房有注册，其中 1 个机房有 2 个实例不健康，立即定位到问题机房。SRE 小张通过业务标签筛选，快速获取某业务线接入的所有服务清单。
|
||||
|
||||
---
|
||||
@@ -215,7 +251,7 @@ XINFRA 只做查找和展示，不替代 CMDB 的写入能力。原因：
|
||||
|
||||
将标准化基础组件封装为服务卡片，SRE 通过界面选择业务线、架构模式、规格等参数，后台自动完成标准化部署，部署完成后自动注册到对应子系统。
|
||||
|
||||
**做什么 / 不做什么**
|
||||
### 做什么 / 不做什么
|
||||
|
||||
- ✅ 基础服务标准化流程部署，基于 Ansible Playbook 自动完成部署，部署后自动注册
|
||||
- ❌ 复杂编排操作（回滚、扩缩容、HPA 等高级 K8s 操作）仍通过跳转 Wayne 完成
|
||||
@@ -236,6 +272,12 @@ XINFRA 只做查找和展示，不替代 CMDB 的写入能力。原因：
|
||||
|
||||
任务中心集中展示主系统中产生的运维任务执行记录，实时流式输出执行日志，支持历史查询。
|
||||
|
||||
### 做什么 / 不做什么
|
||||
|
||||
- ✅ 主系统运维任务的执行记录和实时日志查看
|
||||
- ✅ 历史任务查询和日志回溯
|
||||
- ❌ 子系统内部的任务调度和执行（如 Wayne 的发布流水线）由各子系统自行管理
|
||||
|
||||
> **用户故事**：SRE 小王提交了一个节点加入任务后，在任务中心看到任务状态为「执行中」，实时查看每一步的执行日志，发现某步卡住时及时介入。一周后需要排查某次部署失败的原因，在任务中心的历史记录中找到该任务，查看完整日志定位问题。
|
||||
|
||||
---
|
||||
@@ -252,6 +294,12 @@ XINFRA 只做查找和展示，不替代 CMDB 的写入能力。原因：
|
||||
|
||||
提供资源状态看板，整合物理机、虚机、基础服务三层的健康状态。统一展示告警，按严重程度分类，标注来源。
|
||||
|
||||
### 做什么 / 不做什么
|
||||
|
||||
- ✅ 资源状态看板，聚合三层健康状态
|
||||
- ✅ 统一告警展示，按严重程度分类，标注来源系统
|
||||
- ❌ 不负责告警规则引擎和数据采集，底层仍由各监控系统独立运行
|
||||
|
||||
> **用户故事**：SRE 小王打开告警看板，看到当前所有高级别告警，按来源区分是硬件告警还是业务告警，快速判断故障范围。SRE 小张发现某个机房物理机健康率下降，通过看板看到具体告警信息后联系机房运维。SRE 小王还发现 Kodo 的 MySQL 有 2 个实例异常，直接从看板跳转排查。
|
||||
|
||||
---
|
||||
@@ -268,6 +316,12 @@ XINFRA 只做查找和展示，不替代 CMDB 的写入能力。原因：
|
||||
|
||||
资源大盘提供跨机房资源的全局快照：集群数、节点总数、资源分配率、实例总数。以机房为维度展示节点分布，空闲节点一目了然。
|
||||
|
||||
### 做什么 / 不做什么
|
||||
|
||||
- ✅ 跨机房资源全局快照，提供容量规划的数据依据
|
||||
- ✅ 以机房为维度展示资源分配率和空闲节点
|
||||
- ❌ 不做自动扩缩容决策，资源规划仍由 SRE 团队根据数据判断
|
||||
|
||||
> **用户故事**：SRE 小王每天早上打开资源大盘，一眼看到七个机房的集群数、资源分配率和实例总数。通过节点分布图直观看到各业务线在各机房的节点分布和空闲节点，为扩容计划提供数据依据。
|
||||
|
||||
---
|
||||
@@ -284,4 +338,10 @@ XINFRA 只做查找和展示，不替代 CMDB 的写入能力。原因：
|
||||
|
||||
提供集群列表和节点列表的统一视图，以及节点加入向导——选择目标集群、输入节点 IP、指定业务线，提交后后台自动完成所有加入步骤。
|
||||
|
||||
### 做什么 / 不做什么
|
||||
|
||||
- ✅ 集群列表和节点列表统一视图，所有机房一个页面看完
|
||||
- ✅ 节点加入向导，后台自动完成加入全流程
|
||||
- ❌ 不做 K8s 集群内部的高级操作（节点驱逐、集群扩缩容等），仍通过跳转 Wayne 完成
|
||||
|
||||
> **用户故事**：SRE 小张需要为 LAS 扩容一个节点，通过节点加入向导选择目标集群、输入节点 IP、指定业务线，提交后后台自动完成节点加入全流程。SRE 小王在集群列表中看到所有机房的集群健康状态和资源使用率，对存在告警的集群一眼识别。
|
||||
|
||||
Reference in New Issue
Block a user