安全运维服务规范.docx

安全运维服务规范.docx

《安全运维服务规范.docx》由会员分享，可在线阅读，更多相关《安全运维服务规范.docx（12页珍藏版）》请在冰豆网上搜索。

安全运维服务规范

安全运维服务规范

一、总则

为了规范本公司所从事的运维管理工作，使得相关工作具有持续改善性及相互协作性，能够支撑公司相关业务的健康可靠的运行，由此制定本规范。

本规范适用于公司技术部所有人员。

二、部门职责

（1）负责对甲方信息化基础设施的技术保障，包括网络、电话、机房、服务器系统、数据安全等技术支持；

（2）负责对甲方所有服务器操作系统的技术运维工作；

（3）负责对甲方应用系统数据库的性能调优及技术运维工作；

（4）负责对甲方各种网络及安全设备的技术运维保障工作。

三、行为规范

（1）遵守用户的各项规章制度，严格按照用户相应的规章制度办事。

（2）与用户运行维护体系其他部门和环节协同工作，密切配合，共同开展技术支持工作。

（3）出现疑难技术、业务问题和重大紧急情况时，及时向负责人报告。

（4）现场技术支持时要精神饱满，穿着得体，谈吐文明，举止庄重。

接听电话时要文明礼貌，语言清晰明了，语气和善。

（5）遵守保密原则。

对被支持单位的网络、主机、系统软件、应用软件等的密码、核心参数、业务数据等负有保密责任，不得随意复制和传播。

3.1运维规范

3.1.1各项内容常规检查规范

运行环境检查：

对设备运行环境检查，包括温度、湿度、清洁度。

查看中央空调运行是否正常，温度、湿度显示是否正常，空调有无报警；查看电源配电柜是否有报警，电源电压输出是否正常；每日两次（早、晚）对设备运行环境检查、记录。

常规硬件检查：

每天检查重要服务器的运行状态、有无故障报警、操作系统和应用系统是否正常，每日进行两次（早、晚）检查、记录；每周一次对重要设备全面检查、填写运行记录；每2周一次对所有服务器设备检查、记录。

对检查后发现的故障及时处理，对损坏设备及时维修或更换，对缺乏备件的设备要提交设备购买申请报告。

操作系统的安全设置按照服务器操作系统安全设置文档对操作系统进行设置，确定文件、目录等的访问权限，将服务器对外权限降到可以正常使用的最低状态，及时安装防杀病毒软件。

同时应由专门人员定期修改服务器密码、下载更新补丁等；各应用服务器系统数据上传、更新的安全保障，后台系统的使用和更新进行安全管理；各服务器定期全面更新系统补丁；定期全面更新病毒库、查杀病毒；定期更新系统密码。

数据备份：

网络中心内所有数据必须保持完整备份，重要数据至少需要保存3到4个备份；重要备份数据除在网络中心内SAN存储上即时备份，同时还需要在外存上进行定期保存；每个月末需对重要数据进行全面备份。

3.1.2网络及安全设备日常操作规范

交换路由类外观检查：

每天早晨检查核心交换机电源、端口等指示灯是否正常，是否有报警声，根据外观检查判断网络运行是否正常。

防火墙：

每天早晨监看外观指示灯是否正常；登陆防火墙监看防火墙使用日志、运行状态（CPU、内存等）；查看各接口流量是否正常；定期下载配置信息，保证最新的配置可以有效使用；对防火墙所进行的修改要有记录，如是临时调整，使用完毕应立即恢复到原状态。

IPS、防杀病毒软件：

每天监看IPS、防杀病毒软件防范入侵、检查网络入侵拦截日志、客户端病毒查杀统计日志，根据日志进行相关策略调整；定期检查病毒库是否更新，保持本地病毒库是最新状态。

3.1.3操作系统、应用系统日常操作规范

服务器维护：

按照重点服务器设备运行维护方案对服务器进行维护，根据维护方案按月填写运行维护报告，分析系统运行各项指标、对系统安全性和稳定性进行评估，对存在隐患进行总结和分析。

对运行存在的问题给出合理化处理建议。

操作系统、应用系统维护：

按照应用系统运行维护方案对主要应用系统进行维护，重点应用系统包括教学管理平台及其数据库系统、WEB及后台数据库系统、mysql系统的数据库系统。

维护范围包括操作系统和应用系统以及数据库的运行稳定性和安全性，数据库的安全性包含数据库的自动备份和还原处理是否正常。

根据维护方案按月填写运行维护报告，对存在隐患进行总结和分析。

3.1.4内部运维规范

（1）运维工程师，负责岗位职责内相应的IT设施的《维护手册》的制定和完善、并按照本运维规范执行维护管理工作和巡检工作。

（2）运维工程师应当依据运维过程收集的记录信息，每月整理出当月的《月度运维报告》提报部门经理，报告中要重点关注IT设施的问题和改进分析，并提出改进措施和建议。

（3）部门经理，负责保障运维管理体系的有效执行，包括本运维管理规范的制定和完善，督导维护工程师完善各设施维护手册。

（4）部门经理在月度工作会议上就当月各个运维工作报告与团队沟通共识出整改措施，并形成新的工作计划，推动落实执行。

3.1.5巡检管理规范

（1）巡检对象：

机房、数据备份、网络、服务器、系统的运行状态。

（2）巡检周期：

每日、每周、每月。

（3）每位运维工程师依据各自维护设施，按时对检核内容进行检查。

每日：

当日下班前要把当天检查情况填报检核表。

（4）部门经理将不定期检查巡检的完成情况。

（5）巡检期间，如果发现设备或系统异常，应立即上报部门经理并展开调查，确认故障的应立即进入故障处理环节。

3.1.6监控告警规范

（1）监控中心提供在线监控、流量分析、故障告警；

（2）设定告警阀值：

磁盘阀值95%，非数据库系统内存阀值70%，CPU阀值70%。

（3）告警：

达到阀值或系统中断时，平台通过短信通知到运维工程师，运维工程师收到告警后，应该立即检查系统的健康状况，并在应急预案规定时间内恢复正常；

（4）根据公司《应急预案》的要求，在规定时限内进行故障恢复；

（5）故障发生时，运维工程师在无法锁定问题根源时，应该立即启动应急机制，在规定时间内先恢复业务使用，并在非工作时间进行详细的故障排查；

（6）经过排查仍然无法解决时，应立即向部门经理汇报，并寻求外部资源直至问题解决。

3.1.7运维审计规范

（1）三权分立：

角色分为审计员、设备管理员、运维人员，审计员仅能进行审计工作，对设备管理员和运维人员的行为进行审计，不能创建运维账号，没有系统权限和账号，无法进行运维工作。

设备管理员保管系统账号及权限分配，但不能创建运维账号，也无法进行运维工作。

运维人员只能进行运维工作，没有系统账号及设备管理权限；

（2）内部运维工程师使用AD账号登录堡垒机，进行日常的运维工作；

（3）外协人员通过临时创建的运维账号登录堡垒机，进行相关工作；

（4）任何人员都严禁擅自更改系统的密码、端口等配置；

（5）审计记录保留一年，审计人员不定期进行抽检；

3.2运维流程

IT基础设施运维作业过程中，出现问题需要用到的流程：

事件管理、问题管理、变更管理，随着运维活动的不断深入和持续改进，其他流程可能会逐步独立并规范。

3.2.1事件管理

事件管理流程的主要目标是尽快恢复IT服务，并减少其对业务的不利影响，尽可能保证最好的IT服务质量和可用性。

（1）事件流程：

（2）事件表单

（3）流程说明

任何引起服务中断和服务质量下降的现象，统称事件。

处理人：

表示事件的受理人，并负责整个事件的解决，直到事件结束。

受理人负责事件流程的发起，经理负责审核事件的状态及表单信息的完整性。

事件结束自动转入问题管理。

3.2.2问题管理

问题管理流程的主要目标是预防问题和事故的再次发生，并且在事故的再次发生时，可以找到有效的处理方法。

问题管理流程包括诊断事件根本原因和确定问题解决方案所需要的活动，问题管理还将维护有关问题、应急方案和解决方案的信息。

（1）问题流程

（2）问题表单

（3）流程说明

所有问题都应该被完整准确的记录下来，并保证相关信息应尽可能详细。

明确问题管理的问题信息来源，问题可能来源于某些事件的进一步调查，也可能来源于主动巡检和事件报表分析。

问题发起人首先识别问题，分析可能造成的危害，提出解决方案，计划好问题的处置时间，并通知受影响的用户。

经理负责评估方案的合理性。

03.2.3变更管理

变更管理实现所有IT基础设施和应用系统的变更，变更管理应记录并对所有要求的变更进行分类，应评估变更请求的风险、影响和业务收益。

其主要目标是以对服务最小的干扰实现有益的变更。

（1）变更流程

（2）变更表单

（3）流程说明

所有涉及运维生产环境的变化，都必须走变更流程。

变更的发起人，负责发起变更，提交变更方案，并负责变更的执行。

经理负责评估变更方案的可行性。

3.3现场服务支持规范

运维服务人员要做到耐心、细心、热心的服务。

工作要做到事事有记录、事事有反馈、重大问题及时汇报。

严格遵守工作作息时间，严格按照服务工作流程操作。

（1）现场支持工程师应着装整洁、言行礼貌大方，技术专业，操作熟练、严谨、规范；现场支持时必须遵守用户单位的相关规章制度。

（2）现场支持工程师在进行现场支持工作时必须在保证数据和系统安全的前提下开展工作。

（3）现场支持时出现暂时无法解决的故障或其他新的故障时，应告知用户并及时上报负责人，寻找其他解决途径。

（4）故障解决后，现场支持工程师要详细记录问题的发生时间、地点、提出人和问题描述，并形成书面文档，必要时应向用户介绍故障出现的原因及预防方法和解决技巧。

3.4问题记录规范

根据使用人员提出问题的类别，将问题分为咨询类问题和系统缺陷类问题二类：

咨询类问题是指通过服务热线或现场解疑等方式能够当场解决用户提出的问题，具有问题解答直接、快速和实时的特点，该问题到现场支持人员处即可中止，对于该类问题的记录可使用咨询类问题记录模版进行记录。

系统缺陷类问题是指使用人员提出的问题涉及到系统相应环节的确认修改，需要经过逐级提交、诊断、确认、处理和回复等环节，处理解决需要信息技术服务项目组的分析确认，问题有解决方案后，将解决方案反馈给用户。

具体提交流程如下：

（1）问题提交。

应用信息系统的用户发现属于系统缺陷类的问题时，填写系统缺陷类问题提交单，提交服务支持中心。

（2）问题分析。

服务中心接到用户提交的问题单，要组织相应人员对问题单中描述的问题进行分析研判，确定问题的类型（技术问题、业务问题或者操作问题）。

属于技术问题，提交服务中心技术人员对存在的问题提出具体的处理意见和建议；属于业务问题，提交服务中心业务人员进行处理；属于操作问题，可安排相关人员对问题提出人进行解释，并将系统缺陷类问题提交单转为系统咨询类问题提交单。

（3）问题确认、解决。

服务中心的技术人员和业务人员收到系统缺陷类问题提交单后，对提交的问题进行归类汇总和分析、确认。

可以解决的，明确问题解决的具体处理建议和措施，经主管领导签字同意后，交实施人员进行解决方案的实施。

服务人员确认是否解决，并将解决方法附在系统缺陷类问题提交单上反馈给问题提出人员。

（4）问题上报。

服务人员收到经业务或技术人员确认的系统缺陷类问题提交单后，上报服务中心。

（5）问题回复。

服务中心根据提交问题的进行分析，制定解决方案并进行实施的解决，同时做好变更记录。

将解决方案汇总后及时向问题提交单位或问题交办单位做出回复，并将分析过程和问题产生原因一并提交。

四、运维服务质量指标规范

IT运维服务质量指标体系是用来衡量整个运维服务工作质量的标准规范，指标标准如下：

（1）接收服务请求和咨询：

在5*8小时工作时间内设置由专人职守的热线电话，接听内部的服务请求，并记录服务台事件处理结果。

（2）在非工作时间设置有专人7*24小时接听的移动电话热线，用于解决内部的技术问题以及接听7*24小时机房监控人员的机房突发情况汇报。

（3）服务响应时间：

故障级别

响应时间

故障解决时间

I级：

属于紧急问题；其具体现象为：

系统崩溃导致业务停止、数据丢失。

30分钟，2小时内提交故障处理方案

12小时以内

II级：

属于严重问题；其具体现象为：

出现部分部件失效、系统性能下降但能正常运行，不影响正常业务运作。

30分钟，2小时内提交故障处理方案

24小时以内

III级：

属于较严重问题；其具体现象为：

出现系统报错或警告，但业务系统能继续运行且性能不受影响。

30分钟，2小时内提交故障处理方案

48小时以内

IV级：

属于普通问题；其具体现象为：

系统技术功能、安装或配置咨询，或其他显然不影响业务的预约服务。

30分钟，2小时内提交故障处理方案

5天内

技术支持人员在解决故障时，会最大限度保护好数据，做好故障恢复的文档，力争恢复到故障点前的业务状态。

对于“系统瘫痪，业务系统不能运转”的故障级别，如果不能于12小时内解决故障，乙方将在16小时内提出应急方案，确保业务系统的运行。

故障解决后24小时内，提交故障处理报告。

说明故障种类、故障原因、故障解决中使用的方法及故障损失等情况。

五、应急服务响应措施

乙方已经针对本项目制定了详尽的设计、应急处理预案，整个流程严谨而有序。

但是，在服务维护过程中，意外情况将难以完全避免。

下面，我们将对项目实施的突发风险进行详细分析，并且针对各类突发事件，设计了相应的预防与解决措施，同时提供了完整的应急处理流程。

5.1应急基本流程

维护服务应急处理流程

5.2预防措施

针对上门服务过程中可能遇到的各种各样的风险，乙方总结多年维护服务经验，针对一些可能出现的情况，制定了一系列预防处理措施，举例如下：

类型

事件

预防措施

处理

应用软件

无法启动软件可执行文件

上门人员提前准备好各类需维护软件安装程序

将应用软件数据文件备份后，重新安装

软件打开过程中或运行中异常错误关闭

上门人员准备好安装程序，操作系统优化和修补软件，查杀病毒软件

判断出错原因，备份数据，采取相关修复措施

操作系统

使用者本机操作系统异常或系统资源占用严重

准备好系统检查程序及修补程序，以及查杀病毒软件

告知使用者错误原因可能类型，提出解决方案，经使用者认可后采取相应措施

B/S结构系统，IE浏览器异常或无法下载控件

准备流氓软件清理程序、修复浏览器软件、查杀病毒软件

检查IE浏览器选项设置，分析原因进行修复

网络或服务器

B/S结构系统网络流量异常或服务器登录异常

判断服务器是否异常，否则准备杀毒软件

检查网络流量，流量异常小则报修网络服务商，流量异常大则查杀病毒

六、突发事件应急策略

系统运维应急方案是对中断或严重影响业务的故障，如宕机、数据丢失、业务中断等，进行快速响应和处理，在最短时间内恢复业务系统，将损失降到最低。

在系统维护过程中，突发事件的出现将是很难完全避免的，针对这种情况，乙方设计了完善的突发事件应急策略。

系统维保人员要定期规范检查各硬件设备的运转情况和应用软件运行情况，同时做好日常的数据增量备份和定期全备份。

对发现的问题在报各级负责人的同时，要协调相关资源分析问题根源，确定解决方案和临时解决措施，避免造成更大的影响。

问题得到稳定或彻底解决后，要形成问题汇报，避免以后类似重大紧急情况的发生。

对发现的问题在报负责人的同时，要协调相关资源分析问题根源，确定解决方案和临时解决措施，避免造成更大的影响。

问题得到稳定或彻底解决后，要形成问题汇报，避免以后类似重大紧急情况的发生。

乙方不但拥有经验丰富的技术支持工程师，而且根据长期以来的客户服务工作经验，建立了常用知识库，其中包括多种常见技术故障和突发事件的应急策略。

当获悉出现突发事件时，技术支持人员可以立即从知识库中获取相应的应急策略，并综合用户方的具体情况，给出相关解决方案，然后在第一时间以电话、邮件支持或现场服务的方式帮助用户解决问题，尽最大努力减小突发事件对用户日常应用的影响。

紧急情况

预防措施

应急策略

硬件损坏

项目单位操作用电脑硬件损坏

在磁盘数据未丢失情况下，保证数据安全性，建议项目单位替换相关硬件。

操作失误

加强培训力度，掌握培训效果，检验操作人员操作水准，提示注意事项。

操作失误未造成即成结果或数据未丢失情况下，保障数据安全，反之，协调相关部门，进行补救。

对操作人员强调注意事项

配置丢失

培训时强调使用前配置方法和步骤，并特别提示需在使用前按要求操作

派出上门维护、培训人员重新配置，并耐心讲解。

数据丢失

培训时强调使用过程中注意定期备份重要数据，日常维护过程中，上门服务人员实时备份数据并告知用户

协调有关部门，进行补救，无法补救，提交报告说明原因。

突发事件应急策略服务流程图如下：