5.1 编排自动化与闭环

5.1 编排自动化与闭环

本节摘要：MANO 的核心价值是把 NFV 运维从"人工操作"升级到"自动化闭环"。本节讲清编排自动化的工程实践——闭环运维的监控分析决策执行链路、ONAP 和 OSM 两个主流开源 MANO 的对比选型、意图驱动网络（IBN）怎么用更高层抽象简化管理，以及自动化不该越过的几条边界。

学习目标

阅读完本节，你应当能够：

1. 画出闭环运维的完整数据流
2. 对比 ONAP 和 OSM 的定位差异
3. 解释意图驱动网络相比传统运维的优势
4. 列出自动化运维的三个边界
5. 设计一个基本的故障自愈流程

一、问题与直觉

传统网络运维里，最常见的场景是"人盯着监控屏"。运维人员盯着各种仪表盘，发现某个指标异常（比如延迟升高），然后人工判断原因，手动登录设备排查、改配置、重启服务。这套流程在设备数量少、变更不频繁时还能应付，但 NFV 环境下完全撑不住——一台服务器上可能跑着几十个 VNF/CNF 实例，实例还在不断创建销毁、扩容缩容，人工根本盯不过来。

MANO 的编排自动化就是为了解决这个问题。它把"发现异常—判断原因—执行修复"这套流程自动化：监控数据自动采集，异常自动检测，修复策略自动匹配，执行自动完成。运维人员的角色从"操作员"变成"策略设计者"——你定义"什么情况下该扩容、什么情况下该告警"，系统自动执行。

但自动化不是万能的。复杂故障、未知异常、跨域问题，自动化往往处理不了，盲目自动化反而可能放大问题。理解自动化的能力和边界，才能真正用好 MANO。

二、核心原理

2.1 闭环运维的完整链路

MANO 的闭环运维（Closed-Loop Automation）是一个持续运行的数据流，第 2 章讲过它的四环节，这里展开讲工程实现：

数据采集：从 VIM（资源指标：CPU、内存、网络）和 VNF 自身（功能指标：吞吐量、延迟、错误率）持续采集监控数据。采集频率要平衡——太密数据量大，太疏反应慢。通常资源指标每秒采集，功能指标按业务需求。

实时分析：判断当前状态是否偏离预期。这层可以用规则引擎（阈值判断）或机器学习模型（异常检测、趋势预测）。简单场景规则够用，复杂场景（如流量模式识别）才上 ML。

策略匹配：根据分析结果，从预设策略库里找匹配的应对方案。策略是运维人员预先定义的——"CPU 超过 80% 持续 5 分钟 → 扩容"、"VNF 无响应 → 重启"、"错误率超阈值 → 告警人工"。这层是自动化的"大脑"。

自动执行：NFVO/VNFM 执行决策——扩容、缩容、愈合、迁移、告警。执行后回到采集环节，形成闭环。

闭环的价值在于持续自适应。系统不是部署完就静止，而是持续感知负载变化、持续调整资源分配，让网络始终运行在最优状态。

2.2 ONAP 与 OSM：两个开源 MANO

MANO 的实现有商业产品（各厂商私有方案）和开源项目两类。两个最主流的开源 MANO：

ONAP 是重型方案，由 AT&T 的 ECOMP 和 Open-O 合并而来。它不只做 MANO，还包含策略引擎、数据分析、设计工具等一整套运维平台。功能强大但部署复杂、学习曲线陡，适合有实力的大型运营商（中国移动、AT&T 这种规模）。

OSM 是 ETSI 自己的开源 MANO 实现，严格遵循 ETSI 架构。它比 ONAP 轻量得多，部署简单，适合中小规模部署或 PoC 验证。功能没有 ONAP 全面，但对标准的遵循度最好。

选哪个？看规模和需求：

• 大型运营商、要全功能平台：ONAP
• 中小规模、要快速上手：OSM
• 验证标准兼容性：OSM（最贴合 ETSI）
• 要深度定制、有研发团队：ONAP（扩展性强）

💡 关键直觉：开源 MANO 不是拿来就能用的成品，而是半成品框架。无论 ONAP 还是 OSM，都要基于自己的业务做大量定制——适配你的 VNF、定义你的策略、对接你的 OSS/BSS。评估 MANO 时要把定制成本算进去，不要以为"装上就能跑"。

2.3 意图驱动网络（IBN）

传统运维要管大量细节——"把 vFirewall 扩到 4 个实例"、"把这条路由的 metric 改成 10"、"给这个切片分配 100Mbps 带宽"。这些细节决策繁琐、容易出错、依赖运维经验。

意图驱动网络（Intent-Based Networking，IBN） 提供更高层的抽象。运维人员不描述"怎么做"，而是描述"要什么结果"（意图），系统自动翻译成具体操作。比如：

• 传统指令："给视频流量分配专用路径，带宽 100Mbps，延迟低于 10ms"
• 意图："保障视频业务体验"

系统接收"保障视频业务体验"这个意图，自动分析视频业务需要多少带宽、什么延迟，然后配置对应的资源、路由、QoS 策略。意图变了（比如改成"优先保障视频但不要影响语音"），系统自动调整。

IBN 的价值：

• 降低运维复杂度：运维只需表达业务目标，不用管底层细节。
• 减少人为错误：系统翻译意图时做一致性检查，避免矛盾配置。
• 自动适应变化：底层资源变了，系统自动重新满足意图，不用人工干预。

IBN 是 MANO 演进的方向，但它依赖强大的分析能力和策略翻译引擎，目前还不够成熟。诺基亚、思科等厂商在推 IBN 产品，但大规模落地还有距离。

2.4 闭环自动化的工程实现

实现一个闭环自愈流程的伪代码示意：

class ClosedLoopController:
    def __init__(self, policy_db, vnfm):
        self.policies = policy_db  # 预设策略库
        self.vnfm = vnfm           # VNFM 执行接口

    def run_cycle(self, metrics):
        # 1. 分析指标
        anomalies = self.analyze(metrics)
        if not anomalies:
            return  # 一切正常

        for anomaly in anomalies:
            # 2. 匹配策略
            action = self.match_policy(anomaly)
            # 3. 执行
            self.execute(action)

    def analyze(self, metrics):
        # 检测异常 CPU超阈值 VNF无响应等
        issues = []
        if metrics.cpu_usage > 0.8 for 5_min:
            issues.append({"type": "overload", "vnf": metrics.vnf_id})
        if not metrics.vnf_heartbeat:
            issues.append({"type": "dead", "vnf": metrics.vnf_id})
        return issues

    def match_policy(self, anomaly):
        # 从策略库找匹配的应对
        return self.policies.lookup(anomaly.type)

    def execute(self, action):
        if action == "scale_out":
            self.vnfm.scale_vnf(action.vnf_id, delta=+1)
        elif action == "restart":
            self.vnfm.restart_vnf(action.vnf_id)
        elif action == "alert":
            self.notify_ops(action.vnf_id)
​

这个骨架展示了闭环的核心逻辑——采集、分析、匹配、执行。实际实现会更复杂（要处理并发、状态机、回滚），但结构就是这个。

三、工程实践要点

3.1 自动化的三个边界

自动化不是越多年好，有几条不该越过的边界：

边界一：未知故障模式不自动处理。策略库覆盖的是已知场景。遇到没见过的故障（新型攻击、罕见 bug），自动化可能误判、做出错误响应。这种情况应该告警人工介入，而不是盲目自动处理。

边界二：高风险操作要人工确认。某些操作影响大、不可逆——比如清空 VNF 数据、下线整个网络服务。这些不该全自动执行，应该告警后等运维确认。

边界三：跨域问题人工更稳妥。涉及多个系统（NFV + 传统网络 + 云）的故障，根因复杂，自动化的策略可能只治标不治本。人工分析更能找到根因。

3.2 策略设计的原则

好的策略设计是闭环自动化的关键。几条原则：

• 阈值要有缓冲带：扩容阈值 80%、缩容阈值 40%，中间留缓冲，避免在临界点反复抖动。
• 要有冷却时间：执行一次扩容后，给几分钟稳定期，不要立即再次判断（否则刚扩容指标还没稳定又触发新操作）。
• 要有上限和下限：扩容不能无限扩（资源有限），缩容不能缩到 0（至少留一个实例）。
• 要记录决策日志：每次自动决策（为什么扩容、为什么重启）都记下来，便于事后复盘和调优策略。

3.3 从人工到自动化的渐进路径

不要试图一步到位全自动化。推荐的渐进路径：

1. 先做监控和分析：把数据采集和异常检测做扎实，这是闭环的基础。
2. 再做半自动（告警+建议）：系统检测异常并给出建议操作，运维确认后执行。这阶段积累策略经验。
3. 最后做全自动：对验证过安全的策略，去掉人工确认，真正闭环。

⚠️ 常见坑：有些团队一上来就想做"全自动无人值守"，结果策略设计不成熟，自动化误判导致连环故障（比如错误扩容耗尽资源、又触发更多误判）。闭环自动化要逐步迭代，先让策略在半自动模式下跑稳，再放开全自动。

本节要点回顾

• 闭环运维是持续的数据流：采集→分析→策略匹配→执行→回到采集，让网络持续自适应。
• ONAP 重型全面适合大运营商，OSM 轻量贴合标准适合中小规模：选型看规模和团队能力。
• 开源 MANO 是半成品框架：必须基于业务大量定制，不是装上就能跑。
• 意图驱动网络（IBN）用更高层抽象简化运维：描述"要什么结果"而非"怎么做"，是演进方向但还不成熟。
• 自动化有三个边界：未知故障不自动、高风险操作要确认、跨域问题人工更稳妥。
• 策略设计要合理：缓冲带、冷却时间、上下限、决策日志。
• 渐进式自动化：先监控分析，再半自动告警建议，最后全自动。

最后一章收尾——NFV 面临的性能挑战、安全架构、以及生态系统和实践案例。

四、闭环的成熟度分级

自动化闭环不是开关而是光谱，工程团队需要知道自己站在哪一级。一级，脚本化：人工触发、脚本执行，闭环只在单次操作内成立——多数起步团队的常态。二级，规则触发：监控指标越限自动执行预案（CPU 高了自动扩容），闭环覆盖已知场景，但预案质量决定一切，规则冲突时互相打架。三级，策略闭环：声明的策略（服务等级目标）驱动持续调优，编排器在策略空间内自主决策，人只管改策略不管操作。四级，自学习闭环：闭环参数由学习算法在线调整，系统越用越聪明——愿景美好，现实里电信网络的保守性使它至今停留在试点。分级的价值在于规划：每升一级都需要前一级的预案库、数据积累与故障演练做地基，跳级建设的结果通常是自动化放大故障（自动扩容把配置错误也复制了八份）。务实的路径是把二级的预案做扎实，让三级有料可学——自动化领域的慢就是快。

五、闭环安全的三个红线

自动化闭环的收尾话题是它的阴暗面：自动化如何不变成故障放大器。三条红线来自行业事故的总结。红线一，任何自动动作必须可熔断：全局开关一秒内能把所有自动化降级为人工模式——没有熔断机构的闭环，在预案出错时会把错误执行得又快又彻底。红线二，自动动作要有速率与爆炸半径限制：单实例单时间窗内的自动重启次数封顶、跨实例的连锁自动操作禁止——防止"探针误报引发全量重启"的经典雪崩。红线三，所有自动决策留痕可回放：决策依据的指标快照、匹配的规则、执行的命令全部入档——事后复盘没有留痕的自动化，团队永远无法改进它，只能反复为它惊魂。三条红线的设计成本不高，缺了任何一条，闭环成熟度越高、事故的传播速度越快。把这三条讲给任何要上自动化的团队，都是能救人救项目的忠告。