运行维护管理体系和制度规范Word格式.docx
《运行维护管理体系和制度规范Word格式.docx》由会员分享，可在线阅读，更多相关《运行维护管理体系和制度规范Word格式.docx（25页珍藏版）》请在冰点文库上搜索。
5.4主机、存储系统运维服务17
5.5数据库系统运维服务18
5.6中间件运维服务19
5.7终端、外设运维服务19
6、应急服务响应措施19
6.1应急预案实施基本流程20
6.2突发事件应急策略20
7、服务管理制度规范21
7.1服务时间21
7.2行为规范22
1、总则
第一条为保障实验室系统软硬件设备的良好运行，使员工的运维工作制度化、流程化、规范化，特制订本制度。
第二条运维工作总体目标：
立足根本促发展，开拓运维新局面。
在企业发展壮大时期，通过网络、桌面、系统等的运维，促进企业稳定可持续性发展。
第三条运维管理制度的适用范围：
运维人员。
2、编制方法
本实施细则包括运维服务全生命周期管理方法、管理标准/规范、管理模式、管理支撑工具、管理对象以及基于流程的管理方法。
本实施细则以ITIL/ISO20000为基础，以信息化项目的运维为目标，以管理支撑工具为手段，以流程化、规范化、标准化管理为方法，以全生命周期的PDCA循环为提升途径，体现了对运维服务全过程的体系化管理。
3、运维部工作职责
一、负责网站运维和技术支持
（一）根据网站运营战略和目标，负责网站整体架构、栏目、应用系统等技术开发方案制定和组织开发，保障网站技术的稳定性和先进性。
（二）负责网站栏目和应用系统的使用培训和操作使用指南编写，对用户使用过程中出现问题的沟通和解决。
（三）网站设备和软件购买计划书的拟定，包括采购数量、品牌规格、技术参数。
会同行政部进行采购。
（四）网站设备和软件操作规程和应用管理制度的制定，并负责监督执行。
（五）网站设备和软件安装、调试和验收，使用培训和维修保养。
（六）网站日常运行过程中信息安全和技术问题的协调解决，保障网站24小时安全稳定运行。
（七）网站技术服务外包管理，主要包括技术外包开发、运行服务托管和空间域名管理。
（八）负责网站管理系统及设备保密口令的设置和保存，保密口令设置后报中心主任备案，保密口令设定后任何人不得随意更改，保密口令每季度更新一次。
（九）负责网站新程序、新系统和网站改版升级方案技术的设计开发。
二、负责网站信息和技术安全
（一）执行国家和省上有关网络信息技术安全的法律法规，与通信管理和网络安全监管部门联络，及时处理网站信息技术安全方面存在的问题，确保网站安全、稳定、可靠运行。
（二）网站信息技术安全保密制度和工作流程的制定，落实信息技术安全保密责任制，执行“谁主管、谁负责，谁主办、谁负责”的原则，责任到人。
（三）在服务器和计算机之间设置硬件防火墙，在服务器及工作站上均安装防病毒软件，进行硬件和技术双保护，确保网站不受病毒和黑客攻击。
（四）负责网站信息技术安全应急处理预案制定和实施。
（五）安排专人监控网站各频道，各页面，各版块，各栏目信息内容，建立网站信息技术安全监控值班登记制度，发现问题及时处理，并登记问题和处理结果登记；
（六）建立多机备份网站信息服务系统机制，一旦主系统遇到故障或受到攻击导致不能正常运行，可以在最短的时间内替换主系统提供服务。
（七）建立网站系统集中式权限管理，按照岗位职责设定工作人员操作权限，针对不同应用系统、终端、操作人员，设置共享数据库信息的访问权限，并设置密码。
不同的操作人员设定不同的用户名，且定期更换，严禁操作人员泄漏密码。
4、运维服务管理体系
运维服务管理体系规定了运维活动涉及的各类实体，以及这些实体间的相互关系。
相关的实体按照运维服务管理体系进行有机组织，并协调工作，按照服务协议要求提供不同级别的IT运维服务。
4.1运维服务管理对象
运维服务管理对象包括基础设施、应用系统、用户、研发部门以及IT运维部门和人员，具体内容如下：
（1）基础设施包括网络、主机系统、存储系统、安全系统等。
（2）应用系统包括uap云管理平台、cloud门户、demo、zabbix、机房设备管理系统、vmware以及yum源等。
（3）用户包括使用如上应用系统的用户。
（4）研发部门包括Iaas平台研发部门。
（5）运维部门和人员包括内部参与运维活动的相关部门和人员，以及提供运维服务的企业和相关人员。
4.2运维系统功能框架
根据建设单位的系统结构和业务开展需要，运维项目组将项目的维护框架分为9个具体组成部分，分别为：
服务台、事件管理、工单管理、问题管理、变更管理、配置管理、工程师考核、知识库管理、统计、系统管理等9个子项。
而具体运维流程将以此为依据开展工作。
4.3运维管理组织结构
本运维项目的运维管理结构位三层模式，具体如下图所示。
由项目负责人与甲方进行业务范围接洽，并将沟通结果向下传递。
项目经理负责项目的整体运维工作，包括各种制度的制定和实施。
运维工程师则在项目经理的指导下开展维护工作。
4.3.1运维负责人
职责：
负责项目商务、整体协调事宜。
职位描述：
1）、整体负责建设单位运维项目服务计划的制定，领导项目经理并安排项目工作，指导项目经理完成具体维护工作，每周听取项目经理的工作汇报，负责考核项目经理工作完成情况。
2）、协助建设单位完成新增项目的调研、方案设计并指导项目经理进行具体实施。
4.3.2运维主管
规划、执行、完善信息化项目的运维工作，指导网络、数据库维护工程师开展工作。
1、根据公司战略目标，指导下属工程师开展客户服务工作，确保运维工作能够满足客户的实际需要；
2、建立和持续完善运维管理体系，优化运维流程流程，解决运维服务中出现的特殊问题；
3、规划并提升运维工程师专业服务能力，在整体上提高客户满意度；
4、制定和持续完善绩效考核体系；
5、制定整理运维项目的应急预案系统，并指导运维工程师实施；
6、提高自身专业技能，在业务方面给予网络管理员和数据库管理员指导。
4.3.3系统管理员
操作系统、应用、数据库管理，oracle性能调优，实现应用负载均衡。
1、技术主管非项目常驻人员，根据项目需要进行专业方面指导；
2、负责数据库性能分析与调优，数据库运行状态监控，及时发现异常并快速处理。
3、熟练掌握Oracle10G的RAC技术，能够实现部署及调优。
4、掌握WAS、Weblogic、Tomcat、websphere等中间件的工作原理，能够实现部署调优及故障解决。
5、熟练掌握red-flag、redhat等linux操作系统，部署oracle10g、mysql数据库。
熟练掌握dataguard技术，保证oracle数据库冗灾、数据保护、故障恢复。
6、负责应用负载均衡的部署和调试。
7、负责指导数据库工程师管理员开展工作。
4.3.4网络管理员
维护建设单位网络系统正常，解决网络相关故障。
1、对现有服务器、局域网络及机房、配线间的日常管理维护；
2、对信息安全建设提出相关建议，确保网络的安全；
3、保证外网光纤线路正常，保证局域网运行正常；
4、对网络系统和网络设备的运行状态进行监控；
5、熟练掌握域策略设置、DHCP、DNS、FTP服务器、NTFS权限设置等；
6、编写网络部分的应用处理预案并实施。
7、工作认真、细致，积极主动有条理性，具有良好的沟通能力及团队合作精神.
4.3.5应用、数据库管理员
维护建设单位业务系统运行正常，解决应用和数据库故障。
1、监测业务系统运行状况，应用、数据库性能监视及优化，作必要调整；
2、规划不同数据的生命周期，制订备份、恢复、迁移和灾备策略，根据业务的需要执行数据转换及迁移等操作；
3、保证应用和数据库系统的安全性、完整性和运行效率。
4、负责数据库平台的整体架构及解决方案的制定和实施；
5、工作认真、细致，积极主动有条理性，具有良好的沟通能力及团队合作精神.
4.4运维服务标准流程
IT运维服务管理流程涉及事件管理、问题管理、配置管理、变更管理、发布管理、服务级别管理、财务管理、能力管理、可用性管理、服务持续性管理、知识管理及供应商管理等，随着运维活动的不断深入和持续改进，其他流程可能会逐步独立并规范。
4.4.1项目运维服务工作标准流程图
4.4.2服务台（暂无）
服务台是支持运维服务的核心功能，与各个流程联系密切。
所有管理流程都要通过服务台为用户提供单点联系，解答用户的相关问题和需求，或为用户寻求相应的支持人员。
在本系统中,服务台是接收各种来源服务请求和相关信息反馈的唯一入口和出口，同时服务台还负责一般请求、通过知识库（历史事件）能够解决的请求；
他也是复杂问题二线处理的桥梁。
由于当前人员不足，服务台的工作暂时由运维工程师统一处理。
4.4.3事件管理
事件管理流程的主要目标是尽快恢复服务提供并减少其对业务的不利影响，尽可能保证最好的服务质量和可用性等级。
事件管理流程通常涉及事件的侦测和记录、事件的分类和支持、事件的调查和诊断、事件的解决和恢复以及事件的关闭。
本系统把所有服务请求和报警归结为事件。
事件管理是提供服务台和事件管理者对于事件记录、处理、查询、审核、派发等功能。
它也包括通过和第三方监控系统对接，把其发送报警形成事件的功能。
4.4.4工单管理
工单管理：
工单是现场运维、二线支持的任务载体，运维工程依据所接收工单进行运维工作。
工单管理是对工单实现创建、变更、查询浏览、派发、监督等功能的模块。
4.4.5问题管理
问题管理流程的主要目标是预防问题和事故的再次发生，并将未能解决的事件的影响降低到最小。
问题管理流程包括诊断事件根本原因和确定问题解决方案所需要的活动，通过合适的控制过程，尤其是变更管理和发布管理，负责确保解决方案的实施。
问题管理还将维护有关问题、应急方案和解决方案的信息。
问题管理是针对已处理事件的遗留问题或处理事件的方案只是治标不治本的不能彻底解决问题而考虑的模块。
根据事件、及处理方案，问题处理人经过调查、诊断并提出最终解决方法。
4.4.6变更管理
变更管理实现所有基础设施和应用系统的变更，变更管理应记录并对所有要求的变更进行分类，应评估变更请求的风险、影响和业务收益。
其主要目标是以对服务最小的干扰实现有益的变更。
变更管理是要对重大资源的新增、变更、升级等运维活动进行审核的功能，以免这些活动对现有资源的可用性造成没有必要的影响和破坏；
同时，他还要实现在工单中产生的变化进行后审计的功能。
4.4.7配置管理
配置管理流程负责核实基础设施和应用系统中实施的变更以及配置项之间的关系是否已经被正确记录下来；
确保配置管理数据库能够准确地反映现存配置项的实际版本状态。
配置管理实际上是全部资源的统一管理的功能，包括资源整个生命周期的参数或配置的变化记录的管理。
管理信息主要涉及分类、型号、版本、位置，状态、相关资料等基本信息还包括核心参数等
4.4.8知识库管理
运维知识经验的总结、维护和共享是提高员工运维技能水平、增强单位凝聚力的重要手段，也是把宝贵的经验教训从支持人员头脑逐步沉淀、固化的重要方式。
知识库管理：
知识库是提供给运维人员重要的技术资料内容，他汇集在工作的遇到的典型案例归纳总结的知识要点和全面实用资料手册。
在本系统中，知识库管理提供便于使用的人机接口、快速查询的技术手段和维护手段。
4.4.9统计及工作报告
运维管理系统提供一线解决率统计、客户满意度统计、按分类的事件汇总统计、工作报告生成的功能，按照一定格式根据事件数据、工单数据、问题数据、配置数据、变更数据可以帮助运维管理者能把运维的所做的工作内容清晰的罗列出来。
5、运维服务内容
5.1运维服务目标
实验室运维部门提供的运行维护服务包括，虚拟机、主机设备、操作系统、数据库、网络安全设备和存储设备的运行维护服务，保证云管理平台的正常运行，降低整体管理成本，提高Iaas平台的整体服务水平。
同时根据日常维护的数据和记录，给研发部门提供Iaas平台优化及改善建议。
实验室运维的组成主要可分为两类：
硬件设备和软件系统。
硬件设备包括网络设备、安全设备、主机设备、存储设备等；
软件设备可分为云管理平台、操作系统、典型应用软件（如：
数据库软件等）等。
服务项目范围覆盖的信息系统资源以下方面的关键状态及参数指标：
Ø
运行状态、故障情况
配置信息
可用性情况及健康状况性能指标
5.2IT资产统计服务
服务内容包括：
硬件设备型号、数量、版本等信息统计记录
软件产品型号、版本和补丁等信息统计记录
网络结构、网络路由、网络IP地址统计记录
综合布线系统结构图的绘制
其它附属设备的统计记录
5.3网络、安全系统运维服务
从网络的连通性、网络的性能、网络的监控管理三个方面实现对网络系统的运维管理，网络设备位于IT架构的骨干位置，下面是需要监控的指标，及对应健康状况故障以后可能引起的问题。
设备基础性能检测：
cpu、内存使用情况监测。
当cpu、内存使用率过高，会导致用户网络访问质量下降，丢包、时延较高等状况的产生。
说明当前网络设备负载较高，需要对下行设备进行迁移，分流，减轻负载。
设备日志查看；
当设备日志出现异常时，可能是设备出现异常访问或者异常配置，可能会导致网络中断。
需要检测防火墙等安全设备状态。
设备snmp、telnet状态；
当snmp、telnet都不可达时，一般是设备脱网情况的产生，会导致网络中断。
需要人工查看设备运行状态。
测试Ping，tracert等工具的连通性；
当ping丢包率过高，说明网络访问质量有问题，需要tracert查看网络路径是哪一跳对应的IP设备时延较高或者不可达。
分析是哪个网关路由或者策略引起的问题。
网络安全策略应用是否正常；
安全策略异常会导致网络设备遭受入侵，会影响整个网络的访问。
Internet带宽流量的实时监测；
流量所占带宽比较高，会造成当前网络设备对应端口网关的所有网络访问质量下降。
需要抓包查看是哪些设备对应的访问流量较高，决定是加大带宽还是服务器中毒。
网络拓扑链路状态监测；
链路状态异常说明网络中某个设备异常，需要查看链路对应的网络设备健康状况，结合其他指标分析问题所在。
异常网络数据包流量、Dos、ddos等网络攻击情况监测；
存在异常网络数据流量包等，会导致正常的网络质量下降，说明网络可能受到攻击，需要结合netflow和流量状况查看异常流量的访问网段，从路由策略或者防火墙限制该网段的访问
光纤光口光功率、光电口误码率大小。
光功率值不在光模块的默认光功率范围内，会导致光口不可用，可能是光模块出现故障，需要联系厂家查看光模块是否正常
5.4主机、存储系统运维服务
提供的主机、存储系统的运维服务包括：
主机、存储设备的日常监控，设备的运行状态监控，故障处理，操作系统维护，补丁升级等内容。
进行监控管理的内容包括：
CPU性能管理；
GPU指标过高，会导致服务器程序运行缓慢，出现卡死状况。
需要查看引起GPU过高原因，做虚机迁移等操作，减轻服务器压力。
内存使用情况管理；
内存使用率过大，会导致服务器崩溃，需要及时扩充内存资源，或者回收不再使用的虚机资源。
硬盘利用情况管理；
硬盘使用率过高，会导致开始启动失败，需要定期清理服务器临时文件，或者扩充服务器硬盘。
系统进程管理；
服务器关键进程运行是否正常，异常会导致服务器崩溃，需要查看进程异常原因。
实时监控主机电源、风扇的使用情况及主机机箱内部温度；
电源状态异常，可能会导致服务器断电，风扇异常，主机稳定过高会导致服务器重启，需要与厂商联系，查看硬件是否正常
监控主机硬盘运行状态；
硬盘读写状态等标识硬盘可用性，需要查看是否硬盘压力过大，考虑更换存储类型ssd等
监控主机网卡等硬件状态；
主机网卡down掉，会影响服务器的网络访问，硬件异常会影响服务器正常运行，需要联系厂商做硬件检测。
监控主机HA运行状况；
灾备系统运行异常，会导致HA切换异常，需要查看引起HA异常的原因，是软件问题还是硬件问题，逐步排除原因。
5.5数据库系统运维服务
提供的数据库运行维护服务是包括主动数据库性能管理，数据库的主动性能管理对系统运维非常重要。
通过主动式性能管理可了解数据库的日常运行状态，识别数据库的性能问题发生在什么地方，有针对性地进行性能优化。
同时，密切注意数据库系统的变化，主动地预防可能发生的问题。
数据库基本信息：
文件系统、碎片、死锁、CPU占用率较大或时间较长的SQL语句。
存在上面会导致业务访问缓慢，需要定位那些SQL占用内存较大或者死锁，针对具体情况进行优化代码。
表空间使用信息监测；
表空间占用太大会影响查询效率，需要优化存储结构，将集中存储换为单表文件，索引根据实际业务进行优化，是否需要索引，或者索引删除重建，或者建立分区表。
数据库文件I/0读写情况；
数据库I/0反应数据库瓶颈，查看引起I/O较大的原因是业务量较大还是服务器I/O现在，更换存储类型，必要情况下更换内存数据库等。
Session连接数量监控；
Session长链接数量较大会造成数据库负载较高，需要考虑将长链接更换为短连接。
数据库监听运行状态监测；
数据库运行状态为down会导致业务中断，查看是业务层还是网络层引起的问题，如果为网络层，需要对网络情况排除，如果为业务层导致，要进行SQL优化。
查看每日数据备份、数据同步是否正常；
数据库备份异常，会导致备份数据丢失，对于数据库迁移，和数据恢复造成不可恢复的影响，需要具体查看引起该问题是数据库本身还是服务器问题，具体问题具体分析解决。
对表和索引进行Analyze,检查表空间碎片；
数据库表和索引的占用量太大会影响查询效率，需要调整表结构或者索引删除重建。
数据库对象的空间扩展情况监测；
表空间扩展太快会导致数据库服务器存储空间占满，数据库down掉等异常情况，需要优化表结构。
5.6云管理平台运维服务
云管理平台主要包括管理节点、计算节点、存储节点的运维。
同时，实时监控重点虚拟机，保证主要业务不中断。
主要内容包括：
ManagementServer状态及性能监控（cpu、内存、磁盘、io、mysql数据库、系统及应用日志等）；
虚拟化主机agent状态监控；
主存储及二级存储使用率监控；
数据中心虚拟资源（cpu、内存、磁盘）使用量监控；
单台计算节点cpu、内存分配及实际使用量监控；
单台存储节点硬盘分配及实际使用量监控；
虚拟机模版、网络、方案策略制定；
系统虚拟机、虚机路由状态监控；
非计费用户闲置虚拟资源回收；
用户资源审批、账户充值及余额管理；
虚拟机外网网络及端口开通；
计算节点主机及存储节点扩容；
5.7运维工具
监控工具
实验室选用开源运维工具Zabbix，Zabbix是一个基于WEB界面的提供分布式系统监控以及网络监控功能的企业级开源运维平台，也是目前国内互联网用户中使用最广的监控软件。
Grafana-zabbix展示效果
入门容易、上手简单、功能强大并且开源免费是对Zabbix的最直观评价。
Zabbix易于管理和配置，能生成比较漂亮的数据图，其自动发现功能大大减轻日常管理的工作量，丰富的数据采集方式和API接口可以让用户灵活进行数据采集，而分布式系统架构可以支持监控更多的设备。
理论上，通过Zabbix提供的插件式架构，可以满足企业的任何需求。
优点：
1.支持多平台的企业级分布式开源监控软件;
2.安装部署简单、管理方便;
3.功能强大，监控灵活，可实现复杂多条件告警;
4.多种数据采集插件，灵活集成;
5.自带画图功能，得到的数据可以绘成图形;
6.同时支持调用脚本，很方便;
7.提供多种API接口，定制化最高的监控软件;
8.出现问题时可自动远程执行命令（需对agent设置执行权限）;
缺点：
1.项目批量修改不方便;
2.社区虽然成熟，但是中文资料相对较少，服务支持有限;
3.入门容易，能实现基础的监控，但是深层次需求需要非常熟悉Zabbix并进行大量的二次定制开发，难度较大;
4.系统级别报警设置相对比较多，如果不筛选的话报警邮件会很多;
并且自定义的项目报警需要自己设置，过程比较繁琐;
5.缺少数据汇总功能，如无法查看一组服务器平均值，需进行二次开发;
6.数据报表需要特殊二次开发定义;
实验室监控体系也有集中式监控扩展到分布式监控，监控系统之间的耦合性逐步降低。
在分布式系统中，整个系统有一个监控中心服务器，若干个子监控服务器和被监控对象组成的，每一个子监控服务器负责监控属于它所属的子系统，不同的子系统之间也不完全独立，他们之间的规模也不大，产生的数据也不是很大。
这样就大大减小中心监控服务器的工作压力。
图：
分布式监控架构
分布式监控主要分三个层次，最底层是需要监控的节点，他通过启动snmp服务或者主动发送trapped或者启动agent进程。
收集每个节点的状态信息，并向监控子服务器发送收集的信息。
中间层是proxy服务器层，它负责收集每个节点发送给它的监控信息，然后向中心的监控服务器发送搜集到的监控信息。
最上面一层是中心监控服务器，它主要负责收集每个子监控服务器的数据，然后存入数据库，再通过web服务器发送提供展现、查询、等服务。
分布式的监控结构将大量数据采集的工作分散到每个监控子系统中，从而极大的减少了监控中心服务器的压力，减少了网络的负载，但是也可能带来一定的系统延迟。
Zabbix性能优化：
性能指标的采集方式根据不同指标类型进行指标分组，如CPU组、内存组、文件系统组、进程组等，每个性能组又对应若干个性能，根据不同用户对于不同指标关注度不同，指标采集力度也不同，如CPU内存等实时度要求比较高的，需要1分钟采集一次，而对应存储的硬盘检测可能趋势变化不大，所以采集力度可能比较大一周或者一月。
而随着设备量的增加，虚机的扩张变快，zabbix服务器的优化不得不加入考虑，Zabbix虽然采用分布式结构，但是指标计算（按照通用指标统计）:
2500（服务器数量）*15（指标数量）*3600（一天）=135000000
Zabbixserver的性能同过查看指标，每秒处理数和等待队列长度
Zabbix数据库调优：
a）使用innodb，为每一张数据库表使用一个文件，修改my.cfinnodb_file_per_table=1;
升级会员 