SG-ITOM中基于场景自动化的工具中心系统设计

程仲汉 陈淑珍 丁强

（1.福建警察学院 计算机与信息安全管理系 福建省福州市 350007）

（2.网络安全与执法技术福建省高校工程研究中心 福建省福州市 350007）

在国家电网公司（简称国网）持续推进建设新一代能源互联网，力争实现“一强三优”的战略背景下，信息通信运维支撑能力的重要性被赋予了更高的要求。由于国网软硬件和网络结构的体量极其庞大且复杂，并具备特殊的层次性和多样性，决定了其难以运用现成的互联网公司运维体系。从央企横向对比来看，也没有成功的自动化运维经验可以横跨国网信息通信体系的四大层次，即电信层、IDC 层、应用层、端层[1,2]。

2017年，国网提出要创新运维技术架构，将信息通信运维从传统人工模式向自动化、场景化、智能化模式转变[3,4]。基于运维场景自动化的顶层设计SG-ITOM（State Grid-Information Telecommunication Operation Management）[5]应运而生，目前已发展至3.0 版本。SG-ITOM 的核心思想是场景自动化，架构上是将运维过程解耦在不同的中心子系统完成，每个中心各司其职，这样就可以将各个网省子公司分散杂乱的运维工作纳入统一管理。但是，顶层设计只能用于指导思想和制定标准，支撑场景自动化目标需要实际的系统产品。因此，本文针对SG-ITOM 3.0 的核心子系统工具中心提出系统设计，阐述系统的目标定位、功能设计和技术架构，进一步细化了顶层设计并推进其实用化，可为日后的系统设计与研发奠定基础。

1 SG-ITOM场景自动化

如图1 所示，SG-ITOM 场景自动化的思想是将传统的运维操作编排为场景，以场景为主体，以运维对象为客体，由手动执行或规则触发的方式执行。当软硬件发生状态变化（如服务器负荷过大）时，触发对应的运维场景（扩容场景），并调用相应的工具或指令（扩展集群节点）完成自动化运维。SG-ITOM 共包括八大中心子系统，其中场景中心和工具中心是整个顶层设计的核心模块。场景中心是连接其它中心的命令枢纽，并调用工具中心完成实际的工作。工具将自动化运维工作抽象为比场景更细粒度的单元，工具中心是统一管理运维工具的平台。

2 工具中心概述

2.1 工具定义

工具是用于实现某个运维专项功能如web 应用部署、主机巡检等，且以运维对象或数据为操作客体的脚本、Docker 容器[6]或agent（主机代理）。一般来说，执行逻辑比较简单的程序以脚本形式来编写，而难以用脚本语言实现的工具则封装在Docker 容器里。前者通过agent 指令通道来调度运行，并操作运维对象。后者通过运行在集中的容器云中并对外提供服务如web service，进而间接地影响运维对象。工具按照不同的功能大体分为12 类，如图2 所示。

2.2 工具中心目标

图1：SG-ITOM 场景自动化的总体流程图

图2：各类工具示例图

图3：工具中心的运行流程图

图4：工具中心的功能架构图

图5：工具中心的技术架构图

作为SG-ITOM 3.0 的核心技术支撑架构，工具中心在功能和技术方面规范化运维工具的准入机制、管理标准、运营标准以及计费标准，统一管理国网各单位的运维组件，避免重复建设。图3 给出工具中心作为SG-ITOM 中的子系统之一的运行流程。如图3 所示，工具的执行是通过场景中心调用工具中心指定的工具来触发，实现运维的专项功能，进而作用于运维对象得到用户想要的结果。工具在准入环节就应按照接口规范对外提供相应API 描述和输入输出参数说明，以便场景中心来统一调用。

工具中心的管理范围包括两个层面：

（1）执行层面。将工具在执行环境中上线启动，供用户和场景中心调用。

（2）运营层面。借鉴互联网软件的运营模式，如苹果公司的应用商店，建立工具从注册上线、审核、发布、评价、计费、下线的整个生命周期。

工具中心建设的总体目标如下：

（1）统一准入标准。工具中心统一所有运维工具的准入机制，包含各类运维工具的注册和审核，统一工具发布的入口，保证将来工具使用的合规性、安全性和可用性。

（2）工具统一管理。工具中心对运维工具进行统一的全生命周期管理，统一不同厂家、不同工具的交付形式，简化部署过程，简化配置，简化工具的升级，规范工具的版本及下线管理。

（3）统一执行接口。为工具制定统一的调用接口。这样，在标准的自动化运维场景脚本的支持下，就可以通过场景中心作用于工具之上，实现“一次编排，到处部署”。此外，通过配置引擎及监控功能实现工具根据负载情况进行动态伸缩，提高工具的可用性。

3 功能设计

如图4 所示，工具中心为两级部署架构，一级工具中心作为国网统一工具仓库，是各二级工具中心的通用工具权威源，负责整个国网的通用工具统一准入和全生命周期管理。二级工具中心为各网省公司的工具仓库，存放来自一级工具中心的通用工具，负责各网省自建工具的准入、全生命周期管理，并作为工具最终的运行平台，对外提供工具调用及监控服务。因此，部署在不同层级，系统的功能有所差异，具体包括以下一级功能：

（1）工具准入。为自动化工具的上传注册、审核、发布提供功能支持，保障进入工具中心的工具的安全性和规范性。

（2）工具管理。为已经发布的运维工具提供全生命周期管理，包括工具的展现、搜索、下载、描述编辑、下线、删除、更新和版本管理等基本管理功能。另外，二级工具中心功能上支撑场景中心对工具的调用、启停、脚本类工具的执行。

（3）运行管理。仅存在于二级工具中心，负责响应场景中心对工具的调用，包括工具的分发启停、运行资源调控以及对工具运行状态、操作执行进度进行监控。

（4）工具评价。支持用户对工具发表文字评论和打分评价，其中打分评价将作为精品推荐功能的主要依据指标。

（5）工具计费。支持多种方式计费，并支持后续计费方式的扩展，在结算环节提供多种支付方式，支持接入第三方支付平台。

（6）统计分析。支持对工具下载量进行下载排行，依据工具下载量、使用量、评分等进行同类工具的精品推荐，支持日志记录用户在工具中心的操作行为。

4 技术架构

系统在技术架构上分为接入层、传输层、存储层、执行层和业务层，图5 给出系统的分层次技术架构图。

4.1 接入层

接入层提供各类工具接入的标准及规范，并为各类工具的接入提供统一的接入服务。接入层是所有工具的接入到工具中心的统一入口，按照工具的特性提供脚本类工具接入和容器类工具接入服务，并完成工具接入过程中的各种标准规范、安全性等的审核及检测，从而实现工具接入的流程化和标准化，保证接入工具的安全性。

各类工具按照工具中心的准入管理规范，将工具相关文件，包括程序包、脚本、Docker 镜像、工具描述语言TDL（Tools Describe Language）、工具附属文件等进行统一打包，通过接入层上传。对于接入的工具，接入层通过工具审核服务对工具进行审核（包括由审核专家人工审核以及通过机器进行自动化测试）。对于符合接入条件的工具，接入层调用传输层提供的数据传输服务，将工具相关文件数据发送给存储层。对于Docker 容器类工具，接入层的容器封装模块负责将Docker 容器类工具的程序包及其依赖的运行环境封装为工具镜像。

4.2 传输层

传输层用于支撑工具中心内部控制命令和文件数据的传输、接入层与存储层之间的工具介质数据传输、工具仓库与工具执行环境之间的部分工具数据交换以及业务层与后台的数据交换。传输层需要使用文件加密技术保证数据传输过程中的安全性，同时通过数字签名技术保证文件传输过程中的完整性。

传输层根据工具介质数据的大小等特性，主要提供两种数据传输服务：

（1）消息中间件服务。主要为控制命令、脚本文件等数据量比较小的数据提供传输服务，推荐采用市面上主流的消息中间件技术实现，如RabbitMQ、ActiveMQ、ZeroMQ 等。在消息传输的技术选型上，需要综合考虑准确性、实时性、可扩展性，以及消息服务器主备方案（例如使用三台消息服务器两两互为主备），以防单点失效。

（2）文件传输服务。主要为容器等数据量比较大的工具介质数据提供传输服务，其协议由存储层的技术路线来决定。

4.3 存储层

存储层通过传输层接收接入层传输的数据，并集中存储三类数据：工具介质数据、工具运行的过程数据以及工具中心自身的业务数据。根据不同的数据类型，存储层在技术路线设计上需要考虑数据存储的可用性、扩展性以及数据存取性能。

工具介质指的是工具文件以及工具启动所必须的文件，将其按工具的来源地区、厂商、功能分类、名称和版本号等作为目录结构来分级存储不同工具的介质。按工具的运行方式，工具介质可分为四类：Docker 镜像、程序包文件、脚本文件以及附属文件（如TDL、数据库初始化脚本、相关文档等，列于工具文件清单中）。Docker 镜像分块存储于镜像仓库中，而其它介质数据作为启动容器的基础数据，数据量较为庞大（TB 级），因此采用分布式文件系统HDFS 作为公共存储以扩展其存储能力。

对于工具（主要是容器类工具）运行过程中的数据，细分为结构化数据和非结构化数据。前者可存储于Oracle 或Mysql 中，后者可存储于NFS 服务器或CephFS 服务器。工具通过远程挂载技术或文件传输协议与外部的文件系统交换数据。由于在执行层中运行的工具数量很多，涉及的运行数据量也很庞大，所以在数据库和文件存储方面还需要考虑数据的高并发读写能力和实时处理能力。

4.4 执行层

存储层管理的工具介质可视为工具的静态形式，执行层则是管理工具正式上线并执行后的动态形式。基于存储层中的工具介质及其附属的启动配置文件等，工具中心将工具启动，并为场景中心提供接口服务。场景中心根据工具TDL 文件，传入参数并调用工具中心的执行层来执行工具并获取执行结果。执行层部署于各地网省，由各子公司为其提供和维护相应的私有云资源。

根据工具类型，执行层有几种表现方式：

（1）工具容器PaaS 平台。基于Google Kubernetes[7]实现，各个工具及其运行环境以封装于一体的Docker 容器形式来运行，且互相隔离。提供相同服务的工具可协同并行，以容器集群的方式对外提供统一的REST 接口服务。容器集群的资源管理、容器调度、安全控制、运行监控、请求路由等功能都由Kubernetes 的底层机制完成。容器内部与存储层中的工具运行数据的交互采用Docker 文件远程挂载方式。

（2）由统一Agent 执行脚本，执行层通过向Agent 端推送脚本，并由其执行。

（3）指令通道，通过安全协议远程执行终端指令。

此外，运行中的工具通过与存储层、安全中心、审计中心、日志中心、监控中心、资源配置中心等进行直接交互或间接交互，读写其相应中心的数据。

4.5 业务层

业务层基于统一服务的业务框架层实现面向各类角色的应用服务，实现工具中心的各种功能。业务层及其底层服务的开发需要符合国网统一要求，需采用技术统一、架构柔性、性能高效、安全可靠的企业级信息系统基础框架和公共组件集[8]。业务间在设计上应为松耦合，且各个业务都支持组件式插拔，以便工具中心将来的业务功能扩展。

业务层将工具中心的数据和业务逻辑以REST 的形式统一封装，以RESTful API 的形式对外提供统一的接口服务，由前端或其他业务模块调用。

5 结语

工具中心是国网信息通信运行管理顶层设计SG-ITOM 的核心子系统，与场景中心共同构成了场景自动化的关键模块。它可以将各种运维工具进行标准化的闭环管理，并提供统一的执行环境和接口，以便被场景中心调用，从而实现运维模式向场景自动化转变。本文基于SG-ITOM 3.0 提出工具中心的具体设计，包括功能架构和技术架构，可为研发单位在系统的具体实现时提供思路和依据。