软件运维管理（精选8篇）
软件运维管理 篇1
1 项目背景
电力供应关系国计民生, 河南省电力公司是国家电网公司的全资子公司、国有特大型企业, 承担着为河南经济社会发展和人民生活提供可靠优质电力保障的责任。河南省电力公司主要承担河南省内电力资源优化配置, 负责全省18个市、2 000多个乡镇、1亿多人口的供电服务任务。
华中电网和华北电网首次并网运行, 标志着我国由此形成了一个跨越14个省 (市、自治区) 、装机容量1.4亿k W、南北距离4 600 km、超大规模的交流同步电网, 堪称世界电网第一巨人。这次联网使河南电网运行方式随之发生了巨大变化, 由华中电网末端变为南北电力交换大通道的重要枢纽。河南电网位于华中、华北、西北联网枢纽地位, 在“西电东送、南北互供、全国联网”的格局中处于重要位置。
2 项目需求
随着国家电网公司实用化考评的深入开展以及SG186工程信息化建设不断深入, 河南省电力公司网络运维管理工作也出现了新的变化。一方面提供信息服务的IT软硬件的种类与数量不断增加;另一方面, IT软硬件的运行情况与公司各部门业务的捆绑越来越紧密, IT软硬件承担的责任也越来越重, 对信息部门的全系统安全、运营和维护管理的要求也越来越高, 迫切需要通过信息系统的专门监管对其业务进行支撑。
河南省电力公司服从服务全国联网的战略需要, 对IT管理方案主要有以下需求。
1) 河南省电力公司下属18个供电单位, 出于业务管理及监管的考虑, 省网公司需要对下属单位区域网络进行直接、实时的跨地域监管。公司及其下属18家供电单位也要对内部网络实现独立的分级管理。
2) 管理整个网络系统中的设备和合理分配资源。实现对各个设备的运行状况进行集中监控, 对各设备的运行性能进行分析和统计, 完成对各监控参数的配置管理, 保证各项配置项管理满足运行维护的需要。
3) 根据公司业务需要, 对所发现的物理网络和设备涉及的参数进行预警, 运维管理人员可以通过IT运维管理软件对所有与业务系统相关的事件进行广泛监控, 系统按公司的业务计划需要自动采集事件、提供精细的分析, 能够将分析结果以短消息、E-mail等手段通知业务相关人员。
3 北塔BTIM一期引入
北塔软件针对河南省电力公司的实际需求, 专门安装部署北塔BTIM IT运维管理系统解决方案。
1) 提供跨地域的层次化管理模型, 兼顾到广域网络带宽限制以及管理的实时就近性, 北塔BTIM采取分层管理的运维解决方案。通过分别在河南省电力公司总部中心设立中心管理节点、下属18个供电单位设立区域管理节点来搭建跨地域实时管理平台, 同时每个管理节点配置网络管理机独立管理本区域网络, 确保省电力公司通过层次化管理实现拓扑集中、全局报表等功能。
2) 按照部门级别建立不同IP地址规划, 提供全网用户信息一览表, 通过对IP、MAC的定位, 捕捉地址盗用及非法设备移动, 通过IP地址管理实现网络设备管理实施授权, 对各类网络设备、安全设备实现监控管理, 保障网络运维安全、提升网络可用性和服务质量。
3) 为IT运维管理人员提供了故障管理阈值因需设定、自主定义故障事件是否触发报警等个性化设置模块, 同时系统可主动通知运维人员当前的问题, 并提供故障告警实时查看、告警日志分析功能, 以及多渠道的告警方式输出方式。
4 项目需求变化
电网作为支撑经济社会发展的重要基础设施, 其发展必须与经济社会的发展进步相适应。当前, 国家电网公司信息化SG186工程已经进入建设与应用并重、着力深化应用的阶段, 积极在全网系统推进实用化评价考核。国家电网公司总部强调了信息运维综合监管系统 (以下简称IMS) 在实用化评价考核工作中的重要性, 要求各省以IMS系统提取的指标督促各个业务系统的应用水平, 定期通报应用系统的实用化评价考核指标和消缺整改情况。
5 北塔BTIM二期建设
针对电力行业的发展需求, 北塔软件与时俱进, 积极提出应对方案, 在现有北塔BTIM运维管理系统的基础上, 升级信息运维综合监管模块, 协助河南省电力公司开展IMS的本地化工作。
北塔软件BTIM二期IMS建设, 优化了信息运维综合监管系统网络部分的接口网关, 帮助河南省电力公司与国家电网总公司及其下属18个供电单位之间实现接口的顺利对接, 完成系统上传网络设备监控数据的通畅, 实现了对公司主要信息设备、业务系统的实时在线监控, 进一步规范了运维流程, 有效地提升了公司信息系统运维工作规范化及管理水平。
北塔BTIM二期安装并实施后, 北塔软件派专人负责河南省电力公司及其下属18个供电单位的项目调配维护工作。本次升级在一期项目确保内网建成IT综合运维管理系统的基础上, 对IMS接口进行了优化, 强调在统一展现运维流程标准化的同时达到闭环控制的目的。
6 项目效果
北塔软件BTIM二期IMS建设涵盖了真实呈现、实时监测、授权管理等功能, 现已覆盖河南省电力公司及其下属18家供电单位, 接入的业务系统包括人资、财务、物资、生产、营销等各类应用系统, 同时结合北塔BTIM诊断分析工具抽取的应用数据, 集中在IMS系统展现, 从管理和技术上加强了各业务部门业务系统使用率, 深化了实用化考核的成效, 把国家电网公司信息化SG186工程落到了实处。
北塔BTIM IT运维管理系统有效地帮助用户降低了IT运维成本, 提升了信息系统运行效率、服务质量和运维管理水平, 确保了河南省电力行业信息系统的安全稳定运行, 为护卫中国南北电力枢纽的平稳供电做出了积极贡献。
7 关于北塔BTIM和北塔BTNM
北塔BTIM (Betasoft Integrated Management, IT综合管理软件) 是以业务价值管理为核心, 强调企业对IT的全方位管理, 并集北塔软件多年IT管理实践精髓于一体的综合管理系统。北塔BTIM产品设计思路从企业IT业务服务管理角度出发, 切合行业的最新技术发展, 将业务管理与IT管理进行有效融合。采用符合ITIL理念的设计思路, 形成紧密贴合业务的综合一体化协同管理平台, 平台通过直观的事前管理呈现、先进的根源因定位和智能联动分析, 为用户IT管理提供全面综合管理解决方案。
北塔BTNM (Before Trouble Network Manager, 网络运维管理软件) 是北塔软件基于Windows操作系统发布的, 拥有完全自主知识产权, 跨平台、跨厂商, “立足于平台面向应用”的通用IT运维管理平台。其具有“全面、智能、稳定、易用”等优势:全面覆盖跨厂商跨平台管理对象, 自动辨识各生产厂商, 各种型号;可自动分析、主动预警、事前管理;全中文菜单, 图形化呈现真实物理拓扑及真实设备面板;保障企业IT系统长时间无故障运行。
软件运维管理 篇2
1、负责项目功能技术支持和功能测试;
2、有1年以上运维、测试工作经验;
3、追踪解决项目相关 bug ;
4、具备良好的表达能力，包括语言及文字表达能，良好的团队合作精神和解决问题的能力;
5、与开发人员、运维人员沟通，找出并能够快速准确定位问题。
职位要求：
1、熟悉基本主机、数据库系统、网络知识 ;
2、至少1年以上的软件运维支持经验，有使用常用测试工具的经验者优先 ;
3、具有Linux平台运维经验 ;
4、熟悉Sql语言、熟悉基本数据库操作、有ORACLE经验者优先;
软件运维管理 篇3
中国气象局全国天气预报电视会商系统建设初期业务运行主要采用卫星通信方式,随着全国气象宽带网络逐步建设和开通,会商系统主控中心MCU开始启用,省级会场逐渐过渡到可采用地面宽带网线路或卫星链路两种通信方式入会。通过地面方式接入的分会场由MCU集中进行控制,通过卫星方式接入的分会场由卫星网管系统进行控制,两部分会场汇集与主控台进行统一导播和调度[1],如图1所示。
随着会商系统业务化应用,电视会商系统的功能和规模不断完善和扩展[2],在天气预报领域的应用尤为频繁、复杂,全天候、多批次的各类会商和会议在不间断进行[3],同时国家中心到各省、地市甚至县站三级级联已逐步铺开,各使用单位对电视会商音视频信号、VGA信号的清晰度甚至会场布置等运维监管服务提出了更高的要求[4]。面对如此庞大、不同层面的服务群体,按照会商的主题、内容、参会人员单位、会场情况、保障人员、故障情况等提供一个及时有效的归档、检索及统计就成为必然,而MCU自带的会议管理软件因业务细化程度不够而无法独立支撑工作。本项目的日常业务运维管理软件就是在如此的一个背景下,以规范运行管理和保障工作,保证业务高效自动化为指导原则而设计实现的。
2 设计原则
软件的信息录入界面要求简洁大方、方便规范;信息检索统计要求准确高效;报表输出要求规范化、自动化;要有一定的检错容错机制。
针对以上要求,考虑到值班人员对前期纸质记录表已适应,在软件的信息输入界面上各项内容框图尽量和原来的表风格一致;同时为保证数据的规范性,方便信息输入和日后查询检索,会商信息的各项术语要作统一规定和分级细化,为下一步业务的拓展做好一定的储备;信息的统计查询要方便灵活,能按照单个关键词、多个关键字查询搜索,信息的输出方式可多样化,常用统计的输出要做到规范严谨。
3 数据流程分析
目前的业务运行中,从整体的数据流分析看主要有三类:第一类是会商的基本情况;第二类是针对各省、直辖市、计划单列市等大院外分会场在会商中出现的问题和故障说明;第三类是技术保障人员的情况。数据流整体框架如图2所示。通过把这些信息综合后保存到数据库中,达到可以对其进行检索、统计的效果。
在数据库的选择上,虽然每次会商持续时间比较长,但如果就单次会商只做一次统计来讲数据量并不大,再加上各种会议、应急连线、调试等可算做小于平均10次/天,所以在数据库的构架上采用简单易用的Access数据库。在程序语言的选择上,考虑到人机界面操作灵活高效的要求,采用功能强大的VC6.0作为程序框架[5]。在与数据库的接口方面,采用的是Microsoft为最新、最强大的数据访问范例OLE DB而设计的ADO[6](ActiveX Data Objects)技术,作为一个轻量、高性能的便于使用的应用程序层接口,ADO接口技术在本软件是作为VC应用程序与OLE DB的桥梁来访问和操作数据库中的数据,有使用方便、速度快、内存支出少和磁盘遗迹小等优点。
4 数据关系分析
按照数据流框架图,进一步按照召开、参加、保障的角色不同细化,可以把与会的有关单位、人员信息划分为三类:一是会商的基本信息,包括了时间地点、名称、召开单位、主持人、参会领导、讨论内容、参加单位等;二是主会场技术保障人员的情况,包括了当次会商现场保障的导播岗、MCU会控岗、视频切换岗等人员及其他保障人员,另外还包括其薪酬工资情况、职务等;三是省市单位的参会状况,包括了省市名称、在视频、音频、VGA双流等方面存在的问题等。其中,第一类信息会商基本情况与第二类信息主会场技术保障人员、第三类信息省市状况间都是一对多(即1∶N)的关系,而第二类信息主会场技术保障人员与省市状况间是多对多(即N∶N)的关系。对这三类信息都可进行二次检索统计。E-R结构关系如图3所示。
根据以上分析,对软件的数据表设计如图4所示,包括:3个原始信息表,分别为会商基本信息表DutyDb、技术保障人员表StaffDb、各省市分会场情况表ProvDb;3个二次检索统计表,分别为员工加班费用统计表SalaryLj、会商关键字查询库Search、各省市分会场状况表ProvLj。其中SalaryLj是在DutyDb和StaffDb的基础上二次检索形成的,Search是在DutyDb的基础上检索形成的,ProvLj是在DutyDb和ProvDb的基础上二次检索形成的。
在3个原始信息表中,以DutyDb来记录会商的基本信息,如序号、值班保障人员、基本参数(如时间地点参加单位等、各会场反馈状况等),为方便日后的查询统计,会商查询的关键字确定为时间、主会场地点、召开单位、会商类型;以StaffDb来记录技术保障人员的信息,包括序号、员工姓名、工资、职称等,其序号与DutyDb的序号为同步更新关系;以ProvDb来记录各省的问题状况,包括序号、31个省直辖市、4个计划单列市的问题状况,其序号与DutyDb的序号为同步更新关系。
5 关键技术点
5.1 会商故障术语细化与规范
会商故障一般分为视频、音频、VGA双流及调试等方面[7,8]。因为各省市的故障状况不一,且为文字描述,不利于以后的二次统计检索,故综合考虑目前会商和以后可能出现的问题,对视频、音频、VGA图像及调试中的不同问题分别作了分类和术语细化,设计以英文26个字母来分别表示,由此原始信息记录表以字母形式来记录,方便以后的查询与统计。故障的细化分类与英文字母的对照如图5所示。
5.2 可方便复用的类图设计
在数据信息处理过程中要频繁操作数据库,为提高软件构架的清晰度,保证程序稳定性、数据传递友好性,软件的数据流框架可以进一步设计类图,如图6所示。
3种主要的类如下:
1)数据库基本操作类CAdoData。考虑到在软件中对不同数据表要进行频繁地读取、写入操作,故把常用的指针和动作提取出来,封装为一个父类[9],以方便可复用。
2)对话框类CDailyInDlg,CprovConf及CformDerive。这些类均继承CAdoData的属性和函数。其中,CDailyInDlg作为会商基本信息输入的对话框类,负责数据的界面输入、数据勘误、数据写入及数据修改,主要操作DutyDb表;CProvConf作为各省市的会商中有关问题输入的对话框类,负责数据的界面输入、数据勘误、数据写入及数据修改,主要操作ProvDb表;CFormDerive作为数据二次检索的对话框类,负责按照各关键字段检索、显示,统计特定查询下会商的次数和持续时间,各省市的问题状况统计,并可根据不同的查询生成不同的数据表,可方便导入到Excel中完成表格化打印。
3)其他类CmainFrame及全局对象和全局函数。在CMainFrame中主要实现调用各对话框的菜单项,全局对象主要是以全国35个省市的名称、问题状况等为主的对象,全局函数实现的是前面提到的各问题状况字母化表示与文字描述之间相互对应的关系。
5.3 数据同步更新机制
数据写入过程中,除基本读写操作需对数据的有效性进行检测之外,主要涉及2个表DutyDb与ProvDb的同步更新问题。因考虑到数据输入界面的友好性,除了每次会商时必填的基本项是在一级输入界面外,省市分会场情况是列入二级输入界面。2个输入界面对应的2个数据表之间必须同步数据更新,并以二级界面数据记录服从一级界面控制为大前提。图7为数据写入流程,在一级界面主对话框CDailyInDlg选择取消时,二级界面从对话框CProvConf即使已有写入操作也要撤消;在主对话框CDailyInDlg选择写入时,从对话框CProvConf即使没有相关的信息录入也要添加空白记录。如果设定对话框选择写入为“+”,取消为“-”,则主对话框CDailyInDlg与从对话框CProvConf的选择项可组合为“++”、“+-”为写入,“-+”“--”为取消。
6 小结
软件实现了天气预报电视会商运维管理信息的快速归档、单个或多个关键字检索、输入输出信息校准提醒、查询结果二次修改等功能,统计结果可以通过列表窗口、导出为Excel的VBA自动化表格、消息弹出窗口等三种形式输出,达到预期目的,并投入了业务试运行,在天气预报电视会商的业务化运行中起到了自动化、规范化的作用,为各级气象管理部门检查、监管会商系统运行情况提供了有力保证,从而促进了天气预报工作的顺利进行。
参考文献
[1]姚鸿,邓鑫.全国天气预报电视会商系统MCU应用技术探讨[C]//全国天气预报电视会商及电视会议系统第一届技术交流会.北京:中国气象学会,2008:359-365.
[2]宋莹,宋昕,齐东城,等.河南省国土资源视频会商系统建设研究[J].电视技术,2012,36(18):41-43.
[3]姚鸿,李春来,邓鑫,等.视频会议在气象业务中的应用前景分析[J].电视技术,2011,35(17):108-113.
[4]全国天气预报电视会商业务规定(试行)[EB/OL].[2013-02-21].http://www.doc88.com/p-382740668028.html.
[5]侯俊杰.深入浅出MFC[M].2版.武汉:华中科技大学出版社,2001.
[6]SCEPPA.ADO编程技术[M].石均,葛俊,译.北京:清华大学出版社,2001.
[7]卢伟萍,詹利群,赵芳,等.广西天气预报视频会商系统网管软件的操作及常见问题诊断[J].广西气象,2006,27(1):52-54.
[8]孟慧芳.山西省天气电视会商系统的应用与常见故障维护[J].科技情报开发与经济,2008,18(15):172-173.
软件运维管理 篇4
中化集团是国有重要骨干企业, 世界500强位列前茅, 是中国四大国家石油公司之一, 业务涉及能源、农业、化工、地产、金融五大领域。
面临问题
1.用户服务存在的问题
随着用户数量的不断增长, 缺乏统一的受理平台来记录所有用户请求, 导致无法满足日常服务需求。所有工单处理没有区别, 全部由一线运维人员根据自己的经验进行解答, 一线运维人员之间在经验和个人素质等方面存在个体差异, 没有规范的解答标准也没有服务级别的区分, 导致解决问题效率降低, 用户满意度差;缺乏有效的知识库系统, 降低了问题解答的效率和解答问题口径的一致性;缺乏通知提醒功能, 导致技术员无法快速响应与处理工单。
2.数据中心运维存在的问题
数据中心运维服务的主要内容是受理和解决对支撑应用系统运行的各类软硬件设施进行运维的过程中遇到的各类问题, 运维对象包括数据中心的基础设施、基础服务、各类硬件 (小型机、服务器、网络设备、安全设备等) 、系统软件、数据库、中间件等。目前运维服务受理途径仅仅是普通的电话交流, 没有相应的服务平台和配套的服务流程进行支撑。因此, 应用系统的运维服务需要一个更加高效、更加强大的服务平台从人员、流程、技术等多方面对应用系统的运维服务工作起到更为有效的支撑作用。
解决方案
中化集团经过测试多款产品后, 终于确定选择卓豪ITSM软件Service Desk Plus作为运维管理平台。用户通过统一的接入点接入, 并通过电话 (与Avaya呼叫中心系统集成) 、邮件、网站等多种途径受理信息化系统软硬件在使用过程中遇到的各类事件和问题的请求。
请求提交后由服务台根据请求的内容、性质及涉及的信息系统和模块 (从配置管理数据库中调用) 填写工单并转入相应处理流程, 处理完毕反馈给服务台并由服务台关闭请求。通过这种体系化的运维服务平台, 不仅提高了各类运维服务请求的解决效率, 同时流程控制每一个运维服务请求均形成有效闭环, 切实提高了用户对服务申告的满意度。
此外, 利用CMDB实现对两千多个资产及关联关系的管理, 并为IT服务流程提供基础数据。借助知识库, 记录和积累常见问题的解决方法, 大大提高了运维的效率。
客户评价
开发运维平台实现运维事务管理 篇5
大型应用系统的运行, 涉及人员多、分布广, 运维工作量大且繁琐, 运维问题由业务经办、系统管理、软件开发等部门人员通过交互方式解决, 关键业务还需办理审批手续, 使用纸质单据流转。
实际操作中存在以下问题: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 结语
软件运维管理 篇6
1.压缩运维成本需求与增加运维成本需求之间的突出矛盾, 使得建立成本定额成为解决问题的重要手段
目前, 电信企业处于竞争激烈的态势, 为了提高企业竞争力, 成本控制往往是有效手段之一。市场营销成本、客服成本、网络建设成本因其直接与公司盈利或客户感知有着密切关系, 因此很难成为压缩的对象。而网络维护运行成本由于不直接转化成市场份额, 在短时间内不会影响公司大局, 属于后端支撑类成本, 因此成为成本压缩的重点方向。然而, 随着日益扩大的网络规模, 新增设备越来越多, 需要的维护运行的工作量越来越大, 运维成本的需求和实际开支也必然越来越大。压缩运维成本需求与增加运维成本需求之间的矛盾导致如何保证适量的运维成本成为电信企业急需解决的问题。而成本定额可以对需要的运维成本进行合理估算, 保证重点领域运维成本预算资金的到位, 解决电信企业运维成本管理的难题。
2.电信企业运维成本精细化管理要求, 使得建立成本定额成为有效手段
电信企业目前对运维成本大多处于粗线条管理阶段, 普遍存在运维成本项目名词不统一, 各项目支出无依据和标准等情况。运维成本的控制往往依附于公司利润空间, 运维成本预算规模的确定一般是参考历史数据和受限于公司成本费用总额, 因此多带有主观色彩。这种管理模式不能适应竞争压力下成本精细化管理的强烈需求。采用定额管理, 建立成本与资源的关联关系, 能够促使企业盘清家底, 实施成本动态管理, 使各种费用开支有章可循、有据可依, 避免费用开支的盲目性、随意性, 提高成本使用效率。
3.全面预算管理的要求, 使得建立成本定额成为必要手段
2011年11月24日国资委发文《关于进一步深化中央企业全面预算管理工作的通知》要求央企推进全面预算管理。目前, 电信企业的成本预算管理通常的做法是与上年比较分析, 结合下达的任务目标, 分解下达当年的预算, 忽略动态管理方面发生的变化。因缺乏对成本费用的动态分析, 未取得有效信息资源, 不能及时准确完整的反映企业的生产经营状况, 不能实现真正意义上的全面预算管理。建立并执行成本定额, 把它作为企业进行成本核算与成本控制的基础, 能够深化全面预算管理。
►►二、电信企业运维成本定额制定的原则和内容
(一) 电信企业运维成本定额制定的原则
为保证电信企业运维成本定额发挥最大的作用, 成本定额标准的制定应该执行以下原则:
1.全面性
定额范围应该涵盖电信企业主要网络维护和运行成本, 保证能够通过定额确定运维成本所需规模。
(1) 国内三大电信运营商已经实现全业务经营, 运维成本定额应该包括移动网络和固定网络。
(2) 电信企业的运维成本包括维护成本和运行成本。因此定额应该涉及续保费、代维费、修理费、网优费、房租租赁费、能耗等用于网络维护运行的主要成本。
(3) 电信企业的运维成本有若干驱动因素, 因此定额应该根据驱动因素的主次级别设立一级定额、二级定额, 如果需要可以继续细分, 设立三级定额。对成本的三级定额测算结果进行汇总, 形成成本的二级定额标准。制定二级定额资源驱动因素与一级定额资源驱动因素的折算公式, 计算一级定额指导标准。通过对一级定额进行对标分析, 验证调整二、三级定额标准。
2.科学性
电信企业资产规模庞大, 部门数量繁多, 为保证定额能在业务类型相同的部门、分公司合理运用, 定额的制定要具有科学性。
(1) 考虑地区差异, 设定地区系数
国内各地地域情况、网络规模、物价水平存在一定的差异, 制定定额标准时应该设定地区系数。
(2) 考虑项目周期, 设立调整系数
部分维护项目因有不同的维护周期, 因此制定定额标准时要设立调整系数。比如代维费, 在维护周期分别为3个月、2个月和1个月的情况下, 需要支出的成本是不一样的;在维护站点类型分别为标准站、距市区100公里以外、高山海岛站等时, 需要支出的成本也是不一样的, 因此需要分别设立不同的调整系数以合理确定成本规模。
(3) 考虑成本项目差别, 设立定额级别
根据成本精细化管理程度的要求以及成本项目本身的特点, 分别设定各项目的定额级别。如对容易混入其他费用的修理费, 可以设立三级定额, 第三级定额分别就修理费涵盖的日常修理、大修理及修理用耗材按具体修理的设备制定标准, 第二级定额直接根据具体修理的设备制定修理费的定额标准, 第一级定额根据设备划归的网络类型制定标准。
(4) 考虑网络属性, 设立差别定额体系
移动网络和固定网络承载的业务不同, 支撑的设备不同, 资源类别也不同, 因此制定运维成本定额时必须分移动网络和固定网络分别设立定额体系。
3.统一性
(1) 成本项目统一。定额是在企业集团范围内推广的标准, 因此定额中涉及到的成本项目要统一。
(2) 资源量核定标准统一.定额标准对应的资源量核定的标准要统一, 要有统一的折算标准和统一的计量单位。
(二) 电信企业运维成本定额制定的内容
在遵行上述原则的基础上, 电信企业运维成本定额可以主要涵盖一下内容:
1.移动网络
(1) 维护成本一级定额。按单等效物理站计算维护成本 (万元/等效站·年) 设立定额;
(2) 维护成本二级定额。按维护成本中续保费、代维费、修理费分别计算设立定额;
(3) 能耗成本一级定额。按单载频计算耗电量 (万度/载频·年) 设立定额;
(4) 能耗成本二级定额。按基站能耗=主设备年耗电量* (1+传输配套耗电系数+电源效率系数) * (1+空调耗电系数) *房型调整系数*面积调整系数计算耗电量设立定额。
2.固定网络
(1) 维护成本一级定额。按固定网络10类资源驱动因素:交换、传输、IP及数据、用户接入设备、光缆线路、电缆线路、空调、电源、机房、OSS及平台类计算设立定额;
(2) 维护成本二级定额。将上述10类驱动因素细分到设备或平台计算设立定额;
(3) 维护成本三级定额。各二级定额资源驱动因素下, 根据会计科目维护成本下的三级科目计算定额, 包括维保日修、代维、大修、耗材成本设立定额;
(4) 能耗成本一级定额。按5类资源驱动因素:交换、传输、IP及数据、用户接入设备、OSS及平台类设立定额;另按运维生产用机房建立综合定额设立定额;
(5) 能耗成本二级定额。将上述5类驱动因素细分到设备或平台计算设立定额, 另按24类机房计算设立定额。
►►三、电信企业运维成本定额具体应用应注意的问题
制定科学合理的运维成本定额体系和标准后, 需要合理应用到企业管理中, 才能发挥定额的成本管理作用。在应用中应注意以下几点:
1.准确把握定额与预算的关系, 借助定额反映成本的合理需求
定额不等于预算, 定额是基于各地生产组织及管理水平现状, 测算运维成本的合理需求量, 并不直接等于其预算目标;定额是多方参与、按照统一规范的方法编制的, 反映的是运维成本的合理需求, 预算目标的确定应以定额测算结果为主要依据。
2.日常成本管控要求达到定额要求的颗粒度, 提高运维成本精细化管理水平
运维成本定额项目的日常管控应该达到定额标准的颗粒度。年初运维成本预算的编制, 应该充分考虑根据存量及增量资源量和定额标准测算出来的运维成本总量规模;运维业务的安排和合同价款的谈判应该紧密结合相应成本项目的定额标准;合同及费用的审签应该逐项对比最细维度的定额标准;成本分析应该详细分析账面成本总量与各级定额测算结果差异并落实差异原因。这样将运维成本管理由纯粹的财务环节向非财务环节延伸, 通过事前、事中、事后应用成本定额, 实现资源合理配置, 推进全方位全过程运维成本精细化的管理进程, 提升企业经营管理水平。
3.建立多维度的对标制度, 深入挖掘降本增效潜力
通过定额体系, 将成本总量分解为单价和资产数量, 应该将相对可比的项目归集后, 进行系统内不同分公司、同一级公司内不同部门、同一项目不同合同等多维度的对标, 配套建立公司统一的对标制度, 找到分公司、部门、项目甚至合同对标后, 体现出的先进标杆以及可能存在的薄弱环节, 及时总结推广先进管理经验, 制定并落实薄弱环节的管控措施, 在为网络运维提供必要保障的基础上, 合理降低成本支出, 提高成本使用效益。
4.加强定额应用分析, 找出欠账环节以及重点管控环节, 优化运维成本结构
运维成本中由于包括能耗、租赁费在内的运行成本的刚性需求, 往往压缩续保、修理费等维护成本, 导致网络维护存在潜在不稳定因素。因此应该定期对公司运维成本逐项利用定额标准进行成本对比分析, 找出运维成本中在现有资源量下维护成本和运维成本的应有规模和环节, 对必要的成本给予预算调整和适当保证, 对于超标的成本给予重点管控, 从而保证资源的合理配置和运维成本结构的合理优化。
5.强化定额管理的权威性和有效性, 建立定额执行的考核和监督机制
为保证定额管理对成本管理作用的发挥, 运维成本定额标准制定并执行后, 应该建立相应的定额执行的考核和监督机制。一方面明确制定与定额标准挂钩的考核制度, 企业内部门、分公司等若存在未严格执行定额标准, 导致成本费用未得到合理配置和有效控制, 按照超定额比率大小, 追究相应当事人责任;定额标准执行到位, 则给予相应奖励;另一方面, 制定对运维成本使用部门执行定额标准的监督制度, 内部审计和纪检监察部门定期对建立定额的运维成本分项或整体执行情况进行审计和监察。双管齐下, 以保障定额管理对公司经营管理的有利作用。
摘要：电信企业竞争激烈, 成本控制是提高企业竞争力的有效手段, 运维成本成为企业成本压缩的重点方向。本文以运维成本精细化管理为目标, 论述了电信企业运维成本定额的必要性、制定运维成本定额的原则和内容以及运维成本定额在企业具体应用时应注意的问题。
关键词：成本定额,运维成本,电信企业
参考文献
[1]张俊明, 张海华.EAM构建运维成本控制法则[J].通信世界, 2009年10期
[2]陈为贵.浅析电信行业成本费用定额管理制度[J].引进与咨询, 2006年7期
浅谈运维管理 篇7
1 运维目标
对于SAP应用系统维护的目标,我们给出了基本的定义:
第一,系统要满足用户合理的需求,什么是合理的需求?用户的需求,要看合理性,不合理的需求,我们提供建议,变成合理的需求,以系统实现,合理的需求,即使系统不能直接实现,我们就是开发报表程序也要尽量满足用户需求。目前系统基本满足通用的业务流程需要,合理的个性化需求只要不违背板块的总体要求,不影响到别的销售公司的正常业务,作为运维人员就要尽量满足用户。
第二,改善成易学易用的系统。SAP的系统界面在销售公司的实施已经经过了一次客户化设计,本身比较简化,一些不需要的操作都不作显示。但是销售公司人员广泛,各阶层掌握的层次不一致,针对销售公司岗位化操作的特点,每个岗位相关操作的事物代码不是很多,把常用的事物代码添加到收藏夹的方法就很实用,简单的操作用户就可以更加方便的对系统操作。
第三,稳定性。保证用户正常操作和使用,尤其是月末月初,月结的时候对系统地操作人员增多,但据数量也大量增长,对系统地要求就更高,如果系统不稳定,影响到日常操作或者月末结账,就成运维事故了。
第四,提升系统的性能。销售ERP因为和多个系统进行接口,为了满足不同销售公司的个性化需求开发了很多ABAP和BW报表,这些开发虽然满足了各个公司的要求,但是不可避免的降低了整个系统的性能,我们不断提升硬件的系统性能和进行开发程序系统、接口程序的优化,来保证系统能够满足用户不断变化的正常的使用。
2 SAP系统架构及安全策略
下面我介绍一下销售公司SAP系统的架构,按照SAP的标准,首先是有开发系统、测试环境然后正式环境这三套系统。整个的系统基础平台都已是Netweaver平台,ERP系统我们现在是7100.4.14.3136版本,全部系统的数据库都是在适合大型企业的ORA-CLE下建立起来的。
下面我简单介绍一下我们使用的SAP系统安全策略,首先就是操作系统的安全,它包括了防病毒系统、操作系统的监控和我们的监控人员的日常作业。它保证了我们的各系统的正常运作,特别介绍一下SAP应用系统的策略,例如∶用户口令、用户帐号的安全策略,用户口令安全我们制定了一系列的安全策略,有口令长度的控制、例外控制、使用时间控制等,对于用户帐号的问题,我们设置连续输入三次错误密码自动锁定帐户的机制,防止他人猜测密码进入操作;还设置密码三个月自动重置,加强了安全性。
然后数据的备份策略,为了在系统出现故障时能及时恢复系统,我们从正式系统拷贝出一份,定时备份,以防系统出现意外情况,及时恢复。
系统的安全问题处理,实际上我们主要是从四个方面,一是网络安全、系统安全、数据安全、机房的安全,这四个方面都有专门人员作日常值班。每天值班人员监控系统,对于系统发生异常状况时,都能及时的发现、及早处理,并且对各种异常我们都制定了一系列的处理的流程,比如SLM系统提报机制,根据问题级别,分类处理。然后对于用户的问题处理,用户是能使用系统还是不能完全使用,可以根据不同情况处理作不同的处理。最后还要总结这些问题,制定策略一方面是以后如何避免该问题的发生,一方面是制定以后再出现类似的问题如何处理的流程,以便及时处理好这些问题,提高用用户的满意度。
3 运维的问题以及解决方案
目前主要存在的运维问题有以下几点:
第一、新客户主数据申请时间较长,新开发客户销售业务无法及时开展。
目前,新开发的客户申请流程如下:申请FMIS7.0编码→MDM平台申请ERP编码→ERP编码扩展→财务对照表维护→财务对照表审核→财务责任中心对应。由于FMIS7.0编码和ERP编码申请均需要经过股份和项目组相关人员审批,流程较长,后续流程属于我公司可控范围。目前完成客户申请提报到财务责任中心对应至少需要2个工作日的时间,在此阶段该客户发生的业务无法按照正常业务流程在线运行,导致新增客户困难,影响市场开发。
尽量优化申请流程,尤其是要保证ERP系统内这部分可控范围内的效率,这至关重要,其他系统的操作我们可以电话联系相关人员进行沟通解决。
第二、由于系统流程设计原因,发生的非正常数据,系统考核未剔除。
销售公司对于ERP系统的使用进行考核,一些停用的加油站在系统内并未删除,基数过大导致考核成绩差。
系统内停用的站点都是以冻结客户的形式暂时不允许使用,并不是真正删除,所以导致考核时统计并未刨除这部分加油站。这一点的改进需要调整考核的策略,按照客户数量进行统计在用的加油站客户。
第三、结账时系统速度太慢。
月末结帐时,用户登录系统数量增大,导致系统数据交互频繁,速度减慢。
增大服务器内存,优化程序,提高服务器响应速度。
第四、应用问题。
由于销售公司实行岗位轮换,人员变动频繁,第一批参加ERP系统上线的关键用户大多都不在原岗位上,接手人员由于工作交接、缺乏业务知识等原因,操作不熟练,造成一定的错误。
由于每个销售公司都有专门的运维负责人,各个运维负责人可以根据该公司情况制定出专门的培训手册下发,大家通过看材料自学,在线提问解答的方式尽快完成知识转移。
4 运维流程的优化
目前的运维流程为,分公司用户提出问题给他们的关键用户→关键用户提报SLM至运维中心并发传真→运维中心收到传真转问题给运维负责人→运维负责人转问题给相应负责人→在测试系统处理完毕→运维负责人测试→运维负责人发起传输到正式系统的申请→运维负责人在传输完毕后转移问题给提报人→提报人关闭该问题。
优化流程需要从各个环节做起,首先要求提报人把问题写清楚、要求提明确,减少运维中心和运维负责人进行问题分类和分析的时间;完善测试系统,使测试过程简化;提报人经常提完问题就不再关注,这一点需要纠正,时刻关注邮件提醒,问题转移回来及时通知各分公司用户。
5 结论
运维管理是提高ERP系统顺畅运行的必备保障,已经成为中石油信息化建设的重要组成部分。运维管理可以有效解决实际系统运行中的各类问题。运维工作是一项长期、重复性较多的工作。运维人员要做好预防性的工作,做到防微杜渐;尽量减少人为因素对运维流程造成的不及时性,使运维工作更加有效率。
摘要：该文介绍了运维工作的目的,通过系统架构的分析,从安全策略上的应用保障了运维工作顺畅进行,提出目前运维工作遇到的问题并给出了合理的解决方案,对运维流程给出优化意见。执行有效的运维管理,可以解决系统运行中的各类实际问题,是运维工作更富成效。
关键词：运维管理,ERP,安全策略,SLM,客户主数据
参考文献
[1]王庆琛,刘琨.基于ITIL的石油销售ERP运维体系构建[J].电脑知识与技术,2011,7(12):2753-2754.
运维安全管理系统设计 篇8
关键词：运维安全,系统设计
一、当前运维安全管理的问题
随着企业信息化的不断发展, 支撑企业的各种网络设备、主机系统、应用系统也在不断壮大, 各类业务系统也日益复杂。对于一个企业来说, 最大的威胁和破坏往往来自于企业内部, 主要表现为: (1) 账号管理无序, 多人共享账号。 (2) 权限管理粗放, 系统安全难以保证。 (3) 日志粒度粗犷, 事件无法定位。 (4) 缺乏统一的运维审计机制。 (5) 缺乏对第三方代维管理的行为监控, 等等。
解决上述问题仅仅依靠严格的规章制度来对运维人员进行约束是远远不够的, 堡垒机应运而生。堡垒机能做到对运维人员账号的安全管理和审计, 但不能审核配置信息的正确性, 运维人员维护系统的操作是否正确, 信息系统配置变更后是否安全等等也都不在堡垒机的控制范围内。为保证信息系统的安全可控, 必须设计更有效、更合理的运维安全管理系统。
二、系统设计思路
为更好的满足运维安全管理的需要, 系统既要实现安全管理, 又要能和安全配置核查有联动作用, 实现“系统运维——运维审计——运维核查——问题定位”的全封闭式管理, 如图所示:
主要模块说明如下:
2.1权限管理模块。这一模块的主要目的是隔离终端用户对网络设备和服务器资源的直接访问——通过防火墙等访问策略, 不允许设备 (包括网络设备、操作系统、数据库和应用系统等) 的运维人员直接登录, 所有操作必须经过运维安全管理系统, 任何用户对目标的访问都必须通过此模块进行翻译, 系统能够截获所有操作行为。具体流程为:运维人员要先登陆运维安全管理系统进行身份认证, 通过认证后运维人员提出相应的操作申请, 该请求通过运维安全管理系统权限检验后, 系统将代替运维人员连接到目标设备进行运维管理, 并将结果返回给运维用户。
主要包含以下几个子模块: (1) 账号管理模块。账号和资源的集中管理是集中授权、认证和审计的基础。账号管理模块能够对所有服务器、网络设备、安全设备等账号进行集中管理, 制定统一的、标准的账号安全策略, 进而实现对账号整个生命周期的监控, 账号集中管理也能降低管理大量账号的难度和工作量。 (2) 身份认证模块。用户在登录设备前先连接到运维安全管理系统进行身份认证, 再进行操作申请, 认证模式包括动态口令、静态密码、硬件key等多种方式。同时, 还具备单点登录功能——用户一次登录成功后, 可以无需认证的访问被授权的所有系统。单点登录为具有多账号的用户提供了方便快捷的访问途径, 使用户无需记忆多种登陆ID和口令, 提高了效率;同时, 由于系统本身采用强认证, 从而提高了用户认证环节的安全性。 (3) 资源授权模块。通过集中授权和统一的访问控制, 该模块不仅能够根据用户的权限对主账号能够使用的从账号进行授权, 还能实现对行为和资源命令级的细粒度控制, 能够对不法命令进行阻断, 严防非法、越权访问事件的发生, 最大限度的保护用户资源的安全。 (4) 操作审计模块。模块能够对账号使用情况、资源使用情况、执行操作等进行全程的追踪并记录日志, 实时监控并记录运维人员对操作系统、安全设备、网络设备、数据库等进行的各种操作。具有审计权限的用户可以登陆系统查看监控结果, 出现问题能够直接定位到问题的根源所在, 迅速追责。
2.2安全核查模块。安全核查模块能够以管理员的身份 (权限由权限管理模块处获得) 登陆目标系统, 从而得到各个系统主机、网络设备、数据库、应用平台等的配置信息, 根据提前设定的系统配置规范进行核查, 确保配置是满足安全规范要求的。
该模块主要作用是确保运维人员维护各信息系统的操作正确, 以及信息系统配置变更后是否安全。同时, 如果配置规范发生变化, 模块能够快速地对相应的设备、服务器、应用平台进行配置核查工作, 摒弃传统的人工逐一检查, 降低人工成本和操作复杂度。
2.3配置变更联动管理。当运维人员需要对设备的配置进行变更时, 先通过账号管理模块登录。登录后, 整个配置变更过程在审计模块的监控下执行。更改时, 权限管理模块将相应的用户密码传递给安全核查模块, 运维人员的配置完毕后, 安全核查模块即可以自动对配置后的信息进行配置核查, 检查修改后的配置是否符合现有的安全规范。
如果存在不符合安全规范的地方, 安全核查模块会自动告警, 并出具报告。安全管理员就可以及时发现系统配置的异常情况, 并通过审计模块定位到相应人员, 责令其进行整改。整改的过程也属于配置变更过程, 依旧要求在审计模块和安全检查模块监控进行下操作, 当新的配置能够符合安全规范时, 整个配置变更过程才算完成闭环。
三、结束
本文的运维安全管理系统除了能够解决传统的堡垒机能解决的账号管理、登录审核等问题外, 还能进行配置审查, 并对运维人员修改策略后, 新的策略是否满足安全规范等进行实时的核查, 实现“系统运维——运维审计——运维核查——问题定位”的全封闭式管理, 能够更加合理、高效、安全的对企业运维进行安全管理。
参考文献
[1]郝永清.堡垒主机搭建全攻略与流行黑客攻击技术深度分析[M].科学出版社, 2010.