企业官网建设流程全解析

自定义应用上线，只是排障的开始。这话听着有点丧，但干 ABAP 的应该都懂：开发测试做得再充分，真到了生产环境，用户一操作，数据一组合，场景一叠加，你总会碰上计划外的错误。尤其是从 ABAP On-Premise 过渡到 ABAP environment（云上的 ABAP）之后，老一套排障手法突然不灵了——ST22 没了、SM21 没了、ST05 也没了，连调试器入口都变了。这篇文章我想把我这些年踩过的坑和总结出来的方法完整梳理一遍，核心是一套两套环境都能落地的排障思路，既讲清楚 On-Premise 和 ABAP environment 的工具差异，也把从接到报错到修复验证的完整流程走一遍。适合刚接手自定义应用维护的人，也适合想从本地环境转云环境开发的人参考——不同基础的人都能在里面找到可以直接照着做的部分。

1. 先想清楚：上线后到底在排什么

1.1 排障不是翻代码，而是先定位故障层

很多人一接到生产报错，第一反应是打开代码从头看到尾，这其实是最低效的做法。自定义应用在 On-Premise 和 ABAP environment 里跑着同一套逻辑，但它接触的外部因素太多了，一个生产故障的表面症状可能只是冰山一角，根因往往藏在代码之外。

我习惯把故障分成五层：

• 代码层：空引用、除零、类型转换失败、边界逻辑没覆盖。这类最直观，调试器里看到变量值就能确认。
• 数据层：脏数据、主数据配置缺失、并发覆盖、表数据没同步。这类最坑，因为代码看起来没问题，跑出来结果就是不对。
• 权限层：授权对象没配、角色没更新、数据权限范围不对。用户只会告诉你“报错了”，实际上是不让他干。
• 接口层：RFC 连接断了、外部服务超时、请求报文格式变了。这类问题通常需要两头对照。
• 环境层：系统资源不足、表锁、传输版本不一致、后台作业调度错乱。这类问题最容易骗过你的眼睛。

比如用户说“报表跑出来是空的”，代码可能有 Bug，也可能只是数据权限没配好，或者某张表的数据还没同步过来。如果你一上来就翻代码，大概率浪费时间。相反，先基于现象判断是哪个层的问题，就能直接跳到正确的工具上。

1.2 On-Premise 与 ABAP environment 的排障差异

ABAP On-Premise 和 ABAP environment 的排障逻辑本质一样，但可见度完全不一样，这是很多人转型期最不适应的点。

在本地环境，你能直接打开 ST22 看短转储，开 SM21 看系统日志，开 ST05 抓 SQL，甚至能进服务器目录翻 trace 文件，你拥有很大一块系统可见性，工具老旧但管用。到了 ABAP environment，基础设施是托管方的，你不再有那些传统事务码，只能通过基于 Fiori 的观测应用去观察系统：短转储入口变成了应用日志和系统日志，SQL 跟踪变成了 ABAP Development Tools（ADT）中的调试和 SQL 分析，进程列表、表锁这些底层状态基本不可见。另外代码改动方式也变了，不是生产系统里直接传输，而是代码推到仓库、走部署管道发布。

但这里我想强调一句：可见度变低，不代表排障能力变差。云环境的日志聚合、上下文关联、告警机制，只要用得好，定位问题的速度可能比本地还快。关键在于你认不认这个新的工具边界。

这张表的关键信息是：环境变了，入口换了，但排障思路没有变——你仍然要沿着现象找证据，只是证据放的位置变了。

1.3 通用排障四步法：锁定、收集、分层、修复

不管你是 On-Premise 还是 ABAP environment，也不管故障是崩溃、数据错误还是性能慢，流程基本是同样的四步：

1. 锁定现象。明确什么问题、什么时候发生的、影响谁、影响范围多大。这步不做，后面全是瞎猜。
2. 收集证据。把用户的报错文案、屏幕截图、输入数据、操作步骤全部拿到手。很多时候用户只会说“它坏了”，你得去问细节。
3. 分层定位。对照上面那五层，把问题限定到具体层。这步最需要经验，但你可以用“哪个层最容易产生这个现象”来做筛选，排除法比硬啃代码快得多。
4. 修复与验证。改动代码或配置之后，不是直接上生产，而是先回归测试，再发布，并观察一段时间。

这套四步法我在两个环境里都用，区别只是第 3 步里工具入口不同。后面几章我会按故障类型把细节填进去。

2. 两套环境的排障工具矩阵，按症状选工具

2.1 On-Premise 的老牌事务码，一个都别放过

先说本地环境。我每天用得最多的几个：

ST22是短转储入口。自定义程序崩溃，第一站就是它。进去之后能看到异常分类，比如 CX_SY_REF_IS_INITIAL 是空引用、CX_SY_ARITHMETIC_ERROR 通常是除零、CX_SY_CONVERSION_ERROR 是类型转换失败。双击条目还可以看到触发语句、调用栈和出错代码行。拿到行号之后，用 SE38 打开程序、在那个行号上设断点，然后在测试环境用相同输入数据跑一遍，基本上能复现就能修。

SLG1是应用日志。前提是代码里把日志写清楚，对象名和子对象名都得有约定，否则这个事务码打开就是空的。我的习惯是每个自定义应用固定一个日志对象，关键业务节点都写 INFO，异常分支写 ERROR，这样出事后按时间和对象直接过滤。

SM21看系统级错误，能佐证某个时间段系统是否健康，比如有没有存储过程问题、有没有安全审计告警，和 ST22 形成互补。

ST05是做 SQL 跟踪的。一旦怀疑某个查询慢，或者数据不对是因为某条 SQL 没走对索引，就用它抓取一个会话的数据库访问语句，看执行计划。我当时排查过一个报表越跑越慢的问题，最后发现就是某个内表循环里反复查同一张表，索引完全没利用上，改成一次 SELECT 全部取出之后，响应时间从十几秒降到了两秒内。

另外 SM59 测 RFC 连接，SU53 查权限失败，SM50 看进程锁和占用，SE30/SAT 做运行时分析。这些都属于“老古董但真管用”。

2.2 ABAP environment 的新观测工具，提前理解边界

云环境里，传统事务码是没戏的，但新版观测应用并不弱，关键是提前知道它们各自看什么：

应用日志（Application Log）是所有自定义应用执行日志的汇集点。你可以在代码里用日志类写入 DEBUG、INFO、WARNING、ERROR 级别的记录，之后在 Fiori 的应用日志界面里按对象、时间段、消息类型过滤。比 SLG1 好用的一点是界面和上下文关联更友好。

健康监控（Health Monitoring）主要看系统整体状态、作业执行、性能指标。如果你怀疑自己的应用拖垮了系统，或者系统本身就存在问题，先进这里看全局告警和指标趋势。我记得有次某接口一直超时，排查了半天才发现是某时段系统整体响应时间飙高，问题根本不在应用代码上。

系统日志（System Logs）对应 SM21，适合看 ABAP 应用服务器的系统级错误。短转储信息通常也会在这里留下记录。

集成监控（Integration Monitoring）是解决接口类问题的入口，尤其当自定义应用调用外部接口失败或超时时，这里能看到请求状态和错误信息。

ABAP Development Tools（ADT）则是调试主阵地，断点、变量、调用栈都在这里。你可以在 Eclipse 里直接打开代码，对某一行动态断点，再触发出问题路径。云环境虽然不能直接改代码，但 ADT 把问题定位到行号这一步是完全可以做到的。

一个常见误区是以为云环境啥都看不见。实际上云环境有更完善的告警和日志聚合，只是不会把一个服务器的物理内存、进程列表摆在你面前。你要做的是在排障之前先确认边界，哪些信息你能拿，哪些拿不到，拿不到的部分用什么间接证据替代。

2.3 选工具不是看喜好，而是看症状

经验不够的时候最容易犯的错，就是拿着一堆事务码乱点。我自己的选型逻辑很简单，从症状出发：

• 程序崩溃、异常退出 → ST22 / 应用日志 / 系统日志
• 结果不对、数据错 → ADT 或 SE37/SE38 调试
• 性能慢、报表卡 → ST05 / SQL 分析 / 健康监控指标
• 接口超时、调用失败 → SM59 / 集成监控
• 权限报错、角色缺失 → SU53 / 应用日志 / 角色管理

这里有个小技巧：同一类症状里，先看耗时最短的入口。比如崩溃类问题，On-Premise 首选 ST22，因为它把异常类、调用栈、代码行都聚合好了；云环境首选应用日志，因为它能直接关联到业务上下文，不需要再翻系统日志碰运气。选型表贴在你的工作笔记第一页，排障的时候按表走，能省下不少来回切屏幕的时间。

3. 一次完整排障走查：从报错到修复验证

3.1 接到报错的第一时间，问清楚五要素

“程序报错了”，这不算问题描述。真正能帮你快速定位的问题描述，至少包含五个要素：

• 谁：哪个用户账户复现
• 何时：具体发生的时间段
• 何事：操作了什么功能、点了哪个按钮、输入了什么数据
• 现象：完整报错文案或截图、页面卡住还是结果不对
• 影响：只有一个人受影响还是一批人都受影响

这几个要素能直接帮你缩小排查范围。比如只有一个人报权限错误，那基本是角色授权问题；如果一批人都报，才有可能是代码逻辑或数据问题。我给维护项目写过一个问题登记模板，用户只要照着填，排障效率立竿见影。你也可以在自己的团队里做一个，哪怕就是个文本模板，也好过电话里听对方说“大概失灵了”。

3.2 崩溃类问题：从短转储到源码定位的一整条链路

先说 ABAP On-Premise。

接到崩溃类报错后，第一件事是让用户给出准确操作时间，然后打开 ST22。在 ST22 列表里通常能看到对应时间点、程序名和异常分类。双击条目，切到“Source Code”标签页，能直接看到导致异常的代码行，再切到“Information on where terminated”看调用栈。调用栈能帮你判断异常是自定义代码起的，还是标准代码被自定义代码带崩的。如果是后者，重点就得看你的增强或者调用点。

拿到行号之后，用 SE38 打开程序，在那个行号上设断点，然后在测试环境用相同输入数据跑一遍。如果能在调试器里命中断点，就反复看变量值，什么为空、什么超范围，基本一目了然。修完之后记得把断点清掉，别让调试断点留在生产代码里，这事我见别人干过，后果非常尴尬。

再看 ABAP environment。

你无法打开 ST22，但可以进应用日志选对应的时间段和日志对象，找到异常记录。展开后能看到异常类和堆栈信息。如果日志对象里没写清楚，去系统日志应用里翻对应时段的 ABAP 应用服务器日志，也会留下短转储痕迹。拿到堆栈后，用 ADT 打开出问题的方法，在对应行设断点，重新触发一次，观察变量值。

云环境里完整的调试链路是：应用日志发现异常 → 拿到异常类和方法名 → ADT 打开源码 → 断点调试 → 修改代码 → 推到 Git 仓库 → 部署管道发布 → 测试环境回归验证。整个过程没有 ST22 那么“一刀见血”，但只要日志埋得好，定位并不慢。

3.3 数据错误类问题：从输入到数据库内容逐层核对

数据错误是最隐蔽的，因为系统不报错，就是结果不对。常见原因有逻辑边界没覆盖、并发覆盖、缓存数据过期、源系统数据问题。

我踩过一个很典型的坑：某自定义报表在每年 1 月会多算一批数据，因为动态拼接 SQL 时把月份区间写成了“大于等于起始月、小于等于截止月”，结果把下一年 1 月也包进去了。这种问题不调试根本发现不了，因为平时月份区间是对的，只有跨年那几天才触发。

排查思路是按数据流向逐层核对：

• 第一层，输入参数。用户传了什么，默认值是什么，有没有因为屏幕默认值变化导致查询条件不对。
• 第二层，应用逻辑。调试器里看每个关键变量、内表内容、动态 SQL 拼接结果。
• 第三层，数据库内容。SELECT 前先确认数据库里到底有什么，是不是数据本身就是脏的。
• 第四层，并发场景。两个用户同时写同一条记录，后写的是不是覆盖了先写的。

这个步骤在 On-Premise 和 ABAP environment 里都可以用 ST05/ADT SQL 分析加调试器组合完成，重点不是工具，而是你愿意逐层对比“输入、处理、存储”的差异。不要一上来就怀疑数据库坏了，大概率是你的查询条件或者更新逻辑有问题。

3.4 性能慢与接口问题：先排除环境，再查代码

性能问题别急着看代码，你先确认几点：

• 系统有没有锁等待、进程占满、内存不足？
• 查询有没有走索引？
• 是持续慢还是某个时间段慢？
• 是不是第一次运行没有缓存？

On-Premise 用 ST05 抓 SQL 执行计划，用 SM50 看进程锁，基本能排除环境问题。云环境用健康监控看性能指标是否有异常波动，再用 ADT 的 SQL 分析看某条查询的执行细节。我遇到最多的情况，其实是内表循环里嵌套 SELECT，数据量一大就爆炸。解决办法很简单，能一次取数就不要循环单查，能 FOR ALL ENTRIES 就不要逐条 SELECT。这类优化做完之后，性能通常立竿见影。

接口类问题，我的习惯是先分清是对方还是自己。让用户给出请求时间，On-Premise 用 SM59 做连接测试，云环境看集成监控里对应接口的请求状态。如果对方返回慢，通常错误代码是超时；如果自己代码处理慢，那就是逻辑问题。通信日志里一般都有请求报文和响应报文，对比报文能很快找出字段遗漏或格式变化。

4. 高频故障速查，以及这些年在排障上踩过的坑

4.1 高频问题速查表

这张表不追求覆盖所有错误，只解决日常最高频的几类。你可以在此基础上补自己项目的特有错误码，慢慢积累成自己的排障手册。

4.2 六个用教训换来的排障经验

第一，日志级别没打开，等于排障时在摸黑。上线前一定确认自定义应用的日志都写到位，并且至少 INFO 级别是打开的。否则出问题后应用日志里一片空白，你只能干瞪眼。

第二，日志必须带业务上下文。订单号、用户 ID、会话 ID、执行时间，一个都不能少。光写“执行成功”的日志就是一堆噪音，根本没法定位是哪一笔业务出了问题。后来我们强制要求每个关键节点都带上业务主键，排查速度完全不一样。

第三，别只盯着当前代码，先确认部署版本和当前代码一致。有一次排查生产问题，忙碌了将近两个小时，最后发现生产跑的还是上一版代码，传输请求没传上去。这比代码 Bug 更令人崩溃。

第四，在自己环境复现不了的时候，先对比两个环境的配置差异，不要硬猜代码。数据权限、后台作业调度、RFC 连接、系统参数，任何一项不同都可能是根因。

第五，改完代码别直接上生产。至少先在测试环境验证一次，把关键场景回归跑一遍。云环境的部署管道天然会卡一道关，但 On-Premise 全靠自觉，这一步不能省。

第六，云环境排障，先看全局再钻细节。有次某接口告警，我直接钻进应用日志逐条翻，翻了一小时才发现系统级告警里有个服务不可用的提示。正确的顺序永远是从整体状态开始，一层层往下钻，先把范围缩小，再把单个条目看清。

4.3 上线前多做三步，生产环境少跑一半

排障这件事，功夫在诗外。我自己在项目上线前一定会做三件事：

第一，统一错误处理。把自定义代码里的异常捕获统一收敛到一个出口类，所有错误都带统一格式、统一日志级别、统一消息 ID。这样上线后任何错误都会在日志里形成一个固定模式的记录，排查起来非常省事。

第二，写清排障手册。每个自定义应用在发布时附带一页文档，写清楚日志对象名、关键业务表、错误码含义、常见问题处理方式。别小看这一页纸，出了问题的时候，它是救命稻草。

第三，约定日志与通信规范。日志对象命名、业务主键记录、接口追踪 ID 传递，都在上线前定好。尤其云环境，日志关联查询全靠这些 ID，没有规范就没有线索。

这三步做扎实之后，我遇到过的最好消息就是：真的出了问题时，日志里已经躺好了几乎所有答案。

我个人在实际操作中的体会是，排障能力不是靠临时反应练出来的，而是靠上线前的工程习惯托底。日志埋好、错误处理统一、环境差异想清楚，生产环境就少很多惊吓。ABAP On-Premise 和 ABAP environment 的差异只是入口和工具，排障的方法论始终是那套四步走：锁定现象、收集证据、分层定位、修复验证。如果你现在正被生产环境的某个报错弄得焦头烂额，不妨从第一步开始，退回去把问题描述问清楚，再决定用哪个工具——大多数时候，慢就是快。