的服务器集群里，但接口命名规范遵循的是外部服务的格式。
这意味着它在架构设计上被归类为"外部引入"，但实际运行在内部环境中。
他又点开了调用日志。
日均调用量：12.7万次。
在微光支付模块所有外部接口中排第三，仅次于银联清算和人行征信。
调用场景覆盖信用评估、风控决策、额度调整三个核心环节。
平均响应时间：23毫秒。
超时率：0.002%。
返回数据结构复杂，字段数是标准征信接口的四到五倍，包含常规征信报告里看不到的维度。
他往下翻了一页。
接口文档里有一段简短的描述："AbySS信用评分引擎，提供多维度用户信用画像及实时风控评分服务。"
一句话，没有更多说明，没有供应商资质信息，没有数据来源声明，没有合规备案编号，没有服务等级协议。
"老孙。"
孙工从隔壁桌抬起头，他正在审工行的密钥管理模块，屏幕上全是加密算法的参数配置。
"你看一下这个。"
孙工走过来，弯腰看屏幕。
刘工用光标指着那行接口名称。
日光灯的光打在屏幕上有一点反光，孙工侧了一下头避开。
"AbySS？"
"没见过。"
"我也没见过。"
孙工拉了把椅子坐下来，自己操作了一会儿。
他从接口调用链往上追溯了两层，找到了AbySS在微光整体架构中的位置。
不是一个普通的第三方服务。
它嵌得很深。
跟微光自己的信用评估模块是紧耦合关系，数据通道是双向的，不仅AbySS向微光返回评分结果，微光的用户行为数据也在持续回流给AbySS。
微光的信用购产品、风控决策引擎、用户额度管理系统，底层都在调用这个接口。
如果把AbySS从架构里抽掉，微光整个信用评估体系的数据基础会塌掉一大块。
"这东西是微光自己的还是外部的？"
"接口命名规范是外部服务的格式，但耦合程度像内部的。"
"代码仓库里有AbySS的源码吗？"
刘工在文件目录里搜了一下，没有。
微光提交的代码包里不包含AbySS的源代码，只有调用接口的客户端SDK。
这进一步说明AbySS是一个独立的系统，不属于微光DCEP方案的交付范围，但微光的DCEP方案在运行时依赖它。
两个人对着屏幕看了五分钟，饮水机发出一声咕噜，气泡在水桶里翻了一下。
"记一笔？"孙工问。
"记一笔。"
刘工打开了审查报告的模板文件。
他们的工作不是判断这个接口有没有问题，是如实记录审查中发现的所有非标准项。
判断是上面的事。
上面会看报告，会开会，会决定要不要追问，要不要让微光补充说明。
他们不需要管那些。
他在模板里找到"非标准外部服务"栏目，新建了一条记录。
审查编号：CR-2021-1247。
审查日期：2021年12月15日。
审查对象：微光科技·DCEP技术方案·支付模块·第三层接口。
发现项：外部数据服务接口"AbySS-CreditSCOre-v3.2"，未在央行技术标准白名单内，无供应商资质备案，调用频次高（日均12
-->>(第2/3页)（本章未完，请点击下一页继续阅读）