1.1 术语

在讨论运维云服务时，我们用到的术语混合了云原生中的“现代”概念以及来自早期系统的“传统”概念（其中许多已经被云计算领域所吸收，但仍然保留了一些传统的运维语言）。在云计算和电信行业的交汇处尤其如此，电信行业拥有极其丰富的网络运维词汇。

在使用云计算相关术语的时候，有时会让人感到困惑，而背后的原因是我们正处于从基于专用设备构建网络系统过渡到在廉价商用硬件上运行基于软件定义服务的过程中。这常常导致多个术语被用于表述同一个概念，而更麻烦的是，一个领域巧妙地重新使用了另一个领域的某个术语，但是彼此的含义不同。为了避免彼此混淆，我们首先定义几个概念并介绍相关术语。

● 运营与维护（Operations & Maintenance，O&M，简称“运维”）：一个传统术语，用于描述网络运维的整体挑战（工作），一般来说，运营商通过运维接口来管理整个系统。

〇 FCAPS：这是Fault（故障）、Configuration（配置）、Accounting（计费）、Performance（性能）和Security（安全）这五个词的首字母缩写，历史上用于电信行业中列举对一个操作系统的需求。运维接口必须提供故障检测和故障管理、系统配置、使用情况统计等功能。

〇 OSS/BSS：电信行业的另一个缩略语，全称为运维支持系统（Operations Support System）和业务支持系统（Business Support System），指实现运维逻辑（OSS）和业务逻辑（BSS）的子系统，通常是整个运维架构中处于最顶层的组件。

〇 EMS：电信行业的另一个缩略语，全称为组件管理系统（Element Management System），对应于整个运维架构中的中间层。EMS之于特定类型的设备，就像OSS/BSS之于整个网络一样。

● 编排（Orchestration）：一个与运维类似的通用术语，起源于云计算领域，表示为某些工作负载组装（例如分配、配置、连接）一组物理或逻辑资源。如果只涉及单个资源或设备，我们会使用“配置”这一术语，而编排通常意味着跨多个组件进行“编排”。

从狭义上来说，编排器负责启动虚拟机（或容器），并通过虚拟网络将它们在逻辑上连接。从广义上来说，编排包含本书中描述的与管理相关的功能的方方面面。

如果你尝试将云计算术语映射到电信术语，则编排器通常等同于OSS/BSS的云化版本。这个最顶层的组件有时被称为服务编排器（Service Orchestrator），负责将一组虚拟网络功能（Virtual Network Function，VNF）组装成一个端到端的服务链。

〇 剧本/工作流（Playbook/Workflow）：实现多步骤编排过程的程序或脚本。在UX领域中，术语“工作流”也用于描述用户使用GUI在系统上执行的多步骤操作。

● 配置（Provisioning）：向系统中增加资源（物理或虚拟资源），通常是响应工作负载的变化，也包括初始的部署。

〇 零接触配置（Zero-Touch Provisioning）：通常表示添加新的硬件到系统中，不需要人工配置（除了物理连接设备外）。这意味着新组件会自动完成自身相关的配置。这个术语也可应用于虚拟资源（例如虚拟机、服务），以表明不需要手动配置就可以实例化资源。

〇 远程设备管理（Remote Device Management）：一种定义了远程管理硬件设备的标准（如IPMI、Redfish），用于支持零接触配置。主要的想法是通过局域网发送和接收带外消息，而不是通过视频或串口控制台访问设备。此外，远程设备管理系统可以与监测和其他设备健康遥测系统集成。

〇 库存管理（Inventory Management）：规划和跟踪物理设备（机架、服务器、交换机、电缆）和虚拟资源（IP范围和地址、VLAN列表）是配置过程的一个子步骤。我们通常可以从使用简单的电子表格和文本文件开始，但随着复杂性的增加，库存专用数据库有助于提高自动化程度。

● 生命周期管理（Lifecycle Management）：随着时间推移，不时地执行升级和替换功能（例如部署新服务以及为现有服务增加新特性等）。

〇 持续集成/持续部署（Continuous Integration/Continuous Deployment，CI/CD）：一种生命周期管理方法，在这种方法中，从开发（开发新功能）到测试、集成和最终部署的路径是一个自动化的流水线。CI/CD通常意味着持续进行小的增量修改，而不是进行大的破坏性升级。

〇 DevOps：一种软件工程原则与实践，融合了开发过程和运维需求，并试图打破两者壁垒，在特性开发速度和系统可靠性之间实现平衡。作为一种实践，DevOps使用了CI/CD方法，并通常与基于容器（也称为云原生）的系统相关联，典型例子是谷歌等云厂商实践的站点可靠性工程（Site Reliability Engineering，SRE）。

〇 服务不间断软件升级（In-Service Software Upgrade，ISSU）：要求组件在升级过程中继续运行（服务不间断），从而将交付给最终用户的服务的中断降至最低。ISSU通常意味着拥有能够增量滚出（和回滚）升级的能力，但具体来说是对单个组件的需求（与用于管理一组组件的平台相反）。

● 监控和遥测（Monitoring & Telemetry）：从系统组件收集数据用以帮助做管理决策。这包括故障诊断、性能调优、进行根因分析、执行安全审计和配置额外容量。

〇 分析（Analytics）：从原始数据产生额外洞察（价值）的程序，通常会使用统计模型。它可以用于关闭控制回路（即基于这些洞察自动重新配置系统），也可以为随后需要采取某些行动的运维人员提供帮助。

另一种谈论运维的方式是用阶段来描述，这在传统网络设备运维中很常见：

● 第-1天：设备首次上电后执行的硬件配置（如通过控制台）。这些配置对应于固件（BIOS或类似的）设置，并且通常需要了解设备如何以物理方式连接到网络（例如需要使用的端口）。

● 第0天：在设备和可用网络服务之间建立通信连接所需的配置（例如设置设备的IP地址和默认路由）。虽然这些信息可能是手动提供的，但我们可以使用自动配置设备来实现零接触配置。

● 第1天：我们需要对设备做服务级别相关的配置，包括允许设备使用其他服务（如NTP、Syslog、SMTP、NFS）的参数，以及设置设备能对外提供服务所需的参数。在第-1天运维结束后，设备就应当是正常运行的，并且能够处理用户流量。这也是零接触配置的一种场景，因为预编程的剧本（工作流）应该能够自动配置设备，而不需要依赖人工干预。

● 第2天到第N天：支持对日常运维做持续管理，包括监控网络以检测故障和服务降级，以实现维持服务等级的目标。这可能涉及一些闭环控制，但通常仍需要大量人工操作，包括监控仪表盘和发送告警，然后根据运行状态重新配置系统。这通常被简称为“Day 2运维”。

同样，“Day x”是传统网络供应商对其销售设备运维过程的描述，这反过来又决定了网络运营商和企业系统管理员如何运行这些设备。虽然通用框架已经扩展到虚拟网络功能（VNF），但其操作视角仍然是以设备为中心。但是一旦一个系统变成云原生系统，两件事就会改变大家关注的重心。首先，所有硬件都是商品化的，因此Day 0和Day 1的配置将完全自动化，并且由于所有设备都是相同的，因此Day-1的配置工作将被最小化[4]。其次，Day 2的操作过程将变得更加复杂，因为基于软件的系统更加敏捷，这使得功能升级更为普遍。对特性开发速度的关注与追求是基于云计算或者云原生系统的内在价值之一（或者说是一种保证），但这也给我们的管理带来了一系列挑战。

本书旨在解决这些管理挑战，并对我们常用的两个词运维（Operating）和可运维化（Operationalizing）做了最终解释。能够运维一个云是我们的终极目标，这是一个持续改进的过程，而使云可运维化意味着我们将一组软硬件配置到一种状态，使得我们能够轻松进行日常的运维操作。这种区别是相关的，因为使云可运维化不是一次性的操作，而是日常运维的一个基本方面。快速演进是云最重要的特性之一，这使得持续可运维化成为运维边缘云的关键需求。