审计架构核心概念：可观测性、可审计性、可追溯性

这三个词，几乎是平台工程审计的灵魂。我见过不少团队，把运维监控当审计，把日志收集当追溯，结果出事了啥也查不出来。说白了，它们各自负责不同的事，但又必须拧在一起才能形成完整的审计证据链。今天我就用自己的经验，把这几个概念剥开来说透。

1. 可观测性：你看到的不一定是真相

可观测性（Observability）不是简单的监控。监控告诉你系统挂了，可观测性告诉你——它为什么挂的，挂了多久，影响了谁。这个区别，在我处理一次线上故障时体会特别深。

那次，所有业务指标都是绿的，但用户反馈订单提交失败率飙升。传统的监控完全没报警，因为平均延迟和错误率都在阈值内。可我们用了分布式追踪，发现某个上游服务在特定条件下返回了空指针异常，但被调用方吞掉了，导致HTTP 200但业务数据异常。这就是可观测性的价值——通过日志、指标、追踪三大支柱联动，推导出未知的未知。

2. 可审计性：谁说谁做过，谁说谁看了

可审计性（Auditability）关注的是：谁在什么时候对什么资源做了什么操作。它比可观测性更严格——你必须保证记录的内容不可篡改，且能按时间线完整回放。我刚开始做平台时，觉得把操作日志写进数据库就完事了。结果有次合规检查，对方要求提供半年前某管理员的所有敏感操作，我们发现日志表被误删了一部分——因为开发人员直接执行了delete语句。

嗯，从那以后，我改成写前日志 + 后日志双写，并且用独立的日志服务（比如Fluentd + S3，再配上Hash链校验）。每次追加日志都会带上前一条的哈希值，形成区块链式的链式结构。

3. 可追溯性：从点击到响应的完整路径

可追溯性（Traceability）是连接可观测性和可审计性的桥梁。它要回答：某个操作到底触发了哪些系统调用？数据流经过哪些节点？状态变更的因果关系是什么？我自己的做法是，在每个API请求的入口生成一个全局唯一的requestId，然后通过HTTP Header（如X-Request-Id）传播到所有下游服务。所有日志、审计事件、追踪span都带上这个ID。

说实话，在微服务架构里，如果没有链路追踪，调试就像在黑箱里摸象。我有个原则：任何跨服务调用都必须显式传递上下文，包括请求ID、用户ID、租户ID。这样当审计需求来临时，你能一秒定位出整个请求路径。

下面是一个简化的链路标识示例：

// 服务A入口生成Trace
String traceId = UUID.randomUUID().toString();
MDC.put("traceId", traceId);
// 调用服务B时注入Header
httpHeader.add("X-Trace-Id", traceId);
httpHeader.add("X-Span-Id", UUID.randomUUID().toString());

// 服务B收到后取出
String parentTraceId = request.getHeader("X-Trace-Id");
String parentSpanId = request.getHeader("X-Span-Id");
MDC.put("traceId", parentTraceId);
MDC.put("parentSpanId", parentSpanId);

三者关系：一个不能少

可观测性负责“发现”，可审计性负责“记录”，可追溯性负责“连接”。缺了一个，审计链条就会断。我常常把它们比作一个三角形：可观测性是感知层，可审计性是存证层，可追溯性是关联层。下面这张图能让你直观理解它们的协作关系。

你想想看，如果只做可观测性，没有可审计性，你拿什么给合规部门证明？如果只做可审计性，没有可追溯性，你只能看到一堆孤立的操作日志，根本连不成一条线。我记得有一次做PCI DSS认证，审计师要求我演示：从用户支付请求到银行回执，中间经过了7个微服务，每个服务做了什么事，数据有没有被修改——这就是可追溯性的典型场景。

实战建议：搭建审计三角

别想着一次性搞完美。我建议分三步走：

1. 第一阶段：所有服务接入链路追踪（OpenTelemetry），至少保证每个请求有一个贯穿的traceId。这是基础中的基础。
2. 第二阶段：在关键操作（用户登录、权限变更、数据修改）上加上结构化审计日志，独立存储，定期校验哈希。
3. 第三阶段：将审计日志与链路追踪关联，比如在审计事件中嵌入traceId。这样一旦发生审计事件，你可以直接跳到对应的全链路追踪看板。