算力容器公网服务与后台风控

背景、用户与问题

• 客诉问题：累计收到 20+ 条公网访问相关客诉，开发者、企业和学生需要把算力容器里的服务开放到公网。
• 现有方案问题：依赖 SSH 隧道、端口转发等临时手段，链路长、成本高，也不利于平台统一管理。
• 平台问题：开放公网入口后必须做实名、审核、风险检测和封禁/解封，否则会把平台暴露在滥用风险中。
• 目标用户：开发者、企业团队和学生；管理员负责审核与处置，运营负责日常监控。

目标与方案选择

目标：让有公网访问需求的容器用户完成一次可审核、可追踪的开通，同时让平台能发现和处置高风险入口。

• 方案 A（放弃）：直接在容器上开放端口，不做实名和审核。代价是无法识别用户、无法事前拦截，端口滥用会直接扩大平台风险。
• 方案 B（采用）：容器操作栏提供公网服务入口，用户完成实名、提交申请、配置端口，管理员审核通过后重启实例并生成公网入口；后台持续检测、复核和处置。
• 关键取舍：内容检测因隐私与覆盖范围暂不纳入 MVP，先以实名、端口限制、IP/请求路径检测和人工复核控制风险。

产品框架和关键链路

角色与模块：用户侧提供公网服务入口和端口配置；管理员负责审核申请、复核风险；运营后台负责检测、查看、封禁/解封和日志导出。系统依赖实名认证、容器生命周期、算力租赁、计费和运营后台。

关键分支：实名未通过时跳转认证；端口非法或超量时拒绝；实例重启前提示保存任务；高风险实例自动封禁并支持人工复核/解封；实例关机按生命周期回收公网连接。

本人职责、关键动作和取舍

• 我主导公网服务与后台风控的产品设计：梳理用户开通、管理员审核、风险检测、封禁/解封之间的规则和状态。
• 团队边界：研发负责用户端和后台实现，运营负责审核与日常处置，安全提供风险判断规则；我负责产品方案、流程和页面定义。
• 用户与竞品：收集开发者/企业场景，调研直接竞品的开通链路，确定“申请—审核—端口配置—后台监控”的最小闭环。
• 方案判断：功能开放和平台管制必须同时成立，因此把产品拆成用户侧入口和后台管理两个模块，而不是只做一个端口开关。
• 可视化与自动化：公网看板沿用算力实例看板的信息结构；在申请表中采集业务信息，为后续自动处置提供可校准的数据依据。

核心能力、体验验证和风险处理

• 准入控制：实名认证、申请审核、端口范围和数量限制，避免无效或过量映射。
• 变更保护：生成或变更映射前提示实例重启影响，要求用户确认，避免未保存任务造成损失。
• 运行监控：后台以固定周期检测 IP、请求路径和风险等级，人工复核高风险实例，发现紧急异常时自动封禁。
• 处置闭环：支持封禁、解封、客诉复核和日志导出；实例关机时按生命周期处理公网连接。
• 验证：用 20+ 条客诉样本定义准入字段和处置路径，并用原型走查“实名—申请—审核—端口配置—封禁/解封”主链路。

指标、结果及证据边界

当前阶段：已上线，覆盖算力容器公网服务入口与后台公网管理。

公网风控相关客诉从 20+ 降至 0。

我交付了用户侧公网服务入口、管理员审核链路、后台公网看板与封禁/解封规则；上线结果属于团队交付，我负责其中的产品设计与规则部分。

上线后的增长、运营、卡点和复盘

上线后进入运营阶段：用户完成实名、申请和端口配置，管理员持续审核、检测、复核和处置。增长不靠投放，重点是让有公网需求的容器用户完成首次开通，并在后续项目中复用。

关键卡点：内容检测因隐私与覆盖范围未纳入 MVP；端口滥用和误封需要通过规则校准与人工复核控制；运营以人工处置为主，后续再评估自动化比例。