NetDevOps漫谈：构建基于可视化编排的网络自动化系统

引言在上一篇文章中从“脚本小子”到“乐高玩家”聊聊我的Python网络自动化巡检心得核心就俩字解耦和大家分享了我在传统网络自动化运维过程中遇到的一些痛点问题并思考如何通过高内聚、低耦合的思想将复杂的网络业务解构并封装为一个个“原子积木”。 这篇文章将继续在上一篇的基础上围绕以下两个核心转变来探讨基于可视化编排的网络自动化从“黑箱脚本”到“原子能力” 摒弃针对具体数通网络业务如“检查BGP邻居状态”的过程脚本堆砌改为通过构建抽象的、可复用的“原子”操作来实现将“做什么”业务逻辑与“怎么做”底层实现解耦。从“过程驱动”到“数据驱动” 理解所有数通网络自动化业务行为的本质是数据的管道化处理Data Pipeline采集数据CLI/API-处理数据解析数据、数据操作-决策对各种元数据的运算-行动。而编排系统就是可视化地构建这条管道。网络原子能力分类 │ ├── 【数据采集】从哪里拿数据 │ ├── 从设备获取SSH/Telnet │ ├── 从系统获取API/数据库 │ └── 从用户获取表单输入 │ ├── 【数据转换与处理】数据如何加工转换为可用形式 │ ├── 文本解析TextFSM/正则表达式 │ ├── 模板渲染jinja2 │ └── 变量操作变量构造/变量聚合 │ ├── 【流程控制】控制原子执行的逻辑流 │ ├── 条件分支 │ ├── 循环控制 │ └── 等待延迟 │ ├── 【对数据决策】数据意味着什么将业务逻辑去业务化抽象为元数据运算 │ ├── 元数据运算字符串运算/整数运算/字典运算/列表运算 │ └── 智能分析让AI大模型对数据进行分析决策 │ └── 【输出行动类】接下来做什么 ├── **系统交互** │ ├── 与设备交互 (向设备推送命令) │ └── 调用外部系统 (CMDB更新、标记工单) │ └── **通知与报告** ├── 告警生成 (邮件、钉钉、短信) ├── 报告生成 (HTML, Markdown, Excel) └── 数据存储 (数据库、数据湖、文件)一、核心理念为什么需要可视化编排1.1 从“写代码”到“画流程”的范式转移传统网络自动化的最大痛点是什么不是技术实现难而是环节衔接难迭代升级难知识传递难在脚本交付前期传统网络自动化往往需要网络工程师提供业务目标及业务流程图开发工程师根据业务流程图开发代码最后再交付给网络工程师实施使用。这个传递过程可能存在信息失真、技术壁垒等实际问题。 而相比前期后期维护阶段困难更加突出。 想象一下这个场景一位网络工程师协同开发人员花了一个月写了一个复杂的网络自动化巡检脚本刚开始脚本运行得很好后面问题来了他要休假了临时需要另一位工程师维护这个脚本网络架构调整了脚本需要适配新的网络架构及设备类型合规要求变了检查规则需要更新结果往往是接手的工程师看着几千行代码头大最后甚至不如“重写一遍”。这就是传统脚本化自动化的死循环。可视化编排要解决的正是这个“知识黑盒”问题。通过把自动化逻辑从“代码”转换成“流程图”我们实现了知识可视化业务流程一目了然不再是隐藏在代码中的秘密协作标准化不同角色架构师、网络工程师、开发工程师能在同一张图上讨论维护可持续即使原开发人员离职新人也能够快速理解并修改1.2 低代码/零代码的价值把编码工作从“每个人都要做、每次都要做”变成“专业的人做一次其他人重复用”。这个转变价值在于专业分工原子能力开发者专注于把原子积木做到极致将包罗万象的业务逻辑抽象为几个标准的原子积木业务流程编排师专注于业务逻辑设计用现成的积木搭建解决方案二、系统架构全景分层解耦的协同体系一个健壮的可视化编排系统绝非简单的绘图工具其背后是一套分层清晰、职责明确、协同工作的架构体系。 一般来说可划分为五个核心逻辑层其交互关系可参照下图2.1 前端展示层前端展示层是用户与系统交互的入口根据用户意图的不同主要呈现两种界面编排设计器 (设计态)核心使命提供“所见即所得”的可视化画布。用户通过从能力库中拖拽原子节点、图形化连线、配置属性表单完成对工作流模板的新建、编辑与存储。其最终产出是一个结构化的流程描述文件如JSON定义了“如何做”的蓝图。技术实现通常基于React、Vue等现代Web框架结合GoJS、G6等专业图形库。数据交互该界面通过后端的API网关持续协同后端从数据管理层的“元数据库”和“变量上下文”来进行下游节点对上游节点变更的引用或处理。执行监控器 (运行态)核心使命提供全局、实时的可观测性。当用户触发一个工作流模板后系统生成一个工作流实例。监控器负责全景式展示该实例的生命周期具体包括全局执行态势清晰展示工作流整体进度与最终状态成功、失败、执行中、暂停。节点状态拓扑图动态高亮每个原子节点的实时状态并可视化节点间的数据流向。对于条件分支等节点会明确标记出本次实例实际执行的路径。深度钻取分析允许用户点击任一节点查看其完整的执行信息快照包括输入参数、结构化输出结果以及排错所需的详细执行日志。时间线与审计追踪以时间轴形式呈现实例的关键生命周期事件并与所有相关的用户操作审计日志关联。数据交互该界面通过后端的API网关持续从数据管理层的“运行时数据库”和“审计日志库”中拉取或订阅数据实现信息的动态、实时更新。2.2 核心引擎层核心引擎层是系统的“中枢神经系统”负责将静态的流程蓝图转化为动态的执行过程是自动化流程演出的“导演”。它的核心职责不是亲自上台表演而是确保正确的演员原子在正确的时间上场道具数据在演员间正确传递观众用户能实时了解演出进度核心组件工作流引擎是核心。它负责接收并解析流程模板创建对应的运行时实例并将其转化为内部的有向无环图DAG模型进行精细化调度。技术实现可以独立开发也可以参考使用Airflow、prefect等开源工作流引擎。关键机制状态机驱动为整个流程及每个节点实现一套精细的状态机如Pending、Running、Success、Failed、Retrying这是处理异步、超时、自动重试、复杂回滚等场景的理论基础。上下文管理与数据传递维护实例级别的执行上下文例如10台交换机运行了同一个工作流但是每个交换机可能各有各的差异所以每一台交换机都是一个单独实例确保上游节点的输出能作为参数安全、准确地注入到下游节点。这部分数据是执行监控器中“数据流向”可视化的源头。与数据的交互引擎将每一个状态变更、每一次上下文传递的结果都作为“运行时数据”实时持久化这是整个系统具备可观测性的数据基石。2.3 能力供给层此层是系统的“肌肉组织”封装了所有具体的操作能力是连接抽象流程与物理世界的桥梁。原子能力是系统可调用的最小、功能内聚、可复用的执行单元。原子能力库是所有能力的注册中心、调度中心和版本管理中心。原子能力的设计哲学抽象与实例的辩证统一设计原子能力需深刻理解软件工程中“抽象”与“封装”的思想。 类比面向对象编程原子模板如同“类”定义了一个纯粹的、无业务属性的抽象行为契约如“通过协议获取数据”、“解析文本”、“执行布尔判断”而用户在画布上配置并使用的每一个节点则是该类的“对象实例”通过具体的参数目标IP、CLI命令、解析规则被赋予实际的业务含义。因此首要设计原则是“去业务化”与“高内聚”。应坚决摒弃如“获取BGP邻居状态”这类与具体场景强绑定的“伪原子”。 真正的原子应回归本质数据获取、数据处理转换/解析、数据运算判断/决策。 通过将抽象行为封装为标准API并由前端表单收集参数实现“一个抽象能力通过参数注入实例化衍生无限业务操作”的最终目的。原子能力的设计直接关系到编排系统对于自动化运维生产客观上好不好用、能不用长期用对于业务人员在主观上愿不愿意用。 我在工作中已深刻体验过原子能力设计缺陷的自动化编排系统所存在的天然短板这种编排系统的原子本质还是一个个的“黑箱代码”所谓编排无非是把一个大的黑箱代码变成了多个零散的黑箱代码拼接 所以在构建和运营流程上和传统过程脚本无异依然需要开发和业务协同 在知识沉淀和复用上几乎为零例如检查设备软件版本是否和准入标准一致 与 检查设备BGP router-id是否和loopback0接口地址一致这两个业务需求本应该由相同的原子构成(采集-解析-运算), 而要在这类系统下实现则最终变成了独立构建不同的业务节点这类原子叫做“节点”可能更加准确来完成同一个业务单元内部尚且如此交付、巡检、变更、告警、风险自愈等自动化单元之间就更加难以沉淀复用了最终可能会出现原本十几个高质量原子可以搞定所有业务需求变成了成千上万个质量层次不齐的臃肿节点库。与数据的交互原子能力执行时除返回结果给引擎外必须将详尽的执行日志写入审计库这些日志是事后问题排查与节点详情分析的唯一依据。2.4 数据管理层保障可靠性与可观测性的基石此层的核心价值在于为其他各层提供坚实的数据支撑是运维经验资产化的核心确保自动化运行透明、可追溯、可分析。核心存储与职责元数据库存储工作流模板、原子能力定义等“设计态”元数据。保障流程定义的一致性、版本化与安全复用。运行时数据库存储工作流实例、节点实例的实时状态、上下文变量等“运行态”核心快照数据。这是执行监控器展示全局与节点状态、数据流向的直接来源。审计日志库存储每一次执行的详细日志、节点输入输出快照、用户操作记录。用于深度排错、合规审计并在执行监控器中提供节点级详情钻取。2.5 基础设施层弹性、安全的承载平台此层为应用提供通用的技术支撑能力保障系统的稳定、安全。核心组件API网关作为系统统一的南北向流量入口处理所有前端请求路由至后端微服务并统一实施认证、鉴权、限流与监控。权限与多租户服务实现基于角色和属性的精细化访问控制确保多团队在共享平台时数据、流程和资源的严格隔离与安全。高可用与弹性架构通过容器化Docker与编排Kubernetes技术实现服务的快速部署、水平扩展和故障自愈。三、数据持久化与知识沉淀构筑核心数字资产在可视化编排系统中数据不仅是运行时状态更是可复用、可分析、可传承的组织核心数字资产。3.1 数据持久化存储元数据存储流程模板、原子能力定义等结构化元数据适合使用关系型数据库。确保数据的强一致性、复杂关联查询能力与事务支持例如快速检索所有引用某原子能力的流程。运行时实例与审计存储实例记录、节点状态、详细日志等时序性、海量数据采用“关系库专用存储”的混合模式。核心状态存于关系库便于管理详细日志与大型结果文件存入对象存储实现高性能检索与低成本长期归档。3.2 变量生命周期与上下文管理数据是工作流的“血液”节点执行本质由数据驱动执行所以变量管理必须清晰、安全核心风险数据依赖、级联失效流程A→B→C如果节点B使用了节点A的输出变量那么它就依赖于节点A。 当节点A被删除时其输出的变量失效这种依赖关系被破坏如多米诺骨牌一样导致后续引用了该变量的节点全部坍塌。解决思路数据依赖/级联失效检查流程A→B→C实际上构成一个有向无环图DAG。当删除一个节点时必须触发级联失效检查检查并处理所有依赖它的节点如有依赖可通过删除时提示先解除依赖或自动清理失效变量的引用等办法避免悬空引用。作用域与生命周期变量应与其生产者节点绑定生命周期明确作用域全局变量系统级常量或配置生命周期与系统一致。流程实例变量某次特定执行的上下文随实例创建而诞生结束而消亡。节点局部变量单次节点执行中的临时中间产物对其它节点不可见。3.3 版本管理与知识演进将流程与能力视作可版本化的代码是实现知识沉淀与平滑演进的关键。流程模板版本化任何对流程的修改都生成新版本历史版本完整保留。支持一键回滚、差异对比并确保正在运行的实例不受后续修改影响。原子能力契约化每个原子能力定义明确的输入/输出接口“契约”和版本号。系统应能管理能力依赖预警不兼容调用保障编排的长期稳定性。知识库的构建基于版本化的资产自然形成一个不断丰富的自动化知识库。业务人员可像在代码仓库中搜索最佳实践一样快速查找和复用“核心交换机升级”、“业务链路切换”等场景化模板。3.4 审计追踪全面的审计能力是系统在严格监管行业落地的基石。全链路审计系统必须记录“谁Who、在何时When、从何处Where、执行了哪个流程What、使用了哪些参数、产生了什么结果Result”。实现完整的可追溯性。四、展望从“手动编排”到“自主优化”未来的网络编排系统一定会向着更智能、更主动、更自治的方向演进。演进路径手动编排用户完全控制流程设计当前阶段智能推荐系统基于历史数据推荐节点和流程自动生成用户描述需求系统自动组织编排流程自主优化系统监控执行效果自动优化流程4.1 基于编排流程的智能化基于历史流程、网络架构数据AI充当“副驾驶”。业务人员用自然语言描述意图如帮我检查核心交换机XX状态如果异常则通过XX方式进行变更修复系统能自动推荐并组织生成可执行的编排草图。4.2 基于对数据决策的智能化由人制定对静态数据的运算及决策规则变成通过训练AI大模型让AI实时监控分析数据、预测潜在故障并在网络变化时动态调整策略以维持意图。形成“监控-分析-决策-执行-验证”的自主闭环实现网络的持续自优。4.3 基于系统效率的智能化让AI分析流程历史性能动态优化任务调度策略、并发度与资源分配实现效率的持续自优。结语构建网络自动化编排不应是一场技术表演而是务实地解决95%以上的通用网络自动化业务诉求。与此同时也应以辩证的视角承认在某些特殊、偶发或极简场景下传统的黑盒脚本反而具备更低的切入成本和更高的执行敏捷性。因此自动化架构的设计不应追求单一范式的绝对统治而应在“规模化编排治理”与“场景化敏捷响应”之间寻求平衡——前者保障了规范与复用后者保留了灵活与效率二者互为补充共同构成完整的自动化生产力体系。 感谢大家。