1. 项目概述当AI遇见网络设备基线检查干了十几年网络运维最头疼的活儿之一就是“基线检查”。每次安全审计、等保测评或者就是日常巡检都得把几十上百台交换机、路由器、防火墙的配置捞出来一条条对着安全基线标准去核对。什么密码复杂度、SNMP社区名是不是public、没用的服务关没关、ACL策略对不对……这活儿枯燥、耗时、还容易看走眼。一个疏忽可能就是安全漏洞。现在情况不一样了。最近在折腾一个项目核心就是把AI的能力灌到网络设备基线检查这个传统得不能再传统的领域里。简单说就是做一个工具它内置了一个专业的“安全配置知识库”我们叫它基线库能自动登录你的网络设备批量抓取配置然后用AI去理解、分析这些配置文本判断它是否符合安全规范最后还能一键生成带详细问题和整改建议的报告。这玩意儿听起来像不像给网络运维上了个“自动驾驶”它解决的痛点非常明确效率和准确性。人工一天可能只能查十几台设备还难免遗漏AI工具可以并发检查成百上千台7x24小时不知疲倦而且基于规则和模型的分析一致性极高。尤其对于拥有大量分支网点、设备型号繁杂的企业价值巨大。从最近的热词也能看出来大家一方面在关注具体的网络设备管理像Nornir和Ansible的比较、Zabbix监控另一方面又在疯狂寻找能提效的AI工具各种Kimi、DeepSeek、AI编码工具。我们这个项目正好站在了这两个趋势的交汇点用AI赋能传统网络运维自动化。所以无论你是疲于应付各种安全检查的网工还是负责整个IT基础设施安全的工程师或者是想了解AI如何落地到具体运维场景的技术管理者下面这份从思路到实操的完整复盘或许能给你带来一些实实在在的参考。2. 核心设计思路为什么是“AI基线库”做这个工具不是凭空想象。它的设计思路源于对传统基线检查流程的深度解构和痛点分析。2.1 传统流程的“三座大山”在没有自动化工具之前一次全面的基线检查流程大致如下收集配置通过SSH/Telnet登录每台设备手动执行show running-config或等命令将配置保存为文本文件。人工解析与核对工程师打开这些文本文件用肉眼或者简单的文本搜索CtrlF去查找关键配置项比如找enable secret看密码是否加密找snmp-server community看是否用了弱口令。记录与报告将发现的问题记录在Excel或Word里手动编写整改建议形成报告。这个过程存在几个致命问题效率极低设备数量与耗时呈线性甚至指数增长。容易出错人眼会疲劳复杂的配置逻辑如ACL、路由策略容易误判。标准不一致不同工程师对同一条基线的理解可能有偏差检查结果因人而异。知识传承难资深工程师的经验比如某种特定型号设备的特殊配置语法很难固化下来新手上手门槛高。2.2 我们的解决方案架构为了搬走这“三座大山”我们设计的工具核心架构围绕三个关键部分展开1. 专业基线库规则引擎的核心这是工具的“大脑”。它不是简单的文本列表而是一个结构化的、可扩展的规则库。每条基线规则至少包含规则ID与描述唯一标识和人类可读的说明。适用设备类型Cisco IOS/IOS-XE, Huawei VRP, H3C Comware, Juniper Junos等。配置检查路径告诉程序去配置的哪个部分查找如system / snmp / community。合规判断逻辑这是关键。可能是简单的字符串匹配如检测是否存在service password-encryption也可能是复杂的正则表达式如检查密码复杂度甚至是需要联系上下文的状态判断如ACL是否被正确应用到了接口上。风险等级与整改建议明确标识出高风险、中风险、低风险并给出具体的、可操作的配置命令作为整改建议。这个基线库的构建需要融合国际标准如CIS Benchmarks、行业最佳实践、企业自身安全策略以及资深工程师的实战经验。它是工具专业性的根本保证。2. AI增强的解析与理解层效率与智能的飞跃这是传统自动化脚本和智能工具的分水岭。我们引入AI目前主要是自然语言处理NLP和机器学习ML不是为了炫技而是为了解决纯规则匹配解决不了的问题非标准化配置的识别不同工程师写的配置描述description千差万别AI可以理解“连接核心交换机”和“link-to-core-sw”描述的是同一个接口。配置意图推断检查一条ACL是否真正起到了访问控制作用不仅看ACL是否存在还要看它是否被应用在了正确的接口和方向in/out上。这需要理解配置片段之间的关联。自然语言查询与报告生成未来可以支持“检查所有核心设备的BGP邻居认证配置”这样的自然语言指令并自动生成人类可读的、有重点摘要的检查报告。这是将AI作为“副驾驶”的典型应用。3. 自动化执行与报告平台落地输出的手脚这是工具的“躯体”。它需要多协议支持通过SSH主流、NETCONF更现代、API等方式与设备通信。批量作业引擎能够并发管理数百台设备的登录、配置抓取、命令执行。结果聚合与可视化将每台设备的检查结果进行聚合以仪表盘形式展示整体合规率、风险分布。一键报告生成自动生成结构化的报告Word/PDF/HTML包含问题列表、风险等级、受影响设备、确切的配置片段和具体的整改命令。这个设计思路的核心在于用结构化的基线库保证检查的准确性和专业性用AI去处理模糊的、需要理解的复杂场景以提升智能化水平再用强大的自动化引擎将这一切高效落地。它不是要完全取代工程师而是将工程师从重复、低效的劳动中解放出来去处理更复杂的架构设计和应急响应。3. 构建专业基线库从零到一的实战基线库是工具的基石。一个粗糙的基线库会导致工具要么漏报该查的没查出来要么误报合规的配置被误判为问题最终失去信任。我们构建基线库的过程是一个严谨的“采集-抽象-实现-测试”循环。3.1 基线规则的来源与抽象规则不是拍脑袋想出来的主要来源于四个层面国际安全基准如互联网安全中心CIS针对Cisco IOS、NX-OS等发布的Benchmarks。这是行业公认的起点权威性高。监管与行业要求例如等级保护2.0中对网络设备的具体要求金融、电信等行业监管机构的指引。厂商安全加固指南思科、华为、华三等设备厂商官方发布的安全配置白皮书或加固指南他们对自家设备最了解。企业内部安全策略与运维经验这是最具价值的部分。比如公司规定所有管理接口必须使用特定的访问控制列表ACLMGMT-ACL或者某次安全事件后总结出的特定漏洞配置检查规则。采集到这些文本要求后关键一步是进行“工程化抽象”将一条文本要求转化为程序可执行的规则。例如文本要求“应启用密码加密服务避免密码明文存储。”抽象为规则设备类型Cisco IOS检查命令show running-config | include service password-encryption合规判断如果输出中包含service password-encryption则合规否则不合规。整改建议全局配置模式下执行service password-encryption。文本要求“SNMP社区名不应使用默认或弱口令如‘public’、‘private’。”抽象为规则设备类型Cisco IOS, Huawei VRP检查命令show running-config | include snmp-server community(Cisco) /display current-configuration | include snmp-agent community(Huawei)合规判断使用正则表达式匹配检查社区名字符串是否过于简单长度8仅为常见单词等或直接是否为public/private。整改建议删除弱社区名使用snmp-server community [复杂字符串] RO/RW [ACL]格式配置强社区名并关联访问控制。3.2 规则的结构化存储与实现我们采用YAML或JSON格式来存储这些结构化规则因为它既人类可读也便于程序解析。下面是一个简化版的规则示例YAML格式- rule_id: NET-CISCO-001 title: 启用密码加密服务 description: 检查是否启用服务密码加密防止密码在配置中明文显示。 device_vendor: [Cisco] device_os: [IOS, IOS-XE] check_type: command_include check_command: show running-config | include service password-encryption compliant_condition: output contains service password-encryption risk_level: medium remediation: | 请在全局配置模式下执行 configure terminal service password-encryption end reference: CIS Cisco IOS Benchmark v3.0 - 1.1.1对于更复杂的规则比如检查ACL应用情况check_type可能是config_parse我们需要编写更复杂的解析函数或者利用AI模型来理解配置块之间的关系。实操心得规则版本管理基线库必须是活的。安全威胁在变设备软件版本在升级规则也需要迭代。我们使用Git来管理基线库每个规则文件的修改都有记录。可以建立stable稳定、beta测试、dev开发分支。新的规则或对现有规则的修改先在dev分支编写在测试环境中验证后合并到beta经过一段时间的线上试运行无误再合并到stable。这确保了生产环境使用的规则是经过充分测试的。3.3 多厂商设备的适配挑战与技巧网络设备厂商众多命令行语法各异这是基线检查工具必须跨越的鸿沟。1. 建立设备指纹库工具首先要能识别设备类型。可以通过自动登录后执行show versionCisco、display versionHuawei等命令解析回显信息中的厂商、操作系统版本、型号等形成设备指纹。根据指纹决定调用哪一套规则和命令模板。2. 抽象命令层不要为每个厂商写死命令。应该建立一个“抽象命令层”。例如定义一个抽象操作“获取当前配置”背后对应Cisco:show running-configHuawei:display current-configurationJuniper:show configuration | display set在规则定义中我们引用这个抽象操作而不是具体命令。这样增加对新厂商的支持时主要工作就是扩展这个抽象映射层。3. 处理配置回显格式差异不同厂商配置回显的格式、缩进、注释方式都不同。在解析配置寻找特定配置项时需要编写厂商特定的解析器Parser。例如解析接口IP地址Cisco:ip address 192.168.1.1 255.255.255.0Huawei:ip address 192.168.1.1 255.255.255.0Juniper:family inet { address 192.168.1.1/24; }我们的解析器需要能理解这些语法差异准确提取出关键信息IP地址和掩码。4. 利用NETCONF/YANG模型进阶对于支持NETCONF的设备这是更优雅的解决方案。NETCONF使用YANG数据模型来定义配置和状态数据获取的是结构化的XML或JSON数据完全避免了命令行回显解析的麻烦。你可以直接通过XPath或JSON Path定位到具体的配置节点进行检查精度和可靠性大大提升。在构建工具时应优先考虑对NETCONF的支持。避坑指南特权模式与分页批量登录设备时两个最常见的“坑”特权模式Enable模式很多查看命令需要在特权模式下执行。自动化脚本需要处理从用户模式到特权模式#的切换并自动输入enable密码。这里要注意密码错误、特权等级不足等异常情况的处理。终端分页show running-config这类长输出默认会分页暂停--More--。必须在发送命令时禁用分页例如Cisco下先执行terminal length 0华为下执行screen-length 0 temporary。否则脚本会卡住等待输入。4. AI如何赋能超越简单的字符串匹配如果工具只做字符串匹配那它只是一个高级的grep脚本。AI的引入是为了解决那些规则难以精确描述、需要一定“理解”能力的场景。4.1 自然语言处理NLP在配置解析中的应用配置文件中大量存在人类可读的“描述”description和“注释”remark。这些信息对于理解配置意图至关重要但又是非结构化的。场景一智能关联接口与安全域假设基线要求“所有连接外部网络的接口必须应用严格的外部访问控制列表ACL”。如何自动识别哪些接口是“连接外部网络”的传统方法依赖工程师手动维护一个“外部接口”列表或者通过接口名称如包含outside、internet来模糊匹配。不准确维护成本高。AI增强方法收集设备上所有接口的配置包括接口名如GigabitEthernet0/1、描述如description Link-to-ISP-A、IP地址、已应用的ACL等。使用预训练的NLP模型如BERT的变体或针对网络文本微调的模型对接口描述进行语义分析。模型可以学习到Link-to-ISP、Uplink-to-Core、DMZ-Server等描述词与“外部”、“核心”、“隔离区”等安全概念的关联。工具自动标注出高概率为“外部接口”的列表供工程师确认或直接作为检查对象。这大大缩小了需要重点审查的范围。场景二理解ACL条目的业务意图一条ACL条目access-list 101 permit tcp any host 10.1.1.100 eq 80。传统规则只能检查语法是否正确、是否存在。但AI可以尝试推断其业务意图“允许任何IP访问10.1.1.100的HTTP服务”。结合其他信息如10.1.1.100是一台Web服务器AI可以进一步判断这条规则是否过于宽松any源地址并与“最小权限原则”的基线要求进行比对给出“建议将源地址any缩小为特定的业务网段”的优化建议。4.2 机器学习ML用于异常检测与风险预测这是更具前瞻性的应用。通过持续收集网络设备的配置快照和相应的安全事件日志可以训练机器学习模型。应用一配置漂移异常检测即使初始配置是合规的在日常运维中配置可能会被意外修改配置漂移。我们可以训练一个无监督学习模型如孤立森林、自动编码器学习每个设备在正常状态下的配置特征。当工具定期抓取配置后模型会计算当前配置与“正常模式”的偏差度。如果偏差度超过阈值即使它没有违反任何一条具体的基线规则工具也会发出告警“设备A的配置发生了异常变更建议复核”。这能发现那些尚未被写入基线库的新型风险或误操作。应用二风险关联与预测将基线检查结果如发现10台设备SNMP配置弱口令、漏洞扫描结果这些设备存在某个可通过SNMP利用的漏洞、以及网络拓扑信息这些设备处于核心区域进行关联分析。一个简单的规则引擎可以做到初级关联但ML模型可以挖掘更深层次的风险模式。例如模型可能发现“当核心交换机同时存在弱SNMP社区名和未关闭的Telnet服务时未来30天内遭受入侵尝试的概率上升70%”。工具可以据此给出更高优先级的整改建议。注意事项AI不是银弹在当前阶段AI在网络配置分析中主要起辅助和增强作用而非完全替代规则引擎。可解释性AI模型尤其是深度学习的决策过程常被视为“黑盒”。在安全领域我们必须能解释“为什么判定这条配置不合规”。因此我们的架构是“规则为主AI为辅”。AI发现疑似问题后需要关联到某条具体的、可解释的基线规则或者以“提示”的形式供工程师决策而不是直接下结论。数据与训练好的ML模型需要大量高质量的标注数据即“配置片段-合规标签”对。初期数据不足时模型效果可能不如精心编写的规则。可以从简单的任务如接口描述分类开始积累数据。计算成本复杂的NLP/ML模型推理需要一定的计算资源。对于实时性要求不高的基线检查通常是定时任务这可以接受。但架构上应考虑将AI分析模块与轻量级的规则检查模块分离允许用户选择启用或禁用AI功能。5. 工具链选型与自动化引擎搭建有了清晰的思路和规则我们需要选择合适的技术栈来构建这个自动化引擎。这里没有唯一答案但我们的选型基于社区活跃度、对网络设备的支持、以及与AI集成的便利性。5.1 核心自动化框架选型Nornir vs. Ansible这是两个最流行的网络自动化框架我们的工具需要集成其中一个作为执行引擎。Ansible声明式入门快优点使用YAML编写Playbook语法直观易于理解和分享。有庞大的社区和丰富的网络设备模块ios_command,junos_command,netconf_config等开箱即用。非常适合实现标准化的、流程固定的操作比如我们的基线检查登录-执行检查命令-收集输出。缺点对于需要复杂逻辑处理、流程控制比如根据上一命令的结果动态决定下一个命令的场景YAML会变得冗长和难以维护。性能上Ansible默认是顺序执行虽然支持异步但配置稍复杂在检查成百上千台设备时可能需要借助像ansible-pull或者结合AWX/Tower来提升并发能力。Nornir命令式灵活强大优点一个纯Python框架你可以用完整的Python代码来控制一切。并发处理通过线程或异步天生强大且易于控制。数据处理和转换非常灵活可以轻松地将设备输出送入Python的解析库如TextFSM, Genie Parser或你自己的AI模型。它更像一个“网络自动化SDK”适合构建复杂的、定制化的运维平台比如我们的AI检查工具。缺点需要编写Python代码学习曲线比Ansible陡峭。需要自己管理设备清单Inventory和连接插件虽然也很灵活。我们的选择Nornir对于这个项目我们选择了Nornir。核心原因是我们需要深度定制化要集成自己的基线规则解析器、要调用AI模型接口、要对检查结果进行复杂的关联分析、要生成特定格式的报告。这些用PythonNornir来实现比用Ansible Playbook和Jinja2模板要直接和高效得多。Nornir的并发模型也让我们能轻松实现数百台设备的并行检查显著缩短整体作业时间。5.2 配置解析利器TextFSM与Genie从设备回显的文本中准确提取结构化数据是网络自动化的关键一步。我们不再用脆弱的字符串切割而是用专业的解析器。TextFSM来自Google是什么一个基于模板的文本解析工具。你需要为每种命令的输出编写一个模板文件.textfsm定义如何将文本行映射到变量。优点轻量级模板相对容易编写社区有很多现成的模板比如在ntc-templates项目中。示例解析show interface status命令提取接口名、状态、VLAN等信息。Genie来自Cisco但部分解析器开源是什么Cisco开发的一套更强大的自动化框架其Genie Parser非常出色。它不仅能解析还能将配置和状态信息转化为Python对象模型方便以面向对象的方式操作。优点解析能力更强对Cisco设备支持极好能处理更复杂的命令输出和配置。与PyATS另一个Cisco测试框架集成紧密。缺点对非Cisco设备的官方支持有限。我们的策略混合使用对于Cisco设备我们优先使用Genie Parser因为它更稳健、功能更丰富。对于华为、华三等其他厂商我们使用TextFSM并自己维护和编写关键的解析模板。我们也鼓励社区贡献模板逐步完善多厂商支持。5.3 一个简化的核心执行流程示例下面用一段简化的伪代码展示工具核心引擎的工作流程这有助于理解各个组件如何协同# 伪代码展示核心逻辑 from nornir import InitNornir from nornir_netmiko import netmiko_send_command from my_baseline_library import load_rules, check_compliance from my_ai_module import analyze_config_intent from report_generator import generate_html_report def baseline_audit_task(task, baseline_rules): 针对单个设备的检查任务 results [] # 1. 根据设备类型从task.host获取过滤出适用的基线规则 device_rules filter_rules_for_device(baseline_rules, task.host.platform) for rule in device_rules: # 2. 使用Nornir发送检查命令 command rule[check_command] output task.run(netmiko_send_command, command_stringcommand).result # 3. 使用解析器TextFSM/Genie或简单匹配进行合规判断 is_compliant, details check_compliance(output, rule) # 4. 可选调用AI模块进行深度分析 if not is_compliant and rule.get(needs_ai_review): ai_insight analyze_config_intent(output, task.host.get_config()) details[ai_analysis] ai_insight # 5. 记录结果 results.append({ rule_id: rule[id], compliant: is_compliant, details: details, remediation: rule[remediation] }) task.host[audit_results] results # 主程序 if __name__ __main__: # 初始化Nornir加载inventory文件包含所有设备信息 nr InitNornir(config_fileconfig.yaml) # 加载基线规则库 all_rules load_rules(baselines/) # 并发执行审计任务 audit_results nr.run(taskbaseline_audit_task, baseline_rulesall_rules) # 聚合所有设备结果 all_results aggregate_results(audit_results) # 生成报告 generate_html_report(all_results, audit_report_20231027.html) # 发送邮件或上传到CMDB/工单系统 send_notification(all_results)这个流程清晰地展示了从设备连接、规则匹配、合规判断到结果汇总的自动化闭环。6. 报告生成与集成让结果驱动行动检查出问题不是终点推动整改才是。一份清晰、 actionable可操作的报告至关重要。6.1 报告内容设计我们的报告不是简单的“通过/不通过”列表而是一个决策支持文档。一份完整的报告通常包括执行摘要一页纸说清楚。总体合规率、高风险问题数量、受影响最严重的设备TOP 5、本次检查的核心发现。详细发现列表这是报告主体。以表格形式呈现每行包含规则ID/标题唯一标识和问题描述。风险等级高红色、中黄色、低蓝色。合规状态通过/未通过。受影响设备列出所有不符合该规则的设备主机名/IP。不合规配置示例直接摘录设备上相关的配置片段让读者一目了然。整改建议这是核心价值。提供具体的、可复制粘贴的配置命令。例如“请在全局配置模式下执行no snmp-server community public RO”。参考依据链接到CIS Benchmark或内部安全策略条款增加权威性。设备视角视图除了按问题分类也提供按设备分类的视图。可以快速查看某一台设备的所有合规项和不合规项方便设备负责人针对性整改。历史趋势图如果工具定期运行可以展示整体合规率随时间的变化趋势直观反映安全状况是在改善还是恶化。6.2 报告形式与自动化推送形式支持HTML用于网页查看交互性好、PDF用于归档和正式提交、Word/Excel方便某些部门进一步编辑。自动化推送邮件通知检查完成后自动将报告摘要和PDF附件发送给相关运维团队、安全团队负责人。集成工单系统如Jira, ServiceNow对于高风险问题可以自动创建整改工单并分配给相应的设备负责人跟踪整改进度。推送至CMDB或仪表盘将合规率等关键指标推送到公司的统一监控仪表盘如Grafana实现安全态势的可视化。6.3 与现有运维体系的集成工具不应该是一个信息孤岛。我们设计了几个关键的集成点与CMDB集成从CMDB自动同步设备清单IP、型号、管理账号、所属业务部门等确保检查对象是最新的。同时将检查结果如最后检查时间、合规状态写回CMDB丰富资产的安全属性。与漏洞管理VM平台集成将基线检查发现的配置漏洞转化为漏洞管理平台中的“安全配置项”类漏洞纳入统一的漏洞生命周期进行管理、跟踪和考核。与自动化配置管理工具集成这是实现“闭环”的关键。对于简单的、低风险的整改项如统一开启某项服务工具生成的整改命令可以直接被Ansible Tower或SaltStack等配置管理工具调用在审批后自动执行实现“检查-发现-修复”的自动化。实操心得分阶段推行与人性化设计工具上线初期切忌“一刀切”和强硬问责。“只读”观察期前1-2个月工具只进行检查和报告不创建工单不纳入考核。让各团队熟悉报告格式了解自身问题自行整改。报告语气以“建议”、“发现”为主。试点与沟通选择1-2个配合度高的团队作为试点共同验证检查结果的准确性和整改建议的有效性优化规则库。逐步纳入考核待工具稳定、规则准确后将关键基线项的合规率逐步纳入团队或个人的KPI。报告开始创建低优先级的工单。高风险项紧急流程对于发现的极高风险项如发现默认密码工具应能触发即时告警如短信、即时消息并自动创建高优先级工单启动应急响应流程。这种分阶段、人性化的推行策略能极大减少阻力让工具真正被团队接受和使用。7. 部署模式与持续运营思考这样一个工具如何交付给用户使用是做成一个本地部署的软件还是SaaS服务我们的考虑如下。7.1 部署模式选择本地部署On-Premises优点所有数据设备配置、检查结果都留在客户内网安全性最高符合金融、政府等强监管行业的要求。可以深度集成客户内部的CMDB、堡垒机、4A系统。缺点需要客户准备服务器资源负责工具的安装、升级和维护。初期部署成本较高。适用场景中大型企业、对数据安全有严格要求的机构。SaaS服务云服务优点开箱即用无需维护基础设施自动升级。通常按设备数量或扫描次数订阅付费初始成本低。挑战需要解决云服务如何安全访问客户内网设备的问题。通常需要客户在内网部署一个轻量的“采集器”Agent或网关由采集器执行命令并将结果加密上传到云端分析。网络隔离如防火墙策略需要客户配合开通。适用场景中小企业、拥有多个隔离网络但希望通过统一平台管理的大型企业每个网络部署一个采集器。我们的工具设计支持两种模式。核心的检查引擎、规则库、AI模块是通用的。区别在于任务调度、结果存储和报告生成的模块。SaaS模式会增加多租户管理、计费、采集器管理等功能。7.2 持续运营规则库与AI模型的迭代工具上线只是开始持续的运营才能保证其长期价值。规则库的持续更新订阅服务对于CIS等商业基准可以提供订阅更新服务。社区贡献建立用户社区鼓励用户贡献针对特定设备型号或场景的检查规则。内部反馈闭环在报告或工单系统中加入“规则反馈”按钮。如果工程师认为某条检查结果是误报或漏报可以提交反馈由规则维护团队审核后更新规则库。AI模型的持续训练在用户授权且脱敏的前提下收集匿名化的配置样本和工程师对AI分析结果的修正反馈例如AI误判了某个接口的性质工程师进行了纠正。利用这些反馈数据定期重新训练NLP模型使其越来越准。可以建立“人机协作”模式AI先给出初步分析和建议工程师确认或修正修正后的结果反过来训练AI。性能优化与扩展增量检查对于大型网络每次全量抓取配置可能耗时较长。可以探索增量检查只检查上次检查后发生变更的配置部分。支持更多设备类型随着客户需求不断扩展对新兴网络设备如SDN控制器、云原生网络组件的支持。与CI/CD管道集成在网络配置变更自动化的流程中将基线检查作为一道“门禁”Gate。任何通过自动化工具如Ansible, Terraform下发的新配置在生效前先通过基线检查工具的预检不合规的配置自动被拒绝实现“安全左移”。构建和运营这样一个“网络设备基线检查AI工具”是一个将传统安全运维经验、现代软件工程方法和人工智能技术相结合的过程。它始于一个简单的需求——把网工从繁琐的重复劳动中解放出来最终成长为一个能够持续保障网络基础设施安全配置状态的智能运营平台。这条路没有终点随着技术发展和威胁演变工具也需要不断进化。但可以肯定的是自动化与智能化是网络运维和安全管理的必然方向。
