阿在 · 新旧服务旅程对比

以真实对话还原顾客IT小王的完整服务过程
场景一 · 配置变更

端口映射配置

小王的网关下挂了交换机,交换机上接了服务器,要把服务器端口放到互联网上可以访问,配了端口映射但不管用
1
接入服务
📞 旧旅程 · 致电400~40 min
拨打400… 售后基础咨询请按1… 售前请按2…
400
你好,请问有什么可以帮您?
400
请问您要咨询的设备型号是多少呢?
王
我这边有一个网关,一个交换机,配置有点问题。
王
我看一下啊。
王
呃,NBR6205-E-V2。
400
好的。那这边需要跟您确认一下,您在我们业务体系中是属于最终用户、工程商还是签约渠道伙伴呢?
王
我们算工程商吧。
400
好的,正在为您查询工程师……先生,查询到当前工程师正在业务处理中,稍后30分钟内给您回电,您看可以吗?
王
嗯。
⏳ 挂断等待回电… 10分钟… 20分钟… 30分钟…
⏱ 已耗时 ~40 min,问题尚未开始
💬 新旅程 · 阿在~1 min
王
阿在,我这边一个网关下面挂了台交换机,交换机上接了服务器,要把服务器端口放到互联网上访问,我配了端口映射但不管用。
▶ 🧠 阿在的思考及过程
▸ 需求识别 小王需要将交换机下挂服务器的端口映射到公网可访问,已在网关上配置了端口映射但未生效。需排查配置问题和网络出口环境。 ▸ 客户信息匹配 根据客户档案,小王所在公司为工程商,当前在用设备为网关 NBR6205-E-V2 + 交换机 NBS6002。该客户同时有两条链路(一条走网关,一条走防火墙),之前有过类似映射需求但在另一套设备上实现的。网关当前通过路可云管理,外网口可能为路可云分配的地址而非直接公网IP,这是映射不生效的高概率原因。 ▸ 服务策略 首先通过CLI连接设备确认外网口实际IP地址和出口环境,判断映射不生效的根因(公网地址 vs 路可云地址 vs 路由冲突),再给出针对性方案。需请小王提供管理平台登录凭证。
阿在
小王您好,端口映射不生效的问题我来帮您排查处理。我需要先连接设备管理平台确认网络出口环境,麻烦您输入一下平台的登录账号和密码。
账号:
密码:
▶ ⚡ 阿在连接设备管理平台 & 获取设备信息
$ azai connect --platform device-mgr --auth wangwei
✔ 已连接设备管理平台
$ azai device list --owner wangwei
网关: NBR6205-E-V2 | 在线 | 路可云管理
交换机: NBS6002 | 在线
$ azai interface show --device NBR6205-E-V2 --wan
WAN口IP: 10.8.65.2 (路可云分配)
出口地址: 218.3.180.180 (运营商公网)
⚠ WAN口为路可云内网地址,非直接公网
阿在
已连接成功。您的设备为 NBR6205-E-V2(网关)+ NBS6002(交换机)。

我看到一个关键信息:网关WAN口地址为 10.8.65.2,这是路可云分配的内网地址,不是直接公网IP。出口地址218.3.180.180是运营商侧的公网地址,这就是您之前配了映射不管用的原因——网关上没有直接的公网IP,常规端口映射无法生效。

您这边还有另一条链路走防火墙对吧?服务器具体要映射哪些端口?
✅ 0等待 · 具体怎么做到的
小王不用拨打400排队等人工、不用等30分钟回电 → 打开阿在直接说需求,秒级响应。不用记设备型号SN码 → 输入平台账密,阿在自动获取设备信息。而且阿在1分钟内就发现了"网关WAN口是路可云地址,不是公网IP"这个根因——旧旅程此刻还在等工程师回电。
⏱ 已耗时 ~1 min,设备已识别
2
需求对齐与方案确认
📞 旧旅程 · 回电 + 远程连接~60 min
终于等到工程师回电
工程师
你好,请问什么问题?
王
是这样的,我们出了一套锐捷的设备,一个网关,下面挂了一台交换机。(重新说一遍)
王
用户突然有个需求,交换机上接了一台服务器,要把一些端口放到互联网上访问,做映射对吧。
工程师
对对对。
王
我看网关上有个端口映射,但是配上了不管用,不知道是我配的不对还是咋回事。
工程师
你这个路由器上有公网地址吗?
王
有公网地址的。但我不确定是不是在路由器上,怎么能判断呢?
工程师
看路由器外网口的IP地址多少。
王
咋说呢,我在设备管理那个地方点网关……这里写着有个出口地址,218.3.180.180。
工程师
要不你这边远程给我看一下?有远程工具吗?
王
可以登,但手机验证码不是绑着我手机。
工程师
那咱们用向日葵远程吧,你把码给我一下。
王
行,我把码念给你啊,739253483。
工程师
你先申请,我看一下。
王
同意怎么点不动啊……
王
那我给你说密码吧。
🔧 远程工具卡顿、按钮点不动、改用密码登录… 又折腾了5分钟
⏱ 已耗时 ~100 min,刚建立远程连接
💬 新旅程 · 阿在~3 min
王
对,还有一条链路走防火墙的,之前在防火墙上做过映射能用。服务器IP是192.168.1.100,映射80和443。
▶ 🧠 阿在的思考及过程
▸ 场景梳理 当前网络结构:网关NBR6205-E-V2(WAN口为路可云内网地址10.8.65.2)+ 交换机NBS6002 + 防火墙(另一条链路,有公网IP 218.3.180.180)。服务器接在交换机上,IP 192.168.1.100。客户之前在防火墙上做过映射是能用的,说明防火墙侧有直接公网IP。 ▸ 方案设计 网关WAN口是路可云地址(非直接公网),直接在网关上做端口映射无法生效。最佳方案:利用防火墙侧的公网IP做映射。具体实现:1) 交换机上配一个路由口与防火墙互联 2) 防火墙映射公网端口到服务器IP 3) 交换机写静态路由指向防火墙做下一跳。需确认防火墙接在交换机哪个口上,以及防火墙侧的IP信息。我通过CLI获取完整拓扑后一并配置。 ▸ 风险校验 需注意:1) 两条链路并存可能导致回程路由不一致 → 通过策略路由指定服务器流量走防火墙出口解决;2) 操作前完整备份网关和交换机配置,确保可回滚。
▶ ⚡ 获取完整拓扑 & 防火墙侧信息
$ azai topo get --device NBR6205-E-V2 --include-switch
网关 NBR6205-E-V2
├─ WAN ── 10.8.65.2 (路可云) → 出口218.3.180.180
└─ LAN ── NBS6002 交换机
   ├─ Port1~22 ── 办公终端 (192.168.1.0/24)
   ├─ Port23 ── 网关上联口
   ├─ Port24 ── 服务器 192.168.1.100
   └─ Port25 ── 防火墙 (公网IP: 218.3.180.180)
$ azai nat list --device 防火墙
现有映射: 218.3.180.180:8080→192.168.1.10:80 (已有业务)
端口80/443 在防火墙侧可用 ✔
阿在
拓扑已确认。您的网关WAN口是路可云地址,无法直接做映射,但防火墙侧有公网IP 218.3.180.180,端口80和443可用。

方案如下,请您确认:
✅ 在防火墙上添加映射:218.3.180.180:80 → 192.168.1.100:80
✅ 在防火墙上添加映射:218.3.180.180:443 → 192.168.1.100:443
✅ 交换机Port25配置路由口,写静态路由实现互联
✅ 配置策略路由确保 回程流量不走错出口
✅ 操作前 自动备份 网关 + 交换机 + 防火墙配置
请确认操作方案
✅ 0转接 · 具体怎么做到的
小王全程只跟阿在一个窗口对话。阿在自己具备拓扑分析和配置能力 → 不用转工程师。阿在实时在线 → 不用等30分钟回电。上下文全程保留 → 不用重复描述。旧旅程此刻工程师还在远程里和小王反复讨论"哪个是公网地址"。
⏱ 已耗时 ~3 min,方案已确认
3
执行配置
📞 旧旅程 · 远程排查 + 来回沟通~90 min
工程师
我进来了。10.8.65.2……他这个好像不是公网地址。
王
但是为什么我看他的出口地址是个互联网的地址?
工程师
对,他这个地址应该是路可云的出口地址。你必须得看外网接口地址。
王
只能看这个地址是吧。
工程师
对,如果外网口地址不是公网地址的话,映射不通的。
王
那刚才那个218.3.180.180是什么意思?那是我们本地的公网固定IP。
工程师
这个应该是最后的出口地址,运营商那边的。
王
不,这个是我们本地地址,我们不止一条链路。
🔄 围绕公网地址/出口地址/路可云地址反复讨论,双方理解不一致…
工程师
如果在这套业务内,你只能根据这个出口地址去做映射。
王
我跟你说,另一套业务已经做了映射了能用,现在我们只是换一个端口做映射。
工程师
但是你两条线出去,可能会导致路由不通或者上不去网。
王
那像我这种情况有没有什么办法?
工程师
或者说我这边后台确认一下,给你回个电。
王
好的好的。
🔄 又一轮来回讨论:服务器接防火墙还是交换机、三层口怎么配、路由怎么写…
王
我找了半天也没找到怎么配三层接口。
工程师
要进web界面去配。上传口那边有个路由口。
王
哦。
工程师
然后选个接口,配个地址,路由在这写。
王
明白了。
工程师
你试一下,如果不行的话再联系咱们。
王
好好,谢谢。那我去试操作一下。
🤔 小王自己试了半小时没弄出来…… 路由口怎么配?地址填什么?下一跳写啥?
📞 再次打400求助… 又要重新排队… 又要重新讲一遍…
⏱ 已耗时 ~3.5h,问题仍未解决,需要再来一轮
💬 新旅程 · 阿在~2 min
王
没问题,执行吧。
▶ 🧠 阿在的思考及过程
▸ 执行计划 按照标准安全流程依次执行:1) 备份网关、交换机、防火墙三台设备配置 → 2) 交换机Port25配置三层路由口,与防火墙建立互联 → 3) 防火墙添加DNAT映射(80/443 → 192.168.1.100)→ 4) 交换机添加静态路由和策略路由,确保回程流量不走错出口 → 5) 端口可达性自动验证。 ▸ 变更风险控制 防火墙已有业务映射(8080→192.168.1.10:80),本次仅新增规则不修改现有配置。两条链路并存的回程路由问题通过策略路由解决,确保服务器访问走防火墙出口、办公上网仍走网关出口。三台设备操作前均完整备份。
▶ ⚡ 执行:备份 → 互联 → 映射 → 策略路由 → 验证
$ azai config backup --device NBR6205-E-V2,NBS6002,FW-外网
✔ 三台设备配置已备份
$ azai interface set --device NBS6002 --port 25 --mode routed --ip 10.0.0.1/30
✔ NBS6002 Port25 已配置为路由口 10.0.0.1/30
$ azai nat add --device FW-外网 --ext-ip 218.3.180.180 --proto tcp --ext-port 80 --int-ip 192.168.1.100 --int-port 80
✔ 防火墙映射: 218.3.180.180:80 → 192.168.1.100:80
$ azai nat add --device FW-外网 --ext-ip 218.3.180.180 --proto tcp --ext-port 443 --int-ip 192.168.1.100 --int-port 443
✔ 防火墙映射: 218.3.180.180:443 → 192.168.1.100:443
$ azai route add --device NBS6002 --dst 192.168.1.100/32 --via 10.0.0.2 --out Port25
✔ 静态路由已添加:访问服务器走防火墙方向
$ azai policy-route add --device NBS6002 --src 192.168.1.100 --dst 0.0.0.0/0 --via 10.0.0.2
✔ 策略路由已添加:服务器回程流量走防火墙出口
$ azai verify --ext-ip 218.3.180.180 --test port 80,443
✔ 218.3.180.180:80 可达 ✔ 218.3.180.180:443 可达
阿在
配置已全部完成,各项状态如下:
三台设备配置已备份,支持一键回滚
交换机与防火墙互联 已建立(Port25路由口)
端口映射 已在防火墙生效(218.3.180.180:80/443 → 服务器)
策略路由 已配置,回程流量走防火墙出口,不影响办公网络正常上网
外网可达性验证 已通过

建议您从外网访问 218.3.180.180 确认一下,如有异常随时联系我。
王
试了,可以了!
✅ 使用门槛低 · 具体怎么做到的
小王不用自己琢磨"路由口怎么配、地址填什么、下一跳写啥" → 阿在通过CLI自动完成交换机路由口配置+防火墙映射+策略路由,三台设备联动一次搞定。不用装远程工具、不用来回讨论公网地址 → 全流程在一个对话窗里完成。旧旅程此刻小王自己试了半小时没弄出来,准备再打400。
⏱ 已耗时 ~6 min,配置完成
4
交付赋能
📞 旧旅程—
旧旅程到此结束:工程师给了方向让小王自己试,试不出来又得再打400。无后续赋能,无脚本,无指南。
💬 新旅程 · 阿在~4 min
▶ 🧠 阿在的思考及过程
▸ 后续需求预判 小王作为工程商,后续大概率还会遇到类似的端口映射调整场景(新增服务上线、端口变更等)。本次涉及网关+交换机+防火墙三台设备联动,配置复杂度较高,建议提供自助操作方式降低未来服务依赖。 ▸ 赋能方案 1) 提供一键调整脚本模板——后续增减映射只需修改端口号和IP即可;2) 提供针对NBR6205-E-V2 + NBS6002这套设备的端口映射操作指南,含三层路由口配置和静态路由的界面操作步骤。
阿在
小王,本次配置已完成。另外为您准备了两份资料,方便您后续自主操作同类需求:

①「一键调整端口映射」脚本模板
后续如需增减端口映射,只需修改脚本中的端口号和目标IP,即可直接执行,无需重复联系技术支持。

②「NBR6205 + NBS6002 端口映射操作指南」
针对您这套设备编写,含路由口配置、静态路由、策略路由的完整界面操作步骤,逐步截图标注。如果您希望通过管理界面手动操作,按指南即可完成。
王
这个好,以后我自己就能弄了。
✅ 物尽其用 · 具体怎么做到的
阿在知道小王是独立IT,主动输出脚本 + 界面指南两种自助方式,匹配不同场景需求。让小王从"每次都得找人"变成"自己能搞定",真正释放设备产品能力。
⏱ 总耗时 ~10 min,问题解决 + 赋能交付

旧旅程

~3.5小时
等回电30min · 远程工具卡顿 · 来回讨论公网地址 · 试不出来还得再打
⚡
效率提升 95%

新旅程

~10分钟
1个窗口 · 1个阿在 · 0次往返 · 含赋能
场景二 · 故障排查

跨境电商多员工上网卡慢

小王收到多名同事反馈浏览网页卡慢,各项设备指标看着都正常
1
接入服务 & 初步排查
📞 旧旅程 · 致电400~30 min
拨打400… 排队… 接入人工
400
您好请问什么问题?
王
我们这好几个人上网特别卡,网页半天打不开。
400
好的您先ping一下114.114.114.114看看。
王
20毫秒,不丢包。
400
那ping一下百度呢?
王
也正常。
400
那您重启一下路由器试试。
王
重启过了,没用。
400
换个DNS呢?改成8.8.8.8。
王
也换了,还是卡。
400
您那边是无线还是有线?
王
有线,网线接的。
400
那换根网线试试?
王
好几个人同时卡不可能是网线问题吧……
400
那这个情况我处理不了了,升级二线帮您看。
🔄 标准话术30分钟:ping、重启、换DNS、换网线… 全是常规操作
⏱ 已耗时 ~30 min,未触及根因
💬 新旅程 · 阿在~3 min
王
阿在,好几个人说上网卡,我看了设备没啥问题啊。
▶ 🧠 阿在的思考及过程
▸ 异常特征分析 多人同时卡慢且设备面板指标显示正常——排除单机问题和链路/硬件故障。需注意:设备概览面板通常只显示CPU/内存/带宽等基础指标,而会话数、连接追踪表等关键运行参数不在默认视图中,这些"隐性指标"需要主动查询。 ▸ 客户画像与案例关联 小王所在企业为跨境电商行业,业务特征包括:高频访问海外电商平台(Amazon/Shopee/Lazada等)、可能存在数据采集/竞品比价类应用、出口带宽需求较大。结合历史同行业案例库,跨境电商客户网络卡慢的高频根因排序:1) 会话数超限(采集/爬虫工具占满连接追踪表) 2) 出口带宽饱和 3) 海外DNS解析延迟。 ▸ 排查策略 通过CLI直接获取设备实时深度指标:会话数/CPU/内存/各接口流量/在线终端列表。优先检查会话数——这是该行业场景下概率最高的根因。需先请小王提供管理平台凭证。
阿在
小王您好,已收到。看到您这边是跨境电商业务,结合多人同时卡慢且设备面板指标正常的情况,初步判断问题可能出在一些常规界面不会直接显示的运行参数上。我先连接设备读取实时深度数据做分析,麻烦您输入一下管理平台的账号密码。
账号:
密码:
▶ ⚡ 连接设备 & 获取实时监控数据
$ azai connect --platform device-mgr --auth wangwei
✔ 已连接
$ azai monitor realtime --device FW2024A08871 --detail
CPU: 35% | 内存: 62% | WAN带宽: 58/100M
⚠ 会话数: 49,832 / 50,000 (99.7%!)
接口错误: 0 | 广播比: 正常 | DNS响应: 正常
阿在
小王,关键问题已定位——您的设备 会话数已达上限的99.7%。

FW-3060最大支持50,000个并发会话,当前已占用49,832个。会话表满后,新的网络请求无法建立连接,表现就是网页加载缓慢。CPU、内存、带宽等基础指标确实正常,因此在设备概览面板上无法发现此问题——会话数属于需要主动查询的深层运行指标。

接下来我进一步分析会话分布,确认是哪个终端在异常占用。
✅ 使用门槛低 · 具体怎么做到的
小王不用自己去看设备里各种参数 → 阿在直连设备读取实时数据,自动识别"会话数超限"这个隐藏根因。400工程师用标准话术(ping/重启/换DNS)排查了30分钟都没触及这个维度。阿在3分钟定位到核心线索。
⏱ 已耗时 ~3 min,发现关键线索
2
根因定位
📞 旧旅程 · L2升级 + 漫长等待 + 等一线到场~3.5小时
🔀 400将工单升级至L2,请小王等待…
⏳ 10:30 升级… 10:40 无进展… 10:50 仍在等… 小王不知道工单到了谁手上
🕐 已等待30分钟,无人联系,进展完全不可见
王
(再次打400)半小时前升级的工单,上网卡的,催一下。
400
我看下……工单在排队,L2那边比较忙,您再等等。
⏳ 继续等… 11:05… 11:10…
L2
您好我是L2小张,上网卡慢的事跟我讲讲?
王
好多人上网卡,ping了正常,重启了没用,DNS也换了。(第2次从头讲)
L2
你先帮我看一下设备CPU和内存占用多少?
王
CPU 35%,内存62%。
L2
这个正常。WAN口带宽跑了多少?
王
58M,总共100M。
L2
也没跑满。你看看有没有接口报错?"接口状态"里的错误计数。
王
都是0。
L2
嗯……那你做个抓包看看有没有异常流量?你会用抓包工具吗?
王
不会。
L2
那这样,你看一下系统日志有没有什么告警信息?在"系统"→"日志"里面。
王
日志……挺多的,好几百条,我看不太懂。
L2
那你截图发我邮箱我看看。
🔄 截图日志、发邮件、等L2看邮件分析… 又过了15分钟
L2
日志没看出什么明显问题。这种情况远程比较难查,得安排人到现场看。
王
多久能来?
L2
提交现场工单,一般2小时到。
王
……行吧。
⏳ 等一线到场…… 11:30 提交工单 → 12:00 无消息 → 12:30 小王催 → "在路上了" → 13:00 还没到
🕐 13:20 一线终于到场。此时同事们已无法正常工作近3小时。
⏱ 已耗时 ~3.5小时(从拨打400到一线到场),L2也没查出根因
💬 新旅程 · 阿在~10 min
▶ 🧠 阿在的思考及过程
▸ 异常源定位思路 会话数达到99.7%,需确认异常占用的具体终端。正常办公终端的会话数通常在200~500之间,若存在单个IP占用数万会话的情况,则为明显异常行为。 ▸ 行业场景关联分析 结合该客户跨境电商的业务特征,高会话数的常见业务场景包括:1) 竞品数据采集/爬虫(高频HTTP短连接,目标域名分散在各大电商平台);2) 商品批量上架工具(并发API请求);3) 代购/比价类应用。这些均属于正常业务行为,但会大量消耗设备会话资源。 ▸ 操作计划 通过CLI导出设备会话TOP数据,按源IP聚合排序定位异常终端。同步获取该IP的终端详情(主机名、MAC地址、物理接入位置、流量行为特征),为客户提供可直接对应到具体人员的定位结果。
▶ ⚡ 会话TOP分析 & 终端信息获取
$ azai session top --device FW2024A08871 --limit 10
#1 192.168.1.88 39,420 (79.0%)
#2 192.168.1.15 1,203 (2.4%)
#3 192.168.1.22 987 (2.0%)
... 其余终端均 <500
$ azai client info --device FW2024A08871 --ip 192.168.1.88
MAC: 5C:E0:C5:XX:XX:XX | 主机名: DESKTOP-LILEE
接入: LAN1-Port8 | 在线时长: 6h23m
流量特征: 大量HTTP短连接,目标分散在多个电商域名(amazon、shopee、lazada等)
阿在
异常源已定位—— 192.168.1.88 独占了79%的会话资源(39,420个),主机名为 DESKTOP-LILEE。

该终端的流量特征为高频HTTP短连接,目标分布在Amazon、Shopee、Lazada等多个电商平台,属于典型的数据采集/爬虫行为。结合您公司的跨境电商业务背景,大概率是在进行竞品商品数据抓取。

小王,这台电脑对应的使用人您了解吗?麻烦确认一下。
王
小李!我去问下。
🗣 小王找小李确认 ~5分钟
王
问了,小李在跑爬虫抓竞品数据,说是业务要用。
✅ 一次问题解决(第一步:精准定位根因)· 具体怎么做到的
不需要升级L2 → 阿在自身具备全链路排查能力。不需要派一线到现场用排除法 → 阿在通过CLI直接拉取会话TOP数据,定位到具体IP、主机名、行为特征。不需要小王自己看设备界面 → 阿在把结论直接告诉小王,他只需要去确认一个人就行。旧旅程此刻L2刚接手、一线还在路上、同事已经无法工作3小时了。
⏱ 已耗时 ~13 min(含确认),根因定位完成
3
实施解决
🏢 旧旅程 · 一线现场排除法~2小时
13:20 一线工程师老刘到达现场
一线
你好我是老刘,上网卡的事跟我说说?
王
好多人上网卡,L2看了CPU带宽都正常,没查出来。(第3次讲)
一线
行,我接上设备看看。
🔧 13:30 开始排查… 先看接口流量、ARP表、MAC表……
一线
接口流量没问题,我换几个口试试,看是不是交换机的问题。
⏳ 13:50 换了3个端口,现象一样… 排除交换机故障
一线
交换机没事。我看下防火墙策略有没有什么异常配置……
⏳ 14:10 防火墙策略正常… 逐条看了ACL也没问题
王
怎么样了?同事一直来问我。
一线
还在排查,你再等等。我看下连接数情况……
⏳ 14:30 终于查到会话监控页面——发现会话数49,800+
一线
找到了,会话数满了。但这个表太大了,我导出来看看哪个IP占得多。
⏳ 14:50 导出会话表… 数据量大需要整理… 逐个口断接测试看会话变化
🕐 15:10——已现场排查近2小时,同事们整个下午无法工作
一线
大概是8号口那台机器会话特别多。先加个限制吧,每个IP上限2000。
王
终于好了?
一线
应该行了,让他们试试。那台机器跑了啥你回头问问。
王
后面还会出这问题不?
一线
不好说,先观察吧。
🩹 15:30 临时限制生效。但:只知道8号口,不知道具体谁、为什么、长期怎么办
📊 从10:00拨打400 → 15:30临时恢复 = 5.5小时。同事一整个下午无法正常工作。
⏱ 第一天已耗时 5.5小时,一线也是排除法试了近2小时才找到会话数问题
💬 新旅程 · 阿在~12 min
▶ 🧠 阿在的思考及过程
▸ 解决方案设计 根因已确认:小李的数据采集工具独占79%会话资源,导致其他终端无法正常建立新连接。需要制定临时恢复方案和长期根治方案。 ▸ 临时方案(目标:立即恢复全员网络) 下发单IP会话数限制策略(每IP上限2000),在不关停小李采集工具的前提下,释放会话资源给其他终端使用,网络可即时恢复。 ▸ 长期方案(目标:业务与办公互不影响) 从客户业务角度评估:竞品数据采集是跨境电商的核心业务需求,不应简单限制或禁止。且该需求不局限于小李个人,其所在团队可能均有同类需求。建议方案为业务分流:为数据采集业务申请独立宽带线路,通过设备WAN2口接入并配置策略路由,实现采集流量与办公流量物理隔离。需查询当地运营商线路资源,同步为客户准备运营商对接材料。 ▸ 服务闭环规划 优先下发临时方案恢复网络,同步输出长期方案供客户推进。如小王需离场,可调度一线工程师到现场接手后续跟进工作,确保服务闭环。
阿在
根因已明确,解决方案已就绪。我们分两步走,先恢复网络再做根治。

第一步 · 临时恢复:下发单IP会话限制策略(每IP上限2000),在 不关停小李采集工具 的前提下释放会话资源,其他同事可立即恢复正常上网。

请确认,我这边即可执行。
王
好,先恢复!
▶ ⚡ 下发临时恢复策略
$ azai config backup --device FW2024A08871
✔ 已备份
$ azai session-limit set --device FW2024A08871 --per-ip 2000 --zone LAN1
✔ 单IP会话限制已生效
$ azai monitor realtime --device FW2024A08871 --quick
总会话: 12,458 / 50,000 (24.9%)
✔ 网络已恢复正常
阿在
网络已恢复正常,当前会话使用率降至24.9%,请同事们确认一下网络状况。

同时需要跟您说明:当前的会话限制属于应急措施。考虑到您公司做的是跨境电商,竞品数据采集是核心业务需求,不仅是小李个人在用,他所在的团队可能都有同样的需求。单纯限制会话数无法从根本上解决问题。

建议采取 长期方案——业务分流:

独立线路:为数据采集团队申请一条独享宽带,从设备WAN2口接入,采集流量与办公流量物理隔离,互不影响。

策略路由:小李团队的IP段走WAN2出口,其他终端走WAN1。线路开通后,这边可以直接为您下发策略路由配置。
▶ ⚡ 查询当地电信商务宽带资源
$ azai isp query --region 深圳南山 --type business
电信商务宽带方案:
├─ 100M独享: ¥680/月 (推荐,可支撑~10万次/日采集)
├─ 200M独享: ¥980/月
└─ 500M独享: ¥1,680/月
阿在
已为您查询了当地电信商务宽带资源。推荐 100M独享方案 ¥680/月,可支撑日均约10万次的数据采集请求,满足当前业务需求。

同时为您准备了与电信客户经理的沟通参考:

"我司有独立的数据采集业务线需要独享带宽,不与办公网络混用。需要一条100M电信商务宽带,要求固定IP,合同按年签订。请问目前有哪些优惠方案?"

线路开通后您通知我,这边直接为您完成策略路由配置。
王
对了,我3点要去做个会议保障,这边能帮我安排人盯一下不?
▶ 🧠 阿在的思考及过程
▸ 当前服务状态 临时恢复方案已生效(网络正常),长期分流方案已输出(独立线路+策略路由+运营商对接材料)。客户小王需离场处理会议保障工作。 ▸ 现场跟进事项评估 仍需现场人员完成:1) 确认临时会话限制策略持续稳定运行;2) 与小李团队当面核实数据采集业务的使用规模和人员范围;3) 后续配合电信线路安装及物理接入。以上事项需要一线工程师到场执行。 ▸ 调度与交接策略 主动发起一线工程师调度,将完整服务上下文(问题描述、排查过程、会话TOP分析结果、已下发的临时方案、长期方案规划)全量同步至一线,确保到场后可直接接手工作,无需客户重复说明。
阿在
没问题,这边为您 调度一线工程师到现场接手后续工作。我会将完整的服务上下文同步给他,包括问题背景、排查过程、已下发的临时策略和长期方案规划。工程师到场后可直接开展工作,不需要您再做任何说明。
▶ ⚡ 调度一线工程师 & 同步上下文
$ azai dispatch create --region 深圳南山 --priority high \
  --summary "跨境电商客户会话数超限-爬虫导致-临时方案已下发-需现场跟进" \
  --context-sync full --device FW2024A08871
✔ 已派单: 一线工程师 老刘(E-2087)
✔ 预计30分钟内到场
✔ 已同步: 问题描述 / 排查过程 / 会话TOP分析 / 临时方案 / 长期方案
阿在
已安排 一线工程师老刘,预计30分钟内到场。全部服务上下文已完成同步。您放心去处理会议保障,后续有任何进展我会及时通知您。
王
行,那我去了,有事联系我。
✅ 一次问题解决 · 具体怎么做到的
一次解决 = 临时恢复 + 根因定位 + 长期方案 + 现场交接,全在一个会话里完成。

· 不用等一线到场才能恢复网络 → 阿在CLI直接下发策略,2分钟网络恢复(旧旅程同事已停摆一下午)
· 不用等复发才发现治标不治本 → 阿在基于跨境电商业务理解,主动给出长期业务分流方案 + 线路推荐 + 沟通话术(旧旅程做了临时限制第二天就复发)
· 小王临时有事 → 阿在调度一线到场并完整同步上下文,小王不用第N次重复描述(旧旅程每换一个人都要从头讲)
⏱ 总耗时 ~25 min,网络恢复 + 根因定位 + 长期方案 + 一线已调度
4
复盘与闭环
📞 旧旅程 · 次日复发又1天+
⚠ 次日,另一个同事也开始跑爬虫 → 又触发会话打满 → 再次卡顿
王
又卡了!昨天不是修过了?
📞 小王再次打400…
400
请问什么问题?
王
昨天修的上网卡又出了。(第4次讲)
400
我看下工单……这个需要再安排人到现场。
🔄 再一轮:等→到场→排查→临时限制…没有长期方案
💀 反复折腾2天,业务受损严重
⏱ 累计 ~2天,问题没有根治
💬 新旅程 · 阿在后续跟进
✅ 小王去开会期间,老刘已到场确认临时方案稳定运行
✅ 小王已联系电信办理100M商务宽带,预计3个工作日开通
阿在
小王,为您同步当前进展:
· 老刘已到场,确认临时限制策略运行稳定,全员网络正常
· 已与小李团队当面确认,目前共3人在使用数据采集工具
· 电信线路开通后请通知我,这边直接为您下发策略路由完成分流配置

届时即可撤除会话数限制,办公网络和数据采集业务各走独立线路,互不影响。
王
好的收到,网络恢复了大家都能干活了,小李那边也没太受影响,感谢!
✅ 最终成效
全程1个窗口、1个阿在。网络即时恢复,根因精准定位,长期方案主动给出且含执行细节。小王临时有事阿在无缝调度一线接手。旧旅程此时还在"复发→打400→重讲→等一线→排除法"的循环里。
⏱ 总耗时 ~25 min + 后续自动跟进,彻底闭环

旧旅程

~2天
4+人沟通 · 3+平台 · 4次重复描述 · 5.5h才临时恢复 · 次日复发
⚡
效率提升 99%

新旅程

~25分钟
1个窗口 · 1个阿在 · 0次重复 · 彻底解决
For Customers

对顾客的价值 · 基于真实场景

不是抽象概念,是顾客在每个场景里真实感受到的差异

场景一 · 配置变更

核心价值:0等待0转接 + 使用门槛低

⚡ 0等待

旧旅程卡在哪:拨400排队3分钟 → 鉴权不过挂断 → 二次来电又排队 → 中午人工满线等1小时+ → 登工单等回电没人理 → 第三次打催促
阿在怎么做到的:打开对话窗说需求,AI秒级响应,7×24无坐席限制,中午/高峰/节假日都一样
旧:3次来电 + 等待1小时+ → 下午1点才开始
新:发消息即响应 → 1分钟内开始处理

👤 0转接

旧旅程卡在哪:400不能处理要转网络组 → 网络组午休没人 → 回电后又要从头讲需求 → 一共说了3次
阿在怎么做到的:全程1个对话窗口,阿在自己具备配置能力(通过CLI直接操作设备),不需要转接任何人,上下文全程保留
旧:3个人对接 + 3次描述需求 + 等转接等回电
新:1个阿在 + 说1次需求 + 0次等待

🖼️ 使用门槛低

旧旅程卡在哪:要记SN码和合同编号(跑机房抄)→ 要在不熟悉的管理界面找菜单填参数(找不到NAT在哪)→ 要装远程工具 → 要找回管理密码(前同事离职了)
阿在怎么做到的:只需输入平台账密,阿在通过CLI自动获取设备信息、自动下发配置(NAT+防火墙)、自动验证,小王不需要懂任何界面操作
旧:跑机房 + 找菜单 + 填参数 + 装远程 + 找密码
新:输入账密 + 确认方案 → 阿在全部搞定

🚀 物尽其用

旧旅程缺什么:配完就结束了,下次同类需求小王还得重走全流程
阿在额外做了什么:知道小王是公司唯一IT,主动给出脚本模板(改参数就能用)+ 界面操作指南(按固件版本定制),让他以后能自助
旧:下次还得打400从头来
新:脚本+指南在手,以后自己能搞

场景二 · 故障排查

核心价值:一次问题解决 + 使用门槛低

🎯 一次解决 · 不复发

旧旅程卡在哪:一线到场排除法搞一下午 → 只做了临时限制没查根因 → 次日新同事跑爬虫又复发 → 再走一遍全流程
阿在怎么做到的:一次性给出"临时恢复 + 根因定位 + 长期方案"全套。临时2分钟恢复网络,长期方案基于跨境电商业务理解主动给出(独立线路分流+运营商推荐+沟通话术),不等复发才想办法
旧:临时限制→次日复发→再来一轮 = 2天
新:临时+长期一次到位 = 25分钟,不复发

🖼️ 使用门槛低

旧旅程卡在哪:小王要自己ping/tracert/重启/换DNS(30分钟无效操作)→ 要自己登设备看会话数(不知道在哪)→ 一线到场也是排除法一个个试
阿在怎么做到的:小王只说了一句"好几个人上网卡",阿在自动连设备获取数据、自动分析会话TOP、精准定位到具体IP和行为特征。小王全程只需要做一件事:去问一下小李是不是在跑爬虫
旧:小王配合做各种测试 + 找菜单看数据 + 一线排除法
新:小王说现象 → 阿在全自动分析 → 小王只确认一个人

🤝 无缝交接 · 不重复

旧旅程卡在哪:400→L2→一线每换一个人都要重新描述问题(讲了4次),信息丢失、进展不可见
阿在怎么做到的:小王临时有事,阿在主动调度一线到场,把完整上下文(问题/排查/方案)自动同步,一线到了直接接手,小王0次重复描述
旧:4次重复描述 + 换人就信息断层
新:0次重复 + 上下文自动同步给一线

🧠 懂业务 · 主动思考

旧旅程缺什么:一线只管修好眼前的故障,不关心业务背景,不会想到爬虫是业务需要、不会给长期方案
阿在额外做了什么:基于跨境电商画像,理解爬虫是业务刚需,主动给出业务分流方案(而不是等小王追问),还查了运营商资源给出具体线路推荐和沟通话术
旧:只管修故障,不管业务
新:懂你的业务,主动给长期方案
For The Vendor

对客户(产品厂商)的价值

低成本让全量顾客获得好且稳定的服务体验
💰

省 · 低成本扩展

省

场景1中400客服+网络组+远程工程师3人协作半天才完成的事,阿在10分钟独立完成。产品增长不加人即可扛住。

加人 → 不加人也能接住
🌍

多 · 全量覆盖

多

场景2中一线排除法的质量取决于工程师个人水平。阿在的分析能力稳定一致,全量客户都能获得专业级排查服务。

仅重客 → 全量客户
🏆

快 · 越级SLA

快

场景2从发起到恢复网络只要15分钟,含根因定位和长期方案。普通客户享受到远超金牌SLA的响应速度和解决深度。

普通SLA → 越级金牌SLA