云平台运维管理

2024-10-04

云平台运维管理(共10篇)

云平台运维管理 篇1

0 引言

当下数据中心日益庞大,IT资源服务模式变革,运行维护管理工作日益严峻。云计算改变了传统IT组织模式,将散落的数据中心和分开的信息管理系统转化为统一标准、统一管理、统一服务的综合资源共建共享服务体系。如何通过云计算提高IT运维管理,架构一个可以高效、有序、稳定、可靠地云计算运维管理系统,成为尚待解决的问题。

1 IT运维管理面临的问题及发展趋势

1.1 大数据时代对运维管理带来挑战

大数据时代已经来临,它已经从专注于个别项目转移到影响企事业战略信息架构上来了。随着各个产业的IT架构不断扩展,迅速膨胀的信息量需要更多的服务器和存储设备,网络运维工作也面临着新的挑战。大数据时代IT监控系统需要实时监控上万个数据信息,而对监控的大量数据进行分析和处理才是运维工作的关键。尤其是分支机构庞大的大型企业,层级复杂的政府部门及事业单位,他们对数据的种类、数量、速度复杂度要求较高,如何保障好用户使用和数据的实时性,成了网络运维工作的难点和重点。

1.2 虚拟化技术改变了运维管理的方式

传统的数据中心业务与物理服务器基本上是一对一捆绑,物理服务器上多数为一个或几个业务运行,单一固定。对服务器的管理几乎成了对业务的管理。与传统数据中心相比,云计算环境下服务器多数为虚拟机,采用了虚拟化技术,物理服务器上运行着几种不同的操作系统,和很多不同的应用程序。网络起的作用很大,对网络性能的要求很高,为了应对复杂多变的网络管理,虚拟化监控管理成为趋势。在虚拟化数据中心,虚拟机的计算特性是动态的,传统网络管理系统没办法对虚拟机定位,网络对各项业务的安全控制等监管无法定位到虚拟机,云计算环境下的部署灵活和无限扩展就无法实现。

1.3 虚拟机动态迁移造成运维管理不可控

传统数据中心物理服务器往往固定连接在网络端口上,业务从物理服务器展开,安全控制上比较稳定,运维管理系统归属明确、界面清晰。云计算环境下高密度的虚拟机改变了这一现状,虚拟机动态性使得网络无法定位其具体端口,这样造成了运维管理不可控,只有具有动态感知的管理系统才能解决这一问题。

2 IT运维云平台管理模式实施方案和系统架构

2.1 云计算环境下IT运维管理模式实施方案

面对当前IT运维管理的新形势,以前独立分开的运行模式已经不能满足IT运维服务的要求,新的IT运行模式挑战了传统的运维管理模式。为了应对云计算的虚拟、动态、自动化等服务要求,需要一个统一的运维操作管理平台,这个平台可以进行基于云服务的端对端自动化对接部署和业务服务等需求。基于云计算的IT运维管理平台使得用户和运行维护单位只关注服务层,不必耗费大量精力在云计算的网络计算和存储上。在自动化的服务管理结构中,业务需求通过云服务管理平台响应到基础资源上,基础资源对其进行相关联的资源部署,然后发送到相对应的底层硬件设备中,这样通过云服务管理平台就可以全方位调度硬件设备的配置、对接、服务、各项功能等业务。本文对云计算运维管理模式进行讨论。

2.1.1 集中统一的云计算运维管理模式

以统一集中地方式作为数据中心架构的运维管理架构是一种逻辑简单、结构清楚、管理层少的逻辑架构。这种运维管理模式是把云计算的操作管理平台全面整合,包括云操作中的基础的计算、网络,存储系统等统一整合,让用户和维护管理者看到的只是单一的系统界面。集中统一的云计算运维管理模式虽然实现了部署统一,资源调度自动化,但是要在一个管理系统中既要全面又要业务统一,这就对其本身的规模功能专业程度要求很高,并且对运维团队的业务水平要求严格,这是该管理模式的局限性。

2.1.2 两层式云计算运维管理模式

两层式云计算运维管理模式就是除了统一的运维管理模式平台,把基础计算、数据存储、网络等分成各自的专业管理系统来管理。这种两层式模型可以简化统一运维模式的专业复杂度,还把传统运维工作的管理模式加入到了模型中。把基础服务和基础存储管理分离出来就成为了一个既能集中运行又能分工协作的结构模型。这种模式也有局限性,就是有两种指令系统去指挥硬件物理设备,可能存在操作上的偏差。所以这套系统需要预定操作优先级,以免发生指令冲突。两套指令的缺点还有系统调用的协议可能不同,这就需要制定平台的标准化,对于系统设计上就加大了难度。

2.1.3 三层式云计算运维管理模式

三层式模型是在两层式云计算运维管理模式的基础上,增加了中间的操作管理层。操作管理层集合了云服务管理平台的指令形成一个操作指令集,统一下发到基础硬件设施层。云计算运维管理平台作为上层服务,部署服务操作涉及基础层多个系统的相互关联变化。例如数据迁移会使得存储资源产生位置变化,再如虚拟机的动态性就是要求网络位置不断变化,这些相互关联的变化都涉及到云计算层和基础层的信息交换、协议通告、连接检查等,用来保证云服务的连续及持续性。中间层作为是资源操作管理层,接受来自顶层的云计算服务调用,然后转换为对硬件基础设备的操作和配置,中间层作为专业化系统还可以对硬件设备进行监管、运行、维护等功能。中间层作为操作管理层包含管理界面系统(如机房管理、计费管理、设备管理)、安全管理等资源管理系统(如配置管理、事件管理、变更管理、问题管理等)、资源池管理系统(如IaaS平台、PaaS平台、SaaS平台、资源结构及配置等)等。

2.2 三层式云计算运维管理系统结构模型

三层式云计算运维管理系统模型,如图1所示。第一层是统一的云计算运维管理平台,他向用户和运维管理人员提供界面服务及云计算服务等,该层不直接管理和操作基础设施。中间层是操作管理平台层,中间层作为是资源操作管理层,接受来自顶层的云计算服务调用,然后转换为对硬件基础设备的操作和配置。第三层就是基础硬件设施层,是基础计算、网络、存储等云计算资源形成的物理层,它接收来自中间层的指令并提供运行服务。

三层式云计算运维管理模式优点在于,中间层作为对硬件资源层面的命令层,能够满足诸多需求的变化。它把来自云计算服务层面的多种不同系统的操作信息统一封装,经过处理成容易执行的指令后,再发送到基础设备层。中间层承担了整个云计算系统的基础层数据流转和控制层的信息流转。这三种管理模式各有特点,模式一容易理解自然的涵盖了云服务与基础架构的区别,模式二和模式三则融合了IT的运维管理的实际需求,更传承了传统IT运维管理的架构,运维管理者可以通过自己的需求进行选择。

3 云计算环境下IT运维管理重点及改进方法研究

云计算环境下IT运维管理包括网络管理、日常操作管理、软件管理、用户管理等诸多方面,要架构好云计算数据中心的运行维护管理不管是前期的应用设计、资源配置、服务应用程序的安全等工作都需要运维工作人员的参与。所以在对云计算环境下IT运维管理改进过程中要从平时的日常工作着手,利用高度自动化的运维技术,来进行日常监控、服务响应、故障处理、平台系统维护、安全配置管理、定期检查等工作,从而实现对云数据中心的智能化运维管理。要重点从IT运维管理的运行监控、安全维护、自动化智能化能力出发,来实现对虚拟资源、物理设备的统一管理,提升运维管理的综合管理能力。

3.1 IT运维管理的运行监控

IT运维管理的运行监控要从日常工作入手,从日常维护、变更管理、事件管理、应急预案等方面全方位实时监控,提前发现安全隐患并查找到根源,要做到及时消灭安全隐患。通过认真仔细的运行监控,统一管理各个系统运行,统一收集各个服务操作,并对各种信息进行处理。在有效的运行监控下,系统一旦出现问题会提前并及时的向管理员报警,这样提前就能解决问题,从而避免了系统故障带来的各项损失。

3.2 IT运维管理的安全维护

IT运维管理的安全维护需要做到规范化,对整个系统的信息进行规范,比如重要资源文档进行跟踪和信息审计;对于有可能出现的病毒入侵和信息泄露的设备和传播媒介提前控制;对于用户本文把他们分级别控制权限管理;对各类非法软件及操作禁止使用等等。这样的规范管理可以保证云服务的安全,进一步加大了运维管理安全维护的力度,保证了系统的安全。

3.3 IT运维管理的自动化智能化能力

手工运维早已无法满足当前的运维工作需求,自动化智能化处理才能满足不断深入的IT建设。需要更高层次的自动化智能化处理能力,利用自动化智能化的运维工具来完成系统监控、资源配置管理、安全预警报告等功能,从而大大降低故障发生率,提高业务响应效率。自动化智能化运维成为了运维管理的必然发展趋势。

4 结束语

云计算环境下IT运维管理把云计算系统中的信息服务资源、网络资源、应用信息资源、服务器资源等进行统一的规划管理,为数据中心运维管理提供了一站式运维服务流程,通过自动化、智能化的服务,清晰了运维流程,明确了运维策略,提高了管理能力,保障了系统安全。云计算环境下IT运维管理大大提高了运维工作效率,解决了IT运维管理面临的大数据问题、虚拟化和动态化等问题,把云应用引入到了运维服务层面。

参考文献

[1]朱近之.智慧的云计算[M].北京:北京电子工业出版社,2010.

[2]王鹏,黄华峰,曹琹.云计算中国未来的IT战略「M].北京:人民邮电出版社,2010.

[3]黎加厚.云计算辅助教学[M].上海:上海教育出版社,2010.

[4]刘鹏.云计算[M].北京:电子工业出版社,2011.

[5]耿向东.走下云端,让云计算落地开花[J].中国新通信,2012(5):45-48.

云平台运维管理 篇2

第一章 总则

第一条 为了加强中山市电子政务云服务平台(以下简称云平台)资源管理,确保资源的合理分配和安全使用,根据《中山市电子政务云服务平台管理暂行办法》(以下简称《管理办法》),制定本实施细则。

第二条 市经济和信息化局是云平台的主管部门,负责统筹云平台资源管理工作;云平台资源使用单位(以下简称用户单位)依据各自责任,协助主管部门和运营单位做好云平台资源使用及安全管理工作;云平台运营单位配合主管部门具体负责云平台资源提供及安全管理服务。

第三条 本细则所指云平台资源是中山市电子政务云服务平台为用户单位提供的计算、存储、网络等云资源,具体包括但不限于:

(一)云计算资源。云平台运营单位根据用户单位需求和主管部门审批意见,为用户单位提供虚拟主机服务,用户单位须明确虚拟主机的CPU核数、内存容量、存储容量、端口开放需求和配套设备运维需求。

(二)云存储资源。云平台运营单位根据用户单位需求和主管部门审批意见,为用户单位提供保存系统数据、图片、视频和 备份文件的云存储资源。

(三)第三方软件资源。云平台运营单位根据用户单位需求和主管部门审批意见,为用户单位提供操作系统、数据库、中间件、服务器防病毒、备份工具等第三方软件。用户单位应优先使用自有的正版第三方软件,建议用户单位原则上使用开源软件,如需使用云平台提供的付费第三方软件,用户单位需求须通过按《管理办法》要求组织的专家评审。

(四)云网络资源。云平台运营单位根据用户单位需求和主管部门审批意见,为用户单位提供互联网、党政内外网、业务专网、无线网络、VPN远程访问和其他网络接入服务。用户单位云网络资源需求须明确网络接入地点、数量、带宽和价格等要求,并须通过按《管理办法》要求组织的专家评审。

(五)云安全服务。云平台运营单位提供满足等保三级要求的基础设施安全配套服务。用户单位如需选用云平台运营单位提供的增值安全服务,须通过按《管理办法》要求组织的专家评审。

第四条 云平台服务范围。云平台主要为中山市市直机关及事业单位(含下属单位)、各镇区网站和经市政府批复同意的重点信息化项目提供资源服务。

第二章 部门职责

第五条 市经济和信息化局是云平台的主管部门,在新建电 子政务项目技术评审阶段就项目对云平台资源的需求提出意见;在项目进入实施阶段后,负责云平台资源的申请受理、评估、审批、统筹、协调及管理工作。

第六条 用户单位按需向市经信局提出云平台资源申请,填写《云平台资源申请表》,经市经信局评估、审批和分配资源后,负责对云平台资源的使用和安全进行管理,包括但不限于虚拟主机和账户密码管理、协调软件开发单位合理使用资源、资源使用反馈、信息系统维护等。用户单位须协助云平台运营单位开展安全管理工作。

第七条 云平台运营单位按照主管部门要求,具体负责云平台资源分配实施、资源监控报告、平台运维优化、故障响应、技术支持、平台资源扩容等运营管理工作。

第八条 市公安局是云平台信息安全工作的监督和指导单位,云平台运营单位在市公安局的指导下,按照信息安全有关工作要求,做好云平台信息安全管理工作。

第三章 用户单位前期需求的确定

第九条 新建电子政务项目在技术评审阶段,项目建设方案须参考云平台服务目录,明确云平台资源使用需求。

第十条 新建电子政务项目须参照云平台网络规划,明确云网络资源需求,并经市经信局组织的技术评审和市财政局绩效预 算审核后,作为云平台运营单位进行网络采购的依据。

第四章 云平台资源申请管理

第十一条 用户单位可参照云平台资源服务目录提出资源申请,流程为由用户单位向市经信局提交资源申请表(见附件),市经信局经过内部审批向云平台运营单位发出资源审批意见,云平台运营单位根据资源审批意见分配资源并通知用户单位,协助用户单位进行系统部署或调整。

第十二条 云平台资源申请时间要求。用户单位关于云计算、云存储、第三方软件资源(变更)的申请,须提前于计划实施目标日前至少5个工作日提出申请;云网络资源(变更)申请和云安全服务(变更)申请,须提前于计划实施目标日前至少30个工作日提出申请。

第十三条 用户单位申请将已建信息系统迁移到云平台时,原则上要继续使用前期已采购的操作系统和数据库等第三方软件正版授权,云平台不再安排。

第十四条 用户单位在填写云平台资源申请时,应根据项目建设方案及业务需要,结合信息系统未来3个月的资源需求提出申请,对于资源需求超出实际情况的申请,云平台将根据评估情况做出合理化分配建议。

第五章 云计算资源管理

第十五条 资源分配和使用原则。用户单位应根据业务需要向市经信局提出资源申请,市经信局评估、审批后分配资源总额和初始资源额度,云平台运营单位按初始资源额度分配资源,并监控资源使用情况,在资源总额范畴内,云平台运营单位可根据用户资源使用情况进行动态调整,用户单位可通过邮件方式提出申请,资源调整操作完成后由云平台运营单位通知主管单位和用户单位。如资源使用量已达总额仍不能满足信息系统实际需求,用户单位可再次提出资源申请。

第十六条 云计算资源的初始分配。市经信局通过对在云平台运行的多个信息系统资源使用情况进行统计分析,按照一般性网站及OLTP系统、较大型网站及多用户OLTP系统、大型服务网站和信息系统等三个类别进行资源初始分配。

第十七条 云计算资源升级。在资源总额范畴内,云主机资源的升级按照以下管理原则进行。

(一)达标升级原则。各单位云主机资源需达到一定使用量或条件时才可申请升级,具体如下:

(1)CPU周平均使用率超过80%及以上;

(2)1小时内CPU使用峰值超过90%达到3次以上;(3)内存周平均使用率超过80%及以上;(4)1小时内存使用峰值超过90%达到3次以上;(5)存储空间使用率达80%以上;

(二)临时升级原则。当用户单位的信息系统出现可预期的访问高峰时,用户单位在明确升级时间长度和资源需求后,可向市经信局提出资源临时升级申请。

(三)应急管理原则。云平台运营单位在发现用户部门的云主机出现资源瓶颈情况时,应及时采取资源升级操作并通知用户部门。

第十八条 云计算资源的变更。用户单位需对已分配的云计算资源(第三方软件)进行变更时,须提交资源变更申请,按照申请流程办理。

第十九条 云计算资源的回收。用户单位已申请的资源如出现闲置时可通知云平台主管单位和运营单位进行资源回收。云平台运营单位每季度整理出资源使用率偏低的云主机,对于资源长期闲置不用或已停止服务的主机,在经用户单位和主管部门确认后将收回资源。

第二十条 云主机端口开放管理。用户单位须充分重视应用系统的端口开放管理,在申请端口开放时做到以下几点:

(一)明确端口用途和范围。每一个开放端口均需明确用途和开放范围(互联网、党政外网、部门专网或固定IP),短期无明确用途的预留端口不建议申请,同时端口的开放范围能小则小(最好精确到IP),以减少安全风险。

(二)为加强安全管理,常用端口如TCP21(FTP)、TCP1433(Microsoft SQL)、TCP1521(Oracle)、TCP3306(My-SQL)、TCP50000(DB2)、TCP5000(SyBase)等传输数据类,通常只允许在用户单位应用系统不同云主机之间访问,而不允许外部访问,如需要在非云平台环境内访问此类端口,需要修改到其它非周知端口。

(三)对于不再使用的端口,用户单位应及时通知云平台主管单位和运营单位进行端口权限取消工作,以减少安全漏洞。

第二十一条 VPN账户管理。用户单位须充分重视VPN账户管理,在申请VPN账户时做到以下几点:

(一)申请资格:没有连接党政外网的用户单位允许申请(用户单位有党政外网,但云主机上系统由用户单位的外包单位维护,且外包单位无党政外网的情况时,视为有党政外网);有连接到党政外网的用户单位但有非工作时间需要连接上云主机运维的允许申请一个唯一帐号。

(二)帐号管理:申请的用户单位对任何经由该帐号所产生的安全事件负责。

(三)帐号有效期:所有申请SSL VPN帐号原则上申请使用的有效期不超过3个月。

(四)帐号访问权限修改:用户单位对帐号的访问云主机运维IP、端口权限增加或减少,用户单位须填写申请表交主管 单位审批后由运营单位实施。

第六章 云平台网络资源管理

第二十二条 党政内网和党政外网资源管理。党政内网和党政外网的新增、迁移和撤销申请由市信息中心按照相关流程审批后交由云平台运营单位实施。

第二十三条 对于由用户单位自行负责租赁费用的网络链路需接入云平台网络的,由用户单位提出申请,经审批后实施。

第二十四条 对于由云平台运营单位负责租赁费用的网络需求,数量规模较大的(超过5条链路)须经市政务信息化项目流程进行技术评审和预算绩效审核后实施,数量规模较小的(不超过5条链路)由云平台运营单位参照已提供服务的同类链路价格水平实施,并报云平台主管部门备案。

第二十五条 对于由云平台运营单位负责租赁费用的部门专网,凡涉及到链路增减、带宽调整、点位迁移等变更情况,由用户单位向主管部门提出申请,经审批后由云平台运营单位负责实施。

第七章 云平台资源安全管理

第二十六条 用户单位应安排负责科室(部门)作为云平台资源使用和安全的管理科室(部门),管理云主机的用户名和密码等重要资料,按业务需求提出云平台资源申请。当用户单位 的云平台资源管理科室(部门)发生调整时,用户单位应及时通知云平台主管部门。

第二十七条 用户单位不得随意改变已分配资源的用途及应用系统端口,如确实需进行更改,须经过资源变更审批流程后方可变更。

第二十八条 用户单位须做好应用系统安全防护(如修补安全漏洞等)。应用系统上线前用户单位应通知云平台运营单位,由云平台运营单位进行安全检测,通过后方可正式上线。

第八章 云平台的运维管理

第二十九条 云平台运营单位应在每月中旬向各用户单位提供上一月度的资源使用月报,并根据用户单位的反馈解决问题,完善服务。

第三十条 云平台运营单位须对云主机及应用系统进行监控,当用户单位云主机或系统出现故障时,应及时通知用户单位和主管部门,并按照应急处理机制落实各项措施。

第三十一条 云平台运营单位每季度须对云平台进行定期维护,并提前15个工作日向云平台主管部门提交维护计划,审核通过后,须提前5个工作日通知用户单位,各用户单位需配合云平台做好维护工作。

第九章 附

第三十二条 本实施细则自印发之日执行。

云平台运维管理 篇3

关键词:运营商;管理

中圖分类号:TN915.07 文献标识码:A 文章编号:1674-7712 (2012) 06-0075-01

随着三网融合和NGB的试点工作在全国各地积极开展,甘肃广电及时抓住机遇,加快了全省广电网络的整合,并积极与移动、联通结成战略合作伙伴,全力推动全业务的开展与实施,研发了可承载三网融合全业务开展的语音、数据、标高清、3D电视互动平台和家庭智能平台,实施了以干线扩容、双向网改为主的NGB网络建设。最终形成了甘肃广电自主特色的全业务和全服务平台,通过该平台,就可以利用统一的资源,通过共用平台,向手机网、无线网络、互联网、广播电视网等渠道的不同终端,提供适合各种网络传输和终端显示的业务和服务。目前甘肃广电已经开展数字电视、互动电视、网络电视、电视生活、物联网家庭手机监控等业务。

一、建设全业务综合运维平台的必要性

随着新业务的开展,甘肃广电全业务的平台已形成规模,下一步就要考虑如何保证平台安全、稳定、可靠地运行,也就是从“如何建”逐步转移到“如何管”,因此需要建设以客户为中心、以市场为导向、以效益为目标,建设科学、先进、高效、自动的综合运维管理平台,在保证网络安全的同时,最大限度地利用网络资源,提高网络的运行质量和效率,为用户提供更多的服务内容和更高的服务质量已成为实现新型全业务运营和运维的要求。

二、eTOM增强的电信运营流程体系

对于广电运营商的综合运维平台的规划可参考和借鉴电信企业先进的eTOM体系。eTOM是增强的电信运营流程模型和框架,由TMF根据ITU的TMN模型和各国电信系统的建设经验总结出来的,它阐述了电信运营商及其所处的经营环境,给出了运营商内、外部的相互影响、相互作用的五大实体:客户、供应商/台作伙伴、股东、雇员其他利益相关者。eTOM作为电信运营业务流程向导的蓝图,是NGOSS(新一代运营系统和软件)的重要概念和关键组成元素。

三、综合运维管理平台在eTOM中的定位

广电运维管理平台在eTOM模型中定位在纵向的业务实现、业务保障,以及横向的资源开发和管理、资源管理和运营的交集处。其中业务实现过程组主要负责及时、正确、快速地为客户提供他们所需要的产品和服务,将客户的个性化需求转化为运营商产品的解决方案,并通知客户定单的状态和确保定单的及时完成。业务保障过程组负责业务维护活动以确保提供给客户的业务满足SLA或QoS性能水平;执行连续的资源状态和性能监控;收集性能数据、通过分析这些数据识别出潜在的问题、并在对客户造成影响之前解决这些问题;负责从客户接受故障报告、通知客户故障的状态、确保故障的修复。资源开发、管理和运营过程组主要负责对资源进行维护和管理;确保网络和信息技术基础设施平滑的运行,以支持端到端的业务的交付;同时,它也负责收集资源的信息,并修正、汇总相关的信息给相关的业务管理系统。

四、综合运维管理平台的组成

基于eTOM体系规划的综合运维管理平台主要包含以下几部分内容:

(一)资源管理。可以对运营商的业务资源、IT设施资源和各类网络资源进行管理。便于运营商及时、全面掌握资源的使用情况,进行资源预警和分析。

(二)维护管理。可以对运营商的日常值班、设备运行、巡检维护和检修等工作流程进行规范和管理,便于运营商规范管理制度和优化工作流程。通过工单流转提高工作效率和工作质量。

(三)故障管理。可以对故障做到事前预警、事中处理和事后分析,可以实现声音、闪烁、短信、广播等多种形式的报警方式,并能预先分析故障的可能性,对于出现故障后自动启动工单流程,实现故障派单的及时响应和处理。可以对各类故障进行智能分析,形成知识库,为工程技术人员提供解决问题的能力和保障。

(四)成本管理。可以对设备和网络运行维护过程中产生的各类成本进行管理和跟踪,为管理层提供运营的参考和依据,为新业务的运营提供决策和指导。同时为管理层提供各时段成本支出的同比和环比分析,便于决策分析。

(五)考核管理。可以对运营商的各级运维管理部门和人员进行绩效考评,通过设立科学的KPI指标,实现自动考评和智能分析,便于提高工程技术人员的业务水平和综合能力,为人事考核和管理提供依据。

(六)物资管理。可以对运营商的各级仓库的设备、线缆、器材、仪器、工具和其他各类物资进行统一综合管理,通过对库存模型分析,计算科学、合理的库存量,为运营商最大程度节约成本提供保障。

(七)工程规划设计。可以对运营商新建工程、改造工程的规划设计,实现复杂的工程设计环节,自动生成各类工程图纸和工程材料清单,并能自动计算工程建设费用和成本。

五、综合运维管理平台实现的目标

(一)该平台可以结合GIS技术、工作流技术、移动3G技术和GPS定位技术可以在PC端、PDA端、决策中心大屏幕等进行可视化管理,通过电子地图、影像地图和三维地图进行展示和业务分析,可以展示全省网络的运行数据、故障情况。

(二)该平台利用LBS(基于位置的服务)技术,可以对巡检人员进行定点考勤和现场巡查,可以对故障现场位置信息、故障图像和照片及时反馈到控制指挥中心,便于决策中心全面了解故障情况,提高问题处理效率。可以支持突发事件的临时任务派发管理。

(三)便于预警与提醒,可根据实际需求,对各类机房设备、网络器件等各项参数的预警提示,并在PC端、PDA端提供基于电子地图及列表的各级别声、光、色提醒。同时,可在PC或PDA上提醒各类巡查任务,对过期的巡查任务提报给上级管理人员的PC或PDA上。

(四)可以使客户服务中心降低服务成本,提高服务质量:结合用户发展预测,合理分配网络资源;根据网络负载,调配相关资源,提供用户的稳定业务支持,快速的故障分析和响应处理及工作调度,提高效率。

(五)可以使规划设计部门提高建设效率,有效利用资源:辅助基础施工,防止误伤现有管网和线路,减少意外损失;及时掌握设备、资源的使用情况,帮助运营商做到投资决策有的放矢,杜绝投资黑洞,保证较高的成本效益。

(六)可以使运行维护部门提高故障处理速度,降低维护成本:快速定位故障,对故障影响度进行分析,优先处理关键环节,减少故障损失;提供设备设施准确信息,直接到达,快速处理,降低维护成本。

开发运维平台实现运维事务管理 篇4

大型应用系统的运行, 涉及人员多、分布广, 运维工作量大且繁琐, 运维问题由业务经办、系统管理、软件开发等部门人员通过交互方式解决, 关键业务还需办理审批手续, 使用纸质单据流转。

实际操作中存在以下问题:1、流转周期长, 受物理地位限制, 影响业务及时处理;2、不能及时了解问题处理的进展情况;3、难以统计分析系统运行状况, 为应用系统完善提供决策支持。

为克服传统运维模式的不足, 将运维事务纳入运维平台管理。

1 设计思想

梳理问题, 分别归类, 确定事务类型。为每种事务类型制定处理流程, 包含的运维环节、顺序, 是运维事务处理主线。配置事务处理流程属性, 将人员 (包括业务经办、系统管理、软件开发等部门) 划分至不同的业务群组, 授予事务类型权限, 授权后的业务群组成员才能参与该类事务处理;分配业务角色, 角角色色对对应应事事务务流流程程中中的的运运维维环环节节, , 具具有有业业务务角角色色的的用用户户能能够够参参与该环节业务处理。

2 实现过程

2.1 准备阶段

创建运维事务前, 定义事务类型、业务角色、业务群组, 配置事务处理流程, 给业务人员赋于角色、划分群组, 操作内容如下:

常用事务类型和事务处理流程 (右表为新增需求实例) 配置如下表, 根据需要可以调整事务处理流程的业务环节。

业务群组按业务种类划分, 一般与业务部门对应;按人员在业务经办岗位划分角色, 如业务员、科长、主任等。每个业务人员可以拥有一个或一个以上角色, 属于一个或一个以业务群组, 下表列举部分人员关系实例。

2.2 事务处理流程

下图为事务处理流程, 以“新增需求”事务来说明流程执行过程。

(1) 创建事务。根据事务流程配置表, 具有分管科长角色人员能够创建事务, 本例由科长A (人员ID为00939) 承担。对于事务描述内容很多或者涉及相关政策文件, 可以用附件方式加载。

(2) 指定下一环节处理人员。事务创建后, 指定下一环节处理人员, 人员应为同一业务群组且具备下一环节处理角色。

(3) 事务处理。对本环节事务进行处理或者提出处理意见, 对于涉及系统调整环节的事务处理, 处理结论和处理内容应记载详细, 可以以附件方式保存。

(4) 指定下一步处理人员, 重复 (3) 直至事务处理完毕。如果同意按流程流转至下一环节, 则指下一流程环节处理人员, 否则, 退回给上一环节处理人员或者关闭事务。

(5) 关闭事务。事务创建者确认事务处理满足要求后, 关闭事务。

在事务处理过程中, 已参加过事务处理人员, 在事务关闭前随时可以备注方式追加补充处理意见。

应用开发环境基于开放源代码的IDE工具Eclipse, 采用J2EE标准, 数据库为ORACLE。

3 事务处理界面图

用户登录运维系统后, 系统通知待办事务数量及明细, 点击明细后转入界面如下:

本例为一个事务的完整处理过程, 若事务未处理完毕, 则列出已处理环节以及目前事务处理所在环节。根据需要, 可以增添显示列, 如每个环节处理时长等;在创建事务时, 可以增加一些事务属性, 如所属子系统、事务处理紧急等级等, 为查询统计、安排运维工作提供方便。

4 运维平台事务处理统计分析

运维平台除了事务处理功能外, 通过分析平台数据, 找出应用系统存在问题, 提出改进措施。本应用系统业务终端数约1000个, 下图为运维平台上线运行后按季度统计的事务处理情况。

经分析, 造成平台事务处理数量变化原因为:1、2012年3季至2013年1季度, 运维平台上线初期, 并非所有事务都通过平台处理, 2013年2季度起, 要求所有运维事务必须上平台流转处理, 平台事务数在700-800之间。2、2013年4季, 新增一项业务, 需要调整已有业务功能、整理业务数据, 造成平台事务数增加。

经分析, 造成各类事务分布率变化的原因为:1、运维平台上线初期, 软件故障多, 经过一个季度的完善, 应用软件故障率总体呈下降趋势。2、开库操作分布率一直较高, 说明基础数据的准确率低或者业务经办不规范, 应加强基础数据的整改, 规范业务经办规程。3、当硬件发生故障时, 可能造成平台无法使用, 反应故障率低, 而实际情况是此平台不适合处理硬件故障。4、特殊数据提供分布率处于7%-10%间, 说明应用软件查询统计功能基本满足业务要求, 但对于重复要求的特殊数据, 应该综合分析现有软件功能, 将此纳入功能模块或新开模块查询。

5 结语

云数据中心运维问题解析 篇5

云计算是当下的技术热点,云数据中心是提供云计算服务的核心,是传统数据中心的升级。

无论是传统的数据中心,还是云数据中心,从他们的生命周期来看,运维管理都是整个生命周期中历时最长的一个阶段。

云数据中心的运维工作需要我们仔细分析,认真对待。从开源云计算社区openstack发布的模块来看,截止2014年11月,社区共有项目模块450个左右,模块数量前三的类型是“运维”、“易用性”、“上层服务”,其中运维模块数量第一,占到了153个。可见云计算的技术动向基本上围绕“如何运维”和“如何使用”。

我们今天的话题就先来说一说云数据中心运维的变化。说到云数据中心运维工作的变化,就要分析云的特点。云时代数据中心最明显的特点就是虚拟化技术的大量应用,这使得运维管理的对象发生了变化:

一、云数据中心运维对象数量激增。虚拟化技术将1台物理服务器虚拟为多台虚拟服务器,如果数据中心支撑业务需求规模不变的话,所需要的物理服务器数量将会减少,这与很多人认为的运维服务器数量激增是不符的,那么这个“激增”认识是如何产生的呢。可以这样分析,由于虚拟化技术进一步提高了数据中心各种资源的使用效率,同时大幅提高了业务需求响应能力,所以多个传统数据中心合并为一个云数据中心在技术上成为了可能。很多跨国企业采用云计算技术,实现数据中心10:1到20:1的合并效果,也就是说如果原来在全球建设1000个数据中心,那么现在可以由50到100个云数据中心实现对业务的支撑,在一个合并后的云数据中心内,所要运维的服务器数量绝对可以称得上“激增”,这里所说的服务器既包括物理服务器也包括虚拟服务器。与此同时,运维岗位也就是运维人员虽然也进行了调整,但是人员增加的幅度远低于设备的增涨幅度,也就是人均运维设备数量增加了很多,在这种情况下,如果不借助工具、系统,很难完成运维工作。

二、在传统数据中心中,设备都是物理的、真实的,位置也是相对固定,对业务系统来讲,交换网络、服务器、存储设备对象之间关联也是比较固定的,管理起来相对直观。在云数据中心,虚拟化带来了资源的池化,使得一切管理对象变成虚拟的、可灵活迁移的逻辑存在。虚拟资源可以随时创建、删除,再加上高可用需求、性能优化需求带来的虚拟资源迁移,虚拟资源所在的位置变得不固定了,虚拟资源与物理资源的关系也被解耦了,原来很多能说得清、找得到的资源现在不借助工具就再也无法说得清、找得到了。

三、在传统数据中心中,设备监控主要是采集故障、性能数据,容量一般来讲还不是运维层面的问题,而是规划的问题,当然这也带来了业务系统竖井、数据中心竖井的问题,以及业务资源申请周期长的问题。在云数据中心中,容量不仅是规划问题,同时也是一个运维问题。也就是说,在日常工作中,需要随时采集资源池容量数据,不仅要看资源池的总容量,还要看容量在各个物理宿主机上分布情况,以便满足高可用和迁移的需要。

四、云数据中心在管理虚拟设备时,接口的标准化问题。在传统数据中心内,物理设备已经形成了接口标准,提供运维数据,如snmp、netflow等。而对虚拟化设备,还没有形成国标或行标,对虚拟设备的运维还需要采用厂家标准。如果在一个云数据中心中采用了多个厂家的虚拟化系统,运维人员就需要熟悉多个厂家的界面。这个问题的解决,短期来看,需要一个融合的系统,为运维人员屏蔽多厂家虚拟化系统的差异,长期来看,希望能够形成各厂家虚拟化系统的统一接口标准。

云计算带来了IT服务成本的降低,提高了应对业务需求的敏捷性,同时,我们也要看到,如果云数据中心运维管理调整不及时,不但运维工作量不减反增,而且运维水平还会降低。

2、当数据中心发展到一定的规模,人们在数据中心管控要求的基础上,强调了流程化、自动化运维的模式,以便数据中心的运维工作能够更加快捷高效的开展起来,数据中心步入云时代,对于运维工作的流程化、自动化要求,云管理系统能给用户带来哪些价值? 虚拟化技术是云数据中心的特点,但是云数据中心不仅仅是虚拟化。云数据中心响应业务需求的敏捷性,基于虚拟化,这是云数据中心的技术基础。

云数据中心以租用的方式向资源用户提供云服务,包括IaaS、PaaS、SaaS。从运维的角度讲,云服务的提供者要如何保障用户获得需要的服务呢。

云管理系统保障分配资源给用户的动作是自动化的,也就是说所有操作完全在线上完成,并且支持批量处理。

在云管理系统中,可创建并保存三个层面的资源模板,分别对应IaaS、PaaS、SaaS三个服务层面。用户申请某个或某些服务时,云管理系统就会按照相应的模版去创建资源。这是最基本的虚拟资源分配动作。

复杂一些的操作是可配置参数的资源模板,用户在申请服务时或运维人员在点击资源创建按钮前,可以传递一些参数给创建程序,如操作系统的用户名、密码,那么云管理系统在基于相应模板创建虚拟服务器时,会按照参数设置服务器操作系统管理员的账号信息。

再复杂一些的自动化动作,是基于模板组合进行的、有顺序的、有条件的动作序列,一般用作响应需要多个资源进行部署的业务系统的服务申请,通过一系列操作,为该业务系统分配网络地址、服务器、存储空间,并进行相关的配置,可定义动作执行的顺序以及后续动作执行的前提条件。对于特别复杂的动作组,允许进一步分割,也就是定义子动作组。

上述三种操作都是线上的、自动化完成的,这样的好处就是提高效率。云计算的好处之一就是敏捷分配,如果用户申请后,还要线下做很多配置,就会明显延长服务交付时间。同时基于模板的自动化操作也减少了人工线下操作的不确定性。

上面说完了运维的自动化,下面再说一下流程化。在云管理系统中,服务流程既包含了ITIL流程,如事件管理、问题管理、变更管理、发布管理等,同时也包含了云服务申请和审批的流程,如服务开通、服务变更、服务终止等。云管理系统还提供流程设计器和表单设计器,方便运维人员修改系统提供的服务流程,或者根据需要新建流程。

3、云时代数据中心最明显的特点就是虚拟化技术的大量应用,这使得管理的对象也在变化。以前的设备都是真实的,位置也是相对固定,管理起来相对直观。而应用虚拟化技术的结果是将这些资源进行“池化”,使得一切管理对象变成虚拟的、可迁移的存在,如何帮助用户面对这种挑战?

我们在谈云数据中心运维变化时,曾经提到过这个问题。在云数据中心,虚拟化带来了资源的池化,使得管理对象变成虚拟的、可灵活迁移的逻辑存在。运维人员很难再说清楚虚拟资源与物理资源的对应关系。

云管理系统会采集虚拟资源的运行数据,即时掌握资源之间的关系。首先是虚拟资源与物理资源的关联信息,比如虚拟机运行在哪台物理机上。其次,虚拟资源与虚拟资源的关系,如某台虚拟机与哪个虚拟网络设备的端口连接,某个虚拟磁盘挂载到了哪个虚拟服务器上。第三,物理资源与空间资源的关联,可以定位资源的实际部署位置。第四,物理资源与物理资源的关联关系。第三点与第四点与传统数据中处理方式并无不同。第五,云管理系统,还能够管理资源与业务系统的关系,以及资源与用户的关系。

通过云管理系统,运维人员可以即时掌握云数据中心中有哪些资源,资源的运行情况,以及资源之间的链接,资源分配给了哪个用户、哪个业务系统,资源在哪,这个在哪既包括了虚拟资源的分布也包括了物理资源的位置。

可以这么说,云管理系统以服务租用的方式向最终用户屏蔽了云数据中心内的资源情况,但是运维人员通过云管理系统能够清清楚楚、明明白白的掌握资源情况,包括虚拟的资源,也包括传统的资源。

4、目前,云数据中心管理的最大挑战除了上面提到的流程化、自动化和虚拟化,同时还要实现异构资源的融合管理,在这方面云管理系统是如何满足的? 我们在谈云数据中心变化时,曾经提到过,如果云数据中心同时存在多个虚拟化系统,由于提供商执行各自的厂家标准,要如何去运维。当时我们提到了“融合”,也就是通过一个统一的管理系统,去融合、去屏蔽多个虚拟化系统的差异。

需要融合的虚拟化系统有很多,有商业产品,也有开源系统,在这我们不一一说明。但这只是虚拟资源范畴的融合,在我们实际的云数据中心运维工程中,我们发现,现阶段国内的很多云数据中心并没有全盘的虚拟化,这种现象在企业云数据中心中尤其普遍。企业中一部分业务系统部署在虚拟环境中,另外一部分业务系统部署在物理环境中,还有一些业务系统,部署环境同时存在物理资源及虚拟资源。

基于这种情况,云管理系统进一步扩大了“融合”的范畴,管理的资源范围不仅包括虚拟资源,还包括数据中心的物理资源、空间资源、动环资源,这样就把云数据中心全面地管理起来,既有传统的,也有虚拟的,而且传统资源和虚拟资源结合起来管理,使得云数据中心的运维更加的智能。比如,我要分配一个虚拟服务器,如果有动环资源的信息,我不仅可以基于宿主机也就是物理服务器的使用情况做策略,还可以考虑服务器所在区域的电能、冷能信息。

云数据中心是传统数据中心的升级,那么云数据中心的运维也应该是传统数据中心的运维升级,不应该缺少原有的运维能力。

5、云数据中心解决了业务系统部署的烟囱问题,通过资源池化及资源自动调度实现了灵活统一的业务部署,但不同的业务系统有其固有的专业性,对网络、计算、存储的规格要求各不相同,各个业务系统的服务要求、监控要求、故障处理要求等也存在差异,要做到业务系统的统一部署,又要满足特定需要,对于云数据中心“求同存异”的挑战,云管理系统是如何克服的?

云管理系统以服务租用的方式对云服务用户屏蔽了云数据中心的资源细节。以计算资源举例,一般情况下,云服务用户所看到的、分配给自己的服务器CPU配置都是虚拟的,也就是vCPU,他和物理CPU之间并没有一个统一的对应关系,甲用户和乙用户同样的虚拟服务器配置,可能由于宿主机品牌、型号、虚拟化方式、超配策略等,在计算能力上会有较大差异,当然,云服务提供的成本也会存在差异。这个差异再加上监控、维护等增值服务要求的差异,构成了不同等级的服务水平要求。

云管理系统在资源池划分方式上支持这种服务水平的差异性管理。云管理系统支持几种划分资源池的方式,其中一种就是按资源池等级进行划分并进行管理。可以定义不同等级的资源池,如金牌、银牌、铜牌,把物理资源及虚拟资源调度到不同等级的资源池中,用户、业务系统具有相应等级资源池的配额,在配额内可以申请、使用资源。其实,关于资源划分等级的做法在传统数据中心就有,在云数据中心中只是加入了虚拟资源而已。

6、对于数据中心而言,能效的问题为大家所关注,绿色数据中心的话题也一直再提,云管理系统是否能有效帮助云数据中心降低能耗?

虚拟化技术带来的一个好处就是降低能耗,这是基于虚拟机迁移技术实现的。前提是业务量在某一时间段内下降,物理机资源在这段时间内存在一定比例的空闲。最好是空闲的比例和时间是能够预见的,一般来讲,这个时间是夜晚。在这个相对空闲的周期内,通过迁移虚拟机到值班物理服务器的方式,实现部分物理服务器关机休息,达到省电的目的。

云平台运维管理 篇6

MDCN运维管理平台的建立, 提升信息技术、产品和服务的应用, 充分调动相关维护人员积极性、主动性, 努力提高网络维护质量, 保障了各种业务在MDCN网络上的稳定运行。该平台完全基于浏览器/服务器 (Browser/Server) 三层结构体系, 客户端为浏览器, 服务器端分为应用服务器和数据服务器。

2 MDCN运维管理系统作用

2.1 维护制度管理

⑴维护管理:各项管理制度发布;⑵维护制度:各项作业计划;⑶系统通知:记录各种通告性文档;MDCN系统平台的各项管理制度可以在此模块中查阅, 便于管理、统一要求, 提高运维效率。

2.2 日常维护工作

⑴日常监测:记录每天设备CPU利用率、PING响应时间;⑵定期监测:对全网设备做系统、全面、详细的监测, 确保系统的正常运行;⑶数据备份:为保证数据正确有效, 备份MDCN网的各项参数指标, 防止数据丢失;⑷流量测试:记录各业务系统月度流量;MDCN系统的维护工作的具体记录可在此模块中体现, 实际工作落实到人, 加强员工的责任感。

2.3 系统故障类

⑴故障月报:记录月度全网故障的详细情况及解决程度。⑵故障通知单:故障通知单以各业务系统区分, 做为处理故障的依据。⑶严重、重大故障:对业务系统有严重影响故障的专题报告板块。MDCN网的系统故障及解决情况可在该页面查阅, 便于工作检查;同时也为今后处理类似故障提供依据, 缩短故障排查时间。

2.4 业务申请情况

⑴业务申请单:体现业务系统接入申请到实施全过程进度。⑵承载的业务系统:记录现有各业务系统的使用、运行情况及互通情况。通过该页面可以很好的掌握工程状况, 快速开通新业务;根据客户申请, 审核接入条件并进行审批。

2.5 月报总结归纳

⑴维护月报:记录MDCN网每月的维护情况, 包括网络指标分析、业务流量分析等。⑵割接报告:记录工程施工割接报告。月度的工作情况、系统运行情况、工程进展情况可在该板块中查看, 便于检查, 有助于加强管理。

2.6 用户申告登记

用户申告:记录各业务系统的用户申告, 落实申告的每一项内容进行答复, 提供技术支持。

2.7 网络资料

⑴网络平台:提供MDCN网的相关知识资料, 提高维护组人员素质。⑵系统配置:备份MDCN网设备的配置。⑶统计资料:记录各项基础资料, 主要包括电路、硬件设备、板卡等档案。该页面侧重于MDCN相关技术文件汇总, 通过学习加深对MDCN网的理解, 提高维护人员整体技术水平, 另一方面便于MDCN资源统计。

2.8 FTP服务

提供维护组信息共享平台、上传维护记录、资料备份的渠道。

2.9 业务接入在线审批

⑴提交申请:新业务表单在线填写提交。⑵资料审核:各部门进行审核批复。

2.1 0 故障报障

⑴故障同步:与MDCN监控软件接口, 同步出现网络中各类故障告警。⑵多元告警现实:出现告警, 通过语音或短信形式进行告警通知。

2.1 1 用户管理

⑴登陆权限:不同用户分级别分权限进行管理。⑵设备管理:按权限提供直接登陆设备接口。

2.1 2 配置备份

⑴自动备份:自动备份设备配置, 减少人工备份的繁琐, 保证数据安全性。⑵自动保存:备份同时自动保存到指定目录。

2.1 3 邮件通知

⑴业务接入通知:在线填写竣工通知单邮件发送。⑵故障告警通知:出现告警, 在线填写故障表单, 发送相关负责人。

3 MDCN网络运维管理系统平台特点

⑴安全与开放相统一;⑵使用简捷高效;⑶安装配置简单;⑷可扩充性强。MDCN运维平台功能涉及到的范围广、部门多、人员复杂, 技术体系结构为三层结构体系, 可扩展性强, 用户使用简单方便。MDCN系统平台具有良好的可扩展性, 这种结构均允许系统在多个层面上进行扩展, 并且不影响层面之间以及与其它功能模块的关系, 从而为系统在功能的纵深度和横向的覆盖面上的加强和扩展打下了良好的基础。

4 市场分析

通过MDCN运维系统管理平台的应用, 使网络资源管理体系不断优化升级, 充分应用新技术, 对系统平台进行革新和改造, 有很大的市场需求。通过该平台还增强了MDCN系统的维护高效性、相关信息查询的实效性。

⑴使用用户:主要包括MDCN系统运维人员。用户通过权限管理可以方便浏览相关信息, 简单高效的找到所需资源, 大大提高了效率;并且保证了信息的统一性、时效性、准确性。

⑵用户管理:系统可以为前台不同的板块设置不同的管理员, 板块管理员可以对该板块进行信息的审核、修改、删除等基本操作, 可发布本板块的公告、通知等信息, 可以设置重点信息置顶、重要信息加亮等操作。管理员可以设置不同用户的不同权限, 充分做到了信息的保密性、安全性。

5 技术分析

MDCN系统平台完全基于浏览器/服务器 (Browser/Server) 三层结构体系, 系统平台的建设与运行阶段所涉及的硬件、软件与相关技术等, 随着网络技术的发展, 支撑系统应用的技术日益增多, 平台采用了.net技术, 数据库采用Windows SQLserver。

技术分析如下:⑴数据仓库与数据挖掘技术在网络活动中主要用于各种大量的繁杂数据的存储与分析, 提高数据处理的效率。⑵服务器采用刀片服务器进行扩容, 具有投资小, 建立速度快、安全可靠、无需软件硬件配置、无需技术支持等特点, 对于MDCN系统管理平台升级来说, 可节省大量人力物力及一系列烦琐的工作, 是一种较佳的选择。可以支持多种服务, 如ASP、CGI、PHP、JSP、网站数据库支持、Flash、定期数据库备份等。⑶开发平台:系统的开发程序有.NET、数据库程序等。Microsoft.NET是Microsoft XML Web services平台。XML Web services允许应用程序通过Internet进行通讯和共享数据, 而不管所采用的是哪种操作系统、设备或编程语言。Microsoft.NET平台提供创建XML Web services并将这些服务集成在一起之所需。

在技术的选择上, 系统后期的优化, 包括Web浏览器、数据库服务、邮件服务、防火墙与代理服务器、中间组件、客户操作系统、网络服务系统、商务应用系统在内的软件与硬件设施。

6 经济效益分析

本平台主要是针对MDCN网络开发设计的, 其实用性大, 费时小, 系统成本低, 能满足各个业务系统负责人和管理人员的基本需求, 具有很高的实用价值。

⑴MDCN运维管理平台的建设为MDCN系统稳定运行提供了强有力的坚强后盾, 为业务使用单位节省了资源的开销。⑵提高网络维护水平, 发挥带动用户、引导开发、提供信息、推广技术的综合功能, 减少用户查询资料的的盲目性。⑶按照区域化布局、专业化分工、规模化运营、标准化管理的要求, 进一步优化了MDCN网络维护体系结构。⑷围绕新业务接入、故障信息处理、工程实施进度、信息发布、日常维护等主要功能, 推进了网络维护工作信息化。⑸以较小的维护人员成本, 优化维护质量体系, 促使网络维护及使用向便捷、快速、高效方面转变;

7 总结

⑴MDCN系统平台可增强MDCN系统维护的高效性、提高相关信息查询的实效性, 有市场需求。⑵平台开发周期短, 收效快;该平台提供了资料查询和下载的方便性, 提高了MDCN维护人员的管理维护质量。与投资相比能带来很大的经济效益。

摘要:MDCN运维管理系统平台提供MDCN网络信息浏览和相关资料下载等功能, 随着现代网络规模的扩大, 该系统平台进行改版完善、增强了功能, 旨在为各部门、业务系统相关人员提供一个更强的信息化交流共享平台。本文对MDCN维护管理平台的发展进行研究。

云平台运维管理 篇7

目前, 航天科工防御技术研究试验中心IT运维部门承担的工作包括:计算机终端服务、机房的管理、信息化基础架构的管理、应用系统的管理、安全管理、日常临时性、应急类工作、终端用户咨询、培训类工作以及其他工作。信息化管理组承担了400多台PC、10多台服务器、10多台网络设备、10多台安全设备的维护服务工作, 同时承担了数据库、应用系统的维护及信息化基础项目建设工作。

2 IT运维管理工作现状

有朴素的、实用的运维管理方法, 并在运维工作中证明能够为客户提供较好的运维服务。但是由于资源受限, 因此并没有建立完善的IT运维管理体系, 特别是由于IT运维管理工作的目标并没有明确的量化目标, 因此相应的职能及流程没有做系统的定义, 也就没有进行完善的记录, 也无法进行分析改善。其次, 运维工作更多的仍然属于被动管理阶段, 绝大部分的运维人员主要是进行响应性或者应急性的工作, 没有办法进行主动的问题分析与运维服务的优化。而且缺乏必要的工具来记录、规范IT运维的工作, 同时由于没有工具, 包括可用性、容量、服务响应时间等关键的IT运维指标都无法实现量化, 既无法体现IT运维部门的IT工作质与量, 也无法完善的证明IT运维部门的工作是否合规。

3 IT运维管理系统建设

运维体系的实施与运行需要有相应的技术平台进行辅助与支撑, 即需要建设ITIL运维管理平台, 该平台要达到的目标包括:固化流程、固化职能、统一资产配置库、量化过程、量化结果。

该平台建设将实现对所有网络设备、服务器、数据库、应用系统的综合监控, 通过建立运维服务台, 统一运维服务入口, 实现事件---变更的全过程的流程化管理。

ITIL运维管理平台完全采用模块化和组件化的开发模式, 严格按照软件工程的思想开发。它集成了网络管理和系统管理各自的优点, 对组成网络服务的IT基础架构的各方面:从网络设备到服务的物理载体——服务器, 再到各种应用程序, 进行分层监视, 最终实现了以服务/业务为最终对象的综合管理, 全面的实现了对IT基础架构的故障管理、性能管理、资源管理、安全管理、流量管理等功能;同时, 对系统的各方面:资源管理、事件管理、流程规范化管理、桌面管理和IT资源利用分析等提供了全面的管理手段, 将各个有效的功能模块有机结合在一起, 形成一个单一而完整的管理系统, 真正在一个平台实现了对IT环境以及IT资源管理的需求。该平台和产品一并提供的解决方案能轻松而顺利地让运维人员实现网络运作从被动无序到主动控制的过渡, 可以成倍地提高工作效率, 以便让运维人员真正能运用网络更大的提升工作效率, 降低工作成本。

4 平台建设的总体框架

4.1 监控管理平台

实现对IT基础架构, 主要是网络设备、服务器、数据库以及应用的监控, 并实现监控对流程的驱动。

4.2 服务管理平台

服务管理具体功能包括服务台管理、服务流程管理及运维辅助功能, 具体而言:

4.2.1 服务台管理

职能管理功能包括服务台职能管理以及值班、巡检的管理。服务台是提供给客户提供服务的接入点, 它可以从电话、邮件或者即时通之类的工具让客户快速的找到服务。同时, 运维人员通过服务台可以记录客户的问题, 根据服务台提供的帮助信息解决问题, 也可以将用户的请求生成工单派发下去, 并跟踪工单的执行。

用户也可以通过自助服务台自行提交事件问题申请, 并跟踪事件处理进度。

4.2.2 服务流程管理

服务流程管理包含了事件管理流程、问题管理流程、变更管理流程、发布管理流程。

服务器管理系统是对运维管理的流程进行固化的工具, 它可以制定流程的总体结构、考核目标、每个节点的表单等。运维人员可以基于制定好的流程生成相应的服务流程工单, 也可以接收属与自己相关的工单进行处理。同时在工单中, 应该能够提供运维人员进行服务的一些关联信息, 如配置信息, 相关工单的信息等等。流程要能进行统计分析, 生成各累报表, 作为领导工作汇报和改善流程的依据。

4.2.3 运维辅助功能

运维辅助功能是帮助运维人员更好, 更高效的做好日常运维管理工作。功能包括运维知识库、巡检管理、运维报表等。

4.3 资产配置库 (CMDB)

资产配置库是要收集IT环境的各种IT资源以及IT资源的配置, 建立它们之间的逻辑或者物理的关系, 为IT运维人员在排除故障, 解决问题的时候提供帮助。因此, 除了要记录配置之间的关系外, 还应该将与运维相关的一些信息资产以及其配置进行关联, 例如相关的合同, 维护的厂家, 曾经发生过的变更, 曾经维护过的知识等等。结合资产配置库, 应该有专门的配置管理员来维护和保持资产配置库数据的准确性。

4.4 服务展现

服务展现包括门户及管理驾驶舱

4.4.1 门户

门户是不同类型用户进入到航天科工防御技术研究试验中心信息化门户后, 结合其角色所能够得到的与IT运维相关的信息。

4.4.2 管理驾驶舱

管理驾驶舱是提供统计分析功能, 按照协定的服务承诺分解到具体的KPI, 从人员、流程、技术三个方面统计IT运维管理的实际情况, 并与承诺的质量进行对比, 从而发现不足, 辅助管理者进一步分析的管理改善点, 发现隐患, 解决问题。

参考文献

[1]陈碧珍.浅谈IT运维服务体系的建设[J].广东科技, 2001 (12) .

[2]王晓勤, 赵刚.企业IT服务管理中心架构研究[J].信息化建设, 2006 (05) .

云平台运维管理 篇8

“智能建筑”是一个不断发展的概念,它的内涵与外延都随着时代的进步而发展,提供“用户感知的智能建筑环境”是我们对这个概念的理解重点。在智能建筑的运维领域,运维工作尚处于初步探索阶段。随着大楼越建越高,越来越复杂,这就使建筑物对智能化的要求也越来越高,从而使得运维管理系统成为信息化不可缺少的重要组成部分。从长远来看,运维管理必须采用计算机信息技术管理手段,来进一步提高管理的质量和效率。

智能建筑综合运维管理平台是一个以互联网为基础,企业用户为目标,集呼叫中心、设备管理、运行监控、报警管理、能耗管理等功能模块为一体的综合性服务平台。该平台依托于快速发展的公众互联网络,基于云计算技术,通过“云”服务平台对分散、独立的企业建筑运维管理过程中产生的实时监控数据、音视频数据、管理数据、空间地理信息以及其他图纸、资料信息进行集中存储、集中处理、集中分析。

2国内外发展现状

2.1国内发展现状

随着现代通信技术、计算机技术、自动控制系统、图形图像显示技术的发展,建筑智能化程度大幅提高,建立整体、综合运维管理与服务体系已势在必行。目前智能建筑管理平台一般可以划分为三个层次,第一层次为子系统的纵向集成,目的在于各子系统具体功能的实现,如对BA子系统而言,制冷站、换热站、变配电系统等智能化设备需要与整体BA协同工作,以保证BA的正常工作。第二层次为横向集成,主要体现各子系统的联动和优化组合,在确立各子系统重要性的基础上,实现几个关键子系统的协调优化运行,报警联动控制等增值功能。第三层次为一体化运维管理,通过信息集成使得各应用系统之间以及系统、信息、组织、管理之间实现高度融合和协调运行,使得不同应用项目可以满足与建筑内的设备、办公、信息沟通、管理和服务的全面需要。

国内约有十余家系统集成商或专业智能化管理软件开发商在研发推广建筑智能化管理平台,国内市场上也出现了几个较为成功的系统平台,但多为单一的运行监控功能,强调智能化系统的堆砌,忽略用户的实际需求,其系统无建筑能耗统计分析以及建筑设备运维管理的功能,无法对智能建筑内所有设备的能耗、档案、运行、维护、保养进行管理。建筑机电设备的运行监控只有二维的组态图,一旦设备发生故障报警,在监控系统上无法及时发现故障设备的所在位置。虽然也有企业在推广功能单一的建筑信息管理系统或建筑物业管理系统,但一般皆为不同企业研发,难以在统一的综合运维管理平台上进行管理。此外,目前大多数产品采用单个工程研发、实施的方法,平台产品通用性较差。

2.2国外发展现状

国外的建筑智能化监控主要是以BA系统为核心的建筑物自动化与管理系统,具体做法是以楼宇自动化系统为平台,利用开发硬件网关技术将各系统进行互联,形式上为业主完成了一体化管理方案。但是由于受到基础软件平台的限制,许多功能无法实现,内容也受到很大的限制,不能很好地实现运维管理的目的。另外,由于目前楼宇自动化系统的通讯速率问题、网关协议的专用性问题,在使用效果、与未来新技术衔接上也存在着弊端。

3 平台现存问题分析

目前,公共建筑机电设备运行、维护和管理存在以下几个问题:

3.1 智能建筑信息化程度较低

重硬件、轻软件是当前智能建筑行业非常普遍的现象,很多客户还存在认识上的误区,认为买一大堆“高大上”的设备,企业运维管理的信息化系统自然就有了,企业信息化管理水平也就自然提高了。其实不然,现在大多数企业运维保障工作主要以人工纸本做记录,事件处置过程无法做到全程、实时掌控。事件从接收、分发、处置至用户反馈各个环节,都没有找到一种有效方法进行监督和管理,经常出现处置遗漏、虚报、瞒报等各类问题。

3.2 智能建筑运维管理机构臃肿

企业后勤管理有动力、总务、安保、保洁等部门,不同单位其后勤管理团队大小不一样,但在整个公司占有的比例都不小,小则几十个人,大则几百人,这些人员普遍年龄偏大,文化层次不高,越来越不适应企业运维管理,建筑运维管理机构越来越庞大,管理方式也越来越跟不上时代发展,越来越成为企业的沉重负担。

3.3 智能建筑运维管理成本居高不下

后勤人力资源、设备维修保养、设备升级更新、能源消耗等各方面成本,对一家企业来说,历年居高不下,而且随着环境的恶化、极端气候变化多端,这些成本呈现逐年攀升的趋势。其根本原因是员工的文化水平、管理思想、专业技术水平没有与时俱进,仍停留在十多年前的水平,尽管设备变得高档了,信息化程度变得更发达了,但是管理理念没有变化。所以,设备故障处理不及时、设备维修保养不善、设备运行调度管理不合理、节能降耗不落实,导致设备使用寿命缩短、建筑安全性降低、能源消耗大、环境污染加重等严重后果。为了改变这种现状,大多数企业的处理方式是设备更新换代,推陈出新,直接导致企业的运维管理成本越来越高。

4 平台架构及主要功能

应用GIS、3D、管控一体化等先进技术,基于云计算技术,通过“云”服务平台对建筑运维管理过程中产生的实时监控数据、音视频数据、管理数据、空间地理信息以及其他图纸、资料信息进行集中存储处理分析,将建筑能耗分户计量数据、建筑环境参数监测数据存储于实时数据库,以数据作为建筑能耗统计分析的基础,形成各类直观形象的柱状图、饼图或曲线图等,展现建筑能耗统计的可视化结果,从而达到智能建筑运维综合管理目的,实现节能降耗。

4.1 系统架构

智能建筑综合运维管理平台按照标准的SOA架构模式进行设计:

4.1.1 数据层

包括实时数据库、历史数据库、基础数据库、综合业务数据库、2D/3D空间数据库等。其中,从自动化监控设备采集到的实时数据,一部分通过专门的数据通讯协议,经过加解密操作后,直接与前端的HTML网页、GIS地图、三维模型、Flash组态等进行交互,实现远程管理与控制目的(仅限于按行业标准,远程可控的设备),同时,将实时运行信息保存到历史数据库,用于后期数据查询分析。另外,根据业务需要,一部分实时信息经过数据传输交换协议与综合业务数据库进行交互,便于运维管理。

4.1.2 业务支撑层

包括通用的组件和服务,如:安全服务、通讯服务、数据服务、流程服务、消息服务、文件服务等。

4.1.3 基础服务层

将智能建筑运维管理平台的各种功能模块,按照SOA标准封装成一个个的服务,如:设备档案管理服务、报警管理系统、自动化监控服务等,上层的业务管理系统只需将这些服务按照一定的规则进行调用、整合、连接,成为功能完整的业务管理系统。

4.1.4 业务层

将下层的基础服务按照用户的业务需求进行组装、整合、连接,包含的业务子系统有:运维监控管理、设备管理、报警管理、报表管理以及其他子系统。

4.1.5 UI层

充分利用网页开发技术、二维GIS技术、三维建模技术、Flash动画技术等,将系统的各种信息形象、直观、动态地展示出来,为系统带来良好的用户体验。

4.2 系统的主要功能

智能建筑综合运维管理平台应用系统包括运行监控系统、设备管理系统、巡检系统、报警管理系统、能耗管理系统、应急指挥系统、数据分析与辅助决策系统、客户服务系统。

4.2.1 运行监控系统

通过信息交换和共享,将智能建筑内若干个既相互独立又相互关联的系统,按照建筑智能化的要求,集成到一个带有实时数据库的、统一协调的运行监控平台,对各子系统设备的运行数据和运行状态进行高性能的实时监测、采集、整理、分析和储存,并对异常情况进行报警。

4.2.2 设备管理系统

设备管理系统将设备管理的各种工作要素有机地组成一体,把设备管理的组织体系、设备资产管理、设备运行和维护、备件管理等纳入一个优化的管理体系中,高效地建立设备完整的基础档案和技术档案,实现建筑设备从设备建档、设备安装调试,到设备运行监测、定期的维护保养,再到设备报警/故障维修,最后到设备报废的全生命周期管理,包括设备档案管理、故障维修管理、巡查养护管理、备品备件管理等功能。

4.2.3 巡检系统

巡检系统基于GIS地图、Web网络、移动端智能手机以及GPS定位技术为建筑后勤管理部门提供一套全流程、精细化、标准化的设备巡检业务管理模式,实现巡检、养护工作的高效执行和管理人员对整个巡检工作的统一监管。

4.2.4 报警管理系统

报警管理系统是定义、监控、确认、处理报警信息的一套管理系统,系统以报警信息定义、报警类别、报警级别为基础,分析处理不同的信息,明确每条报警信息的处理方式和信息通知发布方式。系统按照柔性化的设计原则,针对不同职能机构的岗位职责划分,灵活制定不同的报警处理流程。此外,系统可以智能地处理重复报警、误报等常规报警管理难于解决的问题。

4.2.5 能源管理系统

能源管理系统从能源计量规划到优化控制,实现建筑能源运行监控管理、建筑能耗统计分析、初级用能策略管理等功能,并在建筑能耗模拟分析的基础上,建立建筑用能策略管理、能源审计评估管理、能源优化控制管理平台。

4.2.6 应急指挥系统

当建筑内出现火灾、踩踏等突发性事件或发生地震、洪水等自然灾害时,应急指挥系统全面提供现场的图像、声音、人员、应急物资、应急预案等各类信息,并依据采集的信息对建筑内的设施进行统一调度,对人员进行统一指挥,实现反应灵敏、协调有序、运转高效的应急管理体制,具备风险评估、监测监控、预测预警、智能决策、综合协调、应急联动与总结评价等功能,从而最大限度地减少突发性公共事件造成的损失。

4.2.7 数据分析与决策辅助系统

数据分析与决策辅助系统是对数据的搜集、融合、挖掘和分析过程,将分析后的数据以动态、直观的多维报表、图形形式展现给用户,为用户决策提供数据依据,以保证建筑设备高效、安全、经济地运行。

4.2.8 客户服务系统

运维管理系统的信息门户网站、IP呼叫中心提供基于Web技术和系统应用集成技术的统一物业服务信息接口,用户可以通过多种联络媒体和物业服务部门进行交互,包括投诉、保修、建议、查询、申请等各项业务服务,同时为用户提供多渠道信息交流和反馈平台,提高公共服务质量。

5系统关键技术

5.1 基于云平台的运维管理

云服务平台是一个以互联网为基础,企业用户为目标,集呼叫中心、设备管理、运行监控、报警管理、能耗管理等功能模块于一体的综合性服务平台。该平台依托于快速发展的公众互联网络,基于云计算技术,通过云服务平台对分散、独立的企业建筑运维管理过程中产生的实时监控数据、音视频数据、管理数据、空间地理信息以及其他图纸、资料信息进行集中存储处理分析。

5.2 海量多源异构数据挖掘

海量多源异构数据挖掘是将智能建筑的各种业务数据进行归类、整理及深层次分析,以得出对决策有参考价值的知识,具体包括:

多源数据预处理:从来自不同运行系统的数据中提取出有用的数据,并按数据类型和有效性进行清理,以保证数据的准确性。此环节中,以异构数据源的识别与转换装箱,高速并发处理海量数据,高效准确的过滤引擎为研究重点。

海量数据仓库是决策支持系统和数据挖掘应用数据源的结构化数据环境。其关键技术点为统一、可扩展的元数据模型,海量数据的存取及数据安全。

数据挖掘使用诸如神经网络、规则归纳等技术,用来发现数据之间的关系,做出基于数据的推断。数据挖掘的关键点在于可动态配置的规则引擎、自我学习能力、数据捕捞过滤能力。

多源海量动态信息知识的发现和非规范知识的处理分析与演化,从多源异构、复杂内联和动态演化的角度构建新的知识发现策略与方法,对海量知识进行提炼、排疑、融合、重组等处理,结合信息的动态变化规律定性和定量地分析知识的演化规律。

5.3 分布式实时柔性计算

提供面向云计算和虚拟化架构的分布式多任务调度及并行处理模型,根据任务处理量和优先级自动增加、减少服务来满足实时性需求。当超大任务的计算复杂性超出单台服务器性能时,将任务按多维度拆分为细颗粒子任务,由多个服务实例并行处理。

5.4 物联数据服务模型

物联网底层实时信息的获取是构建智能建筑的根基,物联网信息来源、格式、去向各异,需要对物联信息进行分类采集、数据汇聚、传输、协议适配、节点管理等处理。物联数据服务模型对智能建筑感知层的多种数据来源进行识别和采集,并自动对同类信息进行分类汇聚、定向传输、协议适配,最终存入基础平台所构建的城市基础平台各类数据库中,为上层应用提供可靠的实时信息支撑。

6 结束语

智能建筑综合运维管理平台是在建筑运行的各种子系统的基础上,打通上层管理系统与底层控制子系统连接,形成一个建筑的核心和中枢神经系统。通过对建筑设备的全生命周期管理,对设备实时运行信息的管理,特别是对报警和故障信息产生、维修、复原的自动化处理,保证了建筑的健康和安全;通过对主要建筑设备的用能统计分析,用能预警,利用一定的控制和管理手段达到建筑节能目的;通过业主服务支持监督系统,受理业主的服务要求,接受业主的服务监督,为业主提供舒适、温馨、便捷、高效的工作和商业活动环境。

摘要:科学合理的智能建筑综合运维管理平台是解决智能建筑信息化程度低、智能建筑运维管理机构臃肿等问题的关键。本文对智能建筑综合运维管理平台系统架构、功能、关键技术等方面进行了深入研究,意在利用管控一体化、云计算等先进技术,建立智能建筑综合运维管理平台。

关键词:智能建筑,运维管理

参考文献

[1]胡硕兵.加强运维管理推动智能建筑产业发展[J].智能建筑.2007,第11期:P10-12

[2]胡硕兵.建筑智能化系统运维管理探讨[J].智能建筑.2010,第01期:P47-49

云平台运维管理 篇9

2007年7月, 新疆人民银行系统IT运维综合管理平台项目正式启动, 目标是通过引入先进的ITIL服务管理理念, 建设一个能与人民银行总行运维管理平台对接, 对新疆人民银行系统重要信息化资源进行监控, 满足辖内各级机构全面科技管理需要的综合信息化平台。经过两年多的开发建设, 2009年10月, 新疆人民银行系统IT运维综合管理平台在新疆全辖试运行。一年后正式运行。两年多的运行给新疆人民银行系统科技管理工作带来了巨大变化, 科技管理水平显著提高, 对信息系统监控能力实现质的飞跃, 较大地减轻了全辖科技人员的工作负担, 实现了IT运维管理由分散管理向集中管理、由被动管理向主动管理、由职能化管理向流程化管理的转变。

一、新疆人民银行系统IT运维综合管理平台简介

新疆人民银行系统IT运维综合管理平台是以ITIL (国际IT管理领域的事实标准) 服务管理理念开发, 集监控、流程管理和知识库等为一体的综合运维信息平台。可及时预警或告警安全事件, 实现多种规范化运维流程流转的自动化, 方便知识、经验的积累和获取。平台主要由3部分组成, 分别是监控管理平台、服务管理平台和安全管理平台。

(一) 监控管理平台。实现对全疆人民银行系统IT基础架构的集中监控和管理, 监控对象包括网络系统、主机系统、存储设备、数据库、中间件、应用系统、安全产品和中心机房环境设施等。平台能够及时采集各类告警信息、性能数据和配置数据等, 并能以多种方式 (如短信、邮件等) 报告和展示给运维人员和管理人员, 帮助运维人员及时了解系统状态, 快速、有效地诊断、定位问题。告警信息多为隐患的预警, 因此, 可将许多运维由被动支持转为主动服务。

(二) 服务管理平台。服务管理平台是以ITIL最佳实践为蓝本的服务管理流程的电子化流转工具及辅助工具。通过流程化工具, 建立以服务台为核心的运维服务机制, 通过服务台将监控、管理、服务等内容整合起来, 形成统一的IT运维管理平台。平台围绕事件管理、问题管理、发布管理、变更管理、配置管理等ITIL最佳实践流程, 将人员、IT资源和流程有机统一起来, 实现IT运维服务的流程化管理。

(三) 安全管理平台。安全管理平台的功能分2个方面, 一是监控信息安全产品本身的工作状态, 如配置信息、运行状态、设备CPU利用率、缓存使用百分比、板卡工作状态、电源和风扇状态等;二是提取各信息安全专用产品监测到的信息, 如告警信息、入侵事件信息、工作日志, 并提供多种查询方式, 生成报表等。目前, 新疆人民银行系统使用的信息安全专用产品包括防火墙、IDS、防病毒系统、非法外联系统、补丁自动分发系统和桌面设备安全管理系统等。

二、传统IT运维管理存在的问题

(一) 对IT系统监控的精准度不够, 存在较大盲区。传统IT运维管理对IT系统的监控全靠手工、现场进行, 且监控的准确程度与人员的技术水平、责任心有较大关系。非上班时间, IT系统的状态无人监控, 故障不能及时发现, 影响业务开展的事件时有发生。

(二) 技术层面条块分割。传统IT运维是按照系统、网络、应用、设备等进行人员职责划分, 这种面向职能的管理模式导致部门之间、人员之间沟通不畅, 阻碍了信息和技术的交流, 影响工作效率, 并产生潜在安全隐患。

(三) 服务管理流程随意性大。传统IT运维管理的工作流程虽然也比较明确, 但在执行过程中受人为因素影响比较大, 完全依靠个人自觉。走捷径、不遵守安全操作规程或部分遗漏的情况难以避免, 如未及时登记或登记要素不完整等。

(四) 运维记录、知识查询困难, 经验流失严重。传统IT运维管理的运维也会有各种日志记录, 但相关运行记录有些以Word文档方式保存, 有些以纸质方式保存, 孤立存放, 记录之间不便关联, 不便利用工具和没有工具对运行事件和运行故障进行快速统计分析及深度挖掘。运维人员的经验保存在各自的脑子里, 没有专门的工具搜集保存和管理, 不利于知识、经验的积累和交流。运维效率、能力和水平提升缓慢。

(五) 取得IT资产配置及资产间关系困难。有时为了运维或设备统计上的需要急需取得设备当时的配置或配置之间、设备之间的关系, 过去这些信息一般记录在各自的纸质档案或Excel表中, 记录的配置与实际配置可能还存在出入, 取得实际配置往往要费些周折。无法实现资产配置的随时提取, 得到配置之间、设备之间的关系更是困难, 更谈不上对某系统的设备、配置等的全貌展现。

(六) 服务质量和工作量难以准确评估。科技管理部门对科技服务满意度基本依靠业务部门的偶尔口头评价, 记录也不够全面, 不能准确量化科技人员的服务质量和工作量, 对科技人员的业绩考核依据不足, 只能凭个人感觉。

三、IT运维综合管理平台带来运维模式的变革

IT运维综合管理平台的指导思想是ITIL服务管理理念。ITIL运行最明显的标志是运维新组织架构的运作和服务台的启用, 形成以服务台为调度中心和监控中心的IT服务管理架构。新组织架构包括设立服务台岗位, 值守服务台, 即一线岗位;设立二线岗位, 处理复杂的运维任务, 一般为网络、应用系统的管理员;设立流程管理员, 创建新流程, 编制流程规则, 完善现有流程等。

服务台主要职责是调度、监控IT资源和流程, 是科技部门和业务部门之间的单一专职联系点。服务台值班人员借助服务管理平台客户端、电话或邮件等形式, 接收业务部门的服务请求、咨询、事件报告和投诉。对于能够独立解答 (或借助知识库可以解答) 又不需要变更配置的事件, 服务台可直接给予解答或电话指导申请人员和部门计算机安全员来处理;对于自己不能解答或复杂的事件, 由服务台人员作出判断, 转到二线技术支持人员, 或创建工单, 启动相应的服务管理流程。

多数情况下, 科技部门和业务部门之间的沟通是通过服务管理平台进行的, 由业务部门借助服务管理平台客户端自建工单, 服务台值班人员按照规定的派单规则, 通过服务管理平台转派到二线支持人员。运维人员接收到派发的工单后, 按照服务管理平台给出的流程提示, 一步步进行相应的运维操作, 或将工单流转到其他运维人员继续进行操作, 或需要审批时流转到指定的部门负责人。接单人员要将每步的操作内容、解决方案、总结体会或审批结果等填写到提示填写的栏目中。在事件流程中可能引起变更管理流程、配置管理流程或发布管理流程。对一些难以解决、共性或仍可能发生的事件, 可启动问题管理流程, 专题研究寻找解决该类问题产生的根源, 制定解决问题的解决方案或防止事故再次发生的措施。运维人员在事件处理过程中, 可充分利用配置管理数据库 (CMDB) 、知识库来更新完善。服务台要不间断地监视整个平台中各个流程的状态, 对迟办流程进行督办。服务台还负有科技部门日常工作的流程启动、职责提醒, 如口令更改、数据备份、主备服务器切换、安全检查、应急演练等。

四、应用成效

IT运维综合管理平台运行两年多以来, 运维人员、业务部门适应了新模式, 各流程环节得到磨合, 事件响应时间和处理时间大为减少。特别是一线支持能力的显著提升, 较大地提高了事件的首次解决率, 降低了二线支持的工作量。监控平台监测预警到多起设备和网络线路故障, 特别是发现了以前不易发现的备份设备或线路故障, 消除了多项安全隐患, 避免了多起安全事故的发生。这些充分证明了平台的效力。

(一) 实现了对IT系统全天候、全方位、自动化实时监控。监控平台实现了对整个新疆人民银行系统的所有核心网络设备、重要服务器、机房环境设备、供电系统等的全天候、全方位、自动化实时监控, 不再需要人员现场值守和干预, 监控到的属性全面, 数据精度高。对发现的告警定时以短信、邮件、专用客户端等多种形式告知运维人员和部门负责人, 实现了故障的及时发现, 隐患的及时告警。

(二) 优化了IT资源。ITIL的IT服务管理运营架构, 把人员、流程、IT设施三位一体地整合起来, 大大优化了IT资源。通过服务台实现对人员、流程、IT设施的总体监控、调度, 及时全面掌控各种IT资源状况, 综合调配资源, 及时发现问题和作出反应。在人力资源分配方面, 可让一线人员尽可能多地过滤掉简单、重复的问题, 将问题尽可能少流入二线支持。

(三) 固化运维流程, 规避操作风险。基于ITIL最佳实践理论设计的各服务管理流程, 不同类型的操作, 有相应的步骤和缜密的约束机制。将流程固化在平台上, 避免了人员的随意性, 提高了运维的统一性, 实现IT服务的“工程化”, 有效规避了技术人员的操作风险。

(四) 知识和经验得以迅速积累、共享。平台有一套知识和经验积累、共享的知识库建设机制, 避免了知识和经验的流失, 知识库的应用实现了“一人拥有, 全体皆知”的效果, 利于IT人员快速成长。减少运维对个别IT人员的依赖, 避免了一旦某些掌握关键信息和技能人员的缺失对IT服务持续性的影响。

(五) 提高了IT运维效率。监控平台、知识库、CMDB的综合运用, 使运维工作如虎添翼。监控平台可帮助运维人员及时发现问题。知识库中有大量案例可供借签。CMDB中详细记录的IT资源的属性、功用及关系等可快速认识IT资源, 依靠属性变化, 迅速定位故障。通过CMDB展现IT系统体系结构全貌, 也十分有利于问题的解决。

云平台运维管理 篇10

大港油田近期实施IT运维管理平台升级,从3.6版本升级到6.0R3版本,解决了3.6版本中存在系统的承载能力不足,承载监控节点数量瓶颈,ITIL平台频繁的宕机,系统响应时效性差,监控轮询机制不健全等问题,为IT运维管理平台在大港油田生产单位推广应用奠定了基础,具体实现了:

强化主动监控,构建内控体系,实现集中管理。通过部署集中监控,网络的集中监控和统一操作,主动、及时地发现问题,解决被动救火的局面;将分散的设备管理转变为集中操作。

1大港油田关键生产单位IT运维需求分析

目前,大港油田各生产单位的IT运维工作日益繁重,IT基础架构环境日益复杂,为生产、办公、生产现场的自动化处理以及安全管控发挥重要的作用。但也普遍存在着重信息化建设, 轻视信息化管理,尤其在IT运维方面缺少技术手段,造成各业务系统、应用、服务器、网络、设备不断上线后,缺乏统一的管理机制,IT运维工作相对被动、效率较低。所以,建立规范统一的IT运维管理体系是解决问题的必由之路。

根据近期对油田关键生产单位调研,在IT运维管理方面都面临以下几个问题:

1)缺乏网络实时监控工具。对网络远程监控能力的不足导致了IT人员处于被动运维的局面,只能依靠报障和人工巡检来处理问题。一旦发生网络故障势必对业务运行造成影响。

2)缺乏直观的网络运行状况展示工具。IT运维人员对于整体性动态实时的网络状态无法掌控。

3)缺乏有效的报警机制。在网络异常、故障,例如:网络阻塞、断开、设备故障、设备性能下降、流量异常时,缺乏有效的报警机制,并缺少网络运维工具实现故障快速定位。

4)缺乏资产管理。使用纸质、电子表格等方式管理资产, 缺乏资产变更的动态管理,造成资产内容、所属单位、负责人等信息无法做到全部管控。

2大港油田IT运维管理平台解决思路

信息中心在IT运维管理平台6.0R3版本的基础上,结合大港油田各生产单位的需求,开发建设集监控、IT资源资产、运维与服务管理一体化的大港油田IT运维管理平台。以配置管理数据库(CMDB)建设为监控、管控、运维管理流程建设的核心, 通过IT资源监控工具,对各生产单位的网络设备实现自动化监控、运维服务管理,实现主动监控、集中管理,故障预警自动化, 运维工作流程化、运维服务可量化。解决思路分为以下三个步骤:

第一步:开发监控管理模块。实现对大港油田关键生产单位网络设备、服务器等IT资源的监控、告警、视图展示、统计分析等管理。

第二步:定制资产管理模块。改变大港油田关键生产单位资产纸质、电子表格管理,实现资产台账信息化管理,按照资产生命周期管理方式,确保资产清晰,时时准确。

第三步:IT运维管理平台功能全面推广。将IT运维管理平台功能全面在大港油田生产单位推广应用。

3大港油田IT运维管理平台解决方案

3.1开发监控管理模块

信息资源监控平台,实现机房环境、服务器、网络设备的可视化监控与管理,发现问题提前预警,出现故障自动警报。

1)监控管理。以保障业务应用系统平稳运行为前提,实现对IT基础设施(如网络设备、链路、服务器等)运行状态实时监测,主动预警,故障快速定位,及时处理。通过网络拓扑展示及性能报表等多种方式,实现对设备性能的运行质量时时分析。

部署方式:采油一厂部署的网络监控中心3.6版本升级到6.0R3版本,需要将网络设备平滑迁移到新平台,并逐一对设备性能阀值、轮询周期进行优化。采油一厂网络监控平台接入信息中心的运维管理平台,需要对网络监控平台的同步编码等配置文件进行调整。按照分级分权管理的方式,开发监控管理模块,分别将采油二厂的网络设备以及应用服务器、原油运输公司的网络设备纳入到大港油田IT运维管理平台中进行监控,并对监控设备的性能阀值,轮询周期进行设置。

2)告警管理。通过完整的事件流分析形成有效的告警,通过短信方式提醒运维人员及时处理。支持告警事件集中展现, 告警事件流程化管理。

部署方式:按照分级分权管理的方式,开发告警管理模块, 建立告警列表,对告警分级管理,实现采油一厂、采油二厂、原油运输公司网络设备告警的时时展现。制定短信通知策略,一旦发生告警,触发短信平台推送至相关运维管理人员。

3)视图展现。通过图形化方式展现,利用数据推送技术, 主动向运维人员提供网络、IITT资源运行的性能信息,实现IITT资源运行状况、资产配置管理的可视化展现。

部署方式:梳理油田关键生产单位的网络设备结构,通过在IT运维管理平台灵动平台中定制开发网络拓扑展现模块,绘制分层分级网络逻辑图形,同步网络设备的配置信息数据,实现网络设备运行性能、故障可视化展示。

4)报表管理。系统通过数据挖掘分析、报表/报告处理过程,呈现IITT资源和应用系统运行状况、性能数据、故障运维数据、运维工作量情况等。提供各类性能分析报表、资源统计报表和运维分析报表,从各角度反映系统运行状况、性能情况和人员工作情况。

5)部署方式:根据油田关键生产单位的需求,定制网络设备(包括:网络设备流量统计、网络设备通断排名、网络设备负载排名等)、告警的统计分析。

6)运维保障:油田关键生产单位负责告警查询、处理,设备性能统计分析工作,信息中心配合日常完善工作。信息中心负责油田关键生产单位的网络设备监控的设备添加/删除、监测任务添加/修改/删除、阀值调整、告警台配置、展现制作/调整、资产信息录入/调整以及告警短信策略的变更等工作。

3.2定制资产管理模块

建立统一的IT基础设施台账。通过信息化手段,建立电子档案,同时统一资源配置平台作为核心的数据信息集合,并存储所有资源配置管理的数据和信息,保证IT生产环境配置项的完整性和精准性,为上层服务流程提供数据支撑。

1)资产模型建立。根据信息中心IT运维管理平台资产管理模型,结合油田关键生产单位需求,定制开发资产管理模型。

2)资产导入。油田关键生产单位根据CMDB通过自动发现工具、监控采集工具、手工批量导入等方式进行数据采集。

3)资产生命周期管理。建立资产的全生命周期(创建、调拨、变更、报废)管理的自动化流程,实现资产的统一管理、集中监控。

4结束语

IT运维与服务管理体系相当于IT信息化的实施“ERP”系统,它以监控为基础,以资源为核心、流程为导向、客户为中心, 实现IT服务流程驱动运维管理,从而将人员、技术、流程高度统一。

上一篇:胸科医院下一篇:ESP理论