抓取结果

深信服社区-专业、开放、共享 博文 问答 活动 版块 自助 学习 签到 活动专区有一说一全部版块安全类云计算类培训与认证区域群组数字化任职找文档软件下载工具下载故障案例库自助查询在线课堂在线实验平台合作伙伴技术认证深信服直播间 --> 嗨，我是智能客服信服君！我能1秒钟解决您的问题 --> --> --> --> AI应用创新平台 提供AI应用开发指引 新手指南 不活跃账号归档公告 共创博文专区 #信服智创# 【项目案例】移动5G双域网校园AF防火墙GRE隧道安装 技术专题 各类专题资源集锦 推荐 我关注的人 有更新 我关注的内容 有更新 --> 本周精选 版块推荐 经典汇总 产品新版本 --> 有奖调研 Beta 招募：AD7.0.29R1 更多> --> 更多 参与“磐石行动”体验产品升级   2026年破雾计划   用户手册合集   最佳实践合集   服务工具全景图   技术专题   直播回放   社区身份认证常见FAQ   2025深信服合作伙伴技能争霸赛   热点装备合集   产品建议专区   全国研修班招募令 | 2天让客户两天爱上FastGPT深信服商业版 对于FastGPT深信服商业版客户想要，但不敢买？​怕上手难、怕缺少专业指导、怕正式采购后用不好产品、怕投入打水漂……怎么破？用一场集中培训，让客户亲自验证产品价值《FastGPT深信服商业版实战研修班》全国巡讲计划正式启动！两天线下集训，理论+实操+一对一指导，零基础也能快速上手。客户在培训中深度体验产品逻辑，对价值的认知从“功能列表”升级为“业务可落地”，为采购决策注入强心针。通过考核者，还可获得工信部+深信服联合认证，培训成果可衡量、可汇报。 研修班核心信息 培训主题： 《Sangfor Agent Builder 平台应用与实操技能专项培训》 培训形式： 线下1~2天：理论+实操+答疑+一对一指导 培训地点： 全国各地 培训时间： 2026年6~9月 参训人群： 客户开发、运维、AI业务相关技术岗 培训费用： List价4200元/人；普通渠道7折、金牌6折、总代5折 限时福利： 2026年7月5日前下单，前10个项目额外享5折优惠 培训证书： 工信部AI应用开发专家证书 + 深信服Sangfor Agent Builder证书 培训目标： 客户熟练掌握产品核心操作，能自主搭建业务助手，彻底打消“不会用”的顾虑； 客户深度认可深信服AI产品及服务能力，建立长期合作信心 报名咨询：李老师（18511696946） FastGPT深信服商业版实战研修班-招生海报 深信服认证 2026-06-18 26 0 广东联通如何应对招标中的“原厂培训认证”硬指标？ 一、客户需求：采购清单背后的“能力焦虑”近期，广东联通某安全项目招标中，客户不仅对安全运营平台等设备提出了性能要求，更提出了超越产品采购的深层人才培养需求：绑定原厂认证的系统化人才培养机制，将培训认证列为项目核心验收指标。https://wework.qpic.cn/wwpic3az/950854_t3qQ2jbWRfOpEJb_1781658166/0 招标文件截图这一指标揭示了客户的三大核心需求： 能力验证刚性化：培训效果必须可衡量、可验证，原厂认证证书是唯一的、具有公信力的标准。 人才培养体系化：非一次性讲座，而是需要系统化的课程、考核与认证闭环，确保知识有效转化。 业务绑定深度化：将人员能力达标与项目最终验收、款项支付直接关联，体现了客户对“人才成功”与“项目成功”同等重视的决心。 客户的深层需求显而易见：采购一套先进的安全运营平台，仅仅是第一步。他们更迫切的需求是确保运维团队能深度掌握、熟练运营这套平台，最大化释放产品价值，从而真正提升整体安全防护与运营水平。 二、深信服方案：提供“产品交付+人才培养”一体化赋能体系我司深刻理解客户的期望，并未将培训与认证视为产品的附属服务，而是将其作为整体解决方案中不可或缺的核心组成部分。在本项目中，我们打破传统“卖完产品即结束”的模式，将产品交付与人才培养深度耦合，构建了一套“产品到位、技能到手、能力生根”的一体化赋能体系： 产品交付：提供高性能安全运营平台，满足业务刚需； 人才培养：同步嵌入原厂认证培训，确保团队从“会用”到“精通”； 成果绑定：将人员认证通过率与项目验收挂钩，倒逼知识内化与实战转化。 通过这一体系，我们实现了一次交付、双重落地——既交付了先进的安全产品，也为客户留下了可持续进化的安全运营能力。https://wework.qpic.cn/wwpic3az/102914_v943bQbZQ86clbU_1781658167/0https://wework.qpic.cn/wwpic3az/110563_b2M0SFlpQdesRLU_1781658167/0 采购合同截图（部分） 三、价值总结：从“项目交付”到“能力共建”的范式转变通过本项目，深信服与运营商客户共同实践了一种更高阶的合作模式： 解决了“重建设、轻运营”的行业痛点：安全运营类产品不同于传统安全设备，需客户真正“用好”才能发挥运营效果、兑现产品价值。因此，培训至关重要——它帮助客户理解产品设计逻辑，减少非必要定制需求；也让客户更熟练使用工具，释放原厂与渠道支持精力。 构建了长期信任的伙伴关系：运营商历来重视人才能力建设。深信服提供的不仅是产品，更是帮助客户团队成长的能力。当客户因我们的培训而变得更专业，双方合作将从简单的供需关系，升级为共同探索最佳实践、共筑安全能力的战略伙伴关系。 XDR培训认证服务交付模式项目配套的【XDR培训认证服务】分为三种交付模式，具体交付内容及收费标准，见下图所示：https://wework.qpic.cn/wwpic3az/145338_yW_06Fo0Q86WDYW_1781658167/0 XDR培训认证服务下单路径 物料上架位置：已上架在【分布式XDR软件】和【国产化分布式XDR软件】两款产品的服务下，可直接下单。 SCP选型路径：安全BG产品 → AI安全运营 → 分布式XDR软件/国产化分布式XDR软件 → XDR平台 → 服务 → XDR安全运营培训服务。 四、关于培训认证服务FAQQ1：XDR已有安服初始化服务，里面包含了培训，为什么还要单独采购培训认证服务？这两项服务互为补充、各有侧重，但是核心目标一致，都是助力客户用好产品。 专项培训认证：侧重为客户搭建一个整体理论框架，让客户能够从全局视角充分理解如何开展并做好安全运营，解决“看不懂、不会统筹”的问题。 安服初始化培训：侧重于具体运营中的技术细节与操作执行，二者定位各有侧重。 例如：部分客户反馈，若直接讲解技术细节，容易难以理解；理论框架先行，更有利于后续实操吸收。 Q2：产品培训难道不是客户购买产品后的配套服务吗？为何要单独付费？过去，各区域的培训水平参差不齐，交付质量完全依赖个人能力，效果无法保障，且无权威成果认证。如今，我们将其打造为一项专业的增值服务，从四大维度提升交付质量及客户满意度： 课程基线标准化：专职讲师团队，基于场景讲解原理，制作标准化课件并持续更新维护；还配套了专业学习平台及体系化视频课程。 讲师基线规范化：产教专家讲师+区域一线讲师，所有授课讲师均通过严格考核持证上岗，保障授课专业性。 授课基线流程化：依托标准SOW服务范围与SOP执行流程，全程规范化交付，杜绝授课随意化、流程碎片化。 学习成果可量化、可汇报：客户完成培训并通过考核后，可获取深信服技术认证+工信部联合认证证书，能力成果官方认可、可落地汇报、可纳入团队资质考核。 五、XDR培训认证服务宣传海报（欢迎直接转发客户及合作伙伴）https://wework.qpic.cn/wwpic3az/57381_6KafV_L0QDCoRTR_1781658169/0 https://wework.qpic.cn/wwpic3az/36334_-RRSPiOoRQmfjEi_1781658167/0 接口人：培训认证部 李丹（15925）访问support.sangfor.com.cn，获取更多支持 深信服认证 2026-06-18 468 0 用FastGPT搭建岗位模拟面试Agent的实战手记 用FastGPT搭建岗位模拟面试Agent的实战手记 故事从一个崩溃的周五开始 我们电厂要搞年度中层晋升评审。20个候选人，6个专家评委，排了3天档期。结果周五下午，两位评委临时出差，整个排期全崩了。 HR来找我："兄弟，能不能想想办法？" 我能有什么办法？一个搞IT的，又不是做人力资源的。但那天晚上回家，我盯着手机里的AI助手发呆——能不能让AI当面试官？ 不是那种随便聊两句的聊天机器人，而是真正能出题、追问、评分、出报告的模拟面试。 第二天早上，我打开了FastGPT。 从0到1：我是怎么把AI训练成面试官的我先把电厂几个核心管理岗位的胜任力要求理清楚——企业负责人要懂安全合规和应急管理，财务总监要懂成本管控和风险预判，办公室主任要懂跨部门协调和立即响应。 然后在FastGPT里搭了一条工作流，逻辑很简单： 选角色 → AI出5道场景题 → 逐题作答 → 四维度评分 → 出评估报告 核心踩了三个坑： 坑1：AI出的题太"通用"。一开始不管选什么岗位，AI出的题都像公务员考试。后来我在Prompt里硬塞了"电厂"这个上下文，并且要求"必须基于该岗位真实工作场景出题，不能是泛泛的管理题"，题目质量直接起飞。 坑2：用户答题节奏不对。一开始5道题一次性全抛出来，用户要么乱答要么只答前两道。改成"先看题→表单作答→下一题"的节奏后，沉浸感完全不一样，就像真的在面试。 坑3：评分飘忽不定。AI评分最大的问题是"给分太温柔"，人人都80+。我调整了评分Prompt，要求"严格按四维度打分，每维度必须给出具体扣分理由"，评分区分度明显提高。 效果：3天→1天，6个专家→0 我拿真实数据说话： 对比项 传统专家面评我的Agent 单人次评估耗时60分钟20分钟 专家人力投入2人/场0人（AI自动） 题目开发周期2周/岗位即时生成，0等待 评分一致性因人而异，偏差大标准统一，偏差<10% 上次那20人晋升评审，用Agent做初筛，1天搞定。专家只需要对高分候选人做终面确认就行。最让我意外的是，有个候选人跟我说："比真人面试官还紧张，因为AI不会给你面子，答不好就是答不好。"这句话让我觉得，这东西真的有用。 不止电厂，所有行业都能抄 我这个Agent的架构是"角色选项+评分Prompt"驱动的，电厂只是我当前的行业。理论上： 制造业的厂长胜任力评估——换角色选项和行业Prompt 银行的支行行长竞聘——换角色选项和行业Prompt 医院的科室主任选拔——换角色选项和行业Prompt 一次搭建，全行业复制，边际成本趋近于零。 特别适合大型集团企业做人才盘点、竞聘上岗、培训效果检验，不用每次都拉专家排期了。 三点真心话 1. AI不会取代面试官，但会让面试官只做最有价值的事——终面判断，而不是机械出题和初筛 2. 低代码不是"低智商"，FastGPT的工作流编排比我想象的灵活得多，关键是你对业务的理解有多深 3. 最大的坑不是技术，是Prompt——同样一个节点，Prompt写得好不好，效果天差地别Agent名称：环保能源角色扮演（电厂岗位模拟面试Agent） 搭建平台：SF-FastGPT工作流 参赛：Agent Builder 企业级 Agent 实战挑战赛 如果你也在做人才评估，或者只是好奇AI面试官到底靠不靠谱——试试就知道了。有问题评论区见 新手806766 2026-06-12 1k 0 让算力易治理，高效能！深信服AI算力网关正式上线 7.69万亿Token！ OpenRouter最新数据显示，5月11日~5月17日一周，中国大模型周度总调用量约达7.693万亿Token，已达美国的1.81倍，连续三周登顶全球。 中国AI产业正在全面爆发，各行业的Agent应用发展更是迅猛。对企业来说，管好这些Agent并不容易，首先难算清的就是“成本账”——算力使用情况看不清、Token资源浪费管不住、AI投入省不下。一个3000人的研发团队，一个月的外部调用费用可能高达百万元。这中间有哪些是简单诉求调用了最贵的大模型，造成资源浪费；又有哪些是核心业务场景跑着跑着，突然就算力不够用了？ 为了帮助各行业用户实现AI模型和算力的高效治理，深信服发布AI算力网关，与用户共同应对AI Agent时代的算力挑战！ 我们先简单介绍一下： 深信服AI算力网关，是用户自己的“AI算力智能调度中枢”，能为用户实现Token治理、成本治理、安全治理。通过强大的可见性，以及“看到 - 管好 - 用好”的全生命周期护航，将AI能力转化为驱动业务持续增长的核心引擎，让用户的每一份算力都看得清、管得住、省得下、用得稳、更安全。 用深信服自己来举例，我们有3000人的研发团队，在用上AI算力网关之前，每个月Token花费上百万，AI Coding本地算力成本上亿。现在，通过AI算力网关对算力的调度及一系列的优化手段，外部Token调度成本每月可节省40万+，本地算力成本直降数千万！ 具体是怎么做到的？深信服AI算力网关从3个层面解决问题。 01：3个角度，方方面面搞定Token治理Token用了多少、用在哪里，搞不清、管不住；模型频频卡顿出错，业务稳定性无从谈起。要让AI转型更高效，就得先治理好Token资源，在这方面，我们能帮用户做到：看得清、管得住、用得稳。 看得清：强大的算力+模型可见性，提升AI落地效率如果你还在经历：各种算力买了很多，使用量很大，但难以获知各部门Token的使用情况，有了深信服AI算力网关之后，一切状况都能看得清了。我们从多个维度实现全局可视—— 开放兼容、统一入口，所有算力及模型资源皆在眼前通过统一的入口，我们可以看见各类云端模型、本地和租赁算力，在统一的管理界面里，用户可以直接完成模型和算力资源的接入。 各类模型接入兼容OpenAI和Anthropic等协议，各类算力的接入也不会被算力平台厂商绑定。当需要扩展更强大的模型服务时，无需改造AI应用即可快速获得最新模型能力，并由AI算力网关统一对接。 可视可控，Token用量一览无遗，加速AI转型AI算力网关可以进行精细化用量统计，用户可分别从业务组、应用等维度看见Token的调用量、消耗额度、成功率、配额等情况，从而有效推动各部门AI转型、推动明星AI应用的推广。 通过打造强大的可见性，我们希望帮助用户以细颗粒度的Token治理，真正看清算力资源的状况，让AI创新在组织内的落地速度得到数倍提升。 管得住：AI算力精准管理，让每一分算力用有所值各部门都说算力不够用，但这些资源到底有没有用在真正有价值的场景？有了AI算力网关，AI资源的管理和控制就有了科学手段，想知道算力用在哪、哪些业务需要重点保障，都没问题。 在AI算力网关里，我们可以按照组织架构和API Key进行配额管理，管理员可以为下属组织和员工设置Token费用配额。为保障重点业务的运行，还可以对不太关键的需求或异常请求进行精准限流，让算力优先流向更有需要的地方。 AI算力网关通过对Token的精细管控，可以让全局Token消耗降低50%，核心业务AI算力保障能力提升2-3倍。 管好算力资源之余，AI算力网关还能帮助用户更好地管理显卡资源。我们将私有基础设施服务化，实现本地算力API Key的管理和限流，模型服务也可进行多Key精细化权限控制，满足不同部门的资源需求，显卡资源利用率倍增。同时，面向所有算力建设，我们提供GPU基础设施服务化能力，现在已经完成业界主流显卡的兼容适配，各类新卡新模型可快速适配。 用得稳：让AI业务运行更稳定、更可靠把AI算力管好了、治好了，我们还需要关注AI业务的实际运行够不够稳定。在这方面，AI算力网关主要从两个方面发力——创新技术模型聚合路由，让单点故障不再影响业务，敏态AI业务体验更流畅可靠模型服务一旦出现卡顿、异常，甚至宕机问题，就会严重影响业务的正常运转，带来业务损失。AI算力网关通过配置跨本地资源池、跨模型供应商的轮询调度策略，来避免业务高峰单点模型服务过载故障，保障服务流畅稳定。 同时，我们还可以通过配置本地算力+云端模型优先级策略，让云上云下的模型弹性切换，自动分流，缓解高峰压力，从而保障AI业务的流畅运行。 平台自身生产级可靠，匹配生产级核心业务需求除了规避故障风险，AI算力网关本身具备生产级可靠性，以极低开销时延、多实例热备能力和高可靠基础设施底座，保障用户的生产业务体验。 在看得清、管得住、用得稳之余，AI算力网关还为Token治理配置原生Agent，CEO、财务、HR、CIO、研发等各角色，只要向它提个问，就可以在此获取Token投入与业务成效的投入情况，一目了然。 02：关键技术加持，分分钟搞定成本治理当用户的AI建设越来越深入，和成本挂钩的难题就会越来越多——云端各种MaaS模型如何选择？算力不够只好堆显卡？云端和本地哪个更划算？ 深信服全力打造创新技术，为用户持续、大幅降低本地算力和模型费用。 省得下：创新技术加持，让AI越用越省钱传统的模型调度方式基本是黑盒化，各类问题都可能去调用最贵的模型，导致企业成本居高不下。本地算力也存在类似问题，如异构品牌显卡算力不均，导致大参数资源池算力不够用，中小参数模型资源池却利用率低下。现在，AI算力网关可以帮忙优化这类成本难题了。 深信服创新自研的智能路由引擎，就是AI算力网关实现成本优化的核心技术之一。 智能路由引擎有两个硬核的特点： 可解释性高：支持在页面端实时追溯不同场景下的决策因子，这种白盒化的调度机制，让用户对每一笔算力流向都心中有数。 准确率高：深度适配OpenClaw等典型Agent请求特征。通过对任务意图的精准分类，AI算力网关能确保不同类型的AI诉求都能匹配到最合适的算力资源。 因此，AI算力网关可以实现精准判断并将简单的问题调度到更简单的模型，将复杂问题调度到顶尖模型。保障效果的同时，用户每月可节省约50%的成本！而针对本地算力的使用，我们也有创新技术突破，可实现大幅成本优化。 对于大量大小模型混合使用的Agent构建场景如Embedding、Reranker、OCR、TTS等，AI算力网关支持算力1%，256MB级显卡资源切分，单卡承载模型数量可翻8倍以上，显卡越高端、模型使用越多，越省钱。 对于重载AI应用场景深信服AI算力网关通过自研的自适应架构层，提供工具、集成的监控等手段，来辅助定位应用场景的性能瓶颈，再结合自适应的原子优化能力，实现应用端到端承载的ROI提升。 如AI Coding场景，我们可以实现本地算力的ROI提升2~5倍起！ 03：告别翻车，轻松搞定安全治理Agent的大量落地本身会带来巨大的安全风险。应用隐私数据无管控造成核心资产泄露、智能体自行删光数据信息等等，“翻车”事件频频发生。 更安全：核心资产不泄密深信服AI算力网关继承了深信服自身的安全基因，在这方面做了充足防护。 AI算力网关集成深信服大模型安全护栏，对接简单，一键即可开启，应用端无需改造即可根据不同的路由灵活配置安全策略，保障核心资产不外泄，业务运行更安全。 AI落地、算力爆发，深信服AI算力网关不同于业界通用API Gateway、单一MaaS平台或单点优化工具，我们不是“替代一切”，而在于补齐各行业用户在AI供给侧最缺失的治理与调度中枢，助力各行业用户AI创新效率大幅提升，在AI转型中告别成本焦虑，轻装上阵，让每一笔投入都转化为实实在在的、安全可靠的AI生产力。 欢迎体验！ 七嘴八舌bar 2026-05-26 4k 2 更多> 发布了新版本： AD 7.0.29R1 重磅上线！Beta 招募：新功能抢先测，等你来体验！ 全面提升性能吞吐与高可用能力，同时通过授权热变更、SNMP/API优化、日志性能提升等多项增强，实现"更高性能、更易运维"的产品升级。 阅读全文>> 2026年06月6日 15:11 3k 0 分享 AD版块优秀博文 AD故障案例集 AD产品文档 【数智化服务平台】三步入驻数字化服务，立即体验AI服务新生态 数智化平台“先锋共创营”正在招募，加入即享5大专属权益！报名入群领1000S豆，限前30人先到先得->>点击立即报名 ———————————————————————————————————— 七嘴八舌bar 2026-04-24 7k 2 #信服智创#【案例分享】防火墙8.0.107版本ipsec vpn路由模式对接天融信防火墙ipsec vpn虚拟路由 信服智创 | 参与得豆！2026技术征文大赛正式启幕！ 本期案例为替换天融信防火墙ipsecVPN的方案分享 天融信防火墙新版的一些墙，在做ipsec vpn第二阶段填写感兴趣流时，并不是写多个网段，而是只能写一个网段，其他子网通过虚拟路由的方式打通。 那为啥不写多个网段的方式？因为天融信本地网段和对端网段配置框只能写一个段。 所以在深信服防火墙替换或者对接天融信防火墙时，按照正常逻辑配置感兴趣流的方式是行不通的，虽然第二阶段可以成功建立起来，但是你的网络实际上是不能正常通信的。 但是在防火墙8.0.107版本新推出了一个ipsec vpn 路由模式，这个路由模式跟上面提到的虚拟路由逻辑几乎是一模一样的，在第二阶段配置时只需要写加密算法即可，默认放通所有子网段，包括对端和本端都是全部放通的。 接下来给大家放图演示一下，配置也是肥肠的简单。1、下图是一个已经配置完成的界面，可以看到这里的隧道模式已经变成了路由模式。2、第一阶段的配置不变，跟标准配置ipsec的内容一致。3、在第二阶段时，有个与天融信的虚拟路由有些不同的地方，就是咱们得配置vpntun口，这个vpntun口需要配置IP地址，但是这个地址无所谓只要不冲突就行，不参与隧道传输。4、配置完成后可以看到感兴趣流的网段是全部。5、随后对端有哪些网段，直接通过静态路由的方式写过去，不需要写下一跳，接口选择上vpntun口就行，如果有多个分支，会用到多个vpntun口，只需要注意写对口就行。至此深信服防火墙8.0.107版本的ipsec vpn路由模式配置就完成了。其中需要注意的是：正常来说一个分支单独用一个vpntun口，如果需要一个vpntun口对接多个分支的话，需要在路由高级配置里面，写上对端的vputun口地址，这个功能没有用到过，看着只能自家防火墙对接的时候才会用到吧。 最后再给大家看一下天融信那边的配置，没有做过的可以熟悉一下界面。隧道建立配置路径：第一阶段：第二阶段【可以看到只能写一个网段，不能写多个】：隧道路由【跟咱们写的vpn路由逻辑一样】： 魏溢森 2026-05-07 10k 6 更多> 云产品服务订阅 主题数：38 关注人数：1033 软件 案例 资料 --> 助力每一次变更 | 云产品售后变更自动化工具全景解析 HCI基础运维&智能运维价值一览 aDesk基础运维服务价值一览 软件定义数据中心SDDC  主题数：5748 关注人数：13302 软件 案例 资料 --> 全球供应链风险加剧，IT基础设施如何从容应对价格变量？ 深信服SDDC技术深度解析与创新实践（持续更新） SDDC超融合AI三部曲（第二期） AI部署指南 #信服智创#【项目案例】利旧第三方服务器扩容深信服HCI集群实战：资源瓶颈下的平滑扩展方案 信服智创 | 参与得豆！2026技术征文大赛正式启幕！利旧第三方服务器扩容深信服HCI集群实战资源瓶颈下的平滑扩展方案目录： 一、项目背景：76%的内存使用率，逼近n-1冗余红线 1、问题分析 2、客户诉求 二、方案设计：利旧，但不将就 1、方案评估 2、新增节点硬件配置 三、实施前准备：信息对齐是平滑接入的前提 1、软件版本对齐 2、硬件兼容性对齐 3、网络配置对齐 四、实施过程：从兼容性验证到平滑扩容 1、物理上架与连线 2、原集群健康检查 3、提前导入授权 4、新节点安装与集群接入 5、巡检验证与资源均衡 五、典型问题复盘 问题一：系统安装后无法进入系统——“消失”的启动项 问题二：虚拟存储扩容时硬盘不识别——HTTP 500背后的“硬盘坏道扫描超时” 六、实施结果与价值 1、资源变化情况 2、n-1冗余能力恢复 3、项目价值 七、项目经验总结 1、利旧扩容，“对齐”比“安装”更重要 2、第三方服务器最大的风险是不确定性 3、通用报错，要往“下一层”看 4、分批扩容，本质是“分步控制风险” 八、结语 一、项目背景：76%的内存使用率，逼近n-1冗余红线 某客户三节点深信服HCI集群已稳定运行近两年，承载核心业务系统及多套生产虚拟机环境。 近期在日常巡检中发现，集群资源利用率持续升高： 指标当前状态 集群节点数3节点 单节点内存1TB 集群总内存3TB 内存使用率长期维持75%+ 存储使用率55% 1、问题分析 （1）从表面看，业务仍可正常运行，但对于超融合集群而言，76%的内存占用率已经逼近n-1冗余安全红线。 （2）在n=3架构下，一旦任意节点故障，剩余两节点需要承载全部业务负载。 （3）按照现有资源占用情况测算：单节点故障后，剩余节点内存将接近满载运行，存在业务性能下降甚至虚拟机无法正常拉起的风险。 （4）与此同时，客户未来半年内还计划新增业务系统，扩容已成为必须解决的问题。 2、客户诉求 ①尽量降低扩容成本； ②不影响现有业务运行； ③保持集群冗余能力； ④尽可能缩短实施周期。 客户现场恰好有一台闲置的Dell R750服务器，硬件配置与现有节点比较接近。为应对资源瓶颈并控制成本，本次项目决定采用利旧这台服务器进行扩容。 因此，本次项目的核心目标也随之明确：验证第三方利旧服务器能否平滑接入现有深信服HCI集群。 二、方案设计：利旧，但不将就 1、方案评估针对本次扩容需求，我们评估了两种方案： 方案 优点 缺点 结论 新增官方节点官方兼容性保障，实施风险低成本高预算不满足 利旧第三方服务器成本低、盘活闲置资产存在兼容性、不确定性最终采用 虽然最终选择利旧方案，但“利旧”并不意味着“直接上线”。 对于HCI集群而言，第三方服务器接入最大的风险主要集中在以下几个方面： 1、CPU指令集兼容性 2、RAID卡模式差异 3、网卡驱动兼容性 4、硬盘配置是否合理 因此，本次实施的重点并不只是“扩容”，而是：如何让第三方服务器稳定、平滑地融入现有生产集群。 2、新增节点硬件配置 配置项 参数 服务器型号Dell R750 CPUIntel Xeon Gold 6342 内存64GB DDR4 3200MHz ×16，总内存1TB SSD4 × 1.6TB HDD8 × 8TB 三、实施前准备：信息对齐是平滑接入的前提 为了降低第三方服务器接入风险，实施前重点进行了“三类对齐”。 1、软件版本对齐 首先收集原集群信息：HCI版本、补丁版本、CPU信息。 新节点必须使用与现网完全一致的ISO版本进行安装。 2、硬件兼容性对齐 由于本次为第三方服务器利旧扩容，硬件兼容性是整个项目中风险最高的部分。 虽然新节点能够正常安装系统，但如果底层硬件存在兼容性差异，后续仍可能出现：虚拟机迁移异常、存储识别失败、网络性能不稳定、驱动兼容问题、集群节点告警、节点无法正常加入集群等情况。 因此，实施前重点对以下硬件进行了逐项核对与验证： 检查项 检查内容 目的 CPUCPU型号、指令集、虚拟化特性避免虚拟机迁移异常或兼容性问题 内存内存容量、频率避免性能不一致导致资源调度效果差 硬盘SSD/HDD规格、接口类型、健康状态确保存储扩容稳定性 网卡网卡型号、速率、驱动兼容性避免网络异常或链路不稳定 RAID卡RAID模式、固件版本保持存储逻辑一致 BIOS配置启动模式、虚拟化开关、节能策略避免系统安装及启动异常 3、网络配置对齐 提前梳理现网的：VLAN规划、MTU配置、链路聚合模式、VxLAN网络、存储网络规划。 原集群主机网络规划如下，新节点需尽可能保持一致： 网络类型 配置方式 存储网络双万兆口聚合 管理/业务/VxLAN双万兆口聚合（复用） 在此基础上，网络层面还有一个容易被忽略但非常关键的冗余设计： 聚合口成员端口必须跨物理网卡部署。 错误示例：网卡A的Port1与Port2做聚合 正确示例：网卡A的Port1与网卡B的Port1做聚合 这样设计的价值在于：如果某一整张网卡故障，聚合口不会整体中断，网络仍可降级运行，避免单卡故障导致业务中断。 本次实施中： 聚合口成员端口 存储网络聚合网卡A Port1 + 网卡B Port1 管理/业务/VxLAN复用网卡A Port2 + 网卡B Port2 该设计确保了网络层面的网卡级冗余能力。 四、实施过程：从兼容性验证到平滑扩容 整个实施过程分为四个阶段。 1、物理上架与连线 按照现网标准完成：万兆光口连接、聚合配置、VLAN配置、交换机侧LACP配置。 2、原集群健康检查 扩容前，使用集群自带的一键检测功能进行基本健康检查，重点确认：无异常告警、无存储异常、无节点告警、无网络异常，避免“带病扩容”。 3、提前导入授权 在扩容前，需提前为新节点准备并导入授权，确保新节点加入集群后功能正常。 关键原则：此操作务必在节点加入集群前完成。 具体操作步骤如下： （1）授权获取：销售授权下单后，会自动归属于客户的云图账号。 （2）授权合并：在云图平台上，将新节点的授权（2 CPU）加入到原集群的授权（6 CPU）中，进行统一管理。 （3）离线激活： ①从原集群导出设备信息。 ②在云图平台上进行离线激活操作。 ③生成新的授权文件后，导入回原集群。 ④结果确认：授权导入成功后，集群授权状态会更新为 6/8（已使用/总授权），表示原6个CPU授权已生效，新增的2个CPU授权已就绪，等待新节点加入后占用。 （4）注意事项：提前完成授权导入，可以避免节点因授权不足导致无法加入集群，这是扩容前重要的准备工作之一。 4、新节点安装与集群接入 使用与现网版本一致的ISO安装系统，随后加入生产集群，依次完成：管理网络配置、业务网络配置、存储网络配置、VXLAN网络配置。 完成网络配置后，再次使用一键检测功能对新主机的网络进行二次连通性验证，确保无误后开始存储扩容。 5、巡检验证与资源均衡 存储扩容完成后，利用巡检工具对平台进行全面巡检，确认无误后：手动迁移部分高负载虚拟机到新主机，或待系统自动触发资源负载均衡调度。最终确认：节点资源均衡、虚拟机运行正常、存储状态正常。 五、典型问题复盘 本次实施过程中出现了两个典型问题。虽然最终都成功解决，但排障经验值得记录。 1、系统安装后无法进入系统——“消失”的启动项 ① 现象 系统安装完成后重启，无法进入系统，反复进入BIOS或停留在启动设备选择界面。 ② 排查过程 进入BIOS检查启动顺序后发现：安装系统的RAID组并未被设置为第一启动项。系统虽然已经成功安装，但BIOS未自动调整启动优先级。 ③ 根因分析 第三方服务器的BIOS未正确识别新引导项，导致系统无法正常启动。 ④ 解决方案 手动调整BIOS启动顺序：Boot Sequence → 将RAID系统逻辑盘调整为第一启动设备 → 保存重启。问题解决。 ⑤ 经验总结 建议将以下内容纳入标准检查项：安装完成后检查BIOS启动顺序，验证RAID引导项是否生效。 2、虚拟存储扩容时硬盘不识别——HTTP 500背后的“硬盘坏道扫描超时” 这是本次项目中排查耗时较长的环节。 ① 现象 新节点加入集群成功后，进入虚拟存储扩容界面，却无法识别新增硬盘。页面仅提示：“服务器出错，无法完成请求(HTTP错误)，请稍后重试。” ② 初期误判 由于报错信息过于通用，初期排查方向出现偏差： 1.怀疑存储网络异常； 2.怀疑RAID配置异常； 3.怀疑硬盘未正确初始化。 期间进行了 1.网络连通性检查； 2.RAID状态检查； 3.BIOS格式化硬盘； 4.拔插硬盘测试。 但问题始终未解决。 ③ 关键转折 当常规方向逐一排除后，尝试按F12打开开发者工具，查看接口返回详情。 一个HTTP 500错误暴露出来——不是前端页面问题，而是后端接口执行异常。 顺着这个线索，收集日志并上升给400技术支持团队分析后，最终确认根因：系统在扩容前会自动执行硬盘坏道扫描。由于利旧硬盘容量较大，扫描时间过长，导致后端接口处理超时，最终触发HTTP 500错误，前端无法正常获取硬盘列表。 ④ 解决方案 分批扩容 最终采用“分批扩容”方案： 第一批：仅插入一半硬盘。坏道扫描时间减少，成功完成扩容。 第二批：待第一批完成后，再插入剩余硬盘，再次触发扩容。 最终全部扩容成功。 ⑤ 经验总结 这个问题的关键启示在于： 1.HTTP500不是根因，硬盘坏道扫描超时才是。 不要只看页面报错，要深入API与后台日志层面。 2.利旧硬盘是最大的不确定因素。 建议提前检查SMART状态、提前做完整格式化，必要时提前做坏道检测。 3.分批扩容是有效的风险控制手段。 缩小故障影响范围，避免一次性扩容失败，同时提高问题定位效率。 六、实施结果与价值 1、资源变化情况 指标 扩容前 扩容后 变化 集群总内存3TB4TB+1TB 内存使用率76%52%↓24% 集群总存储174TB232TB+58TB 存储使用率55%44%↓11% 2、n-1冗余能力恢复 扩容前：任意单节点故障后，剩余两节点内存使用率将接近满载，存在业务风险。 扩容后：新增节点带来资源冗余，n-1冗余能力恢复，单一节点故障不再影响业务稳定性。 3、项目价值 ①成本价值：通过利旧服务器扩容，避免新增整机采购，大幅降低扩容预算。 ②冗余能力恢复：扩容后集群重新具备n-1冗余能力，降低单节点故障风险。 ③风险控制经验：“分批扩容”策略在利旧硬盘场景下具有较高可行性。 七、项目经验总结 本次项目验证了几个关键原则。 1、利旧扩容，“对齐”比“安装”更重要 需要重点对齐：软件版本、网络配置、RAID模式、BIOS模式。 利旧，不是将就，而是对齐。 2、第三方服务器最大的风险是不确定性 尤其需要重点关注：BIOS启动逻辑、利旧硬盘健康状态、驱动兼容性。建议加入集群前，提前完成硬盘初始化与健康检查。 3、通用报错，要往“下一层”看 页面提示往往只是结果。真正的问题在API、在日志、在后台服务。 HTTP 500不是根因，硬盘坏道才是。 4、分批扩容，本质是“分步控制风险” 不要追求“一次性完成所有操作”。分阶段实施：更容易定位问题、更容易控制风险、更适合生产环境。 分批扩容，本质是分步控制风险。 八、结语 1、本次项目最大的收获，并不仅仅是完成了一次扩容。 2、更重要的是：验证了第三方服务器平滑接入深信服HCI集群的可行路径。 3、实践证明：只要提前做好兼容性评估、网络对齐、风险预案、分步实施，利旧设备同样能够稳定融入生产环境。 4、而那些实施过程中踩过的坑——BIOS启动项问题、硬盘坏道扫描超时问题——最终都沉淀为了可复用的项目经验。 5、这正是项目交付最有价值的部分：不只是解决问题，更是经验积累。 小懒 2026-05-07 11k 9 #信服智创#【排障分享】SSL登录后业务访问异常 信服智创 | 参与得豆！2026技术征文大赛正式启幕！ SSL登录后业务访问异常 【问题现象】客户某国外用户登录当地SSL设备后访问中国大陆业务异常，ping 和 telnet 都没问题，就是 http 和 https 建联不起来。SSL设备部署在海外idc，有海外专线到中国大陆idc机房。 【排查过程】1.服务端查看用户登录获取的虚拟IP。2.后台复现抓包。tcpdump -i any host 业务域名 and host 虚拟IP -nnv -s0 -w /tmp/xxx.pcap 3.查看数据包我们sslvpn发包了，内网过了200+ms才回包，并且异常时服务端发出的client hello 包业务侧1s多才回复，导致客户端已触发重传，连接建立失败。 4.协调客户排查内网回包为啥这么慢，客户反馈海外专线到大陆平均200+延迟是正常范围，并且其他用户接入同一个SSL访问正常，协调正常用户抓包对比。 5.查看正常的用户也是200ms+回包，但是链接没断开，同一台设备相差很大，目前除了用户接入区域不一样，还有不同的就是分配的虚拟IP不一样。 6.控制台查看虚拟IP池，发现有配置三个虚拟IP段，正常的用户获取的236段，异常的用户为240段。 7.控制变量排查，让客户指定异常用户的虚拟IP为236段，并且修改默认虚拟IP池段为236，异常用户重新登陆访问正常了。【处理结论】客户内网环境问题，部分虚拟IP网段业务传输延迟大，具体原因需要排查网络侧。 贺智文 2026-04-30 6k 2 更多> --> --> --> --> --> --> --> --> #信服智创# 【排障经验】3389端口明明可达，RDP却报“内部错误”？一次跨多设备深度排障实录 信服智创 | 参与得豆！2026技术征文大赛正式启幕！3389端口明明可达，RDP却报“内部错误”？一次跨设备深度排障实录 目录： 一、项目背景：安全远程访问下的典型矛盾场景 二、故障现象：典型“网络正常但业务异常“ 三、排障过程：从“路径验证”到“行为分析”的转变 四、分层排查与转折 1、第一层：应用层验证（排除目标服务器问题） 2、第二层：VPN与基础网络验证 3、第三层：安全设备策略验证（AF） 4、第四层：跨设备对照验证 五、关键突破：多点抓包，发现“沉默的杀手” 六、技术定位：0x5826的真实含义 七、根因总结 八、解决方案 九、经验总结 1、“端口通 ≠ 业务通” 2、中间安全设备是“隐性杀手” 3、多点抓包是终极手段： 4、建立“特征指纹库” 十、结语：复杂网络排障的真谛 一、项目背景：安全远程访问下的典型矛盾场景在某企业网络环境中，整体拓扑如下：Internet → 深信服AF防火墙 → 深信服AC上网行为管理 → 核心交换机 → 内网服务器/终端 其中：1、AF防火墙启用SSL VPN功能2、用于为外部供应商提供安全远程接入能力3、AC对内网访问行为（包括终端和服务器）进行精细化管控 业务需求由于新增业务系统上线，客户需向第三方供应商开放一台内网服务器远程维护能力。 基于企业安全要求，明确限制：1、禁止直接暴露公网33892、禁止使用向日葵 / ToDesk等第三方远控工具 最终采用方案：1、供应商通过SSL VPN接入内网2、使用MSTSC（RDP）访问服务器3389该方案符合典型企业“安全接入 + 最小暴露面”设计原则。 二、故障现象：典型“网络正常但业务异常”系统上线后出现异常：供应商通过SSL VPN成功接入后，使用 MSTSC 连接服务器时报错：“出现了内部错误” 关键表象排查初期观察到：1、SSL VPN连接正常2、获取内网IP正常3、tcping/telnet 3389正常4、无明显丢包或超时 初步判断困境从传统排障视角：“端口通、链路通、策略看似正常，但RDP不可用”形成典型的“网络层正常，应用层失败”现象。 三、排障过程：从“路径验证”到“行为分析”的转变在连续验证均“正常”的情况下，问题一度陷入僵局：1、网络通2、会话在3、抓包有数据 一切看起来都没问题，但业务就是失败。 这往往意味着：问题不在“是否能到达”，而在“是否被允许完成通信”。 因此排障思路从：“连通性验证”转向“路径行为分析”。 四、分层排查与关键转折第一层：应用层验证（排除目标服务器问题）在内网直接测试：1、MSTSC访问服务器2、3389服务状态检查3、RDP服务监听确认 结果：1、内网RDP访问正常2、服务器服务状态正常 结论：服务器与应用层完全正常，问题应该不在目标端。 第二层：VPN与基础网络验证SSL VPN侧检查：1、隧道建立正常2、地址分配正常3、策略下发正常 TCP连通性测试：1、tcping/telnet 3389 → 正常 结论：基础TCP连通性无异常。 第三层：安全设备策略验证（AF）在AF侧进行验证：1、会话表存在RDP连接2、无明显丢弃记录 为彻底排除AF拦截可能，甚至将源目IP加入AF‘全局直通’策略（绕过所有安全检测），故障依旧。由此锁定：问题不在AF。 结论：AF未对该流量进行显式拦截。 第四层：跨设备对照验证为缩小范围，进行交叉测试：客户端替换1、不同PC → 失败 服务器替换1、其他服务器RDP → 正常 结论：问题与“特定访问路径”相关，而非通用网络问题。 五、关键突破：多点抓包，发现“沉默的杀手”既然路径上有AF和AC两台设备，我们决定在AF、AC、核心交换机多点同时抓包，进行精细分析： 关键发现（AC侧）观察到：1、TCP连接被中途终止2、出现 RST复位包 并在报文中发现一个异常特征：TCP/IP Identification 字段：0x5826 六、技术定位：0x5826 的真实含义查阅相关知识及结合过往排障经验，了解到该特征值与AC的策略阻断行为相关：AC行为特征机制在深信服AC上网行为管理中：1、当命中访问控制策略2、或未授权协议访问3、会触发主动阻断行为 表现为：1、返回TCP RST复位包2、快速终止连接3、并附带特定协议栈特征0x5826 本案例证据链闭环验证点 结果TCP连通性 正常VPN隧道 正常AF策略 未拦截会话状态 存在RDP应用 失败AC抓包 存在RSTID 0x5826 最终判断AC上网行为管理策略未放通 RDP（3389）协议，导致连接被策略性复位。 七、根因总结本次故障本质并非网络连通性问题，而是：中间安全设备（AC）基于应用控制策略对RDP流量进行了隐式阻断。 关键认知提升端口能通 ≠ 应用正常访问 在AC中：1、即使3389端口可达2、若 RDP 未被策略放通仍会被阻断 八、解决方案在AC上网行为管理策略中进行调整：放通策略调整1、放通 RDP（3389）协议访问 验证结果调整后：1、MSTSC连接恢复正常2、无内部错误3、RDP会话稳定建立 九、经验总结1、“端口通 ≠ 业务通”TCP层可达只代表网络路径存在，不代表应用层被允许。尤其在有多层安全设备的今天，这点至关重要。 2、中间安全设备是“隐性杀手”AF、AC等安全设备，会通过应用识别、RST复位等方式进行“非显性拦截”。排查时务必将其纳入视野。 3、多点抓包是终极手段当逻辑排查陷入僵局时，用数据事实说话。在不同的网络节点同时抓包，对比分析，是定位“沉默故障”最有效的方法。 4、建立“特征指纹库”0x5826这样的特征码，是快速定位问题的关键。将此类经验沉淀下来，能极大提升未来排障效率。 十、结语：复杂网络排障的真谛1、在企业级安全网络中，真正的问题：往往不在“是否能到达”，而在“是否被允许”；2、回顾本次排障，经历了从“信心满满”到“一头雾水”，再到“豁然开朗”的全过程。 3、它再次验证了一个原则：当“网络正常”但“业务异常”时，故障往往隐藏在安全策略与协议行为的复杂交互中。 4、穿透表象，用分层模型定位，用多点抓包取证，最终你会发现，那个“不可能”的问题，答案一直都在那里。 小懒 2026-04-25 19k 18 #信服智创#【项目案例】AF+AC分层改造：一次企业出口架构解耦实践与控制平面问题复盘 信服智创 | 参与得豆！2026技术征文大赛正式启幕！AF+AC分层改造：一次企业出口架构解耦实践与控制平面问题复盘 目录： 一、项目背景：一台“身兼数职”的老将 二、问题分析：单体重载架构的三大隐痛 1. 资源“内卷”，性能波动明显 2. 故障“放大”，任意异常皆影响全局 3. 单点“风险”，设备无冗余 三、方案设计：从“设备升级”到“架构重构” 1. 方案对比 四、简要实施过程：能力迁移与架构重构 1. 阶段一：出口能力从AC“剥离”至AF 2. 阶段二：AC改造为双网桥透明模式 五、关键问题复盘：一次“控制面漂移”的诡异问题 1. 现象 2. 第一反应 3. 转向怀疑网络 4. 关键转折点 六、根因分析：透明模式下的“路径依赖”真相 1. 核心机制 2. 路径推演 3. 本质问题 七、解决方案：构建控制流量确定性路径 1. 方案一：补齐网桥2管理IP 2. 方案二：带外管理网络（增强方案） 3. 方案三：通过LACP（链路聚合）主动控制流量路径 八、项目价值总结 1. 架构价值：能力解耦，职责清晰 2. 运维价值：故障域收敛，排障清晰 3. 技术发现：透明≠无状态 九、经验沉淀：从案例到可复用设计原则 1. 原则一：能力解耦优先于设备升级 2. 原则二：透明部署必须设计控制流路径 3. 原则三：架构改造必须具备可回退能力 十、结语 一、项目背景：一台“身兼数职”的老将 某中型企业网络长期采用传统单设备出口架构： Internet ↓ 深信服AC-1800（出口网关 + 上网行为管理） ↓ 核心交换机 ↓ 办公终端 该设备（2017年部署）长期承担四类核心职责： ①三层网关（PPPoE / 路由 / NAT） ②用户认证与准入控制 ③上网行为管控与审计 ④SSL解密 可以说，当时它是网络和安全的中枢。但随着时间推移，这套“一体化”架构的弊端开始显露。 二、问题分析：单体重载架构的三大隐痛 客户选择改造，并非设备损坏，而是这套架构在日常运行中，问题越来越频繁： 1. 资源“内卷”，性能波动明显 现象：SSL解密与上网管控，与路由、NAT争抢同一块CPU资源。 后果：业务高峰期，CPU时常飙升至85%-95%，甚至100%，导致网页打开延迟达到3-5秒，视频会议卡顿。 2. 故障“放大”，任意异常皆影响全局 由于AC是唯一出口，任何问题都会导致“全网不可用”： ①NAT异常 = 网络故障 ②策略异常 = 业务中断 ③性能瓶颈 = 全网抖动 故障域完全没有收敛。 3. 单点“风险”，设备无冗余 作为唯一出口节点，设备一旦异常（如电源故障、系统死锁、设备宕机），整个公司网络便陷入瘫痪，且无法快速切换。 客户核心目标：不是换一台新设备，而是重构架构，将网络转发能力与安全审计能力解耦。 三、方案设计：从“设备升级”到“架构重构” 1. 方案对比 方 案 描述 结论 方案A 新AC替换旧AC 仅更换新型号AC，架构不变；问题会延续，性能瓶颈可能再次出现 方案B AF + AC 分层架构（最终选择） AF负责网络出口，AC专注行为管理 能力解耦，职责清晰，故障域收敛 我们评估了两个方案： 最终目标架构： Internet → 深信服AF (路由/NAT/安全) → 深信服AC (审计/管控) → 核心交换机 → 办公终端 设计思想： 让AF做它擅长的“确定性转发”、“安全防护”，让AC回归它本该专注的“可视化管控与审计”。从“单体设备”到“能力栈分层”。 四、简要实施过程：能力迁移与架构重构 为了保证业务不中断，我们采用了分阶段、可回退的迁移策略。 1. 阶段一：出口能力从AC“剥离”至AF 将AC上的网络层配置，完整迁移到新部署的AF上（相当于给网络出口换了个“大脑”）： ①网络配置：PPPoE/专线接口、默认/静态路由。 ②NAT策略：同步并清理了多年积累的数十条冗余规则。 ③基础安全：配置了必要的访问控制策略。 ④关键原则：此阶段只做“平移”，保证业务连续性第一。 风险控制措施： 保留原AC出口路径不下线：在AF接管前，原有链路保持可用，确保可快速切回。 2. 阶段二：AC改造为双网桥透明模式 将原来的出口AC“降级”为透明网桥，串联在AF和核心交换机之间（让它专心做“观察员”）： ①网桥1：ETH0 ↔ ETH2 ②网桥2：ETH1 ↔ ETH3 关键注意点： 务必使用硬件Bypass网口对，避免设备断电导致网络中断。 完成网络层迁移后，再将上网认证、流量管控、SSL解密等策略从旧AC迁移至新AC上。 五、关键问题复盘：一次“控制面漂移”的诡异问题 在双网桥透明部署后，出现了一个极为“诡异”的现象： 1. 现象 同一VLAN、相同配置的不同办公终端，一部分可以正常访问AC的管理界面，另一部分则完全不通，Ping管理IP也是时通时断。 2. 第一反应 “配置出错了？”反复检查了AC的网桥配置、管理IP等，确认无误。 3. 转向怀疑网络 “难道交换机有隐藏ACL？”我又花了一整个下午排查核心/接入交换机的配置，VLAN、ACL、STP一切正常。问题依旧。 4. 关键转折点 当我将所有出问题的终端对比分析后，发现了一个规律： ①交换机A的终端 → 可正常访问AC管理界面。 ②交换机B的终端 → 无法访问AC管理界面。 此时才意识到，问题从“配置错误”转向了 “流量路径差异” 。 同样是去往AC管理IP的流量，因为来源不同，走的路径不一样，结果也不同。 六、根因分析：透明模式下的“路径依赖”真相 进一步回溯AC的双网桥设计，发现了根源： 1. 核心机制 在透明网桥模式下，管理IP并非“漂浮”在所有网桥上，而是属于某个特定网桥的控制平面对象。 在本案例中，管理IP仅配置在了网桥1上。网桥2没有配置管理IP。 2. 路径推演 ①成功的路径： 终端流量从交换机A出发 → 进入AC的网桥1 → AC控制平面识别并响应 → 正常通信 ②失败的路径： 终端流量从交换机B出发 → 通过链路进入AC的网桥2 → 网桥2作为“纯数据平面”无法关联到网桥1的控制平面 → 包被丢弃或无法响应 → 管理IP不可达 3. 本质问题 在双网桥透明模式下，控制平面存在“路径依赖”。 当多链路接入环境导致流量随机进入不同网桥时，就发生了 “控制面漂移”——请求来了，但控制面不在这里。 七、解决方案：构建控制流量确定性路径 1. 方案一：补齐网桥2管理 IP ①网桥1：管理IP A ②网桥2：管理IP B ③实现双控制面冗余 此方案不推荐：涉及到各网桥不能同网段、vlan通信、vlanif接口sub IP，实现较复杂。 2. 方案二：带外管理网络（增强方案） 实施方式： ①独立管理口 ②管理流量与业务流量隔离 实现效果： 控制台访问恢复稳定 ①不再依赖接入位置 ②控制平面路径确定性建立 3. 方案三：通过LACP（链路聚合）主动控制流量路径 实施方式： ①在AF与核心交换机之间配置LACP聚合。 ②将AC的两个网桥串联在聚合链路中间。 ③关键一步：通过调整交换机侧LACP的接口优先级，强制指定承载管理IP的网桥1所连接的链路为主用链路。 实现效果： ①管理流量固定：所有去往管理IP的控制流量，100%进入网桥1。 ②数据流量冗余：网桥2所在的链路作为数据转发备用。 ③价值：从“被动适配随机路径”转变为 “主动控制确定路径”。 八、项目价值总结 最终，所有问题圆满解决，架构平稳落地。 1. 架构价值：能力解耦，职责清晰 从“单体出口”升级为“AF(网络边界) + AC(行为审计)”分层架构，网络与安全能力彻底分离。 2. 运维价值：故障域收敛，排障清晰 AF出问题，排查网络层；AC出问题，排查策略层。互不干扰，排障路径一目了然。 3. 技术发现：透明≠无状态 透明网桥模式下，控制平面仍有“归属感”，多链路部署必须设计控制流确定性，避免“路径漂移”。 九、经验沉淀：从案例到可复用设计原则 如果说本次项目解决的是一个具体问题，那么更重要的是对以下通用设计原则的验证： 1. 原则一：能力解耦优先于设备升级 在出口设备长期承载多种职能时，应优先通过架构拆分实现能力解耦，而非简单替换设备。 价值： ①避免资源竞争 ②降低故障放大效应 ③提升系统扩展性 2. 原则二：透明部署必须设计控制流路径 透明网桥对数据流透明，但控制平面具有归属。 多链路场景必须确保： ①控制流具备确定路径 ②避免路径随机 推荐手段： ①单独带外管理（优先） ②链路聚合引导（进阶） 3. 原则三：架构改造必须具备可回退能力 所有网络改造必须设计回退路径： ①保留旧链路 ②新旧路径并行 ③支持快速切换 本项目通过“新IP + 保留原出口路径”，实现秒级回退，大幅降低实施风险。 十、结语 这次改造的最大收获，不只是完成了一次设备替换，而是深入理解了透明网桥下控制平面的行为逻辑。 一个好的架构，不是设备的堆叠，而是让每一类能力各司其职，并为所有流量（包括控制流）设计一条确定的、可预期的路径。 小懒 2026-04-25 7k 3 EOS设备换新升级筑牢企业安全底座 七嘴八舌bar 活动截止时间：2026-06-30 告别老旧隐患、升级防护能力、保障业务稳定 有一说一|解锁Agent真实价值，是摸鱼神器还是鸡肋？ 七嘴八舌bar 活动截止时间：2026-06-10 1. 用AI帮你干过什么事，让你实打实少熬了一小时甚至一下午的班？ 2. AI哪次把你坑得想摔手机——你觉得好用的职场AI到底该替你扛什么、绝不该碰什么？ 更多> #信服智创#信创ARM架构麒麟PC端虚拟化交付云镜最佳实践 信服智创 | 参与得豆！2026技术征文大赛正式启幕！ 信创ARM架构麒麟PC端虚拟化交付云镜最佳实践本项目中客户采购一台云镜主要做为移动端便携式漏扫工具，方便测评人员带着电脑即可随时随地接入客户网络中进行漏扫。由于云镜软件交付仅支持虚拟化环境整套系统部署交付，无法直接通过软件的形式安装到终端环境中，且本项目为纯信创环境，终端PC和云镜均为ARM架构国产化麒麟系统才可通过信创改造验收，估本项目中采购一台信创个人终端PC做为宿主机承载，云镜以虚拟机的方式部署到宿主机中。 下载链接：https://support.sangfor.com.cn/productSoftware/list?product_id=80&category_id=96（下载qcow2格式的即可）PC环境：Kylin Linux Desktop V10 (SP1)、Linux langchao-PC 5.4.18-91-generic #80oemlccp320fh11u SMP Thu Jan 25 07:30:45 CET 2024 aarch64 aarch64 aarch64 GNU/Linux 1.安装QEMU和KVM套件安装命令：sudo apt install qemu-system virt-manager libvirt-daemon-system 2.赋予当前用户管理虚拟机的权限 操作命令：sudo usermod -aG libvirt $USERnewgrp libvirt # 刷新用户组 3.开始创建虚拟机 (1) 在开始菜单中搜索并打开 “虚拟系统管理器” (Virtual Machine Manager)：(2) 点击左上角的“新建新虚拟机”图标→导入现有磁盘映像：(3) 在新建虚拟机窗口中选择现有qcow2的镜像即可： 4.虚拟机初始化创建好虚拟机后，点击打开等一段时间见到如下界面即为已经完成初始化。 5.网口配置 虚拟机配置2个网口，一个网口用来和宿主机通信，作为管理口，另外一个口通过物理口透传出去作为业务口进行业务扫描。网口1：桥接pvbr_enp4s0：空桥接；（pvbr_enp4s0为本机的虚拟网口，主要用于和云镜的eth0口的默认地址进行通信）修改本机的pvbr_enp4s0的IP地址和默认地址10.251.251.250同网段即可。网口2：主机设备enps40:macvtap，源模式：传递 6.登录控制台使用即可。 Sangfor43876 2026-04-22 5k 0 #信服智创#【排障经验】防火墙会话数每5分钟飙升4万+：一次AC"全网扫描"引发的伪攻击事件 信服智创 | 参与得豆！2026技术征文大赛正式启幕！防火墙会话数每5分钟飙升4万+：一次AC“全网扫描”引发的伪攻击事件摘要： 一次例行巡检，发现AF会话数每5分钟飙升至4W+，特征极像内网扫描攻击。然而，最终定位的源头，竟是“自己人”。本文完整复盘了从误判到根因的排查过程，并总结了此类问题的通用排查思路。 目录： 一、异常现象：一次“脉冲式”的会话风暴 二、网络拓扑 三、陷入误区：所有证据都“指向攻击” 四、关键转折：从AF会话中，锁定了“意料之外”的源IP 五、现场验证：在AC上发现了“致命”配置 六、根因分析：一次“能力失控”的放大效应 七、问题本质：不是攻击，而是配置与能力的错配 八、解决方案与优化建议 九、效果验证 十、经验总结 一、异常现象：一次“脉冲式”的会话风暴 在某政企项目例行巡检中，发现AF防火墙的会话监控出现极端异常： 1、周期性触发：大约每5分钟一次 2、瞬时飙升：会话数从正常基线急剧攀升至4W+ 3、脉冲式回落：峰值仅持续数秒，随后迅速恢复正常 更关键的是流量特征：目的IP高度离散，覆盖全网段，无任何单一目标。 初步判断：在安全经验中，“周期性 + 瞬时高并发 + 全网分散IP”几乎可以直接等同于——内网横向扫描、蠕虫行为或自动化探测攻击。排查自然朝着“定位内网失陷主机”的方向开始。 二、网络拓扑 Internet ↓ 深信服AF防火墙 ↓ 深信服AC行为管理 ↓ 核心交换机 ↓ 内网终端 三、陷入误区：所有证据都“指向攻击” 首先验证了两个最可能的攻击模型： 1、内网主机失陷：是否存在中毒终端、扫描脚本或异常进程？ 2、外部攻击回流：外部扫描器周期性探测？或策略误触发导致流量反射？ 最大的迷惑点：“周期性 + 瞬时高并发 + 目的IP分散”这三个特征，在安全领域几乎天然等价于“扫描攻击模型”。这让我在初期浪费了不少时间。 四、关键转折：从AF会话中，锁定了“意料之外”的源IP 为了验证攻击假设，对AF峰值时段的会话日志进行了源IP聚合分析。 结果令人意外： 1、Top异常会话源IP高度集中 2、唯一持续触发异常行为的IP是：172.16.X.X 3、通过ARP及MAC地址追溯，最终确认该IP对应的设备为——深信服AC行为管理。 结论反转：问题不是来自外部攻击或内网病毒，而是内部设备自身的行为异常。 五、现场验证：在AC上发现了“致命”配置 登录AC，直奔终端识别与资产扫描模块。 在“终端发现配置”中，找到了直接原因： 扫描范围被错误配置为：0.0.0.0 - 255.255.255.255 这意味着：AC在执行资产发现时，没有限制在任何边界内，而是对所有IPv4地址发起了主动探测。 六、根因分析：一次“能力失控”的放大效应 1、AC扫描机制原理 AC通过主动探测实现资产识别，核心技术包括TCP/IP指纹识别（类似nmap）、SMB协议探测、SNMP信息采集及ONVIF设备识别等，本质上是一个多协议并发主动探测模型。 2、会话数爆炸的形成机制 AF防火墙基于“五元组”建立会话，当叠加以下两个因素时，问题爆发： 因素一：扫描范围失控：0.0.0.0 - 255.255.255.255等于对全网发起无边界探测。 因素二：多协议并发探测：针对每个IP，AC会同时发起SMB、SNMP、ICMP等多种协议的连接尝试。 最终结果：在极短时间内，AC轮询成千上万个IP，每个IP触发多条会话，导致AF的会话表瞬间膨胀，表现为数万级的“伪攻击”峰值。 3、周期性来源 进一步检查发现，该扫描是AC上配置的定时资产发现任务。这完美解释了为什么在AF侧观察到每5分钟一次、短暂而规律的脉冲。 七、问题本质：不是攻击，而是配置与能力的错配 本事件并非安全攻击，而是： 一个正常的扫描能力，在错误配置下，与防火墙会话机制叠加后，引发的资源放大效应。 1、功能层：AC终端扫描（正常能力） 2、配置层：扫描范围严重错误（核心根因） 3、网络层：AF会话机制如实记录，形成“会话洪峰” 八、解决方案与优化建议 1、根因修复 将AC的终端扫描范围调整为实际业务网段，例如192.168.0.0/16。 核心原则：扫描范围必须严格匹配你的网络边界。 2、长期优化建议 控制扫描范围：避免使用“0.0.0.0”或远大于实际规模的网段。 按需启用扫描策略：在终端规模较小或对实时性要求不高的环境，建议关闭自动扫描，仅在需要资产盘点时手动触发，完成后关闭。 九、效果验证 完成配置修改后，持续观察AF监控视图： 1、会话数恢复正常水平，不再出现数万级突发峰值 2、周期性波动完全消失 3、问题得到彻底解决，业务访问无任何影响 十、经验总结 1、“像攻击”的不一定是攻击： 周期性+高并发+全网分布是典型的迷惑特征，但根源可能是内部自动化组件。 2、安全设备可能“放大”彼此影响： 本案例中，AC的扫描行为被AF以会话形式完整记录，两者叠加形成了意外的“会话洪峰”。 3、功能本身无问题，边界决定安全性： 终端扫描是有效能力，但必须满足“范围合理、策略可控、与网络规模匹配”的前提。 4、排障必须尽快锁定流量源头： 如果只盯着防火墙侧分析，容易陷入流量表象。真正的突破点在于——快速锁定源IP，并回溯到发起行为的真实设备。 5、这类问题在实际项目中具有较强的“迷惑性”： 表象类似攻击、行为却来源于内部设备、根因隐藏在配置细节中。 6、对工程师而言，真正的能力差异不在于“是否识别告警”，而在于： 是否能穿透流量表象，回到设备行为本身。 小懒 2026-04-23 6k 1 #信服智创#atrust沙箱应用使用问题案例 信服智创 | 参与得豆！2026技术征文大赛正式启幕！ atrust沙箱应用使用问题案例 案例一：【问题描述】用户在沙箱内打开一个web应用系统向系统中上传本地文件，但是上传文件列表显示的是本地磁盘目录而不是沙箱内目录，无法正常上传沙箱内文件，并且可以直接绕过沙箱上传本地文件也存在安全隐患。【处理过程】首先三板斧，重装重启重买（不是），首先指导用户重装一下最新版本客户端，但是问题依旧。感觉不是一般问题协调400处理，在终端收集了客户端日志判断是个兼容性问题，随后摇了研发远程排查。研发使用的是procmon分析了相关进程，初步结论是这个平台本地应该有一个服务，浏览器上传文件时会和这个本地服务通信获取盘符路径，本地服务无法拉取到沙箱内的路径导致了问题。具体进程如下：下一步给出了解决方案：1、 配置个人空间进程黑名单，将进程enseuse.exe加进去；2、 将enseuse.exe进程配置到工作空间进程自适应。 具体配置如下：在程序仓库添加对应进程在【个人空间管理】-【程序运行管理】，新增程序黑名单：后续重新进行测试就恢复正常了。【原因总结】 1. 沙箱内浏览器打开的业务平台点击上传文件时获取的文件夹目录结构是和个人空间enseuse.exe通信获取的； 2. enseuse.exe是通过服务进程easeclientservice.exe拉起的，这个进程启动在个人空间，因此其获取到的文件夹结构是个人空间的目录结构。 案例二：【问题描述】依旧是在沙箱内的一个web应用系统，使用远程维护功能时会有报错。【处理过程】 这里实际是同一个用户的问题，当时感觉很相似，但是能力有限不会用工具分析进程，尝试直接问客户远程维护功能是否需要调用本地插件。客户给出了具体的进程名称和通信流程。 于是使用同样的步骤处理对应进程，问题解决。 案例总结： 上面两个案例实际都是沙箱内系统本应该和沙箱内进程进行通信才能使用正常，未经过处理的进程默认只在本地电脑运行，导致功能报错；判断到是这类原因后可以尝试将对应进程（使用工具识别或咨询业务系统工程师）加入到个人空间进程黑名单，同时将进程配置到工作空间进程自适应，这样进程会在沙箱内被拉起，确保应用使用正常。 新手703537 2026-04-22 5k 1 #信服智创#【项目案例】从"光纤一断全网瘫痪"到"双链路无感切换"：某制造企业安恒防火墙替换全流程复盘 信服智创 | 参与得豆！2026技术征文大赛正式启幕！ 从"光纤一断全网瘫痪"到"双链路无感切换"某制造企业安恒防火墙替换全流程复盘 目录： 一、项目背景 二、问题分析 三、方案设计 四、架构设计 五、简要实施过程 六、优化效果 七、典型问题复盘 1.端口映射正常，但业务异常（范围端口映射） 2.访客网络无法访问SSL VPN（非对称路由） 八、项目总结 一、项目背景 客户为某制造企业，现网出口采用双区域架构： 电信专线：承载办公及核心业务访问（主业务链路） 移动专线：承载物联网及访客网络（物理隔离） 基础拓扑如下： 电信专线 → 业务防火墙 → 核心交换机 → 办公/生产终端 移动宽带 → 路由器 → 交换机 → 访客/物联网终端 二、问题分析 随着业务发展与外部环境变化，逐步暴露出以下问题： 1.链路稳定性问题逐渐放大 公司周边施工频繁，电信光纤多次被挖断。现网应对方式为人工切换：将移动宽带接入业务防火墙临时顶替。 实际运行中存在明显问题： ①切换依赖人工，恢复时间不可控（通常10–15分钟） ②业务中断不可避免，影响生产及办公连续性 ③运维压力大，存在误操作风险 本质问题： 缺乏链路层面的自动化调度与健康检测机制，无法实现链路故障的快速感知与自动切换 2.设备能力与安全能力不足 ①原出口设备为安恒明御安全网关（2020年部署） ②上网行为管理能力较弱，难以进行细粒度策略控制 ③安全规则库长期未更新，防护能力持续下降 ④硬件性能老化，维保已过期，存在运行风险 本质问题： 设备仍在运行，但安全能力已“失效” 3. ssl vpn接入能力受限 ①终端支持不完整：仅支持Windows、Android，无法覆盖iOS等移动办公场景，限制管理层及部分业务人员使用 ②接入体验不稳定：在公网链路波动或切换时，VPN连接易中断，缺乏链路级保障机制 本质问题： SSL VPN作为远程接入能力，处于“附属功能”状态，缺乏稳定性保障 三、方案设计 本项目的核心，不是简单替换设备，而是在成本、风险、能力之间做取舍。实际落地前，我们评估了三种路径： 方案A：原厂升级 优点：改造成本低 问题：行为管理能力与链路调度能力仍不足、扩展性差 结论：适合短期缓解，不具备长期价值 方案B：双防火墙HA架构 优点：设备层高可用 问题：无法解决链路中断问题、成本提升明显 结论：解决“设备单点”，但未解决“链路单点” 方案C：单AF + 多链路调度（最终选择） 核心思路：用“链路智能”替代“设备冗余” 采用一台深信服AF作为出口核心设备，重点利用其能力： ①链路健康探测（ICMP / DNS / 自定义目标） ②基于策略的选路与自动切换 ③内置上网行为管理 ④SSL VPN多终端支持（Windows / Android / iOS） 四、架构设计 1.出口结构： 电信专线（主链路） 联通专线（备链路 + 分流） 移动宽带（应急兜底） 2.流量调度策略 核心思想：不同业务，不同路径策略 ① 服务器流量（稳定优先） 优先走电信 电信异常/探测失败 → 自动切换联通 探测目标优先选择公网稳定地址 + DNS地址组合，避免单一探测误判，连续3次失败触发切换 ② 用户上网流量（利用率优先） 电信 + 联通负载均衡 实际调整过程中，对部分业务（如视频、下载）做了链路倾斜，避免挤占主链路资源 ③ 极端场景兜底机制 双专线异常 → 手动接入移动宽带 该方案虽为手动，但作为三层兜底已足够 五、简要实施过程 1.割接前准备：配置梳理 原防火墙： ①NAT规则：50+条 ②存在问题：冗余策略、端口混乱、命中率不可见 ③ 处理策略不是“迁移”，而是：梳理 → 分类 → 重构关键动作： ①删除无效策略 ②合并重复规则 ③ 标记关键业务流量 2.新设备配置 在AF上采用“重建式配置”： ①接口与网络重新规划 ②NAT规则结构化设计（按业务分类） ③ 安全策略分层（业务控制策略 / 上网管控策略） 这一点非常关键： 很多问题不是“迁移失败”，而是“把旧问题带到了新设备”。 3.割接切换 ①选择夜间低峰期进行：原设备保留、不关机（作为回退） ②分阶段验证：内网连通性、外网访问、VPN接入 4.实施结果 ①大部分业务仅在切换过程中短暂中断（个别端口映射例外） ②切换过程可控 六、优化效果 1.可用性提升 ①链路切换：人工 → 自动 ②故障恢复时间：10–15分钟 → 5–10秒 2. 带宽利用率提升 ①原：单链路高峰约80% ②现：双链路均衡约40%~70% 3. 运维复杂度降低 ①不再依赖人工切换链路 ②策略结构清晰，维护成本明显下降 4. 公网访问体验优化 采用“双出口 + 智能DNS（阿里云）”： ①电信用户 → 电信链路接入 ②联通用户 → 联通链路接入 有效降低跨网访问延迟。 七、典型问题复盘 1. 端口映射正常，但业务异常 现象：端口可访问、部分业务连接异常 排查过程： ①排查安全策略 → 正常 ②排查链路 → 正常 ③ 抓包分析 → 发现端口不固定 根因分析： NAT规则中配置了“端口转换为端口范围”，导致端口随机映射，破坏一对一关系。 解决方案： ①删除端口范围配置 ②使用默认一对一映射 经验总结： 涉及端口范围映射时，如无明确需求，应避免使用端口随机转换。 2. 访客网络无法访问SSL VPN接入地址（非对称路由） 现象： 使用访客网络（移动宽带）访问SSL VPN地址 表现为： IP不通，VPN无法建立连接 排查过程： ①本地网络正常，可访问公网 ②检查AF策略与端口监听 → 正常 ③排查公网访问路径 → 无异常 ④抓包发现请求能到达，但无响应 根因分析： ①多出口环境下出现回程路径不一致（非对称路由）： ②请求从电信/联通进入 ③回包从移动链路发出 ④源地址不匹配，客户端丢弃 触发原因： AF配置中引入了移动链路作为应急备用出口 解决方案： 通过策略路由+调整路由优先级，固定回包路径 经验总结： ①在多链路环境中，“能出去”不等于“能回来” ②任何公网服务（如VPN/端口映射）都必须保证回程路径一致，否则必然出现连接异常。 八、项目总结 本次改造的核心价值在于完成了三个转变： ①从“单链路依赖” → “多链路调度” ②从“人工应急” → “自动容灾” ③从“策略堆叠” → “结构化管理” 在制造业场景中，出口防火墙不仅是安全设备，更是业务连续性的关键控制点。 本项目的关键不在于设备替换本身，而在于对现网的理解深度 + 割接过程控制能力。 该项目验证了一点：在出口改造中，“链路冗余设计”优先级应高于“设备冗余设计”，否则即使设备高可用，业务仍可能中断。 小懒 2026-04-22 5k 0 #信服智创#SAAS XDR proxy双网卡部署 信服智创 | 参与得豆！2026技术征文大赛正式启幕！ SAAS XDR proxy双网卡部署 【背景】深信服XDR（安全检测与响应平台，含SaaS XDR、分布式XDR、硬件XDR等形态）是深信服推出的融合多源数据、支持云端协同的安全检测与响应平台，核心定位与特点如下：核心定位：深信服XDR通过原生的流量采集工具与端点采集工具将关键数据聚合在XDR平台，通过云端专家服务提供威胁分析研判及狩猎能力，支持SaaS化交付方式，为用户带来深度检测、精准响应、持续生长的安全价值。主要产品特点：多源数据联动，加速安全闭环、高性能数据处理能力、云端协同，全面可视化。 总之XDR是个好东西，但是太贵了，所以客户选择了高性价比的SAAS XDR。那SAAS XDR在云端，想要接收第三方的日志和联动第三方设备都需要在本地部署一个代理，但是社区的镜像有个小问题，那就是只有一张网卡，而有的客户有两张物理隔离的网络，内网和外网，所以代理就需要多整一个网卡了。 【解决过程】以在HCI部署举例（HCI两个业务口，分别连通内网和外网，这里不过多描述了）：一、正常部署参照社区文档，挺简单的，新增虚拟机，使用对应镜像，开机就自动部署的，此处省略该步骤；二、部署完成后配置IP，修改管理口地址，蓝色光标移动到页面中Configure static IPv4 address，回车后配置该虚拟机的eth0（第一张网卡）的IP地址以及DNS地址 ，保存即可（我这里eth0是属于外网的）；三、在HCI给代理新增一张网卡，登录深信服HCI，在【虚拟机】页面找到需要操作的虚拟机，点击“更多”→“编辑”，进入“硬件”选项卡，选择“添加硬件”，然后选择“网卡”，即可添加一张或多张新的网卡再连到对应端口组； 四、配置新网卡1、SSH进入系统后台，cd /etc/sysconfig/network-scripts，cd到网卡配置文件目录，ls看是只有eth0的配置文件的；2、cp ifcfg-eth0 ifcfg-eth1，生成一个eth1的配置文件；3、sudo su提权；4、vi etc/sysconfig/network-scripts/ifcfg-eth1，根据具体情况修改IP等信息，保存。这里要注意两个点：（1）因为ifcfg-eth1是ifcfg-eth0 cp出来的，HCI虚拟网卡有个UUID，一定要把eth1的UUID删掉不填，不然用不了（这个排查了好久才发现的）；（2）eth1内网口不写网关，然后写明细路由，不然有两条默认路由，会有问题。5、ifdown eth1，再ifup eth1,重启eth1网络服务（platos没有systemctl restart network）；6、ifconfig就可以看到两张网卡IP都生效了；7、配置路由。配置eth1的明细路由，vi /etc/sysconfig/network-scripts/route-eth1。然后写入 x.x.x.x/x via 网关 dev eth1，保存。然后ifup eth1重启eth1网络服务，再route -n看路由生效了没有。 五、配置接口自动连接（这个不知道要不要配，因为配置文件自动连接已经是yes，400说最好配上，我就配上了）nmtui 输这个命令切到接口配置图形化页面，选择eth1，勾选自动连接：好了，现在这个代理就可以同时连接内外网的设备了！！！ 广龙ㅤ 2026-04-16 7k 2 #信服智创#其他技术 超融合Ubuntu 系统安装 信服智创 | 参与得豆！2026技术征文大赛正式启幕！ 其他技术超融合Ubuntu系统安装 Ubuntu 服务器系统主要通过命令行或web管理界面进行配置和管理。设计优点安全可靠、稳定。承若每6个月发布一个新的版本。针对服务器系统部署，推荐大家使用长期支持的LTS版本。是一个值得企业和个人信赖的开源服务器系统。本次安装教程适合初学者。 一、Ubuntu 22.04.5 LTS下载地址 Ubuntu 22.04.5 LTS服务器系统下载的官方系统地址：https://releases.ubuntu.com/jammy/ 二、超融合Ubuntu 虚拟机的建立 1.点击虚拟机-新增-全新虚拟机。 2.点击名称Ubuntu 22.04.5，操作系统选择Ubuntu。 3.硬件选项里CPU选择8核，内存选择16GB,硬盘选择1TB，光驱加载ISO镜像ubuntu-22.04.5-live-server-amd64.iso，eht0网卡选择物理出口1-确定。 4.虚拟机建立完成。 三、超融合Ubuntu 虚拟机系统的安装 1.点击Ubuntu虚拟机-点击控制台。 2.点击启动，选择ubuntu 系统镜像，点击立即安装。 3.选择*Try or Install Ubuntu Server，回车。 4.选择English，回车。 5.选择默认设置，点击Done。 6.选择默认选项Ubuntu Server,点击Done。 7.选择网卡ens18，回车。 8.选择Edit IPv4，回车。 9.IPv4 Method 选择Manual。 10.设置网段、地址、网关、DNS，选择save。 11.选择Done。 12.选择代理设置默认，Done。 13.软件仓库源地址配置。设置新的Mirror address ：https://mirrors.aliyun.com/ubuntu/ 14.选择Continue without updating。 15.硬盘分区选项默认，点击Done。 16.分区默认，点击Done。 17.点击continue，继续。 18.设置系统名称及用户和密码。 19.选择默认，Continue。 20.安装ssh服务。选择安装Install OpenSSH server,选择Done，回车。 21.选择默认，Done。回车。 22.开始安装系统软件。 23.系统软件安装完成后，重启系统。 24.设置root帐户。 25.安装优化工具，输入yes，重启系统，ubuntu系统安装完成。 韩立春 2026-04-07 10k 7 更多> 精华博文 覆盖全产品线，汇聚2000+精华、优秀文章，助您更好了解和使用深信服产品！ 每周精选 汇总每周最新、最热、版主推荐内容，掌握产品资源动态，热点知识一触即达！ 技术圆桌 汇总社区最新、热门话题，点击参与讨论 问答集锦 整合社区用户常问问题，查看最新解决方案 #信服智创#【排障经验】AES分支部署时验证不通过故障排查全解 信服智创 | 参与得豆！2026征文大赛正式启幕！【排障经验】AES分支部署时验证不通过故障排查全解一、问题描述 在部署EDR（aES）分支节点并尝试将其与上级中心平台进行级联时，系统提示“验证不通过”或“连接失败”，导致分支节点无法成功注册到中心平台。 二、告警信息 管理界面提示：验证不通过、连接失败。 三、处理过程 遵循从外到内、从易到难的顺序进行系统性排查。 1、网络连通性与策略验证 检查端口通信：在上级平台服务器上，使用 telnet 命令，确认访问下级分支的HTTPS端口（默认443）是否通畅。 2、排查中间设备：若出现403错误或连接被拒，需检查防火墙、WAF等中间设备是否拦截了上下级平台间的业务流量。 3、确认基础网络：检查DNS解析是否正确，跨网段部署时确认路由可达。 4、检查SSH服务：确认上下级服务器的SSH服务均已开启，因为部分级联操作依赖SSH通道。 5、授权与配置检查 检查授权许可：登录上级中心平台，确认“分支节点授权”数量充足，未耗尽。 核对配置信息：仔细检查下级分支填写的上级平台IP/域名、端口是否完全正确。 校验接入密钥：确认复制的接入密钥（Token）准确无误，特别注意不能包含多余的空格或换行符。 硬件配置校验 检查硬件资源：针对aES 6.0.2R4及以上版本，需校验分支平台的硬件配置。 关键指标： CPU核数、内存大小需满足分支规模要求。 CPU主频需 ≥1800MHz（可通过 cat /proc/cpuinfo | grep -i mhz 命令查看）。 磁盘读写性能及 /sf 分区空间需达标。 6、日志定位根因 若以上步骤均未解决问题，需登录上级平台后台，实时查看级联日志（/ac/var/log/linkage_sdk/log/）。 在前台触发验证操作，通过 tail -f 命令观察日志输出，根据具体的错误码或异常信息进行精准定位。 四、根本原因 经过上述排查，最终定位到根本原因在于网络策略配置不完整。 底层服务未开启：下级分支平台的SSH服务未启动，导致级联验证的底层通道无法建立。 防火墙策略限制：虽然基础网络（如Ping）可达，但在AF（防火墙）的VPN或安全策略中，并未明确放通EDR平台网段之间的业务流量，导致验证握手包被拦截。 五、解决方案 1、开启SSH服务：登录分支平台后台，启动SSH服务并确保其开机自启。 2、调整防火墙策略：在AF防火墙上，在VPN配置中，本地网段加上总部AES所在内网允许分支访问，确保业务端口通信不受限。 3、重新验证：完成以上两步操作后，返回管理界面重新发起级联验证，问题得以解决。 jan 2026-04-02 8k 3 深信服超融合，2025年「双料第一」 国际数据公司（IDC）发布《中国软件定义存储（SDS）及超融合系统（HCI）市场季度跟踪报告，2025Q4》，深信服超融合拿下2025年两项「第一」 ● 中国超融合整体市场「第一」，第四季度市占率21.2%，全年市占率17.8%；（超融合整体市场份额=超融合硬件（超融合一体机）份额+超融合软件集成系统份额）。 ● 中国全栈超融合市场「第一」，全年市占率 34.4%。 回望来时路，深信服已经连续多个季度荣获IDC超融合赛道「双料第一」。这份荣誉是认可，更是前行的动力。 我们始终坚守初心：持续深耕用户需求，聚焦价值创造；与千行百业的用户，并肩共赴数智化转型。 可转型之路，从来都不轻松，三重变局叠加——「VMware替代」加速，「信创」规模化落地，硬仗在前，偏偏又遇全球供应链波动、硬件涨价，让本就不易的转型之路，再添一道难关！ 我们懂这份负重前行的不易，也始终坚信：技术的价值，不该被涨价困住手脚！我们创新内存分层技术，以软件定义之力，破解硬件成本之困，让 VMware 替代、信创规模化走得更从容、更坚定！ 环境在变，挑战在变。深信服的初心，从未改变——用软件定义的确定性，陪你走稳每一步，跨越不确定的周期！ 七嘴八舌bar 2026-04-16 7k 3 #信服智创#AC对接华为NCE、AD域单点登录 信服智创 | 参与得豆！2026征文大赛正式启幕！ 一、背景描述1、客户现有网络有有线无线，均为DHCP获取地址，有线一个网段，无线一个网段；2、使用华为NCE做portal认证；3、新增AC做审计和应用管控（120版本）。拓扑图：【客户需求】1、单位安全事故频发，但网络环境为DHCP,IP经常变，无法快速定位到责任人，需要在AC上进行行为审计，并希望在AC上能定位到终端用户，方便后续溯源；2、对普通员工进行应用管控，领导则不用；3、希望不需要重复认证，只在华为NCE认证即可，以方便统一管理。 【思路】需求1和3解决办法：那AC只能对接华为NCE做单点登录，以获取NCE的用户认证信息，这样就可以快速溯源定位到责任人，终端用户也只需填写一次认证。需求2：难点1、网络为DHCP,领导和普通员工混在一个网段，客户也不想在DHCP那里绑定领导的IP和MAC来固定分配地址，觉得太麻烦，那就无法通过IP做应用管控。难点2、IP不行，那就考虑通过用户来，但是AC不支持将从华为准入系统上来的用户名或组织架构显示在AC本地。这意味着虽然用户能以华为NCE上的用户名在AC上线，但其组织架构信息无法同步到AC的设备本地，因此也无法在AC上直接对这些用户或用户组关联和配置上网权限策略、流控策略等进行精细化管理。GG了，这个不行那个不行的，但天无绝人之路，了解到华为NCE认证是从AD域控同步。用户的组织架构及账号密码信息的，也就是说AC只要对接AD域，就能拿到和NCE一样的。组织架构了，就可以基于用户来做管控。开干！！！ 二、配置1、AC旁路部署，从交换机镜像流量过来（这个就不细说了）；2、AC对接AD域：接入管理-接入认证-portal认证-认证服务器，新增LDAP服务器，填写相关对接信息，需要一个域管理员权限的账号。AD域如果有开启加密的话，AC这里也要勾开启加密，加密方式与AD域一致即可。然后在用个普通域账号测试有效性即可，这里不做了，对接成功后同步LDAP后，即可在用户管理看到同步过来的组织架构了。3、AC对接华为NCE：AC配置：接入认证-单点登录-第三方设备，选择华为Agile Controller（和华为NCE是一样的，AC这边没做区分），配置对接信息，IP、密钥和端口（华为默认端口8001，两边一致即可）。华为NCE配置 iMaster NCE-Campus使用8445端口进行对接。缺省情况下，iMaster NCE-Campus的8445端口是关闭的，需要在管理面开启（注意，这里8445端口是华为NCE对接行为管理类设备端口，与上文和AC对接8001端口不是一回事）。登录控制器管理面。在主菜单中选择“产品 > 软件管理 > 部署产品软件”，单击“更多 > 修改配置参数”，将“ENABLE_8445(是否启用ACANginx服务的8445端口)”设置为“true”，单击“确定”。在主菜单中选择“准入管理 > 准入策略 > 增值业务”，单击“上网行为管理”页签。单击“创建”，添加上网行为管理设备，填写AC地址，对接端口，加密算法（AC只支持AES128）,密钥、认证网段。 对接成功后在AC添加单点登录认证策略，认证服务器选上文配置的NCE。 用户在NCE上线后，即可在AC单点登录上线，可以在在线用户管理-域用户那里看到用户上线，认证方式是单点登录（测试时忘记截图了，随便截个图将就看，是可以看到用户上来了的）。 查看当时认证日志作证，通过华为准入单点登录上线下线。 4、AC配置应用控制策略：这个就正常配置，就对象在域用户那里选。看日志，应用策略有效。 这个时候AC从AD域那里拿到了组织架构，又从华为NCE拿到用户认证信息，就能满足这个客户的需求了，既可以不用重复认证，通过用户名快速溯源，也可以通过用户名来做应用权限管控。 广龙ㅤ 2026-03-30 6k 1 内存条、固态硬盘价格疯涨，为什么说“不买维保”反而更贵？ 七嘴八舌bar 2026-04-15 7k 2 深信服×FastGPT联合发布SF-FastGPT，打造“0专家+好效果”的企业级AI应用 大模型技术飞速迭代，AI能力已深度融入企业研发、客户服务、IT运维等全业务场景，成为数智化转型的核心引擎。 然而，生产级AI应用的建设却常困于一个“魔咒”：效果好必须靠专家。企业高度依赖AI专家团队反复调参，试错成本高、落地周期长、投入不见底，效果难以保障。想要真正破局，就要打破对 AI 专家的过度依赖，让不懂 AI 的业务人员，也能轻松实现专家级 AI 效果。 正是基于这一洞察，SF-FastGPT 应运而生 —— 一款专为企业级用户打造的 “0 专家+好效果”的AI应用构建平台。 深信服 X FastGPT，专为企业级AI应用而生 SF-FastGPT，源自深信服（SANGFOR）与开源平台FastGPT的深度战略合作，将两者的核心优势合二为一。 ▪️ FastGPT：GitHub上超27k星的顶流开源项目 在国内开源社区同类产品排名第二。 凭借强大的RAG（检索增强生成）能力、可视化编排与多源数据接入能力，FastGPT在轻量问答与知识检索中表现优异；复杂业务中可通过工作流灵活编排复杂逻辑，并集成API调用外部工具。被全球开发者广泛用于生产级AI应用构建，经过海量企业场景的实战验证，并保持快速迭代能力。 ▪️ 深信服：深耕AI领域十余年，企业级市场二十余年 自2016年确立“AI First”战略以来，深信服深耕近十载，构建起覆盖“AI安全与基础设施”的全栈AI版图。依托“AI型组织”的实战积淀与顶尖AI人才梯队，持续驱动AI能力进化。 通过安全GPT及安全智能体、企业内部大量场景化Agent应用等复杂场景的最佳效果实践，转化为标准化的产品能力，同时通过大量算法专家的经验沉淀，持续赋能AI算力平台、Agent开发平台及AI原生应用，加速AI能力的普惠化与场景化落地。 同时，深信服依托二十余年服务超十万家政企客户数智化转型的经验，深谙企业级应用的真实业务需求和场景，从而支持构建更贴合客户生产场景的智能体应用。 此次发布 SF-FastGPT 将双方的“顶级AI应用创新能力”与“深厚、普惠的企业级AI应用效果调优”合二为一，从设计之初就只为解决一件事：让没有AI 专家的企业，也能把 AI 真正用起来，而且一开始效果就不错。 从RAG到全栈Agent，打通 AI 落地全链路 ▪️ 不止精于RAG SF-FastGPT延续并升级了FastGPT业界领先的RAG核心能力，覆盖企业知识从治理到应用的全生命周期。通过智能分块、索引优化与检索策略调优，将RAG能力做深做透，在企业知识库、智能客服、AI助理等关键场景，把「知识问答」做到极致，为用户高阶 Agent 应用落地筑牢了可靠的知识根基。 ▪️ 更是全栈Agent平台 在此基础上，SF-FastGPT 进一步提供开箱即用的 Agent 构建、应用测评与企业级平台管理能力，形成从开发到运维的全流程闭环。在低代码、可视化的环境中，业务人员通过拖拽配置，即可快速打造适配自身业务的数智员工、数字分身等场景化应用，极大降低了 Agent 开发的技术门槛，让 AI 真正实现从“对话助手”到“业务执行者”的能力跃迁。 当然，在用户Agent落地的最后一公里环节，SF-FastGPT还配套了相关支撑服务—— 打造了贴合企业真实业务的 Agent 在线 POC 平台，找场景、验证场景、快速部署，均可一站式体验，大幅降低 Agent 的试错成本与落地门槛。 广泛的AI服务商生态，提供覆盖 Agent 落地全周期的陪跑服务，让企业Agent落地全程无忧。 ▪️ 0专家也能保障好效果 SF-FastGPT 之所以能让用户无需AI技术专家，就能轻松落地高质量AI应用，源于两大核心能力的加持—— | 业界领先的知识解析算法 针对复杂文档场景深度优化，精准解析跨页表格、手写体、复杂公式等，从源头确保知识输入高质量，有效提升效果的天花板，真正满足企业级应用的严苛要求。 ➢ 复杂文档场景（含跨页表格、分页、图片表格混合、手写体文字等） ➢ FastGPT深信服商业版对复杂文档的解析效果，远超同类平台 | 效果持续进化的自学习引擎 SF-FastGPT的核心创新，在于将自学习引擎与RAG深度结合。企业知识库准备就绪后，一键触发自动学习，系统自动生成训练样本、完成模型微调。无需算法团队，即可让AI模型从底层深度贴合企业专属业务场景。 首次上线准确率可达85%以上（远超通用Agent的70%平均水平），且越用越精准，让企业AI落地的效果在一开始就有一个更好、更高的起点。 同时，在生态兼容方面，SF-FastGPT做到了极致灵活：硬件上广泛适配英伟达和国内主流算力设备，模型上无缝对接各类主流大模型，模型部署上支持轻量化GB10的算力盒子极简部署，托管云 / 公有云服务、本地私有化部署全场景方案，无论企业IT环境如何，都能快速落地。 不止于此，SF-FastGPT 还与 FastGPT 开源社区版能力同步迭代。每次版本升级，用户都能第一时间获得最新的智能技能和知识检索增强等前沿能力，始终享有最先进的AI能力，保持竞争力。 目前，SF-FastGPT已服务新能源、PCB制造、政府、金融、教育等多个核心领域的数百家企业，成为他们AI应用落地的加速器。 企业AI转型的下半场，真正需要的不是单一的RAG/Workflow工具，而是一个无需专业AI团队就能快速落地生产级AI应用的综合解决方案。 SF-FastGPT 企业级一站式AI应用落地引擎，彻底打破了AI应用的技术壁垒，重构了企业级AI应用的落地逻辑，让AI普惠真正触手可及。 添加SF-FastGPT服务团队，我们为您提供： -免费试用-多套上市企业智能体编排模板免费部署-企业级AI agent应用落地私训课（深圳、长沙、北京、浙江）-企业内训定制课程-Agent技术专家在线咨询答疑 七嘴八舌bar 2026-04-02 14k 5 AI时代供应链投毒比你想象的更疯狂！所有接入开源组件的企业，速自查！ 近两周，深信服千里目安全技术中心先后监测到三起影响广泛的供应链投毒事件—— ● 开源AI API网关LiteLLM在PyPI发布的1.82.7和1.82.8版本被植入恶意代码，在常规安装时即可静默触发信息窃取并横向移动。 ● API协作平台Apifox公网SaaS版桌面客户端遭遇供应链投毒，恶意代码可窃取凭证并远程执行命令。 ● 主流JavaScript库axios的两个npm版本axios@1.14.1、axios@0.30.4被恶意植入远程控制代码。 三起影响广泛的供应链投毒事件分析 AI时代，开发迭代速度大幅提升，企业对开源组件、AI工具链的依赖程度持续加深。攻击者正是利用开发者生态的信任链条发起攻击，潜伏在开源组件、开发工具、部署流程等环节中。 从LiteLLM、Apifox到axios接连爆发的供应链投毒事件中，我们可以看出：供应链攻击已进入常态化、精准化的新阶段，安全风险全面升级。 ● 开发工具软件成为供应链攻击的首选入口。一旦工具被攻陷，攻击者可直接获取系统权限，快速渗透内网，破坏力远超常规攻击，成为AI时代企业安全的核心短板之一。 ● 攻击工具化与精准化是重要趋势。以Apifox投毒事件为例，恶意软件本质上是一个远程代码执行平台。攻击者基于回传的信息筛选高价值目标并实施定制化攻击，整个攻击模式逐步向APT化演进，而常规安全防护手段难以有效抵御。 Part.1 应急响应建议 面对这类攻击，需要警惕的是，目前公开的IoC仅涵盖侦察和凭据采集阶段，绝非攻击的终点。受影响的企业和开发者需要按照“已完全失陷”的最高级别启动应急响应，以免遗漏可能已发生的深度入侵。 ■ 快速排查（IoC） 在网络侧检查是否出现对apifox.it.com、models.litellm.cloud等异常访问； 在终端侧排查litellm_init.pth、/tmp/ld.py，6202033.vbs等恶意留存痕迹。 ■ 全域清除感染 Apifox客户端升级至2.8.19或以上版本（官网下载并覆盖安装）；LiteLLM降级至安全版本1.82.6并锁定依赖；axios退回至安全版本1.14.0-1.x分支或0.30.3-0.x分支。 在防火墙、企业DNS或本机hosts中封锁已知恶意域名；同步清空Apifox本地缓存数据；删除axios相关的木马文件。 ■ 凭证轮换（按优先级执行） 立即重置SSH私钥、Git凭证、云服务凭证AccessKey、K8s集群配置等所有可能泄露的凭证。 Part.2 从「被动修复」转向「主动治理」，重构AI时代的供应链安全防线 实际上，供应链安全风险具有‌系统性、长期性和复杂性‌等特点，仅靠一次临时性、事件驱动的应急响应难以构建持久的韧性。 企业和开发者必须将供应链安全纳入与功能开发同等优先级的体系化建设中，从制度和技术两个维度重构开发工具链信任体系，实现从「被动修复」到「主动治理」的根本转变，从而筑牢AI时代的供应链安全防线。 ■ 从制度层面明确规范 企业和开发者应将安全管理融入研发流程中，通过开发工具沙箱化运行、凭据动态轮换机制、供应链SBOM管理等举措，形成常态化的安全治理体系，以制度约束推动规范化管理，从源头降低供应链安全风险，实现长效治理。 ■ 从技术层面强化保障 此外，为更好地应对复杂多变的供应链攻击，深信服提供一整套解决方案，帮助企业主动守护研发安全—— ● 主动运营，提前发现风险并闭环处置 深信服MSS安全托管服务，7*24小时主动监测风险，主动预警供应链攻击情报并协助用户应急响应，确保用户第一时间获取最新威胁情报并完成内部排查；联动aES终端安全，及时发现隐蔽威胁并实现安全事件闭环处置，有效防范攻击者深度渗透。 ● 主动防御，以快制快，实时拦截新型威胁 深信服AI+SASE赋能的下一代防火墙，通过云威胁情报网关，实时拦截C2外联等新型威胁；通过云端AI智能体，实时挖掘供应链攻击事件并全网共享威胁情报，帮助用户快速发现异常远控等新型威胁。 ● 主动隔离，构建可信可控的研发环境 深信服零信任上网沙箱方案，帮助用户实现业务访问与互联网访问的双重隔离，最大限度收缩攻击暴露面，保障办公与开发环境的可信可控。 欢迎咨询供应链攻击全场景主动防护方案 七嘴八舌bar 2026-04-08 11k 6 #信服智创#【排障经验】L20显卡直通异常问题处理分享 信服智创 | 参与得豆！2026征文大赛正式启幕！ 一、问题描述使用dellR760xa 服务器搭载4张nvidia-L20显卡安装超融合系统，运行windows2022server虚拟机，显卡直通异常。问题现象：1、显卡驱动安装后，nvidia-smi命令报错： 2、重启虚拟机后设备管理器中显卡设备异常报错43： 3、事件查看器提示显卡被意外删除： 4、无法打开显卡驱动控制面板。 二、定位问题1、排查虚拟机环境配置问题，将启动模式修改为uefi，主板设置为q35，更换显卡驱动，但Q35不支持L20的显卡，改为uefi和驱动后依然没有效果。2、将服务器重新安装为物理windows2022server，同时安装驱动，能够安装驱动以及识别显卡，证明硬件无异常。 3、重新装回深信服超融合，进入asv后台，查看显卡pci信息（由于是直通场景，超融合没有安装显卡驱动，直接用lspci命令查看显卡）发现显卡的bar内存只申请到了8G，找到关键原因。 问题解析：1、什么是 PCIe BAR（Base Address Register）？CPU 想要读写显卡上的显存，并不能直接伸手去摸，必须通过 PCIe 总线在内存地址空间里开一个“窗口”。CPU 看着这个窗口，就能映射到显卡内部的显存。这个窗口的大小，就是你在 lspci 里看到的 size。2、L20 的特殊性NVIDIA L20 拥有约 48GB 的物理显存。当识别为 8G 时：CPU 每次只能透过这个 8GB 的窗口看到一小部分显存。如果程序需要访问整块显存，CPU 就得频繁地“翻页”或切换映射地址，效率极低，且会导致驱动程序架构逻辑冲突。3、现代驱动的要求对于 L20 这种 Ampere/Lovelace 架构的卡，NVIDIA 驱动默认要求开启。Resizable BAR (Re-Size BAR) 或者直接分配一个大于物理显存的静态窗口（如 64GB）。如果窗口只有 8G，驱动自检时会认为硬件资源不足或分配异常，从而触发 “设备管理器代码 43”。 因此在虚拟化直通环境中asv加载的是 vfio-pci这种占位用的存根驱动，只能识别到8G的资源映射表直通给虚拟机，因此在虚拟机主板中，会认为这张显卡就是只有8G，安装驱动时，驱动自检就会报异常43而直接物理安装windows驱动正常是因为nvidia驱动会主动向主板发起动态寻址，向主板申请更大的内存，因此直接安装物理机一切正常。 三、排障思路1、在同型号的ubuntu系统中lspci查看，发现显卡显示的是64G，说明linux内核驱动是支持这个显卡的，怀疑主板配置问题，咨询了dell厂家，该型号默mmiou的bar大小为1024T，完全满足该显卡运行。 2、为了验证是否asv兼容性问题，使用ubuntu桌面体验版进入系统，使用lspci依然是8G，确认是硬件问题导致的。 使用nvidia工具查看显卡状态，发现L20显卡提示可视化功能已打开。L20 在这种模式下，会强行开启一种叫“可扩展可视化”的特性。在 NVIDIA 的底层逻辑里，这个特性会要求主板 BIOS 分配一组非常特殊的、非连续的或者受限的物理内存地址。而戴尔 R760xa 的 BIOS 在处理这种请求时，如果不经过特殊配置，就会因为分配不下而退化成最保守的 8G。 /displaymodeselector --gpumode physical_display_disable 通过这个命令从物理硬件层面，彻底禁用所有显卡的显示输出功能。 使用该命令后可看到3个选项，显卡现在的状态就是2导致的。我们选择1将显卡的显示功能关闭。 询问是否全部切换工作模式，选择y。 确认后开始执行，所有显卡提示转换成功即可。完成后手动重启物理主机生效。 重启后使用lspci -vvv -s 查看显卡状态，看到显卡的bar内存大小已变为64G。 重新为虚拟机直通显卡。 安装驱动后，虚拟机内输入nvidia-smi可正常看到显卡，问题解决。 四、问题根因 L20 虽然是计算卡，但它底层可能带了一部分虚拟显示控制逻辑（刚才看到的 Scalable visualization 就是证据）。之前的状态：显卡觉得自己要负责“显示输出”，所以它会向主板请求一组特殊的、复杂的 PCIe 资源池。戴尔主板 BIOS 比较死板，一看是显示设备，就只按照老规矩给它分配最保守的 8G。这条命令的作用：它直接改写显卡固件，告诉显卡：“你从今往后就是个纯纯的算力干活机器，把所有显示相关的物理开关全都关掉。结果就是：一旦禁用了物理显示，显卡对 PCIe 资源的诉求会变得极度简单粗暴。主板 BIOS 再次自检时，会发现这只是个纯计算设备，就会毫无压力地吐出那 64G 的完整空间。 PS：这个问题真的非常隐蔽，整整排查了3天，觉得很有分享意义 蔡勇 2026-04-03 13k 8 #信服智创#【广东创讯案例】以腾讯云作为范例浅谈公有云AF防火墙实施思路 信服智创 | 参与得豆！2026征文大赛正式启幕！ 前言：客户在公有云部署了多台业务系统，需求通过防火墙进行安全防护，实现通过防火墙映射访问业务系统，并通过防火墙代理上网，达到上下行流量经过防火墙安全防护之目的。 一、明确需求背景 客户为什么要做这个项目？重点是需要切换哪几台ECS ？例如：公有云部署了多台业务系统，实现通过防火墙DNAT映射访问业务系统，并通过防火墙SNAT代理上网，达到上下行流量经过防火墙安全防护的效果。所有的ecs都需要将流量切换到防火墙后进行防护。 详细如图： 二、方案编写思路 三、项目坑点总结1、客户如果原有是包年包月的普通公网ip，需要先转成按量计费，再转成弹性ip，最后改回包年包月计费弹性Eip的时候存在大量的费用差额，一定要提前和客户沟通好这部分费用问题。（目前已知腾讯云从普通ip转为弹性Eip时有费用问题）差额=新建包年包月计费弹性ip开销-原有普通公网ip转为按量计费的退款2、腾讯云配置默认路由的时候，需要新建一个VPC路由表，并且不能关联防火墙的WAN口。因为关联WAN口之后腾讯云会将wan口出来的流量又转发给防火墙。但是在华为云和阿里云上，如果内网IP绑定了公网ip，会有更高优先级的VPC路由将流量直接转发至互联网，不存在三层环路问题。3、在进行变更前预配置的时候，建议配置和DNAT相同的BNAT策略，这样可以在没有改变公有云VPC路由的情况下，进行业务验证。4、建议vAF在创建的时候，新建2-3个网段用作lan口和wan口，不要与原有的业务子网复用。 ECS虚拟机实例及CLB负载均衡调研表格 公有云防火墙高可用部署参考 陈璨 2026-03-30 5k 0 #信服智创# 【项目案例】某会计行业VMware替换实战：双路径迁移模型下的70+虚拟机平滑迁移与架构收敛 信服智创 | 参与得豆！2026技术征文大赛正式启幕！ 目录：一、项目背景 1、部署情况如下 2、两套存储体系 3、业务规模二、现网问题分析 1、稳定性开始出现波动 2、资源已经逼近上限 3、架构复杂度逐渐失控 4、生命周期风险进入临界区三、方案设计 1、整体思路 2、方案取舍过程 3、资源与容量设计 4、业务承载策略 5、存储架构选择 6、双路径迁移模型设计 7、迁移策略设计 四、简要实施过程 1、迁移前准备 2、环境准备 3、迁移工具验证 4、分批迁移策略 5、业务割接与回退 五、关键问题与处理 问题一：vmtools安装失败导致虚机网络异常 问题二：Windows 2008 R2虚拟机迁移后蓝屏且无法关机/关电源 问题三：Windows Server 2008 R2虚拟机启动卡在Startup Repair修复失败 问题四：部分Windows虚拟机无法在系统内调整分辨率 问题五：文件服务器访问延迟波动 六、效果验证 1、稳定性 2、资源使用情况 3、架构变化 4、运维侧变化 七、项目价值总结 1、架构层面 2、稳定性 3、成本与资源策略 4、迁移模型价值八、项目复盘 1、双路径迁移更适合复杂环境 2、分批迁移是风险控制核心 3、文件服务器比想象中更“敏感” 一、项目背景 某客户为会计服务机构，核心业务覆盖财务开票、企业代账、资料归档等场景。原VMware平台不是不能用，而是继续用风险不可控。系统本身不算复杂，但有一个特点：白天不能中断、数据不能出错。一旦异常，影响的是客户报税和开票，业务容错空间比较小。 现网环境搭建时间较早，整体已经运行了接近 7 年。1、部署情况如下 服务器：5台 Dell R740 单节点内存：256GB 虚拟化平台：VMware + vSAN 2、两套存储体系 vSAN存储：每节点2×960GB SSD（缓存）+ 14×1.2TB HDD（容量），集群vSAN原始容量约74TB，实际可用容量约37TB（2副本策略） 外置HP存储（iSCSI方式接入），约7TB 3、业务规模业务在不断增长，目前虚拟机数量在70台以上。 其中几类业务比较关键： AD域控（所有认证依赖） 财务开票系统（核心生产） 文件服务器 Web服务及合作方系统 实际存储占用约54TB，折算有效数据约27TB（考虑副本开销后）。 从资源规模看，这套环境并不算小，但也没有大到必须做复杂架构。问题的关键不在“规模”，而在运行时间 + 架构叠加。 二、现网问题分析 这次改造并不是因为某一次重大故障触发的，而是系统在长期运行过程中逐渐“变得不太对劲”。有些问题单独看都还能接受，但叠加在一起，就开始影响决策。 1、稳定性开始出现波动 历史上出现过两次ESXi紫屏（PSOD），当时恢复过程比较顺利，没有造成长时间中断，但这个问题一直没有彻底定位清楚。这个问题虽未引发长时间业务中断，但已经具备明显的不确定性风险。 2、资源逼近平台上限 集群总内存约1.25TB，但使用情况比较紧张： 日常运行：80%左右 高峰期：存在明显资源争抢 最直接的影响是： 新业务上线需要反复评估资源 部分业务性能波动 一开始考虑过扩容，但很快遇到现实问题： 老型号内存采购周期长 成本明显偏高 投入之后仍然是老架构 扩容变成了一件“投入大、收益不确定”的事情。 3、架构复杂度逐渐失控 存储侧是两套体系同时存在： vSAN（本地） iSCSI外置存储 这在早期是为了扩展容量，但随着时间推移，带来了几个明显问题： 存储路径变复杂（本地 + 网络存储并存） 故障排查需要跨多层（虚拟化 / 存储 / 网络） 一些问题很难第一时间判断归属 实际运维中，经常会遇到这种情况： 一开始怀疑是网络 → 排查后没问题 → 再看存储 → 最后才定位到具体组件 排查路径被拉长，风险也随之增加。 4、生命周期风险进入临界区 7年这个时间点，本身就比较敏感。现场能明显感觉到变化： 磁盘故障更换频率增加（尤其是HDD） 硬件状态不再稳定 厂商支持逐步减少 继续在原平台上叠加投入，风险很难评估。 三、方案设计 这次设计并没有一开始就确定“必须上深信服HCI”。现场其实讨论过一段时间，核心问题是：是继续补这套老系统，还是换一套更简单的架构。 1、总体设计策略最终确定的方向是： 新建一套深信服HCI承载核心业务 原VMware保留，作为过渡与回退环境 采用分阶段迁移，避免一次性割接 这不是“推倒重来”，而是一个相对稳的过渡方案。 2、方案取舍过程方案一：继续扩容VMware优点很直接： 不需要迁移 风险可控 但问题也很明确： 原有架构复杂度不会下降 历史问题（PSOD、存储结构）仍然存在 后续还要继续投入 这条路更像是在“延长使用寿命”。 方案二：新建HCI（最终选择）优势在于： 架构收敛（计算 + 存储一体） 运维路径更短 后续扩展更简单 更关键的一点是：可以把复杂度“清掉一部分”，而不是继续叠加。 最终选择新建 HCI，再通过迁移完成过渡。 3、资源与容量设计 新平台采用： 深信服 aServer-X5-2105 × 2 台 资源配置： 单节点内存：512GB 集群总内存：1TB 存储：6×3.84TB SSD / 节点（全闪） 集群原始容量约44TB（双副本后可用约22TB） 4、业务承载策略 一开始并没有打算“全量迁移”。现网有效数据约27TB，如果全部迁入： 容量压力较大 成本不合理 最终做了拆分： 核心业务（约7TB）迁入HCI 非核心业务继续留在原平台 这样处理之后，新平台负载控制在约30%~50%，同时预留了扩展空间。 5、存储模型选择 在方案设计阶段，对两种路径进行评估： 方案 优点 缺点 混合架构（SSD+HDD） 容量大 随机IO性能不稳定 全闪SSD架构 高性能成本较高、容量受限 结合实际业务： 文件服务器：大量小文件随机读写 财务系统：数据库事务型IO 在经验判断中，混合架构有一个明显问题：一旦缓存命中下降，HDD会成为瓶颈，尤其是在并发访问时，延迟会放大。 最终还是选择了全闪架构，核心考虑不是“性能极致”，而是：让性能更稳定、可预期。 6、双路径迁移模型设计 在迁移方案设计阶段，迁移方式并不是一开始就确定的，而是结合现网条件、授权情况以及迁移风险做了实际取舍。 现场主要评估了两种路径：VMware纳管迁移 和 SCMT迁移工具。（1）VMware纳管迁移通过HCI平台对VMware集群进行纳管后，可以直接调用生命周期管理中的迁移能力，将虚拟机从VMware侧迁移到HCI平台。这个方式的特点很直接： 不需要额外部署组件 不依赖Agent 操作路径相对简单，适合批量迁移 但在进一步评估时，也发现几个限制： 部分老旧虚机（尤其驱动、硬件版本较低）兼容性不稳定 一旦迁移过程中出现异常，可调整空间有限 （2）SCMT迁移工具SCMT本质上是一个独立的迁移工具，支持P2V / V2V场景，可以通过Agent方式完成数据同步和业务切换。相比纳管迁移，它的特点更偏“稳”： 支持全量 + 多轮增量同步 业务中断时间可以控制（分钟级） 对操作系统和环境兼容性更强 在测试过程中，Windows和Linux虚机都可以正常完成迁移，启动成功率较高。 但它也有比较现实的限制： 需要单独部署组件 依赖授权（本项目通过测试授权验证） （3）最终取舍：双路径并行 结合客户实际情况，这里做了一个比较“务实”的选择： 优先使用VMware纳管迁移作为主路径 原因是现场未采购SCMT正式授权，同时纳管方式可以覆盖大部分标准业务 SCMT作为备用路径引入（测试授权） 主要用于应对迁移过程中可能出现的兼容性问题或失败场景 这样形成一个比较清晰的策略： 能用纳管的，优先走纳管； 纳管不稳定或失败的，再切SCMT处理。 （4）现场经验这个决策背后，其实有一个很现实的考虑： 在多业务环境下，迁移的不确定性往往不在“工具本身”，而在： 虚拟机历史版本差异 驱动及系统环境 存储结构差异 7、迁移执行策略 所有虚拟机统一采用三阶段迁移： 全量同步 多轮增量同步 最终切换 在实际执行中，大多数业务中断可以控制在： 3～10分钟（特殊情况例外） 四、简要实施过程整个实施周期控制在两周左右，没有做“大批量一次性迁移”，而是拆开执行。1、迁移前准备 主要做了几件事： 梳理70+虚机清单 标记业务依赖关系（重点关注AD、财务系统） 整理VLAN、IP规划 统计迁移数据量（约7TB核心数据） 在梳理依赖关系时，有一个比较直观的感受：AD一旦出问题，所有系统都会受影响 所以后面迁移顺序是围绕这个来设计的。 2、HCI、SCMT环境准备 完成集群初始化 计算、网络、存储配置与调优 部署SCMT虚拟机 这里有个关注点： VMware、HCI网络打通（确保迁移链路稳定） 3、迁移工具验证 在正式迁移前，单独对SCMT做了一轮验证。当时的目标很简单：不追求快，只确认“能不能用”。 测试结果： Windows / Linux都能正常迁移 启动成功率100% 单台切换时间约5分钟 做到这一步，其实心里就比较有底了。 4、分批迁移策略 迁移顺序不是按“重要程度”，而是按“影响范围 + 可控性”来排的： Web、打印服务 → 先做验证 文件服务器 → 中间阶段（重点观察） AD、财务系统 → 最后迁移 这里有一个取舍：文件服务器虽然不是最核心，但用户感知最明显，所以放在中间阶段处理。 5、业务割接与回退设计 割接统一在夜间窗口执行。流程相对固定： 完成最终增量同步 停止源端虚拟机 启动HCI侧虚拟机 回退策略做得比较保守： 源虚机不关机 仅断开网络 出现问题可以快速恢复 整个迁移过程中，这套回退机制没有真正用上，但在现场非常关键——有回退，执行起来心里更稳。 五、关键问题与处理这次迁移整体过程是可控的，但并不是完全“顺滑”。 真正有价值的，反而是中间遇到的这些问题。 问题一：vmtools 安装失败导致虚拟机网络异常现象 个别虚拟机迁移完成后，系统可以正常启动，但网络始终不通。 现场第一反应是比较常见的方向： 虚拟网卡类型是否兼容 但检查下来，配置本身没有明显问题。 排查过程 一开始的判断其实有点“惯性思维”——优先怀疑驱动兼容。 尝试过： 更换虚拟网卡类型 问题依然存在。这时候才把关注点从“虚拟化层”往系统内部转。 继续排查vmtools安装日志，发现报错：Error: copy file success but the file is not the same! Please retry.Install Update module failed! 当时翻了下support故障案例，发现有个因boot分区、导致scmt客户端安装失败问题： “对于linux要求linux的boot区分空间至少要有200M，其他分区也不要有占满的情况”，因此接下来也尝试往这个方向排查。 根因定位继续往系统层看，发现一个细节： /boot分区使用率已经接近满 进一步分析后确认：vmtools安装过程中需要写入引导相关文件/boot空间不足时： 文件写入不完整 校验失败 安装流程中断 最终导致：驱动未正确加载 → 网络异常 处理方式处理过程反而比较简单： 清理 /boot分区无用文件 释放空间 重新安装vmtools 处理后： 驱动正常加载 网络恢复 经验总结：这个问题本身不复杂，但有两个点比较典型： 迁移问题不一定出在“迁移工具”或“虚拟化层” 系统内部环境（尤其是分区空间）很容易被忽略 在后续迁移中，针对 Linux 虚机，额外增加了一步检查： 提前确认/boot、/、/var等关键分区空间 避免同类问题重复出现。 问题二：Windows 2008 R2 虚机迁移后蓝屏且无法关机/关电源现象在一次纳管迁移完成后，一台 Windows Server 2008 R2虚拟机启动过程中出现蓝屏。 这台机器的问题比较典型但也比较棘手，不是单次蓝屏，而是进入了自动重启循环： 系统一启动即蓝屏 随后自动重启 无法正常进入系统 现场尝试常规关机、关闭电源都没有效果，虚拟机一直在循环重启。多次尝试后，在开机过程中按F8进入启动选项界面，才把系统“卡住”，从而完成关闭电源操作。蓝屏信息如下： 排查与尝试 初步判断还是偏向迁移带来的兼容性问题，重点怀疑方向包括： 虚拟硬件环境变化 磁盘控制器类型变化 系统驱动不匹配 现场没有第一时间更换迁移方式，而是先尝试做一轮基础修复，看能不能在原路径上恢复。 由于系统无法正常启动，这里通过挂载PE的方式进入系统进行处理，主要做了几步尝试： 尝试进入安全模式（未能成功进入） 通过PE环境对系统盘进行修复，排除明显的文件系统异常 整体过程没有报明显错误，但修复完成后，系统依然在启动阶段蓝屏，没有实质改善。 处理方式 到这一步，其实有两个选择： 继续在系统层做更深入的修复（如驱动替换、启动项调整等） 或者直接更换迁移路径 结合当时现场情况，这里没有继续在系统层“往深挖”，而是选择切换方案： 使用SCMT对该虚拟机重新进行迁移 迁移完成后再次启动，系统可以正常进入，未再出现蓝屏问题。对比来看，SCMT在迁移过程中会对目标虚拟机进行驱动适配处理（包括磁盘控制器驱动注入），对原系统环境依赖更低，因此在老系统场景下成功率更高。 经验总结这个问题不算复杂，但在迁移场景中比较典型，主要有几个点：1、老系统对底层环境变化更敏感像Windows 2008/2003这类系统，驱动体系较老，对虚拟硬件（尤其是磁盘控制器）的变化适应能力有限，一旦环境发生变化，就容易在启动阶段出问题。 2、迁移问题不一定都适合“修”从结果来看，这台虚拟机本身是正常的，问题更多出在迁移后的环境适配。如果一直停留在系统修复路径上，时间成本会比较高，而且结果不确定。 3、切换路径比持续修复更有效这次处理没有在原路径上反复尝试，而是直接更换迁移方式，从结果来看效率更高，也更可控。在多业务迁移场景中，这种方式更容易保证整体节奏，不会因为单点问题被拖住。 总结：在类似场景中，如果出现“启动即蓝屏 + 安全模式无法进入 + 文件系统无异常”，可以优先考虑存储控制器或驱动兼容问题，而不是继续从系统损坏角度排查。问题三：Windows Server 2008 R2启动卡在Startup Repair修复失败现象：在迁移完成一台Windows Server 2008 R2虚拟机后，系统启动阶段直接进入自动修复流程，界面提示：该过程持续较长时间后，最终提示修复失败：随后系统进入“发送错误报告 / 关闭”选项界面，但无论选择何种方式，均无法正常进入操作系统，虚拟机持续停留在修复与重启流程中。 排查过程 从现象来看，首先考虑的是磁盘或文件系统异常，因此优先按传统思路进行了验证，包括： 检查虚拟磁盘是否存在明显异常提示 尝试进入安全模式（未能成功） 通过挂载PE环境对系统盘进行硬盘修复操作 但排查结果： 文件系统无明显损坏 无法定位到具体坏道或逻辑错误 同时，系统在修复阶段并未给出明确错误码，属于“修复过程卡住但无明确报错”的状态。 处理判断在排除磁盘与文件系统问题后，问题开始转向迁移适配层面进行分析。 结合前期类 Windows 2008 R2虚拟机的迁移情况，判断该问题更可能与以下因素相关： 迁移后虚拟硬件环境变化（磁盘控制器 / 虚拟显卡类型） 老版本操作系统启动链路对虚拟化环境兼容性较弱 自动修复机制在检测异常启动链路时进入循环修复状态 该类问题的特点是： 系统本身并未损坏，但无法完成正常启动初始化流程。 处理方式在尝试常规修复路径无效后，未继续在系统层深入排障，而是直接切换迁移方式： 使用SCMT对该虚拟机重新执行迁移流程 采用重新同步 + 增量切换方式重建虚拟机环境 迁移完成后，虚拟机启动正常，不再进入Startup Repair流程，系统可直接进入登录界面，业务恢复正常。 经验总结该问题在现场属于“启动修复循环失败”场景，在Windows Server 2008 R2这类老版本系统中较为常见。 从处理结果来看，问题并不在于磁盘或系统文件损坏，而更偏向于： 虚拟化环境变化后引起的启动链路异常 自动修复机制无法正确识别虚拟硬件状态 老系统对迁移后驱动与启动顺序敏感 在类似场景中，如果已经排除文件系统损坏但仍无法正常启动，继续进行系统层修复的收益较低，优先考虑通过重新迁移方式重建运行环境，往往比“修复系统”更直接有效。 问题四：部分Windows虚拟机无法在系统内调整分辨率现象在迁移完成后，个别Windows虚拟机（主要为 Windows Server 2008 R2、Windows 7）存在显示异常： 系统分辨率固定，无法调整 显示设置中无可选分辨率或仅支持低分辨率 远程连接体验较差（画面拉伸、模糊） 而同批迁移的Windows Server 2016、Windows 10虚拟机未出现该问题，可正常在系统内修改分辨率。排查过程 初期按常规方向排查：1、VMTools 状态检查确认虚拟机内工具已正常安装服务运行正常，无报错2、设备管理器检查显卡驱动正常识别无未知设备或驱动异常3、虚拟显卡类型调整尝试更换虚拟机显示适配器类型在Windows Server 2016 / Windows 10中调整后可生效在Windows Server 2008 R2 / Windows 7中无变化 到这一步可以确认：问题不在工具或驱动，而是与系统版本及底层启动方式存在关联。 根因定位后续通过support案例检索，定位到一个关键差异： 部分虚拟机采用 UEFI 启动模式 老版本 Windows（2008 R2 / Win7）对该模式下的显示控制支持有限 在该组合下： 系统内无法正确调用虚拟显卡的分辨率调整能力 分辨率控制由固件（BIOS/UEFI）层接管 处理方式针对该类虚拟机，未再从系统内部继续调整，而是直接从底层处理： 进入虚拟机 BIOS / UEFI 设置界面 手动调整显示分辨率参数 保存后重启虚拟机 调整后： 系统内显示分辨率同步提升 远程访问体验恢复正常 经验总结该问题属于典型的“系统版本 + 启动模式”兼容性问题，特点是： 新系统（Win10 / 2016 及以上）基本不受影响 老系统在 UEFI 模式下功能受限 在类似场景中，如果已确认： VMTools 正常 驱动正常 显卡类型调整无效 则应优先考虑启动模式因素，而不是继续在系统或驱动层排查。 对于老版本Windows虚拟机，如采用UEFI启动，建议直接在BIOS层调整分辨率，可减少无效排障时间。 问题五：文件服务器访问延迟现象文件服务器迁移完成后，用户反馈： 日常访问基本正常 但在高并发访问时，偶尔会出现短时间卡顿 这个问题的特点是： 不稳定、不可复现、但用户有感知 排查过程现场第一判断是典型三板斧： 看存储IO 看网络 看资源使用 结果比较“反直觉”： IO没有明显打满 网络无丢包 CPU /内存也正常 一度怀疑是应用层问题，但对比迁移前情况，又基本可以排除。 定位过程后来把关注点放在一个细节上： 存储策略和原环境是否一致 发现： 初始配置使用的是通用策略 没有针对文件服务器做单独优化 虽然资源没有打满，但在并发场景下： 缓存命中率波动 IO调度不稳定 就会放大延迟感知。 处理方式针对文件服务器做了两点调整： 切换为高性能存储策略 优化磁盘分配方式 调整后： 延迟波动明显收敛 用户侧基本无感 经验总结这个问题有一个比较典型的误区：“监控看不出问题 ≠ 用户体验没问题”尤其是文件服务这类场景： 对延迟敏感 对稳定性要求高 在迁移后，建议优先做一轮： “用户体验验证”，而不仅仅是资源指标验证 六、效果验证迁移完成后，没有立即做结论，而是观察了一段时间运行情况，再做对比。1、平台稳定性迁移前： 存在磁盘老化问题 HDD更换频率增加 出现过PSOD 迁移后： 集群运行稳定，无异常告警 全闪架构下，未再出现磁盘相关问题 未出现主机级异常 现场最直观的反馈是：运维侧“心理压力明显降低” 2、资源使用情况迁移前： 内存长期维持在 80%+ 高峰期存在资源争抢 迁移后： 内存使用率约40%～60% 资源冗余空间明显提升 这带来的变化不是“更快”，而是： 更稳、更有余量 3、平台架构变化 迁移前： vSAN + iSCSI双存储体系 存储路径分散 网络链路复杂 迁移后： 单一HCI架构 无外置存储依赖 存储与计算统一管理 变化的核心不是“减少设备”，而是：故障路径被明显缩短 4、运维侧变化 迁移前： 存储问题需要分别排查vSAN与iSCSI 网络与存储链路需逐层确认 磁盘更换操作频繁 迁移后： 存储统一在HCI平面处理 故障定位路径更直接 外置链路消失 整体变化可以总结为： 从“经验驱动运维” → “结构驱动运维” 七、项目价值总结 1、架构层面 完成从“多套系统叠加”到“单一平台”的收敛。减少了： 多存储体系并存 多路径依赖 系统结构变得更简单，也更可控。 2、稳定性 这次改造没有追求极限性能，而是优先解决不确定性： 老旧硬件风险被消除 磁盘频繁更换问题不再出现 历史隐患（PSOD）不再影响当前环境 3、成本与资源 本次没有做“全量替换”，而是只迁移核心业务（约7TB）这样做的实际效果是： 避免一次性资源投入过高 原平台压力得到缓解 新平台资源使用更集中 资源使用变得更“有针对性”，而不是平均分配。 4、迁移模型价值双路径迁移模型在这次项目中起到了实际作用： 纳管迁移 → 提升整体效率 SCMT → 处理异常情况 相比单一方案： 容错空间更大 迁移节奏更可控 这个模型在多业务环境中是可复用的。 八、项目复盘 1、双路径迁移模型更适用于复杂环境 在虚机数量多、系统类型复杂的场景中： 不确定性来自多个维度（驱动、系统、存储） 单一迁移方式很难覆盖所有情况 双路径设计的价值在于： 出现问题时，不需要“卡住”，可以直接切换路径继续推进 2、分批迁移是风险控制核心 这次没有追求效率，而是优先控制风险： 每一批迁移都单独验证 每一步都可回退 这样做的结果是： 没有出现集中性问题 节奏始终可控 3、文件服务器比想象中更“敏感” 在这个项目中，一个比较深的体会是：文件服务器往往比数据库更容易引发用户反馈问题。原因在于： 用户直接感知 操作频繁 对延迟敏感 迁移这类业务时： 需要更关注“体验”，而不是只看监控 小懒 2026-03-27 10k 7 加载更多 全部 我关注的 全部 最新发表 最新回复 最多回复 热门 最新发表 最新回复 最多回复 热门 =20"> 没有更多了 加载更多 0">哎哟，没有更多内容啦！ 赶紧去多找几个大神关注吧！关注后将在此处优先展示你关注的人发表的最新内容哦！ 0)">哎哟，你还没有关注任何人！ 关注后将在此处优先展示你关注的人发表的最新内容哦！赶紧去找大神吧！ --> 专业 | 开放 | 共享 深信服社区致力于打造开放共享的技术社区。如有问题，可私信管理员 @七嘴八舌bar或联系 0755-86725929 社区长期不活跃账号归档公告 2026-5-29 社区文明行动倡议书 2026-5-19 智能客服总接入量 556w+ 论坛总帖数 +4 158389 资料帖总数 --> 5311 --> --> 活动专区更多> 【SF-FastGPT挑战赛脑洞征集】你的业务，最需要哪款企业Agent来解放效率？ 18k 37 有一说一 | 从大湾区走向世界，深信服超融合扛起VMware替代大旗！ 19k 47 数智化服务平台 - 伙伴先锋共创营 招募令 4k 0 软件升级 “磐石行动”开始啦！多重奖励燃爆全场，共赢高增长！ 11k 7 最新疑问 更多> 今日还没有待解决问题 快去提问吧 更多资源 更多> 产品文档 在线课堂 故障案例库 热门标签 软件下载 维保查询 博客牛文 热门话题 技术专题 产品版块 关注我们了解更多> 关注技术服务公众号 关注微信小程序 关注我们了解更多> 关注技术服务公众号 关注微信小程序 --> 深信服科技官网 | 用户协议 | 隐私政策 | 售前咨询：400-806-6868 | 售后咨询：400-630-6430 ©2000-2026 深信服科技股份有限公司 版权所有 |粤ICP备08126214号-5 返回顶部 --> --> 在线客服 --> --> 售后智能在线 售后技术问题诊断，7*24小时在线 售前在线咨询 专属商务经理在线服务 新手指引 --> 投诉意见 小程序 关注微信小程序实时掌握新资讯 更新日期：2025年 7月16 日 前言 欢迎您使用深信服社区平台（以下简称“本平台”）提供的服务！我们深知隐私对您的重要性，并充分尊重您的隐私，我们将严格遵守法律法规要求采取相应的安全保护措施，致力于保护您的隐私信息安全可控。基于此，本平台服务提供者（或简称“我们”）特制定本《隐私保护政策》（以下简称“本政策”）。 本政策将向您说明在您使用本平台及相关服务的过程中，我们如何收集、使用及共享、披露您的个人信息，我们如何存储以及采取安全措施保护您的个人信息，以及您对您的个人信息所拥有的管理权利及实现方式。除此之外，我们可能会在收集本政策未体现的相关个人信息前，通过单独的隐私通知或声明的方式向您告知前述内容，并征求您的同意，尤其是在您选择开通或启用一项新的服务时。 本政策与您所使用的本平台及相关服务息息相关，请务必仔细阅读并了解本政策的全部内容，在确认充分理解并同意全部内容后再使用。您通过在线勾选等方式确认接受本政策或通过其他任何方式使用本平台服务的，即视为您已充分阅读、理解并同意接受本政策的约束，本政策即在您与我们之间产生法律效力。 本政策将帮助您了解以下内容： 一、本政策的适用范围 二、我们如何收集及使用个人信息 三、我们如何共享、转让、公开披露个人信息 四、信息存储地点和期限 五、我们如何保护个人信息的安全 六、您如何访问和管理您的个人信息 七、我们如何使用 Cookie 和同类技术 八、未成年人保护 九、本政策的更新 十、如何联系我们 一、本政策的适用范围 1.1 如无特别声明或其他专用协议，本政策适用于您使用本平台服务、以及通过本平台使用/访问我们提供的其他产品。 1.2 本政策不适用于其他第三方通过本平台或其他方式向您提供的产品或服务。当您使用其他第三方向您提供的产品或服务时，需由您与该第三方另行就产品或服务使用相关的权利义务协商达成一致。 1.3 您作为本平台的实际操作使用人，当您以认证用户的身份使用时，我们将基于合理信赖、默认您所执行的操作在涉及行使归属于您所代表的实体用户的相关权利、履行实体用户的相关义务、或处置该实体用户的其他相关权益时，您已经获得您所代表的实体用户的充分、有效的授权许可，如您所执行的操作涉及处置其他相关个人主体的个人信息或其他合法权益，我们也将默认您已按照个人信息保护相关法律规范的要求获得该个人主体的充分、有效的授权。本协议仅适用于您在使用本平台及相关服务的过程中所涉及的个人信息，包括归属于您本人的个人信息以及归属于其他个人、但经由您获得个人主体的授权后提交的个人信息，针对其他归属于实体用户的信息，我们将按照与对应实体用户签署的合同或协议或通过其他方式达成一致的约定进行处理。 二、我们如何收集及使用个人信息 在您使用我们通过本平台提供的服务的过程中，我们收集信息的具体情况如下： 2.1 为获得社区平台账号及相应的服务及功能使用权限，您可通过注册页面主动提交相关信息完成账号注册，或直接使用其他社交平台账号授权登录，在这个过程中将会涉及收集并处理您的个人信息为：重新注册账号您需提交手机号码并通过短信验证码完成验证，并可自行设置符合要求的登录密码；您可将社区平台账号与个人的微信账号、QQ账号或微博账号进行绑定，绑定后社区平台将记录用户的微信/QQ/微博平台的账号信息，以便在用户使用前述第三方平台账号登录社区平台时进行身份识别和验证。 2.2 您在注册账号后，平台将会自动为您生成账号对应的UID及用户名、初始头像，您可在个人设置的个人信息页面自行操作修改用户名和头像信息，并可自行填写昵称、所属单位信息、生日、所在城市、邮箱地址及个人签名信息（非必填），您还可通过账号安全页面修改账号绑定的手机号码；前述信息统称为修“账号信息”。我们会记录您的账号信息，以便进行基本的平台用户管理，同时也帮助验证您作为我们的实体用户的真实身份，以便更好地为您提供本平台的功能服务。 2.3 您可通过本社区平台完成相应角色的身份认证，以获得更贴近您的需求的服务。如您属于我们产品/服务的使用用户，您可通过提供设备SN码或设备网关ID自动进行身份认证，或通过提供设备名称、单位名称、产品序列号信息申请人工协助完成认证；如您属于深信服合作伙伴，您可直接申请认证，后台会通过您的手机号码进行身份信息匹配验证 2.4 您通过本社区平台发帖或发布评论时，为同时满足您内容发表和本社区平台内容安全的需求，我们会对您发布或提交的内容进行记录和审核 2.5 当您使用本社区平台提供的技术认证服务（包含合作伙伴认证考试平台https://cert-ca.sangfor.com/examine?type=0提供的考试服务），我们需要您向我们提供如下必要的个人信息，包括：姓名、手机号码、身份证号、邮箱地址、考试日期、考试时间、所属区域、所属公司全称，以便于进行身份核验、考试安排等；在您通过相关技术认证后，本社区平台会永久保存您所获得的认证证书信息，以便进行认证项目相关必要的统计和管理、以及供您需要时查询。 2.6 当您使用本社区平台学习版块-在线课堂（learning.sangfor.com.cn）提供的线上课程学习和考试服务，我们需要收集您的手机号码和所属单位名称信息，以便进行身份验证、并针对性为您提供您权益范围内的学习内容；如您报名考试，我们将需要收集您的姓名、手机号码、所属公司名称以及公司所在区域信息。同时，我们将记录您参与学习及考试的具体课程或项目及时间信息，以及您在学习过程中发表或提交的相关内容，以便帮助您顺利完成学习或考试、以及向您反馈所需的信息内容，与此同时，您知悉并同意：如您在学习过程中发表的提问或互动内容具备代表性或典型意义，我们可能会将您的提问或互动内容设置为推荐类问答话题，此种情况下所有观看相应的课程视频的学员均可查看您的提问或互动内容。 2.7 当您使用本社区平台学习版块-在线实验平台（hol.sangfor.com.cn）提供的产品接入/功能演示等在线实验服务，我们需要收集您的手机号码和所属单位名称信息，以便进行身份验证、并针对性为您提供您权益范围内的实验服务。 2.8 如您需使用本社区平台积分兑换礼品，在兑换成功后，我们需要您提供收件信息（包括收件人名、手机号码和收件地址信息），以便为您提供礼品寄送服务。 2.9 为了向您提供本社区平台的通知和推送服务，我们可能通过您的手机号码、绑定的微信账号、邮箱地址、站内信等方式，向您提供内容推送或通知服务。您可以通过短信退订、邮件退订、客户反馈等方式停止接收我们的服务信息。 2.10 同时，为了履行网络安全保护义务，维护本平台的稳定运行以及保障您的账号安全，同时也为了改进及优化您的服务体验，在您使用本平台的过程中，我们可能会收集您的设备信息，以及您和您的设备如何与本平台交互的信息，包括设备名称、设备型号、IMEI 号码、手机型号、Mac地址、序列号、IP 地址、操作系统版本等设备信息，您使用本平台的时间和持续时长、网站的事件日志（如重启、错误、崩溃等）等信息。我们收集上述信息用于验证您的身份、分析平台运行及相关功能使用情况、防范网络安全风险。 2.11 您使用深信服品牌产品或其他技术服务所涉及的个人信息将通过具体产品或服务各自适用的用户协议或服务协议向您进行列举说明，并将仅在您使用具体产品或服务时才会按照相关协议约定进行处理。如本平台或其他具体产品或服务提供需要您提交本政策或其专门适用的协议中所述范围以外的其他相关个人信息，我们会通过更新协议或弹窗通知或线下签署授权函等书面方式另行征得您的同意。 2.12 您充分知晓，依据可适用的法律，在以下情形中，我们收集、使用相关个人信息无需征得您的授权同意： 2.12.1 与我们履行法律法规规定的义务相关的； 2.12.2 与国家安全、国防安全直接相关的； 2.12.3 与公共安全、公共卫生、重大公共利益直接相关的； 2.12.4 与刑事侦查、起诉、审判和判决执行等直接相关的； 2.12.5 出于维护您或其他个人的生命、财产等重大合法权益但又很难得到本人授权同意的； 2.12.6 所涉及的个人信息是您已自行向社会公众公开的； 2.12.7 为签订和履行您或企业用户与我们之间达成的合同/协议所必需的； 2.12.8 从合法公开披露的信息，如合法的新闻报道、政府信息公开等渠道，收集相关个人信息的； 2.12.9 维护我们提供的产品及服务的安全稳定运行所必需的，如发现、处置产品运行故障。 三、我们如何共享、转让、公开披露个人信息 3.1 共享 我们不会向第三方共享您的个人信息，但以下情形除外： 3.1.1 在获取您明确同意情况下的共享。在向您告知第三方的名称或者姓名、联系方式、处理目的、处理方式和个人信息的种类，且获得您的明确同意后，我们会向您同意的第三方共享您授权范围内的信息。 3.1.2 在法定情形下的共享。根据适用的法律法规、法律程序、诉讼/仲裁、政府的强制命令、监管要求而需要共享您的个人信息；如为了满足相关法律法规的网络实名认证要求，向相关的政府机关或其指定、认可的第三方共享您的个人信息。 3.1.3 在法律要求或允许的范围内，为了保护您或社会公众的利益、财产或安全免遭损害而有必要提供您的个人信息给第三方。 3.1.4 为了保护国家安全、公共安全以及您和其他主体的重大合法权益而需要共享您的个人信息。 33.1.5 您自行公开的或者我们能从其他合法公开渠道获取到您的个人信息。 3.1.6 我们可能会将您的个人信息向我们的关联方披露，以供它们为您提供交易支持、服务支持或安全支持。例如，为避免用户重复注册账号，我们需要对拟注册的帐号进行唯一性校验；我们仅会出于特定、明确且合法的目的向我们的关联方共享您的信息，并且只会共享提供服务所必需的信息。 3.1.7 为提供服务之必要，共享给业务合作伙伴。我们可能会向客户或其他相关合作伙伴等第三方共享您的姓名及联系方式、账号信息、项目合作或交易相关信息，以保障顺利为您提供所需的服务或与您达成相应合作。我们仅会出于合法、正当、必要、特定、明确的目的共享您的个人信息，并且会控制在最小必要范围内，我们保证不滥用您的个人信息。我们可能共享信息的合作伙伴具体包括： 3.1.7.1 经销商合作伙伴。由于深信服数年来一直坚定推行渠道化战略，致力于与经销商合作伙伴协同为广大客户提供优质的产品及配套服务，与此同时也致力于帮助合作伙伴与深信服一同实现共赢发展，基于此深信服需根据不同合作伙伴的具体情况对合作伙伴进行体系化的管理，在此过程中我们可能需要将您的姓名及联系方式等个人信息与客户或其他合作伙伴共享，以及借助第三方平台向您推送宣传/营销相关信息。 3.1.7.2 产品或其他相关服务的受托人。为向您提供产品或其他相关服务之必要，我们可能会将您的个人信息提供给支持本平台功能或相关业务的受托人，包括但不限于向您提供订单查询、订单支付、物流配送、售后服务、客户支持（如安装服务）、开票、与合作伙伴对账、支付机构调查回复、奖品发放等服务的受托人； 3.1.7.3 第三方合作方。为提供服务之必要，我们可能会将您的账号信息、联系方式、订单信息、必要的交易信息和交易纠纷信息共享给其他供应商和合作伙伴； 我们在引入合作伙伴之前会进行信息安全相关调查或确认，并通过合同约束要求合作伙伴采取严格的措施来保护您的个人信息。如有新增本政策所述提供产品或服务必要范围以外的其他合作伙伴，我们会在向该合作伙伴共享您的信息前另行征得您的同意。 3.2 转让 我们不会将处理/受托处理的个人信息转让给任何公司、组织和个人，但以下情况除外： 3.2.1 已征得您的明确同意； 3.2.2 在涉及合并、收购或破产清算时，如涉及到个人信息转让，我们会要求新的持有您的个人信息的公司、组织继续受此隐私保护政策的约束，否则我们将要求该公司、组织重新向您征求授权同意。如果不涉及个人信息转让，我们会对您进行充分告知，并将我们处理的个人信息进行删除或匿名化处理。 3.3 公开披露 我们不会将相关个人信息进行公开披露，但以下情况除外： 3.3.1 基于已征得您的明确同意或您的主动选择，我们可能会公开披露相关个人信息。 3.3.2 基于法律规定/要求的披露：在法律、法律程序、诉讼或政府主管部门强制性要求的情况下，我们可能会公开披露相关个人信息。 3.3.3 出于维护公共利益的目的，披露是合理且必须的，则我们可披露相关个人信息。 3.4 在以下情形中，我们共享、转让、公开披露相关个人信息无需事先征得您的授权同意： 3.4.1 基于与国家安全、国防安全相关的原因； 3.4.2 基于与公共安全、公共卫生、重大公共利益相关的原因； 3.4.3 基于与犯罪侦查、起诉、审判、和判决执行相关的原因； 3.4.4 出于维护用户或其他个人的生命、财产等重大合法权益但又很难征得您的同意的； 3.4.5 披露从合法公开的信息中收集的数据信息的，如合法的新闻报道、政府信息公开等渠道； 3.4.6 出于维护所提供产品或服务的安全稳定运行所必需，如发现、处置产品或服务的漏洞或故障问题。 四、信息存储地点和期限 4.1 我们在中华人民共和国境内处理/受托处理的数据信息将存储于中华人民共和国境内的服务器上，并将按照相关法律规定或与用户约定的期限（需满足为用户提供产品或服务的必要需求）存储。 4.2 若为了处理跨境业务，确需向境外机构传输境内处理的相关数据信息的，我们会另行向您告知并征得您的同意，并按照法律、行政法规和相关监管机构的规定执行。我们会确保相关个人信息得到足够的保护，例如对个人信息进行匿名化处理、采取安全加密措施存储和传输等。 4.3 您了解并同意，为了安全及备份的需要，我们可能将所处理的数据信息储存到关联公司的服务器上。 4.4 我们通常仅在为您提供服务期间保留您的信息，保存期限不会超过满足相关使用目的所必需的期限，但在下列情况下，且仅出于下列情况相关的目的，我们有可能需要较长时间保留您的全部或部分信息： 4.4.1 遵守适用的法律法规等有关规定。 4.4.2 遵守法院判决、裁定或其他法律程序的要求。 4.4.3 遵守相关行政、司法机关或其他有权机关的要求。 4.4.4 为执行本政策或其他相关协议的约定、或处理投诉/纠纷、或保护您或其他相关主体的人身和财产安全或合法权益所合理必需的。 五、我们如何保护个人信息的安全 5.1 我们非常重视您的信息安全。我们将努力采取各种技术（包括安全加密、防入侵、防病毒等）和管理方面的安全措施来保护您的个人信息，以防止您的个人信息遭到未经授权访问、使用、公开披露、修改、损坏或丢失。例如，我们会对本平台提供 HTTPS 协议安全浏览方式；我们会使用加密技术提高用户信息的安全性；我们会使用受信赖的保护机制防止用户信息遭到恶意攻击；此外，我们会建立用户信息安全管理制度及工作流程，对用户信息的访问进行严格的权限管控，对接触个人信息的工作人员进行权限限制及安全和隐私保护相关培训，并定期进行个人信息安全风险评估，及时处置相关风险问题，以便不断提升个人信息保护的安全能力。 5.2 尽管我们有责任保护您的个人信息，但您也有责任合理使用并妥善保管您的账号相关信息，因此请使用复杂程度高的密码，以便尽可能增强账号的安全性。如果您发现其他人未经您的许可使用您的帐号，您应立即向为您分配账号使用权限的人员反馈或联系我们协助您对该未经授权的使用行为进行制止。 5.3 如不幸发生信息安全事件（信息泄露、丢失等），我们将按照法律法规的要求，及时向您告知：安全事件的基本情况和可能的影响、我们已采取或将要采取的处置措施、您可自主防范和降低风险的建议、对您的补救措施等。我们将及时将事件相关情况以邮件、信函、电话、推送通知等方式告知您，难以逐一告知信息主体时，我们会采取合理、有效的方式发布公告。同时，我们还将按照监管部门要求，上报信息安全事件的处置情况。 5.4 我们会尽力保护您的个人信息，但任何措施都无法做到无懈可击，也没有任何服务或产品、网站、信息传输、计算机系统、网络连接是绝对安全的。如因我们的物理、技术或管理防护设施遭到破坏，导致信息被非授权访问、公开披露、篡改或毁坏，并导致您的合法权益受损，我们将承担相应的法律责任。但如因您将本平台或所使用的产品/服务账户密码告知他人、或违反本平台/产品/服务使用相关协议的约定、或使用不当/疏于防范等您自身原因、或因黑客攻击/病毒侵入等第三方原因、或不可抗力因素导致发生用户信息泄露/丢失等安全事件，您理解我们将无法承担任何直接或间接的损失或责任。 六、您如何访问和管理您的个人信息 6.1 您有权访问和管理您的个人信息。但如前列第1.3条所述，由于深信服为用户提供本平台及其他相关服务均致力于为实体用户提供更简单、更安全的助力业务开展和效益增长的解决方案，因此如您所代表的实体用户在授权您使用本平台时对您使用相关功能设置了相应的限制或审批程序，则您首先需按照该实体用户的要求执行。与此同时，您理解并同意：为保障您的账号安全及其他相关合法权益，不同的个人信息访问或管理请求可能需满足不同的前提条件（例如变更账号密码等基本信息需要进行身份验证）；且基于前述我们对收集及使用相关个人信息的目的的说明，您对个人信息的管理可能与您正常注册、使用产品或服务的需求产生冲突。因您自主行使对数据信息的管理权而导致产品或服务的使用障碍或遭受的损失，我们将无法承担责任。 6.2 在满足一定条件的情况下，本平台可为您提供如下管理个人信息的途径： 6.2.1 在您注册完成后，您可对账号信息进行修改或完善等。 6.2.2 您可注销本平台账号。当我们协助您注销账号后，我们将按照相关法律法规的要求保留您的相关信息；超出法定保存期限后，我们将依法删除或匿名化处理您的个人信息。 6.3 在以下情况下，您也可以向我们提出删除相关个人信息的要求： 6.3.1 我们处理/受托处理相关个人信息的行为违反相关法律法规。 6.3.2 我们主动收集、使用您的个人信息，却未征得您的明确同意。 6.3.3 我们处理/受托处理相关个人信息的行为严重违反相关协议约定。 6.4 响应您行使管理权的请求 6.4.1 对于您合理的请求，我们原则上不收取费用，但对多次重复、超出合理限度的请求，我们将视情况收取一定成本费用。对于无端重复、或需要过多技术投入（例如需开发新系统或从根本上改变现行惯例）、或可能给他人合法权益带来风险或者非常不切实际（例如涉及备份磁带上存放的信息）的请求，我们可能会予以拒绝。 6.4.2 为保障安全，您可能需要提供书面请求，或以其他方式证明您的身份。我们可能会先要求您验证自己的身份，然后再处理您的请求。 6.4.3 在以下情形中，我们将无法响应您的请求： 6.4.3.2 与国家安全、国防安全直接相关的； 6.4.3.3 与公共安全、公共卫生、重大公共利益直接相关的； 6.4.3.4 与刑事侦查、起诉、审判和执行判决等直接相关的； 6.4.3.5 有充分证据表明您存在主观恶意或滥用权利的； 6.4.3.6 出于维护个人生命、财产等重大合法权益而无法响应的； 6.4.3.7 响应您的请求将导致相关个人、组织的其他合法权益受到严重损害的； 6.4.3.8 涉及商业秘密的。 七、我们如何使用Cookie和同类技术 7.1 Cookie是访问网站时放置在您的计算机或移动设备上的小型数据文件。Cookie 的内容只能由创建它的服务器检索或读取。我们可能会通过Cookie记录和使用您的信息，但通过Cookie记录的信息仅在您所使用的设备本地保存，以及仅在您使用本平台相关功能/服务时使用。我们使用Cookie的具体用途包括： 7.1.1 记住您的身份，以便于您登录和完成验证，例如：Cookie有助于我们辨认您作为我们的注册用户的身份。 7.1.2 用于存储您的操作设置或偏好，以便您可获得更高效的使用体验。 7.1.3 统计并分析您使用我们平台的服务情况，以便为您提供更加周到的个性化服务，可能包括但不限定制化页面、内容推荐等。 7.2 其他类似的技术 除Cookie之外，我们可能会使用其他同类技术来自动收集信息。例如，我们可能会使用浏览器网络存储（包括通过HTML5），也称为本地存储对象，从而达到与Cookie类似的目的。 7.3 大部分网络浏览器都有设置阻止Cookie和清除浏览器网络存储的功能，您可根据自己的偏好进行管理或清除。但请注意，如果您设置阻止Cookie或其他同类技术的运行，您可能无法享受最佳的服务体验，某些功能的可用性也可能会受到影响。 八、未成年人保护 8.1 我们主要面向成年人提供本平台服务及其他相关产品。我们非常重视对未成年人个人信息的保护，如您为未成年人，我们要求您请您的父母或其他监护人仔细阅读本政策的所有内容，并在征得您的父母或其他监护人同意的前提下使用我们的产品或服务以及向我们提供信息。 8.2 对于收集经父母或其他监护人同意使用本平台的未成年人个人信息的情况，我们只会在法律规定允许、父母或其他监护人明确同意或者保护未成年人所必要的情况下处理此信息。 8.3 如果深信服发现自己在未事先获得可证实的父母或其他监护人同意的情况下，收集了未成年人的个人信息，则会设法尽快获取有效的授权同意或删除相关个人信息。 九、本政策的更新 我们可能会根据我们的产品或个人信息处理的变化情况不时修订更新本政策。如本政策的更新可能造成您在本政策下享有的权利的实质性减少，或涉及扩大我们收集并处理个人信息的范围等重要规则的变更，我们将通过在本平台页面显著位置发布公告或进行弹窗、或向您发送电子邮件或其他方式通知您查看更新后的声明。在前述情况下，若您继续使用我们的平台，即表示您已同意接受更新后的本政策内容。 十、如何联系我们 如您对本政策或服务使用相关其他事宜存有疑问、或有任何的意见或建议，您可通过电话0755-86725929或在线客服与深信服联系，我们将在接收到您提交的信息后尽快审核，并在明确您的需求后及时予以反馈。 附录：相关定义 本平台服务提供者：指深信服科技股份有限公司以及其他与提供本平台服务相关的关联公司，包括但不限于湖南深信服科技有限公司、长沙深信服信息科技有限公司、青岛市深信服职业技能培训学校有限责任公司。 实体用户：指已经或拟购买并使用、或试用深信服产品的客户，或与深信服合作开展业务的签约经销商或其他类型的合作伙伴，类型包括但不限于法人、政府机构、其他组织、合伙或个体工商户等。 认证用户：指通过注册或其他深信服允许的方式获得相应产品的账号/使用权限、并按照实体用户的授权/指示或基于实体用户的需求满足的目的使用产品功能的主体，该类型主体可能为实体用户内部相关管理人员，也可能为实体用户授权的其他人员。 非认证用户：指未注册账号或仅注册但未完成任何实体用户身份认证/绑定/关联、仅浏览产品相关信息或在限制范围内使用部分产品功能的主体。 用户：本协议实体用户与认证用户、非认证用户统称“用户”，也称“您”。 个人信息：是以电子或者其他方式记录的与已识别或者可识别的自然人有关的各种信息，不包括匿名化处理后的信息。 更新日期：2025年 7月16日 本协议是由用户（或“您”）与当前所用产品提供者共同签署的关于产品使用的协议。当前所用产品提供者指深信服科技股份有限公司以及其他与提供当前产品相关的关联公司，包括但不限于湖南深信服科技有限公司、长沙深信服信息科技有限公司、青岛市深信服职业技能培训学校有限责任公司，以下统称“深信服”或“我们”。 当您以认证用户的身份使用当前产品，本协议由您所代表的实体用户与深信服共同缔结。您作为实体用户签约的授权代表，按照实体用户的授权通过点击/勾选的方式确认签署本协议，本协议条款约定的具体权利义务将由您与您所代表的实体用户单独或共同承担。当您以非认证用户的身份使用当前产品，本协议由您与深信服共同缔结。您或您所代表的实体用户与深信服在下文中单独提及时可被称作一方，一同提及时可被称作双方。 请您务必审慎阅读、充分理解本协议全部条款内容，特别是免除或者限制深信服责任的条款、对您的权利进行限制的条款、约定争议解决方式和司法管辖的条款等，以及针对性或专用的协议或其他规则。限制、免责条款或者其他涉及您重大权益的条款会以加粗、加下划线等形式提示您重点注意。 除非您已充分阅读、完全理解并接受本协议所有条款，否则请您不要使用深信服提供的产品。您点击“同意”或“下一步”或类似的按钮、勾选框，或您直接使用深信服产品，或者通过下载安装使用以及账号/账号权限获取、登录等任何明示或者默示方式表示接受本协议的，均视为您已阅读并同意签署本协议，本协议即成为对双方均具有约束力的法律文件。 第一条 重要定义 1.1 产品：本协议“产品”为深信服提供的多种形态的解决方案的统称，包括但不限于软件产品、硬件产品、订阅服务、授权、其他相关服务或前述形态产品的组合，以及用于自身或与合作伙伴共同开展业务活动的相关系统、工具等。 1.2 实体用户：指已经或拟购买并使用、或试用深信服产品的客户，或与深信服合作开展业务的签约经销商或其他类型的合作伙伴，类型包括但不限于法人、政府机构、其他组织、合伙或个体工商户等。 1.3 认证用户：指通过注册或其他深信服允许的方式获得相应产品的账号/使用权限、并按照实体用户的授权/指示或基于实体用户的需求满足的目的使用产品功能的主体，该类型主体可能为实体用户内部员工或相关管理人员，也可能为实体用户授权的其他人员。 1.4 非认证用户：指未注册账号或仅注册但未完成任何实体用户身份认证/绑定/关联、仅浏览产品相关信息或在限制范围内使用部分产品功能的主体。 1.5 用户：本协议实体用户与认证用户、非认证用户统称“用户”，也称“您”。 1.6 用户数据：是指用户在注册深信服产品账户以及使用深信服产品的过程中，由用户主动填写、或在使用产品的过程中基于本协议（包括用户数据处理协议）约定而获取或采集的数据、以及由前述数据产生的其他相关数据。用户数据的类型可能既包含网络资产相关信息，也包含个人信息。 1.7 个人信息：是以电子或者其他方式记录的与已识别或者可识别的自然人有关的各种信息，不包括匿名化处理后的信息。 1.8 数据处理者：是指有权决定产品使用过程中涉及的用户数据的处理目的、方式等的组织或个人。一般而言，针对非认证用户的相关用户数据，深信服为数据处理者；针对认证用户按照实体用户授权/指示/需求使用相应产品时涉及的相关用户数据，处理者为本协议所指实体用户，深信服仅作为受托人，按照本协议的约定、实体用户的需求、认证用户的具体操作或其他形式的指令，对相关用户数据进行收集、存储、使用、加工、传输、提供、公开、删除等受托处理。 第二条 产品使用与限制 2.1 产品使用权利许可 2.1.1 许可声明：就深信服为用户提供的当前产品，深信服以及本协议条款及条件授予用户一项不可转让、不可转授权、非排他性、有限且可撤销的使用许可。除此之外，本协议条款及条件未明示授予用户的其他一切权利仍由深信服保留，深信服在本协议下不授予用户任何默示许可；用户在行使这些权利时须另外取得深信服的书面许可，且深信服如未行使前述任何权利，并不构成对该权利的放弃。 2.1.2 许可使用及维持：用户应在遵守本协议约定及其他相关规则限制的前提下使用产品。除非另有约定或说明，用户对本协议项下的产品仅限于非商业用途使用，用户承诺不对当前产品或其任何部分进行复制、拷贝、出售、转售或用于包括但不限于广告及任何其它商业目的。对于用户经合法、有效的授权许可使用的产品，深信服应按照所签署的合同、本协议或其他相关规则、以及用户的配置或其他形式的授权/指示为用户提供产品功能及相关服务，并在用户使用过程中尽可能提供全面的支持与保障。 2.2 产品使用规范和限制 深信服产品依据中华人民共和国（为本协议之目的，不包括香港、澳门和台湾地区，以下简称“中国”或“国家”）法律法规及政策要求开发，协议适用的产品为依据中国法律法规提供给中国境内的用户使用，深信服仅对在中国境内使用的产品提供相应的售后维护和技术支持服务。用户应当在遵守中国法律法规的前提下使用深信服的产品。 2.2.1 网络安全规范 在使用深信服产品期间，您承诺不自行或帮助/指使他人从事以下行为： 2.2.1.1 通过上传、公开发布或定向发送等方式传播可能干扰、破坏或限制任何计算机软件、硬件或通讯设备功能的软件病毒或其他计算机代码、程序或相关资料等； 2.2.1.2 通过技术手段非法侵入、破坏、干扰、改变或试图改变相关产品功能、软件、服务器系统、网络的运行或连接，或者修改、增加、删除、窃取、截留、替换承载产品运行的服务器系统中的数据，或者非法挤占产品运行之服务器空间，或者实施其他的使之超负荷运行的行为； 2.2.1.3 擅自通过扫描等方式挖掘/探测产品或服务器系统等可能存在的漏洞或缺陷，或违反相关法律规定发布漏洞或缺陷，或利用相关漏洞或缺陷从事损害相关产品及深信服的任何行为； 2.2.1.4 制作、发布、传播用于上述用途的软件、介质或方法等，无论相关行为是否出于商业目的。 2.2.2 信息内容规范 在使用深信服产品期间，您承诺遵守中国宪法法律，遵守公共秩序，尊重社会公德，不得制作、复制、发布、传播含有下列内容的信息，或者故意为制作、复制、发布、传播含有下列内容的信息提供技术支持或任何便利/帮助： 2.2.2.1 反对宪法所确定的基本原则的，或危害国家安全、荣誉和利益，泄露国家秘密，煽动颠覆国家政权，推翻社会主义制度，煽动分裂国家，破坏国家统一的； 2.2.2.2 宣扬恐怖主义、极端主义，或宣扬民族仇恨、民族歧视，破坏民族团结，煽动地域歧视、地域仇恨的，破坏国家宗教政策，宣扬邪教和封建迷信的； 2.2.2.3 编造、传播险情、疫情、警情、自然灾害、生产安全、食品药品等产品安全以及其他方面扰乱社会秩序的信息； 2.2.2.4 散布煽动非法集会、结社、游行、示威或者其他扰乱社会管理秩序、破坏社会稳定的信息； 2.2.2.5 编造、传播虚假信息，扰乱经济秩序和社会秩序、破坏社会稳定的； 2.2.2.6 传播淫秽色情、暴力、赌博、凶杀、恐怖的信息，以及教唆犯罪，传授犯罪手段、方法，制造或者交易违禁物品、管制物品，实施诈骗以及其他违法犯罪活动的信息； 2.2.2.7 危害网络安全、或利用网络从事危害国家安全、荣誉和利益或侵害他人合法权益的； 2.2.2.8 仿冒、假借国家机构、社会团体及其工作人员或者其他法人名义散布的信息，或者为实施违法犯罪而冒用他人名义散布的信息； 2.2.2.9 侮辱或者诽谤他人，侵害他人名誉、隐私、知识产权或者其他合法权益，以及危害未成年人身心健康，不利于未成年人健康成长的信息； 2.2.2.10 歪曲、丑化、亵渎、否定英雄烈士事迹和精神，以侮辱、诽谤或者其他方式侵害英雄烈士的姓名、肖像、名誉、荣誉的； 2.2.2.11 其他违反法律法规、公共政策、社会治安及公序良俗、或侵犯深信服、其他用户或第三方合法权益的信息内容。 用户应当对使用深信服产品期间涉及发布或通过任何方式传播的信息内容的合法性负责，深信服对于自行运营管理的平台/网站等产品，有权对用户使用相关功能/服务的过程中涉及的信息内容进行审核。如用户违反前述信息内容规范，深信服有权不经通知随时对相关内容进行删除或屏蔽，并视行为情节对违规账号进行功能使用限制、封禁、甚至注销，由此造成的全部后果及责任均由用户自行承担，并且深信服留存的系统日志或其他相关记录数据将有可能作为用户违反法律法规的证据。 2.2.3 其他行为规范：用户在使用相关产品的整个期间，应避免从事任何违反法律法规、社会主义制度、国家利益、公民合法利益、公共秩序、社会道德风尚和信息真实性的行为及其他违法违规行为，并不应从事任何侵犯其他用户或第三方合法权益、干扰深信服正常经营或产品/服务稳定运行、或其他深信服未明示授权的行为，且用户承诺将不对其他第三方从事前述行为提供任何便利或帮助。 第三条 产品使用费用 3.1 用户应当按照所签署的购销合同支付产品使用相关费用，在用户经合法、有效授权许可使用当前产品前提下，用户无需在签署本协议时单独支付费用，且用户理解并同意：深信服有权自主决定、以及按需调整用户可免费使用的产品功能或其他相关服务、以及免费使用期限或需满足的其他条件（深信服保留对任何未书面表明免费为用户提供的功能/服务收费的权利），并将仅在法律规定或深信服明确声明的范围内为用户提供相应的技术支持与保障。 3.2 用户理解并同意，任何产品的运维管理都需耗费一定成本，如用户超出深信服免费提供的产品功能或相关服务的范畴向深信服提出相关诉求（包括但不限于访问或导出相关使用数据），除确认该等诉求不违反相关法律规范或要求、未侵犯其他第三方主体之合法权益外，深信服有权自主评估用户诉求的合理性、以及响应用户诉求所需时限或其他必要条件，并有权要求用户自行承担满足其诉求所需的合理成本。 3.3 用户需注意：您应当自行支付使用产品时可能产生的上网费、流量费以及其他第三方收取的通讯费、信息费等。 第四条 用户声明与保证 4.1 合法经营保证 4.1.1 缔约双方均保证已经依照国家相关规定获得了合法经营资质或政府审批等，有权依法运营各自的产品或服务等业务。双方进一步保证，在本协议有效期内持续保持具备国家相关规定要求的经营资质或审批手续。深信服依约或根据您的授权向您提供各类产品，但不会参与您的业务或相关网站、应用、软件、平台的运营，您的网站、应用、软件、平台等、以及所从事的业务及相关内容，均由您自行运营并承担全部责任。 4.1.2 若您选择在中国境外使用深信服提供的产品，您应当自行评估产品使用是否满足您跨境使用的需求，包括但不限于是否符合当地法律法规、政策等的要求，尤其是有关数据跨境传输、跨境组网等的许可或批准要求；同时，也应当确保您所进行的经营或非经营活动、相关资质/许可、以及本协议的签署和履行相关全部行为等均符合当地法律法规、政策等的要求，并自行承担全部相关责任。 4.2 授权保证 如您属于使用相关产品的认证用户，您应保证您使用该产品的全部相关行为均已获得实体用户的合法、有效、充分的授权，并将自觉按照本协议约定、以及实体用户的制度规范、管理需求和真实意愿履行全部职责，包括但不限于遵守账号注册及使用相关规范、切实进行账号安全保护、规范使用产品功能、在整个使用过程中均注意保护所涉及的信息系统及数据安全等。与此同时，您同意相关实体用户有权基于经营管理、人力资源管理、或内部信息安全管控等需求，对您使用产品的行为以及相关数据和权益进行管理。除法律另有规定外，深信服不就实体用户与认证用户之间的授权行为、产品使用相关权限管控及相关权益处置行为，向实体用户或认证用户承担任何责任，且深信服有理由默认您依其权限所从事的行为均代表相应的实体用户，并有权在您怠于履行本协议约定的义务时要求您所代表的实体用户承担责任。 4.3 产品使用管理 基于用户需求，深信服可为用户提供多样化的产品功能配置及产品管理能力，但不对因用户账号管理/自主配置所导致的任何问题承担责任，包括但不限于以下情形： 多账号管理、委托管理/代运维：用户可按照自身管理需求自行设置产品管理方式及分配产品管理权限，并在产品管理平台进行相关接口或账号权限配置。用户需自行建立健全内部管理制度，规范对产品的使用与管理，如用户需授权委托外部第三方代为进行管理/维护或执行相关操作，须自行谨慎评估第三方的相关资质及能力、以及授权的权限范围，并自主对第三方进行监督、管理及考评等。用户须对产品使用相关的用户名、密码采取必要、有效的保密和安全保护措施。用户需自行对前述相关产品使用和管理方式的选择以及相应的配置和授权行为承担责任，为保障用户需求的满足，深信服将默认用户自行配置的所有账号或授权的第三方的相关操作行为均已获得所需的必要授权。 4.4 非正式销售类产品使用 您理解并同意：深信服可能在一定条件下向用户提供非正式销售类产品，供用户试用或测试，该类产品仅按“现状”和“当前可用”的形态提供，本协议中相关保证条款和正式销售时配套的SLA等规则均不适用于该类产品，且对该类产品深信服可能不会提供技术支持，我们也可能会在不另行通知的情况下随时更改或者停止提供产品试用或测试；对于其中尚未正式发布或发售的相关产品，深信服并无义务且不承诺正式发布或发售。用户应自行合理规划使用深信服提供的产品，不应将此类非正式销售的产品应用/运行在正式生产系统中或用于处理真实的业务数据，否则用户须自行承担相关风险和全部可能的后果，包括但不限于因深信服未提供保证的产品功能、性能、稳定性等问题或技术支持问题而导致的任何损失、产品终止提供后需切换使用并迁移相关业务及数据所带来的成本投入等。 4.5 第三方产品/服务 4.5.1 如因您所运营/管理的业务的特殊性，您使用产品需以第三方的授权或许可为前提，则您应保证已经满足该前提，深信服将基于您的前述保证接受您的委托为您提供本协议约定的产品或其他相关服务，且深信服对您所为的违背与第三方之间的约定、或侵犯第三方合法权益的行为不承担任何形式的连带责任。 4.5.2 您理解并认可深信服提供的产品及深信服均将保持与第三方产品或其他业务/内容的独立性，对于由第三方提供的软/硬件、插件、工具或发送的广告、推广或宣传信息（包括商业或非商业信息）等的合法性、可靠性、适用性或质量等问题，您应当自行判断并为自己的判断行为负责；除法律明确规定的外，对于您因第三方提供的产品/服务/信息内容而遭受的损失或损害，深信服概不承担任何责任。 4.5.3 本协议仅适用于当前产品使用相关事宜，不适用于任何其他第三方通过深信服产品提供的产品，您在选择使用第三方产品前，应充分了解并自行确认是否接受第三方产品适用的协议或规则。 第五条 深信服的义务履行 5.1 提供产品及相关服务 深信服应当依照本协议约定向您提供产品及售后服务。同时，为了向用户提供完善和优质的产品，深信服将定期或不定期地对产品本身或承载产品运行的相关基础设施/设备、系统、软件等进行检修、维护、升级及优化等（统称“常规维护”）。为保证产品的安全性和稳定性，深信服还可能进行机房/数据迁移、设备更换等重大调整。常规维护及重大调整可能导致产品使用在合理时间内中断或暂停，深信服将提前通知用户，用户应予以配合。若因不可抗力因素、基础运营商过错等原因导致须进行非常规维护，深信服将尽可能及时通知用户。深信服无需为此类服务的中断或暂停向用户承担违约或损害赔偿责任。 5.2 违规行为处置 用户同意并接受深信服有权对其使用相关产品功能及其他服务的情况进行持续的监督、审查。如深信服发现您存在任何违反本协议相关约定的行为，或接收到来自第三方机构或个人提出的关于您实施违法或侵权行为的质疑或投诉，深信服将有权对相关行为或信息内容进行查证或核实，以及根据具体情况采取相应的处置措施，包括但不限于立即中止/终止使用相关功能/服务、删除相应信息以及向有关部门报告等，并有权视必要情况要求您于限期内提交相关说明或证明材料，对此您同意将予以配合。因深信服在前述情形下采取相应措施而给您造成的损失，深信服不承担任何法律责任，同时深信服将保留追究您的法律责任以及向您索赔所遭受的全部损失的权利（包括但不限于因维权而产生的调查费、诉讼/仲裁费、律师费，以及因此所遭受的业务损失或索赔等）。 5.3 违法犯罪行为防范 与此同时，您应了解，如您所用的深信服产品通过任何方式被利用于实施诈骗（包括但不限于发送诈骗信息、接通远程控制以便实施诈骗相关操作等）、赌博、卖淫、非法放贷等违法犯罪行为，发生此类事件时，深信服将尽全力配合公安或其他监管机关调查取证、以及尽可能采取有利于减小损失的措施，但深信服作为产品提供方，无法预知或控制此类事件的发生，因此用户在使用产品及相关服务期间应时刻谨慎注意，防范可能利用产品从事的违法犯罪行为给自身带来的相应风险。 第六条 保密 6.1 定义 保密信息指由一方向另一方披露、但并不为公众所知悉、能为披露方带来经济利益或其他利益、具有实用性的所有技术及非技术信息(包括但不限于产品或服务的价格或营销方案等相关资料、业务规划及战略、客户名单及客户信息、财务信息、产品开发情况或相关技术方案等)。 6.2 保密义务 6.2.1 本协议任何一方同意对获悉的对方之上述保密信息予以保密，并严格限制接触上述保密信息的人员遵守本条之保密义务。除非国家机关依法强制要求或上述保密信息已经进入公有领域外，接收保密信息的一方不得对外披露。 6.2.2 本协议双方明确认可各自拥有的业务数据等信息是各自的重要资产及重点保密信息，并同意尽最大的努力保护上述保密信息等不被披露。一旦发现相关保密信息泄露的风险/隐患或事件，双方应合作采取一切合理措施避免产生或减轻损害后果。 6.3 保密义务的有效期 在产品使用期间，双方负有保密义务，双方另有约定的除外。 第七条 数据合规与隐私保护 7.1 用户使用当前产品涉及处理的数据具体情况，包括但不限于数据类型、处理目的及方式、以及数据安全保护等，将通过专门的《隐私保护政策》集中向用户进行说明。 7.2 深信服作为产品提供方，除了提供满足用户需求的产品外，还将致力于通过产品功能实现方式及相关交互设计帮助用户更好地落实数据安全及个人信息保护相关合规要求，从而更好地保障用户及相关个人主体的合法权益，但用户理解并同意，用户自身作为网络运营者/数据处理者，应履行数据合规及隐私保护的主体责任，并承担相应的法律后果。 第八条 知识产权 8.1 深信服作为为您提供的产品所包含的相关知识产权的权利人，依法享有相关著作权、商标权、专利权等知识产权以及商业秘密法律保护。知识产权是深信服业务赖以存续的宝贵的无形资产，既包含在用户使用的深信服产品之中，也包含在用户认准深信服的商标和标识等品牌形象中。深信服向用户承诺：用户通过合法授权的方式获取并在中国境内使用的产品，深信服均具备独立完整的知识产权，不存在任何侵害第三方知识产权的权利瑕疵情形。 8.2 与此同时，您理解并同意：在使用深信服的产品的过程中，不得以任何方式侵犯深信服所拥有的知识产权及其他合法权益，包括但不限于不得在未经深信服书面同意的情况下基于商业或者非商业的目的自行或许可任何第三方实施、许可、转让上述涉所及的知识产权，不得对深信服为您提供使用的软硬件产品和/或其中的任何部分进行复制、修改、反汇编、反编译、逆向破解、反向工程等操作，或者通过任何方式试图访问或者截取深信服产品中任何源代码，不得避开或破坏深信服为保护知识产权而采取的技术措施，不得擅自修改、破坏或掩盖深信服产品或相关系统平台上标注的商标或标识等。深信服保留依法追究任何侵犯知识产权的行为的法律责任的权利。 8.3 您理解并同意授权深信服在宣传和推广中使用相应实体用户的名称、商标、标识，但仅限于表明该实体用户属于我们的客户或合作伙伴。 第九条 责任限制 9.1 免责声明 您理解并同意，深信服为您提供的产品均是按照现有技术和条件所能达到的现状提供的。深信服将尽最大努力为您提供优质的产品，但由于受行业技术水平限制或其他客观因素影响，深信服无法保证所提供的产品毫无瑕疵或完全适用于您的业务需求。因此，除深信服在特定场景中向您作出明示保证的事项外，深信服对提供的产品所涉及的技术或信息等的有效性、完整性、准确性、可靠性、及时性等均不作承诺和保证，也无需承担任何责任。如用户在使用产品的过程中，出现超出双方承诺或认知范围的技术或其他方面的问题，双方可通过友好协作寻求共同解决。 9.2 不可抗力及其他免责情形 您理解并同意，在使用产品的过程中可能会遇到以下情况导致功能/服务发生中断。出现下述情况时，深信服将及时与相关单位配合进行修复，但对于由此导致您所遭受的损失深信服将无法承担： 9.2.1 受不可抗力因素影响，包括但不限于自然灾害、政府行为、法律法规颁布调整、罢工（任一方内部劳资纠纷除外）、动乱等不能预见、不能避免并不能克服的客观情况； 9.2.2 受基础运营商服务影响，包括但不限于电信部门技术调整、电信/电力线路被他人破坏、电信/电力部门对电信网络/电力资源进行安装、改造、维护等； 9.2.3 发生网络安全事故，如计算机病毒、木马或其他恶意程序、黑客攻击等； 9.2.4 您通过非深信服允许的方式使用相关产品功能或服务，或因您操作不当、账号丢失或被盗，或您的电脑软件、系统、硬件和通信线路出现故障等原因而导致的功能或服务无法正常使用； 9.2.5 其他非深信服过错、且深信服无法控制或合理预见的情形。 9.3 责任除外 不论在何种情况下，深信服均不对任何间接性、惩戒性、突发/偶然性、特殊性的损害后果承担责任，前述损害后果的类型包括但不限于利润损失、利息损失、营业中止、数据或其他资产毁损灭失等。 9.4 责任限制 深信服基于为您提供的产品违反所适用的协议条款或其他相关规则而应承担的违约或损失赔偿责任总额不超过提供相应产品所收取的费用总额。 第十条 协议期限、中止与终止 10.1 本协议在终止前或根据当前产品使用期限到期前有效（如适用）。用户理解并同意，深信服通过本协议条款或其他方式与用户约定的产品全部或部分功能使用中止或终止条件成就时，深信服有权以发送单方通知的方式中止或终止为用户提供本协议约定的部分或全部产品功能使用许可： 本条所指的中止条件包括但不限于：因用户拒绝同意本协议或其他相关规则更新、或用户在许可使用期限截止后未及时续费、或因用户违反本协议约定的各项义务等其他用户自身原因而导致暂时无法使用产品功能； 本条所指的终止条件包括但不限于：因用户未及时续费超过一定期间、或因用户违反本协议约定义务而导致不满足使用产品的必要条件、或因用户违反法律规定而给深信服带来实际损害。 10.2 深信服有权根据自身运营安排，随时调整或终止相关产品的部分或全部功能（包括但不限于对相关功能进行下线、迭代、整合等），而无需事先通知，产品的任何变更均受当时有效的协议条款约束。对于可能影响用户业务的相关产品，深信服将尽可能提前通知用户，以便用户做好数据转移备份或业务调整等相关准备工作，尽可能避免产生不必要的成本或损失。 第十一条 适用法律与争议解决地 本协议签订地为深信服所在地。协议的成立、生效、履行、解释及纠纷解决等相关事宜，均适用中华人民共和国法律（不包括法律适用法，为本协议之目的，不包含香港、澳门和台湾地区）；如无相关法律规定的，则可参照适用商业实践惯例。若您和深信服之间发生任何纠纷或争议，首先应友好协商解决；协商不成的，您同意将纠纷或争议提交协议签订地有管辖权的人民法院管辖。 第十二条 附则 12.1 关系 深信服和用户是独立的缔约方，本协议并不构成合伙、代理或雇佣等法律关系。任何一方或其关联公司都不是另一方的代理人，无权约束另一方的行为。 12.2 权利义务的转移 未经深信服事前的书面同意，您不得转让或以其他方式转移本协议或本协议下的任何权利和义务。任何违反本条的转让或转移都是无效的。请您理解并同意深信服有权在提前通知您的前提下将本协议的权利义务全部或者部分转移给深信服的关联公司。 12.3 协议的完整性 本协议正文、附件、援引的政策和文件以及与本协议相关的其他政策、规则、声明、通知、警示、提示、说明（本协议中统称“规则”）等，构成您与我们就当前产品达成的完整协议。前述所有类型的规则均为本协议不可分割的组成部分，与本协议具有同等法律效力。 12.4 不构成放弃权利声明 如深信服于您过失或违约时放弃本协议规定的权利，不应视为其对您的其他或以后同类之过失或违约行为弃权。 12.5 可分割性 本协议内容无论因何种原因部分无效或不可执行，均不影响其余部分的法律效力。 12.6 协议更新 基于互联网络的实时性、复杂性、高效性等特性以及法律规范/监管要求/政策调整、用户/深信服双方业务或经营等发生重大变化、产品功能迭代更新等原因，您同意深信服可以不时对本协议正文、附件或相关规则进行更新，变更后的协议或规则将通过本产品界面重新提交给用户确认，或另行通过本协议所载的有效通知方式通知您。如您不同意协议的相关变更，则应当立即停止使用相关产品；如您继续使用，即表示您已充分阅读、理解并同意接受经修订更新后的协议。 12.7 通知 12.7.1 联系方式的真实有效性 您应当保证和维持使用相关产品期间所提交的相关资料（包括但不限于电话号码、电子邮箱等联系方式）的真实有效性，如您提交的相关资料存在虚假、无效等任何可能导致您无法及时获悉业务通知、功能/服务提示、技术支持、纠纷协调、违规处罚等信息的，由您自行承担相应责任。 12.7.2 有效通知方式 您应当根据本协议或深信服官方网站公布的联系方式向深信服发送通知，双方另有约定除外。 深信服可通过网页公告、系统通知、站内信、电子邮件、手机短信、即时通讯工具、函件等方式中的一种或多种向您发送与产品/服务有关的通知、提示、验证消息、营销信息等各种信息（包括但不限于更新后的用户协议、相关规则、产品/服务升级、机房裁撤、广告等）。前述信息在发送或公布之日视为已送达（如果送达时间为法定节假日的，则以送达后首个工作日为送达日）。 12.7.3 推送授权 为更好地向您交付所需产品或提供与产品使用配套的其他相关服务，对于您申请或开通使用（包含试用）产品或具体功能时主动提供的手机号码及电子邮箱等联系方式，您同意深信服在您使用期间向您发送短信或邮件推送产品使用的实时情况信息或与之相关的产品发布/更新信息，深信服会为您提供退订途径，或者您也可以主动联系深信服的客服人员为您解决相关问题。 12.8 出口管制合规 用户承诺遵守中国、美国、欧盟等国家和地区可适用的出口管制及经济制裁法律法规，包括但不限于： 12.8.1 不将深信服产品和/或服务转卖至适用法律法规禁止或限制的任何国家或地区； 12.8.2 不将深信服产品和/或服务用于核武器、燃料生产或推进系统、导弹、火箭或无人驾驶飞机系统、生化武器等最终用途； 12.8.3 不将深信服产品和/或服务用于最终军事用途。 12.9 标题 本协议所有条款的标题仅为内容概述，目的在于方便阅读，标题本身不能单独作为本协议条款内容解释的依据。 12.10 语言 本协议以中文书就，如有其他语言仅作为参考，不同语言版本间如有冲突，以中文版为准。 12.11 冲突适用 如本协议条款与您所使用的具体产品功能/服务所适用的专有协议或规则的有关约定不一致时，以专有协议或规则的约定为准；如本协议条款与您在具体项目中与深信服或深信服授权经销商签署的采购合同条款相冲突，将以本协议约定为准。 12.12 联系方式 用户在使用相关产品的过程中，可按照不同需求通过如下客服热线电话或发送电子邮件至support@sangfor.com.cn或在线技术支持与深信服的客服人员联系，以获取产品使用相关技术支持或进行权益保障方面的咨询： 售前咨询：4008066868 深信服技术支持/售后（服务期内）/投诉/举报：4006306430 附件一： 账号使用协议 本协议为深信服社区平台“用户协议”的附件之一，在用户勾选或通过其他方式确认“用户协议”并开始使用社区平台提供的相关服务时即已生效，成为对用户在深信服社区注册和使用账号的相关行为具备约束力的法律文件。 第一条 账号注册 1.1 任何使用深信服产品的用户依法均应具备必要、适当的权利能力和行为能力，并按照实名认证等要求完成注册或通过其他深信服允许的方式获得产品相关账号的使用权，以及应在账号注册时自觉遵守相关规范及限制，包括但不限于不得恶意注册使用产品账号（本条所指恶意注册行为包括但不限于频繁注册、批量注册账号、滥用多个账号、买卖账号等行为）。深信服有权对不同类型用户账号的注册设置相应的认证要求、以及对账号权限进行分配，并可按需对权限设计进行变更或调整。 1.2基于深信服主营业务及产品的定位和功能，我们将主要面向已成年用户提供账号注册和相关功能/服务，任何主体在指示/授权未成年人注册相关产品账号或通过其他任何方式使用产品前，应负责取得其监护人的同意、并通过身份证号码核验其授权的未成年人及其监护人的真实身份，以及应在整个使用期间均注重对该未成年用户的个人信息等合法权益予以特殊保护。 第二条 用户资料 2.1 用户应当按照要求填写、提交真实、合法、有效的资料，包括但不限于用户名称、联系人、电子邮箱、联系电话，且您同意按照深信服的要求提交您所代表的实体用户相关资料，包括但不限于营业执照、资质许可文件、业务相关说明等资料，以便深信服自行或委托第三方按照相关法律法规的要求对相关主体的身份进行实名认证，或在必要时用于核实相关主体利用深信服提供的产品或其他相关服务所开展的业务的真实性、合法性。如前述资料发生变更的，您应及时书面通知深信服或根据具体产品的使用规则自行进行更新。 2.2 用户应保证其注册的账号名称、设置的头像和简介等信息中均不会出现任何违反法律规范、公共政策、社会治安及公序良俗、或侵犯任何第三方合法权益的信息内容，包括但不限于：不得假冒、仿冒捏造政党、党政军机关、企事业单位、人民团体和社会组织、国家（地区）、国际组织、新闻媒体的名称或标识、以及重要空间的地理名称、标识等；不得冒充他人（包括但不限于管理员）身份或擅自使用他人的姓名、肖像或商标/标识；不得故意夹带二维码、网址、邮箱、联系方式等；不得含有名不副实、夸大其词等可能使公众受骗或者产生误解的内容等。 第三条 账号使用行为规范 用户在登录产品账号并使用相关功能/服务期间应自觉承担账号主体相关的法律义务，包括但不限于不得通过账号登录等方式利用任何产品功能实施违反法律法规或政策要求的行为，不得通过任何技术手段干扰深信服产品运行或深信服对产品的运营管理、或恶意绕开或者对抗相关功能/服务的规则、或突破账号的权限或其他使用限制，不得发布或通过任何方式传播违法违规或虚假的信息内容或发布广告，不得通过刷帖/注水/虚假打赏等方式干扰其他用户对产品的正常使用或通过其他任何方式侵害他人的合法权益等。 第四条 账号安全保护 4.1 账号将作为用户使用对应产品的身份识别依据，您应当对账号名称、密码等信息及账号的安全性采取必要、有效的保护措施（包括但不限于进行有效的权限控制、设置高强度密码并定期更换等）。 4.2 如您发现有他人盗用您的账号及密码、或任何其他未经您合法授权即获取您的账号使用权限的情形时，您应立即以有效方式通知深信服并提供必要资料（如情况说明、证明材料、具体诉求及联系方式等）。深信服收到您的有效通知并核实身份、确认事实情况后，会依据法律法规及协议/规则的约定进行处理。深信服依据本条进行处理产生的相关责任和后果由您承担。若您提供的资料存在瑕疵，导致深信服因无法核实您的身份或无法判断您的需求而未能及时处理，由此导致您遭受损失应由您自行承担。同时，您理解，深信服对您的请求进行处理需要合理期限，对于深信服采取措施前您已经遭受的损失以及采取措施后因不可归责于深信服的原因导致的损失，深信服不承担任何责任。 第五条 账号管理 5.1 除对账号的安全保护外，您还应建立健全内部管理制度，规范对账号的使用管理。如任何用户实际违反了本协议或其他相关规则或约定，您有义务立即通知我们，同时应采取适当的行动来制止并纠正相关违规/违约行为，并负责承担全部相关责任。 5.2 您理解并同意：深信服作为产品的运营方，将有权依据相关法律规定或本协议及其他相关约定，在任何用户存在违反本协议或其他相关规则/约定的行为或发生账号权限相关的纠纷时，采取包括但不限于限制、暂停或终止访问/使用相应产品或其他相关服务等必要措施，以便尽可能确保产品的安全、有效运行，如由此导致用户使用相关产品的数据被清空或丢失等损失，用户应自行负责承担；且深信服有权自主评估建立用户账号的信用管理体系，并按照用户账号使用期间的信用评价情况为用户提供服务或其他相关权益保障。 第六条 账号权限限制及终止 6.1 账号注销 为便于更系统、高效地满足用户使用深信服产品的需求，本平台账号已与深信服其他产品的用户身份认证体系关联，因此为免影响用户使用其他产品，如需注销本社区平台账号，您需通过用户协议中第十条提供的联系方式联系社区管理员提供协助。如您作为认证用户，您所代表的实体用户在授权您使用相关产品时设置了相应的限制或审批程序的，则您需自行确保已事先经内部审批或确认，深信服不对用户自主要求注销社区账号而导致其他产品使用受限或所产生的其他任何不利影响承担损害赔偿责任。除前述以外，任何账号注销还需满足以下条件： 6.1.1 账号处于正常状态，不涉及任何争议纠纷（包括投诉举报或被投诉举报），且未被有权机关采取限制措施； 6.1.2 账号内无未完成的交易； 6.1.3 账号内不存在其他未了结的权利义务或可能因注销账号而产生纠纷的情况； 6.1.4 无其他可能影响账号注销的情况。 深信服将停止为已正式注销账号的用户提供相应的产品功能及其他相关服务。账号注销后，我们将根据相关法律法规的要求以及与您或您所代表的实体用户的相关约定（如有）对相关数据进行妥善处理。 6.2 为了保护用户账号安全，深信服有权对访问异常的行为进行独立检测判断并采取相应处理措施。例如，对于注册后长期不登录或登录后长期无任何访问或操作记录的账号，为保护用户账号安全，深信服有权限制其登录功能，用户需重新激活账号或重新登录后才能正常使用。 6.3 在用户违反本协议相关约定或其他双方约定的账号使用许可权限中止或终止条件成就时，深信服有权收回或终止对您所用账号的使用许可。 附件二： 社区发帖规范 本协议为深信服社区平台“用户协议”的附件之一，在用户勾选或通过其他方式确认“用户协议”并开始使用社区平台提供的相关服务时即已生效，成为对用户在深信服社区发表或传播信息内容的相关行为具备约束力的法律文件。 深信服倡导用户发布符合当代社会主流价值观的内容，鼓励真诚地表达、专业地讨论、友善地互动，严格禁止一切违法违规行为，反对任何违法或不良信息内容的的发布或传播。为与用户共同维护良好的社区环境，特此约定社区发帖行为规范，用户在深信服社区平台通过任何方式发布或传播信息内容，均须遵守本规范要求。 第一条 遵守法律规范 在使用深信服社区服务期间，用户承诺遵守中国宪法法律、遵守公共秩序、尊重社会公德，不得制作、复制、发布、传播含有下列内容的信息，或者故意为制作、复制、发布、传播含有下列内容的信息提供技术支持或任何便利/帮助： 1.1 反对宪法所确定的基本原则的，或危害国家安全、荣誉和利益，泄露国家秘密，煽动颠覆国家政权，推翻社会主义制度，煽动分裂国家，破坏国家统一的； 1.2 宣扬恐怖主义、极端主义，或宣扬民族仇恨、民族歧视，破坏民族团结，煽动地域歧视、地域仇恨的，破坏国家宗教政策，宣扬邪教和封建迷信的； 1.3 编造、传播险情、疫情、警情、自然灾害、生产安全、食品药品等产品安全以及其他方面扰乱社会秩序的信息； 1.4 散布煽动非法集会、结社、游行、示威或者其他扰乱社会管理秩序、破坏社会稳定的信息； 1.5 编造、传播虚假信息，扰乱经济秩序和社会秩序、破坏社会稳定的； 1.6 传播淫秽色情、暴力、赌博、凶杀、恐怖的信息，以及教唆犯罪，传授犯罪手段、方法，制造/交易违禁物品、管制物品、或涉及违禁活动（如传销、胎儿性别鉴定等），实施诈骗以及其他违法犯罪活动的信息； 1.7 危害网络安全、或利用网络从事危害国家安全、荣誉和利益或侵害他人合法权益的； 1.8 仿冒、假借国家机构、社会团体及其工作人员或者其他法人名义散布的信息，或者为实施违法犯罪而冒用他人名义散布的信息； 1.9 歪曲、丑化、亵渎、否定英雄烈士事迹和精神，以侮辱、诽谤或者其他方式侵害英雄烈士的姓名、肖像、名誉、荣誉的； 1.10 侮辱或者诽谤他人，侵害他人姓名、肖像、名誉、隐私、知识产权或者其他合法权益的信息； 1.11 其他违反法律法规、公共政策、社会治安及公序良俗、或侵犯深信服、其他用户或第三方合法权益的信息内容。 第二条 保护未成年人合法权益 深信服倡导用户共同承担保护未成年人合法权益的社会责任。用户在深信服社区通过发帖或评论等方式发布或传播的信息内容不得包含任何危害未成年人身心健康的相关内容，包括但不限于： 2.1 涉及未成年人色情低俗的，如展示未成年人婚育、性侵害等； 2.2 涉及未成年人暴力欺凌的，如施暴犯罪、残害体罚、校园欺凌等； 2.3 涉及披露未成年人隐私的，如展示未成年人性器官，公开个人隐私等； 2.4 涉及未成年人不良行为的，如宗教传授、饮酒吸烟、邪典动画等； 2.5 涉及规避未成年人系统监管的，如故意规避防沉迷、青少年模式的方法攻略； 2.6 其他危害未成年人安全和健康的相关内容。 第三条 抵制一切色情低俗内容 禁止发布、传播的信息包括但不限于： 3.1 直接暴露和描写人体性部位的内容； 3.2 表现或隐晦表现性行为、具有挑逗性或者侮辱性的内容； 3.3 以带有性暗示、性挑逗的语言描述性行为、性过程、性方式的内容； 3.4 全身或者隐私部位未着衣物，仅用肢体掩盖隐私部位的内容； 3.5 带有侵犯个人隐私性质的走光、偷拍、漏点等内容； 3.6 以庸俗和挑逗性标题吸引点击的内容； 3.7 相关部门禁止传播的色情和有伤社会风化的文字、音视频内容，包括一些电影的删节片段； 3.8 传播一夜情、换妻、性虐待等的有害信息； 3.9 情色动漫、小说； 3.10 非法的性药品广告和性病治疗广告等相关内容； 3.11 推介淫秽色情网站和网上低俗信息的链接、图片、文字等内容。 第四条 禁止违法违规发布广告 深信服社区内禁止用户擅自发布商业广告，尤其不得违法违规发布广告，包括但不限于： 4.1 利用党旗、党徽、国旗、国徽、国歌等代表党和国家形象的标识及内容，或英雄烈士的姓名和肖像，或者借国家重大活动、重大纪念日和国家机关及其工作人员名义等开展商业营销活动； 4.2 发布通过恶搞经典、恶俗营销、歪曲历史，制造噱头、吸引眼球，挑战公序良俗，伤害中国人民和中华民族感情进行商业营销宣传的内容； 4.3 发布带有任何有联系方式的网络创业、网络兼职、奢侈品高仿代购、刷Q币、买卖加V认证以及非真实性中奖信息； 4.4 内容包含带有任何联系方式的学历职称代办、专业代做试题、作业、论文等题目以及售卖考试答案等信息； 4.5 发布任何带有联系方式的银行卡代办、买卖发票、非法彩票等信息； 4.6 含有联系方式的黑客、收费删帖、办证刻章等违法信息； 4.7 非官方认证的发布任何带有联系方式的医院、美容、药品、祛斑、医生专家和整容等信息； 4.8 具有明显导流性质的外站链接、下载链接、活动二维码等； 4.9 发布集资内容及外链、通过隐蔽形式进行集资应援，如“无实物交易”“不运回”“售卖周边”等），引导用户进行集资活动。 第五条 维护社区良好氛围 深信服社区鼓励互相尊重、真诚分享、友好互动，禁止一切攻击性、侮辱性的语言和其他破坏社区氛围的内容与行为，包括但不限于： 5.1 不友善行为 辱骂攻击：内容中包含脏话、粗俗词汇、蔑称、污言秽语等不文明用语； 歧视恶搞：涉及带有歧视、恶搞或侮辱的内容。如对性别、种族、地域、身份、人群等发表带有侮辱、歧视等言论； 情绪宣泄：涉及带有偏激情绪宣泄的内容。如使用粗俗不堪的口头禅、低俗、猥亵、龌龊等语言词汇或网络用语等发泄情绪的言论； 恶意贴标签：用具有贬损性质的词汇对他人进行定义； 故意抬杠：发表无建设性、无逻辑或带有攻击性的驳斥言论； 阴阳怪气：发布包括挖苦、讥讽、含沙射影的内容； 恶意骚扰：使用单个或多个账号，持续通过@、私信、想法、评论等功能对他人进行骚扰，或对他人发布包含性暗示、性引诱等冒犯性内容； 5.2 引战、钓鱼或煽动对立等行为 发布引起个人或群体之间的对立、冲突的内容，包括但不限于： 挑动和诱导群体或用户之间的对立和冲突、拉踩引战； 发表极端男女权、宣扬对某一性别的歧视、仇恨、挑唆性别对立等言论； 发表涉及民族、种族、宗教、性取向、年龄、地域、生理特征等身份或者归类歧视的内容； 5.3 其他影响氛围的行为 带节奏或鼓动、煽动他人做出跟风不理智的行为； 通过各种途径进行对平台的攻击、贬损等宣泄行为，影响其他用户的社区体验； 除以上内容和行为外，其他任何可能会破坏社区氛围、影响用户使用体验的行为，均属于深信服社区禁止和不鼓励的行为。 第六条 其他禁止或不鼓励的内容和行为 6.1 传播不良价值观：包括传播不良社会风气、恶搞优秀传统文化等的； 6.2 发布不实信息：包括发布存在事实性错误的信息，欺骗、误导他人，或胡编乱造虚假或引人误解的背景、情节，欺骗、误导他人，或发布未经权威学术期刊及机构等学术界收悉或认可的学术突破、科学发现等爆料，以及无可信来源的新闻资讯或社会事件的相关信息等； 6.3 发布危害他人人身、财产安全的内容：包括发布求医问药、医疗建议等可能会对求助者造成误导，甚至延误病情的内容，或发布包含具体理财建议、募捐或网络乞讨等可能影响个人财产安全的内容，或发布包含易引发他人模仿的危险行为的内容等； 6.4 发布影响阅读体验的低劣质内容：包括发布征求作业答案、招聘、调查问卷等个人任务类问题，发布他人难以理解、语言逻辑混乱等表意不明的内容，或发布与问题无关的答非所问内容，发布无明确意义的灌水内容或重复发布大量相同内容，在标题、封面等位置发布刻意夸张、故设悬念，进行诱导转发、骗取用户点击的内容等； 6.5 其他：如滥用产品功能，违背功能设计初衷，造成不良影响的内容或行为。 第七条 违规处置 用户理解并同意，深信服社区有权对用户的使用行为进行监督及审查。若用户的使用行为违反本规范或用户协议中其他约定、或违反国家法律法规及政策要求，本社区在经由监督检查或接收投诉、举报、接到权利通知书等途径发现不当行为时有权做出独立判断，并有权在无需事先通知用户的情况下直接采取一切必要的措施，包括但不限于： 7.1 对相关信息内容进行处置，如直接删除、或断开链接、屏蔽、或限制展示范围等； 7.2 对用户使用社区相关功能进行限制，如限制发布内容、限制访问、限制登录等； 7.3 对用户账号进行处罚，如回收相关权益、扣除积分等； 7.4 对用户账号进行回收、封禁、甚至永久纳入黑名单等； 7.5 如涉嫌违反相关法律法规，社区将按照相关规定向有关部门报告。 -->

网站标题

深信服社区-专业、开放、共享

关键词

专业,开放,共享

站点描述

深信服社区致力于为用户数字化转型提供开放共享的技术生态圈。提供技术博文、技术论坛、技术圈子等产品与服务，聚合海量行业专家分享、最佳实践、经验心得，在这里您可以与超过50万同行者共同拥抱数字化转型浪潮。