专栏首页信息化运维什么是信息通信运维体系SG-ITOM3.0
原创

什么是信息通信运维体系SG-ITOM3.0

NO.1

为方便阅读下述文章,请理解下表中术语:

序号

术语名称

术语定义

1.

SG-ITOM

State Grid-Information Telecommunication Operation Management,国家电网-信息通信运维管理。

2.

CMDB

Configuration Management Database,配置管理数据库。

3.

LB

Load Balance,负载均衡。

4.

REST

Representational State Transfer,表述性状态传递,一种软件架构风格。

5.

URI

Uniform Resource Identifier,统一资源标识符。

6.

JSON

JavaScript Object Notation,一种轻量级的数据交换格式。

7.

元数据

与所有单位共享的相对稳定不变的定义数据,如资源模型、定义数据等。

8.

主数据

与所有单位共享的相对稳定不变的管理数据,如配置数据、设备信息基础数据等。

9.

统一Agent

在宿主机上采集数据、执行下发指令的程序及其管理系统。

10.

资源配置中心

通过识别、控制、维护,检查企业的IT资源,从而高效控制与管理不断变化的IT基础架构与IT服务,并为其他中心,例如场景中心、工具中心、监控中心、展现中心、公共支撑平台、审计中心和统一Agent等提供准确的配置信息。

NO.2

总体架构

第一条  业务架构

业务架构部分对运维需求及范围进行梳理分析,确定SG-ITOM 3.0技术支撑组件的目标和功能划分。

整个技术支撑平台向下对运维对象进行监测与控制,向上为SG-ITOM3.0规划的业务管理域提供服务支撑,在业务逻辑上隔离运维对象,为业务管理域提供可视化、自动化运维操作,从而实现运维操作自动化、场景自动化。具体业务架构如下图所示:

第二条 应用架构 根据运维需求,对应用所具备的功能进行抽象、设计。按“一平台、一系统、多场景、微应用”的思路,SG-ITOM3.0技术支撑部分包括分析展示中心应用、流程中心应用、监控中心应用、场景中心应用、工具中心应用、资源配置中心应用、采集中心应用、日志中心应用、安全中心应用、审计中心应用和公共支撑服务。从功能耦合度上考虑,中心内部可采用紧耦合设计实现中心内部功能,中心之间采用去核心的分布式设计,实现分布式、扁平化的应用结构。总体应用视图如下所示:

NO.3

各部分功能规范详解

一 、 分析展示中心部分

分析展示中心实现数据分析、业务综合展现和可视化监控管理功能,通过各种数据模型对采集的数据进行统计分析,使其具备故障溯源、影响分析、关联分析、预警预测能力。数据分析涵盖数据报表分析和数据可视化分析两种形式,为日常运维决策分析提供依据;业务综合展现需实现页面展示、文档展示和融合通信展示功能,将展示中心的各类数据、文档以多样化的形式交互;可视化监控管理实现监控数据的可视化、各类监控数据整合功能,如:机房监控数据、场景监控数据。

功能介绍:

1. 综合展现:实现页面展示、文档展示和融合通信展示功能,将展示中心的各类数据、文档以多样化的形式交互。

2. 数据分析:涵盖数据报表分析和数据可视化分析两种形式,为日常运维决策分析提供依据。

3. 自定义图表:使用HTML/Flash/JS图形化界面技术开发展示组件,通过数据可视化技术实现图表功能。

二、 场景中心部分

场景中心是SG-ITOM 3.0技术支撑平台的调度中心,实现对各种运维工具调用的流程化和标准化以及规范运维作业流程。

功能介绍:

1. 场景设计:实现场景的编排、测试、维护和版本管理以及工具在场景中心的注册和更新功能。

2. 场景执行:对已完成审核和注册的场景进行调用执行,包括场景控制、调度以及与其他中心的数据传递功能。

3. 场景监控实现对场景运行状态的集中监控显示,包括场景的过程监控、回放和状态查询功能。

4.场景库是对场景的集中管理,包括场景的注册、分类、搜索功能。

三 、 监控中心部分

监控中心的主体功能模块包括资源监测、监控指标管理、监控对象管理、统计任务管理、性能数据管理和告警管理六个部分,其数据来源主要是统一Agent、采集服务、日志中心、审计中心、CMDB及第三方数据源,经过数据加工处理和数据持久化(入库)之后,可为上层分析展示中心其他模块提供KPI数据服务、展示组件。

功能介绍:

1. 资源监测:监控对象的监测功能,包括服务器监测、网络监测、数据库监测、中间件监测、存储监测。

2. 监控指标管理:对监控指标的管理、维护功能,包括监控指标的维护,指标模板的管理。

3. 告警管理:告警策略的管理功能,包括生成规则、过滤规则、处理规则和关联规则的配置、管理,同时提供告警信息的查询功能。

4. 监控对象管理:监控对象的配置、管理功能,包括监控对象的配置,与监控指标的关联,监控任务的下发,监控任务情况的监控功能。

5. 统计任务管理:统计任务的配置,定时任务的管理,任务执行情况、执行结果的监控。

6. 性能数据管理:通过接口的形式,提供各类监控对象的性能数据的查询功能,包括当前值、实时值、历史值。

四、 流程中心部分

流程中心实现流程管理、流程实例管理、用户任务管理功能并提供统一流程服务。流程管理需实现流程的设计、建模及浏览功能;实例管理可对具体的业务流程实例进行查询、统计和分析并可人工调整流程走向;用户任务管理实现相关人员发起、审批、查看、回退和作废流程任务操作;统一流程服务主要实现与其他中心应用的接口功能。

功能介绍:

1. 流程设计:通过web可视化流程建模工具,可以通过拖拽的方式,快速实现流程搭建,同时对每个人工节点进行相应的属性配置。

2. 数据建模:通过web可视化进行数据库基础表的建立,用户只需要制定字段名称,字段数据类型即可,无需深入进行研究,系统自动生成标准数据库表。

3. 表单设计:通过web可视化拖拽方式,快速实现用户页面结构,所见即所得的页面非常适合非专业人员进行开发。

4. 流程监控:可以查看流程实例相关的信息外,还可以对流程实例进行挂起、恢复、删除操作。

五 、 工具中心部分

工具中心是以工具为单元对自动化运维工具集合进行管理的应用。工具中心实现工具准入、工具管理、运行管理、工具评价、工具计量、统计分析和服务订阅功能。

功能介绍:

1. 工具准入:应支持通过开发者账号上传工具及附件,支持自动和人工审核工具的合规、合法、安全性,能够对通过审核的工具进行发布上架操作。

2. 工具管理:应支持工具发布后的全生命周期管理,包括但不限于工具目录、搜索、更新、介质维护、版本管理、下线,二级工具中心还应支持从一级工具中心同步工具功能。

3. 运行管理:应支持工具运行管理,响应外部对工具的调用,完成工具的部署启停、工具运行状态监控、运行环境管理。

4. 工具评价:应支持用户对工具进行匿名文字评论、打分评级。

5. 工具计量:应包括但不限于采用下载次数、使用次数、使用时长方式进行工具计量操作。

6. 统计分析:应支持工具下载排行、支持根据用户所选工具进行同类型精品工具推荐,记录用户在工具中心的操作行为。

7. 服务订阅:通过服务订阅方式与场景中心、监控中心、资源配置中心、日志中心、安全中心、审计中心、采集中心交互。

六 、 资源配置中心部分

资源配置中心对资源进行识别、控制、维护、检查,并为其他中心提供准确的资源配置信息。提供模型管理、资源维护、变更管理、资源查询、数据整合、数据调和、资源关系管理、配置审计功能。

功能介绍:

1. 配置管理:实现模型配置信息管理,包括配置类型管理、配置关系管理、配置属性管理、配置属性组管理、配置类型关系管理、基础管理。

2. 配置项管理:管理配置类型实例化数据,实现配置项的新增、查询、修改、删除操作。

3. 数据整合:通过服务接口,实现多个数据源的数据整合功能,提高配置库的完备性。

4. 数据调和:对于来自多个数据源的数据进行比对审核,保证配置项数据的完整性、准确性。

5. 配置审计:创建审计计划,通过人工或自动的方式对配置项数据的准确性、完整性进行审计管理。

6.日志管理:实现配置项新增、变更操作日志的记录管理。

七 、 统一Agent部分

采集中心以协议采集和统一Agent为基础,提供指令管理、插件管理、安全验证、状态监控、数据接入、任务调度、代理端管理、采集管理、数据采集功能。

功能介绍:

1. 协议采集管理:对协议采集的服务进行服务的启动、停止操作;

2. Agent代理端:负责具体采集任务的接收调度,采集插件的管理,采集数据的传输;

3. Agent管理端:对Agent代理端、采集插件进行管理,主要包括代理端的升级,插件的安装及升级;

4. 采集监控:对当前已有采集服务状态的监控,采集流程的监控,关键采集日志的查询;

5. 采集配置:对需要采集的资源进行配置,并进行任务调度和下发;配置采集项相关信息;

6. 数据接入:第三方数据按照一定的数据格式,通过数据接入接口,接入该中心,并对接入的数据进行存储。

八 、 日志中心部分

日志中心实现日志的统一收集、管理、分析、存储需求,通过有效的分析手段,及时准确定位网络故障和真正的安全隐患,做到防患于未然。提供日志的分组管理与日志的备份管理功能。

功能介绍:

1. 日志管理:实现日志的分组管理与日志的备份管理功能。

2. 配置管理:实现字典管理、系统消息、定时任务管理功能。

3. 日志搜索:实现对搜索内容的保存、关键字搜索、语言检索、搜索结果导出功能。

4. 状态监控:实现对日志中心运行状态监控功能。

5. 日志导入:实现本地上传和流式上传功能。

6. 日志统计:实现从多个维度对日志进行统计;日志解析实现自动对日志内容的解析、解析规则的配置、时间信息识别功能。

九 、 安全中心部分

安全中心提供各中心统一的用户管理、权限管理功能和公共支撑服务,以保证用户权限的一致性及各中心API调用过程的安全性。公共支撑服务主要为各中心提供服务注册与发现、消息队列服务和负载均衡公共服务。

功能介绍:

1. 系统管理主要功能包括:用户账号管理、菜单管理、组织机构管理、角色管理、密码策略管理、用户权限管理。

2. 集成管理:主要实现功能支撑平台与其他中心信息的集成功能,主要包括场景信息同步、工具同步、资源同步、组件权限角色同步。

3. 授权管理:主要实现对应用菜单的授权、数据资源的授权、各中心服务的授权,形成的授权关系用于执行许可模块的判定条件。

4. 认证管理主要包括:用户身份认证、中心认证、中心注册,它是公共支撑平台的核心主题部分。

5. 许可管理:主要实现对操作权限的判定和限制,它包括权限的提取和权限的核实。

6. 状态监控:主要完成组件认证情况的监控、认证授权情况监控、服务运行情况监控、各中心令牌使用情况监控、告警规则配置。

7. 服务注册与发现:围绕着服务注册与服务发现机制来完成对微服务应用实例的自动化管理。

8. 负载均衡:负载均衡是对系统的高可用、网络压力的缓解和处理能力扩容的重要手段。

9. 网关:系统的入口点,并负责路由,请求过滤,安全访问。

10. 限流和容错:能够在运行时自动限流和容错,保护服务,如果进一步和动态配置相结合,还可以实现动态限流和熔断。

11. 配置中心:除了支持普通配置文件方式的配置,框架层还可集成动态运行时配置,能够在运行时针对不同环境动态调整服务的参数和配置。

12. 消息队列:用于应用程序之间传输消息,并最小化应用之间的依赖。

13. 结构化存储:提供统一的关系型数据、实时数据、时序型数据的访问服务。

14. 非结构化存储:提供统一的文档、模版、镜像文件、脚本文件非结构数据的访问服务。

15. 任务调度:根据用户的任务配置,触发用户定制的业务逻辑,进行业务处理。

十 、 审计中心部分

审计中心实现对操作审计的需求,主要针对信息系统的运维行为进行风险控制管理,为公司各部门内部控制、外部审计、违规调查提供运维行为的追踪审计。

功能介绍:

1. 指令通道:实现了工具向运维对象下达控制指令的传输通道,受审计中心的监管,用户无需知道真实密码即可操作相应资源。

2. 数据分析:基于审计数据,建立数据分析策略,进行数据分析。

3. 审计数据展示:实现以操作人、操作时间、操作类型、资源对象多种维度对操作记录进行查询、展现功能。

4. 异常监控:实现对数据分析过程中发现的问题及时进行监控告警。

5. 工具审计:实现工具运行过程的审计功能。

NO.4

接入规范

第一条 工具准入

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

(一) 工具注册

各个工具研发厂商、省(市)公司依据自动化工具研发标准,将工具封装为指定格式并通过工具注册功能上传到一级或二级部署工具中心。工具包中应包含工具描述文件,描述文件中定义了工具的作用、输入/输出、收费标准、是否需要数据持久化信息。工具注册时应一并上传工具相关的测试报告、用户手册附件,包括功能测试、安全测试报告,用以支持工具安全性审核。

(二) 工具审核

工具上传至一二级工具中心后,需进行安全性和规范性审核。规范性审核由工具审核功能实现对工具规范化的自动校验;安全性审核由审核管理员进行人工审核。

(三) 工具发布

通过工具审核的自动化工具进入待发布状态,工具管理员可选择待发布工具进行发布。在一级工具中心中,已发布的工具会进入工具列表,可以被外部查询、下载、调用。在二级工具中心,工具发布除工具会进入工具列表,可以被外部查询、下载、调用外,同时通过工具描述文件完成工具在场景中心中的注册。

第二条 Agent插件准入

(一) 插件注册

插件在安装或升级时,需要在Agent管理端进行注册,注册之时需提供该插件的名称、该插件所支持的指标、插件的版本号信息。插件需要明确自身支持的哪些指标,划分资源类型及对应的指标关系。

(二) 插件测试

开发好的插件要进行安全性和规范的验证测试。

(三) 插件部署

通过测试的agent插件由采集中心中的Agent管理应用进行插件的部署/升级操作。

NO.5

非功能性规格

第一条 性能

(一) 系统容量

系统注册用户数

每单位平均250

系统最大在线用户数

每单位约50

系统结构化数据量

每年产生500GB

系统非结构化数据量

每年产生2TB

业务吞吐量

业务正常时约20笔/分钟,业务高峰时最大100笔/分钟

业务吞吐量增长预测

三年后业务正常时约30笔/分钟,业务高峰时最大150笔/分钟

系统对外网络带宽占用量

业务正常时最大10Mbps,业务高峰时最大40Mbps

(二) 系统响应时间

首页访问平均响应时间

业务正常时<3秒,业务高峰时<5秒

用户登录平均响应时间

业务正常时<3秒,业务高峰时<5秒

页面打开及刷新平均响应时间

业务正常时<3秒,业务高峰时<5秒

基本提交操作响应时间

业务正常时<2秒,业务高峰时<3秒

特殊提交操作响应时间

<10秒

基本查询操作响应时间

<5秒

复杂查询操作响应时间

<10秒

跨单位数据联动查询

<30秒

基本统计报表响应时间

<5秒

月度统计报表响应时间

<20秒

年度统计报表响应时间

<30秒

(三) 事务失败率

事务失败率

业务正常时<0.1%,业务高峰时<0.3%

(四) 数据库性能

基本SQL平均响应时间

业务正常时<3秒,业务高峰时<5秒

复杂SQL响应时间

<15秒

CPU平均占用率

业务正常时<75%,业务高峰时<80%

存储或内置磁盘组IOPS

业务正常时1000,业务高峰时3000

单台数据库主机网络吞吐量

业务正常时5Mbps,业务高峰时20Mbps

(五) 云平台容器性能

CPU平均占用率

业务正常时<75%,业务高峰时<80%

内存平均占用率

业务正常时<75%,业务高峰时<80%

单台服务器网络吞吐量

业务正常时5Mbps,业务高峰时20Mbps

第二条 可靠性

描述

l 负载均衡能力:应用服务需支持双机负载均衡模式部署l 故障监控能力:需要具备模块运行情况自监控能力

第三条 可用性(灾备)

按照灾备整体建设要求,采用存储虚拟化数据复制方式进行系统灾备。

第四条 可扩展性

描述

l 二次开发支持能力:支持基于十中心微服务进行微应用模块的扩展开发,提供通用底层服务功能。能提供标准的数据接入和数据读取接口,主要包括资源台账数据的读取和监控指标数据接入。

第五条 安全性

描述

l 用户身份管理要求;l 用户权限管理要求;l 数据安全要求;l 应用部署在不同网络区域的安全性要求;l 系统等级保护的要求。

参考资料

(1).  中国国家标准化管理委员会《GB/T 8567-1988计算机软件产品开发文件编制指南》

(2). 《国家电网公司应用软件架构设计指南(试行)》

(3). 《国家电网公司应用集成技术规范》

(4). 《国家电网公司软硬件目标架构设计规范》

(5). 《国家电网公司关于印发公司信息通信运维体系(SG-ITOM3.0)总体设计的通知》(国家电网信通〔2017〕23号)

《国网信通部关于印发国家电网公司信息通信运维体系(SG-ITOM 3.0)总体设计-技术支撑专题设计(2017版)等三个方案的通知》(信通运行〔2017〕34号)

原创声明,本文系作者授权云+社区发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 微服务架构案例(01):项目技术选型简介,架构图解说明

    知了一笑
  • ​腾讯 Techo 开发者大会首发来袭!云原生中间件技术实践等你来!

    腾讯 Techo 开发者大会是由腾讯云发起的面向全球开发者和技术爱好者的年度盛会,2019 年 11 月 6 日 - 7 日将在北京嘉里大酒店首次召开。

    CODING研发管理系统
  • 「数字体验」Liferay数字体验平台(DXP)的好处

    在这篇文章中,我们将挑选一些Liferay DXP的新功能,并对它们进行详细的探讨。

    首席架构师智库
  • Gin-Web-Framework官方指南中文(下篇)

    ShouldBind,ShouldBindJSON,ShouldBindXML,ShouldBindQuery,ShouldBindYAML

    小诚信驿站
  • 什么是微服务?

    在介绍微服务时,首先得先理解什么是微服务,顾名思义,微服务得从两个方面去理解,什么是"微"、什么是"服务", 微 狭义来讲就是体积小、著名的"2 pizza 团...

    芋道源码
  • 与我一起学习微服务架构设计模式4—使用Saga管理事务

    微服务架构下的事务往往需要横跨多个服务,每个服务都有属于自己的私有数据库。传统的分布式事务管理并不是合适选择,需要使用Saga机制。

    java达人
  • 一文让你理解微服务架构(图文详解)

    本文将介绍微服务架构和相关的组件,介绍他们是什么以及为什么要使用微服务架构和这些组件。本文侧重于简明地表达微服务架构的全局图景,因此不会涉及具体如何使用组件等细...

    Java编程指南
  • 前1号店技术总监黄哲铿揭秘:微服务架构在千万级别日调用量、亿级别海量数据场景下的应用实践

    电商是促销拉动式的场景,也是价格战驱动的场景。618和双11都是典型的促销活动。其实都是在抢用户、扩市场占有率。在这样的场景之下,对秒杀、抢购是很热衷的玩法。

    猿天地
  • 我对分布式多中心架构的几点看法

    由于我们一直从事的是传统企业的架构改造工作,所以对新兴的互联网企业如何实施微服务架构并没有实践过。在写这一章之前,我在架构群里和曾经实施过微服务架构的互联网企业...

    芋道源码
  • Dubbo 在 K8s 下的思考

    Dubbo 在 2011 开源之后,一直是国内最受欢迎的 RPC 框架,之后 Spring Boot 和 Spring Cloud 的面世,助推了微服务的火热程...

    heidsoft

扫码关注云+社区

领取腾讯云代金券