企业官网建设流程全解析

做 SAP 运维这些年，被问得最多的问题之一就是：“帮我查一下某某用户昨天登录了系统没有？他到底跑了哪些事务码？”每次接到这类需求，我第一反应就是打开 SM19 和 SM20 这对组合。很多顾问平时不太碰这两个事务码，觉得它们属于安全审计的领域，等真正出了权限纠纷、合规检查、接口报错才想起来要查日志，结果又不知道从哪里下手。这篇文章就把用户对话、登录、接口、事务码、程序这几类日志怎么配置、怎么查询、怎么读懂结果，完整梳理一遍，适合 SAP 运维、安全审计顾问和刚接触 ABAP 开发的人直接参考。

1. 什么情况下你会用到 SM19 和 SM20

1.1 最常见的三类查日志需求

先别急着上手操作，搞清楚“什么时候需要这两个事务码”比会点按钮更重要。我实际工作中碰到的需求基本可以归成三类，每类的思路和侧重点都不一样。

第一类是账号安全与登录异常。典型场景是：某用户说自己在凌晨没有登录过系统，但系统里有操作记录；或者一个账号在短时间内连续登录失败，疑似有人在试密码。这种问题要查的是“对话登录”和“RFC 登录”事件，重点看登录时间、登录成败、来源终端。只要 SM19 里开启了登录审计，SM20 一过滤就能拉出完整的登录时间线，比翻数据库表快得多。

第二类是权限审计与合规检查。年底内部审计或者外部合规检查时，领导要求提供“某段时间内谁执行了敏感事务码、谁跑过大批量程序”的操作清单。这类需求必须按“事务码”和“ABAP 程序”两个审计对象去配置，配合用户名过滤，基本能还原出操作轨迹。审计日志里会记录每次执行的用户名、客户端、时间戳，这些就是合规报告里最有力的证据。

第三类是接口与程序异常追踪。外围系统通过 RFC 调用 SAP 功能，某天接口报错，业务部门把问题抛过来，说“肯定是 SAP 这边的问题”。这时候需要查 RFC 登录和 RFC 调用审计事件，结合外围系统日志的时间戳，判断是 SAP 拒绝了登录，还是调用本身出了故障。ABAP 程序被后台 Job 调度执行后结果异常，也能通过审计日志找到执行记录和结果代码。

1.2 为什么安全审计日志选 SM19/SM20，而不是 SM21 或 STAD

有同事一听“查日志”就直奔 SM21，这其实是个误区。SM21 看的是系统日志（System Log），记录的是程序崩溃、更新模块错误、锁冲突、数据库连接异常这类“系统内部状态”。它回答不了“某用户在几点几分登录、点击了哪个事务码”这种用户行为问题。

SM19 和 SM20 是安全审计日志（Security Audit Log）的配置与查询入口，专门记录用户层面的操作行为。这两个事务码的分工我后面会细讲，先拿一张表把三者的区别说清楚：

至于 STAD，它更多是工作负载与性能统计的场景，告诉你某个事务码跑了多少次、平均执行时间是多少，但拿它当审计证据是不够的。统计记录不会保留完整的“谁在哪个客户端做了什么”的审计上下文，外审人员通常只认安全审计日志。所以一旦涉及用户行为和权限合规，SM19/SM20 才是正解。

2. 安全审计日志的底层链路：日志到底从哪里来

2.1 审计日志不是默认全开的

很多人以为 SAP 系统会默认记录所有用户操作，这是个危险的误解。安全审计默认处于“关闭”或“最低级别”状态，必须先通过 SM19 告诉系统“要记什么”，用户操作才会被写进审计日志。

打个比方：这就像给机房装了监控摄像头，但摄像头默认没有开录像功能。你必须在 SM19 里设置好“哪几个画面要录、录成功率还是失败率”，系统才开始工作。等真出了事才想起来要开监控，那前面前段时间的录像必然是空白。

审计事件触发后，系统会把一条审计消息写入本地审计日志文件。日志文件按天滚动，同时受最大文件大小限制。SM20 的作用就是去读这些文件，按条件筛选展示。所以整个链路可以概括成：SM19 配置过滤条件 → 用户操作发生 → 审计消息写入日志文件 → SM20 读取并展示。

2.2 SM19 管“记什么”，SM20 管“怎么看”

这是新手最容易绕晕的地方，其实一句话就能记住：SM19 是写配置的，SM20 是看结果的。SM19 里定义的是审计对象、审计级别、过滤条件；SM20 里做的是查询、解读和导出。配置没做好，SM20 自然查不到数据，这不是查询方式不对，而是源头没开。

SM19 中有多个审计对象（Audit Class），每种对象负责记录一类事件。常用对象包括：对话登录（Dialogue Logon）、RFC 登录（RFC Logon）、事务码调用（Transaction）、ABAP 程序执行（Report）、RFC 调用（RF Call），另外还有面向用户（User）和文件（File）相关的参数对象。每个对象都有独立的审计级别开关，你可以只开自己关心的那几类。

2.3 日志文件写到哪里，为什么有时换日期就查不到

审计日志文件存放在 SAP 应用服务器本地文件系统的审计目录下，不是默认直接写进业务数据库表里。文件名通常包含日期信息，按天生成，配置了最大文件大小时还会继续滚动生成新卷。

这也是为什么有时在 SM20 里把查询日期往前调，却发现查不到内容。SM20 默认读的是当前活动卷，更早的历史日志可能需要手动切换“卷”（Volume）才能看到。卷的切换入口在 SM20 界面的顶部区域，会列出当前系统可读取的日志文件卷，点选对应日期或卷名后再执行查询，老数据才会出现。

3. 一步一步配置 SM19：日志能不能查到，八成都在这

3.1 进入 SM19 前要先想清楚的事

打开 SM19 之前，先列一个“审计对象清单”。不要一上来就把所有对象全开成“全部审计”，生产系统全量审计会明显增加应用服务器的 I/O 和 CPU 开销，直接影响前台对话响应速度。

实操中建议按下面的优先级来开：

• 对话登录：追踪用户的登录成功与失败，几乎必开
• RFC 登录：追踪外围系统、后台接口的登录，涉及接口必开
• 事务码调用：记录敏感事务码的执行，权限审计必备
• ABAP 程序执行：记录直接执行的报表和程序，排查数据异常走这条
• RFC 调用：记录接口调用细节，接口故障定位靠它

审计级别怎么选，取决于目的。查账号是否被盗用，登录成功和失败都要看；查接口为什么连不上，重点看 RFC 登录的失败记录；做敏感事务码审计，则要记录“成功”执行的结果，因为失败的调用通常不是关注重点。

3.2 主审计级别与过滤条件的设置细节

SM19 界面左侧是审计对象树，右侧是选中对象的当前参数。顶部工具栏有一个“主审计级别”（Master Audit Level）按钮，点开后是四档选项：

• 无审计（No Audit）：什么都不记
• 仅审计失败（Only Failures）：只记录失败操作，适合兜底
• 仅审计成功（Only Successes）：只记录成功操作，适合敏感操作追踪
• 全部审计（All Categories）：成功失败都记录，数据量最大

主审计级别是所有对象的默认底色。实际操作时，我建议先把主审计级别设成“仅审计失败”，保证异常操作至少能留痕，然后再对敏感对象单独拉高级别。比如把对话登录、RFC 登录设成“全部审计”，因为登录行为本身频率不高，全量记录性能影响有限；但不要把事务码对象全局设为“全部审计”，否则系统里所有事务操作都被记录，日志量会非常吓人。

在具体对象上还可以设置过滤值。比如“Transaction”对象中填入敏感事务码清单，系统就只审计这几个事务码；“User”对象中填入指定用户名，就只审计该用户的操作。过滤条件设置得越精准，审计文件里的有效信息密度越高，后续排查的效率也越高。

3.3 保存、激活与验证，三步缺一不可

配置完成后，先保存，再点“激活”按钮。很多人在这里翻车：以为保存就生效了，结果第二天查不到任何日志。SM19 的配置必须激活后，新的审计设置才真正注入到运行系统里。

激活之后还要做一次验证：换一个测试用户登录系统，执行一个事务码或程序，然后到 SM20 里查刚才那一段时间的记录，确认审计消息确实产生了。建议在测试环境先整个流程走一遍再上生产机改配置。生产机上首次开启审计尽量选业务低峰期，避免大量审计事件集中写入造成性能抖动。

4. 在 SM20 里把日志捞出来：查询条件与结果解读

4.1 查询条件的组合技巧

SM20 的初始查询界面里，主要字段包括日期范围、用户名、客户端、审计类（Audit Class）。默认日期范围是“昨天到今天”，实际排查时最好手动放宽，因为日志按天滚动，跨天场景很容易漏数据。

我常用的组合思路：

• 查登录问题：日期范围选准，用户名可留空，审计类选“对话登录”或“RFC 登录”
• 查具体用户的全量行为：用户名填进去，日期放宽，审计类留空，先把该用户所有审计事件拉出来
• 查某个事务码谁在用：审计类选“事务码”，用户名留空，配合事务码过滤值，输出全局使用清单
• 查接口调用：审计类选“RFC 调用”或“RFC 登录”，再配合客户端和 RFC 目标字段收窄范围

一个原则：第一次查询宁宽勿窄。先把类型和时间段确定，用户名、客户端这类字段能不加就不加，等看到全貌后再逐步追加条件过滤。上来就加一堆条件，容易漏掉关键线索。

4.2 结果列表的关键字段怎么读

SM20 执行后返回的结果列表，每一行就是一条审计事件。不同版本字段名称略有差异，但核心字段基本一致：

读列表时建议按三步走：先看“结果代码”，区分成功和失败；再看“对象 ID”，对应到具体事务码或程序名；最后按日期时间排序，把同一用户的多条事件串成时间线。串时间线是最有价值的动作，能直观还原“用户从登录到执行操作再到退出”的完整路径。

4.3 把审计日志导出到本地文件

审计报告通常要交付给安全团队或外部审计，SM20 支持把查询结果导出。在结果列表的菜单里找到“保存/下载”功能，可以存成文本或表格格式，再转成 Excel 加工成报告。

导出时有几个细节要注意。第一，大结果集导出会卡住对话，建议先加筛选条件再导出，不要一次性导几十万行。第二，导出文件应保留原始审计事件的时间戳、用户名、结果代码等内容，不要手工合并或删减，否则审计证据的效力会打折扣。第三，文件名建议包含查询日期范围和系统编号，方便后续追溯。

5. 实战视角：登录、事务码、程序、接口日志分别怎么查

5.1 用户登录与对话日志的追踪

最常见的场景是用户登录追踪。在 SM20 里把审计类锁定为“对话登录”，选好日期范围，用户名可以填也可以留空。查询结果会区分成功和失败的登录事件，成功登录一般会记录客户端和终端信息，失败登录同样有时间戳和用户名。

如果怀疑账号被暴力破解，可以按时间升序排列所有失败登录事件，看多次失败尝试的间隔是不是接近。这里有个技巧：不要只看用户名，还要看客户端。同一个人在同一客户端连续失败是记错密码，从不同客户端轮流尝试大概率是扫描攻击。这类细节在实际排查中能帮你少走很多弯路。

5.2 事务码与 ABAP 程序的执行追踪

事务码审计回答的是“谁在什么时候执行了什么敏感操作”。先在 SM19 里把“事务码”对象打开，审计级别设为“全部审计”，过滤值里填上 SE16、SE01、SU01 这类敏感或数据访问型事务码。然后在 SM20 里按审计类“事务码”筛选，输出字段中会包含用户名、时间、客户端和事务码代码。

ABAP 程序执行追踪与事务码类似，走“Report / ABAP 程序”审计对象。要注意的是，直接通过 SE38 执行程序和通过后台 Job 调度程序，审计记录的上下文不完全一样。如果查 SE38 直接执行时发现数据缺失，检查一下该对象是否单独开启，以及主审计级别是否被过滤条件限制了。

5.3 接口（RFC）调用日志的追踪方法

接口日志要分两个维度看：RFC 登录和 RFC 调用。RFC 登录关心的是“外围系统有没有成功接入 SAP”，RFC 调用关心的是“某个功能模块被哪个来源调用了”。

查到一条 RFC 审计事件时，重点看附加信息里的 RFC 目标、逻辑端口、来源客户端，这几个字段能帮你定位到具体的集成对象。有一次我排查财务接口报错，外围系统说“SAP 拒绝登录”，本地网络测试都是通的。最后在 SM20 里查到那段时间的 RFC 登录失败事件，附加信息里明确指向了一个过期的连接用户，问题五分钟就定位了。没有审计日志，这种接口问题就只能靠两边反复对时间、对报错，非常低效。

6. 运行维护里容易踩的坑，以及我自己的习惯做法

6.1 配置了却查不到数据的五类原因

整理了这些年遇到过的“SM20 查不到日志”的真实原因，其中最典型的是下面五类：

• 配置没有激活，SM19 改完只保存了，没有任何作用
• 过滤条件设置过严，比如在 User 对象里填了一个永不匹配的表达式，系统以为你不需要记录
• 查询卷不对，SM20 默认读当前活动卷，跨日期数据要被忽略
• 日期范围太窄，查询区间正好落在日志滚动的间隙里
• 审计对象选错，事件实际属于“RFC 登录”，却按“对话登录”去查

碰到“查不到”，先别急着怀疑系统有问题，回去看 SM19 该对象是否开启、级别是否合适。SM19 端没有采集，SM20 端再精心组合条件也是白搭。

6.2 审计日志与系统日志对不上的排查思路

有时 SM21 里能看到接口报错，SM20 里却找不到对应审计事件，这不一定是谁出了问题。系统日志记录的是系统层面的事实，安全审计日志记录的是用户层面触发的事实。接口报错发生在 SAP 侧数据库连接异常，SM21 有记录；但该异常是由外围系统发起，没有成功建立会话，SM20 的 RFC 登录审计可能就看不到对应事件。

排查时不要执着于“两边必须完全吻合”。正确姿势是：先用 SM21 定位系统异常时间段，再用 SM20 定位该时间段内用户行为，把两条线放在同一时间轴上对齐。很多时候故障要还原成完整故事才能确定根因，单独看任何一边都可能被误导。

6.3 日志保留策略与磁盘空间管理

审计日志文件会持续增长，尤其是开了“全部审计”的系统，单日文件几百 MB 很常见。如果不规划保留策略，审计目录被写满之后，新的日志可能写不进去，这比“没开审计”还危险——你会在最需要日志的时候发现日志停在昨天。

我个人的习惯是：每月用 SM20 把重要审计事件导出归档一次，检查服务器审计目录的空间占用，确认日志文件按预期在产生。归档之后可以清理已归档的旧日志文件，但保留周期定多长要结合行业要求，不能随手删。金融、制造这些行业对审计数据留存时间通常有明确要求，删错了就是合规事故。

最后再分享一个我自己的默认配置习惯：平时把主审计级别设为“仅审计失败”作为全系统兜底，再把登录、RFC 接入、敏感事务码这几个对象单独拉高到“全部审计”。这样既不把生产系统拖垮，又能保证关键时刻拿得出完整证据。每季度随手用 SM20 抽查一次，确认审计链路还在正常工作，远比出事之后追悔莫及要省心。