> ## Documentation Index
> Fetch the complete documentation index at: https://doc.lwops.cn/llms.txt
> Use this file to discover all available pages before exploring further.
# 业务洞察实践（通用）
操作手册：[业务拓扑操作手册](https://doc.lwops.cn/business-topology)
**核心结论：业务洞察以业务为核心，将 IT 资源与业务系统关联，让运维从“看设备”转向“看业务”。**
## 1. 适用场景
适用于业务系统数量多、单个业务依赖多个 IT 资源的客户环境。资源异常时，仅看设备指标难以判断业务影响，需要建立面向业务的统一监控视角。
| 环境特点 | 典型表现 | 业务洞察如何解决 |
| ------- | ---------------------- | --------------------- |
| 业务系统多 | 不同业务由不同人员负责，系统管理分散 | 按业务负责人建立业务目录 |
| 业务关系复杂 | 一个业务涉及服务器、数据库、中间件等多类资源 | 通过业务拓扑关联业务与 IT 资源 |
| 业务状态难判断 | 资源指标正常，但无法判断业务体验 | 综合资源指标、服务质量和健康度判断业务状态 |
| 故障定位困难 | 出现异常后需要逐层排查资源 | 从业务视角下钻定位异常资源 |
## 2. 为什么要建设业务洞察
痛点：只有设备监控，看得见指标，却看不懂业务。
告警来了，值班人员看到的是 IP、主机名和一条技术描述；但最需要立刻回答的是：影响哪个业务、该找谁、下一步看哪里。
* 设备告警无法说明业务影响，紧急程度只能靠个人经验判断。
* 一个业务涉及多类资源，排查需要在多个视图间切换。
* 资源指标看似正常，业务体验仍可能异常，缺少业务侧判断口径。
* 业务负责人、厂商和资源归属分散在台账里，告警发生后先花时间找人。
设备监控解决“有没有告警”；业务洞察解决“影响什么业务、由谁负责、从哪里继续查”。
## 3. 业务洞察最佳实践
**核心设计思路：** 采用“业务负责人 → 业务系统 → IT 资源”的组织模型，先让业务有责任人，再让资源有业务归属，最后校准资源关系和采集体量。
**3.1 规划业务目录树**
按实际业务管理职责建立目录：业务负责人作为一级目录，其负责的业务系统归入目录下。业务异常时，目录本身就能给出责任边界。
| 业务树 | 业务系统 |
| ---------- | --------------------- |
| 张三（客户服务业务） | 客户管理系统、客服工单系统、保单查询系统 |
| 李四（核心保险业务） | 核心承保系统、理赔管理系统、保全管理系统 |
| 王五（销售渠道业务） | 代理人管理系统、移动展业系统、经纪业务系统 |
| 赵六（数据分析业务） | 数据仓库平台、经营分析平台、报表管理系统 |
配置要点：目录树先求准确、再求完整：先覆盖核心业务和明确的责任人，再逐步补充其他业务
业务目录树示例
业务拓扑配置示例
业务拓扑图展示
**3.2 将业务系统与 IT 资源关联**
目录树规划后，先找业务负责人调研，而不是直接开自动发现。调研结果决定发现范围、资源归属和校准基准。
| 调研项 | 要确认的内容 | 用途 |
| ----- | --------------------- | --------------- |
| IP 范围 | 业务独占网段、共用网段、云主机地址 | 限定自动发现和资源归属范围 |
| 业务端口 | 操作系统、数据库、中间件、Web 服务端口 | 确认业务组件，减少无效采集 |
| 旧拓扑图 | 厂商交付拓扑、旧系统拓扑、架构图 | 作为资源关系和发现结果校准基准 |
| 责任信息 | 业务负责人、厂商联系人、运维分工 | 让告警直达责任边界 |
用调研出的 IP 范围和端口配置自动发现后，建议按下面顺序整理结果：
* **先对照旧拓扑**：发现结果不要直接当作业务拓扑，先和厂商交付图或旧系统拓扑对照，确认资源是否完整、归属是否正确。
* **补齐容易漏掉的资源**：自动发现通常依赖流量，只开启本地监听的服务容易漏发现，这类关键资源需要人工补到对应业务下。
* **确认后再挂载**：多出来的资源不要直接挂进业务树，先确认是否真的属于该业务；归属不清的先保持监控，后续再补充。
* **控制采集体量**：如果发现内容过多，回收不必要的 IP 范围，只保留业务端口和核心指标，足够支撑业务判断即可。
落地顺序：先明确业务负责人，再建立业务目录；先调研资源范围，再配置自动发现；先校准关键业务资源，再扩展采集体量。
## 4. 典型应用场景
### 场景一：日常巡检
问题：逐台检查主机、数据库、中间件，耗时长且容易漏重点。
解决：对核心业务配置每日巡检，覆盖 CPU、内存、文件系统和数据库死锁等数据
效果：先看业务健康和异常清单，再决定是否下钻资源，巡检标准固定、结果可追溯。
### 场景二：业务波动观测
问题： 核心业务存在明显高峰和低谷，异常波动难以被及时发现。
解决： 选择 CPU、内存、文件系统使用率等关键指标，按指标类型聚合，展示最近 24 小时趋势，并结合历史数据观察变化。
效果： 直观看到每日高峰时段和异常波动，为资源调整和风险预判提供依据。
### 场景三：业务异常快速定位
问题： 业务异常后，需要判断来源是业务本身、主机、数据库还是中间件。
解决： 进入异常业务的业务拓扑，查看关联资源及对应指标，再逐层下钻定位异常。
效果： 从业务视角快速缩小故障范围，减少逐台设备排查。
