第一篇:《家客》建设、接维、故障、投诉处理方案
家宽建设、接维、故障、投诉处理流程
一、整体说明
1、交接时间点和原则
⑪2015年1月1日网络管理部接手。
⑫之前走投资费用的工程在2015年3月前全部完工。⑬走投资费用的家宽工程仍由工程建设部负责。
⑭省计划部要求:2015年3月,采用投资费用建设全部结束,未完成的退回费用。
2、集成服务商
⑪集成服务内容包括施工、设计。⑫采购设计服务,审核集成商设计。
3、集成服务商招标
⑪本着“责、权、利”对等原则,省公司明确家宽接入工程集成服务商招标职责下放地市公司。
⑫拟定2015年2月14日前完成集成服务商(施工、设计)招标。
4、工程过程管理
⑪省计划部原则上同意省网络管理部使用现有投资管控平台作为项目管理手段。省网络管理部与信息支撑部沟通,对现有投资管控平台进行改造。
⑫平台改造完成后将立即下发告知。
5、集成服务商招标
⑪本着“责、权、利”对等原则,省公司明确家宽接入工程集成服务商招标职责下放地市公司。
⑫拟定2015年2月14日前完成集成服务商(施工、设计)招标。
6、工程过程管理
⑪省计划部原则上同意省网络管理部使用现有投资管控平台作为项目管理手段。省网络管理部与信息支撑部沟通,对现有投资管控平台进行改造。
⑫平台改造完成后将立即下发告知。
二、流程
1、提出需求
操作要求
⑪家客建设需求上报依据
① 市公司五网协同批量需求。
② 县市分公司客户绝对需求。③ 各个县市公司根据营销情况,发起需求。⑫物业协调
① 客户经理为物业协调主体。
② 建立“能者协调”奖励机制,不局限施工单位独立负责。③ 目前省公司还没有明确协调费用,明确后立即下发告知。
⑬提出需求
客户经理洽谈成功后,提出需求。需求部门填写附件一:《**家庭宽带工程勘察设计委托需求表》,将该附件以邮件形式提交给所属建维中心。
⑭资源核查
① 所属建维中心负责核查资源。
② 核查内容包括:是否具备分纤点、管道及引入光缆距离。③ 无分纤点、管道或引入光缆距离超过1公里,按优先级排序发给计划建设部、网络部。由计划建设部列入滚动规划中。
⑮需求提出注意事项
① 需求部门根据资源核查情况,将具备资源的按优先级排序后,交给设计院进行勘察设计;
② 单端口造价是否符合省公司要求; ③ 投资回收期是否小于5年; ④ 端口覆盖率是否符合省公司要求;
⑤ 审核小区接入对周边的资源覆盖辐射效应;
⑯上报建设小区数量时间点 ① 3月1日前上报全年40%建设量。② 5月1日前上报全年30%建设量。③ 7月1日前上报全年20%建设量。④ 10月1日前上报全年10%建设量。
⑰考核原则
为了避免盲目提出需求,提高需求准确性。采用后评估机制,评估投入产出比、均匀度、流失率,纳入公司领导班子KPI考核中。
⑱批复原则
对于投入产出比较低的,需要公司领导决策。
2、勘察设计
操作要求 ⑪设计单位选择
① 市分公司依据相关法规、省公司相关采购管理办法自行采购; ② 走成本费用采购,以集成服务形式进行采购,由省网络管理部负责制定技术规范、考核办法等内容,由集采中心负责下发相关采购指导意见。
③ 拟定2015年2月14日前完成设计单位招标。
⑫勘察设计
① 勘察设计人员组成:县建维中心、设计单位、施工单位、需求部门。
② 设计人员制作方案,勘察组其它成员参与方案制作。③ 方案制作完毕后客户经理需要找客户签署《中国移动小区宽带网络接入协议书》,一式四份,村屯或小区物业公司两份,所属分公司、网络部各一份。
④ 客户未签署《中国移动小区宽带网络接入协议书》,不允许上报建设需求,该项目流失。
⑤ 方案制作完毕后,分公司以请示汇报形式上报市公司集客部和网络部(传输室、客响室)审核。
⑥ 方案审核未通过将驳回分公司重新设计,重新设计的方案仍未通过该项目流失。
勘察设计模板.doc
⑬启动投资管理平台
请示汇报流程流转完毕后,在收到流程结束阅知文件的0.5个工作日内启动投资管理平台单项工程。
3、工程施工
操作要求 ⑪施工单位选择
① 市公司依据相关法规、省公司相关采购管理办法自行采购; ② 家宽接入工程费用以集成服务形式列支到网络成本费用中,集成费用包括施工。由省网络管理部负责下发技术规范、考核办法、份额调整办法等文件,集采中心下发相关采购指导意见; ③ 拟定6个标段
标段1:中国移动通信集团设计院有限公司;
标段2:广东省电信规划设计院有限公司;
标段3:黑龙江中移通信技术工程公司;
标段4:吉林吉大通信设计院股份有限公司; ④ 拟定2015年2月14日前完成施工单位招标。⑤ 招标完成后立即签署安全生产责任状。
⑫工程施工
① 根据招标结果,标段内家宽接入项目由中标单位实施。② 施工单位必须设内页人员,与移动公司接口。
③ 施工单位施工前必须取得相应的土地、公路使用租赁合同。
④ 施工安排:建维中心按照市公司批复的需求设计方案,制定施工计划,启动施工。
⑤ 农村宽带建设涉及杆路安装整体时限为20天。⑥ 市区宽带建设整体时限为15天 ⑦ 工程施工前施工单位携带建设方案到需求部门报道,需求部门沟通业主后通知施工单位进场施工。(备注:涉及引电时间依据电业部门时间为准)。
⑧ 计划建设部要考虑家客项目建设配套工程提前启动,防止配套工程影响主体项目竣工。⑲工程施工必须符合《中国移动集团客户及宽带接入(客户侧)工程施工工艺标准》要求。
中国移动集团客户及宽带接入(客户侧)
4、工程管控
操作要求 ⑪工程管控
① 分公司负责属地工程管控,按照施工计划推进完工。包括施工、网络资源调配、工程余料管理,网络部协助管控。
② 施工单位内页人员通过微信定期(每周一、三、五)发布信息(**小区开工时间、进度、涉及直埋光缆发布多个不同地点埋深照片、设备安装位置照片、标签照片、接地照片、熔纤盘照片,光缆接入照片,是否竣工、是否通过验收、未通过整改方案、计划、通过后是否交维、是否已经报账、工人工资发放录像。
③ 分公司核实施工单位发布信息的正确性。对不正确的信息及时纠正。
④ a、非客观原因造成1个小区或村屯超期,影响施工进度,超期5天以内,提出警告,超期10天以上按合同约定考核2000.00元。b、非客观原因累计造成2个小区或村屯超期,影响施工进度,按合同约定考核 6000.00元。
c、非客观原因累计造成3个小区或村屯超期,影响施工进度,影响业务发展的,将调整标段内的施工量,由其它施工单位实施一部分。
⑤ 施工单位未按《中国移动集团客户及宽带接入(客户侧)工程施工工艺标准》标准施工,工程管控人员有权要求其停工整改,拒不整改约谈中标单位经理并上报网络部。
⑥ 约谈后仍不改变的,分公司上报网络部,经公司领导同意后,根据采购合同约定,在黑河移动公司内将不予许实施家宽接入工程。
⑦ 网络部将不定期检查家宽项目,发现问题要求施工单位整改,同时警告分公司。2次考核分公司1分,3次考核分公司2分,以此类推。
⑫资源录入
① 工程建设完成后,施工单位将“家客自建/合建小区资源信息表”填好后发给马晶(联系电话:***,邮箱:***@139.com)和网络部客响室孙桐丽(邮箱:suntongli@hl.chinamobile.com)。马晶2个工作日内完成资源录入工作。
② 马晶录入结束后,网络部在1个工作日内完成资管录入审核工作。
5、工程调测
操作要求 家宽项目调测
⑪家宽项目调测由网络部统一实施。
⑫调测总调度人为:李庆丰,联系电话***。⑬施工单位定期发布工程进度,分公司、施工单位提前与调测总调度人联系,避免联系不及时影响整改工期。
⑭网络部调测人员根据施工单位发布的照片完整性和质量,纤芯测试数据及分公司工程管控人员的描述,有权决定是否调测(未达到要求拒绝调测)。
6、验收接维
操作要求 ⑪验收接维
① 调测人员调通设备后,按《中国移动宽带小区接入工程验收测试表》完成相应的测试工作。
② 调测人员通过“家客自建/合建小区资源信息表”与现场信息核对,核对通过后,通知分公司立即组织验收。
③ 验收人员组成:建维中心、需求部门、施工单位、代维单位、网络部(现场调测人员)。
④ 施工单位和网络部调测人员共同提供资料《××家客项目验收资料》
⑤ 现场验收未通过,施工单位立即整改。并根据合同约定考核施工单位2000.00元。
⑥ 现场验收通过,现场填写《初验报告》和《工程验收交接书》。
⑦ 现场验收通过,施工单位、网络部将《中国移动宽带小区接入工程验收测试表》、《××家客项目验收资料》、《初验报告》和《工程验收交接书》交给代维单位。
⑧ 与代维单位交接材料后填写《家客验收接维确认单》。
⑨代维单位立即接维,并粘贴贴心服务卡。⑩需求部门通知放号。
7、工程决算开支
交维后先付60%,3个月后终验再付40%。
8、装机
操作要求
⑪提高代维装机费用
① 经测算农村装一部有线宽带75元(不含材料费,我公司提供材料),农村装一部无线宽带95元(含材料费,代维单位自供),市区装一部有宽线带45.21元(不含材料费,我公司提供材料)。
② 代维装机
代维单位通过“综合网络资源管理系统”接收装机工单,根据工单并依照【黑龙江移动家庭宽带业务上门服务规范】上门装机。
③ 代维单位未按【黑龙江移动家庭宽带业务上门服务规范】上门装机,将根据代维管理办法进行考核。
⑫探索代维装机新模式
在距离市区偏远的地点,代维单位通过与当地移动代办点合作,由当地代办点负责所属区域的装机、维护等工作。
9、质量管控 操作要求 质量管控:
⑪制定《监控表》;
⑫家宽开通及时率=预约及时率*0.4+业务开通及时率*0.6故障处理分析;
⑬家宽用户报障修复及时率=及时处理申告工单数/形成工单的总家客业务申告总数*100%;
⑭探针质量监控; ⑮投诉服务分析;
10、故障和投诉
操作要求
⑪在建家客投诉处理:
市公司服务质量管理部负责接听客户申告故障电话,涉及在建工程引发的投诉,服务质量管理部直接将工单派至分公司投诉管理人员,同时在“黑河家客信息交互群”中发布。问题解决完成后,分公司直接回单,最后由服务质量管理部完成客户回访工作。
⑫接维后故障、投诉处理:
a.市公司服务质量管理部负责接听客户申告故障电话,通过代维管理信息《通用任务工单》下发到对应区县代维单位故障处理接单人,抄送网络部客户响应室。故障处理完成后,由代维单位直接回单,最后由服务质量管理部完成客户回访工作。
b.黑河传输室监控到家客设备故障直接派发代维单位,并在“黑河家客信息交互群”中发布信息,跟踪处理进度在群里反馈处理信息。
c.其它接到关于家客故障投诉,反馈所属建维中心或集客部,建维中心或集客部人员在“黑河家客信息交互群”中发布信息,代维单位收到后立即处理,并反馈结果。
11、整治与扩容
操作要求 整治与扩容
⑪各分公司有家宽整治与扩容需求,以邮件的形式发至网络部客响室,抄送分公司领导和网络部李章军主任,网络审核或现场勘察后给出整治方案和预算,经领导批示后,安排施工单位实施。
⑫家宽整治与扩容要考虑投资收益,因此投资收益非常低的整治与扩容方案将取消。
单位:网络管理部
日期:2015年01月
第二篇:重大故障及用户投诉处理办法
项目重大故障及用户投诉处理办法
北京神州泰岳软件股份有限公司
项目重大故障及用户投诉处理办法 总则
为加大管理力度,提高项目实施与维护工作的流程化和规范化,控制和减少各类项目事故和用户投诉的发生,保证项目质量,提升用户满意度,树立公司良好的用户形象,公司决定下发项目重大故障及用户投诉处罚管理办法,要求公司各事业部、各大区与分公司学习和贯彻执行。关于项目故障和用户投诉的级别
关于项目故障和用户投诉的级别,分为以下五级:
1.用户通报:指在用户内部公司层面进行公开通报。
2.重大投诉:指用户内部虽未公开通报,但用户向公司领导层进行书面或口头投诉、或者用户向销售、项目管理部和大区总经理进行书面投诉。
3.一般投诉:指用户内部虽未公开通报,但用户直接向销售、项目管理部和大区总经理进行口头投诉。
4.内部一级故障:指用户虽未投诉,但造成用户核心业务受到影响30分钟以上(含30分钟),包括用户业务中断、计费损失、重大保障不力和重大财产损失等。
5.内部二级故障:指用户虽未投诉,但造成用户业务受到影响而影响范围在30分钟以下或用户业务虽未受到影响但自身系统宕机或中断服务2小时以上的(含2小时)或公司资产受到重大损失或者项目上线后系统中重复发生宕机、中断服务不足2小时的重大故障。关于项目故障的责任认定
关于项目故障的责任认定,分为以下五种 项目重大故障及用户投诉处理办法
北京神州泰岳软件股份有限公司
1.低级失误:造成项目故障的原因在于责任人的操作失误或过失。2.管理问题:造成项目故障的原因在于责任人不遵守公司、部门和项目组的各类管理规范。
3.实施设计问题:造成项目故障的原因在于项目组的实施或设计方案(合同方案存在问题暂不属于项目组责任,但项目组有识别合同技术方案是否存在问题的责任和义务)。
4.产品问题:造成项目故障的原因在于项目中公司产品或第三方产品、设备自身存在问题,但当事人响应处理不及时、不到位。5.第三方因素:造成项目故障原因的在于第三方,但当事人响应处理不及时、不到位。关于用户投诉的原因
关于用户投诉的原因,分为以下五种:
1.项目故障:由于项目出现故障导致用户投诉,而故障的责任认定见第三部分的四类责任定义。
2.项目进度:由于项目进度存在问题导致用户投诉。3.项目质量:由于项目质量存在问题导致用户投诉。
4.项目管理能力和水平:由于项目管理能力和水平的问题导致用户投诉。
5.项目组服务态度和水平:由于项目组服务态度和水平的问题导致用户投诉。关于项目故障和用户投诉的通报机制
1.责任人(或第一知晓人)应在发现后第一时间立即通知项目经理(或维护类项目维护负责人,本办法中提到的项目经理统指项目经理或维护类项目维护负责人)。
2.项目经理在得知事件后应第一时间立即口头通知主管销售和事业部技术 项目重大故障及用户投诉处理办法
北京神州泰岳软件股份有限公司
总监或项目总监,在4个小时内负责向主管销售、行业经理、部门经理、技术总监、公司项目总监、大区项目总监、项目管理部、大区技术总监、大区总经理和事业部总经理进行邮件通报事故概况,并电话通知部门经理和行业经理。
3.对于除内部一般事故外的其他性质的项目事故,由技术总监或项目总监负责立即向公司CSO和CTO进行口头和邮件上报。
4.由销售受理的用户投诉,需及时通知项目经理进行跟进处理,并通知事业部主管项目领导和项目管理部。
5.由项目管理部受理的用户投诉,需及时通知项目经理、销售和事业部主管项目领导,由项目经理跟进处理。
6.由大区总经理受理的用户投诉,需及时通知主管销售,由主管销售及时通知项目经理、销售和事业部主管项目领导,由项目经理跟进处理,处理结果要上报大区总经理。
7.由公司领导层受理的用户投诉,可由公司领导层通知项目管理部,由项目管理部负责通知项目经理、主管销售和事业部总经理进行跟踪处理,处理结果要上报公司领导。关于项目故障和用户投诉的处理机制
1.项目经理为事故处理的第一责任人,由项目经理组织协调相关人员进行跟踪处理:控制事故影响,恢复受损系统和业务,最后进行事故分析、处理、汇报和总结。
2.项目经理需要会同项目组和事业部分析事故原因,给出解决办法、后续避免措施和本次事故的处理决定,生成故障分析报告。
3.故障分析报告报主管销售和项目总监(技术总监)协商确定;对于用户通报类事故和重大投诉,向用户提交的故障分析报告,需邮件向事业部总经理和公司CTO报批,并同时口头通知。
4.项目故障分析报告经审批后,由项目经理和主管销售向用户进行书面回复和正式口头汇报。项目重大故障及用户投诉处理办法
北京神州泰岳软件股份有限公司
5.由项目经理协调项目组总结故障原因与处理过程,形成项目事故案例库,上报给事业部质管部门。
6.事业部质管部门审定后向事业部内部进行全员发布,并把事故案例上报项目管理部。
7.项目管理部根据案例特点选择定向或向公司范围进行事故案例发布(发布案例的用户名、责任人等匿名处理),并由项目管理部整理汇总形成公司事故案例库。其中对于涉及公司产品问题,由项目管理部向产品管理及公共研发部进行通报。关于项目故障和用户投诉的处罚办法
7.1 处罚原则
1.差异化原则:依据故障级别和责任认定、投诉内容进行差异化处罚。其中:针对投诉内容不是“项目故障”的用户一般投诉,如果用户不做处罚的明确要求,第一次公司内部不做罚款处理,如果同一项目组再发生同类投诉则进行罚款处理。
2.责任共担原则:与项目事故和用户投诉相关的项目组和事业部人员或大区人员责任共担,依当事责任人归属技术事业部或大区进行责任共担,涉及人员包括:
1)相关当事人(归属事业部)→项目经理→事业部部二级部门经理(含行业经理)→部门技术总监(含项目总监)
2)相关当事人(归属大区)→项目经理→大区技术经理。
3.同类事故性质加罚原则:对于在公司事故案例库内发布的事故,如果重复发生处罚力度加罚一倍。
4.瞒报或不及时上报加重处罚原则:对于事故责任人和项目经理发生瞒报或不及时上报事故的,按照最高处罚标准进行处罚(即故障等级认定为由于低级错误导致的用户通报)。
5.项目经理岗位津贴罚没原则:依据故障级别和责任认定、投诉内容,决 项目重大故障及用户投诉处理办法
北京神州泰岳软件股份有限公司
定事故或用户投诉发生当月项目经理津贴是否罚没,如果需要罚没但当月已发的,则下月项目经理岗位津贴罚没(属于补罚)。
6.当事人与项目经理当期绩效降级或限级原则:依据故障级别和责任认定、投诉内容,对当事人及项目经理的当期绩效进行降级或限级。7.降低项目奖金标准原则:依据故障级别和责任认定、投诉内容,降低该项目项目奖金的标准。
8.累加原则:罚款和降低项目奖金标准的额度按照事故和用户投诉发生次数进行累加计算。
7.2 处罚标准
依据故障级别和责任认定、用户投诉内容决定责任人、项目经理、二级部门经理(含行业经理或大区技术经理)、部门技术总监(含项目总监)的处罚决定以及项目经理岗位津贴是否罚没、项目奖金基准折扣、当事人的绩效评定和事故通报范围等,具体处罚标准详见下表(附件:项目重大故障及用户投诉处罚标准.xlsx)。项目重大故障及用户投诉处理办法
北京神州泰岳软件股份有限公司
7.3 处罚执行机构
1.罚款:由事业部、大区和项目管理部联合执行。
1)由主管项目的事业部领导制定事业部内受罚当事人的罚款结果,涉及用户通报和重大投诉的处罚决定事业部需要与主管销售、公司CTO进行沟通确定,然后邮件通知当事人和项目管理部;由大区技术总监制定大区内受罚当事人的罚款结果,涉及用户通报和重大投诉的处罚决定需要与主管销售、公司CTO进行沟通确定,然后邮件通知当事人和项目管理部。
2)当事人到项目管理部进行书面签字或对处罚结果进行邮件确认(如果事业部或大区发出处罚邮件通知单后7个工作日内当事人不做邮件回复视作同意处罚决定),如果当事人不接受,可向事业部、大区或项目管理部提出邮件上诉,由事业部主管领导、大区技术总监和项目管理部协调处理。
3)项目管理部按月把处罚结果汇总报人力资源部执行。
2.通报:公司范围由项目管理部负责;事业部范围由事业部主管项目副总负责。项目重大故障及用户投诉处理办法
北京神州泰岳软件股份有限公司 名词释义
1.第一时间:含义为“从时间序列看为知道情况后的下一个动作(除非下一个动作能够立即避免故障影响扩大化)”。例如故障发生在凌晨2:00,甚至2:01就应该上报,而不是要等到上班时间(9:00)再上报。2.瞒报:含义是“知道故障发生,并且故障危害的容忍时间和规定的上报时限已过,而在公司知道前项目组还未上报”。
3.不及时:含义是“没有在规定和容许的时限内上报、响应或处理”。其中:不及时上报是指:“虽在公司知道前上报,但没有在规定和容许的时限内上报”。生效日期
本办法自发布之日起生效。
北京神州泰岳软件股份有限公司
2011年
第三篇:运维故障处理思路
事件/故障处理应该要有什么思路 导读:
在讲解事件、故障处理思路前,我先讲一个故障场景(以呼叫中心系统作为一例子):
业务人员反映呼叫中心系统运行缓慢,部份电话在自助语言环节系统处理超时,话务转人工座席,人工座席出现爆线情况。
运维人员开始忙活了,查资源使用情况、查服务是否正常、查日志是否报错、查交易量还有没有„„时间不知不觉的在敲键盘、敲键盘、敲键盘中过去,但是原因还未定位。
经理过来了解情况:“系统恢复了吗?”、“故障影响是什么?”、“交易中断了吗?”„„
运维人员赶紧敲键盘,写sql,看交易量;敲键盘,写命令,看系统资源、情况„„
最终,定位到问题原因是其中一个功能没有控制返回数量,导致内存泄露。针对这个故障,业务希望运维能否更快的解决故障的恢复,经理希望制定优化呼叫中心故障处理流程,做了以下几件事:
1.优先故障处理过程的时间——”能通过鼠标完成的工作,不要用键盘“ 2.提前发现故障,加强监控——“技术早于业务发现问题,监控不仅是报警,还要协助故障定位”
3.完善故障应急方案——“应急方案是最新的、准确的、简单明了的” 4.长远目标:故障自愈——”能固化的操作自动化,能机器做的让机器做“ 下面将从故障常见的处理方法开始介绍,再从故障前的准备工作(完善监控、制定应急方案等方式)来解决经理提出的问题,并提出未来解决故障的想法。
1、常见的方法:
1)确定故障现象并初判问题影响
在处理故障前,运维人员首先要知道故障现象,故障现象直接决定故障应急方案的制定,这依赖于运维人员需要对应用系统的整体功能有一定的熟悉程度。确认了故障现象后,才能指导运维人员初判断故障影响。2)应急恢复
运维最基本的指标就是系统可用性,应急恢复的时效性是系统可用性的关键指标。
有了上述故障现象与影响的判断后,就可以制定故障应急操作,故障应急有很多,比如:
服务整体性能下降或异常,可以考虑重启服务; 应用做过变更,可以考虑是否需要回切变更; 资源不足,可以考虑应急扩容;
应用性能问题,可以考虑调整应用参数、日志参数; 数据库繁忙,可以考虑通过数据库快照分析,优化SQL; 应用功能设计有误,可以考虑紧急关闭功能菜单; 还有很多„„
另外,需要补充的是,在故障应急前,在有条件的情况需要保存当前系统场景,比如在杀进程前,可以先抓个CORE文件或数据库快照文件。
3)快速定位故障原因
是否为偶发性、是否可重现
故障现象是否可以重现,对于快速解决问题很重要,能重现说明总会有办法或工具帮助我们定位到问题原因,而且能重现的故障往往可能是服务异常、变更等工作导致的问题。
但,如果故障是偶发性的,是有极小概率出现的,则比较难排查,这依赖于系统是否有足够的故障期间的现场信息来决定是否可以定位到总是原因。
是否进行过相关变更
大部份故障是由于变更导致,确定故障现象后,如果有应的变更,有助于从变更角度出现分析是否是变更引起,进而快速定位故障并准备好回切等应急方案。
是否可缩小范围
一方面应用系统提倡解耦,一支交易会流经不同的应用系统及模块;另一方面,故障可能由于应用、系统软件、硬件、网络等环节的问题。在排查故障原因时应该避免全面性的排查,建议先把问题范围缩小到一定程序后再开始协调关联团队排查。
关联方配合分析问题 与第(3)点避免同时各关联团队同时无头绪的排查的同时,对于牵头方在缩小范围后需要开放的态度去请求关联方配合定位,而对于关联方则需要有积极配合的工作态度。
是否有足够的日志
定位故障原因,最常用的方法就是分析应用日志,对运维人员不仅需要知道业务功能对应哪个服务进程,还要知道这个服务进程对应的哪些应用日志,并具备一些简单的应用日志异常错误的判断能力。
是否有core或dump等文件
故障期间的系统现场很重要,这个在故障应急前建议在有条件的情况下留下系统现场的文件,比如COREDUMP,或TRACE采集信息等,备份好一些可能被覆盖的日志等。
上述是一般性的故障常见的方法,在重大故障或多方处理的故障出现时,往往小范围的排查不利于快速解决,需要启动紧急处理的流程,建议可以考虑以下沟通:
召集相关人员 描述故障现状
说明正常应用逻辑流程 陈述变更
排查进展,展示信息 领导决策
2、完善监控
1)从监控可视化上完善
完善的监控策略需要有统一的可视化操作界面,在制定完善的监控策略后,故障处理人员需要能够快速的看到相应的运行数据,比如:能够看到一段时间的趋势、故障期间的数据表现、性能分析的情况等等数据,且这些数据可以提前制定好策略直接推出分析结果给故障处理人员,这样就大大提高了故障的处理效率,以呼叫中心系统为例,需要提前配置好以下实时交易数据,以便故障定位:
-交易性能数据:平均交易耗时、系统内部模块交易耗时(IVR交易耗时、接口总线交易耗时)、关联系统交易耗时(核心交易耗时、工单系统交易耗时等)-重要交易指标数据:交易量、IVR交易量、话务量、座席通话率、核心交易笔数、工单等系统交易量
-交易异常情况数据:交易成功率、失败率、错误码最多交易-按服务器分析交易数据:按server统计各服务交易处理笔数,交易总耗时 有了以上交易数据,并通过监控按一定频率统计,运维人员在出现故障时,通过鼠标即点击即可看到故障什么时候开始,是系统内部有问题还是关联系统有问题,最突出的交易是哪一支,各服务器交易量是否均衡等情况。
2)从监控面上完善
监控最基本的工作就是实现对负载均衡设备、网络设备、服务器、存储设备、安全设备、数据库、中间件及应用软件等IT资源的全面监控管理。在应用软件类的监控工作中,不仅需要有服务进程、端口等监控,还需要有业务、交易层的监控。
全面性的应用监控可以让故障提前预警,并保存了影响应用运行环境的数据,以缩短故障处理时间。
3)从监控告警上完善
完善的监控策略需要有清晰的监控告警提示,值班人员要以根据监控告警即可作出简单的问题定位与应急处理方案。比如类似以下的监控短信:
22时,【理财应用系统】中【应用服务器LC_APPsvrA 10.2.111.111】的【前置应用模块】出现【应用端口:9080】不存在,该端口作用【提供理财应用处理(负载均衡部署)】,原因可能为【SERVER1服务异常停止】,监控系统己进行以下应急处理【自动执行端口进程启动】,该事件紧急程度【高】。管理员可以通过短信内容看到哪个系统、哪个应用、哪个模块出了什么问题,可能是什么原因,对业务有什么影响,是否需要马上处理(比如凌晨出现此预警是否可以延迟到次日处理)等信息。
4)从监控分析上完善
完善的监控策略不仅需要有实时的数据告警,也要有汇总数据的分析告警,实时数据分析的告警的重要性不用多说,对于汇总分析的数据则能发现潜在风险,同时也为分析疑难杂症提供帮忙。
5)从监控主动性上完善
监控不仅仅是报警,它还可以做得更多,只要我们想办法赋予它主动解决事件的规则,它便有为管理员处理故障的能力。
3、应急方案
提前制定好故障应急方案是很有必要的,但在日常工作过程中我们的应急方案遇到一些问题: 1)应急方案缺乏持续维护,缺乏演练,信息不及时、不准确; 2)应急方案过于追求大而全,导致不利于阅读与使用; 3)应急方案形式大于实际使用效果,方案针对性不强; 4)只关注应急方案的内容,但没有关注运维人员对方案的理解; 针对上述常见问题,我认为应急方案需要做到以下几点:
1)内容精&简
很多人可能会认为故障出现的形式各种各样,所以应急方案需要涉及到方方面面。但实际的故障处理过程中,我们可以发现其实我们的应急措施往往重复使用几个常用的步骤,所以我认为应急方案要有重点,如果一个应急方案可以应对平时故障处理80%的场景,那这个应急手册应该是合格的。过于追求影响应用系统方方面面的内容,会导致这个方案可读性变差,最终变更一个应付检查的文档。以下是我觉得应用系统应急方案应该有的内容:(1)系统级:
能知道当前应用系统在整个交易中的角色,当前系统出现问题或上下游出现问题时,可以知道如何配合上下游分析问题,比如:上下游系统如何通讯,通讯是否有唯一的关键字等。
另外,系统级里还涉及一些基本应急操作,比如扩容、系统及网络参数调整等。(2)服务级:
能知道这个服务影响什么业务,服务涉及的日志、程序、配置文件在哪里,如何检查服务是否正常,如何重启服务,如何调整应用级参数等。(3)交易级:
能知道如何查到某支或某类交易出现了问题,是大面积、局部,还是偶发性问题,能用数据说明交易影响的情况,能定位到交易报错的信息。这里最常用的方法就是数据库查询或工具的使用。
知道最重要的交易如何检查是否正常,重要的定时任务的应急处理方案,比如开业、换日、对账的时间要求及应急措施。(4)辅助工具的使用:
有时候,需要借助一些工具或自动化工具辅助分析并应急,这时需要有辅助工具如何使用的方法。(5)沟通方案:
沟通方案涉及通讯录,包括上下游系统、第三方单位、业务部门等渠道。(6)其它:
上述5点内容如何都完备,相信这个应急手册己可以解决80%的故障恢复工作。
2)应急方案是一项持续的工作
有了应急方案,如何让运维人员持续去更新是难点。我认为要解决这个难点,需要先让运维人员经常使用这个手册。如果一个手册没有场景可以用,那就需要管理者为运维人员创造机会去使用这个手册,比如应急演练。
3)关注运维人员对应用关键信息的认识
前两点关注了手册,最后一点我觉得有必要关注使用这个手册的人。有些运维人员认为应用运维人员没有能力去把应用系统本身的内容了解得很透彻,所以应用运维人员在故障处理过程中的地位很尴尬,运维人员掌握操作权,但却不知道应该操作什么。
对此,我认同应用运维人员不需要掌握应用系统的业务功能,但我觉得就对应用系统本身来讲应用运维人员需要具备以下最基本的能力:(1)知道应用系统这个是干什么的,基本的业务是什么;(2)知道应用架构部署、上下游系统逻辑关系;
(3)知道应用下的服务的作用、端口、服务级的应急处理,日志等数据信息如何找到并简单定位。
(4)知道应用系统重要的时间点及任务,比如开业、停业、换日、定时任务的时间点以及如何判断这些任务是否正确(5)知道最重要的几支交易的流程;(6)知道常见数据库表结构,并能使用。
4、智能化事件处理
处理方法如下图(详细的智能化涉及监控、规则引擎、配置工具、CMDB、应用配置库等模块协同工作,具体介绍后续分析)
第四篇:代维故障处理规范
代维故障处理规范
为保证代维单位及时高效地处理故障,结合公司实际制定本规范。
一、故障分类
按照目前代维公司维护的界面分工,需要代维处理的故障主要分为基站设备故障(主要为动力配套设备)、基站停电故障、光缆线路故障(按线路级别分干线、本地网、接入网)、室内分布系统。
二、故障通知程序
1、基站设备故障
基站设备故障由网管中心值班人员通过监控系统发现通知基站代维管理员,并做好故障派单记录,基站代维管理员接到通知后应立即通知代维公司专业接口人,并做好故障记录督促代维公司在规定时间内修复障碍,代维公司未能在规定时间内修复障碍的,基站代维管理员应立即通知动力代维中心主任和部门分管经理。
2、基站停电故障
基站停电由网管中心值班人员通过动力环境监控系统发现通知基站代维管理员,并做好故障派单记录,基站代维管理员接到通知后应立即通知代维公司专业接口人,并做好故障记录督促代维公司在规定时间内修复障碍,代维公司未能在规定时间内修复障碍的,基站代维管理员应立即通知动力代维中心主任和部门分管经理。
3、光缆线路故障
干线光缆线路故障(含本地网骨干网线路)网管中心值班人员通知线路代维管理人员,同时通知传输中心值班工程师和传输中心主任,线路代维管理人员接到通知后应立即通知代维公司专业接口人,并向部门分管领导汇报,代维公司未能在规定时间内修复障碍的,网管中心值班人员应立即部门经理和公司分管领导。
本地网线路故障(本地网骨干网除外)网管中心值班人员通知线路代维管理人员,同时通知传输中心值班工程师和传输中心主任,线路代维管理人员接到通知后应立即通知代维公司专业接口人,并做好故障记录督促代维公司在规定时间内修复障碍,代维公司未能在规定时间内修复障碍的,线路代维管理员应立即通知动力代维中心主任和部门分管经理。
接入网线路故障由客响中心112故障专业人员和网管中心值班人员谁先发现谁通知客响中心值班工程师或县分装维人员,客响中心值班工程师(或县分装维人员)判断为线路故障应立即通知线路代维管理人员(网管中心值班人员若能直接判断线路故障可直接通知线路代维管理人员,并告知客响中心值班工程师),线路代维管理人员接到通知后应立即通知代维公司专业接口人,并做好故障记录督促代维公司在规定时间内修复障碍,代维公司未能在规定时间内修复障碍的,线路代维管理员应立即通知动力代维中心主任和部门分管经理。
4、室内分布系统
室内分布系统故障由网管中心值班人员通过监控系统发现通知基站代维管理员和无线中心主任,并做好故障派单记录,基站代维管理员接到通知后应立即通知代维公司专业接口人,并做好故障记录督促代维公司在规定时间内修复障碍,代维公司未能在规定时间内修复障碍的,基站代维管理员应立即通知动力代维中心主任和部门分管经理,网管中心值班人员应通知部门无线分管经理。
三、故障处理记录
1、对于基站设备和停电故障,代维单位每周汇总一次提交基站代维管理人员,对涉及到的抢修材料应做好台账登记。
2、对于线路故障,应在处理故障结束后24小时内提交故障处理记录。
四、故障处理支撑
对于已经交由代维单位处理的故障如不能及时抢通修复,运行维护部相应专业需派人到场进行指导和督促。对于影响业务的故障如代维单位不能在规定的抢修时限内完成,基站或线路代维管理人员应与相关专业工程师到场协助抢修。
五、故障归口及上报
所有涉及代维故障需第一时间通知到代维管理中心基站或线路代维管理人员,各专业工程师及县分工维中心工程师不得擅自调动代维人员,紧急情况下可先通知代维抢修人员后向代维管理中心报备。所有代维公司处理的故障由动力代维中心督促代维公司提交故障处理记录后向质量管理中心进行上报。
二○一二年一月十七日
第五篇: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放进了阻止访问列表、错误的防火墙策略等,可尝试检查策略、降低防火墙安全等级或直接关掉试试是否恢复正常。2显示器 ⑴无图像显示 ①开机无反应
I检查电脑的外部接线是否接好,把各个连线重新插一遍,看故障是否排除。
II如果故障依旧,接着打开主机箱查看机箱内有无多余金属物,或主板变形造成的短路,闻一下机箱内有无烧焦的糊味,主板上有无烧毁的芯片,CPU周围的电容有无损坏等。
III如果没有,接着清理主板上的灰尘,检查显卡等硬件是否有松动,然后检查电脑是否正常。IV如果故障依旧,则故障可能由内存、显卡、CPU、主板等设备引起。接着使用插拔法、交换法等方法分别检查内存、显卡、CPU等设备是否正常,如果有损坏的设备,更换损坏的设备。
②未检测到信号
台式机开机时键盘灯不亮、主机风扇正常运转,则多数属于链接线的问题,将电脑与主机间的链接线拔下后清理插头/孔的灰尘进行重试。⑵蓝屏
①首先了解发生蓝屏前电脑的情况及所做的操作。如果电脑在CPU或内存等超频后,出现蓝屏,则蓝屏故障与超频有关,只要将频率恢复正常即可。
②如果电脑在光驱读盘时被非正常打开导致蓝屏,则蓝屏故障是由于被误操作引起的,此故障一般将光盘重新放入光驱,再关上光驱托盘即可。
③如果电脑在带电插拔某设备时发生蓝屏,则蓝屏与带电插拔设备有关,一般重新启动电脑即可恢复。
④如果电脑在使用某一个应用程序软件时发生蓝屏,则蓝屏故障可能是由此程序软件引起的,一般将程序软件卸载,再重新安装即可排除故障;如果不行,则可能是程序软件本身有错误,不能使用。⑤如果电脑在进入系统后就出现蓝屏,引起蓝屏故障的原因可能较多,需要逐步进行排除。先用杀毒软件查杀病毒,排除病毒造成的蓝屏故障,如果故障排除,则是病毒造成的蓝屏故障。
⑥如果故障依旧,重新启动电脑,然后再用安全模式启动电脑,启动后退出系统再重新启动到正常模式,如果排除则是系统错误造成的蓝屏故障。二网络章 ㈡实际操作 2网络运维常用工具 ①驱动精灵
驱动精灵是一款集驱动管理和硬件检测于一体的、专业级的驱动管理和维护工具。驱动精灵为用户提供驱动备份、恢复、安装、删除、在线更新等实用功能。另外除了驱动备份恢复功能外,还提供了Outlook地址簿、邮件和 IE 收藏夹的备份与恢复。并且有多国语言界面供用户选择。
利用驱动精灵的驱动程序备份功能,在电脑重装前,将电脑中的最新版本驱动程序通通备份下载,待重装完成时,再试用它的驱动程序还原功能安装,便可节省驱动程序安装的时间。驱动精灵对于手头上没有驱动盘的用户十分实用,用户可以通过本软件将系统中的驱动程序提取并备份出来。②360硬件大师
360硬件大师是一款专业易用的硬件工具,准确的硬件检测可协助辨别硬件的真伪,并能准备提供中文的硬件名称,使电脑配置一目了然,防止在购买电脑的时候被奸商蒙骗。此外还具有温度监测、性能测试、一键电脑优化等功能。㈢常见网络问题及解决方案 1电脑安装网卡后启动速度降低
①TCP/IP设置中设置了“自动获取IP地址”,启动计算机时,计算机都会主动搜索当前网络中的DHCP服务器,所以计算机启动的速度会降低,这种情况可选择“指定IP地址”。
②安装太多网络通讯协议或服务,计算机启动时寻找和加载程序时间加长。可在本地连接的属性中删除不必要的协议和服务,对局域网的一般应用而言,有TCP/IP协议,MICROSOFT网络用户,MICROSOFT网络的文件和打印机三个网络组建即可。2网络中的某台计算机挪动后,线路连接出现中断,将水晶头用手按住时,网络连通情况为时断时续。计算机Ping本机地址成功,Ping外部地址不通,使用测线仪对网络线路进行测量,发现部分用于传输数据的主要芯线不通。
①拔下水晶头,检查水晶头与网卡接口,若网卡RJ-45接口中的部分弹簧片松动,导致网卡接口与RJ-45头没有连接好,用镊子将弹簧片复位,再行接入后故障即可排除。②采用网络测线仪对双绞线两端接头进行测试,必要时可让两端双绞线脱离配线架、模块或水晶头直接进行测量确诊,以防因连接问题造成误诊,确诊后即可沿网络路由对故障点进行人工查找。如果有专用网络测试仪就可直接查到断点处与测量点间的距离,从而更准确地定位故障点。对线路断开的处理,通常可将双绞线、铜芯一一对应缠绕连接后,加以焊接并进行外皮的密封处理,也可将断点的所有芯线断开,分别压制进入水晶头后用对接模块进行直接连接。如果无法查找断点或无法焊接,在保证断开芯线不多于4根的情况下也可在两端将完好芯线线序优先调整为1、2、3、6,以确保信号有效传输。在条件许可的情况下,也可用新双绞线重新进行布设。五视频会议系统 ㈠宝利通视频会议系统 3常见问题
⑴系统不响应遥控器
①遥控器中没有电池、电池电量不足或电池耗尽; ②遥控器中电池安装不正确;
③红外传感器接收不到遥控器信号或遥控器信号受到干扰; ⑵拿起遥控器,监视器屏幕保持黑屏 ①监视器电源线未插入; ②监视器为正确连接到系统。㈡科达视频会议系统 3常见问题
⑴本会场在会议中本端讲话有较大回声 ①麦克风位置摆放不适合。
检查使所有的麦克风距离扬声器都在3米以上,且没有麦克风正对着扬声器。
②远端会场扬声器输出音量过大。
与远端会场联络,请其检查并降低音量。
③当召开多级级联的会议、主会场发言时,分会场没有闭音。
当召开多级级联的会议、主会场发言时,最好要求分会场将本地麦克风闭音或主会场将各分会场远端闭音。⑵终端开启后没有声音输出。①音频输入线路异常。
用一个已确认正常工作的音频输入设备连接到终端之后再听声音。
②音频输出线路异常。
用一个已确认正常工作的音频输入设备连接到输出设备,确认输出线路和音箱等音频输出设备正常。③终端的音量是否太低或为静音状态。
通过遥控器改变声音大小或静音状态。第五篇 制度篇 三各单位
㈠信息化管理工作制度 ㈡信息化管理岗位职责