运维故障处理思路

事件/故障处理应该要有什么思路

导读：

在讲解事件、故障处理思路前，我先讲一个故障场景（以呼叫中心系统作为一例子)：

业务人员反映呼叫中心系统运行缓慢,部份电话在自助语言环节系统处理超时,话务转人工座席，人工座席出现爆线情况。

运维人员开始忙活了，查资源使用情况、查服务就是否正常、查日志就是否报错、查交易量还有没有……时间不知不觉得在敲键盘、敲键盘、敲键盘中过去，但就是原因还未定位。

经理过来了解情况：“系统恢复了吗?”、“故障影响就是什么？”、“交易中断了吗？”……

运维人员赶紧敲键盘，写sql,瞧交易量；敲键盘，写命令,瞧系统资源、情况……

最终,定位到问题原因就是其中一个功能没有控制返回数量，导致内存泄露。

针对这个故障，业务希望运维能否更快得解决故障得恢复,经理希望制定优化呼叫中心故障处理流程，做了以下几件事：

1.优先故障处理过程得时间——”能通过鼠标完成得工作,不要用键盘“

2.提前发现故障，加强监控-—“技术早于业务发现问题,监控不仅就是报

警,还要协助故障定位”

3.完善故障应急方案——“应急方案就是最新得、准确得、简单明了得"

4.长远目标:故障自愈—-”能固化得操作自动化，能机器做得让机器做“

下面将从故障常见得处理方法开始介绍,再从故障前得准备工作（完善监控、制定应急方案等方式)来解决经理提出得问题,并提出未来解决故障得想法。

1、常见得方法：

1)确定故障现象并初判问题影响

在处理故障前，运维人员首先要知道故障现象，故障现象直接决定故障应急方案得制定，这依赖于运维人员需要对应用系统得整体功能有一定得熟悉程度。

确认了故障现象后，才能指导运维人员初判断故障影响。

2）应急恢复

运维最基本得指标就就是系统可用性，应急恢复得时效性就是系统可用性得关键指标。

有了上述故障现象与影响得判断后,就可以制定故障应急操作，故障应急有很多,比如:

?服务整体性能下降或异常，可以考虑重启服务；

?应用做过变更，可以考虑就是否需要回切变更；

?资源不足,可以考虑应急扩容；

?应用性能问题，可以考虑调整应用参数、日志参数；

?数据库繁忙，可以考虑通过数据库快照分析,优化SQL;

?应用功能设计有误,可以考虑紧急关闭功能菜单；

?还有很多……

另外，需要补充得就是，在故障应急前，在有条件得情况需要保存当前系统场景,比如在杀进程前，可以先抓个CORE文件或数据库快照文件。

３)快速定位故障原因

?就是否为偶发性、就是否可重现

故障现象就是否可以重现,对于快速解决问题很重要，能重现说明总会有办法或工具帮助我们定位到问题原因,而且能重现得故障往往可能就是服务异常、变更等工作导致得问题.

但，如果故障就是偶发性得，就是有极小概率出现得，则比较难排查,这依赖于系统就是否有足够得故障期间得现场信息来决定就是否可以定位到总就是原因。

?就是否进行过相关变更

大部份故障就是由于变更导致，确定故障现象后,如果有应得变更,有助于从变更角度出现分析就是否就是变更引起,进而快速定位故障并准备好回切等应急方案.

?就是否可缩小范围

一方面应用系统提倡解耦,一支交易会流经不同得应用系统及模块；另一方面,故障可能由于应用、系统软件、硬件、网络等环节得问题。在排查故障原因时应该避免全面性得排查,建议先把问题范围缩小到一定程序后再开始协调关联团队排查.

?关联方配合分析问题

与第（3）点避免同时各关联团队同时无头绪得排查得同时,对于牵头方在缩小范围后需要开放得态度去请求关联方配合定位,而对于关联方则需要有积极配合得工作态度。

?就是否有足够得日志

定位故障原因,最常用得方法就就是分析应用日志，对运维人员不仅需要知道业务功能对应哪个服务进程，还要知道这个服务进程对应得哪些应用日志，并具备一些简单得应用日志异常错误得判断能力。

?就是否有coｒｅ或dｕmp等文件

故障期间得系统现场很重要,这个在故障应急前建议在有条件得情况下留下系统现场得文件，比如ＣORE＼DＵMP，或TRACＥ采集信息等，备份好一些可能被覆盖得日志等。

上述就是一般性得故障常见得方法，在重大故障或多方处理得故障出现时，往往小范围得排查不利于快速解决，需要启动紧急处理得流程，建议可以考虑以下沟通:

?召集相关人员

?描述故障现状

?说明正常应用逻辑流程

?陈述变更

?排查进展,展示信息

?领导决策

２、完善监控

1）从监控可视化上完善

完善得监控策略需要有统一得可视化操作界面,在制定完善得监控策略后,故障处理人员需要能够快速得瞧到相应得运行数据，比如：能够瞧到一段时间得趋势、故障期间得数据表现、性能分析得情况等等数据，且这些数据可以提前制定好策略直接推出分析结果给故障处理人员，这样就大大提高了故障得处理效率,以呼叫中心系统为例,需要提前配置好以下实时交易数据,以便故障定位：

-交易性能数据:平均交易耗时、系统内部模块交易耗时(IVR交易耗时、接口总线交易耗时）、关联系统交易耗时（核心交易耗时、工单系统交易耗时等）

-重要交易指标数据:交易量、IＶR交易量、话务量、座席通话率、核心交易笔数、工单等系统交易量

－交易异常情况数据：交易成功率、失败率、错误码最多交易

－按服务器分析交易数据:按sｅｒver统计各服务交易处理笔数,交易总耗时

有了以上交易数据，并通过监控按一定频率统计，运维人员在出现故障时,通过鼠标即点击即可瞧到故障什么时候开始,就是系统内部有问题还就是关联系统有问题，最突出得交易就是哪一支,各服务器交易量就是否均衡等情况。

2）从监控面上完善

监控最基本得工作就就是实现对负载均衡设备、网络设备、服务器、存储设备、安全设备、数据库、中间件及应用软件等IT资源得全面监控管理。在应用软件类得监控工作中,不仅需要有服务进程、端口等监控，还需要有业务、交易层得监控。

全面性得应用监控可以让故障提前预警，并保存了影响应用运行环境得数据,以缩短故障处理时间。

３)从监控告警上完善

完善得监控策略需要有清晰得监控告警提示，值班人员要以根据监控告警即可作出简单得问题定位与应急处理方案。比如类似以下得监控短信：

２2时,【理财应用系统】中【应用服务器ＬC＿APＰｓvｒA 10、2、1１１、11１】得【前置应用模块】出现【应用端口:9０8０】不存在，该端口作用【提供理财应用处理(负载均衡部署）】，原因可能为【SERVＥＲ1服务异常停止】,监控系统己进行以下应急处理【自动执行端口进程启动】,该事件紧急程度【高】。

管理员可以通过短信内容瞧到哪个系统、哪个应用、哪个模块出了什么问题，可能就是什么原因，对业务有什么影响,就是否需要马上处理（比如凌晨出现此预警就是否可以延迟到次日处理）等信息.

4）从监控分析上完善

完善得监控策略不仅需要有实时得数据告警，也要有汇总数据得分析告警，实时数据分析得告警得重要性不用多说，对于汇总分析得数据则能发现潜在风险,同时也为分析疑难杂症提供帮忙。

5)从监控主动性上完善

监控不仅仅就是报警,它还可以做得更多，只要我们想办法赋予它主动解决事件得规则,它便有为管理员处理故障得能力。

3、应急方案

提前制定好故障应急方案就是很有必要得,但在日常工作过程中我们得应急方案遇到一些问题：

１）应急方案缺乏持续维护，缺乏演练，信息不及时、不准确；

2)应急方案过于追求大而全,导致不利于阅读与使用；

３）应急方案形式大于实际使用效果，方案针对性不强；

4)只关注应急方案得内容,但没有关注运维人员对方案得理解;

针对上述常见问题,我认为应急方案需要做到以下几点:

1）内容精＆简

很多人可能会认为故障出现得形式各种各样，所以应急方案需要涉及到方方面面。但实际得故障处理过程中，我们可以发现其实我们得应急措施往往重复使用几个常用得步骤,所以我认为应急方案要有重点，如果一个应急方案可以应对平时故障处理80％得场景，那这个应急手册应该就是合格得。过于追求影响应用系统方方面面得内容,会导致这个方案可读性变差，最终变更一个应付检查得文档。以下就是我觉得应用系统应急方案应该有得内容:

(１）系统级：

能知道当前应用系统在整个交易中得角色，当前系统出现问题或上下游出现问题时，可以知道如何配合上下游分析问题,比如：上下游系统如何通讯，通讯就是否有唯一得关键字等。

另外,系统级里还涉及一些基本应急操作，比如扩容、系统及网络参数调整等.

（2)服务级:

能知道这个服务影响什么业务,服务涉及得日志、程序、配置文件在哪里,如何检查服务就是否正常,如何重启服务,如何调整应用级参数等。

（3）交易级:

能知道如何查到某支或某类交易出现了问题，就是大面积、局部,还就是偶发性问题，能用数据说明交易影响得情况，能定位到交易报错得信息。这里最常用得方法就就是数据库查询或工具得使用。

知道最重要得交易如何检查就是否正常,重要得定时任务得应急处理方案,比如开业、换日、对账得时间要求及应急措施。

（4）辅助工具得使用:

有时候,需要借助一些工具或自动化工具辅助分析并应急，这时需要有辅助工具

如何使用得方法.

(５)沟通方案:

沟通方案涉及通讯录，包括上下游系统、第三方单位、业务部门等渠道。

(６）其它:

上述５点内容如何都完备，相信这个应急手册己可以解决80％得故障恢复工作. 2）应急方案就是一项持续得工作

有了应急方案，如何让运维人员持续去更新就是难点。我认为要解决这个难

点，需要先让运维人员经常使用这个手册。如果一个手册没有场景可以用，那

就需要管理者为运维人员创造机会去使用这个手册，比如应急演练。

３）关注运维人员对应用关键信息得认识

前两点关注了手册,最后一点我觉得有必要关注使用这个手册得人。有些运维人员认为应用运维人员没有能力去把应用系统本身得内容了解得很透彻,所以应用运维人员在故障处理过程中得地位很尴尬,运维人员掌握操作权,但却不知道应

该操作什么。

对此,我认同应用运维人员不需要掌握应用系统得业务功能,但我觉得就对应用

系统本身来讲应用运维人员需要具备以下最基本得能力：

（1）知道应用系统这个就是干什么得,基本得业务就是什么；

(２）知道应用架构部署、上下游系统逻辑关系;

（3）知道应用下得服务得作用、端口、服务级得应急处理，日志等数据信息如

何找到并简单定位。

(4)知道应用系统重要得时间点及任务,比如开业、停业、换日、定时任务得时

间点以及如何判断这些任务就是否正确

（５）知道最重要得几支交易得流程;

(6)知道常见数据库表结构,并能使用。

4、智能化事件处理

处理方法如下图（详细得智能化涉及监控、规则引擎、配置工具、CMDB、应用

配置库等模块协同工作，具体介绍后续分析）

计算机网络故障处理与维护方法(毕业论文)

五年制高职商贸信息专业毕业论文 计算机网络故障处理与维护方法 班级 姓名 学号 指导老师

目录 【摘要】 (1) 一、计算机网络故障的分类 (1) （一）计算机网络物理故障 (4) （二）计算机网络逻辑故障 (3) 二、计算机网络常见故障的处理 (1) （一）本地连接断开 (1) （二）本地连接收限制或无连接 (1) （三）本地连接正常，但浏览器无法连接网页 (1) 三、如何加强网络的维护 (1) （一）概括的说，应做到： (4) （二）具体来说，应该做到： (3) 四、结论 (8) 【参考文献】 (3)

计算机网络故障处理与维护方法 【摘要】 本文就网络中常见故障进行分类，针对各种常见网络故障提出相应的解决方法，并就如何加强网络的维护进行了概括论述。 网络出现故障是极普遍的事，其种类也多种多样，在网络出现故障时对出现的问题及时进行维护，以最快的速度恢复网络的正常运行，掌握一套行之有效的网络维护理论方法和技术是至关重要的。 【关键词】 网络故障分类处理维护 一、计算机网络故障的分类 计算机网络故障主要是指，用户在使用计算机网络过程中或网络在运行过程中出现的问题，导致计算机网络不能正常使用。通常计算机网络故障可以按照其故障的性质，分为物理故障和逻辑故障。 （一）物理故障： 物理故障也就是硬件故障，一般是指网络设备或线路损坏、接口松动、线路受到严重干扰，以及因为人为因素导致的网络连接错误等情况。出现该类故障时，通常表现为网络断开或时断时续。物理故障主要包括： （1）线路故障

线路故障的发生率在日常的网络维护中非常高，约占发生网络故障的60％～70％。线路故障包括线路的损坏和线路受到严重干扰。 （2）接口故障 接口故障通常包括插头松动和端口本身的物理损坏。如：双绞线RJ45接头的损坏。 （3）交换机或路由器故障 交换机或路由器故障在这里是指设备出现物理损坏，无常工作，导致网络不能正常运行的情况。 （4）网卡故障 网卡也称网络适配器，大多安装在计算机的主机部。通过主机完成配置和。网卡故障主要包括网卡松动、主机网卡插槽故障、网卡本身物理故障等。 （二）逻辑故障： 逻辑故障也称为软件故障，主要是指软件安装或网络设备配置错误所引起的网络异常。与硬件故障相比，逻辑故障往往要复杂得多。常见的网络逻辑故障有：主机逻辑故障、进程或端口故障、路由器故障等。 （1）主机逻辑故障 主机逻辑故障通常包括网卡驱动程序、网络通信协议或服务安装不正确、网络地址参数配置有误等。对计算机网络用户来讲，该类故障是十分常见的网络故障之一。 （2）进程或端口故障 进程或端口故障是指一些有关网络连接的进程或端口由于受到病毒或系统

故障管理及故障处理流程规定

故障管理和故障处理流程规定 (暂行稿) 工程运维中心 二〇〇八年八月 目录 第一章目的 (3)

第二章工程运维中心在95013业务维护管理中的职责 (3) 第三章 95013业务故障分类 (3) 第四章故障处理的原则: (4) 第五章故障处理时限要求。 (4) 第六章故障管理和故障报告制度 (4) 第七章故障通报制度 (5) 第八章故障处理及报告流程图 (5) 第九章工程运维中心内部处理流程 (6) 第十章外部支持流程(研发、建设和其他厂家） (6) 第十一章工程运维中心各部门及公司相关部门的责任 (7) 第十二章故障的跟踪管理 (7) 附件一：95013业务重大/严重故障分析报告 (9) 第一章目的 工程运维中心承担95013业务网络和平台日常维护工作，为规范故障管理和故障处理的工作流程，使网络和平台故障能够得到正确及时地处理，保证 95013业务安全稳定的运行，特制定本规定。

第二章工程运维中心在95013业务维护管理中的职责 a）工程运维中心网管中心值班工程师和各分公司运维人员承担95013业务的日常运行监控和维护工作。 b）工程运维中心运维组负责95013平台的故障处理；各地分公司运维人员负责现场支持，并负责协调当地运营商的运维支持。 c）建立故障通报制度，如发生重大故障，应按照故障等级和故障上报流程逐级向上汇报。 d）定期召开网络质量分析会，遇有重大故障，应及时召开故障分析会。 负责全公司运维人员的技术业务培训，提高运维人员的技术维护水平和工作能力。 第三章 95013业务故障分类 95013业务系统和网络故障分为重大故障、严重故障和一般故障。 1.重大故障：全部业务中断 2.严重故障包括： 一种以上业务全部中断≥60分钟 一省以上业务全部中断≥60分钟 用户注册、业务受理全部中断≥4个小时 3.一般故障：除重大故障、严重故障以外的其它故障。 第四章故障处理的原则：

网络运行维护及机房应急方案计划

网络运维小组应急预案 随着网络信息化建设的不断深入，加强机房各类设备、系统以及信息与网络安全等方面应对突发事件的处理能力将是我们目前面临的一项重要任务。为确保系统及机房安全与稳定，以保证正常运行为宗旨，按照“预防为主，积极处置”的原则，本着建立一个有效处置突发事件，建立统一指挥、职责明确运转有序、反应迅速处置有力的机房安全体系的目标，将正在发生或已发生事故的损害程度减轻到最低，确保员工安全，特制定本应急处置预案。 本预案共分为应用系统故障应急流程和机房突发事件应急流程 系统故障应急流程 一、系统故障应急流程说明 1、故障发生 系统运维服务小组可从以下途径得知故障的发生： 1.1、运维服务中心通过网管告警发现故障 1.2、维护站点通过维护巡检发现故障 1.3、用户发现故障，报给呼叫中心 1.4、驻场工程师发现故障 2、报障受理 监控系统运维服务小组得知系统故障发生后，立即响应，并向报障人或单位详细了解系统故障情况。 3、信息研判 运维服务小组根据了解到的系统故障情况进行分析判断，以确定采用一般故障处理流程还是立即启动系统突发故障应急处理预案。 4、预案启动 如需启动应急预案，则立刻通知系统突发故障应急领导小组，由领导小组启动应急预案，对系统突发故障应急事件进行全面管控处理。 5、资源确认

系统突发故障应急预案启动后，首先是根据现场突发故障实际状况、紧急程度、技术难度、备品备件等情况对相关资源（主要是参与人员）依据经验进行调度和确认，主要有以下资源： 我公司技术支持人员； 相关厂家技术支持人员； 我公司聘请的技术专家 6、预案执行 按照既定的预案进行突发故障抢修，如遇到问题及时向系统突发故障应急领导小组汇报。 7、预案终止 预案的终止时间由故障现场技术人员根据现场的实际进展情况，在与用户单位有关部门协调后报系统突发故障应急领导小组决定。 8、结果上报 预案中止后，相关预案参与人员将整个事件过程中的经验和教训，修改、完善事件应急预案。然后集中上报至系统突发故障应急领导小组。

运维故障处理思路 (3)

事件／故障处理应该要有什么思路 导读： 在讲解事件、故障处理思路前，我先讲一个故障场景(以呼叫中心系统作为一例子): 业务人员反映呼叫中心系统运行缓慢,部份电话在自助语言环节系统处理超时,话务转人工座席,人工座席出现爆线情况。 运维人员开始忙活了,查资源使用情况、查服务是否正常、查日志是否报错、查交易量还有没有……时间不知不觉的在敲键盘、敲键盘、敲键盘中过去，但是原因还未定位。 经理过来了解情况:“系统恢复了吗?”、“故障影响是什么?”、“交易中断了吗？”…… 运维人员赶紧敲键盘，写ｓql,看交易量；敲键盘,写命令，看系统资源、情况…… 最终,定位到问题原因是其中一个功能没有控制返回数量，导致内存泄露。 针对这个故障，业务希望运维能否更快的解决故障的恢复，经理希望制定优化呼叫中心故障处理流程,做了以下几件事: 1.优先故障处理过程的时间-—”能通过鼠标完成的工作,不要用键盘“ 2.提前发现故障,加强监控——“技术早于业务发现问题,监控不仅是报警, 还要协助故障定位” 3.完善故障应急方案——“应急方案是最新的、准确的、简单明了的” 4.长远目标:故障自愈——”能固化的操作自动化,能机器做的让机器做“ 下面将从故障常见的处理方法开始介绍，再从故障前的准备工作（完善监控、制定应急方案等方式)来解决经理提出的问题，并提出未来解决故障的想法。 １、常见的方法： １)确定故障现象并初判问题影响 在处理故障前,运维人员首先要知道故障现象,故障现象直接决定故障应急方案的制定,这依赖于运维人员需要对应用系统的整体功能有一定的熟悉程度。 确认了故障现象后，才能指导运维人员初判断故障影响。 2)应急恢复

网络运维方案

网络运维方案-CAL-FENGHAI-(2020YEAR-YICAI)_JINGBIAN

1服务体系 1.1总体原则和基本措施 1.1.1我公司在提供服务时要根据辽宁XX的服务需求情况和要求，遵循下 述基本原则： 以保证辽宁XX业务系统稳定正常为目标，全力保障所维护设备的正常 运行为最高指导原则 统一组织管理和调度针对本服务项目的技术资源，保证在客户需要时 能提供符合要求的人员和设备支持 以单一的接口保证双方的沟通能够简捷有效，并易于落实责任 建立快速响应机制，保证在特殊情况下，能够通过快速机制提供响应 通过责任到人、过程监控制等保证服务的效率和质量 1.1.2我公司采取如下主要措施： 采取7×24小时轮流值班制度，保障客户问题能在第一时间得到响 应； 采用问题升级制度，即在响应不到位或问题难以尽快解决的情况下， 将问题升级给更高级别的技术管理层。 根据辽宁XX的需要和知识产权的许可与辽宁XX共享与本项目服务相 关的部分技术信息资源。 通过我公司客户服务系统管理服务请求的登录和服务过程的监控等， 通过对过程记录文档的审计总结保证服务质量和服务过程改进。 1.1.3我公司与国内各大运营商有长期的合作关系，在沈阳本地设有分支机 构。我公司与本合同的维保设备原厂家具有一定的合作和授权关系。

1.1.4在项目实施后，我公司项目组与客户技术人员协商，制定出更合理的 资源配置方案。 1.2服务组织和人员 1.2.1公司人员 1.2.1.1我公司技术服务人员应有设备厂家的技术资格认证和多年维 护客户设备类型的工作经验，并根据客户设备种类、数量、分布、服务 要求，配备足够人员。我公司应有经过认证的专业技术服务人员可以作 为本项目的储备力量，当有紧急事情需要协助时，可以随时进行调配。 1.3备件管理 1.3.1在本地拥有专业的售后服务部门和备件库，配备有较强的技术支持和 服务资源，我公司能够利用这些资源对辽宁XX提供良好的快速响应和支持。 1.3.2我公司提供本项目维保设备相关的备件库、备品备件清单、所在地情 况和提供服务情况，备件库情况要求能随时接受检查。 1.3.3如需进行备件更换，须提供原厂商配件，不得使用假冒伪劣配件等。 发生硬件损坏时，应根据服务级别尽快提供备件以便及早解决故障。服务商须保证备件来自合法渠道。 1.4服务方式 1.4.1要求我公司提供包含并不限于如下服务方式： 7x24小时响应。 远程技术支持。 现场技术支持。

IT运维手册故障及处理

IT运维手册 第二篇硬件篇 一计算机章 ㈤常见问题 1主机 ⑴无法正常开机 ①硬盘灯亮 多为显示器或LCD排线问题，可插入系统引导盘看有无反应，若无反应，则为硬件问题，建议售后处理；若有反应，则为软件问题，可重装系统。 ②硬盘灯不亮 I电源问题 需更换电源和电池，多为电源适配器或电池损坏造成的提供电压不稳。可更换同型号电源线，排查故障。 II内存问题 拔插内存条或更换插槽。可能是内存条松动或自配内存条不兼容造成，若因不兼容，可通过更改BIOS设置解决。 III灰尘问题 笔记本长期不清洗，积压过多灰尘会造成静电或短路，可拆开外壳用吹风机清理灰尘。 IV主板问题 主板问题是造成不能开机最大可能因素，主板为集成电路，任何地方损坏都会造成硬盘无法通电，从而不能开机，建议去售后处理。 ⑵无法正常上网

①网络设置问题 此原因较多出现于需手动指定IP、网关、DNS服务器联网方式下，及使用代理服务器上网的，应仔细检查计算机的网络设置。 ②DNS服务器的问题 I当IE无法浏览网页时，可先尝试用IP地址来访问，如果可以访问，则为DNS的问题，造成DNS的问题可能是联网时获取DNS出错或DNS服务器本身问题，可手动指定DNS服务（地址可以是当地TSP提供的DNS服务器地址，也可用其它地方可正常使用DNS服务器地址。在网络的属性里进行（控制面板-网络和拨号连接-本地属性-TCP/IP协议-属性-使用下面的DNS服务器地址）。不用的ISP有不同的DNS地址。有时候则是路由器或网卡的问题，无法与ISP的DNS服务连接，这种情况可重启路由器或重新设置路由器。 II本地DNS缓存出现问题，为提高网站访问速度，系统会自动将已经访问过并获取IP地址的网站存入本地DNS缓存里，一旦继续访问此网站，则不再通过DNS服务器而直接从本地DNS缓存取出该网站的IP地址进行访问。所以，如果本地DNS缓存出现问题，会导致网站无法访问。可以在“运行”中执行ipconfig /flushdns来重建本地DNS缓存。 ③IE浏览器本身的问题 IE浏览器本身出现故障或IE被恶意修改破坏都会导致无法浏览网页，可尝试用上网助手“IE修复专家”来修复或者重装IE浏览器。 ④网络防火墙问题 如果网络防火墙设置不当，如安全等级过高、不小心把IE放进了阻止访问列表、错误的防火墙策略等，可尝试检查策略、降低防火墙安全等级或直接关掉试试是否恢复正常。

运维常见问题详细解决方案

运维工作及常见解决方案

1.概述 1.1编写目的 编写本解决方案的目的是对运维人员在遇到问题的时候提供一个可参考的依据。运维人员以此解决方案作为今后在运维工作中遇到相同问题的一个指南和依据，指导运维人员如何去解决类似问题。也为新来运维人员熟悉运维工作。本解决方案主要从问题类型、问题描述和解决方案等方面进行说明。 1.2适用范围 适用于运维人员、新来运维人员及相关人员。 2.运维工作流程 ?客户打找运维服务，接到电话，先判断是由运维做还是的 人做； ?运维分机号为1，，先记录房间号，报修时间，服务开始时 间，故障现象及记录接线人。 ?负责人先想解决方法，告知运维人员大体方向，运维人员 根据了解的情况想解决方案，在去见客户的时候知道如何 操作； ?负责人给运维人员派工单，运维人员去执行； ?执行完之后跟负责人交待此次工作结果；

?回复，双方接收 ?每周的运维工作数据及运维工作报告的电子档须在下周一 十点前发送到负责人邮箱中。 3.运维工作内容 1)终端软件维护 2)网络调整 3)电话调整 4)机房巡检 5)服务器操作：应用系统包括安全系统、移动执法系统、备份系 统、机房监控系统；网络设备包括交换机、路由器、防火墙、 流量控制系统。 6)机房清洁 7)空调维护 8)其他 4.常见问题解决方案 4.1电脑装应用软件的步骤 新台式机和笔记本： ●装OFFRICE，正版序列号为 ●杀毒软件

●360安全卫士，修复系统漏洞，点击修复，在安装路径中产生 一个hotfix文件夹，然后把工具中的hotfix文件夹里面所有文 件拷贝到安装路径下的hotfix文件夹； ●装常用的工具：Wara,暴风影音，Adobe,QQ,MSN,以及用户要求 的免费软件 旧电脑： ●IP设置，每次都要记录IP，在用完之后把IP设置为原来的IP ●旧机器在装系统之前，我的文档及桌面上的文件要备份，用U 盘拷贝出来再装系统（要特别注意财物室的机器重装系统， 在装系统之前还需要把C盘里面的某些文件给拷贝出来） 注意事项： 1.不装克隆XP 2.不安装盗版软件 4.2常见问题类型 4.2.1打印机

运维故障处理思路

事件/故障处理应该要有什么思路 导读: 在讲解事件、故障处理思路前,我先讲一个故障场景(以呼叫中心系统作为一例子): 业务人员反映呼叫中心系统运行缓慢,部份电话在自助语言环节系统处理超时,话务转人工座席,人工座席出现爆线情况。 运维人员开始忙活了,查资源使用情况、查服务就是否正常、查日志就是否报错、查交易量还有没有……时间不知不觉的在敲键盘、敲键盘、敲键盘中过去,但就是原因还未定位。 经理过来了解情况:“系统恢复了不？”、“故障影响就是什么？”、“交易中断了不？”…… 运维人员赶紧敲键盘,写sql,瞧交易量;敲键盘,写命令,瞧系统资源、情况…… 最终,定位到问题原因就是其中一个功能没有控制返回数量,导致内存泄露。 针对这个故障,业务希望运维能否更快的解决故障的恢复,经理希望制定优化呼叫中心故障处理流程,做了以下几件事: 1.优先故障处理过程的时间——”能通过鼠标完成的工作,不要用键盘“ 2.提前发现故障,加强监控——“技术早于业务发现问题,监控不仅就是报 警,还要协助故障定位” 3.完善故障应急方案——“应急方案就是最新的、准确的、简单明了的” 4.长远目标:故障自愈——”能固化的操作自动化,能机器做的让机器做“ 下面将从故障常见的处理方法开始介绍,再从故障前的准备工作(完善监控、制定应急方案等方式)来解决经理提出的问题,并提出未来解决故障的想法。 1、常见的方法: 1)确定故障现象并初判问题影响 在处理故障前,运维人员首先要知道故障现象,故障现象直接决定故障应急方案的制定,这依赖于运维人员需要对应用系统的整体功能有一定的熟悉程度。 确认了故障现象后,才能指导运维人员初判断故障影响。 2)应急恢复

运维故障处理思路

事件/故障处理应该要有什么思路 导读： 在讲解事件、故障处理思路前，我先讲一个故障场景（以呼叫中心系统作为一 例子）： 业务人员反映呼叫中心系统运行缓慢，部份电话在自助语言环节系统处理超时，话务转人工座席，人工座席出现爆线情况。 运维人员开始忙活了，查资源使用情况、查服务是否正常、查日志是否报错、 查交易量还有没有……时间不知不觉的在敲键盘、敲键盘、敲键盘中过去，但 是原因还未定位。 经理过来了解情况：“系统恢复了吗？”、“故障影响是什么？”、“交易中 断了吗？”…… 运维人员赶紧敲键盘，写sql，看交易量；敲键盘，写命令，看系统资源、情况…… 最终，定位到问题原因是其中一个功能没有控制返回数量，导致内存泄露。 针对这个故障，业务希望运维能否更快的解决故障的恢复，经理希望制定优化 呼叫中心故障处理流程，做了以下几件事： 1.优先故障处理过程的时间——”能通过鼠标完成的工作，不要用键盘“ 2.提前发现故障，加强监控——“技术早于业务发现问题，监控不仅是报 警，还要协助故障定位” 3.完善故障应急方案——“应急方案是最新的、准确的、简单明了的” 4.长远目标：故障自愈——”能固化的操作自动化，能机器做的让机器做 “ 下面将从故障常见的处理方法开始介绍，再从故障前的准备工作（完善监控、 制定应急方案等方式）来解决经理提出的问题，并提出未来解决故障的想法。 1、常见的方法： 1）确定故障现象并初判问题影响 在处理故障前，运维人员首先要知道故障现象，故障现象直接决定故障应急方 案的制定，这依赖于运维人员需要对应用系统的整体功能有一定的熟悉程度。

确认了故障现象后，才能指导运维人员初判断故障影响。 2）应急恢复 运维最基本的指标就是系统可用性，应急恢复的时效性是系统可用性的关键指标。 有了上述故障现象与影响的判断后，就可以制定故障应急操作，故障应急有很多，比如： 服务整体性能下降或异常，可以考虑重启服务； 应用做过变更，可以考虑是否需要回切变更； 资源不足，可以考虑应急扩容； 应用性能问题，可以考虑调整应用参数、日志参数； 数据库繁忙，可以考虑通过数据库快照分析，优化SQL； 应用功能设计有误，可以考虑紧急关闭功能菜单； 还有很多…… 另外，需要补充的是，在故障应急前，在有条件的情况需要保存当前系统场景，比如在杀进程前，可以先抓个CORE文件或数据库快照文件。 3）快速定位故障原因 是否为偶发性、是否可重现 故障现象是否可以重现，对于快速解决问题很重要，能重现说明总会有办法或 工具帮助我们定位到问题原因，而且能重现的故障往往可能是服务异常、变更 等工作导致的问题。 但，如果故障是偶发性的，是有极小概率出现的，则比较难排查，这依赖于系 统是否有足够的故障期间的现场信息来决定是否可以定位到总是原因。 是否进行过相关变更 大部份故障是由于变更导致，确定故障现象后，如果有应的变更，有助于从变 更角度出现分析是否是变更引起，进而快速定位故障并准备好回切等应急方案。 是否可缩小范围 一方面应用系统提倡解耦，一支交易会流经不同的应用系统及模块；另一方面，故障可能由于应用、系统软件、硬件、网络等环节的问题。在排查故障原因时 应该避免全面性的排查，建议先把问题范围缩小到一定程序后再开始协调关联 团队排查。 关联方配合分析问题

故障管理系统及故障处理流程规定

故障管理和故障处理流程规定 (暂行稿) 工程运维中心 二〇〇八年八月 目录 第一章目的 (3)

第二章工程运维中心在95013业务维护管理中的职责 (3) 第三章 95013业务故障分类 (3) 第四章故障处理的原则: (4) 第五章故障处理时限要求。 (4) 第六章故障管理和故障报告制度 (4) 第七章故障通报制度 (5) 第八章故障处理及报告流程图 (5) 第九章工程运维中心部处理流程 (6) 第十章外部支持流程(研发、建设和其他厂家） (6) 第十一章工程运维中心各部门及公司相关部门的责任 (7) 第十二章故障的跟踪管理 (7) 附件一：95013业务重大/严重故障分析报告 (9) 第一章目的 工程运维中心承担95013业务网络和平台日常维护工作，为规故障管理和故障处理的工作流程，使网络和平台故障能够得到正确及时地处理，保证 95013业务安全稳定的运行，特制定本规定。 第二章工程运维中心在95013业务维护管理中的职责

a）工程运维中心网管中心值班工程师和各分公司运维人员承担95013业务的日常运行监控和维护工作。 b）工程运维中心运维组负责95013平台的故障处理；各地分公司运维人员负责现场支持，并负责协调当地运营商的运维支持。 c）建立故障通报制度，如发生重大故障，应按照故障等级和故障上报流程逐级向上汇报。 d）定期召开网络质量分析会，遇有重大故障，应及时召开故障分析会。 负责全公司运维人员的技术业务培训，提高运维人员的技术维护水平和工作能力。 第三章 95013业务故障分类 95013业务系统和网络故障分为重大故障、严重故障和一般故障。 1.重大故障：全部业务中断 2.严重故障包括： 一种以上业务全部中断≥60分钟 一省以上业务全部中断≥60分钟 用户注册、业务受理全部中断≥4个小时 3.一般故障：除重大故障、严重故障以外的其它故障。 第四章故障处理的原则： 先抢通，后修复；先核心，后边缘；先本端，后对端；先网，后网外，分故障等级进行处理。 第五章故障处理时限要求。 1. 重大故障，故障处理时限≤2小时。

运维外包服务方案

运维外包服务方案 一、资产管理 1、维护设备/终端资产管理 对维护目标系统、设备、模块进行资产登记及相关配置信息的整理和记录 2、网络设备拓扑管理 掌握目标维护系统各个网络的拓扑结构，包括路由配置、vlan 划分、端口使用、IP 规划、设备位置等信息的资料设备维保信息管理 对目标维护系统的网络设备、板卡、安全设备、终端、IP 电话、视频监控的硬件以及软件维保信息、厂家维护人员等管理 二、文档管理 1、配置文档维护和管理 1) 《墙插或地插信息点与配线架端口对应表》及《配线架端口与交换机端口对应表》 2) 《网络系统连接图》 3) 《设备间链路端口表》 4) 《接入终端IP 子网表》(此表含L2 VLAN-ID 属性)、

5) 《设备链路IP 子网表》(此表含L2 VLAN-ID 属性) 6) 《设备管理IP 子网表》 2、设备使用手册管理 针对维护的硬件设备、软件系统整理用户操作手册，形成规范化的配置文档，对实际操作经验进行总结和积累，逐步提高自身对相关系统、设备的维护能力。 3、设备资料信息维护和管理 建立ITRMS 资源管理平台，对所维护的的设备、板卡等硬件设备建立“机历卡”进行详细资 料的管理，包括：设备详细配置、上线时间、故障记录等等进行记录。 三、设备监控 1. 监控系统部署 部署专业的设备监控软件，实现对相关网络设备、信息安全设备、终端、排队机、IP 电话 等设备的7*24 小时监控，并提供短信、邮件等告警信息，及时发现及处理设备网络故障。 2. 网络流量监控 结合相关的网络流量监控设备和软件，监控网络整体流量情况，对异常情况进行告警和处理； 3. 信息安全设备监控 定期检查防火墙、上网行为管理设备日志和策略，及时了解和发现异常安全事件，并及时进行处理和加固。

计算机网络几种典型故障的处理及维护方法

计算机网络几种典型故障的处理及维护方法 摘要网络故障极为普遍，网络故障的种类也多种多样，要在网络出现故障时及时对出现故障的网络进行维护，以最快的速度恢复网络的正常运行，掌握一套行之有效的网络维护理论、方法和技术是关键。就网络中常见故障进行分类，并对各种常见网络故障提出相应的解决方法。 关键词网络故障网络维护分类解决办法 随着计算机的广泛应用和网络的日趋流行，功能独立的多个计算机系统互联起来，互联形成日渐庞大的网络系统。计算机网络系统的稳定运转已与功能完善的网络软件密不可分。计算机网络系统，就是利用通讯设备和线路将地理位置不同的、信息交换方式及网络操作系统等共享，包括硬件资源和软件资源的共享：因此，如何有效地做好本单位计算机网络的日常维护工作，确保其安全稳定地运行，这是网络运行维护人员的一项非常重要的工作。 在排除比较复杂网络的故障时，我们常常要从多种角度来测试和分析故障的现象，准确确定故障点。 一、分析模型和方法 (一)七层的网络结构分析模型方法 从网络的七层结构的定义和功能上逐一进行分析和排查，这是传统的而且最基础的分析和测试方法。这里有自下而上和自上而下两种思路。自下而上是：从物理层的链路开始检测直到应用。自上而下是：从应用协议中捕捉数据包，分析数据包统计和流量统计信息，以获得有价值的资料。 (二)网络连接结构的分析方法 从网络的连接构成来看，大致可以分成客户端、网络链路、服务器端三个模块。 1、客户端具备网络的七层结构，也会出现从硬件到软件、从驱动到应用程序、从设置错误到病毒等的故障问题。所以在分析和测试客户端的过程中要有大量的背景知识，有时PC的发烧经验也会有所帮助。也可以在实际测试过程中询问客户端的用户，分析他们反映的问题是个性的还是共性的，这将有助于自己对客户端的进一步检测作出决定。 2、来自网络链路的问题通常需要网管、现场测试仪，甚至需要用协议分析仪来帮助确定问题的性质和原因。对于这方面的问题分析需要有坚实的网络知识和实践经验，有时实践经验会决定排除故障的时间。 3、在分析服务器端的情况时更需要有网络应用方面的丰富知识，要了解服务器的硬件性能及配置情况、系统性能及配置情况、网络应用及对服务器的影响情况。 (三)工具型分析方法 工具型分析方法有强大的各种测试工具和软件，它们的自动分析能快速地给出网络的各种参数甚至是故障的分析结果，这对解决常见网络故障非常有效。 (四)综合及经验型分析方法靠时间、错误和成功经验的积累 在大多数的阿络维护工作人员的工作中是采用这个方法的，再依靠网管和测试工具迅速定位网络的故障。 二、计算机无法上网故障排除 1、对于某台联网计算机上不了网的故障，首先要分别确定此计算机的网卡安装是否正确，是否存在硬件故障，网络配置是否正确在实际工作中我们一般采用Ping本机的回送地址(127.0.0.1)来判断网卡硬件安装和TCP/IP协议的正确性。 如果能Ping通，即说明这部分没有问题。如果出现超时情况，则要检查计算机的网卡

运维必备制度 故障分级和处罚规范

运维必备制度故障分级和处罚规范 作者简介 唐文，《海量运维、运营规划之道》一书作者，关于海量运维、运营规划，我想业界都没有准确的定义，假如说互联网的架构师用能否设计多高的摩天大楼来衡量架构能力，那运维、运营更多的是在关注互联网服务的质量、效率、成本、故障、瓶颈，用户的忍耐、抱怨等问题。 在接下来的日子里，将以质量、效率、成本为核心，从运营规划、管理、流程/规范、系统/平台，监控、告警、安全、优化、考核等几个维度结合案例来与大家分享自己的体会，内容大致如下所示。 编者按：一个好的制度是可操作、可执行的，不是高高挂起的。每个公司情况不同，制度需要定期根据公司自身情况进行适当修改，以下文章算是一个制度的模板，仅供参考，要想使用肯定还需要修改。 正文 互联网产品提供7*24小时服务，而因人为操作、程序Bug等原因导致服务不可用是影响服务持续运行的重要原因，为了提高各业务产品的运维和运营质量，规范各业务线的服务、故障响应，拟定和发布“故障分级和处罚规范”是非常必要的。 故障分级标准 运营故障中，对非不可抗力所造成的故障归类为“故障”，对于故障将追究故障的分级，故障责任人，及故障处理结果。下面将就各类故障级别进行定义说明，由于故障可能在多方面体现影响，所以故障的综合等级评定原则，取各个方面中严重等级最高者为该故障综合严重等级，故障分级如下所示。 故障分级表 故障奖惩制度 运营故障处理评定是根据相关责任人对故障的响应、处理、完成结果等因素来对故障的处理情况进行综合评定，部门内会依据这个评定来对故障处罚等级进行调整。该评定只用于由部门内决定的故障处罚分级，公司的处罚条例不受此约束。符合下面条件者，可以对故障处罚等级进行适当降级，具体所降等级由部门领导决定，故障升级制如下所示。 故障升级制度表 对于所出现的各级运营故障，如果运营故障的主要原因由人为工作疏忽/失误所导致，参照以下处罚标准对个人和项目组进行相关惩处，任何运营故障，要及时通报相关领导或相关处理人员，对于延报、瞒报故障者，将从严处罚，故障分级及处罚如下所示。 故障分级表

网络运维方案完整版

网络运维方案 HEN system office room 【HEN16H-HENS2AHENS8Q8-HENH1688】

1服务体系1.1总体原则和基本措施 1.1.1我公司在提供服务时要根据辽宁XX的服务需求情况和要求，遵循下述基 本原则： 以保证辽宁XX业务系统稳定正常为目标，全力保障所维护设备的正常运行 为最高指导原则 统一组织管理和调度针对本服务项目的技术资源，保证在客户需要时能提 供符合要求的人员和设备支持 以单一的接口保证双方的沟通能够简捷有效，并易于落实责任 建立快速响应机制，保证在特殊情况下，能够通过快速机制提供响应 通过责任到人、过程监控制等保证服务的效率和质量 1.1.2我公司采取如下主要措施： 采取7×24小时轮流值班制度，保障客户问题能在第一时间得到响应； 采用问题升级制度，即在响应不到位或问题难以尽快解决的情况下，将问 题升级给更高级别的技术管理层。 根据辽宁XX的需要和知识产权的许可与辽宁XX共享与本项目服务相关的 部分技术信息资源。 通过我公司客户服务系统管理服务请求的登录和服务过程的监控等，通过 对过程记录文档的审计总结保证服务质量和服务过程改进。 1.1.3我公司与国内各大运营商有长期的合作关系，在沈阳本地设有分支机 构。我公司与本合同的维保设备原厂家具有一定的合作和授权关系。 1.1.4在项目实施后，我公司项目组与客户技术人员协商，制定出更合理的资 源配置方案。 1.2服务组织和人员 1.2.1公司人员 1.2.1.1我公司技术服务人员应有设备厂家的技术资格认证和多年维护客 户设备类型的工作经验，并根据客户设备种类、数量、分布、服务要求， 配备足够人员。我公司应有经过认证的专业技术服务人员可以作为本项目 的储备力量，当有紧急事情需要协助时，可以随时进行调配。

网络运维的紧急故障处理及对策

网络运维的紧急故障处理及对策

导读：为了提高广大初入此行的网管读者们的紧急故障处理水平，故策划了本文，将这几年来的经验撰写出来，与读者分享管理思路和控制管理能力的思维。 随着信息化进程的飞速发展，网络已经成为每个现代企业必须的要素之一。相对于网络维护，网络运维更加侧重于保障网络系统的正常运行，运维有运行和维护两层含义。对于一个系统，有时出错我们无法预知，系统越复杂，其难维护难度更大，为了减少损失，我们尽可能地去预防各种错误，对于突发情况，尽可能地去修复。 紧急故障解决的通用流程 在本文开始前，笔者先给出紧急故障解决的流程图，见图一。

图一 根据上述流程图，我们可以一目了然明白处理网络运维的紧急故障的处理流程。

当客户端发生网络中断的故障后，首先判断用户（或终端）到三层网关设备之间通道是否存在问题，从用户（或终端）上ping 网关是否能通，用户（或终端）自身是否发生问题。 二层网络是否正常：如果用户（或终端）ping网关不通，则检查下端二层网络、用户网线、三层网关设备以下网线或光纤是否正常，端口是否UP，是否有CRC error报文统计。检查二层网络中的交换机设备是否能正常学习到用户MAC地址，检查三层网关设备与二层交换设备之间的连通性、二层设备的CPU利用率是否正常，是否有二层环路造成或病毒攻击。首先确保用户（或终端）能正常ping通网关设备。 三层网络是否正常：可以通过telnet/console口登陆三层设备，如果有问题，通过ping、tracert、show logging、端口统计、CPU利用率统计、链路状态、路由表状态、MPLS标签表状态等对问题进行分析，在业务忙时，不得擅自重启或倒换三层核心路由器等设备。 如果用户上网或承载业务仍然存在故障，可以查看DNS等外界环境是否正常，承载的业务本身是否发生问题，查看相关告警，然后做出相应的处理。 其它问题，如果现场不能解决，就通报关键用户并联系厂商解决。

运维常见问题详细解决方案

运维常见问题详细 解决方案

运维工作及常看法决方案

1.概述 1.1编写目的 编写本解决方案的目的是对运维人员在遇到问题的时候提供一个可参考的依据。运维人员以此解决方案作为今后在运维工作中遇到相同问题的一个指南和依据，指导运维人员如何去解决类似问题。也为新来运维人员熟悉运维工作。本解决方案主要从问题类型、问题描述和解决方案等方面进行说明。 1.2适用范围 适用于运维人员、新来运维人员及相关人员。 2.运维工作流程 ?客户打找运维服务，接到电话，先判断是由运维做还是 的人做； ?运维分机号为1，，先记录房间号，报修时间，服务开 始时间，故障现象及记录接线人。 ?负责人先想解决方法，告知运维人员大致方向，运维人 员根据了解的情况想解决方案，在去见客户的时候知道 如何操作； ?负责人给运维人员派工单，运维人员去执行； ?执行完之后跟负责人交待此次工作结果；

?回复，双方接收 ?每周的运维工作数据及运维工作报告的电子档须在下周 一十点前发送到负责人邮箱中。 3.运维工作内容 1)终端软件维护 2)网络调整 3)电话调整 4)机房巡检 5)服务器操作：应用系统包括安全系统、移动执法系统、备份 系统、机房监控系统；网络设备包括交换机、路由器、防 火墙、流量控制系统。 6)机房清洁 7)空调维护 8)其它 4.常见问题解决方案 4.1电脑装应用软件的步骤 新台式机和笔记本： ●装OFFRICE，正版序列号为 ●杀毒软件

●360安全卫士，修复系统漏洞，点击修复，在安装路径中产 生一个hotfix文件夹，然后把工具中的hotfix文件夹里面 所有文件拷贝到安装路径下的hotfix文件夹； ●装常见的工具：Wara,暴风影音，Adobe,QQ,MSN,以及用户要 求的免费软件 旧电脑： ●IP设置，每次都要记录IP，在用完之后把IP设置为原来的 IP ●旧机器在装系统之前，我的文档及桌面上的文件要备份，用 U盘拷贝出来再装系统（要特别注意财物室的机器重装系 统，在装系统之前还需要把C盘里面的某些文件给拷贝出 来） 注意事项： 1.不装克隆XP 2.不安装盗版软件 4.2常见问题类型 4.2.1打印机

设备运维故障处理表 ln

3G设备运维故障处理表

3G运维故障（TD） 故障处理流程一般包括四个阶段：信息收集、原因分析、定 位和排除。 故障现象： 从RNC侧观察到站点相关的接口单板上指示灯告警，从B328侧观察到IIA板的ALM灯红亮、红闪。 故障原因分析： RNC、B328或传输设备中，任何1种设备有问题都会导致传输断。 故障处理方法： （1）检查RNC到B328的线路是否正常。 （2）用自环判断传输是否正常，必须双向环回。即从RNC侧环回，检查B328指示灯是否正常；从B328侧环回，检查RNC侧的指示灯是否正常。 （3）如果无法明显判断线路哪一段出现问题，则将RNC到B328的线路分成若干段，从RNC最近的一段开始进行自环测试，如果告警消失，接着进行下一段自环测试，如果又出现告警，则可以把故障定位在这一段。 故障现象：

后台观测到RNC和B328之间链路时断时通。 故障原因分析： 可能存在帧失步告警、19.44 M时钟告警、同步或信元定界丢失，这些都会产生传输误码。故障处理方法： （1）检查传输布线是否符合要求。 （2）检查站点、DDF架、RNC和传输的接地是否良好。 （3）从RNC开始逐段对E1线路（或光纤）进行自环并且检测E1线路（或光纤）误码是否异常，如果异常，那么问题就出在该段，请对该段连接线或连接设备进行更换。 （4）使用传输测试仪器来进行传输指标测试。 故障现象： RNC和B328之间的NCP链路中断告警，用户不能接入。 故障原因分析： 某站点的NCP链路断，可能有以下原因。 （1）IIA板或与之相连的光纤或E1 线出现硬件故障。

（2） BCCS 硬件故障 （3） RNC 侧硬件故障。 （4） 传输故障。 故障处理方法： （1） 检查RNC 和B328中NCP 链 路的VPI/VCI 等相关配置是否一致。 （2） 查看传输有无告警，如有告警， 先解决传输问题。如果传输正常，按以下步骤继续排查。 （3） 检查该B328内IIA 板是否有告 警，如果是，按以下步骤排查。 ● 检查E1线（或光纤）是否连接正 确。 ● 检查RNC 中Iub 接口板是否有告 警，如有告警，排除相应故障。 ● 检查传输是否故障，用误码仪测量 传输的误码情况，如果误码率异常，则排查传输故障，包括传输设备、接地等故障情况。 ● 如果问题依然存在，则更换IIA 板。 （4） 检查该B328内BCCS 板是否有 告警，如果是，按以下步骤处理。

运维故障处理思路

运维故障处理思路内部编号：（YUUT-TBBY-MMUT-URRUY-UOOY-DBUYI-0128）

事件/故障处理应该要有什么思路 导读： 在讲解事件、故障处理思路前，我先讲一个故障场景（以呼叫中心系统作为一例子）： 业务人员反映呼叫中心系统运行缓慢，部份电话在自助语言环节系统处理超时，话务转人工座席，人工座席出现爆线情况。 运维人员开始忙活了，查资源使用情况、查服务是否正常、查日志是否报错、查交易量还有没有……时间不知不觉的在敲键盘、敲键盘、敲键盘中过去，但是原因还未定位。 经理过来了解情况：“系统恢复了吗”、“故障影响是什么”、“交易中断了吗”…… 运维人员赶紧敲键盘，写sql，看交易量；敲键盘，写命令，看系统资源、情况…… 最终，定位到问题原因是其中一个功能没有控制返回数量，导致内存泄露。 针对这个故障，业务希望运维能否更快的解决故障的恢复，经理希望制定优化呼叫中心故障处理流程，做了以下几件事： 1.优先故障处理过程的时间——”能通过鼠标完成的工作，不要用键 盘“ 2.提前发现故障，加强监控——“技术早于业务发现问题，监控不仅 是报警，还要协助故障定位” 3.完善故障应急方案——“应急方案是最新的、准确的、简单明了 的” 4.长远目标：故障自愈——”能固化的操作自动化，能机器做的让机 器做“ 下面将从故障常见的处理方法开始介绍，再从故障前的准备工作（完善监控、制定应急方案等方式）来解决经理提出的问题，并提出未来解决故障的想法。 1、常见的方法：

1）确定故障现象并初判问题影响 在处理故障前，运维人员首先要知道故障现象，故障现象直接决定故障应急方案的制定，这依赖于运维人员需要对应用系统的整体功能有一定的熟悉程度。 确认了故障现象后，才能指导运维人员初判断故障影响。 2）应急恢复 运维最基本的指标就是系统可用性，应急恢复的时效性是系统可用性的关键指标。 有了上述故障现象与影响的判断后，就可以制定故障应急操作，故障应急有很多，比如： 服务整体性能下降或异常，可以考虑重启服务； 应用做过变更，可以考虑是否需要回切变更； 资源不足，可以考虑应急扩容； 应用性能问题，可以考虑调整应用参数、日志参数； 数据库繁忙，可以考虑通过数据库快照分析，优化SQL； 应用功能设计有误，可以考虑紧急关闭功能菜单； 还有很多…… 另外，需要补充的是，在故障应急前，在有条件的情况需要保存当前系统场景，比如在杀进程前，可以先抓个CORE文件或数据库快照文件。 3）快速定位故障原因 是否为偶发性、是否可重现 故障现象是否可以重现，对于快速解决问题很重要，能重现说明总会有办法或工具帮助我们定位到问题原因，而且能重现的故障往往可能是服务异常、变更等工作导致的问题。 但，如果故障是偶发性的，是有极小概率出现的，则比较难排查，这依赖于系统是否有足够的故障期间的现场信息来决定是否可以定位到总是原因。 是否进行过相关变更

运维服务方案

1运维服务方案 1.1运维服务承诺 如我公司中标，我公司作出如下承诺： 1、运维工作人员 1)我司针对本项目成立专门的运维团队和项目管理机构，负责保障服务期 内本项目安全、稳定地运行。我司明确运维团队组织、人员、岗位职责、 工作流程等，须建立详细的运维保障体系，并提供方案。 2)系统运维团队须具备安全防范系统工程设计、施工和维护能力。 3)系统运维团队须熟练掌握网络安全配置技术，包括网络及安全设备管理、 安全域划分、安全策略优化、防火墙配置、VPN管理技术。 4)系统运维团队须具备视频服务管理能力，精通各种视频监控设备与平台， 精通视频资源目录服务体系管理，精通各种可视调度系统设备维护。 2、巡检排故工作 1)对重点设备的维护工作，采取分工负责的措施；节假日期间，或有重要 的会议及有关活动期间，应专门安排值班，同时作好应急准备工作，必 要时安排专人在现场值班，以确保系统正常运行。 2)维护人员应围绕系统功能、系统的各项技术指标及操作运行情况，逐点、 逐台、逐项地进行检验，边检边进行记录，并排除发现的故障。 3、用户信息反馈及持续改进工作 1)建立客户意见反馈渠道，收集对维护工作的希望、要求和意见。 2)建立维护工作联系卡，提供公司相关部门负责人及维护工作人员联系电 话，保证与客户联系的畅通、维护工作的及时、有效。 3)每半年向用户送交《维护工作客户意见征询表》，收集对维护工作的意 见、要求和评议。 4)每维护年度对客户满意度作统计分析，提交书面报告 5)及时修正维护工作方案、方法及纠正维护工作的不足之处，回复客户的 意见和要求，提高维护工作质量和服务水平。 4、服务响应要求 (1)运营维护服务要求

运维应急故障处理方案

运维应急故障 处理方案 文件编码AQ2I-02-S001 版本V03 文件层级□一阶□二阶 ■三阶 文件类别 ■体系文件 □技术文件 编制部门运维部机密等级■内文□秘密□机密□绝密 编制人文件类别■通用□项目 审核编制日期 审批生效日期 总页数9 分发编号01 文件发布盖章

文件制/修订记录 页码章节制/修订记录 版本 修订人修订日期备注修订前修订后 全部全部首次制定无V01 2,3 4,5 职责/作业内容V01 V02 全部全部按新的角色职责 定义更新角色 V02 V03

1 目的 用于突发性事件发生后的应急处理措施，确保在紧急情况下仍能保证系统平台正常运行 2 适用范围 本程序适用于所有在系统平台运行过程中能事先预测到的非自然灾害所产生的突发性事件。 3 术语和定义 突发事件: 由于系统软件，硬件，接入线路，机房电力，温度等发生问题和突发意外，引起故障时间达30分钟以上，造成关键服务不可用，形成重大影响的事件。 4 职责 4.1运维工程师： 负责突发性事件应急处理计划和对策的拟定和执行。 4.2 平台研发部，移动应用部，客户服务部，服务营销部： 由部门负责人及相关人员共同处理突发性应急事件。 4.3质量管理工程师： 负责突发性事件应急处理计划和对策的监督执行。 5 作业内容

5.1突发事件分类和应急处理 5.1.1 基础设施环境不可用 包括运营商网络割接、机房电力、空调、线路接入等基础设施出现故障，且影响时间高于30分钟的。 对于运营商已告知问题原因时处理方案： 1.提前通知相关运营人员和客户服务部 2.通告影响时间，影响范围 3.公告用户 4.调整域名解析，启用容灾机房 对于运营商未告知问题原因时处理方案： 1.紧急联络机房接口人 2.了解故障原因，和影响时间，评估影响范围 3.紧急公告，启用预案同已知问题处理 5.1.2 设备不可用 服务器硬件故障、交换机及防火墙等网络设备发生故障，且影响时间高于30分钟的故