关于it运维事件分析的信息

本篇文章给大家谈谈it运维事件分析，以及对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。 今天给各位分享it运维事件分析的知识，其中也会对进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

• 1、IT运维数据分析如何做？
• 2、IT运维问题分析的常用方法是什么
• 3、IT运维工作报告

IT运维数据分析如何做？

给你个专业的。（信息安全的运维管理）
7.2.5 系统运维管理
7.2.5.1 环境管理（G3）
本项要求包括：
a) 应指定专门的部门或人员定期对机房供配电、空调、温湿度控制等设施进行维护管理；
b) 应指定部门负责机房安全，并配备机房安全管理人员，对机房的出入、服务器的开机或关机等工作进行管理；
c) 应建立机房安全管理制度，对有关机房物理访问，物品带进、带出机房和机房环境安全等方面的管理作出规定；
d) 应加强对办公环境的保密性管理，规范办公环境人员行为，包括工作人员调离办公室应立即交还该办公室钥匙、不在办公区接待来访人员、工作人员离开座位应确保终端计算机退出登录状态和桌面上没有包含敏感信息的纸档文件等。
7.2.5.2 资产管理（G3）
本项要求包括：
a) 应编制并保存与信息系统相关的资产清单，包括资产责任部门、重要程度和所处位置等内容；
b) 应建立资产安全管理制度，规定信息系统资产管理的责任人员或责任部门，并规范资产管理和使用的行为；
c) 应根据资产的重要程度对资产进行标识管理，根据资产的价值选择相应的管理措施；
d) 应对信息分类与标识方法作出规定，并对信息的使用、传输和存储等进行规范化管理。
7.2.5.3 介质管理（G3）
本项要求包括：
a) 应建立介质安全管理制度，对介质的存放环境、使用、维护和销毁等方面作出规定；
b) 应确保介质存放在安全的环境中，对各类介质进行控制和保护，并实行存储环境专人管理；
c) 应对介质在物理传输过程中的人员选择、打包、交付等情况进行控制，对介质归档和查询等进行登记记录，并根据存档介质的目录清单定期盘点；
GB/T 22239—2008
28
d) 应对存储介质的使用过程、送出维修以及销毁等进行严格的管理，对带出工作环境的存储介质进行内容加密和监控管理，对送出维修或销毁的介质应首先清除介质中的敏感数据，对保密性较高的存储介质未经批准不得自行销毁；
e) 应根据数据备份的需要对某些介质实行异地存储，存储地的环境要求和管理方法应与本地相同；
f) 应对重要介质中的数据和软件采取加密存储，并根据所承载数据和软件的重要程度对介质进行分类和标识管理。
7.2.5.4 设备管理（G3）
本项要求包括：
a) 应对信息系统相关的各种设备（包括备份和冗余设备）、线路等指定专门的部门或人员定期进行维护管理；
b) 应建立基于申报、审批和专人负责的设备安全管理制度，对信息系统的各种软硬件设备的选型、采购、发放和领用等过程进行规范化管理；
c) 应建立配套设施、软硬件维护方面的管理制度，对其维护进行有效的管理，包括明确维护人员的责任、涉外维修和服务的审批、维修过程的监督控制等；
d) 应对终端计算机、工作站、便携机、系统和网络等设备的操作和使用进行规范化管理，按操作规程实现主要设备（包括备份和冗余设备）的启动/停止、加电/断电等操作；
e) 应确保信息处理设备必须经过审批才能带离机房或办公地点。
7.2.5.5 监控管理和安全管理中心（G3）
本项要求包括：
a) 应对通信线路、主机、网络设备和应用软件的运行状况、网络流量、用户行为等进行监测和报警，形成记录并妥善保存；
b) 应组织相关人员定期对监测和报警记录进行分析、评审，发现可疑行为，形成分析报告，并采取必要的应对措施；
c) 应建立安全管理中心，对设备状态、恶意代码、补丁升级、安全审计等安全相关事项进行集中管理。
7.2.5.6 网络安全管理（G3）
本项要求包括：
a) 应指定专人对网络进行管理，负责运行日志、网络监控记录的日常维护和报警信息分析和处理工作；
b) 应建立网络安全管理制度，对网络安全配置、日志保存时间、安全策略、升级与打补丁、口令更新周期等方面作出规定；
c) 应根据厂家提供的软件升级版本对网络设备进行更新，并在更新前对现有的重要文件进行备份；
d) 应定期对网络系统进行漏洞扫描，对发现的网络系统安全漏洞进行及时的修补；
e) 应实现设备的最小服务配置，并对配置文件进行定期离线备份；
f) 应保证所有与外部系统的连接均得到授权和批准；
g) 应依据安全策略允许或者拒绝便携式和移动式设备的网络接入；
GB/T 22239—2008
29
h) 应定期检查违反规定拨号上网或其他违反网络安全策略的行为。
7.2.5.7 系统安全管理（G3）
本项要求包括：
a) 应根据业务需求和系统安全分析确定系统的访问控制策略；
b) 应定期进行漏洞扫描，对发现的系统安全漏洞及时进行修补；
c) 应安装系统的最新补丁程序，在安装系统补丁前，首先在测试环境中测试通过，并对重要文件进行备份后，方可实施系统补丁程序的安装；
d) 应建立系统安全管理制度，对系统安全策略、安全配置、日志管理和日常操作流程等方面作出具体规定；
e) 应指定专人对系统进行管理，划分系统管理员角色，明确各个角色的权限、责任和风险，权限设定应当遵循最小授权原则；
f) 应依据操作手册对系统进行维护，详细记录操作日志，包括重要的日常操作、运行维护记录、参数的设置和修改等内容，严禁进行未经授权的操作；
g) 应定期对运行日志和审计数据进行分析，以便及时发现异常行为。
7.2.5.8 恶意代码防范管理（G3）
本项要求包括：
a) 应提高所有用户的防病毒意识，及时告知防病毒软件版本，在读取移动存储设备上的数据以及网络上接收文件或邮件之前，先进行病毒检查，对外来计算机或存储设备接入网络系统之前也应进行病毒检查；
b) 应指定专人对网络和主机进行恶意代码检测并保存检测记录；
c) 应对防恶意代码软件的授权使用、恶意代码库升级、定期汇报等作出明确规定；
d) 应定期检查信息系统内各种产品的恶意代码库的升级情况并进行记录，对主机防病毒产品、防病毒网关和邮件防病毒网关上截获的危险病毒或恶意代码进行及时分析处理，并形成书面的报表和总结汇报。
7.2.5.9 密码管理（G3）
应建立密码使用管理制度，使用符合国家密码管理规定的密码技术和产品。
7.2.5.10 变更管理（G3）
本项要求包括：
a) 应确认系统中要发生的变更，并制定变更方案；
b) 应建立变更管理制度，系统发生变更前，向主管领导申请，变更和变更方案经过评审、审批后方可实施变更，并在实施后将变更情况向相关人员通告；
c) 应建立变更控制的申报和审批文件化程序，对变更影响进行分析并文档化，记录变更实施过程，并妥善保存所有文档和记录；
d) 应建立中止变更并从失败变更中恢复的文件化程序，明确过程控制方法和人员职责，必要时对恢复过程进行演练。
7.2.5.11 备份与恢复管理（G3）
本项要求包括：
a) 应识别需要定期备份的重要业务信息、系统数据及软件系统等；
GB/T 22239—2008
30
b) 应建立备份与恢复管理相关的安全管理制度，对备份信息的备份方式、备份频度、存储介质和保存期等进行规范；
c) 应根据数据的重要性和数据对系统运行的影响，制定数据的备份策略和恢复策略，备份策略须指明备份数据的放置场所、文件命名规则、介质替换频率和将数据离站运输的方法；
d) 应建立控制数据备份和恢复过程的程序，对备份过程进行记录，所有文件和记录应妥善保存；
e) 应定期执行恢复程序，检查和测试备份介质的有效性，确保可以在恢复程序规定的时间内完成备份的恢复。
7.2.5.12 安全事件处置（G3）
本项要求包括：
a) 应报告所发现的安全弱点和可疑事件，但任何情况下用户均不应尝试验证弱点；
b) 应制定安全事件报告和处置管理制度，明确安全事件的类型，规定安全事件的现场处理、事件报告和后期恢复的管理职责；
c) 应根据国家相关管理部门对计算机安全事件等级划分方法和安全事件对本系统产生的影响，对本系统计算机安全事件进行等级划分；
d) 应制定安全事件报告和响应处理程序，确定事件的报告流程，响应和处置的范围、程度，以及处理方法等；
e) 应在安全事件报告和响应处理过程中，分析和鉴定事件产生的原因，收集证据，记录处理过程，总结经验教训，制定防止再次发生的补救措施，过程形成的所有文件和记录均应妥善保存；
f) 对造成系统中断和造成信息泄密的安全事件应采用不同的处理程序和报告程序。
7.2.5.13 应急预案管理（G3）
本项要求包括：
a) 应在统一的应急预案框架下制定不同事件的应急预案，应急预案框架应包括启动应急预案的条件、应急处理流程、系统恢复流程、事后教育和培训等内容；
b) 应从人力、设备、技术和财务等方面确保应急预案的执行有足够的资源保障；
c) 应对系统相关的人员进行应急预案培训，应急预案的培训应至少每年举办一次；
d) 应定期对应急预案进行演练，根据不同的应急恢复内容，确定演练的周期；
e) 应规定应急预案需要定期审查和根据实际情况更新的内容，并按照执行。2011-10-20

IT运维问题分析的常用方法是什么

第一点，基于问题树的模式本质上是结构化问题分析和思维的模式。这种模式往往造成不独立，其原因在于进行每一次分解的时候没有考虑相互独立。
第二点，问题诊断要先对造成问题的根源进行逐层分解，分解到最后往往解决方案也就水落石出了，但是我们经常犯的一个错误是跳过了中间的结构化思维步骤，而直接去分析针对问题的解决方案，这是造成没有相互独立的重要原因。因为问题树分解的最后问题原因分支和解决问题方案之间往往是多对多的关系，一个解决方案有可能会是针对多个问题根源采取的措施。没有按照MECE的一个重要原因就是将问题根源的分解过程和问题的解决过程混合在了一起，跳过了中间的一些重要的问题原因分析的步骤。
第三点，旨在强调结构化思维不能代替系统思维，有时候不能简单的头痛医头，脚痛医脚。在问题树分解到最末枝的时候，各种原因之间往往存在着正负作用的相互影响。这就会造成当我们针对某一个原因制定解决方案的时候，会导致其他原因的恶化或出现新的问题和原因。脚的病往往医治好了但是头又开始痛了，你整个人仍然是一样的不舒服，病情仍然是没有改观。这也是针对MECE方法我们必须强调的一点，对于问题的分解是能够达到完整性和相互独立性，但是对于解决问题必须要考虑依赖性和相互影响，否则分解的再漂亮也不利于我们真正的解决问题。

IT运维工作报告

IT运维工作报告

为满足公司的快速发展，提升业务部门网络办公效率，提升it服务意识，it运维工程师按照sla协议承诺受理公司用户提交的it服务请求，包括用户使用网络、服务器、电脑终端及周边设备等设施过程中软硬件维护、事件处理、操作指导、资讯指导等，提供规范、稳定、持续、高质量的it可用资源和服务。

一、分担部门kpi指标,实现部门sla承诺

1、事件管理

a.通过主动积极服务或热线电话和邮箱受理等公司用户提交的it服务请求;

b.及时记录所有用户的事件，保证记录完整率达标;

c.在sla承诺的`时间内响应用户的事件，响应及时率达标;

d 对用户事件进行规范的分类、分级，并按事件级别不同要求进行响应和处理;

e.在承诺的时间内处理用户事件，或按规范传递给高一级技术支持，保证事件处理及时率达标;

f.合运用服务规范、沟通技巧和专业技能处理用户事件，并记录处理过程及方案，保证事件处理平均时间达标;

g.规范跟踪用户事件的处理进展，最终关闭事件或提交bug立项，保证事件解决率达标;

h.定期抽样回访用户和汇总用户意见，进行自我批判和持续改善用户满意度，保证用户满意度达标，用户投诉率在承诺范围以内;

i.承诺日平均事件处理数量，主动接管处理事件，高峰期需要灵活调整事件平均处理时长;

j.维值班人员按规范跟踪突发事件以及通报相关人员，保证跟踪正确率达标;

k.对本岗负责的事件跟踪处理，根据事件处理经验，提出合理化建议，将各类隐患消除在可控范围内;

l.养成良好工作习惯，做到事前有计划、事中有控制、事后有反馈、完成有记录;

2、配置管理

a.it资产配置管理：对it资产生命周期进行管理，包括分类统计、预购、选购审核、转移审核、报废审核，保证配置管理正确率达标;

b.建设案例库：累积和提炼工程师的事件处理经验制作成案例，并持续丰富运维案例库供查询，案例覆盖已知事件的比率达标，不断提高运维工程师工作效率;

c.it系统配置信息管理：定期更新网络及应用系统描述信息及技术支持信息配置，保证最新;

3、问题管理

a.对事件进行统计分析，找出疑难、重复发生的事件，纳入问题管理流程，分析问题产生的根本原因，确定可能解决的方案，需要修改网络或应用系统配置时提交变更申请触发变更管理流程。

4、发布管理

a.运维值班人员按规范统一发布信息部网络及应用系统正式公告、变更公告、特殊公告等，正确率达标;

二、其他运维工作

a.承担新员工导师工作，辅导新员工快速熟悉公司文化、环境、工作岗位及提升技能，为新员工顺利通过试用期提供保障;

b.持续反省自身的工作、总结工作中存在的不足和可改善之处，积极对部门运作提出改善建议;

c.积极参加公司重点应用项目的培训并按事件管理规范提供支持，如sap、oa系统等;

d.应部门发展需要在不影响现有工作的基础上主动承担其他项目支持，如网络、服务器，程控交换机等;

e.共享个人的技术经验，主持运维内部讲座;

f.积极参加信息部各类培训，有计划地进行自我学习，不断提升自身专业技能;

g.对重点维护设备进行定期巡检并记录，巡检及时率和正确率达标;

三、其他工作

a.担任it讲师，应其他部门邀请提供it技能培训，提高其他部门办公人员的it操作水平;

b.贯彻执行公司理念，积极完成上级分配的临时任务;

关于it运维事件分析和的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 it运维事件分析的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于、it运维事件分析的信息别忘了在本站进行查找喔。