4. 系统性能基线建立

性能基线不是一组“好看的截图”，而是一份可复现、可对比、可追溯的量化参照。它的价值在于：当业务方反馈“系统变慢了”，你能立刻回答三个问题——慢在哪个层级、偏离基线多少、从哪个时间点开始偏离。建立基线需要先定义指标，再用受控方法采集基准值，最后把持续采集的数据与基准值做趋势比对。

一、关键指标定义：分层与口径统一

S/4HANA 的性能指标必须分层定义，否则会出现“应用层说慢、数据库层说快”的口径冲突。建议按四层组织：

• 用户体验层：事务平均响应时间（如 VA01 保存平均 1.8 s）、SAP GUI 往返时间、Fiori 页面首屏加载时间、超时率。
• 应用层：对话工作进程（DIA）平均响应时间、对话步骤数、请求在队列中的等待时间、RFC 调用耗时、后台作业运行时长。
• 数据库层：SQL 语句平均执行时间、逻辑读/物理读次数、锁等待时间、HANA 语句执行计划中的算子耗时。
• 资源层：CPU 使用率、内存占用（含 HANA 列存与行存）、磁盘 IOPS 与吞吐、网络延迟、HANA 内存池命中率。

每个指标必须明确口径：统计周期（如 5 分钟均值还是日峰值）、采样对象（全部用户还是特定事务码）、排除条件（是否剔除批量作业时段）。例如“对话响应时间”应区分前台交互与后台批处理，否则基线会被夜间作业拉偏。建议为每个指标记录：指标名、单位、采集频率、数据来源（ST03N、DBACOCKPIT、HANA 视图、OS 监控）、告警阈值。

二、基准测试方法：受控、可重复、有对照

基准测试的核心是控制变量。推荐采用“固定场景 + 固定数据量 + 固定并发”的三固定原则。以一个采购订单创建场景为例：

1. 准备测试数据：固定 10 万条采购订单历史，物料主数据 5 万条，供应商 1 万条。
2. 固定并发：使用 eCATT 或 SAP GUI 脚本模拟 20 个并发用户，每个用户执行 50 次 VA01 创建并保存。
3. 采集窗口：预热 5 分钟后开始记录，持续 30 分钟，取稳定段均值。
4. 记录环境：应用服务器数量、HANA 节点规格、网络带宽、是否启用缓存，全部写入测试报告。

基准测试至少做两轮：第一轮建立初始基线，第二轮在相同条件下复测，验证波动范围。若两轮偏差超过 10%，说明环境或数据不稳定，需排查后再定基线。对于 HANA 数据库，可额外使用 HANA 自带的 hdbcli 或 HANA Studio 执行 SQL 基准，记录语句执行计划与算子耗时，作为数据库层基线。

三、性能数据采集：从被动到主动

采集要覆盖“实时—小时—天”三个粒度。实时采集用于故障定位，小时级用于趋势观察，天级用于容量规划。常用采集点包括：

• ST03N / ST03：按事务码、用户、任务类型统计响应时间与数据库时间。
• SM50 / SM66：工作进程状态与当前请求，用于判断是否出现进程阻塞。
• ST05 / ST12：SQL 跟踪与 ABAP 跟踪，用于单次请求的深度剖析。
• DBACOCKPIT / HANA 视图：M_SQL_PLAN_CACHE、M_ACTIVE_STATEMENTS、M_SERVICE_MEMORY 等，观察 SQL 与内存。
• OS 层：sar、nmon、top 采集 CPU、内存、IO、网络。

采集频率建议：实时指标 10 秒一次，小时指标 5 分钟聚合一次，天指标每日 00:05 汇总前一日数据。所有采集数据应写入统一的时间序列库或至少按日期归档，保留周期不少于 90 天，以便做同比与环比。

四、趋势分析与基线偏离判断

趋势分析的目标是识别“缓慢劣化”而非“突发故障”。常用方法有三种：

1. 移动平均对比：计算 7 日移动平均，与基线均值比较。若连续 3 天偏离超过 15%，触发预警。
2. 分位数分析：关注 P95 和 P99 响应时间，而非仅看平均值。平均值正常但 P99 恶化，往往意味着少数用户已受影响。
3. 相关性分析：将响应时间与并发用户数、数据库逻辑读、CPU 使用率做散点图，判断瓶颈是否随负载线性增长。

判断基线偏离时，建议按“偏离幅度 + 持续时间 + 影响范围”三维定级：偏离 15% 以内为观察，15%～30% 且持续 1 小时为关注，超过 30% 或影响核心事务为告警。每次告警都应记录：时间点、指标、当前值、基线值、偏离率、初步排查结论。

五、基线维护与落地建议

基线建立后，需要指定责任人定期复核。建议每月做一次基线回顾：检查指标口径是否仍适用、采集是否中断、阈值是否需要调整。对于核心事务（如财务过账、销售开票、物料移动），应单独建立事务级基线，而不是只依赖系统级平均值。基线数据应纳入变更管理流程：任何影响性能的变更（补丁、配置、数据量增长）都应在变更后 24 小时内复测关键指标，并与基线对比，形成闭环。

最后，基线不是越细越好。指标过多会导致采集开销和告警疲劳。建议每个层级保留 3～5 个核心指标，确保每个指标都有明确的采集来源、判断阈值和责任人。这样，当性能问题出现时，团队能沿着“用户层→应用层→数据库层→资源层”的链路快速定位，而不是在大量数据中盲目翻找。