14. 将自动化作为产品#

在那次改变了团队工作思维方式的谈话发生六个月前，网络平台团队已经交付了一个真正令人印象深刻的成果。两年来持续不懈的努力，打造出了一个端到端处理分支机构上线的配置平台：一个用于站点请求的自助服务界面、一个在部署前捕获错误配置的闭环验证工作流，以及一个跨三百个站点追踪服务健康状态的运营仪表盘。团队将变更窗口从二十四小时压缩到了四十分钟的自动化部署。他们为此感到骄傲，而且理所应当。

然后，业务发展团队敲定了一项零售连锁并购。一百二十家新门店需要在六个月内接入网络。基础设施负责人发来一封简短的邮件：“我们指望自动化平台来完成这件事。我们该怎么开始？”

网络平台团队的第一反应是自信的：他们可以实现自动化。工作流已经有了，模板也有了，工具链也经过了验证。

然而，当他们尝试回复这封邮件时，第二反应就没那么自信了。基础设施负责人问的并不是自动化技术上是否可行。他们问的是另一套问题：门店上线的 SLA 是什么——具体而言，提交站点信息后，门店获得网络连接的承诺时间是多少？当部署在中途失败时，升级路径是什么？是否有一个状态页面或仪表盘，可以让基础设施负责人的团队在不直接询问网络团队的情况下自行监控？平台的容量是多少——它能同时处理二十个并发部署吗，还是需要将请求分批处理？最令人不安的问题：在平台故障期间上线的门店，会被自动修复，还是需要有人逐一审计？

网络团队拥有自动化能力，但他们没有（用业务和产品语言表达的）答案。

这道鸿沟——介于"我们构建了可以运行的自动化"与"我们提供了其他团队可以依赖并据此规划的服务"之间——正是本章的主题。

这是我充满热情的话题。我在 Autocon3 上发表的演讲 从设计驱动的自动化视角涵盖了这一主题，是本章的参考资料。

14.1 从能力到产品#

第 13 章 描述了团队如何转变其人员、角色和工作方式，以将自动化构建为一种组织能力。这种转变是必要的，但还不够充分。

能力是团队能做到的事情。产品是其他团队（或最终是第三方实体）可以依赖的东西。这种区别与技术质量无关：零售连锁上线平台在技术上是卓越的。区别在于提供方与使用方之间的关系。能力为其创造者而存在。产品为其用户而存在。

网络团队的输出物已经发生了转变。在自动化之前，输出物是设备配置：一台路由器完成配置，一个 VLAN 扩展，一条 ACL 应用。该输出物的使用者是设备本身，成功的证据是 ping 通或应用正常运行。有了自动化，输出物发生了变化：网络团队的产品是由其他团队使用的网络服务。每一次与网络的交互——配置一个分支站点、为新应用扩展一个网段、执行安全策略、临时授予会议 VLAN 访问权限、在互联网交换节点添加互联连接——都变成了服务请求，而不是变更工单。设备配置是实现细节，服务才是制品。

这就是将网络服务作为产品 (Network Service as Product) 模式：服务是主要制品，底层网络是实现手段。这在软件工程中并不新鲜：API 对基础设施进行抽象，调用方不知道也不关心哪台服务器处理了请求。然而，对于历史上围绕设备、厂商和协议来组织工作的网络团队来说，这是一个重大转变。那些将自身身份认同建立在路由器配置技能上的工程师，现在被要求将其身份认同建立在服务交付能力上。这种重新定位与第 13 章第 13.1 节中的"工匠困境"直接相关：旧技艺的专家是最迫切需要进行这种重新定位的人，而那些完全完成这一转变的工程师将变得更有价值，而不是更少。

该产品的技术载体是第 8 章所描述的展示层模块。自助服务界面、API 接口、Webhook 集成、基于角色的访问模型——这些都是服务契约对使用方可见的地方。第 14 章将视角从技术界面拉远，聚焦于其周围的组织和业务模型。界面附带哪些承诺？当它出现故障时谁来负责？服务如何演进？谁来决定它下一步做什么？

14.2 定义产品#

当团队尝试将网络自动化转变为服务时，始终会出现两种失败模式。

第一种是过度暴露：界面暴露了实现细节，使用方必须了解网络内部机制才能使用它。一个要求输入 VLAN ID、子网掩码和 OSPF 区域编号的分支配置服务，不是一个服务——它只是一个带有 Web 表单的 CLI。使用方是零售连锁的设施协调员，他们不知道什么是 OSPF 区域，也不应该需要知道。

第二种是过度限制：界面约束如此之严，以至于只能处理网络团队预先设想的精确场景。任何偏离模板的请求都需要走例外流程。需要为临时快闪门店配置与常规零售门店不同连接需求的设施协调员，无法自助完成。他们只能提交工单，工单流转到网络团队，自动化带来的收益并未惠及那位使用方。

服务契约模式 (Service Contract Pattern) 通过明确、版本化且经过刻意界定的界面定义，解决了这两种失败模式。服务契约包含三个组成部分：

• 输入接口：使用方提供的内容，以业务术语而非网络术语表达（抱歉坚持这一点，但这是关键所在）。一个分支站点请求接收位置名称、实际地址、站点层级（标准、小型、快闪）和激活日期，而不接收 VLAN ID。契约在内部将业务意图转译为网络实现，而这种转译是自动化平台的责任。层级定义并非永久不变：为临时零售亭定义的快闪层级，不一定适用于连接需求不同的快闪活动场所。输入接口必须与使用团队以相同的路线图节奏进行评审，以确保层级反映实际的使用场景，而非网络团队在最初编写契约时所预想的场景。

• 输出接口：使用方观察到的内容，包括成功完成和失败两种情况。精心设计的输出接口不会暴露"部署在第 14 步中的第 7 步失败：gNMI 推送被错误代码 400 拒绝"，而是暴露"激活失败：该地址的物理线路尚未由运营商完成配置。预计完成日期：[来自 SoT 的日期]。您无需采取任何操作；当线路上线时，系统将自动重试"。自动化不仅仅是成功或失败：它以使用方能理解的语言发出可观察的生命周期事件。

• 内部依赖：服务在内部追踪的内容——使用方不需要看到，但团队必须管理的信息。来自运营商的线路状态、与该服务共享基础设施的相邻服务、新站点 SoT 记录与驱动自动化监控的库存记录之间的一致性关系。当一条线路进入运营商维护期时，网络团队需要了解哪些服务受到影响，以及由此造成的 SLO 风险敞口。使用方可能需要了解对其服务的影响，但不需要知道导致该影响的实现细节。

flowchart LR
    classDef consumer fill:#d9e8f5,stroke:#4a7fa5,color:#1a2e3b
    classDef contract fill:#f5e8d9,stroke:#a57a4a,color:#1a2e3b
    classDef internal fill:#d9f5e8,stroke:#3a8a5a,color:#1a2e3b

    subgraph Consumer["使用方界面"]
        IN["输入接口<br/>位置、层级、日期<br/>业务意图"]
        OUT["输出接口<br/>状态、生命周期事件<br/>业务语言"]
    end

    subgraph Contract["服务契约"]
        TRANS["转译层<br/>意图到实现<br/>VLAN、子网、OSPF 区域"]
    end

    subgraph Internal["内部依赖"]
        CIRC["线路状态"]
        SOT["SoT 一致性"]
        NEIGHBOR["相邻服务"]
    end

    IN --> TRANS
    TRANS --> OUT
    TRANS --> CIRC & SOT & NEIGHBOR
    CIRC & SOT & NEIGHBOR -.-> OUT

    class IN,OUT consumer
    class TRANS contract
    class CIRC,SOT,NEIGHBOR internal

服务契约定义完成后，下一个问题是随着时间推移会发生什么。

生命周期问题是许多团队投入不足的地方。服务契约不仅仅关乎配置的那一刻。当底层基础设施发生变化时，该服务会怎样？一个运行在即将进入运营商计划维护窗口的线路上的分支站点，会有预期的 SLO 影响。谁知道这一影响，谁来决定是否通知零售连锁的运营团队，如果维护窗口超时，谁来负责沟通？这些问题要求服务在 Term "sot" not found 中作为一等实体存在。

第 4 章中的 SoT 将意图描述为网络应有状态的权威记录。在产品模型中，服务将该意图向上延伸：不仅仅是网络元素应该是什么样子，还包括这些元素正在交付哪些业务功能，以及面向谁交付。一个只对设备和线路建模而不对服务建模的 SoT，无法回答"哪些零售门店受到这次线路维护的影响？“这个问题。它无法提供使服务感知的变更管理成为可能的依赖关系图。第 7 章的编排模块在协调修复时依赖这张依赖关系图：一个响应线路故障的闭环工作流，在路由通知和触发正确的恢复序列之前，需要知道哪些服务受到了影响。

这正是第 4 章第 4.2.2 节将设计驱动模块正式化的抽象：操作员提供高层意图（“添加一个分支”），SoT 将其扩展为执行器在接触设备之前所需的五十多个技术对象。第 14 章的服务模型将同样的原则再向上延伸一层——从"必须存在哪些技术对象"到"这些对象交付什么业务功能，以及面向谁交付”。最初设计用于将设备语法与操作员解耦的 SoT，同样可以将网络内部机制与服务使用方解耦——前提是服务在其中被建模为一等对象。

实际结论是：服务必须在 SoT 中与其依赖链一起建模。分支站点服务依赖一条物理线路，物理线路依赖一个运营商，运营商有历史维护窗口记录。网络网段服务依赖一组接入交换机。互联网交换节点的互联服务依赖一个 BGP 会话，BGP 会话依赖一个物理端口，物理端口位于特定设施中。当任何依赖项改变状态时，服务模型随之更新，受影响的使用方可以以他们能理解的语言收到通知。

flowchart TB
    classDef service fill:#d9e8f5,stroke:#4a7fa5,color:#1a2e3b
    classDef infra fill:#d9f5e8,stroke:#3a8a5a,color:#1a2e3b
    classDef external fill:#f5e8d9,stroke:#a57a4a,color:#1a2e3b

    S1["分支站点服务<br/>门店 847"]
    S2["应用连接服务<br/>库存系统"]

    C1["线路<br/>运营商 X，CID-44821"]
    SW1["接入交换机<br/>bldg-b-sw-01"]
    BGP1["BGP 会话<br/>AS64501"]
    PORT1["物理端口<br/>rack-14-u32"]

    S1 --> C1
    S2 --> SW1
    S2 --> BGP1
    BGP1 --> PORT1

    MAINT["运营商维护窗口<br/>2026-06-15 02:00 UTC"]
    C1 -.->|"受影响于"| MAINT

    class S1,S2 service
    class C1,SW1,BGP1,PORT1 infra
    class MAINT external

团队应能以这种方式建模的网络服务包括：新分支站点激活、会议或快闪活动的临时网络访问、使用 ACL 执行依赖规则的应用连接、在交换节点的互联网互联扩展，以及为新项目网段进行的 VLAN 扩展。每一项服务都有一个业务使用方、一个生命周期、若干依赖项，以及对健康和故障的有意义的定义。

大多数构建此模型的团队并非从一张白纸开始。现有网络已经有三百个分支站点、多年积累的配置变更，以及一个对设备和线路建模但不对服务建模的 SoT。在这些现有站点能够参与服务模型之前，必须发现并核对其实际状态与 SoT 认为正确的状态之间的差异。一个运行配置已偏离其 SoT 记录的站点，在该偏差被解决之前无法安全地纳入自动化生命周期管理：自动化将基于 SoT 对意图的理解来推送配置，如果该理解有误，推送只会使情况更糟。发现与核对——读取设备状态并与 SoT 记录进行比对，以识别和解决差距——是棕地环境的前提步骤。这项工作单调乏味、耗时费力，但跳过它意味着服务模型仅对平台搭建后配置的站点有效，而这通常只占整个网络的一小部分。

在 SoT 中对服务建模是必要的，但还不够充分：团队还需要在正确的层面上对其进行观测。第 6 章的可观测性模块完成了这个闭环：从使用方角度追踪服务是否健康的服务级可观测性，与追踪底层基础设施是否健康的设备级可观测性是不同的。两者都是必要的。当服务模型未在正确层面进行探测时，服务对使用方可能显示为降级状态，而底层所有设备却报告健康。

14.3 业务对齐#

网络自动化的传统论据侧重于运营效率：更少的工单、更快的配置、更低的错误率。这一论据是正确的，对于证明初始投资的合理性也很有用。但对于长期维持战略投资而言，它是不够的。

运营效率是相对于当前基线来衡量的。一个将手动配置时间从四小时缩短到四十分钟的团队，展示了显著的吞吐量提升。三年前批准预算的业务部门负责人感到满意，但并没有产生战略参与感：网络团队运转得更好了，这很好，但这不是进一步投资的理由。

更有力的论点是能力：自动化能够实现若非如此则不可能或代价极高的业务成果。零售连锁扩张就是一个具体的例子。没有成熟的自动化平台，在六个月内上线一百二十家门店，需要一支网络工程师团队为该项目专注工作六个月。假设激进的手动配置速度约为每名工程师每天一家门店（这个数字因连接类型、设备数量、运营商协调时间以及站点勘测是否完成而有很大差异），大约需要一支八人团队且没有其他职责。有了成熟的自动化平台，同样的工作由现有团队并行运行自动化工作流来完成。业务成果——以可接受的成本在六个月内完成扩张——只有在自动化存在的情况下才能实现。这不是一个效率论据，而是一个能力论据，一个业务论据。

第二个例子：一个运行大规模 AI 模型训练的组织，依赖互联配置的延迟和可靠性。如果上线一个新的训练集群需要两周的手动网络配置，该业务以有竞争力的速度运行训练实验的能力，就会受到网络团队吞吐量的制约。将配置从两周缩短到四十八小时的自动化，是业务部门认为具有战略意义的业务能力的直接输入。无法清晰表达这种关联的网络团队，正在放弃本可拥有的影响力。

第三个例子：一家服务提供商，其工程师为每个新的企业 MPLS VPN 合同手动配置 PE 路由器、VRF 实例、与客户 CE 设备的 BGP 会话和 QoS 策略，从订单接受到服务上线需要四周时间。这个时间表不是一个运营问题，而是一个销售问题。已将相同配置序列自动化的竞争对手——从服务请求生成一致的配置，针对现有拓扑进行验证，并通过经过测试的工作流推送——在招标文件回复中承诺两周交付。无论工程师多么熟练，四周的服务提供商都无法兑现这一承诺，因为约束不在于技能，而在于配置过程的串行手动性质。将交付时间从四周压缩到三天的自动化，改变了销售团队能够承诺的内容，进而改变了公司能够赢得哪些合同。这不是效率论据，这是收入论据，它应该出现在关于是否投资自动化平台的讨论中。

推理的顺序至关重要。从设备行为向上设计的自动化——从"我们可以对路由器配置的哪些方面进行自动化"开始，朝向"业务从中获得什么"——往往无法阐明业务价值，因为它从一开始就没有被设计为交付业务成果。从业务能力向下设计的自动化——从"哪些业务成果需要可靠的网络服务"开始，向后倒推通过服务设计到实现这些服务的自动化——可以从第一次对话起就将其工作与业务优先级联系起来。

业务驱动服务映射 (Business-Driven Service Map) 模式使这种联系变得明确：一个将网络服务映射到它们所支撑的业务能力的图谱。对于每项网络服务，该图谱回答三个问题：哪些业务流程依赖于这项服务，如果该服务降级或不可用，业务影响是什么，以及如果该服务更快、更可靠或支持自助服务，哪些业务能力将成为可能。这是网络自动化产品经理会拥有的文件，也是使自动化路线图与业务优先级对齐的主要工具。

flowchart TB
    classDef biz fill:#d9e8f5,stroke:#4a7fa5,color:#1a2e3b
    classDef svc fill:#f5e8d9,stroke:#a57a4a,color:#1a2e3b
    classDef auto fill:#d9f5e8,stroke:#3a8a5a,color:#1a2e3b

    subgraph BIZ["业务能力"]
        B1["零售扩张"]
        B2["AI 训练速度"]
        B3["活动运营"]
    end

    subgraph SVC["网络服务"]
        S1["分支激活"]
        S2["互联配置"]
        S3["临时访问"]
    end

    subgraph AUTO["自动化"]
        A1["站点上线工作流"]
        A2["线路与 BGP 配置"]
        A3["会议 VLAN 生命周期"]
    end

    B1 --> S1 --> A1
    B2 --> S2 --> A2
    B3 --> S3 --> A3

    class B1,B2,B3 biz
    class S1,S2,S3 svc
    class A1,A2,A3 auto

这种重新定位对许多网络团队来说是不舒服的，因为它需要衡量不同的事情。运营指标（关闭的工单数、变更成功率、Mean Time To Resolution (MTTR)）在团队的控制范围之内，且易于检测。业务成果指标（开设新零售门店的时间、作为训练吞吐量输入的互联配置延迟）则需要与其他业务部门合作，并了解他们实际衡量的内容。完成这种转变的团队——从衡量技术卓越到衡量业务贡献——在预算讨论中回答的是一个不同的问题：不是"本季度我们运营网络的效率如何"，而是"本季度哪些业务成果依赖于网络平台，没有它会有什么失败"。这是一个更难回答的问题，但它决定了平台是否能获得下一阶段的资金。

影响度量优先于效率度量 (Impact Measurement over Efficiency Measurement) 原则由此而来：优先衡量对业务重要的成果，而非仅对网络团队重要的运营指标。效率指标是输入，成果才是业务所关心的。

这种重新定位也改变了团队在规划周期中的诉求。一个呈现"我们将 MTTR 降低了 40%“的团队，是在报告自身的绩效。一个呈现"零售扩张时间表是可实现的，因为我们的上线自动化可以在无需人工干预的情况下同时处理四十个激活"的团队，是在报告业务能力。这两个事实可能都是真的，但只有其中一个与是否为零售扩张项目配备人员的决策相关。

14.4 内部 SLA#

一个其他团队依赖却没有可靠性承诺的自动化平台，是一个信任陷阱。它在有效时运作，在失效时便无从规划。安排在周一早上同时提交二十个分支激活请求的零售连锁基础设施负责人，需要在周一早上之前知道平台的行为方式：每次激活需要多长时间，二十个可以并行运行还是需要排队，如果中途有一个失败会怎样，以及平台将如何传达该故障？

这些都是 SLA 问题。在产品模型中，每项自动化服务都附带明确的 SLA——不是作为法律保护，而是作为使服务可被规划的运营契约。

自动化 SLA 包含四个组成部分：

• 可用性：服务界面可访问并接受请求的时间百分比。月可用性为 99.5% 的分支激活服务，每月允许约三个半小时的停机时间。这个数字是一项承诺：当服务停止时，团队有义务给出解释和恢复时间表。

• 执行延迟：从提交请求到完成，服务所需的时间。对于分支激活，这可能是：三十秒内确认收到，五分钟内开始配置，标准站点四十分钟内完成。这些数字定义了"正常工作"的样子，而不仅仅是服务是否可访问。

• 错误预算：服务可以失败而不违反 SLA 的频率。每周成功完成率为 99% 的服务，有 1% 的错误预算。当一周内超过 1% 的激活失败时，说明出了问题，团队有义务进行审查。第 13 章第 13.2 节中描述的 NRE 角色，是负责定义和维护这些预算的人，SRE 文献中的错误预算模型直接适用：当错误预算耗尽时，新的自动化部署暂停，直到可靠性恢复。

SRE（站点可靠性工程）是一门起源于大规模软件运营的学科，它将工程原则应用于可靠性：定义服务级目标、衡量错误预算，并使用可靠性数据来管理功能开发速度。NRE（网络可靠性工程师）角色将这些原则应用于网络自动化平台。这两个角色及其在网络团队中的应用，在第 13 章第 13.2 节中有详细介绍。

• 升级路径：当服务失败或未达到其 SLA 时，使用方联系谁，以及预期的响应时间是多少。将升级路径路由到通用网络团队收件箱的，不是升级路径——那只是一个工单队列。产品 SLA 需要一个有明确响应承诺的具名或基于角色的升级联系人。

支持模型问题自然随之而来：当自动化失败时，谁来负责？几乎每个故障中都会出现三种失败模式，混淆其中哪种处于活跃状态，会导致故障在团队之间被漏掉。

这些类别之间的重叠是故障被漏掉的地方。一个因 gRPC Network Management Interface (gNMI) 推送被拒绝而失败的自动化工作流，可能是自动化漏洞（错误的数据模型）、平台故障（gNMI 采集器丢失了会话）或网络故障（设备在推送期间重启）。故障响应流程必须被设计为能够在这些类别间进行分类，而无需使用方团队了解哪一种处于活跃状态。从零售连锁的角度来看，门店没有获得连接。由谁来修复以及何时修复，是服务提供方的问题，而不是他们的问题。

任何自动化故障的实用分类序列分三步进行。第一步，检查自动化日志：工作流是否报告了错误，该错误在相同输入的多次运行中是否一致，还是特定于某一次？相同输入上的持续失败指向自动化漏洞；随机或间歇性失败则指向别处。第二步，检查平台健康状态：其他不相关的服务是否同时失败，执行引擎、SoT 和可观测性堆栈是否报告健康？不相关服务间同时大面积失败是平台故障的特征，无论工作流日志怎么说。第三步，检查设备状态：网络元素是否接收并应用了预期配置，其当前状态是否与自动化尝试推送的内容一致？如果工作流无错误完成，但网络未收敛，则故障在网络层。这个序列可以被编码为自动化操作手册的前三个步骤，这样值班工程师到达故障现场时，分类工作已经完成，而不是从零开始。

第二种失败模式中提到的平台团队，与第 10 章相关：平台可靠性是服务 SLA 的前提条件。如果服务运行的执行引擎没有可靠性目标，服务就无法承诺 99.5% 的可用性。第 10 章中的平台工程模式——冗余、健康监控、自动化恢复——正是使自动化 SLA 具有可信度的基础。

在事故发生之前设计好升级路径。关于"谁负责什么"的事后讨论，总是比事先建立清晰边界的讨论更加困难。

爆炸半径是一个相关的设计问题，应在同一个事前讨论中提及。手动配置错误影响一个站点，因为工程师一次配置一个站点。一个自动化漏洞可能在人类注意到之前影响所有符合输入模式的站点。对此的回应不是放慢自动化速度，而是将并发限制和分阶段推出作为刻意的安全选择，而非实现细节，设计进服务契约中。一个将并发部署上限设为五个活动任务、在释放下一批之前验证第一个部署完成，并在任何失败任务上暂停直到人工处理的分支激活服务，不是一个慢速服务——而是一个爆炸半径经过设计约束的服务。该约束应出现在服务契约中，与可用性和执行延迟并列，以便使用方团队既了解平台能做什么，也了解平台为保护他们而拒绝做什么。了解平台在第一次失败后会暂停四十家门店的批量上线，而不是基于损坏的模板继续完成另外三十九个部署的零售连锁基础设施负责人，会对平台更加信任，而不是更少。

SLA 承诺、爆炸半径控制和分类框架的存在，为与变更治理建立不同关系创造了条件。在仍采用传统变更管理运营的组织中，每一次网络变更——包括自动化的变更——都可能被路由到变更顾问委员会进行事前审批。该流程是为每次变更都是独特的、手工定制的、不可预测的世界而设计的：由合适的人审查人类工程师的手动变更，能真正降低风险，因为人类判断会有所不同。将同样的逻辑应用于一个已经设计完成、在预生产环境中经过测试、针对 SoT 进行了验证、受到爆炸半径限制约束，并已成功运行数十次的自动化工作流，并不会降低风险——它只是给一个在投入生产之前就已确定风险状况的操作增加了延迟。

预审批自动化模式 (Pre-Approved Automation Pattern) 解决了这一问题：变更审批一次性应用于工作流设计，而不是重复应用于该工作流的每次执行。当一个分支激活工作流通过了其验证阶段、经过相关工程和运营利益相关方的审查和批准、并在其安全约束激活的情况下部署到生产环境时，该工作流的每次后续执行都不是需要重新审批的新变更——它是一个已批准、受约束操作的实例。适当的治理问题是"此次执行是否在已批准的范围内？"，而不是"此次执行是否应该发生？“云提供商不要求人工批准每个虚拟网络创建请求：服务经过了适当约束的设计、彻底测试，并作为服务获得了批准。该服务边界内的单个客户请求不是需要审查的变更事件，而是服务调用。网络自动化服务一旦经过适当设计和批准，应以同样的方式运作。证明这种信任合理性的工作，正是第 14.2 节至第 14.4 节所描述的内容：明确的服务契约、可观察的输出、受约束的爆炸半径，以及出错时明确的分类路径。这项工作就是变更审批，在正确的时机，一次性完成。

14.5 性能、成本与投资回报率#

自动化是有成本的。执行引擎、编排器和可观测性堆栈的计算基础设施。SoT 记录、作业历史和遥测数据的存储。构建、测试和维护自动化代码的工程时间（以及支持其的相应 AI 编码令牌）。平台商业组件的工具许可证。当使用方提交问题或请求新能力时产生的支持负担。这些成本是真实的，也是持续性的。

投资回报率问题同样是真实的，回避它的网络团队会将预算决策拱手相让给财务和采购团队，而他们的回答往往不够准确。该框架包含三个组成部分：

• 自动化成本：构建和运行平台的完全加载成本。分配给平台开发和维护的工程师薪资、基础设施成本（自动化基础设施本身的计算、存储和网络）、工具许可证以及运营开销。这个数字是可知的，团队应该了解它。

• 手动等效成本：在没有自动化的情况下交付相同服务所需的成本。对于分支激活，这是每个站点的工程小时数乘以执行工程师的小时成本，加上错误成本（手动配置错误导致的故障，以 Mean Time To Resolution (MTTR) 和受影响服务计量）。对于零售连锁扩张，手动成本之大，足以让自动化投资显然合理。对于每年仅配置两次的低流量服务，计算方式则有所不同。

• 解锁能力的价值：没有自动化则不可能实现的业务成果。这是最难量化的组成部分，也是最有价值的论据。一百二十家门店六个月内完成，不是效率问题，而是二元能力问题。没有自动化，无论工程预算多少，都无法在那个时间线上完成。能够清晰表达"零售扩张时间表依赖于我们的自动化平台"的网络团队，参与的是战略对话，而不是预算谈判。

三个轴定义了任何自动化服务的设计空间，每个轴都代表一种产品模型迫使公开化的权衡：

• 速度：从请求提交到完成，服务需要多快？
• 安全性：通过验证、演习阶段和回滚路径，服务避免使情况变得更糟的可靠程度如何？
• 利用率：平台在不降级的情况下能处理多少并发请求？

这些轴之间存在张力。通过广泛验证和有监督的执行阶段来最大化安全性，会增加延迟：更安全的工作流通常速度更慢。通过减少验证阶段来最大化速度会增加风险。通过最大化并发利用率需要的基础设施投资，可能无法被实际请求量所证明。

产品框架迫使这些权衡在服务契约中变得明确。当零售连锁基础设施负责人询问二十个同时部署是否安全时，答案不是"测试中可以运行”。答案是关于平台设计的具体陈述：并发部署容量上限为二十四个活动任务，每个部署有独立的回滚路径，可观测性系统在将作业标记为完成之前会确认成功的状态收敛。这些陈述来自一个将权衡作为产品设计决策而非工程实现细节来思考的团队。

投资回报率的衡量直接影响优先级排序。下一步构建哪种自动化，应该由哪些业务成果受到网络限制最多来决定。追踪哪些手动请求占用了最多工程时间、哪些服务在手动配置期间故障率最高、哪些业务能力被网络吞吐量阻塞的团队，拥有提出优先级论据的数据，而这些数据是业务可以评估的。没有这些数据的团队，会基于技术上的有趣程度来提出优先级论据，而这些论据在预算周期中败给了那些量化了其影响的团队。

14.6 优先级排序与路线图#

每个网络自动化团队都面临两个持续性的问题，却很少获得正式的回答：下一步自动化哪些任务，以及何时对请求说不。产品模型要求对两者都给出正式答案。以下是优先级排序的类别：

• 业务影响：哪项服务实现自动化后，能够支撑最高价值的业务能力？第 14.3 节中的业务驱动服务映射是回答这个问题的输入。自动化后能够解锁战略业务举措的服务，优先级高于自动化后每年节省十二工时的服务。

• 频率乘以工作量：这项任务手动执行的频率如何，每次执行需要多少工程时间？每天执行且每次耗时四小时的任务，其投资回报率是每周执行且每次耗时三十分钟的任务的两百倍。每次耗时大量且高频的手动任务，是最明确的自动化候选对象。

• 风险降低：有些任务即使不频繁，也值得自动化，因为人为错误的代价是灾难性的。手动 BGP 互联变更——配置错误时会导致路由泄漏影响数百个客户——即使每年只发生六次，也值得自动化。自动化的合理性不在于吞吐量，而在于消除一种后果不可接受的错误模式。

• 用户需求：其他团队正在积极请求什么？用户需求是一个不完美的信号，因为团队通常请求他们知道可行的内容，而非最有价值的内容。但来自同一团队对同一能力的持续请求，是关于服务界面不符合实际用例的有意义数据。

自动化待办列表 (Automation Backlog) 模式将未自动化的任务与产品团队对待功能待办列表一样处理：按优先级排列、进行估算，并明确"完成"意味着什么的验收标准。完成不是"自动化在实验室中成功运行”。完成是"自动化已通过第 13 章第 13.5.2 节中描述的信心阶梯 (Confidence Ladder) 阶段、已记录在案，并且可供相关使用方团队自助消费"。待办列表对利益相关方可见，以便他们了解即将到来的内容并据此规划。

路线图的沟通比路线图本身更重要。以季度频率与依赖团队共享的网络自动化路线图，是一种信任信号。它使自动化团队的工作对业务可见。它允许使用方团队根据平台在下一季度将能做和不能做的事情，规划自己的工作。它创造了使用方团队提出网络团队不知道存在的需求的反馈机会。

来自使用方/利益相关方的反馈循环，是路线图决策最有价值的输入。哪些团队提交了最多例外请求？哪些自动化输出需要手动解读才能让使用方采取行动？当前服务界面在哪些地方迫使使用方以网络术语而非业务术语提交请求？这些都是产品反馈信号，系统化地捕获它们，正是使路线图反映实际用户需求而非自动化团队认为用户应该想要的内容的关键所在。

利益相关方会议的频率值得明确说明。一个定期会议——对大多数平台来说是季度，对于积极开发的平台来说是月度——在会议上审查路线图、收集用户反馈并传达即将到来的变更，这不是一个状态会议，而是自动化平台像一个倾听用户声音的产品一样运作的机制。跳过这一步的团队构建的自动化解决的是去年的问题，而消耗的是今年的预算。

14.6.1 产品管理职能#

并非每个团队都需要一个专职的产品经理。每个成熟的自动化项目都需要有人承担产品管理职能。

在小型团队规模下，网络架构师或高级 NRE 可以在其技术工作之余承担产品管理职能。他们维护待办列表，主持利益相关方会议，并负责业务对齐对话。在这个规模下，每周几个小时就足以维持该职能的运转。

随着平台的增长，外部利益相关方与内部工程之间的转译工作变得相当繁重。一个服务十个使用方团队、有三十个服务在生产中运行、季度路线图需要跨竞争优先级进行谈判的平台，不能在每周几个小时内完成产品管理工作。该职能变成了一个全职角色。

网络自动化产品经理 (Network Automation Product Manager) 角色正在拥有成熟自动化项目的组织中兴起。其职责包括：

• 代表平台拥有利益相关方关系：作为使用方团队的主要联系人，负责将其需求转译为服务需求
• 维护业务驱动服务映射和自动化待办列表，优先级排序同时反映业务影响和工程现实
• 对外传达路线图，并在优先级发生变化时管理预期
• 定义和追踪业务影响指标，使平台对业务成果的贡献对领导层可见
• 在团队优先级讨论中代表用户反馈，确保工程优先级反映实际用户需求，而非内部技术偏好

此角色不需要深厚的网络专业知识。它需要能够理解网络团队能交付什么、业务需要什么，以及这两者在哪些方面对齐或不对齐的能力。网络自动化产品经理与第 13 章第 13.2 节中技术角色之间的协作模型，遵循软件产品组织中熟悉的模式：产品经理拥有构建什么以及为什么构建，网络平台工程师和自动化开发者拥有如何构建，NRE 拥有如何在生产中保持其健康运行。这些群体之间的冲突是该模型的特性，而非缺陷：产品经理推动用户需求，工程师推动平台可持续性，两者之间的张力产生比任何一方单独达成的更好的决策。

网络自动化产品经理角色在某些网络组织中颇具争议，因为它将一个非技术角色引入以技术为中心的团队结构中。这种担忧是有道理的：技术基础不足的产品经理会做出工程团队无法兑现的承诺，并且难以区分哪些请求是直接实现的，哪些请求需要根本性的平台变更。解决方案不是回避这个角色，而是使协作边界具体化。两条底线是不可谈判的：产品经理在没有工程负责人明确签字确认范围和时间表的情况下，不能向外部利益相关方承诺交付日期；工程负责人对任何需要尚未设计或估算的平台变更的承诺拥有否决权。没有这些护栏，产品经理角色会产生一种新的失败模式：外部利益相关方收到了工程团队在事后才知晓的承诺，而信誉损失落在平台上，而不是产品经理身上。

在他的平台转型两年后，Jordi——一位带领团队从手动运营转变为自动化平台的网络架构师（在第 13 章中曾介绍过）——被邀请参加一次关于零售连锁整合项目的会议。业务团队负责人介绍了上线时间表，指着一个六周窗口，其间需要四十家门店同时上线，并问道：“平台为此准备好了吗？“Jordi 有答案：平台在技术上可以应对，但新激活站点的监控覆盖在全遥测摄取之前有十二小时的延迟。四十个同时激活意味着四十个站点在半天内以有限的可观测性覆盖运行。他直接说明了这一点，点明了风险，并提出了一个修改上线顺序的方案：将激活分散在三天窗口内，而不延长整体时间表。业务团队接受了。整个对话在十五分钟内完成，因为 Jordi 既了解技术约束，也了解其业务后果。这种转译——在平台所做的事情与业务所经历的事情之间——就是产品管理职能，无论谁持有这一头衔。

14.6.2 管理服务生命周期#

第 14.6.1 节中的产品经理角色描述列出了职责。本节展示这些职责如何在每项网络服务经历的四个阶段中运作：定义、交付、运营和演进。

flowchart LR
    classDef def fill:#d9e8f5,stroke:#4a7fa5,color:#1a2e3b
    classDef del fill:#f5e8d9,stroke:#a57a4a,color:#1a2e3b
    classDef ops fill:#d9f5e8,stroke:#3a8a5a,color:#1a2e3b
    classDef evo fill:#d9e8f5,stroke:#4a7fa5,color:#1a2e3b

    DEF["定义<br/>服务契约<br/>业务论证"]
    DEL["交付<br/>待办列表管理<br/>验收标准"]
    OPS["运营<br/>SLA 监控<br/>用户沟通"]
    EVO["演进<br/>版本管理<br/>弃用"]

    DEF --> DEL --> OPS --> EVO
    EVO -->|"下一版本"| DEF

    class DEF def
    class DEL del
    class OPS ops
    class EVO evo

定义

产品经理与新服务的首次接触发生在工程团队编写任何自动化代码之前。使用方团队提出请求：“我们需要更快地完成门店上线，“或"我们的应用团队在不提交工单的情况下无法配置网络网段。“产品经理在这个阶段的工作是使用第 14.2 节中的三组件结构，将该请求转译为有边界的服务契约：使用方提供什么（输入接口）、他们观察到什么（输出接口），以及服务携带哪些使用方不需要了解但团队必须管理的内部依赖？这种转译不是交给工程的需求文档，而是使用方需求与平台能够交付的内容之间的谈判，产品经理和工程负责人都参与其中。

产品经理拥有"从使用方角度来看，完成是什么样子"这个问题。工程负责人拥有"从平台角度来看，完成是什么样子"这个问题。在定义完成之前，两个问题都必须得到回答，因为一个满足使用方但忽略平台约束的服务契约，将在交付期间产生返工；而一个满足平台但不满足使用方的服务契约，将在发布后被闲置。

在定义结束之前，产品经理将新服务置于第 14.3 节的业务驱动服务映射中。这一步确保服务有明确的业务论证，并且其相对于其他自动化待办列表项目的优先级，可以按照一致的标准进行评估。一个无法被置于映射中的服务——因为没有人能说清楚它支撑哪种业务能力，或者缺失它的影响是什么——还没有准备好被定义。这是一个信号，应该回到使用方对话中，而不是开始工程工作。

交付

一旦服务契约达成一致，产品经理便管理相应的自动化待办列表条目通过开发过程。验收标准以使用方术语编写：“标准分支激活在提交后四十分钟内完成，在每个阶段发出一个生命周期事件，“而不是"gNMI 到 PE 路由器的推送无错误完成。“这种区别很重要，因为以实现术语编写的验收标准，可能在使用方体验失败的情况下通过：推送完成了，但使用方没有收到通知，也无法判断他们的门店是否已激活。

在交付过程中，产品经理拥有所有关于时间表和范围的外部沟通。工程负责人拥有内部技术决策。这种分工保护工程团队免受破坏大多数自动化项目的模式：在服务契约达成后才到来的范围添加。契约签署后的每个新需求，都是一个有其自身优先级排序的新自动化待办列表条目，而不是对当前交付的修改。产品经理的工作是对使用方团队维持这一边界，因为工程团队无法在不损害使用方关系的情况下做到这一点。一个可以被任何利益相关方随时扩展的交付范围，就是一个永远无法完成的交付。

运营

当服务上线时，产品经理的角色从交付转变为信任维护。第 14.4 节中的内部 SLA 定义了服务的承诺：可用性、执行延迟、错误预算和升级路径。产品经理监控这些指标，不是为了诊断故障（这是 NRE 的职责），而是为了在阈值接近或被突破时，拥有面向使用方的沟通。一个通过查看他们没被告知要关注的仪表盘，发现其服务一直在 SLA 之外运行的使用方团队，没有收到 SLA——他们收到的是一个没有关系的指标。产品经理就是那种关系。

产品经理还运行运营反馈收集过程。哪些使用方团队提交了最多的例外请求？哪些服务输出需要手动解读才能让使用方采取行动？当前输入接口在哪些地方迫使使用方以网络术语而非业务术语提交请求？这些信号不是投诉——它们是产品数据，产品经理的工作是系统地汇总它们，并以足够的具体性带到路线图对话中，使工程团队能够采取行动。“使用方对分支激活不满意"这样的反馈没有可操作性。“过去十二个例外请求中有七个是针对不符合任何定义层级的快闪站点，所有七个都需要网络团队的直接介入"这样的反馈是可操作的：它点明了输入接口中的一个差距，并量化了其运营成本。

演进

停止演进的服务，会在其设计处理的内容与使用方实际需要的内容之间积累不匹配。产品经理拥有服务何时以及如何演进的决策，这一决策以上一阶段收集的运营反馈以及业务驱动服务映射中不断变化的条目为依据。

并非所有演进都具有相同的运营后果。添加新的可选输入字段或发出更丰富输出事件的变更是增量式的：现有使用方不受影响，新能力的采用是可选的。重命名必填字段、删除输出事件或更改 SLA 承诺的变更，会打破依赖于它的每个使用方的现有契约。产品经理必须在任何演进开始之前区分这两种类别，因为它们需要不同的流程：增量变更可以作为次要更新交付，而破坏性变更需要版本增量、迁移路径，以及在变更发布之前传达给使用方团队的弃用时间表。

弃用时间表是许多团队失败的地方。工程团队自然希望在新版本稳定后尽快删除旧版本。使用方团队自然希望留在他们依赖的版本上，直到他们有能力迁移。产品经理在这两种立场之间谈判达成窗口期，并向双方承诺：一个具体的日期，在该日期后旧版本不再受支持，并且提前足够长的时间传达，以便使用方团队能够规划其迁移。没有此流程而演进的服务，会侵蚀服务契约本应建立的信任。在生产中发现破坏性变更的使用方团队，经历的不是技术故障——他们经历的是关系故障，而从中恢复更加困难。

14.7 总结#

四个主题锚定了本章：

服务，而非脚本：产品转变是从构建可以运行的自动化，到提供其他方依赖的服务。将网络服务作为产品模式为这种重新定位命名：服务是主要制品，底层网络是实现细节。服务契约模式是使其具体化的制品：一个明确的、版本化的输入接口、输出接口和内部依赖的定义，将界面约束在使用方需要提供的和可以观察到的范围内，同时不暴露他们不需要了解的网络实现细节。

业务对齐是结构性的：衡量业务影响需要从业务成果向下设计自动化，而不是从设备行为向上设计。业务驱动服务映射是工具：将网络服务明确映射到它们所支撑的业务能力，以及服务降级或不可用对业务的影响。能够流畅地进行此类映射的团队，是其他业务部门在规划新项目时首先致电的团队，因为那些团队已经回答了"网络使什么成为可能"这个问题。不能做到这一点的团队，是在时间表已经确定后才听到新举措的团队，只能解释为什么网络无法及时准备好。自动化待办列表将同样的逻辑应用于优先级排序：下一步构建哪种自动化，应该由哪些业务成果受到网络限制最多来决定，而不是由哪种自动化在技术上最有趣来决定。

在需要之前制定 SLA 和支持模型：在第一次重大故障之前定义可靠性承诺、升级路径和故障所有权，正是将平台与脚本集合区分开来的关键。内部 SLA——包含可用性、执行延迟、错误预算和升级路径这四个组成部分——是使信任变得明确的工具。三种失败模式分类（自动化漏洞、平台故障、网络故障）是防止故障在团队之间被漏掉的分类框架。预审批自动化模式对此进行了延伸：一旦工作流已经设计、测试并在其安全约束激活的情况下获得批准，单个执行就是已批准操作的实例，而不是需要重新审批的新变更。SLA 模型和治理模型都必须在第一次故障之前建立，而不是之后。

跨服务生命周期的产品管理职能：每项网络服务经历四个阶段——定义、交付、运营和演进——产品管理职能拥有所有四个阶段的连续性。在定义阶段，产品经理在工程开始之前将使用方请求转译为有边界的服务契约。在交付阶段，产品经理维持范围边界并拥有外部沟通。在运营阶段，产品经理拥有面向使用方的 SLA 沟通，并将反馈汇总为可操作的产品数据。在演进阶段，产品经理区分增量变更和破坏性变更，拥有版本决策，并与工程和使用方团队双方谈判弃用时间表。没有这一职能，服务被临时定义，交付时没有验收标准，运营时没有使用方关系，演进时没有通知。有了它，平台就像一个倾听用户声音的产品，并随着时间的推移赢得信任。

本章描述的产品规范，是第五部分所描述内容的前提条件。闭环自动化做出实时修复决策。自愈网络在无需人工干预的情况下响应故障。自主网络代表其使用方做出路由和配置决策。这些中的每一个，都代表平台在没有针对特定操作的直接人工授权的情况下，采取使用方依赖的行动。没有定义好的服务边界、可观察的状态、可靠性承诺，以及在超过阈值时清晰的升级路径，自主运营就不是一个产品——而是一个无契约行事的不可预测系统。本章的工作，正是使自主运营成为可信赖的基础，而这也是第五部分所构建的基础。

参考资料与延伸阅读#

• 《持续交付》，Jez Humble、Dave Farley 著（Addison-Wesley，2010年）。软件交付生命周期的奠基文本：如何构建使发布成为可靠、低风险操作的部署流水线。本章中的服务生命周期模式——从开发到生产运营——借鉴了这些原则并应用于网络自动化。

• 《SLO 的艺术》，Google SRE 工作手册（可在 sre.google 获取）。关于定义服务级目标、错误预算，以及可靠性承诺与功能开发速度之间关系的实用指南。第 14.4 节中的内部 SLA 模型，将这些原则应用于服务内部使用方的自动化平台。

• 《赋能》，Marty Cagan 著（Wiley，2020年）。技术组织的产品管理框架：如何围绕成果而非功能组织团队，如何定义产品团队的"完成"意味着什么，以及如何保持工程工作与业务优先级之间的战略对齐。第 14.6.1 节中描述的网络自动化产品经理角色，借鉴了这一框架。

• 《团队拓扑》，Matthew Skelton、Manuel Pais 著（IT Revolution Press，2019年）。在第 13 章中曾被引用，在这里依然相关：平台团队模型——自动化平台服务于流对齐团队作为内部使用方——是本章中产品模型所设计支持的组织结构。

• 《加速：精益软件和 DevOps 的科学》，Nicole Forsgren、Jez Humble、Gene Kim 著（IT Revolution Press，2018年）。关于将高绩效技术组织与低绩效组织区分开来的实证研究。与第 14.4 节相关：数据显示，变更审批委员会与更好的稳定性成果不相关，但与更慢的交付强相关——这是预审批自动化模式背后的证据基础，以及变更治理应属于工作流设计时而非每次执行时的论据。

💬 Found something to improve? Send feedback for this chapter