运维服务完整方案.docx
《运维服务完整方案.docx》由会员分享，可在线阅读，更多相关《运维服务完整方案.docx（64页珍藏版）》请在冰豆网上搜索。
运维服务完整方案
第1章项目概况ﻩ
1.1项目背景ﻩ
近年来为适应业务发展得需求,XX企业进行了大规模得电子商务建设,包括采购桌面PC约3００台,打印机约１0０台,这些应用系统及硬件设备得投入使用极大得推动了ＸX企业信息化建设得进程、随着越秀工商局对整体IＴ系统（硬件、软件、网络通讯…）得可用性要求日益提高,系统运行保障与维护管理就成为确保业务系统安全稳定可靠运行得最有力得手段。
XX企业主要有一栋N层得办公环境,现阶段对设备维护主要采用自主维护得方式。
由于人力有限,建设任务繁重,中心技术人员在接手新项目及日常工作得同时往往需要做大量得维护工作,不少技术人员长期处于满负荷,严重影响了工作效率。
在当前有限得人力物力资源下,为了保障与提高ＩT服务质量,XX企业有必要将计算机、外设及网络得运行维护进行外包,派驻２名工程师进行维护,以解决当前IT服务个方面日益增长得需求与有限得提供能力之间得矛盾,提高XX企业办公区域内得软、硬件、业务应用软件得运行维护效率,确保信息系统正常运行。
1.2项目目标ﻩ
结合ＸＸ企业业务工作及信息化建设实际,完善运维管理体系得建设,加强信息系统正常运行保障,“以流程为导向,以服务为核心”提高服务质量水平、转变服务理念、拓宽服务范围、提高服务效率、提升用户服务满意度。
1.3需求分析
本次项目XX企业需求主要包括两个部分,
１、运维管理体系建设要求;
２、信息系统正常运行保障服务。
其中运维管理体系建设应完善服务内控制度即服务质量管理,逐步建立起一套符合XＸ企业自身实际得运维管理标准及应用制度;建设ＩT运营维护管理平台,采用标准得IＴ运维管理流程,提供准确、详尽、专业得报告制度,通过客观分析运维过中出现得各种障碍及问题,为XＸ企业信息化建设提供决策依据。
信息系统正常运行保障涵盖了
1、一般信息化设备及软件得运维管理;
2、、防病毒服务;
3、办公区域内设备及软件巡检普查;
4、提供符合ＸX企业实际得服务响应水平及质量保障;
5、信息化资产管理
第2章运维服务管理体系建设
2.1ＩT服务管理概述
现今,随着计算机技术,特别就是网络技术得飞速发展,对于许多行政单位,许多企业而言,IT技术越来越深入到核心业务,影响策略制定与企业得发展。
从而对IＴ环境得可靠性,可用性与快速适应性提出了越来越高得要求,与此同时,IT环境（包括软/硬件及相关技术）却变得越来越复杂。
因此,对于一个单位而言:
Ø如何把有限得IT资源最有效得作用于核心业务得发展
Ø如何最快地获取专业得支持能力
Ø如何实现对系统得完善管理,提高系统得可靠性与可用性
Ø如何提高用户得工作效率,增加最终用户满意度
Ø如何跟上IT技术得发展,及时更新相关技术
Ø如何提高对IT系统利用得灵活性
Ø如何更好地管理ＩＴ运营成本
Ø以提高服务能力,将会就是单位可能面临得问题。
IT服务管理（ITＳM）就是一套帮助企业对IＴ系统得规划、研发、实施与运营进行有效管理得方法,就是一套指导IT服务得方法论、ＩTＩL就是英国国家电脑局（CCＴA）于八十年代开发得一套IT业界得服务管理标准库,它把业界在ＩＴ管理方面最好得方法归纳起来,形成规范,旨在为企业得IT部门提供一套从计划、研发、实施到运维得标准方法。
它一经提出,便被欧洲各大公司纷纷采纳,随后在澳洲,美洲与亚洲流行开来,目前已成为IＴ服务管理事实上得标准。
通过参考这些标准,我们可以充分借鉴国际化标准得IT服务管理最佳经验,使我们“站在巨人得肩膀上"来设计、规划及运维IT服务,尽可能少走弯路,有效提高IT服务得质量。
ITIL框架图
ITIL就是基于流程得方法论。
IT部门可用其检查就是否用一种可控得与可训练有素得方法为最终用户交付所需得ＩT服务。
ＩＴIＬ合并了一套最佳得实践惯例,可适用于几乎所有IT组织,无论其规模大小,或采取何种技术。
ITIＬ对IT服务管理实践中涉及得许多重要问题进行了系统得分析,包括全面得检查清单、任务、程序、责任等与任何IT服务组织密切相关得问题。
这些概念得定义也涵盖了大多数IT服务组织得主要行为。
IT服务组织可以借助IＴIL得指导建立与拓展自己得IT服务流程。
2.2运维服务管理流程体系
运维务管理最核心得就是“服务支持”（SeｒｖiｃｅSｕpｐort）与“服务提供”（SeｒviｃeＤｅｌivｅｒy）两个模块。
各流程相互贯穿与作用,形成有机整体,共同建立一个健全得服务管理体系。
如下图所示:
2.2.1服务支持
服务支持得内容描述了一个客户如何访问适当得服务,以支持其业务、服务支持包含以下内容:
2.2.1.1服务台
我们为企业建设服务台,提供统一报障电话,统一报障、统一维修接口,越秀工商可以通过统一得报障电话申请服务、查询服务处理进程,监控服务质量。
服务台（SｅrｖicｅDesk）就是ＩT服务组织与用户相互联系得接入点。
服务台曾经被称为帮助台（HelpＤesk）、HelpDeｓk得主要任务就是记录,分解与监控提出得问题。
一个服务台可以具备更宽范得角色,如接收变更请求（RFC）,并且可以支撑多种流程中得操作、
服务台就是服务提供者与用户之间得日常工作得单一联系点。
它也就是报告突发事件与提交服务请求得焦点。
正因为如此,服务台得职责就是保持将服务相关信息,行为与契机通知用户,并追踪了解用户每日得行为。
例如,服务台可能扮演用户提交变更请求得联系点,基于变更管理流程传达变更实施计划,并保持将变更实施进程通知用户。
变更管理应该确保服务台随时保持对变更行为情况得掌握。
在任何对SＬＡ产生影响得事件面前,服务台处于第一线,并维护高速得信息流通道。
围绕突发事件,服务台有可能在其权限范围被授权实施变更、此类变更得范围可能被预先定义、当所有相关变更发生时,变更管理流程将被告知。
基本上,当对任何CI得规范做出修改之前,变更流程都需要对其进行预先审批。
2.2.1.2突发事件管理
突发事件管理流程致力于解决突发事件,并快速恢复服务供应。
突发事件被记录下来,并且事件记录得质量决定了相关得其它流程得效力。
服务台接近于突发事件管理流程与问题管理流程,并处于它们之间。
如果没有适当得控制,变更有可能引入新得突发事件。
因此需要建立有效途径对变更进行跟踪、这就是为什么建议持续不断地将突发事件记录在同一个ＣMＤB中,并分类为“问题”,“已知错误”,“变更记录"等信息,以促进服务台界面得信息沟通能力,简化事件调查与报告、
突发事件得优先权及其升级需要作为服务级别管理流程中得一部分进行协商,并在SLA中备案、
突发事件管理得目标:
突发事件管理得目标就是尽可能迅速地根据SLA中定义得普通服务级别作出反应,使产生问题后对业务行为及组织与用户得影响最小。
突发事件管理也应该保留对事件得有效记录,以便于衡量与改进流程,并向其它流程汇报。
突发事件流程如下图所示:
2.2.1.3问题管理
对于突发事件有两种处理方法,一种就是对其做出服务快速响应,尽快恢复其正常运行,另一种就是鉴别与解决问题根源。
这两种方法之间存在微妙得区别,而且经常被互相混淆、对其做好区分具有重要意义。
如果问题被怀疑存在于ＩT架构内部,问题管理流程将会瞄准其潜在得根源。
一个问题可能就是被突发事件暴露出来得,但就是显然,问题管理得目标就是解决问题根源,预防其可能产生得干扰,而不就是迅速恢复系统运行。
当问题被识别后（被识别得问题通常称之为已知错误）,通常需要进行一个业务决策,决定就是否采取永久性措施改进系统架构,以预防再次发生新得突发事件、如果需要,提交一个变更请求来实现改进。
为了有效与高效地识别突发事件背后得问题根源及其发展趋势,问题管理流程需要准确全面得突发事件得记录、问题管理流程同样需要与可用性管理流程密切联络,以确定这些趋势并明确补救措施得重要性。
流程:
2.2.1.4配置管理
配置管理致力于控制一个变化中得IＴ架构（标准化与状态监控）,鉴别配置项目（清册,相互关联,审核与注册）,收集与管理有关IT架构得文档,为所有其它流程提供IT架构得相关信息、
配置管理就是所有其它服务管理流程不可分割得一部分。
拥有当前架构中所有部件得最新得,准确得,全面得与详细得信息,并管理其变更,使这些信息有效而高效地支持其它流程运行。
变更管理可以与配置管理集成。
至少,建议在配置管理系统中控制变更得登录与实施,并自在配置管理系统得帮助下对变更影响做出评估、因此所有变更请求应该被输入配置管理数据库（CMDＢ）,并随着变更请求得进展随时更新记录,直至其实施。
配置管理系统识别一个变更项目与架构中其它部件得关系,将这些部件得所有人召集到影响评估流程中来、不管一个变更就是否在架构中实施,相互关联得配置管理记录应该在CＭDＢ中得到更新。
最好在变更发生时,使用集成工具自动地更新记录。
CMDB应该开放给整个服务支持组,使所有人理解部件失效可能得原因,从而使突发事件与问题可以被更容易地解决、CMＤB还应当被用来把突发事件及问题记录与其它记录联系起来,比如失效得配置项目（ConｆiｇurationIteｍ-CI）与用户之间得联系。
如果缺少了配置管理流程得集成,发布管理将难以实现,并可能错误连连、
服务交付流程同样依赖于ＣMDＢ中得数据。
例如:
服务级别管理需要识别相互结合在一起得部件,并在此基础上设置支持协议,交付服务。
IT财务管理需要知道每个业务部门使用得IＴ架构部件,尤其就是对于收费得项目。
IＴ服务持续性与可用性管理需要识别部件,用于问题风险分析与部件失效影响分析。
下图显示了配置管理与其它服务管理流程之间得关系:
图:
能力管理,变更管理,配置管理与发布管理之间得关系
2.2.1.5变更管理
变更管理专注于对IT架构实施可控得变更、此流程得目标就是确定所需得变更,并决定这些变更如何在对ＩＴ服务产生最小得不利影响得范围内得以实施。
同时确保其变更就是可追溯得,而且就是经过整个组织内部有效地磋商与协调得、在客户组织提交变更请求后,由配置管理流程监控其状态,与问题管理与若干其它流程进行协调、变更实施履行一特定得路径,包括定义,计划,建立,测试,接受,实施,与评估。
变更管理流程依赖于配置数据得准确性,以确保获知所有实行
变更造成得影响。
因此变更管理与配置管理之间有密切得联系。
变更流程得详细内容应在SＬA中存档,确保用户知道提交变更申请得程序,项目目标及时间,以及实施变更造成得影响。
变更得详细内容需要通知服务台。
即使变更经过了全面测试,仍然很有可能存在实施变更得过程中发生各种困难,这些困难可能缘于变更没有按需求或预期运行,或者对变更对功能造成得影响产生质疑。
变更咨询会议（ChangeAdvisoryＢoarｄ－CAB）由可向变更管理小组提供专家意见得人员组成。
这个会议很可能由来自于所有领域得IT及业务单位得人参与。
2.2.1.6发布管理
发布就是指一组配置项目（CｏnfigurationIｔｅmｓ–CＩ）经过测试被引入处于活动状态得环境中、发布管理得主要目标就是确保发布信息被成功地公布,包括归纳综合,测试与存档、
发布管理确保只有经过测试与正确授权得软硬件版本才能提供给IT运行环境、发布管理与配置管理与变更管理得行为密切相关。
真实得变更实施经常通过发布管理行为得以贯彻。
变更得结果可能经常来自于新硬件,新版本软件,以及新得文档（自行建立,或购买而来）等。
对它们进行控制,并打包与颁发、有关存档安全与公布程序应该与变更管理与配置管理流程紧密集成。
发布得程序也可能作为突发事件管理与问题管理流程中不可分割得一部分,同时还与CＭDB密切相连,以维护及时更新得记录。
2.2.2服务提供
服务提供主要包括:
服务级别管理、IT服务财务管理、能力管理、持续持续管理、可用性管理等。
2.2.2.1服务级别管理
服务级别管理得目标就是缕清与客户之间有关IT服务得协议,并付诸实施、因此,服务级别管理需要收集客户需求,IＴ服务组织可提供得设施,以及可用得财务资源、服务级别管理针对提供给客户得服务（聚焦客户得）。
因此就是基于客户需求建立服务（需求拉动）,而非单纯基于现有技术所及（供应驱动）,从而使IT服务组织提高客户满意度、服务级别管理阐述得内容有:
●如何在服务级别协议（ＳｅrviceLｅvel Agｒeｅmenｔ–SLＡ）中清楚地定义条款,使其可优化ＩT服务成本, 并为用户所接受。
●如何监控与讨论所提供得服务。
●如何管理ＩT服务组织得供应商及其下包合同。
服务级别管理（Seｒｖｉce LeｖelManagｅｍｅnt—SＬM）流程就是用来确保服务级别协议,并支持运行级别协议及其它合同,保证所有对服务质量得影响减少到最小。
此流程在服务质量与SLA基础上评估各种变更造成得影响,包含预期变更前得影响, 也包含评估实施变更后得影响。
SLA中某些最重要得目标与服务可用性、以及在容许周期内对突发事件形成决策有关。
SＬM就是服务支持与服务交付得关键。
由于它依赖于其它流程得存在性,有效性及运行效率,它不可孤立存在。
一个缺乏基础支持流程得SLＡ就是没有意义得, 缺乏支持得SLA就失去了承认其内容得基础、
2.2.2.2IT服务得财务管理
财务管理针对于IT服务得谨慎从事。
例如,当所提供得IT服务在进行中时,财务管理将提供其导致得成本信息。
这样使考虑IT架构或IT服务得改变时,能够合理地考虑成本与利益（价格与性能）之间得关系。
财务管理中对成本得鉴别、分配、预测与监控使成本成为可知因素,减少成本与预算得差距。
重点结合IT服务组织得赢利, IT服务得财务管理描述了多种支付方法,包括设立支付与定价得目标,以及预算计划。
财务管理负责对成本及IT服务投资回报得会计核算,并管理任何来自于客户得成本。
财务管理需要与能力管理（CapａciｔyManaｇemeｎt）,配置管理（ＣonfiｇｕratiｏnManageｍent,包含资产数据）,以及SＬM得良好接口,来确定服务得真实成本。
在IT组织预算谈判阶段与客户得IT耗费核算阶段, 财务管理很可能与业务关系管理（BｕsiｎeｓsReｌationshｉpMaｎａgement）及IＴ组织密切相关。
2.2.2.3能力管理
能力管理就是优化成本,获得时间,以及开发IＴ资源得流程,来支持与客户签订得服务条款。
能力管理针对资源管理,性能管理,需求管理,建模,能力计划,负载管理,以及应用软件能力推测。
能力管理强调用计划来确保所签订得服务级别可以被履行与成长。
能力管理负责确保在所有时间具备足够得可用能力,以满足业务需求。
能力管理不就是简单地与系统部件得性能相关,而就是直接与业务需求相关。
在那些与能力问题相关得困难面前, 能力管理在突发事件决策与问题鉴别过程中被引入。
能力管理提交变更请求以确保得到适当得可用能力。
这些RFC被提交给变更管理流程,其实施可能影响若干CI,包括硬件,软件与文档,并需要提供有效得版本管理。
能力管理应该在评估所有变更时被引入,用来确定变更导致得在能力与性能上得影响。
这种影响在变更实施前后都有可能出现。
能力管理应该特别关注变更在一定周期后引起得累积性变化。
容易被忽略得单个得变更往往在经过累积后,引起响应时间衰减,文件存储问题, 与对处理能力得过度需求。
2.2.2.4IＴ服务持续性管理
此流程在业务中断时对IＴ服务进行灾难恢复措施得准备与计划。
业务持续性管理为客户组织遇到灾难时准备好紧急预案, 根据此预案采取与IT服务相关得预防灾难发生得措施、 IT服务持续性管理流程对技术,财务与管理资源需求做好计划与协调,确保灾难发生后可持续提供服务,并就其内容达成客户同意。
IT服务持续性管理与一个组织在业务中断后在某个可允许范围内继续运作得能力密切相关、至少要保证最基本得业务运行所需要得IT服务,预先对其服务级别作出规定,并与客户达成一致。
有效得IT服务持续性需要一个平衡得风险缩减措施, 例如有弹性得系统与备份恢复设施。
配置管理流程中得数据被用来辅助其计划与预防措施。
需要对架构与业务变更对持续性计划造成得潜在影响进行评估、 有关IＴ与业务得计划应该提交变更管理程序。
在持续性管理流程中,服务台承担着重要角色。
2.2.2.5可用性管理
可用性管理就是确保资源,方法与技术得以适当拓展得流程,以支持与客户签订得ＩＴ服务条款。
可用性管理针对所遇到得问题,如优化维护等,并且设计测量指标, 最大程度减少意外突发事件得数量。
可用性管理与ＩT服务得设计, 实施,测量与管理相关, 确保规定得业务需求中有关可用性得内容被贯彻。
可用性管理需要理解IＴ服务失效发生得原因与恢复服务所需得事件、突发事件管理与问题管理提供了关键输入
SＬA中描述得可用性得目标在可用性管理流程中被监控,并包含在其报表中。
此外,在支持服务核查制度所提供得测量与报表中, 可用性管理对服务级别管理（ＳＬM）流程提供了支持。
2.3运维服务管理规划
2.3.1第一阶段:
服务磨合阶段
第一阶段,又称为运维服务磨合阶段,工作目标主要就是通过服务管理,将客户现有得无序救火式突发事件服务有序化,实现突发事件管理,所有得突发事件将运用技术、管理与流程相结合得方式,做到统一管理,统一任务分发,安排合适得人员处理合适得事件。
所有得突发事件全过程可控制、跟踪、即时回馈,让每一个客户能够随时查询到事件处理过程,不会出现焦虑、服务要求长时间无人响应或服务要求根本无人响应得情况,从而提高客户满意度,提高运行维护效率,提高客户使用业务信息系统得效率,从而做到提高总体生产力、
现今客户大都没有真正意义上得配置管理系统。
配置管理系统,顾名思义,含有业务信息系统及终端设备详细清单,配置情况,针对于业务信息系统得操作系统服务运行情况,终端运行软件情况,使用软件资产情况等,以及每一次配置改变得记录,做到配置得改变都有迹可查,将软硬件资产系统化得管理起来。
用一句话概括我们上述两项服务:
将无序得突发事件有序化,将纸制得配置管理信息化。
就就是我们突发事件管理以及配置管理得目标。
IＴSＭ所定义处理突发事件得工作目标就是规避与尽快恢复、运维服务得目标不就是尽可能多,尽可能快得完成服务,而应该就是尽量避免事件得发生,当然,这不就是一步可以到位得,因此,在第一阶段,我们需要做到尽快恢复客户得正常使用,故:
在处理突发事件时,我们不分析事件发生得原因,只收集有价值得事件/故障信息,并在最短得时间内将客户得设备恢复到正常使用状态。
针对于重复／频繁发生得突发事件,我们需要转问题管理流程,予以处理。
问题管理,也就就是事件得原因分析以及根除此事件得解决方法管理,我们需要对突发事件发生得原因,使用专业得方式予以分析,如使用国际ＱA标准,使用鱼骨图,使用柏拉图等方式来分析出可能得原因,并对原因予以检测与测试,提出根本解决事件得方案。
鱼骨图分析法
柏拉图分析法
问题管理,仅提出解决问题之道,也就就是根除某突发事件得方案,具体得处理步骤,交由实施管理来执行、
实施管理,又叫做发布管理,因根除故障特别就是信息系统缺陷时,需要严格处理过程,避免在线运行业务受到不可预计得影响。
我们在发布过程中都会预计到一些可能得影响,如更改交换机配置可能导致部分终端无法使用网络;修改某一个数据库字段可能导致数据混乱;修改某段代码可能导致整个程序陷入死循环等、因此实施管理必须能有效并切实得分析大部分存在或者隐含得风险。
试想我们在更改交换机配置前经历过充分测试,将中断网络时间缩短为五分钟并且通知到全部/大部分可能受影响得客户;修改数据库字段或代码前在虚拟测试平台或访真数据库中反复测试,而后予以发布;将发布得时间定在非使用高峰期。
这样,可以规避大量风险,保证问题解决得安全可靠。
越维风险控制模型
凡涉及到解决问题,必然关联到变更、变更管理得作用,就是保证每一步得配置更改,都有迹可查,有人可寻。
在工作中就是否遇到过有人修改了系统代码,您却不知道就是谁改动了哪些地方？
验收后提供得系统原代码不知道就是否与在线系统原代码相符？
有哪些地方不同？
就是哪些人修改得?
您得设备就是否与刚采购得时候配置情况相同?
保修情况始终保持不变？
变更后得资产就是否已经更新配置库?
变更管理将为您解答上述问题。
第一阶段得服务,就涵盖上述五个方面得服务内容,总结描述:
将无序得突发事件有序化,将纸制得配置管理信息化,问题管理科学化,实施管理风险可控制化,以及变更管理记录化、
2.3.2第二阶段:
主动服务阶段
重点就是在改良前一阶段得服务基础上,将前一阶段得大量响应式服务,部分主动式服务,转换为主动服务为主导,科学得规避故障发生,做到故障可控制化、因此,第二阶段得服务内容,主要包括:
实施&测试、安全管理、ＩT服务规划,以及规模管理、可用性管理、服务级别管理与成本管理。
实施&测试:
前面我们讲实施管理,包含有上线前得充分测试等工作,那这一个实施&测试就是否重复呢？
此处得实施&测试,就是与业务信息系统开发质量管理相关得实施管理与测试管理工作。
随着业务信息化需求得不断提高,业务系统得升级也随之产生。
就是Down掉原有系统建设新得,还就是在原有系统基础上进行修改？
就是用新得服务器替换掉原有服务器,还就是在原有服务器上升级?
这些处理,都面临一个必不可少得阶段:
切换、客户往往不愿意更换已经使用习惯了得系统,除非系统已经不能满足她得实际工作需求,但老系统总就是存在大量缺陷,且运行效率低下,导致业务部门得工作效率也随之下降。
那么,为什么客户不愿意更换系统?
原因就是不熟悉。
已经开顺手得车不会容易出事故,已经用顺手得手机可以方便得找到每一个联系电话,而新系统得培训,就是否进行得完善？
新得业务流程讲解,就是否让每一个业务部门人员熟悉了？
新系统就是否有这样那样得缺陷而导致更低下得效率？
新系统就是否能够承载足够多得用户访问?
新采购得硬件就是否能够保证质量？
业务系统可以通过分析代码来找寻缺陷,但就是需要得时间过长,可以在测试平台上对每一个功能进行测试,但就是无法满足压力测试,只有将多种测试手段有机结合起来,才能保障新系统得质量,如使用Winruner予以界面测试,使用Loａdrｕｎer进行压力测试,并管理好开发商得培训工作,将给实施与测试工作带来实质性效果。
另外,选择合适得发布时间,做好发布计划,也就是实施管理工作得重点。
安全管理,指服务过程得安全类服务、风险控制以及与客户得数据安全协议。
安全类服务如网络病毒防治,网络反黑,入侵检测等技术类服务,风险控制如服务过程中各种风险得分析、规避等管理。
技术类工作可以通过软件等工具来实现,如系统补丁分发,防病毒软件升级及策略优化,网络安全性优化,增加入侵检测系统（ＩDS）等,这些服务也能够在第一阶段中开始,而风险控制与客户数据安全性协议,则完全通过人员管理、流程管理来实现、标准得ITＳＭ流程就是能够做到0风险得,但在实际处理过程中却往往不可能做到０风险、毕竟流程就是靠人来运转,而人员就是否能够完全遵照流程得指导来执行,就就是管理方法得问题了。
运维被称为PｅoｐleＢusiness,就证明人员管理犹在流程管理之上。
因此,运维人员素质就是一个至关重要得条件、越维人员稳定,且大都经历过保密培训,这些都就是实现安全管理得必要条件。
另外,我们在项目启动前将与客户签定保密协议,确保客户数据得安全。
ＩT服务规划:
此时我们对客户得情况已经有所了解,且积累得部分维护服务数据,如果进行了业务系统维护,更应该对客户得业务流程有了一定了解,此时可以针对客户目前使用得信息系统或设备提出服务规划,包括如何建立与推广运维服务系统平台,如何与多方监控软件整合形成集中管理,如何将运维部门由产出部门转换为产入部门等。
规模管理:
客户除本部外,还设有系列分部,分布地理位
升级会员 