概念定义：AB页跳转决策日志是什么
先把概念说清楚。所谓AB页跳转决策日志，就是跳转系统在每一次请求打到决策引擎之后，把整个判断过程结构化地记下来，形成的那份数据。一条完整的日志里面，至少得有这么四块内容：输入特征，包括请求是从哪来的、设备信号是什么、地域标识这些；规则匹配轨迹，就是命中了哪些规则、优先级怎么排的；决策输出，跳到哪个版本、返回什么状态码、做了什么响应动作；再加上时间戳和链路标识。
这跟普通的访问日志完全是两码事。访问日志记的是"谁在什么时候访问了什么"，决策日志要回答的是"系统凭什么做出这个判断"。一个是流量维度的东西，另一个属于逻辑维度。跳转规则一旦堆到几十条以上，光看访问日志根本还原不出一次跳转决策的完整推理链条，决策日志就是拿来补这个缺口的。
运行机制：从请求到日志落盘的生命周期
决策触发与特征采集
请求到达跳转服务的那一刻，决策引擎干的第一件事就是特征采集。这一步要抓的输入挺杂：HTTP请求头、URL参数、IP归属地、设备指纹片段，还有会话上下文。每个特征在送去规则匹配之前都会先做归一化，日志里落的是归一化之后的值，不是原始值。为什么要这么处理？原始值里可能夹着敏感信息，归一化之后的值对于后续回溯决策来说已经够用了。
规则匹配与分支选择
规则引擎按优先级一条条评估条件。到了这个阶段，决策日志得记两类东西：一类是规则命中序列，哪些规则被评估过、哪些跳过了、跳过是因为什么；另一类是最终选中的那个分支，以及选它的依据。规则数量多的时候，全量记录命中轨迹会让日志体积涨得很快，所以一般只记命中的规则和被排除掉的高优先级规则。
输出动作与日志落盘
决策输出这块包括跳转目标、响应状态码、要不要带参数这些。日志落盘一般走异步写入，不能让它卡住跳转响应。写的时候会给每条日志配一个链路标识，方便跟上游的请求日志、下游的页面加载日志串起来。这个链路标识，后面做端到端回溯全靠它。
采样策略：完整性与成本的平衡
并发一高，全量记录决策日志的存储开销膨胀得特别快。采样策略要解决的其实就是一件事：在能接受的存储预算里，留下足够多的决策样本，够审计和优化用就行。
全量采样：规则变更之后的观察窗口期用它，一般持续几个小时到一天，目的是验证新规则的决策分布跟预期对不对得上。；分层采样：按决策结果分层，异常分支、兜底分支这种少数派提高采样率，主流分支压低采样率。总量压下来了，异常路径的可见性还保得住。；时间窗口采样：每隔固定时间抽一批样本，做长期趋势分析比较合适，但突发异常来了它未必抓得住。；触发式采样：只有满足特定条件才记日志，比如规则冲突了、决策延迟超标了、特征缺失了。这种日志量最小，可单条的信息密度最高。。
到底选哪种，得看当前阶段想干什么。规则稳定期用分层采样控成本，灰度发布期切到全量采样保证可回溯，故障排查的时候用触发式采样快速定位问题。
可解释性输出规范：让每条日志能回答"为什么"
可解释性输出规范，核心就一条要求：随便拎出一条决策日志，不翻外部文档也能把关键推理步骤还原出来。也就是说，日志不能光写"跳到了B版本"，还得写清楚"因为命中了规则R3，而规则R1和R2的条件没满足"。
规范里通常会要求这几个字段：
决策依据字段：最终决策依赖的规则标识和条件表达式，记下来。；排除依据字段：被评估过但没命中的高优先级规则，以及具体是哪个条件项没中。；特征快照字段：参与决策的关键特征值，保证后面用同样的输入能把决策复现出来。；版本标识字段：当时生效的规则集版本号和引擎版本号，不然规则一更新，旧日志就没法解读了。。
排除依据字段缺失，是实际项目里特别常见的一个毛病。只记命中规则，碰上规则冲突或者优先级调整，你就说不清当时为什么走了另一个分支。把这个字段补上，日志的可解释性能往上提一大截。
适用条件与边界
决策日志这东西，不是所有AB页跳转场景都值得全量去建。日均请求量就几百的时候，访问日志加一份规则配置文件基本能应付。等规则数量过了五十条，或者跳转决策牵扯到多条件组合判断了，投决策日志才开始看到明显回报。
边界上有三点必须掰扯清楚。第一，决策日志记的是决策逻辑，不记页面内容，这俩别塞进同一个存储管道。第二，日志里的特征快照可能带着设备信号，得按数据留存规范定好保留期限。第三，采样策略定了之后，一定要在日志元数据里标清楚采样率和采样方式，不然以后做统计分析，偏差会把你带沟里去。
一个实战案例
去年底碰到一个做工具类应用投放的团队，日均跳转请求大概一千二三百次，规则集六十多条。他们一开始只记了跳转结果，决策依据没记。有段时间发现某个地区的跳转目标时不时落到兜底版本上，排查了整整两周没找到原因。后来把排除依据字段和特征快照补上，重新跑了一周日志，才看出来是某条地域规则的优先级被另一条设备规则给盖住了——两条规则的条件在特定设备型号上同时成立，优先级配置跟他们的预期对不上。优先级调完之后问题就没了。这个案例说明的倒不是决策日志有多万能，而是规则规模到了几十条以后，没有决策依据字段的日志，基本上等于半盲排查。
相邻概念对比
决策日志和审计日志容易被搞混。审计日志面向的是操作行为，记的是"谁在什么时候改了哪条规则"；决策日志面向运行时逻辑，记的是"系统在什么时候为什么做了这个决策"。数据结构不一样，用途也不一样，别共用同一张表。
跟链路追踪呢，有交集但也不重合。链路追踪盯的是请求在多个服务之间的流转路径和耗时分布，决策日志盯的是单次决策内部的逻辑推理过程。实践里可以把决策日志的链路标识接进链路追踪系统，实现从请求入口到决策输出的全链路关联。但两者记录粒度不同，合并存储反而会拖累各自的查询效率。
概念性FAQ
决策日志需要记录原始请求的全部请求头吗
不用。记参与决策的那些特征字段就够了。没参与决策的请求头记进去，除了增加存储成本和脱敏负担，没别的用处。不过要是特征采集逻辑以后可能会变，建议在日志里留一个特征采集的版本标识，方便后面对比不同版本采集逻辑下的决策差异。 这个真没有固定值。主流分支的采样率压到百分之几都行，异常分支和兜底分支建议保持全量或者高采样率。关键原则就一句：任何你希望事后能回答"为什么"的决策路径，都不该被采样策略过滤掉。
决策日志的保留周期怎么定
看两个因素：规则变更频率和排查响应周期。规则每周都在调的系统，日志保留周期至少得覆盖两个完整的规则迭代周期，否则一出问题，旧日志早过期了。规则稳定的系统可以适当缩短，但建议别低于三十天。
