粤港供水有限公司运维管理平台建设方案.doc

广东粤港供水有限公司
运维管理平台建设方案

36 / 36

目 录
1 项目建设概述 4
1.1 项目建设背景 4
1.2 项目建设目标 4
2 平台方案设计 6
2.1 设计原则 6
2.2 功能架构 7
2.3 建设规划 8
2.4 平台功能需求 10
2.4.1 一期功能需求 10
2.4.2 二期功能需求 17
2.5 平台技术要求 24
2.5.1 系统性能要求 24
2.5.2 可扩展性要求 26
2.5.3 开放性要求 27
2.5.4 易用性要求 27
2.6 平台安全要求 27
2.7 平台部署方式 28
3 平台技术路线及选型 30
3.1 关键技术路线 30
3.1.1 国外产品与国内产品 30
3.1.2 传统架构与新型PaaS架构 30
3.1.3 运维功能全面性及功能联动 30
3.2 技术路线选择 31
3.2.1 技术对比 31
3.2.2 选型推荐 32
4 费用预算 33
4.1 一期建设预算 33
4.2 二期建设预算 34
5 实施计划 36

1 项目建设概述
1.1 项目建设背景
近年来，随着虚拟化、云计算、大数据等技术快速发展并获得的广泛应用，公司的IT资源规模激剧增长，当前管理节点已超过200个，且随着业务的发展，此规模还会迅速提升，然而当前运维工作仍然以人工为维护为主，我方面临的运维压力前所未有，同时新技术的应用也让运维的技术复杂度增大，对人员的技术要求也随着提高。现有监控与运维管理模式已很难适应当前的运维管理的要求，当前面临的运维挑战主要包括：
1、资源规模急剧增长，资产台账梳理不能及时同步，运维管理基础不足；
2、虚拟化、云计算、大数据等新技术开始使用，现有监控手段不足；
3、目前采用手工管理模式，IT服务质量难以监控和提升；
4、运维方式以人工操作为主，效率不高且存在安全隐患；
5、缺乏直观、可视化的运维展现；
6、运维团队沟通方式分散，团队协同水平低。
随着云数据中心业务的发展，IT规模激剧扩展，公司面临的运维压力也激剧增大，因此迫切需要一套一体化、自动化的运维管理平台来支持数据中心的运行保障工作，提升运维管理效率、降低运维管理风险。
1.2 项目建设目标
通过运维管理平台的建设，能够让在网络、业务系统的运行监控管理的基础上，实现统一运行维护工作，最终达到如下目标：
一、梳理资产配置，构建精确、统一的资产配置管理库
构建符合实际管理需求的资产配置模型，对资产配置信息进行梳理，实现资产配置的全生命周期管理，并实现资产配置的可视化展现。
二、强化主动监控，构建内控体系，实现集中管理
通过部署集中监控系统，实现网络、IT资源、业务应用的集中监控和统一操作，主动、及时地发现问题，解决被动救火的局面。
三、规范运行流程管理，促进有序高效协作
参照ITIL 规范，对运维管理工作进行优化，对服务管理进行改善，根据相关制度进行，对内完善流程，使运维人员具备更高的工作效率；同时把运维过程中产生的丰富经验进行积累和总结，形成有效的知识库，建立知识的共享机制。
四、建设自动化能力，提高运维效率，降低操作风险
参照互联网成功经验，建立自动化操作平台，实现对应用软件安装、系统巡检、合规检查、故障自愈等运维操作的自动化，提升运维效率、降低人工操作风险，同时为下一步走向智能化运维打下基础。
五、全方位数据展现，实现统计分析和决策支持
通过提供各类性能分析报表、资源统计报表和运维分析报表，从各个侧面、各个角度反映系统的运行情况、性能情况和人员工作情况，为系统升级、改造、扩容提供科学依据；也为员工的绩效考核提供电子依据。
2 平台方案设计
2.1 设计原则
n 先进性
应采用成熟、先进的技术产品，设计和搭建IT运维管理基础平台，在该平台的基础上，结合运行管理业务，采用模块化设计方法，确保架构层次鲜明、有序，确保各个模块不会相互影响，最大限度的保障系统的稳定。与此同时，系统的各个模块应具有良好的发展潜力，适应技术的发展方向。
n 可靠性
平台应具备高可靠设计，当部分组件故障时应不影响整个系统的使用，平台应具备较强的容错能力。
n 安全性
应采用加密、数据缓存等方式保障数据传输中的安全和可靠性。提供系统用户管理功能，应可以对系统用户进行授权管理，提供完善的日志审计功能，对系统的登录日志、操作日志等均保持记录和归档，确保日后追查和跟踪取证。
n 开放性
平台设计应符合相关的技术规范，提高系统的兼容性，包括：Restful、SNMP、SysLog、CORBA、J2EE、JMS等标准和规范，遵循接口的标准化和规范化原则，提高系统的集成能力。
n 可扩展性
平台业务功能的实现应采用面向对象技术进行分析、设计和封装，系统功能实现应被封装成独立的业务组件。应采用模块化结构，以保证系统功能扩展和兼容。同时系统应具有很好的拓展性，并提供开放和标准的接口，如Restful、MIB、CORBA等，可以在不影响系统正常使用的情况下与第三方系统灵活对接。
n 灵活性
平台应具备灵活操作特性，支持各种异构的环境系统，提供充分的配置参数驱动能力，可通过调整参数配置来达到监控适应性，而不需要对系统程序进行修改才能实现。实现系统便捷修改、定义、维护、升级、备份等操作。
n 标准性
应提供标准的接口规范和完备的文档资料， FCAPS、eTOM、ITIL等国际规范，遵循业界公论的ITIL服务管理标准。
2.2 功能架构
综合运维平台的架构设计需要既从现有的应用需求出发，又要面对未来业务和技术发展的要求，在技术方案的先进性、实用性、扩展性、稳定性等方面保持一个良好的平衡，确保为我司的信息化建设提供长期的支撑，保证IT运维管理的不断发展需要。
平台需要对我司现有网络、物理主机、虚拟主机、虚拟化平台、云平台、数据库/中间件、应用服务等IT资源进行统一管理，需要通过agent有代理或agentless无代理的模式对资源进行发现、采集、监控等操作，并最终实现资产配置管理、网络监控、系统监控、应用性能监控、用户体验监控、集中告警管理、运维可视化展示、服务流程管理、操作自动化管理等，提供统一的管理门户，并在平台层打通各功能模块数据形成统一资源库，实现不同功能间的运维联动，做到自动化、智能化运维。功能架构如下：

附图1. 运维管理平台功能架构
其中各模块应分别实现如下功能：
n 资产配置管理库
实现对数据中心所有IT资源的配置信息管理，保证数据中心中配置项的完整性和精准性，构建运维管理元数据，并为监控、运维流程提供资源数据。
n 集中监控管理
实现数据中心基础资源、业务应用、用户体验全方位监控，同时提供集中的监控告警管理及监控性能数据展示。
n 服务流程管理
实现基于ITIL的规范化运维管理流程，建立基于服务目录的对外服务交付过程。
n 操作自动化管理
实现面向于服务器运维自动化，提升运维操作效率、降低人工操作风险。
n 可视化展示与分析
实现美观形象的可视化展示平台，帮忙准确掌握IT运行态势与运维服务水平。
n 运维管理门户
实现运维管理门户网站、个人工作台等形式的面向外部最终用户自服务及内部人员人性化的运维界面。
此外，平台应预留多种标准接口及开放的接口体系，实现和第三方系统的功能或数据集成对接，包括云管理平台、PKI认证、短信系统、邮件系统、VOIP语音系统等。
2.3 建设规划
信息化建设是一个持续过程，业务、技术、管理都在持续发展，这些都要求运维工作也必须是一个持续建设、持续改进的过程，运维项目的建设不能着眼于当前的管理需求，还要充分考虑未来3~5年的发展规划，从而确保项目建设成果具备一定的扩展性和延伸性，能够满足或通过升级、扩展的方式逐步满足未来对运维工作的要求。
根据本项目建设需求，运维管理平台的建设也遵循分阶段、分步的建设策略，逐步完成运维平台“一体化、自动化、智能化”的建设目标。

附图2. 运维平台两步走建设策略
1) 一期：平台搭建，建立一体化运维管理平台
建设一体化运维管理平台，实现对IT基础设施的全面监控，针对关键基础设施进行网络监控、系统监控、集中告警管理，同时构建配置管理库（CMDB）实现对配置项的集中管理，然后根据实际需求，利用以获取的监控管理数据进行运维可视化展示。
2) 二期：优化完善，提升运维自动化与对外服务交付能力
根据运维工作的实际情况，进行运维流程管理的建设，实现运维工作规范化管理；同时建立运维自动化基础能力，实现环境准备自动化、应用安装自动化、巡检自动化等，提升运维效率、降低运维操作风险。最后，建设关键应用的用户体验监控和应用性能监控功能，进一步提升业务系统的性能，提高业务用户使用的满意度。
同时，通过与华为VOIP语音系统进行对接，实现监控语音告警通知。
2.4 平台功能需求
2.4.1 一期功能需求
2.4.1.1 资产配置管理需求
(一) 总体要求
配置管理工具作为本次项目的核心支撑功能，应具有以下能力：
1) 数据收集容易，提供配置数据收集能力，减少人工维护工作量；
2) 数据维护容易，自动化校验配置项变化，保证数据鲜活性；
3) 数据分区容易，可划分区块进行权限控制和协作，满足精细管理需求；
4) 数据消费容易，提供完整的API体系，方便扩展上层应用。
(二) 配置建模
配置库应支持灵活的动态建模能力，可根据IT架构分层，自由、灵活的定义和调整配置模型，需支持配置项类型、配置关系、配置表单的建模能力，所有设计与调整要求都基于可视化界面。
(三) 配置发现
配置管理库应支持多种配置项的发现和收集手段，包括：人工录入和批量导入、配置自动发现工具等。
配置自动发现工具应支持通过代理和无代理方式进行配置数据发现，发现对象应包括网络设备、服务器、操作系统、数据库、中间件、虚拟化等，并需支持发现配置项关系的发现。
应支持向导式发现配置功能，支持ICMP、TCP、SNMP、WMI、Telnet、SSH、CCLI、Http、DNS、JDBC、JMX、VMWare、libvirt、XenAPI等多种协议来实现配置信息的自动发现，可以通过发现配置向导来实现发现范围、发现参数的设置，应构建合理的配置发现策略，同时应支持将发现结果导入到配置管理库中。
从不同采集源获取到相同的资源数据时，系统应能够识别并合并，并与配置库中标准数据进行比。
(四) 配置维护
数据维护应包括数据分区管理、配置审核管理。
配置维护分区，应按照技术团队视角划分创建配置维护分区，各团队可进行资源认领并负责对该数据的维护管理。应采用社交协作化的思路，支持配置评论与配置的动态展示。
从不同采集源获取到相同的资源数据时，系统应能够识别并合并，并与配置库中标准数据进行比对。系统应能够判断是否产生变化，并通知技术团队管理员进行审核，避免出现重复或不一致的配置信息。
配置数据的变更生效应由工作区负责人审核决定，确保变更的快捷有效。变更审核时应支持查看配置数据变化报告。
应支持对工作区内所有资源的数据变化时，实时通知数据的订阅者或第三方系统，并告知变化内容。
(五) 配置数据消费
应提供图形化配置数据展示视图，能够直观展示资源间的关系结构，同时提供业务系统级的资源关系图。配置关系图应提供多种样式的自动化布局，能够使用不同的形状、颜色、方向的箭头直观地展现配置项之间的关系，配置关系应支持图形化界面进行编辑。
应支持基于配置关系视图的故障影响分析与变更影响分析等配置数据消费场景。
应提供全文检索的能力，能够对所有配置信息通过全文检索的方式进行数据查询。全文检索应支持对配置信息的附件信息进行检索，应同时提供最近搜索记录功能，能将最近、常用的搜索的关键字进行记录，并通过点击快速进行检索。
2.4.1.2 网络监控管理需求
网络监控工具应面向网络运维人员，为其提供相应的技术工具，实现网络拓扑结构、网络故障、网络性能、网络配置的实时监控，及时发现网络故障、流量异常，提高网络管理效率，确保网络的安全性和可靠性。应支持大规模、分布式管理需求，能够适合大规模、分域、分级等管理特点。应支持多层级联部署，满足网络隔离以及单向通信的需要，以及满足大规模部署的要求。
应支持国内外主流网络厂商、安全厂商的设备进行有效的监控和管理，能够自动发现网络的结构并自动生成物理拓扑、网络拓扑和子网拓扑，应能够通过拓扑编辑工具能够定制网络拓扑图。应支持包括Cisco、Huawei、H3C、Nortel、Foundry、3Com、等厂商的路由器、交换机、防火墙等设备。应支持对路由器、二层交换机、三层交换机、防火墙的监控。
(一) 网络拓扑发现
应支持自动网络发现能力，能够实现对华为、华三、锐捷、神码、中兴、CISCO等主流品牌设备自动发现，应支持局部发现某个设备的邻居设备，并支持自动网络拓扑构建。
应支持全局网络拓扑与分层网络拓扑，全局拓扑能够显示所有的网络设备及关系。分层网络拓扑应支持通过拓扑逐层建立组合的方式，应支持构建骨干网拓扑展示，也可以根据业务管理场景进行拓扑构建。
网络拓扑应支持良好的拓扑交互，能够通过高亮显示指定设备及相关设备，能快速分析设备间的关系；应支持放大、缩小等地图式操作功能。应支持在在拓扑上显示设备与链路的性能负荷。应支持通过IP、设备名等关键字快速搜索与定位设备。
(二) 网络设备监控
应支持发现与监测主流厂商的网络设备，设备性能监控指标应包括：在线状态、Ping延时、CPU、RAM、端口状态、端口速率、端口包速、端口丢包率、端口错包率等。
(三) 网络链路监测
应支持对网络链路的发现与监测，能够自动发现二层、三层网络链路，应支持对网络链路可用状态、丢包率、包延时的监测。
(四) 网络事件管理
应支持网络设备发出的SNMP Trap与Syslog告警事件，并对进行告警事件进行事件关联压缩，能将对称的事件或重复的事件压缩，在界面上只显示事件的最新信息，并能点击查询事件的相关信息
应支持事件的关联分析，并提供实时事件浏览界面，以对实时关注当前系统中发生的各类事件，以便对故障采取快速响应行动。
2.4.1.3 系统应用监控需求
应支持对数据中心计算、存储、网络等基础资源以及对运行于基础资源上的数据库、中间件等平台环境的监测。应具备大规模、分布式管理能力，能够适应大规模资源管理要求，系统的部署应不会对现有环境产生影响。
应支持通过Agent方式和多种协议方式管理和监测主流服务器硬件指标和操作系统，应在操作系统层面系统支持Windows、Linux、HP-UX、IBM AIX、SUN Solaris、SCO Unix等不同操作系统的服务器的运行状态和性能数据，包括服务器的基本信息、CPU负载、内存利用率、应用进程、文件系统、磁盘空间和吞吐、事件、网卡和日志等信息的分析与监视，能够收集系统日志信息（微软操作系统包含系统日志、应用日志和安全日志），帮助及早发现服务器系统的性能瓶颈与故障隐患。
(一) 服务器硬件监控
对IBM、DELL、HP、华为、浪潮、联想等国内外主流品牌的服务器硬件监控，应支持通过IPMI协议实现监测，监控指标包括：服务器电流、传感器风扇、传感器状态、传感器温度、服务器电流、服务器电源功率等。
(二) 存储监控
应支持对主流存储设备的监控，包括：HP、IBM、EMC、华为、HDS、Netapp等，技术手段包括：SMI-S、SNMP。监控指标应包括：存储阵列、物理磁盘、存储池、控制器、存储卷、存储卷组等。
若设备支持，应支持监控设备环境参数，如温度、风扇、电源电压等。并能支持基于SNMP Trap、Syslog方式接收存储设备主动告警。
(三) 虚拟化监控
应支持对华为、VMWare虚拟化平台的监控管理，监控指标应包括：虚拟机集群、物理机CPU、物理机内存、物理机磁盘、虚拟机CPU、虚拟机内存、虚拟机磁盘等。
(四) IaaS云管理平台监控
应支持通过与IaaS云管理平台进行对接实现云资源监控，支持Openstack（华为云、浪潮云、曙光云等）、阿里云等云平台监控。
(五) Docker容器监控
除虚拟化及IaaS云平台监控之外，应同时支持对新兴的Docker监控。
(六) 操作系统监控
应能够监测主流的服务器操作系统，包括：Windows、Debian、Ubuntu、CentOS、Redhat、Mac OSX、Fedora、CoreOS、AIX、HP-UNIX等。应支持通过SNMP、CLI、WMI、代理Agent方式监控服务器，Linux/Unix系统的CLI监控方式应当同时支持SSH及Telnet两种方式。
1) 可自动监测服务器的各类性能指标，应包括：CPU、RAM、磁盘、负载、文件系统、网络、监测、服务等指标；
2) 可自动监测服务器重要事件，应包括：Windows Event、Syslog；
3) 可监测一些常见的系统服务，应包括：HTTP、DNS、TCP、SSH、SNMP、WMI。
(七) 中间件监控
应支持对各类中间件进行监控：
1) Web服务中间件，应包括： Tomcat、IIS、Nginx、JBoss、Apache、Lighttpd、Weblogic、Websphere；
2) 缓存中间件，应包括：Redis、Memcached ；
3) 消息中间件，应包括：ActiveMQ、RabbitMQ、Kafka；
4) 大数据中间件，应包括： etcd、HAProxy、Elasticsearch、Hadoop（HDFS、MapReduce、Zookeeper）。
(八) 数据库监控
应支持传统关系型数据库与NoSQL数据库的监控：
1) 监测各类传统关系数据库，应包括：Oracle、SQLServer、MySQL、PostgreSQL、DB2、Sysbase、Informix；
2) 监测各类NoSQL数据库，应包括：Cassandra、MongoDB。
(九) 大数据架构监控
当前云数据中心在大数据方面发展势头明显，大数据云成为云数据中心的主要研究方向之一，同时也是云数据中心与实战结合的关键点。在大数据云的建设方面Hadoop技术占据的重要角色，运维系统应支持面向Hadoop核心组件（HDFS、MapReduce 、Yarn、Zookeeper）及内部消息中间件（RibbitMQ）的监控。
(十) 监控可视化展现
应支持资源的监控信息灵活展示，系统对上述资源监控后，可通过定义不同维度仪表盘来实现监视指标的可视化呈现。
此外，应支持按照时间轴方式同步展现多个指标，即管理人员查看某个时间节点的运行情况时，系统仪表盘将同步联动该资源在该时间节点上的全部监控指标信息。
(十一) 组件标签化管理
应支持可视化展示运维的负载热图，通过不周同色度显示资源运行负载情况。应同时支持主机或设备增加数据中心、业务、位置、集群、管理组等任意维度进行展现，同时利用标签过滤进行分组展现，应支持快速呈现高负荷资源并钻取查看。
应支持以数据中心、业务、位置(机房)、集群、管理组等不同纬度进行资源展示，同时应支持基于不同的纬度进行组合展现，如业务与集群进行组合。
应支持利用标签过滤进行分组展现，应可以根据主机名称、标签、应用等进行查询。如输入：XX，即过滤出观测业务系统相关的所有的资源。
应支持快速呈现高负荷资源并钻取查看，单击某一资源节点进入到该节点性能详情界面。
2.4.1.4 集中告警管理需求
对告警事件进行统一的处理和分析，将IT环境中产生的异构、复杂且关联的事件信息通过集中的处理平台进行格式化、过滤、归并和关联分析，并将处理结果发送给管理人员，帮助管理人员对各种事件进行有效的分析和后续处理。
(一) 告警接入管理
应支持对网络监控、系统监控、应用性能监控等工具告警统一接入，也应支持对ZABBIX等开源监控系统的告警接收。
应支持通过可视化界面自定义规则实现接收和解析对来自第三方的SNMP TRAP的告警事件可将事件转换成标准格式。
(二) 区块化告警展示
应支持对告警流水式查看，能够通过时间轴查看告警生成情况，并通过查看某个时间的告警事件。也应支持通过区块化方式查看告警事件，支持通过告警关联对应的资源业务标签，通过业务标签对故障告警进行区块化分类汇总。应能够通过区块化对告警的告警数量、紧急程度进行呈现，方便运维人员直观快速的掌握告警信息。
(三) 告警操作处理
应支持对告警流水式查看，应能够通过时间轴查看告警生成情况，并通过查看某个时间的告警事件。应支持自动从CMDB关联数据，并为每条告警打标签，提供基于标签分类的告警区块化展示。
应支持对告警事件进行归并、解除、关闭操作，应支持对事件解决方法的记录，并支持基于告警事件触发运维流程工单。
(四) 故障影响分析
应支持基于时间线进行告警分析，并提供故障影响可视化分析，掌握故障告警态势。
(五) 事件处理规则
应支持可视化界面设置告警处理规则，包括：告警通知、告警抑制、告警关闭/删除等。告警抑制规则应支持按告警时间、源地址、等级、类型等维度进行设置设定，避免不必要的告警。
2.4.1.5 运维展示分析需求
可视化展现系统提供从网络系统、主机服务器、数据库、应用、安全等几方面的运行状况的集中展示管理平台，应提供当前运行一览视图、业务一览视图、业务监测视图、网络监测视图、机房展现视图等多种监测视图来查看当前系统的整体运行情况，并应支持投放到大屏幕上。
(一) 大屏可视化展示
实时方便查看企业信息平台运行状态。例如，应该能够将网络、服务器、业务应用、机房等信息，在同一界面全屏显示，投放到大屏幕上。
(二) 可视化设计平台
应内置丰富的运维展示场景模板，包括面向网络、系统、应用及综合运行展示视图，并应支持自定义展示场景的设计。应支持多个运行展示场景之间的自动轮播，应灵活设置场景轮播间隔与循环播放窗口。
应提供数据展示可视化设计器，应能够通过拖拽进行展示视图的设计，应支持：拓扑关系图、地球仪、折线图、面积图、柱状图、条形图、堆叠柱图、柱图和折线组合图、散点图、气泡图、饼图、环形图、玫瑰图、雷达图、仪表盘、热度地图、迁徙地图、计数器、表格、文本等展示元素。视图应支持部件自由摆放、叠加和层级设置，应支持背景图、背景色、透明度的调整，应支持全屏预览，即可查看设计的窗口展示效果。
2.4.2 二期功能需求
2.4.2.1 操作自动化管理需求
应支持数据中心各层资源自动化运维操作场景，包括如下：

资源层
技术方式
自动化操作场景
L6
业务系统
自动化代理
应用部署
L5
系统应用（数据库、中间件等）
自动化代理
软件安装、参数调整、配置采集、服务启停、……
L4
操作系统
自动化代理
服务启停、参数调整、配置采集、文件管理、账号管理、系统关机与重启、……
L3
IaaS云平台
API
资源启停、模板管理、参数调整、配置采集
L2
虚拟化层
API
资源启停、参数调整、资源销毁、配置采集
L1
服务器硬件
IPMI
服务器启停、状态与性能巡检、配置采集
(一) 资源管理与文件仓库
应具备所资源配置自动发现能力，能自动收集所纳管主机和所部署服务的配置信息，应内置标签和自定义标签能力，以便快速查找定位资源。系统应支持自动化资源库与CMDB资源数据同步。
应内置文件仓库，并内置常用的标准安装文件和镜像。应支持自行上传添加文件，也应支持文件直接下载。
(二) 自动化操作库
应能够建立运维操作脚本库，应支持根据操作管理需求创建各种操作脚本，应支持Python、Shell、VBS和Windows的批处理脚本类型。
操作应支持输入参数定义，参数类型至少应支持文本、数值和文件等，参数应可设定默认值和描述信息，以便编排时复用默认值，了解参数的作用。文件列表参数应可直接通过文件仓库选择文件，并能快速上传新文件。操作应支持多标签设定，以便快速查找和定位。
(三) 编排管理
应提供基于浏览器的可视化流程编排设计器，应可通过点选完成编排设计。编排应支持设定手工或定时执行，通过作业管理进行管控。应支持编排设定参与人，只有参与人才可编辑和执行该编排，所有人可查看编排信息、执行历史。编排支持全局参数设定，应支持文本、数值、文件和主机等数据类型，参数可设定默认值或执行时输入参数，便于流程复用。
应支持编排克隆功能，能快速克隆一个编排并通过编辑调整后保存。应支持跨主机混合编排，应支持多操作任务串联执行，编排时可灵活调整顺序，满足不同运维场景。操作任务的参数应支持固定值或由编排全局参数，能自动匹配数据类型。重要的操作步骤应支持人工确认互动，确保任务执行无误，当有任务执行出错时可继续或中断作业的执行。
(四) 作业调度
应支持人工或定时自动方式执行作业任务，应支持任务并发批量执行。应能详细记录作业执行过程，动态查看作业执行过程、执行日志与执行结果。
作业任务应支持多主机分布式并发执行，能够高效执行编排作业。应支持人工参与作业执行，当任务设定需用户确认或任务执行出错时可确认继续或中断作业执行。应能自动记录作业执行总时间、每个作业任务执行的耗时。作业执行过程中如果需要参与人进行确认需及时发送通知告知，执行结果也需立即通知参与人。
(五) 作业监控
应能够展示数据中心自动化作业全局执行情况，并能查看资源当前实际运行状态，以及所部署的服务和服务运行状态。应能从资源角度查看该资源所执行过的历史操作。
(六) 运维自动化场景
应能够基于运维操作脚本、资源、作业编排，实现日常运维场景的自动化，支持包括：环境安装、应用部署、环境配置、系统巡检合规检查、故障处置、应急切换及各类批量操作等自动化运维场景。
1. 环境准备
应支持虚拟化环境与物理环境的准备，支持虚拟机创建与裸机安装。
（1）服务器裸机安装
应支持X86服务器的裸机安装。应支持自动发现数据中心中已上电启动的服务器，并识别出服务器的硬件配置信息，将这些信息收集起来展现在界面上，包括：厂商、型号、CPU、内存配置等，并进行安装操作系统。
（2）虚拟化创建
系统应支持对VMware、Openstack、阿里云的自动化虚拟化的创建。
2. 环境设置
应支持对服务器、应用系统各类参数的修改与调整，比如修改操作系统的句柄数、交换区大小等。
3. 应用部署与补丁安装
应支持对数据库（Oracle/Oracle RAC、Mysql、DB2、MongoDB等）、中间件（Weblogic、Apache、Tomcat、Ngix等）、应用（Web应用）的安装部署。同时支持补丁的安装与部署。
4. 自动化巡检
应支持对各类资源进行自动化的巡检，及时发现资源的运行参数和状态，自动化巡检通过编写相应的脚本，获取相应的参数，并生成相应的巡检结果报告。
5. 合规检查
应支持依据公安部的安全管理规范及风险预警制定自动化作业，实现自动化合规检查。
6. 批量作业
应支持对系统参数调整、文件操作、数据备份等日常运维工作的批量化执行。
7. 应急切换
应支持针对不同应用系统的技术架构与部署情况进行切换操作脚本的编写与切换场景的编排。
2.4.2.2 服务流程管理需求
运维服务流程应支持ITIL、DevOps运维理念，通过规范服务流程和技术服务工作，基于随需定义的服务流程引擎，建立标准的运维服务流程，围绕服务目录、事件管理、问题管理、变更管理、服务请求管理等ITIL最佳实践内容，进行IT运维服务的流程化、规范化管理。
(一) 运维管理流程
1. 事件管理
应支持故障的记录、分类、处理、解决的流程管理，确保故障尽快恢复。应支持通过监控告警触发生成事件工单。应支持基于故障处置预案通过自动化平台实现故障的自动化处置。
2. 问题管理
应支持问题的记录、识别、调查、诊断、解决的流程管理，预防同类情况重复发生。
3. 变更管理
应支持变更的请求、评估、审核、实施、确认的流程管理，确保变更有序实施。支持基于通过自动化平台实现变更的自动化实施。
4. 服务请求管理
应支持服务请求的记录、分类、处理，确保服务尽快交付。应支持基于通过自动化平台实现资源交付的自动化实施，如云资源申请、网络资源申请等。
(二) 流程设计引擎
应支持流程扩展定制能力，能够灵活设计流程、流程表单和流程规则。应支持web在线的流程自定义，实现流程环节可定义，流程处理人应能够定义，流程展现能够定义，无需编码。
应支持流程在不同环节展现不同的表单，表单应支持自定义字段，字段类型应包括时间、短文本、数字、长文本、附件、下拉列表、单选项、多选项、图片等，表单应支持复制功能。
应支持流程通知，在流转过程中应支持短信或邮件形式给相关人员发送阅知信息，发送阅知信息应不影响流程流转。
2.4.2.3 应用性能监控需求
应支持针对关键业务的应用性能深度监控，实现应用性能瓶颈定位，并为系统优化提供数据依据。应支持B/S应用、移动应用和传统C/S应用的监控。
应以业务应用拓扑为中心，采集各业务环节的访问量、成功率、并发数、响应时间、连接数、返回码六大关键指标，展现应用系统服务组建的运行状态，以时序图、业务拓扑图形式实现负载量分析、可用性分析、业务Apdex健康度分析和应用调用路径全面可视化。
针对业务应用性能深度监测应采用旁路部署，应支持端口镜像，对生产系统零影响，应不修改业务系统参数、不嵌入代码、不修改应用服务器或操作系统配置即可实现业务监控。
(一) 应用架构透视
应支持业务应用架构拓扑的自动发现，及业务系统内部拓扑组成关系的可视化展现，能够自动识别业务节点IP、端口及协议。
(二) 应用性能监控
应支持应用性能的跟踪监控，了解业务系统各节点运行性能（平均响应时间、吞吐量、错误数、成功率），应支持对HTTP/HTTPS、数据库（SQL）、中间件（消息中间件、交易中间件、缓存中间件）、Web服务等协议组件的性能监控分析。应提供基于时间轴的应用系统性能监测数据快速回溯能力，并能与业务拓扑图、业务性能监控指标的联动，支持快速应用性能瓶颈定位。
(三) 关键业务监控
应支持交易渠道、交易类型、返回码等多维度实时业务交易监测分析，应能够自动记录交易级别出现的各类异常信息，包括错误码、异常原因及调用参数。应提供脚本级的灵活的自定义关键交易能力。
(四) 应用体验分析
系统应支持真实用户体验监控，应提供面向浏览器、设备、操作系统、页面、地理位置用户体验分析，应支持体验最差页面统计排行。
应支持应用性能分析，提供系统可用性分析、性能分析、业务交易分析、错误分析等报表。错误分析能定位应用运行最慢SQL、最慢页面。
2.4.2.4 用户体验监控需求
用户体验监控应实现对应用系统的WEB与移动客户端的应用性能、用户操作体验、及用户行为的监控，为应用系统优化用户体验、系统设计改造提供数据支撑。应能够对各类应用的访问量做全面的统计，并且能够根据不同查询条件来做访问量的全面分析，方便了解某项应用系统的访问分布情况，能够对应用的关心程度和使用情况等进行全面的分析。
数据采集代理不能对原有应用逻辑做改造。
(一) 用户行为分析
应提供用户会话的总体分析能力，包括当前应用用户会话数与操作次数的关系。硬能够按照着操作系统、运营商、地域等角度分析会话的分布情况，并提供排名显示哪些浏览器版本、或操作系统版本使用的用户最多。用户体验分析指标应包括：操作次数、响应时间、吞吐量、满意度、平均用户可操作时间。
应支持用户会话跟踪能力，应提供用户的聚合能力，应把同一个用户的会话信息进行统一的聚合处理，提供列表式展现，能查看最后一次访问的用户。
(二) 应用前端性能监测
应支持监测页面加载性能：包括卸载、重定向、应用缓存、DNS、TCP、请求、响应、组件加载、渲染等全过程耗时情况。应支持监测页面各组件（包括Html文档、JS文件、CSS、Ajax资源、图片、字体等）加载耗时情况。应支持监测Ajax请求的请求、回应、回调耗时，并应支持请求错误码采集。
(三) 页面脚本错误分析
应能够监测浏览器端JS错误总体分析能力，应显示当前应用JS错误次数与操作次数的关系。应能够按照浏览器、操作系统、运营商、地域等角度分析JS错误的分布情况，并提供排名显示哪些浏览器版本、或操作系统版本错误发生最频繁。
应能够监测发生JS错误的用户所在的区域、使用的浏览器类型及版本、运营商、分辨率、终端类型等信息，了解错误发生的规律。应提供图形化的界面对错误用户进行分析，定位错误信息的详情，并定位到堆栈的行和列。
应通过自动化跟踪用户与页面的交互过程，自动全量采集各页面及操作的相关指标。可视化埋点需提供完全可视化的操作界面，支持标记站点中关键的页面和页面元素。
应支持查看用户访问热图，准确了解用户访问业务系统的所关注页面区域。
2.4.2.5 VOIP集成对接需求
邮件、站内信、短信等告警通知方式往往容易被忽视，应通过与华为VOIP语音系统进行对接，实现告警自动拨号并进行语音通知的目标。
2.5 平台技术要求
2.5.1 系统性能要求
应利用当前先进的软硬件技术、数据库系统技术，提供较高的实时性能、处理性能、存储效率、用户并发访问能力。着力于占用较少的资源和网络带宽，不影响对目标源的正常运行干扰，确保所建平台对各种操作的响应时间在合理的时间范围内。具体来说，本项目应采取以下性能设计方案。
2.5.1.1 并发访问性能要求
应能够根据系统业务量、数据量的要求和估算结果，采用并发处理机制、多级存储机制，有效保证系统访问的并发性有效满足项目建设要求和实际业务需要。
（一）并发处理机制
应采用多线程、多任务并发处理和执行机制，通过服务请求缓存队列，有效管理系统访问的用户总量、并发响应规模。从表示层、应用逻辑层、数据层提供相应的并发容量、并发响应的处理机制和逻辑组件。
（二）并发扩展能力
当并发访问量扩展、数据收集广度精度扩展时，应能够提供水平扩展能力。在表示层可通过虚拟IP技术、负载均衡设备、Nginx反向代理等技术，实现WEB层面的并发扩展；在业务层通过无状态业务处理，通过基础模块（缓存服务、消息总线、认证服务）本身来保持状态共享，通过无状态实现便捷的水平复制，提高业务层面的并发能力；在数据层通过数据库的集群、数据的读写实时复制技术提供读并发的能力，并在关键数据写入中采用大数据NO-SQL的技术，提高写入的并发能力。
（二）并发性能指标
通常情况下，系统需达到的并发性能指标如下：
1) 平台应满足1000个用户同时在线，应能够通过优化软件、扩容硬件进一步提高在线用户；
2) 平台应满足500个用户同时并发，对同一功能调用，应满足200个用户来同时提交事务，并应能够通过优化软件、扩容硬件进一步提高；
3) 服务端单节点接入需保证3000个指标/秒的吞吐量，以支持1000个以上服务器或虚机；
4) 服务端接入应能够实现水平扩展，通过多种负载均衡措施，充分利用集群扩展能力，让接入吞吐量不断增加，以满足监控规模的不断扩展。
2.5.1.2 响应时间性能要求
应从用户体验的角度，系统功能页面的打开、显示、常规操作的响应时间控制在较短的时间范围以内。对于大批量数据处理与检索、统计分析数据转换、数据汇总报表生成等复杂处理，需要将系统响应时间控制在合理的范围内。
为了保障面向用户的响应时间，应通过表示层、应用层、数据层三层来保障系统响应时间，以满足项目建设要求和实际业务需要。
在并发的容许范围内，通常情况下系统应达到如下响应时间标准：
1) 一般页面平均响应时间应小于 3秒，配置库的平均业务响应时间应小于2秒；
2) 各类管理流程对配置库的相关操作响应时间应小于3秒；
3) 需要下载较多内容和图片的交互性