13. 文化转型#

会议邀请在周四发出，主题是"网络团队架构调整"。Jordi 做了十五年网络工程师，拿到了 CCIE 认证，经历了三次收购、两次 NOC 整合，以及一次严重到成为内部案例的 BGP 路由故障。他以为这只是一次人事通知。

他错了。

他的经理解释说，网络团队将被重组并入平台工程部门，团队名称改为"网络自动化平台"。工作内容也将随之演进：减少手动配置，更多精力投入构建和运营处理配置任务的自动化系统。新的岗位描述已经写好，职位名称是"网络平台工程师"。

Jordi 当天晚上回家搜索了这个职位名称，大多数结果指向云计算招聘和容器编排基础设施，他读了一个小时，大约能理解一半的内容。他没有写过 Python 脚本，也不清楚 Git 究竟是什么，更不确定自己应该感到兴奋还是恐惧。

到年底，Jordi 已经向生产环境交付了两个自动化工作流，审查了来自从未配置过路由器的软件工程师的数百行代码，并撰写了团队的第一份架构决策记录。他不是软件开发者，他是一种更难界定、也更有价值的工程师：既理解网络，又理解操作网络的系统。

本章讲述的正是这场转型。不只是 Jordi 一个人的转型，而是整个组织的转型。第 1 章至第 12 章所介绍的技术无法自行运转，它需要具备不同技能、不同角色、与网络工程传统培养模式截然不同协作方式的人来驱动。把技术做对已经很难，把组织转型做对更难，而这也是自动化项目最常失败的地方。

13.1 身份认同危机#

文化转型中最难的部分，不是学会使用 Git，而是放下多年深耕 Command Line Interface (CLI) 所积累的专业身份认同。

网络工程的职业文化建立在一种直到近期才难以获取、且无法造假的专业技能之上：理解 BGP 在故障条件下的收敛行为；在凌晨 2 点调试生成树拓扑变化（是的，生成树至今仍广泛运行在生产环境）；读懂数据包抓取，在应用团队还没来得及提交工单之前便识别出细微的 MTU 不匹配。这些都是经年累月磨练出来的硬核技能，也由此构建了强烈的职业身份认同。

自动化打破了这种专业技能的表层。当一个设计良好的自动化平台能够处理 VLAN 配置、配置加固和设备零接触入网时，那些多年来通过手工 CLI 操作精通这些任务的工程师将面临一个看似矛盾的选择：使用自动化替代自己擅长的事，还是抵制自动化来保护定义自我的技能？

这就是工匠的困境：你在某门手艺上越是精通，任何将其抽象屏蔽的工具就越像威胁而非助力。熟悉每家厂商 CLI 细节的网络工程师抵制抽象层，并非出于非理性，而是来自一个完全理性的判断：他们被要求以熟悉换陌生。

破解困境的关键在于重新定位：自动化并不取代深厚的网络知识，恰恰相反，它需要这种知识。区别在于这种知识在哪里、如何发挥作用。深刻理解 BGP 收敛机制的工程师，在自动化时代并没有变得不那么重要，反而是唯一有资格设计可靠闭环 BGP 自动化的人。技能的应用场景从执行移向了设计，从亲手运行命令变成了定义应运行哪些命令、在哪些条件下运行。

这种转变——从"我配置网络"到"我构建配置网络的系统"——正是本章文化转型的核心。这不是技能缺口，而是视角缺口。

flowchart LR
    classDef legacy fill:#d9e8f5,stroke:#4a7fa5,color:#1a2e3b
    classDef emerging fill:#d9f5e8,stroke:#3a8a5a,color:#1a2e3b

    A["**Network Engineer** - Executes configuration - Deep device expertise"]
    B["**Network Platform Engineer** - Designs automation systems - Expertise embedded in code"]

    A -->|"framing shift"| B

    class A legacy
    class B emerging

成功完成这一转变的工程师，几乎从来不是那些决定转行做软件开发的人，而是那些好奇于自动化为何总在某个特定厂商边缘案例上失败，并深究到足以理解症状背后系统的人。这种好奇心——不只想知道如何配置，还想弄清楚配置如何从意图抵达设备、故障如何传播、系统如何恢复——正是让转型成为可能的思维方式。它也是自动化之前最优秀的网络工程师所共有的特质：想要理解协议本身，而不只是套用配置模板。

这种好奇心的回报，是任何个人通过手工操作都无法企及的规模化影响力。一个跨八百台交换机正确运行的自动化工作流，几分钟内完成的工作量超过一整个团队一周手动变更窗口的总和。构建这个工作流的工程师并没有被它取代，而是成为了一个力量倍增器。他们的专业知识嵌入在一个他们休眠时仍在运转的系统中，稳定地处理日常工作，将工程产能释放给那些仍需要判断力的问题。这比任何手工 CLI 熟练程度都更有力量。

在第 1 章中，自动化的障碍包括对变化的恐惧与错误的技能预设。这些障碍不会因为经理重组团队而消失，它们需要刻意关注：如何定义角色、如何培养技能，以及组织如何传达出深厚的网络专业知识在新模式中比以往更有价值，而非更少。

身份认同危机往往就在这里开始：一个工程师还无法定义的新头衔，对应一个组织尚未弄清楚如何支持的新角色。

13.2 自动化时代的新角色#

团队在启动自动化转型时最适得其反的问题是"哪些岗位会消失？“更有用的问题是"哪些角色正在涌现，它们需要什么能力？”

大多数角色是演进而非消失。变化的是价值集中的位置。每天花八小时处理手动变更工单的运维人员并不会被淘汰，被淘汰的是那八小时的工单处理本身。释放出来的产能，要么流向更高价值的工作，要么——如果团队没有主动塑造这一过渡——演变为组织摩擦。

以下角色在成功完成转型的团队中持续涌现。

• 网络平台工程师：该角色将自动化平台作为工程产物来拥有和运营。平台涵盖 Source of Truth (SoT) 的 Schema 设计、执行流水线配置、验证和部署自动化变更的 CI/CD 工作流、网络可观测性平台，以及自动化模块间的接口契约。网络平台工程师是运行容器集群或管理内部开发者工具的软件平台工程师的对等角色：他们构建并维护其他工程师用于运营网络的系统。该角色与第 4 章至第 8 章的架构工作以及第 10 章的平台工程模式直接相关。

• 网络可靠性工程师（NRE）：面向大规模软件服务发展起来的 SRE 模型经过有意义的调整后同样适用于网络自动化。NRE 角色将 SRE 原则适配到网络运维：为自动化流水线定义服务级别目标、构建自动化故障的应急响应流程，以及维护在功能迭代速度与运维稳定性之间取得平衡的错误预算。当一个闭环自动化在凌晨 3 点误触发时，NRE 正是那个已经为这种故障模式设计好应急手册的人。

• 网络架构师：该角色进一步远离设备，靠近意图。网络架构师定义网络应该是什么：真实数据源中的意图模型、自动化将强制执行的设计模式、管理拓扑与地址规划的策略。他们在设备 CLI 上花费的时间更少，在 Schema 设计、跨团队架构评审以及评估设计决策如何约束或使能自动化上投入更多。第 4 章所描述的意图层，正是该角色主要负责的领域。

• 网络数据工程师：闭环自动化、自愈网络以及自主运营（见第 15 章至第 17 章）依赖高质量的运营数据。网络数据工程师构建并维护馈送 Observability 系统的数据流水线，定义使遥测数据具备可操作性的 Schema，并拥有自动化决策所依赖的数据质量。该角色将第 6 章的可观测性模块与第五部分的闭环模式连接起来。

• 网络自动化开发者：该角色编写自动化代码本身：集成逻辑、工作流编排、验证框架，以及平台所依赖的工具链。网络自动化开发者可能是嵌入网络团队、学到足够网络知识的软件工程师，也可能是学到足够软件开发能力的网络工程师。两条路径都可行。与网络平台工程师的重要区别在于范围：自动化开发者交付具体的自动化能力，平台工程师则拥有运行这些能力的系统。

传统运维角色收缩但不会消失。消失的是重复性的执行：手动配置、逐票 CLI 会话、人充当脚本运行者的工作流。背后的判断力——知道哪里出了问题、发现自动化遗漏的情况、在模糊的故障事件中做出决策——依然有价值，只是从日常执行转向了质量保障和升级处理的所有权。

下图并非晋升路线图，而是一张价值流向图：从重复性执行流向设计、可靠性、数据与平台所有权。大多数工程师不会沿着单一箭头前行，而是选择与自己已有的好奇心最相符的那条。

flowchart LR
    classDef legacy fill:#d9e8f5,stroke:#4a7fa5,color:#1a2e3b
    classDef emerging fill:#d9f5e8,stroke:#3a8a5a,color:#1a2e3b
    subgraph Legacy["Legacy Role Profiles"]
        direction TB
        L1[**Network Operator** - Manual provisioning - Device CLI mastery]
        L2[**Network Engineer** - Design and troubleshoot - Vendor expertise]
    end
    subgraph Emerging["Emerging Role Profiles"]
        direction TB
        E1[**Network Platform Engineer** - Automation platform - CI/CD and SoT ownership]
        E2[**Network Reliability Engineer** - SLOs and incident response - Error budgets]
        E3[**Network Architect** - Intent models - Design governance]
        E4[**Network Data Engineer** - Telemetry pipelines - Observability quality]
        E5[**Network Automation Developer** - Workflow and integration code - Validation frameworks]
    end
    L1 -->|evolves to| E1
    L1 -->|evolves to| E5
    L2 -->|evolves to| E2
    L2 -->|evolves to| E3
    L2 -->|evolves to| E4
    class L1,L2 legacy
    class E1,E2,E3,E4,E5 emerging

13.3 技能转型路径#

每个正在经历这场转型的组织都会出现两种失败模式。第一种是期待每位网络工程师都成为软件开发者；第二种是期待嵌入网络团队的软件工程师在不具备深厚协议知识的前提下，拥有网络自动化的所有权。两者失败的原因相同：它们假设一个领域的技能可以仅凭意愿转移，而非通过实践积累。

13.3.1 T 型工程师#

T 型工程师的概念由 Tim Brown 在 IDEO 提出，并被平台和 DevOps 组织广泛采用，它命名了行之有效的工作模式：在一个领域深度垂直专精，在另一个领域具备广泛的横向素养。不是对称，不是第二专业的全面深入，而是有效的不对称。

向网络平台工程师转型中的网络工程师，需要足够的软件开发素养来阅读、调试和修改编程语言（如 Python）和 DSL（如 YAML），理解 Version Control System (VCS) 工作流，对 CI/CD 流水线故障进行推理，并参与 Schema 设计决策。他们不需要从零设计数据结构或优化算法复杂度，而是需要对软件实践的操作素养，而非软件工程的第二职业。

进入网络自动化领域的软件工程师，则需要足够深的网络基础，以理解 BGP 收敛为何需要这么长时间、生成树拓扑变化如何传播、在分布式路由表的语境下"最终一致性"意味着什么，以及为什么在实验室中正确运行的自动化在生产环境中可能因厂商实现差异而失败。他们不需要 CCIE，而是需要足够的基础，能够与网络工程师进行有效对话，并在自己的假设出错时及时察觉。

T 型本质上是在领域之间建立清晰定义的接口：每个人都足以理解对方的语言，从而能够清晰沟通、共同调试、做出共同决策，而无需为每一次对话寻找翻译。

T 型并非固定目标，它随着角色的演进而演进。重要的是为每个人识别出深度轴与宽度轴，并构建尊重两者的学习路径。

当 Jordi 提交第一个自动化 Pull Request 时，负责审查的软件工程师留下了十一条评论：变量命名、缺失错误处理、只覆盖了正常路径的测试用例。他第一反应是防御，他已经正确地配置网络十五年了；第二反应是关掉浏览器标签页；第三反应是重新慢慢阅读那些评论，就像面对一台从未接触过的设备发出的接口报错。到第三个 Pull Request 时，他在评论中留下的是问题而非解释，审查者变成了合作者。从某个领域的专家变成新手、再成为另一个领域专家的过程并不舒适，但这正是转型的形态。

13.3.2 基础知识之争#

每个正在推进自动化转型的团队都会提出这个问题：深厚的协议知识在今天还有意义吗？CCIE 认证（或同等资质）还值得追求吗？是的，但方式有所不同。

在自动化时代，基础知识并非变得不那么重要，而是以不同的方式被应用。不理解 BGP 收敛行为的工程师，无法设计可靠的闭环 BGP 自动化；不理解生成树的工程师，无法构建忠实复现生产拓扑故障模式的仿真环境。自动化层叠加在网络之上，其正确性取决于建模网络行为的质量，而这个模型只有在构建它的人深刻理解底层协议时才能是高质量的。

变化的是学习路径。传统认证路线——学习理论、通过考试、在生产中应用——本身没有错，但它不再是唯一可信的路径。问题优先路径已经变得至少同样有效：从一个真实的运维问题出发，构建解决它的自动化，学习该问题所需的特定协议行为或设计原则。认证验证既有知识，先实践再考取往往比先考取再实践更有价值。

CCIE 仍然是深度的强信号。在自动化时代，它所传达的正是自动化所依赖的那种深度。但它单独已无法传达运维时效性：手工配置设备的能力是必要条件，却不再是充分条件。

面向自动化的认证已与传统网络认证并行涌现，验证的是 T 型的横向轴：版本控制规范、API 设计、CI/CD 流水线基础。它们是协议深度的有益补充，而非替代。

13.3.3 AI 对技能要求的影响#

Artificial Intelligence (AI) 编码助手已经显著降低了网络自动化中软件开发的入门门槛。无法凭记忆写出 Python 类的工程师，现在可以通过提示词完成日常自动化任务的可运行代码：解析设备输出、生成配置模板、编写基本的集成脚本。这降低了入门门槛，但并没有降低做好的上限。

AI 辅助无法替代的是：知道何时自动化不应该运行的判断力，诊断以意想不到方式表现的自动化故障的能力，以及将特定自动化工作流与第 4 章至第 12 章所覆盖的更广泛平台设计连接起来的架构推理能力。AI 助手会生成通过你所想到的测试的代码，但不会告诉你遗漏了哪些测试。

这里适用的模式是受监督的同事：像对待称职但资历尚浅的工程师的代码一样对待 AI 生成的自动化代码——审查它、测试它、充分理解它以便在出问题时能够调试，并且拥有它。一旦自动化进入生产流水线，它就是你的，无论你是否亲手打出了每一行代码。

AI 工具链的演进速度远超任何一本书的追踪能力，此处描述的具体能力在您读到时可能已经过时。但底层模式是持久的：将 AI 生成的代码视为与其他任何贡献相同的需要审查和承担所有权的产物，并理解 AI 辅助无法替代工程判断力。

实际需要多少编程知识：足以阅读并理解他人编写的代码、调试常见的故障模式、针对新需求修改现有自动化，以及在代码审查中做出有依据的判断。这是代码的运维素养，而非专业软件开发者的水平。门槛高于"会使用 CLI 工具"，但低于"能从零设计分布式系统"。

13.3.4 技能发展路径#

在完成转型的团队中，有两条具体的发展路径反复出现。

• 对于向平台和自动化角色转型的网络工程师：实践起点是聚焦于阅读和调试而非编写的 Python 基础、VCS 工作流与规范、对 CI/CD 流水线故障的诊断能力，以及 YAML 和 JavaScript Object Notation (JSON) Schema 设计。重点应放在先阅读和调试现有代码上，而非先生成新代码。第一个有意义的里程碑不是"写了一个脚本"，而是"调试了别人的自动化故障并理解了原因"。转型六个月后，Jordi 恰好遇到了这样的情景：一个他没有参与编写的生产工作流中出现了四十行 Python 报错。他的第一反应是转发给团队中的软件工程师，但他没有，而是从头开始逐行阅读，就像当年阅读路由表那样。导致故障的网络特定假设在第 23 行：一个关于 BGP 会话状态的硬编码预设，对任何手工配置过 BGP 的人而言都显而易见，但从未有人想到需要为此写一个测试。他自己修复了这个问题。报错不再是噪声，它成了一张地图。

• 对于进入网络自动化领域的软件工程师：实践起点是 IP 基础、一个研究得足够深入以推理故障模式的路由协议、让网络工程师对变更格外谨慎的运维信任模型（一条错误命令可能让生产网络以 Web 应用 Bug 通常不会带来的方式崩溃），以及跟随网络工程师参与生产故障处理的影子经验。第一个有意义的里程碑不是"理解了网络理论"，而是"知道网络工程师在担心什么，以及为什么"。

flowchart LR
    classDef net fill:#d9e8f5,stroke:#4a7fa5,color:#1a2e3b
    classDef sw fill:#d9f5e8,stroke:#3a8a5a,color:#1a2e3b
    classDef shared fill:#f5e8d9,stroke:#a57a4a,color:#1a2e3b

    subgraph Network["Network Engineering"]
        N1["Protocol expertise - Device behavior - Fault diagnosis"]
    end
    subgraph Overlap["Shared Zone"]
        O1["Automation design - SoT schema - Simulation fidelity - Change trust model"]
    end
    subgraph Software["Software Engineering"]
        S1["Code structure - Testing discipline - CI/CD pipelines"]
    end

    Network --- Overlap --- Software

    class N1 net
    class O1 shared
    class S1 sw

轮岗模式是加速这一过程的实践模式：结构化的跨团队轮岗，让双方都置身于必须向对方学习的真实情境中。网络工程师花两周嵌入软件团队，软件工程师花两周与网络团队一起值守生产。目的不是正式意义上的交叉培训，而是构建让协作长期可持续的共同词汇和相互尊重。

转型两年后，Jordi 在经理发起的一次计划轮岗中，花了三个月嵌入云基础设施团队。他带着怀疑接受了这个安排。云团队不考虑设备或协议，他们考虑的是应用程序对网络能提供什么的假设。这些假设从未被写下来，也经常是错误的。Jordi 回来后构建的自动化，是团队迄今为止第一个从应用层向下建模网络意图（而非从设备层向上）的版本，也是他们交付的最可靠的自动化。Jordi 和他的经理都没有预料到这一点。轮岗并没有把他交叉培训为云工程师，而是给了他一个重新审视自己深刻理解之事物的新框架，这种重新定位正是架构思维在实践中的样子。

回来三个月后，Jordi 为团队开了一次非正式分享，主题是他观察到的应用团队如何建立网络假设的。六名工程师参加，其中两人在听完之后修改了下一个自动化工作流的设计。轮岗不仅仅改变了 Jordi：它通过他，改变了其他工程师思考问题的方式。一个人的学习，经过有意分享，会产生倍增效应。

致工程管理者和团队领导： 本节描述的技能转型，不会通过文档和良好意愿自动发生。它需要时间分配（学习不能只发生在繁重运维负荷的间隙）、心理安全（工程师需要在低风险环境中犯错，这意味着需要实验室访问权限和有意设计的非生产实验时间），以及来自领导层的可见背书——深厚的网络知识在新模式中是有价值的，而非负担。

失败于这场转型的团队，几乎从来不是因为缺乏工具或计划，而是因为工程师感受到学习新技能是在"真正工作"完成之后才能做的事。

13.3.5 实践工具集#

以下工具序列按照网络工程师开始转型的优先级排列。每个阶段的目标不是精通之后再进入下一阶段，而是达到足以有效参与并识别出问题的流畅度。

flowchart BT
    classDef foundation fill:#4a7fa5,stroke:#2d5f80,color:#fff
    classDef automation fill:#3a8a5a,stroke:#2d6b45,color:#fff
    classDef platform fill:#7a5a8a,stroke:#5d4570,color:#fff

    F["**Foundation Layer** - Git · Python · YAML"]
    A["**Automation Layer** - Ansible · Jinja2 · Netmiko/NAPALM · Nornir"]
    P["**Platform Layer** - SoT · Testing · Docker · Kubernetes · CI/CD"]

    F --> A --> P

    class F foundation
    class A automation
    class P platform

基础层（从这里开始）：

• Git：不可跳过的起点。提交、分支、Pull Request、合并冲突解决。自动化平台的其他一切都依赖版本控制规范。在任何自动化工具之前先掌握它。
• Python：聚焦于先阅读和调试现有代码，再编写新代码。第一个里程碑是阅读一条报错栈并理解它在说什么，而非从头写一个类。
• YAML：大多数网络自动化工具的配置语言。理解结构、缩进和数据类型，是使用 Ansible、NetBox 以及大多数 CI/CD 流水线的必要条件。

Python 是今天网络自动化的主流语言，但不是唯一有效的选择。Go 越来越多地用于性能敏感的工具和平台组件，脚本编程的概念可以跨语言迁移。学习 Python 基础的投入是对编程素养的投入，而非对 Python 的忠诚。无论平台使用哪种语言，心智模型都会延续。

自动化层：

• Ansible：网络环境中部署最广泛的执行工具。Playbook、Inventory、Role 和变量优先级。覆盖了大多数配置和配置自动化场景。
• Jinja2：与 Ansible 及大多数配置生成工作流配合使用的模板引擎。理解模板如何根据变量数据渲染，对规模化配置管理至关重要。
• Netmiko 或 NAPALM：Netmiko 处理传统设备的 SSH/CLI 自动化；NAPALM 为支持结构化 API 的设备提供多厂商抽象层。大多数现有网络自动化代码库中会出现其中一个或两者兼有。
• Nornir：Python 原生自动化框架，负责大型设备库存中的连接管理、任务执行和并行处理。Ansible 将 Python 抽象隐藏，Nornir 则将其暴露，因此更适合需要完整编程控制的复杂工作流。

这份列表是学习建议，而非使用建议。这些工具许多在规模化时会暴露出局限，一个设计良好的平台会将它们隐藏在更清晰的接口背后。理解它们如何工作——包括它们的故障模式和边缘案例——正是让工程师能够做出何时使用、何时替换、以及在生产中行为异常时关注什么的有依据决策的基础。

平台层：

• 真实数据源：常见的真实数据源实现。理解 Schema 设计、API 交互，以及自动化如何从 SoT 读取并写回，将执行工具与第 4 章的架构模型连接起来。
• 测试：为自动化代码编写测试。第一个有意义的用途不是编写新测试，而是理解现有测试覆盖了什么以及遗漏了什么。
• Docker 基础：足以运行本地开发环境、理解容器镜像是什么、并能阅读 Compose 文件。不是容器编排，只需足以不再被环境配置阻塞。
• Kubernetes 基础：自动化平台组件（编排器、API 网关、可观测性栈）越来越多地作为容器化工作负载运行在 Kubernetes 上。工程师不需要运营一个集群，但阅读 Deployment 清单、理解 Pod 重启、以及知道如何查看运行中容器的日志，是调试平台问题时经常用到的技能。
• CI/CD 流水线：阅读和理解流水线定义、诊断流水线故障、以及知道故障发生在流水线的哪个阶段。从头编写流水线是之后的事。

工具的顺序比具体工具更重要。一个精通 Git 且能调试 Python 的工程师，对网络自动化团队的价值高于一个装了所有工具却对其一知半解的人。深度来自使用，而非安装。

AI 编码助手并不使这套工具集变得可选。无法阅读自己提示生成的代码的工程师，在代码于生产中失败时无法调试它，在同事提交时无法审查它，也无法向利益相关方解释自动化为何如此行事。上述基础，正是使 AI 辅助安全可用、而非不再必要的前提。

13.4 推动采用#

让一个团队开始使用自动化，是一个与让团队将自动化作为组织级能力来构建和维护截然不同的问题。两者都需要关注，且需要不同的方式。本节聚焦于前者：如何让团队启动，并越过大多数自动化项目在达到自持规模前就停滞的可预见障碍。

采纳阶梯模式命名了三个阶段：试点、规模化、持续。每一级都有不同的成功标准。

1. 试点是证明自动化在至少一个场景中工作得足够可靠，让团队信任它。成功标准不是覆盖率或代码量，而是信任。团队是否真的在重要变更时也使用这个自动化而非手动流程？如果答案是"大多数时候，但重要变更我们仍然手动操作"，那试点并未成功。

2. 规模化是将自动化扩展到更多场景和更多工程师。成功标准是自助服务：没有参与构建的工程师，能否在不询问原始作者的情况下使用该自动化？一个只有构建者才能操作的平台并没有实现规模化，只是把手动依赖从设备 CLI 转移到了自动化工具。

3. 持续是超越原始作者存续的自动化。成功标准是入职：新工程师能否在不需要原团队解释的情况下理解、修改和扩展现有自动化？如果答案是否，那么该自动化只是一个用了更好工具的关键人依赖。

13.4.1 变革阻力模式#

三种阻力模式的出现足够规律，值得命名：

1. 冻结专家模式：拥有最高资历、建立在深厚手动工作方式专业知识之上的工程师，成为自动化最响亮的批评者。这并非非理性。他们的地位、职业轨迹和职业身份受到变革的威胁，远超任何初级工程师。有效的应对是让他们成为自动化的作者，而非受众。设计了第一个自动化工作流的冻结专家，会为其成功而投入；被递上一个完成的平台并被告知去使用的冻结专家，则有动力去挑它的毛病。

2. 隐形 ROI 模式：运转良好的自动化不产生工单，也没有可见活动，只有故障才可见。成功自动化 VLAN 配置的团队可能数月内都没有任何信号表明自动化在产生价值，因为那个信号本该是数百张从未提交的工单。应对此问题需要刻意的量化追踪：记录配置前后的时间、统计避免的故障次数、衡量 Mean Time To Resolution (MTTR) 改善幅度，并让这些数字对利益相关方可见，否则他们只会在自动化出故障时才注意到它的存在。

3. 黑盒模式：自动化只被构建者使用，不是因为他人没有访问权，而是因为他人不信任他们无法看懂的东西。自动化产生正确结果，但对它在做什么或为何这么做没有任何说明。其他工程师绕过它，因为手动流程虽然更慢，但至少清晰可辨。应对方式是将透明度内建进自动化本身：审计日志、逐步执行跟踪、清晰的错误信息，以及在任何操作发生前展示将会发生什么的 Dry Run 模式。信任随理解而来。无法解释自身行为的自动化系统，永远赢不到作者圈子以外的采纳。第 2 章第 2.1 节奠定了在自动化中建立信任的基础：可理解、可预测、易用等特质，并非叠加在可运行系统之上的功能，而是让系统值得信赖到足以被使用的前提。

13.4.2 采纳度量#

采纳度量不能靠统计脚本数量或代码行数。以下度量追踪团队是否真正在拥抱自动化：

• 自助服务比例：无需网络团队直接介入即可完成变更的比例。高自助服务比例意味着应用团队、安全团队和其他消费者能够独立操作该平台。
• 手动逃逸率：工程师绕过自动化直接访问设备的频率，以及原因。部分绕过是合理的（自动化尚未覆盖该场景），其他则表明存在信任赤字。追踪原因与追踪数量同样重要。
• 新自动化从立项到生产的时间：从"这件事应该自动化"到"这在生产中运行"的时长。过长的周期表明存在流程摩擦，会降低团队将新事物自动化的动力。
• 入职时间：新团队成员做出第一次有意义自动化贡献所需的时间。这个指标同时衡量文档质量、代码库清晰度和环境配置摩擦。

13.5 持续运营平台#

到达采纳阶梯的持续阶段并不是问题的终点。进入生产并赢得信任的自动化，仍然需要积极的组织支持，才能随着团队增长、代码库老化、以及构建它的工程师离开而保持健康。本节的实践针对的是与采纳不同的挑战：不是如何开始，而是如何持续。

13.5.1 DevOps 与敏捷的传承#

本章描述的模式并非起源于网络工程，它们是在过去十年软件工程组织中——首先是 Web 运维（DevOps 运动），然后是产品开发（敏捷方法论）——经过磨砺后得出的。

DevOps 解决的是想要快速交付的开发团队与需要保障稳定性的运维团队之间的结构性张力。解决方案不是让运维团队接受更多风险，而是整合开发与运维实践，使部署可靠性成为共同责任。同样的张力存在于网络自动化中：想要交付新工作流的自动化开发者，与需要生产稳定的网络运维工程师。DevOps 的传承在这里直接适用：对自动化流水线的共同所有权、生产前的自动化测试、以及通过无责事后复盘来改进系统而非追责。

敏捷方法论解决的是另一个问题：如何在不需要完整前期规格说明的情况下，在复杂系统中增量交付价值。自动化的等价物是上述采纳阶梯：在尝试全面覆盖之前先交付一个可运行的试点，增量扩展覆盖范围，并将每个增量视为在下一个增量开始之前必须能够正常工作的东西。这听起来显而易见，但与网络项目传统的范围界定方式相冲突：部署之前的完整设计，生产使用之前的全面覆盖。

从软件工程文化中借鉴，不是为了采用其词汇，而是为了应用那些通过十年相似组织挑战赢得的解决方案。要避免的失败模式是语义采纳：团队将他们的变更流程改称"CI/CD"，将季度规划叫做"Sprint"，宣称自己是 DevOps 组织，同时保留着那些运动专门为打破的每一个行为习惯。信号是一个拥有自动化流水线却仍然需要四周 CAB 审批的团队，即使对流水线将执行的每一个变更也不例外。词汇改变了，文化没有。

13.5.2 新变更管理#

自动化不会消除变更管理，它会改变变更管理。

传统网络变更管理建立在计划窗口、手动审查和显式审批链之上，因为每个变更都是由可能犯错的人手动执行的操作。流程的存在是为了减慢从决策到执行的路径，在其中加入人类发现错误的检查点。

自动化改变了风险特征。当一个变更被自动化后：它在自动化编写时就被审查过（而非在运行时），它在进入生产前经过了测试，并且自动生成了审计跟踪。在一个过去一年中成功无故障执行了三百次的例行配置操作之前，要求四周变更冻结的理由已经大为削弱。

自动化赋能的变更管理是赢得的，而非宣告的。一个团队在未完成试运行和受监督阶段的情况下宣布已转向自主执行，并没有降低风险，而是将其隐藏了。信心阶梯只有在每个阶段都基于真实执行历史而非政策决定或经理对自动化"大概没问题"的信心诚实完成时，才真正有效。

向自动化赋能变更管理的过渡是增量赢得的。信心阶梯模式命名了这一进程：自动化分阶段赢得自主权。新自动化首先以试运行模式运行，生成执行预览但不做任何变更；经过足够多的成功试运行和人工审查后，赢得受监督执行：变更被应用，同时有工程师主动监控并随时准备干预；经过足够多的成功受监督运行且无需干预后，赢得该类变更的自主执行权，转为例外驱动的人工监督。

这个过程折射出一个好工程师对待初级同事的信任模型：自主权通过可靠性的展现来赢得，而非事先授予、失败后再收回。

13.5.3 学习与文档文化#

未经记录的自动化会随其作者的离去而消亡。这不是陈词滥调，而是每次关键自动化工作流的构建者离开团队时都会出现的模式。

自动化中的文档挑战是一个架构问题，而非写作问题。事后单独作为产物撰写的文档几乎总是不完整的，几乎总是会过时的。能够存续的文档嵌入在自动化本身中：能够自描述的 Schema、解释发生了什么的试运行输出、结构足够清晰以至于阅读它能回答大多数问题的代码，以及捕捉非显而易见选择的架构决策记录（ADR）——记录为何选择此设计而非备选方案、哪些约束条件塑造了决策——而非描述代码做了什么。

支持这一点的团队实践，是将文档作为自动化审查的质量标准，而非关闭工单前要完成的任务。一个缺乏清晰试运行模式、可读审计输出和记录故障行为的自动化工作流是不完整的，不是因为文档缺失，而是因为这些能力本身就是使自动化值得信任的组成部分。

转型一年后，Jordi 与一名没有网络背景的初级工程师搭档。她问他，为什么自动化在移除对等体之前要检查 BGP 会话是否活跃，而不是直接发出移除命令。Jordi 花十分钟写了这个检查，从未记录过。他解释道：移除一个仍在通告路由的对等体会造成流量黑洞，需要完整的路由协议收敛时间才能恢复，在园区网络中通常是三十秒或更长，这对于一个配置工作流来说是不可接受的中断。在解释的过程中，他意识到该检查有一个他未曾编码的第二层含义，他将两点都写了下来。三周后，那名初级工程师在第二个含义中发现了一个逻辑错误。教授的行为让自动化比他最初的推理更好。他没有预料到这一点，但此后每次都是如此。

13.5.4 知识沉淀与开源#

机构记忆问题随时间推移而加剧。一个有三年自动化历史且人员流动显著的组织，积累了大量嵌入在没有任何现任团队成员完全理解的代码中的未记录决策。

降低这一风险的是流程实践，而非工具实践。代码审查作为强制性的知识传递：不理解代码为何如此编写的审查者，没有资格批准它。在自动化任务上进行配对工作，其中知识传递是与交付并列的主要目标。针对非显而易见设计选择的架构决策记录，作为积累平台当前形态背后推理的活文档来维护。

AI 辅助开发的节奏引入了这一问题的特定变体。当工程师使用 AI 工具快速生成自动化代码时，结果可能在行为上达到生产级别，但在理解上是孤立的：团队中没有人完全知道代码为何如此构建、考虑了哪些边缘情况、或其中嵌入了哪些假设。代码运转直到不再运转，当它失败时，调试链从零开始。第 13.3.3 节的受监督同事模式是应对措施：AI 生成的代码需要与任何贡献者的代码相同的审查和所有权转移，以及额外的纪律——记录生成过程未明确说明的内容。

开源网络自动化工具贡献了一种不同类型的知识沉淀：跨越众多组织而非单一组织积累的共同词汇和共同故障模式。构建在开源工具上的团队继承了更广泛社区的调试、设计和运维经验。当他们遇到社区已经记录的故障模式时，他们能够识别出来。回馈社区——哪怕是小的修复或文档改进——能够构建团队有效参与这一知识库的能力。这是一项组织能力，而非仅仅是技术选择。

13.5.5 伦理与人文影响#

全面自动化以行业尚未完全厘清的方式转移了责任归属。

当一名人类工程师执行了导致停机的变更时，责任归属是清晰的：一个人做了一个决定。当一个自动化系统执行了导致停机的变更时，责任链更长且更难追溯：编写自动化的工程师、批准它的工程师、配置触发器的工程师、批准自主执行策略的经理。相关的法律和组织框架仍在发展中。

AI 维度加剧了这一问题。当一个 AI 驱动的编排系统自主做出路由决策（如第 17 章所述）时，从人类意图到网络行为之间包含了一个无法像确定性代码那样完整审计的推理层。AI 系统可能以工程师未曾预料的原因得出正确的行动，也可能以同样的原因得出错误的行动。当自动化出错时，“谁负责？“这个问题会变得真正困难。

这并不意味着应该回避自主运营，而是意味着自主行动的范围、触发人工升级的条件，以及允许事后复盘的审计跟踪，必须与自动化逻辑本身一样经过严格设计。无论自动化成熟度如何，两条原则始终适用：自主行动应当是有界的（自动化知道自己无权做什么并停止），以及系统应始终能够解释它做了什么、为何这么做、以及在不同情境下本会如何处理。

13.6 跨域协作#

网络团队花了六个月构建可靠的防火墙规则配置自动化。安全团队也做了同样的事，构建了安全组策略执行的自动化。两个平台都运转良好，都通过了试点，都在生产中运行。

然后，网络团队对一个园区区域进行了重新分段，以隔离一批新的物联网设备。变更经过了自动化、审查，并针对网络的真实数据源正确执行。四十分钟后，安全团队的策略引擎开始生成违规：新网段不存在于安全真实数据源中，因此来自它的流量与任何已批准策略都不匹配，被悄无声息地丢弃。两个自动化都没有 Bug。网络自动化正确执行了预期的网络变更，安全自动化正确执行了预期的安全策略。故障来自两者之间共享模型的缺失。停机持续了四个小时，两个团队的工程师手动重建了两个自动化系统本应共同掌握的信息。

本章描述的文化转型不会局限于单一团队内部发生。能够交付有意义组织价值的网络自动化，总是会触及其他领域：安全策略执行、云基础设施管理、服务交付工作流。那些边界处的组织摩擦，正是大多数成熟自动化项目停滞的地方。

问题是结构性的。NetOps、SecOps 和 CloudOps 通常各自演进出独立的自动化能力，具有不同的真实数据源 Schema、不同的变更管理仪式，以及相互重叠但不集成的工具链。每个系统在其自身领域内工作正确，却对另一个做了什么毫无感知。上述故事中的失败不是例外，而是跨域自动化未经刻意设计时的默认结果。

13.6.1 治理与赋权的平衡#

每个跨域自动化项目都面临同样的张力：平台团队想要标准化，因为标准化是共享工具可行的前提；领域团队想要自主权，因为他们的需求无法完全纳入标准。

实践中行之有效的解决方案是铺路模式，由平台工程社区（尤其是 Netflix 等大规模运营组织）发展出来：平台团队构建一条光线充足、维护良好的路径，比绕开它更容易使用。他们不禁止替代方案，不强制采用，而是将好路径变成容易走的路径，并接受部分团队出于正当原因会走野路。

一个持续涌现的所有权问题：谁拥有网络作为物理和协议产物与网络作为自动化目标之间的边界？网络工程师拥有网络设计、协议行为和意图模型的正确性，网络自动化工程师则拥有实现该意图的平台。实践中这些所有权边界持续模糊，最有效的团队将其视为具有清晰升级路径的共同责任，而非清晰的划分。

跨域自动化项目在领域团队之上没有单一可追责负责人时，总是会停滞。没有总监或 VP 级别的共享责任点，治理与赋权的平衡仍然是优先级相互竞争的同级之间的谈判，而非有明确仲裁者的受管理张力。平台团队无法解决自己没有被授权解决的跨域冲突。责任结构必须在架构能够运转之前就已存在。

13.6.2 共享平台与联邦自动化#

跨域协作背后的架构问题是：自动化应该汇聚到共享平台，还是保持跨领域工具的联邦化？

可扩展的模式两者都不是极端。共享数据层，联邦执行。一个持有跨域意图（网络拓扑、安全策略、云资源分配）的单一真实数据源，具有一致的 Schema 和访问模型。领域特定的执行工具（网络自动化平台、安全策略引擎、云配置系统）从共享数据层读取并将结果写回。

这种架构允许领域工具独立演进，同时维护跨域工作流所需的共享上下文。替代方案——一个覆盖所有领域的统一自动化平台——在不同需求、不同变更速度，以及哪个团队的优先级驱动平台路线图的组织政治重压下，持续失败。

这一架构选择与第 11 章的规模化模式直接相关。具有共享数据层的联邦执行模型有特定的一致性要求：数据层必须具备足以协调安全策略变更及其网络执行的一致性，同时又足够松耦合，以至于网络变更不会阻塞等待云基础设施同步。

13.6.3 嵌入式协作#

委员会式的跨域团队协调，不会产生好的跨域自动化，只会产生会议。产生可运行自动化的模式是嵌入式协作：来自不同领域的工程师在具体自动化问题上并肩工作，而非在定期审查会议中协作。

一个实践模型是跨职能小队：一名网络工程师、一名安全工程师、一名云工程师，在限定时间内共同构建特定的跨域自动化能力。小队对所构建的内容拥有交付和持续运营的所有权。轮岗确保每个领域的从业者对其他人的约束条件具备实际工作知识，而非通过交接和翻译层运作。

跨职能小队只有在其成员真正专注于小队使命时才能有效运作。每个成员仍然承担着其领域团队全部工作量的小队，不是小队，而是一个换了名字的委员会。有效的跨域自动化需要管理层承诺保护小队成员的时间。没有这种保护，小队会默认走阻力最小的路径——每个人做适合其现有领域角色的工作，跨域集成永远无法完成。

跨域 SLO 将这种协作正式化。当一个自动化工作流跨越领域边界时，端到端工作流的可靠性预期不能由单一领域团队拥有。定义共享 SLO 需要双方理解彼此的故障模式，并协商对结果的共同所有权。谁拥有一个起源于网络变更、表现为安全策略违规的自动化故障？答案不能是"事件工单系统先路由到谁就是谁的”。

flowchart TD
    classDef shared fill:#d9e8f5,stroke:#4a7fa5,color:#1a2e3b
    classDef domain fill:#d9f5e8,stroke:#3a8a5a,color:#1a2e3b

    SoT["Source of Truth - Cross-domain intent"]

    subgraph Domains["Domain Execution Layer"]
        direction LR
        NP["Network Platform"]
        SP["Security Policy Engine"]
        CP["Cloud Provisioning"]
    end

    Obs["Observability - Cross-domain telemetry"]

    SoT --> NP & SP & CP
    NP & SP & CP --> Obs
    Obs -.->|"feedback"| SoT

    class SoT,Obs shared
    class NP,SP,CP domain

13.7 总结#

第 13 章论证了网络自动化中最难的问题，有些并非技术问题，而是组织问题：谁来做这项工作、如何学会做好它、组织如何在第一波采纳之后持续推进，以及历史上各自为政的团队如何共同构建系统。

三个主题锚定本章：

• 角色演进，而非消失。 从网络运维到平台工程的过渡，是一张转型地图，而非替代图表。深厚的协议知识在自动化时代并非变得不那么重要，而是以不同的方式被应用：从执行配置变为设计能够正确执行配置的系统。第 13.2 节描述的五种新兴角色，正是 T 型技能发展路径所指向的目的地。

• 采纳需要主动设计。 采纳阶梯（试点、规模化、持续）命名了具有不同成功标准的三个阶段。越过第一级需要的是信任，而非覆盖率；越过第二级需要的是自助服务；越过第三级需要的是超越作者存续的自动化。阻力模式（冻结专家、隐形 ROI、黑盒）是具有已知应对策略的可预见障碍（第 13.4.1 节）。持续这种采纳需要一套不同的习惯：DevOps 与敏捷的传承、与自动化风险特征相匹配的变更管理模型、嵌入在自动化本身中的文档，以及在团队人员更替中存续的知识沉淀（第 13.5.1 节至第 13.5.4 节）。

• 跨域协作是架构性的，而非组织性的。 三国分治问题（NetOps、SecOps、CloudOps 各自在孤岛中运营）无法通过善意或治理授权来解决，而是通过共享数据架构来解决：一个具有一致 Schema 的单一真实数据源、从中读取的联邦执行工具，以及拥有领域间边界所有权的嵌入式跨职能小队。铺路模式是使其在不要求每个团队汇聚到单一平台的情况下运转的治理模型。

第 14 章将从不同角度延伸组织维度：将自动化不只视为一种工程能力，而是一个产品，具有自身的生命周期、利益相关方模型以及衡量业务影响的方式。

参考文献与延伸阅读#

• 《凤凰项目》，Gene Kim、Kevin Behr、George Spafford（IT Revolution Press，2013）。以小说形式讲述 IT 组织在压力下进行 DevOps 转型的故事。组织动态、开发速度与运维稳定性之间的冲突，以及共同所有权的涌现，与本章描述的自动化项目动态高度契合。

• 《DevOps 实践指南》，Gene Kim、Patrick Debois、John Willis、Jez Humble（IT Revolution Press，2016）。《凤凰项目》的实践伴侣：三种方式（流动、反馈、持续学习）、部署流水线与无责事后复盘。本章 DevOps 传承部分的内容以这些基础为依据。

• 《团队拓扑》，Matthew Skelton、Manuel Pais（IT Revolution Press，2019）。围绕快速软件交付设计团队结构的权威框架。流对齐团队、平台团队和赋能团队的概念，直接对应第 13.6 节讨论的跨域协作与嵌入式小队模型。

• 《加速》，Nicole Forsgren、Jez Humble、Gene Kim（IT Revolution Press，2018）。基于研究的分析，探讨哪些组织和技术实践能够预测软件交付绩效。四项关键指标（部署频率、交付周期、变更失败率、恢复时间）为第 13.4.2 节的采纳度量提供了量化基础。

• 《设计变革》，Tim Brown（HarperCollins，2009）。介绍 T 型工程师模型及其背后的设计思维方法。IDEO 对深度领域专业知识与跨学科素养相结合的阐述，是第 13.3 节技能转型路径的基础。

💬 Found something to improve? Send feedback for this chapter