从业务开发到企业级认证平台排障 —— 我在 RG-SAM 的成长经历

前言

2025 年底，我进入锐捷网络参与 RG-SAM 企业认证计费与准入控制平台相关开发与维护工作。

相比之前接触的传统业务系统，这套系统最大的不同在于：

• 业务链路更复杂
• 在线状态实时性要求更高
• 涉及网络认证、Radius、LDAP、Portal 等多个模块联动
• 问题更多发生在“生产环境”
• 很多问题并不是简单 CRUD 能解决的

这段经历让我真正开始接触：

• 企业级平台
• 在线状态管理
• 缓存与数据库一致性
• Kubernetes 容器环境
• 线上问题分析
• NAC 网络准入控制

也让我对“后端开发”有了完全不同的理解。

一、RG-SAM 是什么

RG-SAM 是一套企业级 NAC（网络准入控制）与认证计费平台。

系统主要包含：

• Portal 认证
• Radius 认证
• LDAP 对接
• 无感知认证（MAB）
• 在线状态管理
• 自助服务
• 用户并发控制
• 在线同步
• 设备优先级控制

核心目标是：

实现统一身份认证与网络准入控制。

简单来说：

终端设备接入网络时，需要经过认证，认证成功后才能正常上网。

而系统需要实时维护：

• 谁在线
• 从哪里上线
• 什么设备
• 是否重复登录
• 是否允许抢占
• 是否需要踢人
• 是否达到套餐并发限制

这些业务都属于典型的“强状态系统”。

二、第一次真正接触“线上问题”

以前做业务系统时：

大多数问题都比较固定。

比如：

• 接口报错
• SQL 异常
• 参数问题

但在 RG-SAM：

很多问题只有在真实网络环境下才会出现。

例如：

• 在线人数统计异常
• 在线趋势与实际人数不一致
• LDAP 用户同步缺失
• MAB 无感认证数量异常
• Portal 登录异常
• Redis 缓存与数据库状态不一致
• 在线状态未清理导致重复认证异常

这些问题最大的特点是：

很难复现。

很多时候需要：

• 看日志
• 查数据库
• 分析缓存
• 跟代码链路
• 理解业务逻辑
• 理解认证流程

才能慢慢定位问题。

三、在线趋势统计异常分析

这是我印象比较深的一次问题。

现场反馈：

首页“在线人数”和“在线趋势”数据不一致。

一开始以为：

是不是 SQL 统计有问题。

但后面分析发现：

两边虽然都和 ONLINE_USER 有关，但并不是同一条链路。

首页在线人数

直接统计 ONLINE_USER。

在线趋势

并不是直接查 ONLINE_USER。

而是：

OnlineUserCache → 统计任务 → ONLINE_NUM

也就是说：

趋势数据中间经过了一层缓存与统计沉淀。

最后定位发现：

问题并不在 ONLINE_USER。

而在：

OnlineUserCache 数据不完整。

导致统计任务写入 ONLINE_NUM 的数据偏小。

这次问题让我第一次真正理解：

企业系统里，“缓存链路”本身也是业务系统的一部分。

四、MAB 无感认证问题分析

MAB（MAC Authentication Bypass）本质上是：

通过 MAC 地址完成无感知认证。

系统允许用户绑定多个 MAC。

但现场出现了：

用户 MAB 数量超过最大限制。

理论上：

达到最大值后应该自动淘汰旧 MAC。

但实际数据库里：

有用户存在数百条绑定记录。

后面结合：

• PostgreSQL
• Redis
• 升级时间
• 业务代码

分析后发现：

异常数据主要集中在系统升级期间。

最终推测：

升级过程中的批量处理绕过了正常业务限制逻辑。

这类问题和普通 CRUD 最大不同在于：

需要同时理解业务、缓存、数据库和历史数据。

五、开始真正使用 Kubernetes

以前虽然知道 Docker。

但真正接触 Kubernetes 是在这段时间。

工作期间经常需要：

kubectl get pods -A
kubectl logs
kubectl exec

查看：

• 服务状态
• Pod 日志
• 容器运行情况

也开始逐渐理解：

• Namespace
• Pod
• Deployment
• Service
• 容器日志链路

很多问题实际上：

并不是代码本身。

而是：

• 服务没起来
• 配置异常
• 环境问题
• 容器运行状态异常

这让我开始意识到：

后端开发并不只是写代码。

还需要理解系统运行环境。

六、AI 对研发方式的改变

这段时间还有一个很大的变化：

开始大量使用 AI 辅助研发。

以前：

分析问题可能需要：

• 到处搜
• 翻源码
• 慢慢试

现在：

可以快速：

• 分析代码链路
• 定位可疑逻辑
• 生成排查思路
• 输出问题汇报

但我越来越觉得：

AI 最大的价值不是“替代思考”。

而是：

提高问题分析效率。

真正重要的仍然是：

• 业务理解
• 判断能力
• 现场经验
• 对系统的理解

因为 AI 可以帮你分析。

但最终决定：

• 哪里有问题
• 是否合理
• 影响面是什么

还是需要人来判断。

七、最大的收获

在 RG-SAM 这段经历里，我最大的收获并不是：

“会了多少框架”。

而是：

开始真正理解：

• 企业级系统
• 在线状态
• 缓存一致性
• 认证链路
• 生产环境
• 问题排查

也开始逐渐从：

“功能开发”

向：

“系统分析与问题解决”

转变。

这可能才是后端开发真正有价值的部分。