ABAP自定义应用排障实战：从On-Premise到云环境的方法

自定义应用上线只是排障的开始。这话听着有点丧但干 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 ToolsADT中的调试和 SQL 分析进程列表、表锁这些底层状态基本不可见。另外代码改动方式也变了不是生产系统里直接传输而是代码推到仓库、走部署管道发布。但这里我想强调一句可见度变低不代表排障能力变差。云环境的日志聚合、上下文关联、告警机制只要用得好定位问题的速度可能比本地还快。关键在于你认不认这个新的工具边界。维度ABAP On-PremiseABAP environment短转储ST22应用日志 / 系统日志系统日志SM21系统日志应用应用日志SLG1应用日志应用SQL 跟踪ST05ADT 调试器 SQL 分析后台作业SM37作业仪表盘RFC 连接SM59集成监控进程/锁监控SM50/SM66不可见托管代码变更直接传输Git 部署管道授权失败SU53应用日志 / 角色管理这张表的关键信息是环境变了入口换了但排障思路没有变——你仍然要沿着现象找证据只是证据放的位置变了。1.3 通用排障四步法锁定、收集、分层、修复不管你是 On-Premise 还是 ABAP environment也不管故障是崩溃、数据错误还是性能慢流程基本是同样的四步锁定现象。明确什么问题、什么时候发生的、影响谁、影响范围多大。这步不做后面全是瞎猜。收集证据。把用户的报错文案、屏幕截图、输入数据、操作步骤全部拿到手。很多时候用户只会说“它坏了”你得去问细节。分层定位。对照上面那五层把问题限定到具体层。这步最需要经验但你可以用“哪个层最容易产生这个现象”来做筛选排除法比硬啃代码快得多。修复与验证。改动代码或配置之后不是直接上生产而是先回归测试再发布并观察一段时间。这套四步法我在两个环境里都用区别只是第 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 ToolsADT则是调试主阵地断点、变量、调用栈都在这里。你可以在 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 高频问题速查表问题现象可能根因快速定位方法修复方向程序崩溃用户被中断空引用、除零、类型转换ST22 / 应用日志查看异常类修改对应行逻辑加空值判断报表结果少几条或多几条查询条件拼接错误调试器查看动态 SQL 与变量值修正拼接逻辑权限不足报错授权对象没配SU53 / 应用日志授权错误调整角色授权接口超时外部服务慢、报文错误SM59 / 集成监控对比请求响应优化代码或联系对方后台作业失败前序依赖失败、资源不足SM37 / 作业仪表盘查看日志按依赖关系修复生产与测试环境行为不一致传输缺失、配置不一致对比传输请求和配置补传或统一配置这张表不追求覆盖所有错误只解决日常最高频的几类。你可以在此基础上补自己项目的特有错误码慢慢积累成自己的排障手册。4.2 六个用教训换来的排障经验第一日志级别没打开等于排障时在摸黑。上线前一定确认自定义应用的日志都写到位并且至少 INFO 级别是打开的。否则出问题后应用日志里一片空白你只能干瞪眼。第二日志必须带业务上下文。订单号、用户 ID、会话 ID、执行时间一个都不能少。光写“执行成功”的日志就是一堆噪音根本没法定位是哪一笔业务出了问题。后来我们强制要求每个关键节点都带上业务主键排查速度完全不一样。第三别只盯着当前代码先确认部署版本和当前代码一致。有一次排查生产问题忙碌了将近两个小时最后发现生产跑的还是上一版代码传输请求没传上去。这比代码 Bug 更令人崩溃。第四在自己环境复现不了的时候先对比两个环境的配置差异不要硬猜代码。数据权限、后台作业调度、RFC 连接、系统参数任何一项不同都可能是根因。第五改完代码别直接上生产。至少先在测试环境验证一次把关键场景回归跑一遍。云环境的部署管道天然会卡一道关但 On-Premise 全靠自觉这一步不能省。第六云环境排障先看全局再钻细节。有次某接口告警我直接钻进应用日志逐条翻翻了一小时才发现系统级告警里有个服务不可用的提示。正确的顺序永远是从整体状态开始一层层往下钻先把范围缩小再把单个条目看清。4.3 上线前多做三步生产环境少跑一半排障这件事功夫在诗外。我自己在项目上线前一定会做三件事第一统一错误处理。把自定义代码里的异常捕获统一收敛到一个出口类所有错误都带统一格式、统一日志级别、统一消息 ID。这样上线后任何错误都会在日志里形成一个固定模式的记录排查起来非常省事。第二写清排障手册。每个自定义应用在发布时附带一页文档写清楚日志对象名、关键业务表、错误码含义、常见问题处理方式。别小看这一页纸出了问题的时候它是救命稻草。第三约定日志与通信规范。日志对象命名、业务主键记录、接口追踪 ID 传递都在上线前定好。尤其云环境日志关联查询全靠这些 ID没有规范就没有线索。这三步做扎实之后我遇到过的最好消息就是真的出了问题时日志里已经躺好了几乎所有答案。我个人在实际操作中的体会是排障能力不是靠临时反应练出来的而是靠上线前的工程习惯托底。日志埋好、错误处理统一、环境差异想清楚生产环境就少很多惊吓。ABAP On-Premise 和 ABAP environment 的差异只是入口和工具排障的方法论始终是那套四步走锁定现象、收集证据、分层定位、修复验证。如果你现在正被生产环境的某个报错弄得焦头烂额不妨从第一步开始退回去把问题描述问清楚再决定用哪个工具——大多数时候慢就是快。