如何以项目的运作方式进行运维管理
引言
作为企业IT的主要技术负责人，在逐步建立起支撑全国上万员工的企业IT系统的过程中，对互联网运维和企业IT运维、外网与内网、甲方和乙方之间在IT技术运用和管理实践上有深刻的感悟。
以下我谈一下本人在运维管理或者称为企业IT管理上的粗浅想法及具体应用。
曾经的我是怎么看待运维工作的?
之前听腾讯刘栖铜同学讲到运维是技术运营，我觉得挺好，很高大上，意境很令人向往!我之前有时候会粗鄙的认为运维干的就是照看一堆网络设备、服务器、各种操作系统和应用软件……让他们有效率和安全稳定的运行好。
对于运维来说，汗流浃背扛着服务器上架是常有的事情，他这一说，我就联想到网站运营、企业运营、运营某某大项目……反正感觉“运营”这个词就比较大气，这让一直以来苦逼的运维汗水一下抖落，似乎神气了。
我对运维工作的简单分类
再重复单调的工作也需要有一种超脱的心态去面对，跳出自身才能更好的做好本职工作。运维就是一项比较单调的工作，根据技术分类，运维有做机房管理的，有做网络管理的，有做系统管理的，有做数据库管理的，有做各类应用系统管理的。
从管理这个层面来看，无论是哪种技术类型，根据处理事情的特性，比如周期长短、量大事小、日常重复、紧急等等，我都把运维分为两大类。一类是日常(类)运维，一类是项目(类)运维。
我这样分类源于五六年前在PMP培训过程中的感悟，PMPBOOK书中有一段这样的话：“项目源于人类有组织的活动。随着人类社会的发展，人类有组织的活动逐步分化为两大类型：一类是连续不断，周而复始的活动，人们称之为’作业’或’运作(operations)’，如企业流水线生产大批产品的活动;另一类是临时性、一次性的活动，人们称之为’项目’(project)”。
日常运维就是属于第一类的活动，稍大的角度来看，我们的整个运维工作可能都谈不上是项目。但如何使得本来是做周而复始的工作变成一次性的工作呢?还记得在上学的时候说到微分的概念吧!如何求导?这两个问题好像奇妙的产生了火花，通过微分的方式我们可以把一个曲线函数看做是一段段的直线，从而可以求导。
项目运维是什么?
在实际的工作中，一个持续性的工作是否可以通过微分的方式将连续有波动的工作做成项目?
我想是可以的。通过将不同阶段的任务或周期性的任务进行切割和统筹安排，一个周期性的运维是可以划分成若干个微小项目的。通过对微小项目的管理建立起整个运维工作的体系。
微小项目的管理方式，也称任务式管理。这种任务式的管理方式可以有助于我们缓解长期易疲劳的运维工作。而且还可以形成快速迭代体系，让方法变得更灵活，注重交付结果的同时也关注过程。
下面我们根据几个例子来说明。在几十人的运维团队，我们实际上也是根据会议沟通和日常工作来实现了对分类的认识：
对运维分类的进一步解释
日常运维，就是咱们运维人员日常经常处理的工作内容。比如：
?系统运维人员处理一台服务器某个目录磁盘空间不足的问题;
?添加或者修改一个DNS域名A记录
?机房人员更换一块有故障的硬盘
?网络人员对某个出口线路带宽有异常的流量检查
?桌面支持人员给同事安装一个Office
?……
对这类事情处理，讲究的是“短平快”。
项目运维，就是非日常运维的内容了。大到包括一个IDC机房或者办公楼的系统网络建设，小到比如升级系统内核，因为涉及重要和关键的业务，或因技术上升级过程比较繁琐，需要考虑的方面比较多，也会放到非日常运维这块。
要重点说明的是，团队在日常运维中遇到一些故障，在快速解决后，会在统计中发现经常出现类似现象，也总会拿出来作为问题来解决。不管是理论意义上真正的项目，还是问题类项目，或者其他具有项目特征的事情，只要不能在日常运维类别中快速了结，都会考虑以项目的方式来进行处理。
这里指的是具有项目特征，要处理的事情有很多事情的集合，涉及面比较广泛，成功完结后有从无到有的深远影响，也像项目一样是计划内的，周期也相对比较长，涉及的资源和人员也可能比较多。
具体其他特征可以参考下项目管理方面的书，但是可不能硬套。所以这类事情个人认为按照项目管理的方式去落实和推进非常合适，这也是为什么称为项目类运维。
总之，通过综合处理各类运维事情的共性，做了一个二分法，日常运维和项目运维。非此即彼，也好划分。
如何立项?
在实际操作中，由于没有太明确的定义，一般同事也不好掌握。但既然是项目，还是有立项门槛的，最后能不能立项，还是需要几个人讨论后才能说了算的。但这几个人怎么确定?
答案是，当然不是终身制的所谓立项委员会，原则上根据这件事的利害关系及简单好操作来确定。
在实际工作中，团队的例行会议中就可以了，毕竟负责各个技术方向的主管人员都是技术出身的，能够把握好方向。举个例子：
我们发现日常运维中某个路由器CPU始终很高，连续很多次触发报警，日常运维中通过分流可以缓解。但是，实际报警时候流量负载并没有到达设备的设计上限。初步推断就知道需要进行更深入的排查。这时候由谁来发起立项呢?
?通常网络管理员会在周期工作报告中汇报这个问题，希望提升成为项目，以查找问题根源。
?当然这种情况也可能是他的主管领导，在查看日常运维处理报表中发现这个事情经常出现，而希望提升为项目。
?另外还可能是服务器系统管理员，发现最近某些服务器或者应用网络延迟很大，进而发现这个问题比较严重，于是在运维部门较高的例行会议上立项。
无论哪种，在内部技术类的周期例会上，或运维管理层会议上，都会分析这些情况，大致评估对业务的影响程度和主要解决这个问题的技术类型，决定立项和负责人、大致的项目目标和起止时间。
项目工作如何流转?
假设这个问题是在网络组内部会议讨论要立项的，那么项目就在网络组内部自行组织人员解决。后续处理过程中，如果发现需要涉及线上业务的正常运行，可能需要机房组和系统组人员协助。甚至问题根源可能就在系统组负责的某个服务器上，那么项目会升级到较大团队级别。
但升级就升级，一般习惯是不会变更之前既定的项目负责人的，除非特殊，否则不会临阵换将。
过程中管理层可以多出些力来协助项目负责人，尤其是负责人的直接主管领导。我想这对培养团队人员个人技术综合素质和提升整个团队的协作能力是非常有益的。
如何落实运维工作?
既然运维工作分为日常运维和项目运维，就可以分别来落实了。基本原则是思想上要认识清楚每项工作的意义，制度上要落实到位。落实到位最好的办法就是将思想和制度技术化。
“技术化”通俗的讲就是通过各种软件系统来管理运维工作。打个很形象的比喻：
我们日常开车，要对安全有很高的认识(思想层面上)，当然还需要制定交通法规(制度上)来指导我们开车，路上也会设置各种行车线。
比如实线和虚线，路中间的实线就是不能碾压和跨越的，高速上的实线处还设立了很高和厚实的水泥防护栏，这个水泥防护栏就是思想和制度技术化的极端体现。实线拦不住不守规矩的车，但是水泥防护栏能!
所以思想需要形成文档来固化，当文档最好要通过技术化的实体软件系统来固化以协助我们更正确的工作。
有了体现思想的制度和软件系统，最关键的是：要用，天天用。还有，不是所有的文化思想都能固化的，还要培训和沟通，这些无形的和有形的都需要讲，换着方法的讲，日日讲。
当然思想文化、文档制度、系统软件不是一天能完善的，也不是完善了就能高枕无忧的，需要集众人智慧，与时俱进，不停的进化下去。因为开放、向上、探索本身应该是一个良好运维团队的文化核心之一。
如何做好日常运维?
对于日常运维，这类事情是运维的主体工作，虽然琐碎、技术含量一般不高，但是非常影响客户(外部用户和公司同事)的用户体验，影响运维团队提供的服务质量。ITIL中的事件管理系统可帮助我们管理日常运维工作。
我们就基于ITIL的IT服务管理思想，结合自身业务情况，公司自己开发了一套事件管理系统。个人认为这套系统最有意义的地方有两处：
1.使各个团队或者部门的服务接口化了。
用户可以根据自己选择的事情类别由系统分配给最适合的团队来处理。原理是各个团队将自己的工作职责提前进行了菜单化，用户根据自己的需求“点菜”即可。
比如上海办公室的用户outlook有问题了，就可以在事件管理系统中输入outlook，找到outlook相关的服务项，选中提交即可，系统会根据用户账户里面的属性分配给上海的IT桌面支持团队处理。
系统也有分配错误的时候，被分配者可以重新替用户转给认为正确的团队处理……我甚至认为应该将这个系统推送给公司所有部门使用，而不是仅仅局限于技术中心。
2.服务质量的把控技术化了。
用户的问题根据重要情况是分级别的，不同的级别有不同的初始响应时间，响应不及时以及后续处理不及时会升级。
不是原本不重要的事情变成重要，而是无论哪种事情，响应不及时都会逐级报给事件处理人的领导，甚至领导的领导。
当然，还有相关的统计报表，来统计个人和团队的事件处理数量和质量。所以无论是个人还是团体部门，都像有一根鞭子在背后飞舞。
如何做好项目运维?
对于项目运维，这类事情一般涉及比较广泛和深远，更是重中之重了。项目运维类的事情在实际中我一般用来监控比较长期的事情，比如部署某某系统，或者作为问题管理。
基本上是运维部门内部的事情，或者是已经转化为内部的事情了。因为用户少，只面向运维部门，所以我们直接拿开源的Redmine 作为管理软件。
Redmine很灵活，需要先理解它是基于任务(issue)的，至于具体怎么用，就需要结合标签来做，具体就不细谈了，感兴趣的各位可以慢慢摸索。
通过这个软件系统，可以弥补事件管理系统的不足。那么事件管理哪里不足呢?
最主要的不足是事件管理最(只)适合对单个零散的、短平快的事情管理。而项目类的事情需要拆分成N个子任务，任务之间也有前后依赖关系等等。另外项目类的运维周期有时候还很长。
这么长的时间没有处理完，要是在事件管理系统中记录，那你的KPI就完蛋了。-_-|||
通过项目管理软件我们实现了扁平化的管理，可以查看到所有正在进行的任务情况，可以细致到下面的一个个子任务。这样向领导汇报的时候不至于抓瞎，和团队成员沟通也便于就事论事。
一般情况，子任务都是项目负责人和任务被指派者相互沟通协商确定的，最终干活的人有很大的自主权。
最佳实践
在不影响上级任务目标的情况下，给予子任务实施人较大的自主权，比如自己定制细节的任务目标，有助于调动当事人的主观积极性，因为他在完成自己的目标。
运维都用数据说话
因为运维工作被分成了日常运维和项目运维，并分别有事件管理系统和项目管理系统来监管，有了很好的运维管理平台，现在基本上可以说整个运维团队的工作大体上都实现了数据化了。
同时作为一般运维人员来讲，这二者也是一个非常好的知识和沟通平台，工作的好与不好不是领导说了算，是自己平常在日常运维和项目运维中的表现说了算。这样作为运维管理人员来讲同样就有了管理的利器，团队的表现也是用数据说话。
写在最后的话
以上看法和做法都是我个人的一家之言，纯粹为了交流，每个人都有自己的管理心得，个人觉得只要符合自身企业的实际情况，运行起来圆融无碍，就是很好的方式方法了。
好的方式方法里总是有普世的智慧之光，希望能为大家提供一些借鉴的价值。
【编辑推荐】
1.IT运维管理，您了解多少？
2.运维工作经验总结：逃离系统故障的十个心得
3.运维管理者须知：企业IT设备如何防范雨季？
4.总结这几年运维工作中犯的错
5.孙娜：将运维工作进行到底
项目运维管理办法 一、目的 为了更好的服务与客户，加强对公司运维项目的统一管理，对项目维护活动、维护过程等相关事宜进行规范，特制定本管理办法。 二、适用范围 公司所有运行维护项目组及相关干系人。 三、职责 1、销售部：负责对服务合同进行管理，包括合同签订、合同范围及合同条款的管理； 2、技术部：负责对项目的实施、管理、监控等，负责调查客户满意度、向相关人员反馈问题、跟进问题处理情况； 3、商务：负责硬件采购及相关备件的管理。 四、运维服务对象与类型 1、运维服务对象 运维服务对象是运维服务的主体，按客户要求所提供的运维服务相关的信息技术资产。运维服务对象包括应用系统、软件平台、硬件平台、数据。 1）、应用系统； 指由相关信息技术基础实施组成的，完成用户特定业务功能的系统。 2）、软件平台： 指安装运行在计算机硬件中，构成应用系统的软件程序，如系统软件、支持性软件、应用软件等。软件平台包括：数据库软件、操作系统、系统运行平台。 3）、硬件系统： 硬件系统是指构成应用系统的硬件关联设备。
4）、数据：指应用系统支持业务运行过程中产生的数据和信息。 2、运维服务类型 根据合同的要求及相关工作目标、工作内容、交付结果将运维服务方式分为完善性维护、适应性维护和预防性维护三大类。 1）、完善性维护 针对平台业务系统原有的功能进行扩充性完善，使系统对新业务具有包容性支持，以满足客户需求，确保系统现有功能的最大发挥。 2）、适应性维护 当客户业务需求发生变化是，且供需双方对系统业务更改事宜协调确认后，运维项目组对软件系统进行业务调整，以适应用户生产的管理需要。 3)、预防性维护 定期丢业务系统进行例行巡检，挖掘并消除系统中各种影响系统高效运行的隐患，同时优化系统各方面性能，使系统高质量的运行。 五、项目维护过程 1、服务协调升级管理机制 1）、首问责任制 公司实现首问责任制，受理客户问题反馈的第一任，为首位责任人；首问责任人须将问题清晰纪录，并将问题转达至问题所属项目经理或该项目负责人。 2）、管理升级 a、系统运维实施项目经理负责制； b、当问题处理超出合同范围，项目尽力应当将问题反馈至上级或销售部，由销售部人员进行协调； c、当客户反馈的问题属于合同范围内，但超出项目经理范围时，项目经理应当第一时间反应给上级总监，由上级总监协调；
某公司运维服务规范 第一章总则 第一条为保障公司运维工作有序开展,规范运维工作和人员的服务要求,避免人为操作不当引起的重大、关健运维事故，根据电信公司及公司维护管理办法要求，特制定本规范。 第二条本规范是公司运行维护管理的基本依据，维护岗位人员必须严格遵照执行。 第三条本规定的最终解释权在技术质量管理部。 第二章适用范围 第四条本规定所指的系统是指公司及各部门承接的运维项目中涉及的范围，按合同约定包括：网络设备、服务器、操作系统、应用系统、数据及保障项目正常运行的各项辅助设施。 第五条本规定适用于对各部门运维分管领导、运维管理员、运维项目经理及成员等各维护岗位人员（包括各部门外包员工）的运维管理要求。 第三章运维服务要求 第六条运维岗位人员要具备良好的工作作风和严谨的工作态度，服从管理，认真负责，坚守岗位，在问题面前不推诿、不拖拉、不盲目、不蛮干，要冷静分析、沉着处理。 第七条遵照公司各项运维管理制度及客户运维工作要求，严格执行维护工作服务规范，确保人员、系统及各项设施安全。具体要求
包括： （一）、基本维护要求 1、遵守客户业务管理和现场管理要求。 2、周期性的维护工作应经客户审批同意后方可实施。 3、因故障修复、功能升级等引起的系统版本升级和割接工作应经客户测试通过后方可实施。 4、未经客户同意，各维护岗位人员不得私自对客户的在线系统进行数据变更、数据统计、应用程序变更、系统参数调整、硬件设备调整。 5、维护外包人员须经业务和管理培训，明确岗位职责，通过部门考核确认后方可上岗。在客户现场以理想公司员工身份执行维护工作，遵循各项运维管理制度。 6、定期检查所维护系统的安全状况，为客户提出合理的预防处理措施。 （二）、故障响应/处理制度 1、遵照公司（故障控制管理办法）要求，在接到故障报修通知后，及时与用户取得联系后进行排障，故障排除后填写故障修复信息。 2、各维护岗位人员应确保通讯工作24小时畅通。 3、严格执行故障处理和处理逐级上报制度。 （三）、信息记录（维护资料管理） 1、建立健全系统维护文档和记录资料库，相关资料由各部门妥
项目运维管理办法一、目的 为了更好的服务与客户，加强对公司运维项目的统一管理，对项目维护活动、维护过程等相关事宜进行规范，特制定本管理办法。 二、适用范围公司所有运行维护项目组及相关干系人。 三、职责 1、销售部：负责对服务合同进行管理，包括合同签订、合同范围及合同条款的管理； 2、技术部：负责对项目的实施、管理、监控等，负责调查客户满意度、向相关人员反馈问题、跟进问题处理情况； 3、商务：负责硬件采购及相关备件的管理。 四、运维服务对象与类型 1、运维服务对象运维服务对象是运维服务的主体，按客户要求所提供的运维服务相关的信息技术资产。运维服务对象包括应用系统、软件平台、硬件平台、数据。 1）、应用系统；指由相关信息技术基础实施组成的，完成用户特定业务功能的系统。 2）、软件平台：指安装运行在计算机硬件中，构成应用系统的软件程序，如系统软件、支持性 软件、应用软件等。软件平台包括：数据库软件、操作系统、系统运行平台3）、硬件系统：
硬件系统是指构成应用系统的硬件关联设备。 4）、数据：指应用系统支持业务运行过程中产生的数据和信息。 2、运维服务类型根据合同的要求及相关工作目标、工作内容、交付结果将运维服务方式分为完善性维护、适应性维护和预防性维护三大类。 1）、完善性维护针对平台业务系统原有的功能进行扩充性完善，使系统对新业务具有包容性支持，以满足客户需求，确保系统现有功能的最大发挥。 2）、适应性维护当客户业务需求发生变化是，且供需双方对系统业务更改事宜协调确认后，运维项目组对软件系统进行业务调整，以适应用户生产的管理需要。 3）、预防性维护定期丢业务系统进行例行巡检，挖掘并消除系统中各种影响系统高效运行的隐患，同时优化系统各方面性能，使系统高质量的运行。 五、项目维护过程 1、服务协调升级管理机制 1）、首问责任制 公司实现首问责任制，受理客户问题反馈的第一任，为首位责任人；首问责任人须将问题清晰纪录，并将问题转达至问题所属项目经理或该项目负责人。 2）、管理升级 a、系统运维实施项目经理负责制； b、当问题处理超出合同范围，项目尽力应当将问题反馈至上级或销售 由销部，售部人员进行协调；
运维管理制度 XXXXXX有限公司2014年5月18日
目录 引言 (1) 1、总则 (2) 2、编制方法 (2) 3、运维部工作职责 (2) 3.1系统运维和技术支持 (2) 3.2.平台信息和技术安全 (3) 4、运维服务管理体系 (4) 4.1运维服务管理对象 (4) 4.2运维系统功能框架 (4) 4.3运维管理组织结构 (5) 4.3.1项目负责人 (5) 4.3.2项目经理 (5) 4.3.3技术主管 (6) 4.3.4服务台 (6) 4.3.5网络管理员 (7) 4.3.5应用、数据库管理员 (7) 4.3.7终端管理员 (7) 4.4运维服务流程 (8) 4.4.1项目运维服务工作流程图 (9) 4.4.2服务台 (9) 4.4.3事件管理 (10) 4.4.4工单管理 (10) 4.4.5问题管理 (10) 4.4.6变更管理 (10) 4.4.7配置管理 (11) 4.4.8知识库管理 (11) 4.4.9统计及工作报告 (11) 5、运维服务内容 (11) 5.1服务目标 (11) 5.2IT资产统计服务 (12) 5.3网络、安全系统运维服务 (12) 5.4主机、存储系统运维服务 (13) 5.5数据库系统运维服务 (13) 5.6中间件运维服务 (14) 5.7终端、外设运维服务 (14) 6、应急服务响应措施 (14) 6.1应急预案实施基本流程 (15) 6.2突发事件应急策略 (15) 7、服务管理制度规范 (16) 7.1服务时间 (16) 7.2行为规范 (16)
001-2 办公信息系统协同管理及协同数据交换策略研究运维制度引言 本文件是依据《XXXXXX系统协同管理及数据交换策略研究》分任务要求，完成“运维制度”的研究工作。 课题组参照国际国内标准有： ITIL/ISO20000标准 GBT 28827.1-2012 信息技术服务运行维护第1部分：通用要求 GBT 28827.2-2012 信息技术服务运行维护第2部分：交付规范 GBT 28827.3-2012 信息技术服务运行维护第3部分：应急响应规范 结合XXX课题应用实施及运维管理的实际情况研究、编制运行维护管理制度，本文分为7章内容分别为： 1.总则 2.编制方法 3.运维部工作职责 4.运维服务管理体系 5.运维服务内容 6.应急服务响应措施 7.服务管理制度规范等内容。
运维技术研发管理规范 Company number：【WTUT-WT88Y-W8BBGB-BWYTT-19998】
目录
技术研发管理规范 第一章总则 第一条为规范运维技术和工具的预研和开发管理，有效提升公司运维服务能力，不断改进服务过程，为客户提供稳定、安全、高效运行的运维产品和工具，特制定本规范。 第二条本规范适用于在研发中心立项自研的运维系统项目和运维产品的设计和开发管理。第三方的运维系统项目和运维产品的集成技术管理，由事业部负责。 第三条本规范由研发中心负责解释和修订。 第二章技术研发经费管理 第四条技术研发经费管理原则 技术研发实行重视研发成本、促进研发进度、关注研发效益的经费管理原则，由集团财务部统一归口管理。 第五条技术研发经费管理职责 集团财务部负责建立研发经费管理制度，根据研发计划和费用预算，提前准备资金确保研发资金需求，同时有效监督研发经费的合理使用。研发中心负责按照研发计划制定并执行各项开发项目的研发预算，有效利用研发经费。 第六条技术研发预算管理 为规范集团的经营预算管理流程，提高预算管理的科学性，保证集团经营目标的实现，根据《公司法》等国家相关法律法规，结合《公司章程》，公司财务部制定了《经营预算管理制度》。 研发体系作为集团预算单位之一，对技术研发预算目标的实现承担经济责任，并享有相应的资源使用权，通过预算编制管理、预算执行管理和预算调整管理三个方面实施预算管理，其主要内容包括：编制和上报研发的经营预算草案，提供预算编制的各项基
础资料；严格执行下达的正式经营预算方案，在预算范围内开展经营活动；分解和落实研发预算指标，监督和保证研发预算得到执行；分析和报告研发预算执行情况；当发生特定情形时，提出经营预算调整申请；配合财务部做好各项预算管理工作；研发负责人对研发预算执行结果负责。 第七条技术研发核算管理 集团财务部为承担研发任务的研发中心设立台账归集核算研发费用，研发中心发生的各项开支均纳入研发费用管理。集团财务部协助研发中心做研发投入费用的预算编制和控制，对研发费用的入账方式进行规定，研发阶段的支出全部费用化，计入当期管理费，开发阶段的支出符合资本化条件的，按照财政部有关规定，确认无形资产；研发费用的纳税扣除，按照财政部、国家税务总局有关规定执行。集团每年在当年年度财务会计报告中，按照规定披露研发费用相关财务信息，包括研发费用支持规模及其占销售收入的比例，集中收付研发费用情况等。 第八条技术研发成本控制 技术研发成本主要包括研发物料成本、人力工资成本、差旅费用等，其中研发物料成本估算在技术研发项目任务书中体现，集团财务对项目成本进行控制、统计，同时，研发中心内部制定了《研发物料管理规定》和《关键物料导入管理规定》等规定，对研发物料成本实施监督管理；人力工资成本是技术研发成本的主要构成部分，即研发项目成本主要来源于项目实际工作量，通过项目管理对研发项目投入人工实施成本管理；差旅费用及其他费用按照集团财务部《借款和日常费用报销制度》和《研发中心费用管理制度》相关条款对费用执行进行监督和管理。 第三章技术研发环境管理
XXXX设备运维管理规范 （讨论稿） 1目的 1.1为规范XXXX各区域设备管理运维方面的行为，实现设备维护标准化、降低故障率；提升设备维护人员、使用人员的安全意识、行为标准化意识，集团XX 部制定此规范。 2适用范围 2.1XX集团XX各区域所属的设备管理部门； 2.2XX集团XX各区域所属的物流设备，如叉车、输送机及自动化仓储设施等。3岗位设置 3.1XX集团XX各区域应设立设备管理部，设置设备经理岗，设备保全岗（电气、机械、安全工程师）等职能，可兼任； 3.2XX集团XX各区域应当根据建仓量配置若干设备保全人员建立保全组。 图一：设备部门组织架构图 4岗位职责 4.1各区域设备部门各岗位职责至少包含以下内容； 4.2设备经理 4.2.1负责区域设备管理工作； 4.2.2完善制度建设，推进TPM体系建设； 4.2.3制定设备条线人员考核及培训计划和实施； 4.2.4编制年度设备维保计划（包含外协、备件资金预算）； 4.2.5维修档案管理； 4.2.6组织设备服务商的年度评价； 4.2.7积极参与设备选型、验收、移交、厂家培训工作； 4.2.8接受集团设备管理部门的专业指导，对区域负责人负责。 4.3电气工程师 4.3.1负责设备电气方面的工作； 4.3.2编制电气维护方案； 4.3.3制定设备点检方案； 4.3.4解决设备故障，审核维修记录； 4.3.5编制电气备件采购需求； 4.3.6对区域设备经理负责。 4.4机械工程师 4.4.1负责设备机械方面的工作； 4.4.2编制机械传动部分维保方案； 4.4.3制定设备点检方案； 4.4.4解决设备故障，审核维修记录； 4.4.5制定机械备件采购计划； 4.4.6对区域设备经理负责。
1.项目概况及建设要求(运维) 2.1项目背景 随着国民经济的迅猛发展，用电需求的激增，电网规模也处于高速发展期。以宁波电业局为例在十一五期间就实现了电网规模翻番，这就导致了电力企业人力资源极度紧张的局面出现。在电力专业生产人员不能与电网规模同步成比例增长的前提下，提高电力系统自动化、智能化水平，优化工作模式和工作流程等工作是就成为目前摆在电网企业面前的头等大事。 依据国网公司2012年精神大力推进三集五大体系建设，遵循电力发展客观规律，围绕“一强三优”现代公司战略目标，按照集约化、扁平化、专业化方向，变革组织机构，创新管理模式，优化业务流程，深化人财物集约化管理。变电运行体制已构建大检修运维一体化管理体系。 电网的主要支撑点—各种电压等级的变电站，其机房内安置着很多屏柜，每个屏柜内安装着继保设备、自动化设备、信息设备、通信设备、电源设备等，各类设备各司其职，保障着电网的安全可靠运行。各类专业屏柜由变电运行部门统一管理，并由相应的专业人员运行维护。变电站设备的日常工作涉及:
1)运行维护。各专业设备主人签发工作票，变电运行人员到现场 做好工作屏柜及相邻屏柜的安全措措后，办理工作票的许可手续后，再由专业人员开展运维作业。工作完成后运行人员与专业人员再共同办理工作结束手续。 2)资源记录。以往每次运维工作结束后，需要由工作人员返回后 登录到资源管理系统对资源数据进行更新，一方面增加了工作人员的工作量，另一方面由于不是当场做记录，难免会出现漏记误记现象，造成资源库数据准确性下降和更新不及时，同时也对运维工作和新项目设计造成一定困难。 3)屏柜外形接近，外部没有明显标识，特别是同一专业的屏柜， 工作中容易搞错间隔，甚至造成重大事故。 4)某些不涉及对屏柜装置的工作，如：仅仅是查勘，检查等方面 的工作。一般经运维站值班人员电话同意后，专业人员自行进入保护室。但没有有效可靠的技术措施，能控制专业人员对屏柜装置的操作。存在着不安全隐患。 5)随着电网新技术新设备的大量应用，厂方技术人员广泛参与现 场设备技术支撑的服务已形成了常态化。但厂方技术人员没受过正规系统的安全培训教育，安全规范意识差。在变电站工作现场不能有效受控，时有出现不安全行为的情况，存在着重大
1总则 为了加强对公司运维项目的统一管理，对项目维护活动、维护过程等相关事宜进行规范，特制定本管理办法。 2适用范围 公司所有运行维护项目组及相关干系人。 3职责 3.1市场营销部：负责对运维合同进行管理，包括合同签订、合同范围及合同条款的管理； 3.2技术部：负责对维护项目的实施、管理、监控等； 3.3客服专员：负责调查客户满意度、分析与核算客户满意度、向技术部反馈客户申诉问题、 跟进问题处理情况； 3.4采购部：负责硬件采购及备品备件的管理； 3.5财务部：负责运维过程中的各项费用审计。 4运维服务对象与类型 运维服务对象 运维服务对象是运维服务的受体，是按用户要求所提供的运维服务相关的信息技术资产。运 维服务对象包括应用系统、软件平台、硬件平台、数据。 应用系统： 指由相关信息技术基础设施组成的，完成用户特定业务功能的系统。 软件平台： 指安装运行在计算机硬件中，构成应用系统的软件程序，如系统软件、支持性软件、应用软件等。软件平台包括：数据库软件、操作系统、系统运行平台（如科威系列平台）。 硬件系统： 硬件系统是指构成应用系统的硬件关联设备。 数据： 指应用系统支持业务运行过程中产生的数据和信息。
运维服务类型 根据技术协议的要求及其工作目标、工作内容、交付结果将运维服务方式分为完善性维护、适应性维护和预防性维护三大类。 完善性维护 针对科威平台业务系统原有功能进行扩充性完善，使系统对新业务具有包容性支持，以满足用户需求，确保系统现有功能的最大发挥。 服务触发方式：响应用户反馈。 适应性维护 当用户业务需求发生变更时，且供需双方对系统业务更改事宜协调确认后，运维项目组对软件系统进行业务调整，以适应用户生产和管理需要。 服务触发方式：响应用户反馈。 预防性维护 定期对业务系统进行例常巡检，挖掘并消除系统中各种影响系统高效运行的隐患，同时优化系统各方面性能，使系统高质量运行。 服务触发方式：基于系统稳定的主动式服务。 5项目维护过程 5.1服务协调升级管理机制 5.1.1首问责任制 公司实行首问责任制，受理客户问题反馈的第一人，为首问责任人；首问责任人须将问题清晰记录,并将问题转达至问题所属项目经理或该项目所属的事业部经 理，转达后视结束首问责任。 5.1.2管理升级 ?系统运维实行项目经理负责制； ?当问题处理超出合同范围，项目经理应当将问题反馈至市场营销部，由业务人员进行协调； ?当客户反馈问题属合同范围内，但超出项目经理能力范围时，项目经理应当第一时间与事业部经理汇报，由事业部经理协调； ?当合同范围内问题需要进行跨部门协调时，事业部经理应当将问题反馈至技术副总进行协调。
运维项目管理制度 一、目的 为规范公司运维项目的管理维护，加强对公司运维项目的统一管理，为了更好的服务与客户，结合本公司实际情况，对项目维护活动、维护过程等相关事宜进行规范，特制定本管理制度。 二、适用范围 公司所有运行维护项目组及相关干系人。 三、职责 1、市场部：负责对服务合同进行管理，包括合同签订、合同范围及合同条款的管理； 2、商务组：负责硬件采购及相关备件的管理。 3、技术部：负责对项目的实施、管理、监控等，负责调查客户满意度、向相关人员反馈问题、跟进问题处理情况； 四、运维服务对象与类型 1、运维服务对象 运维服务对象是运维服务的主体，按客户要求所提供的运维服务相关的信息技术资产。运维服务对象包括应用系统、软件平台、硬件平台、数据。 1）、应用系统； 指由相关信息技术基础实施组成的，完成用户特定业务功能的系统。 2）、软件平台： 指安装运行在计算机硬件中，构成应用系统的软件程序，如系统软件、支持性软件、应用软件等。软件平台包括：数据库软件、操作系统、系统运行平台。 3）、硬件系统：
硬件系统是指构成应用系统的硬件关联设备。 4）、数据：指应用系统支持业务运行过程中产生的数据和信息。 2、运维服务类型 根据合同的要求及相关工作目标、工作内容、交付结果将运维服务方式分为完善性维护、适应性维护和预防性维护三大类。 1）、完善性维护 针对平台业务系统原有的功能进行扩充性完善，使系统对新业务具有包容性支持，以满足客户需求，确保系统现有功能的最大发挥。 2）、适应性维护 当客户业务需求发生变化是，且供需双方对系统业务更改事宜协调确认后，运维项目组对软件系统进行业务调整，以适应用户生产的管理需要。 3)、预防性维护 定期丢业务系统进行例行巡检，挖掘并消除系统中各种影响系统高效运行的隐患，同时优化系统各方面性能，使系统高质量的运行。 五、项目维护过程 1、服务协调升级管理机制 1）、首问责任制 公司实现首问责任制，受理客户问题反馈的第一任，为首位责任人；首问责任人须将问题清晰纪录，并将问题转达至问题所属项目经理或该项目负责人。 2）、管理升级 a、系统运维实施项目经理负责制； b、当问题处理超出合同范围，项目尽力应当将问题反馈至上级或销售部，由销售部人员进行协调； c、当客户反馈的问题属于合同范围内，但超出项目经理范围时，项目经理
运维管理制度XXXXXX有限公司2014年5月18日
目录
引言 本文件是依据《XXXXXX系统协同管理及数据交换策略研究》分任务要求，完成“运维制度”的研究工作。 课题组参照国际国内标准有： ITIL/ISO20000标准 信息技术服务运行维护第1部分：通用要求 信息技术服务运行维护第2部分：交付规范 信息技术服务运行维护第3部分：应急响应规范 结合XXX课题应用实施及运维管理的实际情况研究、编制运行维护管理制度，本文分为7章内容分别为： 1.总则 2.编制方法 3.运维部工作职责 4.运维服务管理体系 5.运维服务内容 6.应急服务响应措施 7.服务管理制度规范等内容。 1、总则 第一条为保障XXXX课题信息系统软硬件设备的良好运行，使参与课题技术人员运维工作制度化、流程化、规范化，特制订本制度。 第二条运维管理工作总体目标：立足根本促发展，开拓运维新局面。在办公系统运行推广时期，通过网络、桌面、系统等的运维，促进XXXX课题能够稳定可持续性发展。 第三条运维管理制度的适用范围：本项目运维全体人员。
2、编制方法 本实施细则包括运维服务全生命周期管理方法、管理标准/规范、管理模式、管理支撑工具、管理对象以及基于流程的管理方法。 本实施细则以ITIL/ISO20000为基础，以信息化项目的运维为目标，以管理支撑工具为手段，以流程化、规范化、标准化管理为方法，以全生命周期的PDCA 循环为提升途径，体现了对运维服务全过程的体系化管理。 3、运维部工作职责 系统运维和技术支持 （1）根据示范工程实施推进和发展目标，负责系统信息协同管理及协同数据交换策略研究的整体架构、应用系统等技术开发方案制定和组织开发，保障基础研发平台的稳定性和先进性。 （2）负责系统基础研发平台的使用培训和操作使用指南编写，对用户使用过程中出现问题的沟通和解决； （3）会同项目实施单位，确认系统信息基础研发设备和软件数量、品牌规格、技术参数，确保课题有效推进实施。 （4）系统信息基础研发设备和软件操作规程和应用管理制度的制定，并负责监督执行。 （5）系统信息基础研发中心设备和软件安装、调试和验收，使用培训和维修保养。 （6）系统信息基础研发平台日常运行过程中信息安全和技术问题的协调解决，保障网站24小时安全稳定运行。 （7）负责研发平台系统管理及设备保密口令的设置和保存，保密口令设置后报课题领导小组备案，保密口令设定后任何人不得随意更改，保密口令每季度更新一次。 （8）负责系统信息协同管理及协同数据交换策略研究新程序、新系统和软件改版升级工作。
附件一运维人员管理规 1.管理目的 项目实施完成后,完善外包人员的规化作业.保证系统正常生产. 2.运维人员要求 乙方在完成项目终验后,直接转到项目维护, 乙方指定的工程师由甲方直接管理.乙方运维人员必须遵守甲方的考勤制度、外形象制度，该岗位工作人员无论是本公司职员或外包商职员，一律以我公司员工对外。 2.1 运维人员资源要求. 乙方必须给运维人员配备电脑及上网环境及居住环境(要求到达现场，不超过5分钟路程). 必需配备可移动热线,24小时保持开机,处于能接通状态. 2.2 人员技术要求. 按附件五中人员的要求,该名运维人员必须参与过该项目的实施,有从业经验一年以上. 2.3 运维人员考勤要求 要求早8:30到现场，晚5:30离开.得到最终用户同意，可以享受国家法定假日. 2.4 运维人员的考核 每一个季度,甲方会针对运维人员的巡检情况,故障解决能力,项目的稳定性等综合情况打分,纳入到考核,按考核分值付款. 3.项目运维双方接口 甲方管理接口人: 许胜凯 (甲方一卡通小组组长), : ，：https://www.doczj.com/doc/b011997639.html, 甲方客服专员 :
媛媛（服务00）：https://www.doczj.com/doc/b011997639.html, 乙方运维工程师:吕青青，: ：wwy9555163. 乙方项目负责人:牟骏宇，：：284735006qq. 乙方投诉：职位：经理 (因关系到付款，要求经理以上) 4. 客户关系处理要求 1.直接客户关系维护 保持良好的工作形象和积极的工作态度，配合直接客户的业务推广，让直接客户零投诉。 2.终端客户关系维护 保持良好的工作形象和积极的工作态度，做好维护巡检及故障及时处理，让终端客户零投诉。 3.潜在客户关系维护 保持良好的工作形象和积极的工作态度，合理详细的解说一卡通相关业务，让潜在客户有良好的印象。 5.工作容 主动巡检要求: 1. 乙方运维工程师每天20:00前提交项目日报到甲方管理接口人，抄送给甲方客户专员. 2. 乙方运维工程师每周五20:00前提交项目周报到甲方管理接口人，抄送给甲方客户专员. 3．乙方运维工程师每季度最后一天20:00前提交项目季度总结报告到甲方管理接口人，抄送给甲方客户专员. ４．主动巡检容及表格，详见本规附件。 故障处理： 维护工程师接到故障任务，要求在10分钟响应，并处理故障（或现场），按最终用户的要求时间解决故障，并提交case报告。
Confidential 拓维信息系统股份有限公司项目运维交接管理指导规范 Written By TALKWEB Talkweb 拓维信息系统股份有限公司?1996，2011 All Rights Reserved
目录 1. 文档说明..................................................错误!未定义书签。 . 文档目标............................................错误!未定义书签。 . 适用范围............................................错误!未定义书签。 . 术语................................................错误!未定义书签。 2. 一般规则..................................................错误!未定义书签。 . 交维通用流程........................................错误!未定义书签。 . 交维启动应具备的条件................................错误!未定义书签。 . 交维资料的查验......................................错误!未定义书签。 . 交维系统的查验......................................错误!未定义书签。 . 软／硬件交维........................................错误!未定义书签。 . 人员招聘及管理......................................错误!未定义书签。 . 代码管理............................................错误!未定义书签。 3. 运维范围及要求............................................错误!未定义书签。 . 设备管理............................................错误!未定义书签。 . 应用管理............................................错误!未定义书签。 . 业务管理............................................错误!未定义书签。 . 桌面管理............................................错误!未定义书签。 . 其它日常任务........................................错误!未定义书签。 4. 日常运维作业计划..........................................错误!未定义书签。 . 故障检查............................................错误!未定义书签。 . 能力检查............................................错误!未定义书签。 . 可用性检查..........................................错误!未定义书签。 . 业务数据检查........................................错误!未定义书签。 . 安全检查............................................错误!未定义书签。 . 配置检查............................................错误!未定义书签。 5. 资源配置..................................................错误!未定义书签。 . 一线运维角色........................................错误!未定义书签。 . 人员配置............................................错误!未定义书签。 . 设备及办公环境配置..................................错误!未定义书签。 . 非驻地运维..........................................错误!未定义书签。 6. 能力交接..................................................错误!未定义书签。 . 培训计划............................................错误!未定义书签。 . 能力考核计划........................................错误!未定义书签。 7. 运维相关技术与工具........................................错误!未定义书签。 . 自助服务............................................错误!未定义书签。 . 监控工具............................................错误!未定义书签。 . 诊断工具............................................错误!未定义书签。 . 远程控制工具........................................错误!未定义书签。 . 流程控制工具........................................错误!未定义书签。 . 知识管理工具........................................错误!未定义书签。 . 业务管理集成工具....................................错误!未定义书签。 8. 运维制度..................................................错误!未定义书签。 . 运维工作时间安排....................................错误!未定义书签。
运维部门管理规范 v1.0.201403 一、组织结构 运维部门组织结构图 组织结构说明： ?运维部门，下设三个室：数据库管理室、硬件管理室、应用系统管理室； ?原技术支持部下维护组成员，根据实际职责分工以及技能特点，分别转入到数据库管理室、硬件管理室及数据库管理室中，详见“附：运维中心编制人员规划”。 二、部门和主要岗位职责 2.1.部门职责 1)根据项目需要，整理项目硬件配置，进行询价； 2)新平台的网络架构设计、硬件配置、系统施工； 3)公司各平台系统、数据库日常维护； 4)负责保障全公司所有平台的系统、数据库、网络稳定安全运行； 5)协助业务单位实施平台的重大升级/割接；
6)各平台信息安全扫描，系统漏洞修复； 7)技术支持质量检测； 8)协助宽连学院实施技术支持技能提升培训； 2.2.主要岗位职责 ●系统部高级经理 1)负责部门战略规划和目标实现，制定并完善部门管理制度； 2)对公司所有平台的系统、数据库支撑工作总负责，保障所有平台的系统、数据库、网 络稳定安全运行； 3)对业务单位平台的重大升级/割接提供技术指导； 4)牵头公司系统、数据库技术难题攻关工作。 ●系统部系统组技术经理 1)负责公司所有平台的系统、网络支撑工作，保障所有平台的系统、网络稳定安全运行； 2)牵头或直接解决公司平台的系统、网络方面的问题； 3)协助业务单位实施平台上系统、网络方面的重大升级/割接； 4)负责对组内人员进行技术指导； 5)协助技术管理部对公司所有平台定期进行信息安全质量检查。 ●系统部数据库组技术经理 1)负责公司所有平台的数据库支撑工作，保障所有平台的数据库稳定安全运行； 2)牵头或直接解决公司平台的数据库方面的问题； 3)协助业务单位实施平台上数据库方面的重大升级/割接； 4)负责对组内人员进行技术指导。 ●系统工程师 1)公司各平台系统日常维护； 2)项目硬件施工； 3)协助各平台实施系统方面的重大升级/割接； ●网络工程师 1)公司各平台网络日常维护； 2)项目硬件施工； 3)协助各平台实施网络方面的重大升级/割接；
运行维护管理制度 2017年8月 目录 1、总则 (3) 2、编制方法 (3) 3、运维工作职责 (3) 4、运维服务管理体系 (5) 4.1运维服务管理对象 (6) 4.2运维系统功能框架 (6) 4.3运维管理组织结构 (7) 4.3.1项目负责人 (8) 4.3.2项目经理 (8) 4.3.3技术主管 (9) 4.3.4服务台 (9) 4.3.5网络管理员 (10) 4.3.5应用、数据库管理员 (10) 4.3.7终端管理员 (11) 4.4运维服务流程 (11) 4.4.1项目运维服务工作流程图 (12) 4.4.2服务台........................................... ...................................................... 4.4.4工单管理......................................... 4.4.5问题管理.........................................
4.4.6变更管理......................................... 4.4.7配置管理......................................... 4.4.8知识库管理....................................... 4.4.9统计及工作报告................................... 5、运维服务内容.......................................... 5.1服务目标............................................ 5.2资产统计服务 ........................................ 5.3网络、安全系统运维服务 .............................. 5.4主机、存储系统运维服务 .............................. 5.5数据库系统运维服务 .................................. 5.6中间件运维服务 ...................................... 5.7终端、外设运维服务 .................................. 6、应急服务响应措施...................................... 6.1应急预案实施基本流程 (20) 6.2突发事件应急策略 (20) 7、服务管理制度规范 (21) 7.1服务时间 (21) 7.2行为规范 (22) 1、总则 第一条为保障公司信息系统软硬件设备的良好运行，使员工的运维工作制度化、流程化、规范化，特制订本制度。 第二条运维工作总体目标：立足根本促发展，开拓运维新局面。在企业发展壮大时期，通过网络、桌面、系统等的运维，促进企业稳定可持续性
运维规范 第一章总则 1.为加强公司各个项目后期的系统运维管理，确保系统能够平稳、可靠地运行， 更好地为客户提供管理服务，特制定本规定。 2.本规定适用所有进入运维环节的项目。 3.运维人员应根据授权，处理本规定中所涉及的业务事项。 第二章主机、服务器及数据库系统的运维管理 1.根据应用需求，主机、服务器及数据库系统的配备和安装、以及系统资源的使 用等由公司项目实施部统一规划。 2.应指定专人作为系统管理员（系统工程师）和数据库管理员，对系统的运行、 管理、维护和安全负责，并按照有关规定负责系统和数据的备份与恢复。 3.系统/数据库管理员应定时对系统进行监控和定期的健康性检查，分析系统运 行和资源使用状况，并进行必要的优化、调整和修正，及时消除隐患。如系统设置发生变化，或重新安装系统，或安装了新软件，应在此后15个工作日内对系统进行密切跟踪。 4.及时解决处理系统运行过程中出现的异常问题和软硬件故障，并采取必要措施， 最大限度地保护好系统资源和数据资源。 5.对于重大软硬件系统故障，应立即通知部门领导，协调服务商，使系统尽快得 以恢复运行；对于应用系统引发的系统异常或故障，应及时通知相关人员，并协同解决处理。 6.每季度应对系统主机/服务器/数据库进行一次停运维护，其操作必须严格按照 操作规程进行。其他非正常性停运（故障引发的除外），应提出书面申请，并经部门领导批准后方可进行。同时做好相应的准备工作，最大限度地减少对业务操作带来的影响。 7.具有系统操作或管理权限的人员调离工作岗位或离职，应立即从系统中删除该 用户；如该人员掌握超级用户口令，应立即更换口令。 第三章软件系统的运维管理 1.避免在用户工作时间进行软件版本升级工作，以免由于人为失误造成业务中断。 2.软件系统的安装、升级等操作应保留完整的实施记录。 3.对软件系统进行升级、更新补丁，应首先进行相关的测试，并在确认无误后实 施。 4.对软件系统进行升级、更新补丁，或进行系统的重新安装等操作，应在实施前 对原有系统及数据进行备份。 5.变更系统配置，修改配置文件、参数文件时，应对原始配置数据（或文件）进 行保留。 6.软件进行版本升级时，对于不影响业务的升级工作，须以书面形式详细将计划、 方案、措施等报上级主管部门备案；对于影响业务的升级工作，必须提前两周向上级通信主管部门以书面形式提出申请详细报告计划、方案、措施等，经批
项目运维管理制度 篇一：运维项目规章制度 篇二：信息系统运维管理制度 信息系统运维管理制度 为了规范公司信息系统的管理维护，确保系统硬、软件稳定、安全运行，结合公司实际，制定本制度。制度包括信息机房管理、服务器管理、信息系统应用管理、信息系统变更管理、信息系统应用控制。 一、信息机房管理 1、硬件配备及巡检 1.1、各单位信息机房按规定配备防静电地板、UPS、恒温设备、温湿度感应器、消防设备、防鼠设施等相关基础设施。 1.2、各单位机房管理人员应定期（如每月或每季度）对机房硬件设备设施进行巡检，以保证其有效性。 1.3、各单位机房应建立相关的出入登记、设备机历登记、设备巡检、重大故障等记录，并认真填写。 2、出入管理
2.1、严禁非机房工作人员进入机房，特殊情 况需经信息中心批准，并认真填写登记表后方可进入。 2.2、进入机房人员应遵守机房管理制度，更换专用工作鞋。 2.3、进入机房人员不得携带任何易燃、易爆、腐蚀性、强电磁、辐射性、流体物质等对设备正常运行构成威胁的物品。 3、安全管理 3.1、操作人员随时监控中心设备运行状况，发现异常情况应立即按照应急预案规程进行操作，并及时上报和详细记录。 3.2、未经批准，不得在机房设备上随意编写、修改、更换各类软件系统及更改设备参数配置； 3.3、软件系统的维护、增删、配置的更改，必须按规定详细记入相关记录，并对各类记录和档案整理存档。 3.4、机房工作人员应恪守保密制度，不得擅自泄露信息资料与数据。 3.5、机房内严禁吸烟、喝水、吃食物、嬉戏和进行剧烈运动，保持机房安静。 3.6、严禁在机房计算机设备上做与工作无关的事情（如聊天、玩游戏），对外来存储设备（如U盘、移动硬盘等），做到先杀病毒后使用。 3.7、机房严禁乱拉接电源，应不定期对机房内设置的消防器材、烟雾报警、恒温设备进行检查，保障机房安全。
运维管理制度规范（试行）
第一章概述 运维管理制度规范（试行），是针对目前数据中心现有体制制定的一系列运维规划，其中包括运维项目实施、运维流程控制、 第二章运维实施 第一节硬件上架 1.硬件上架应严格按照机房管理室所提供的流程进行操作，填写机房管理室要求 的相关申请文档。 2.硬件上架后，要检查设备标签、网络标签、电源标签是否完整。 3.硬件上架后，要检查机柜内走线是否已整齐。 4.检查电源、网络配置能否符合和客户签定的SLA，如不符合走服务请求流程提 交相关文档。 5.机房管理室创建该项目的配置项文档，并通知服务经理进度。 6.涉及流程：机器上架申请、配置管理、服务级别管理、服务请求。 7.涉及文档：《设备上架申请》、《服务请求单》、《服务级别协议》/《服务合同》、 《配置项文档》 第二节网络配置 1.网络配置时，要求按照客户的服务合同中承诺的要求一致，如合同中没有明确 说明以领导确认为准。 2.网络配置后，录入相关的配置项信息，以及变更相关联的交换机、防火墙信息， 并通知服务经理进度。 3.网络配置后，要建立该业务系统的网络拓扑图，网络拓扑图属于该项目的一个 配置项。 4.涉及流程：配置项管理 5.涉及文档：《配置项目文档》 第三节软件实施 1.软件实施前要创建《软件实施调查表》，详细调查客户的软件环境、配置、版 本等信息。 2.软件实施要按照《软件实施调查表》进行实施。 3.软件实施后，如客户没有要求，修改所有默认密码，密码规则同《信息安全管 理制度》的口令、权限一章。 4.软件实施后，要录入相关配置项目，并适当备份介质。 5.软件实施后，要建立该业务系统的逻辑拓扑图，逻辑拓扑图属于该项目的一个 配置项。 6.涉及流程：配置项目管理 7.涉及文档：《软件实施调查表》、《配置项目文档》 第四节运维手册