IT运维项目ITSS运维方案实施汇报.pptx

上传人:zf 文档编号:30803837 上传时间:2024-01-29 格式:PPTX 页数:51 大小:19.86MB
下载 相关 举报
IT运维项目ITSS运维方案实施汇报.pptx_第1页
第1页 / 共51页
IT运维项目ITSS运维方案实施汇报.pptx_第2页
第2页 / 共51页
IT运维项目ITSS运维方案实施汇报.pptx_第3页
第3页 / 共51页
IT运维项目ITSS运维方案实施汇报.pptx_第4页
第4页 / 共51页
IT运维项目ITSS运维方案实施汇报.pptx_第5页
第5页 / 共51页
点击查看更多>>
下载资源
资源描述

IT运维项目ITSS运维方案实施汇报.pptx

《IT运维项目ITSS运维方案实施汇报.pptx》由会员分享,可在线阅读,更多相关《IT运维项目ITSS运维方案实施汇报.pptx(51页珍藏版)》请在冰豆网上搜索。

IT运维项目ITSS运维方案实施汇报.pptx

xxxxx省xxx市信息化系统运行维护外包服务项目验收汇报,2021-10,目录,01,项目概况,02,运维目标及工作,03,运维方案,04,工作总结,05,下一步工作安排,1、背景,xxxxx于2015年启动了xxxxxx综合管理与服务系统的建设,该系统基于SOA架构体系建立了基于营运车辆、经营业户、从业人员、客运线路等基信息的数据中心,包含运政业务子系统、日常办公管理子系统、出租汽车服务管理信息子系统、重点营运车辆联网联控子系统、道路运输视频监控子系统等。

该系统现有业务数据记录2500万条,每日数据记录增量2万条,核心业务数据总量250G,扫描件库数据总量1.2T。

卫星定位数据12T,日增长50G。

数据中心需要与xxxx、xxxx、xxx交通局、xxx交通厅、xxx市级部门和运输企业等进行数据交换共享。

根据交通运输部、xxxx市政府相关文件要求对系统进行不断完善升级,以满足行业管理和公众服务需求。

2、业务系统运行现状,道路运输综合管理与服务系统,OA系统,运政系统,出租车系统,联网联控系统,统一认证系统,视频监控平台,联网售票系统,智能公交,驾培系统,风险隐患系统,统计分析系统,综合系统设计采用了虚拟云技术,以面向服务(SOA)的架构搭建系统基础框架,系统整体采用IBMSOA中间件技术进行开发,其中包含规则引擎、业务流程引擎、企业服务总线、数据共享交换平台、统计分析引擎等,实现了各类业务服务的独立封装以及复用,能快速响应业务需求的变化,大大提高了IT管理效能。

1、统一认证系统以人事管理业务为主线,实现用户的统一身份管理、集中授权管理、安全认证管理及单点登录。

上线7年,管理用户4000余个,权限认证超1100万次。

2、OA系统建立协同事务处理、行政办公、电子印章、消息通信等应用,规范了办公流程、提高了办公效率。

上线7年,处理相关公文近10万件。

3、运政业务系统实现了道路运输人、车、户、线等相关行政许可及备案业务办理,运政业务规则得到有效管理,运政业务办理的实时性和准确性大大提升。

系统上线5年,共办理业务1000万余件。

4、统计分析系统通过对运政数据中心中基础数据库、业务数据库中的数据进行智能分析,形成了服务行业管理的安全、出租、维修、基础统计等多个主题数据库,将报表分析结果以多种图形方式进行直观展现,辅助决策支持。

5、出租汽车服务管理信息系统接入了主城区15000余辆出租车,实现了出租汽车监控指挥和调度、电召服务、动态监管稽查、服务质量信誉考核、公交IC卡刷卡付费、企业在线业务管理、综合运行分析、信息发布和浮动车交通信息等九大功能。

6、重点营运车辆联网联控系统该系统实现了对xxx市22000辆重点营运车辆动态监测全覆盖,通过卫星定位监控服务商接入全市联网联控平台,有效提升营运车辆安全动态监管能力,是运输安全管理方式的一次重大变革,有效遏制了重特大交通安全事故的发生。

7、视频监控平台接入了全市2000余路视频监控,在安全生产、服务监督、执法监察等方面发挥着重要的作用。

3、数据中心运行现状,市交通局,违法、投诉等数据各类基础数据及动态业务数据,交通运输部,网约车、普货、跨省业务等数据运政业务、综检联网等数据,87个数据资源目录,出租车系统,运政业务系统,联网联控系统,12+TB数据资源总量,风险系统,客运经营系统,驾培系统,平均每天接入5亿+条,30GB+,平均每天共享2.5亿+条,数据中心,已搭建xxxxxx行业分中心的基础框架,建立道路运输数据交换与整合平台,建设基础数据库、业务数据库、主题数据库和元数据库,并利用数据交换与整合平台、企业服务总线(ESB)分别对批量数据及实时数据进行数据交换与共享,满足各级相关管理部门和社会公众不同层次信息服务的需求。

目录,01,项目概况,02,运维目标及工作,03,运维方案,04,工作总结,05,下一步工作安排,1、运维目标,建立日常检查和故障应急处理机制,及早发现潜在问题,缩短系统故障恢复时间,服务内容明确,操作步骤标准,保证服务规范化,服务全过程有详细记录,按照要求完成数据共享交换工作,根据业务处室需求建立数据分析及统计体系,安排不少于5人运维服务人员驻场,协助业主做好项目运维和操作培训,协助业主建立、完善符合重庆市道路运输事务中心的信息化运维体系,确保信息系统安全稳定运行,保证服务规范化,保障数据需求,保障运行维护服务力量,完善信息化体系,2、运维内容,日常巡检,监控,用户请求与处理,培训,业务需求变更,用户现场交流,应急保障,故障处理,3、运维内容-重点需求,交通运输部,市政府,市大数据局,市交通局,便民系统,互联互通系统,政务资源目录,审批系统,重点营运车辆考核,电子证照,xx快办,xx通办,1、交通运输部电子证照:

便民系统:

道路旅客运输、普货运输、危货运输驾驶员从业资格证补发/换发/变更/注销、诚信考核、网上年审等业务互联网申请,实现全国通办。

互联互通系统:

按照交通部互联互通数据共享标准对运政基础、业务、执法数据等进行清洗、共享,更好的为全国互联网便民服务系统提供数据支撑。

重点营运车辆考核:

按交通部要求对两客一危车辆、重型货车的车辆入网率、上线率、轨迹完整率、动态数据合格率、卫星定位漂移车辆率平均车辆超速次数、平均疲劳驾驶时长等指标进行考核。

2、市政府xx快办:

按照市政府电子政务办要求,将运政系统中行政许可、公众服务事项纳入渝快办平台。

xx通办:

根据关于协同推进成渝地区双城经济圈“放管服”改革合作协议推进从业资格证换发、变更、补发、转籍、注销等业务纳入渝快办、天府通办,实现xx地区数据共享、业务通办、证照互认。

3、市大数据局政务资源目录:

按照市大数据局最新要求对运政基础、业务相关数据进行共享,并建立数据持续共享机制保障数据及时性、完整性、可用性。

4、市交通局行政审批系统:

按照市交通局要求配合交通局行政审批系统中行政审批许可业务开发,提供基础、参阅数据支撑及办理数据归集。

数据资源目录:

按照市交通局数据共享交换平台要求,将道路运输相关数据共享到市交通局。

道路运输综合管理与服务系统,跨区县通办,数据资源目录,目录,01,项目概况,02,运维目标及工作,03,运维方案,04,工作总结,05,下一步工作安排,1、运维管理的重要性,“三分建设,七分运维”IT部门80%的工作围绕IT运维管理三个月的基建项目,要经历超过三年的运维周期百万投入的IT设施,如果维护不好,将变得一文不值,IT建设,IT运维,2、运维现状与困难,信息化迅猛发展的同时,给IT部门带来了更大的压力,1、业务运行环境越来越复杂,故障定位慢,2、运维工作繁重,缺少自动化工具和手段,各种业务系统越来越多,系统对IT资源的依赖性高,系统一旦出现任何问题,需要逐个排查,故障定位难。

运维人员每天面临大量的重复性、手工性的故障排查工作,不仅费时费力,而且容易出错,亟需自动化的手段帮助提升效率。

IT部门面临的“技术”难题,2、运维现状与困难,信息化迅猛发展的同时,给IT部门带来了更大的压力,3、运维工作没有流程化、规范化、电子化,4、信息化建设投入巨大,难以展现效果,日常运维工作流程混乱,或者没有标准流程,造成工作效率低下,同时客户抱怨、投诉不减员工干好干坏一个样,员工绩效无法体现,信息化投入了巨大资金,到底都花到哪了?

花的钱建设成了什么效果?

对单位的信息化提升起到了什么帮助?

IT部门面临的“管理”难题,3、问题解决思路分析,主要症结,解决思路,统一运维,软件过程管理,人机协作,运维过程管理,业务系统多业务复杂,不利于管控,维护只注重结果,过程未管控,开发过程不规范导致程序质量较差,相应的维护工作太多,维护纯人力手工,效率低下,效果很差,统一运维,成立专业运维团队,负责整个维护相关工作,人机协作,通过程序系统对一些维护工作(监控类,审计类等),提高运维质量以及效率,软件过程管理,采用CMMl指导思想,面向软件过程管理,降低软件风险与减少程序BUG,大大降低维护工作量,运维过程管理,采用ITIL思想体系,通过建立系统流程规范运维过程,加强运维过程管控.对运维过程产生知识进行积累沉淀,4、自动化运维体系建设思路,集简约、高效、自动化运维体系建立的思路,第三步:

建立可量化的卬普阶门考核体系,呈现如倍阶门业绩和价值,业务,流程,资源,业务需求,服务承诺保障请求,获得反馈,登记、自助知识库、跟跟进度,快速响应和恢复故障,知识积累和共享,根源分析和解决,变更风险管控,IT资源全生命周期管理,周期性工作值班与巡检,项目进度、资源管理,达成IT交付于也无需求的平衡,IT基础设施,第二步:

建立故障与流程的自动触发。

结合SLA提开人员服务效率,第一步:

建立自动化监控和管理平台。

并展现信息化童设成果,应用服务资源监控,业务应用监控,网络监控,5、持续改进思路,在运行维护服务中对运行维护服务能力进行整体策划,提供必要的资源支持,实施运行维护服务能力管理和服务内容,保证交付质量满足服务级别协议要求。

对运行维护服务结果、服务交付过程以及相关管理体系进行监督、测量、分析和评审,并实施改进。

制定服务目录建立组织架构和管理制度规划人员、资源、技术和过程,建立相应指标体系和服务保障体系改进服务质量机制,建立内部审核评估机制,服务管理团队根据运维服务能力管理体系规划的内容实施IT服务管理并交付IT服务,按策划好的时间对服务管理体系进行监控与测量,收集和分析相关度量数据,通过审核的方式检查运行维护服务能力管理活动符合计划要求和质量目标的程度,即:

服务质量管理体系完成的质量。

IT服务管理团队根据运维服务能力管理体系检查阶段的结果,采取改进措施不断改善IT服务管理和服务交付,逐步提高IT服务管理和服务交付的效果和效率。

6、运维管理-理想(目标),呼叫中心电话受理,自动识别来电用户身份,自助服务台用户WEB登录,提交服务或故障请求,事件管理快速响应,解决突发故障及请求,在最短时间内恢复业务,知识库,IT基础设施监控,数据中心机房监控,问题管理根源分析,找出根本原因,避免故障再次发生,变更管理控制变更可能产生的风险,配置管理资产配置全生命周期管理,项目管理开发及重大实施项目周期管理,计划任务管理周期性任务提醒、执行、监督,SLA服务级别管理跟踪事件处理失效,达成与客户的服务约定,KPI与报表管理报表输出,关键绩效指标分析,CMDB,用户-电话服务或者故障报告,用户-服务台或者故障报告,服务台座席创建事件单,客户与IT主管,IT主管决策、优化改进,达成服务级别协议,短信邮件通知,自动生成事件单,大屏幕,查询知识,分派,事件工程师受理并快速恢复,升级,项目经理,任务工程师,问题小组分析并根源解决,申请变更,指派,变更评审委员会评估、制定变更计划,变更工程师变更实施及发布,更新,管理,配置工程师配置项管理,7、IT运维管理体系架构,运维团队,团队角色,角色职责,素质要求,人员组成,运维过程,制度规范,安全管控,质量管控,运维流程,知识管理,流程协作,协作监控,事件升级,项目管理,整体管理,风险管理,进度管理,质量管理,工作内容界定,运维规范,质量考核规范,IT运维体系,运维监控,对象界定,采集平台,监控中心,应用中心,项目管理过程,项目管理体系,现场管理制度,8、运维服务能力指标体系,9、运维团队建设,团队建设是基础,运维团队必须是一个多角色,角色人员素质高,运维经验丰富的高效成熟团队!

10、运维团队建设,战略决策支撑数据,战略运转分析支撑数据,业务优化支撑数据,工作量统计,SLA遵守情况,持续优化的支撑数据,配置/资产管理,业务可用性,流程运转情况,故障预测/主动预警,故障快照/自动处理,运维知识库,IT设施自动巡检,故障精准定位,应用性能监控预警,应用体验分析,应用潜在风险预测,应用可用性巡检,项目经理,驻场运维经理,技术支撑经理,11、运维团队建设-人员变更流程,新负责人应尽量选择在相关领域有经验的人员(由于是中途接手,难度较大);如果选择本项目中已承担其他工作任务的人员作为新负责人,则一定要准确度量其负荷,并要明确其接手后的责任;交接期限的确定应以工作能够有效交接为中心,可能的情况下部门应在工作交接结束后,才最终同意原担当离职或变动工作;交接计划要与项目经理和被交接者商讨制定,计划中应包含要进行哪些交接活动、时间、内容及相关人员安排等,应该包括相关培训和自学的内容。

项目经理要对工作交接的结果进行检查,判断相关工作是否都已经顺利交接;如果存在问题,与相关人员商讨后续计划,变更请求,分析影响,确定新负责人,明确交接期限,召开交接短会,对当前工作内容和产品进行整理和完善,制定交接计划,按计划交接,工作交接评审,变更结束,12、运维过程-运维流程,概述,运维流程主要是通过流程协作的形式对于运维过程中运维事件进行处理。

建立维护工作平台管理积累运维知识,记录运维流程轨迹,并对整个运维过程管控。

包含四个部分:

运维流程管理,运维知识管理,运维过程监控,运维事件升级管理。

运维流程管理:

结合实际按规范建立六大流程故障,问题,提数,发布,变更,交接流程。

定义流程各角色职能协作流转。

运维知识管理:

运维过程知识体系,包括项目文档,常见业务咨询问答,常见故障问题解决,支撑服务台人员对于事件甑别,事件初检。

运维过程事件职能分析成知识。

运维过程监控:

对于运维事件协作过程分层级(红色,橙色,黄色等)进行监控预警。

触发点事件环节流传点通知提醒,事件处理时间超期提醒,事件紧急处理提醒,事件升级告警。

运维事件升级管理:

事件在规定的时间内不能由一线支持小组解决,那么更多有经验的人员和有更高权限的人员将不得不参与进来。

13、运维过程-运维流程,问题处理流程,故障,问题流程根据发起人的不同分为外部流程与内部流程。

外部流程发起人为运维项目使用人员,内部流程是运维团队内部人员在巡检,稽核,或者使用过程中发现的故障,问题。

本流程为外部流程,输入,客户,服务台,维护工程师,运维经理,输出,发起阶段,处理阶段,电话,邮件,QQ,工单,事件发起,ITIL单登记,开始,单独处理,单独处理,FAQ解决,事件升级,编写处理方案,执行处理方案,反馈客户结果,验证结果,ITIL归档,ITIL事件单,FAQ,Y,Y,Y,N,N,14、运维过程-运维流程,运维交接流程,开发团队将软件项目交接给运维团队进行项目运维,该过程是一个责任过度的过程,需要严格的规范以及流程进行支撑。

该部分叫做运维交接流程。

注:

交接过程中,提交的软件文档一般包含需求说明书,概要说明书,详细设计说明书,数据字典,测试报告,试运行情况报告分析,部署文档等,必须保持项目实际情况与文档一致性。

运维团队测试包含功能测试,用户测试,业务逻辑测试,集成测试,压力测试,需要在流程中填写相关的测试总结以及上传测试报告,不合格需要说明不合格原因。

以上过程需要再严格的规范下进行,不然,流程会因为只是个形式而失败,达不到预期效果。

开发团队,提交运维申请,合格?

提交软件文档,检查文档质量,测试软件质量,填写测试结果,合格?

重新交接,交接成功,运维团队,输出,15、运维过程-运维流程,知识库管理,整个运维过程中,知识的积累沉淀,传承至关重要,可以有效的避免对同一事件重复运维以及由于人员流动导致知识流失。

良好的知识库体系应当包含知识广泛的收集渠道能力,知识强大的管理能力,知识有效的应用能力。

知识展现渠道,知识应用能力,知识管理能力,知识收集能力,使用用户,知识分类,知识采集,知识共享,知识审核,智能检索,知识地图,知识视图,业务培训,知识版本管理,电脑,服务台,手机,人工收集,其他知识系统收集,智能分析知识收集,问卷调查,在线考试,知识评价,知识推荐,知识传播,知识服务组件,常用FAQ管理,客户,运维团队成员,16、运维过程-运维流程,预警监控,预警监控主要对运维流程监控,通过设定预警规则,生成预警信息,后台自动调度的方式将预警信息推送。

预警过程的紧急度以及影响度,根据具体处理情况以及历史预警日志,系统智能将预警信息升级。

按运维流程紧急度,严重度,相应处理时间限制将预警级别划分为红,橙,黄警告根据流程紧急度,严重度,处理时间限制等规则化时间升级条件,满足条件事件流程自动升级,并进行预警,涉及到运维流程中的事件到达提醒,事件将超期提醒,事件逾期涌告,对采集点进行监控,通过预设定规则,区分紧急度,信息接收对象生成预警信息,依据时间,事件紧急程度等实际情况,系统智能按频率触发监控,推送流程,依据接收人不同的角色信息,推送相应的预警信息,监控点采集,预警分析,自动调度,信息推送,流程升级,流程预警,17、运维过程-运维流程,事件升级,如果某一事件不能在规定的时间内由一线支持小组解决,那么再多有经验的人员和有更高权限的人员将不得不参与进来。

这就是升级,它可能发生在事件解决过程的任何时间和任何支持级别,升级分为职能性升级和结构性升级。

两者的区别如下:

职能性升级:

需要具有更多时间、专业技能或访问权限(技术授权)的人员来参与事件的解决。

结构性升级:

当经授权的当前级别的结构不能保证事件能及时、满意地解决时,需要更高级别的机构参与进来,运维过程中应当尽量在运维团队内解决,避免结构性升级。

解决,无法完成事件,协调资源,协调资源,组织团队解决,解决方案,Y,N,职能性升级,结构性升级,运维工程师,项目经理,内部专业工程师,外围开发团队/移动技术部门,产出,18、运维过程-运维流程,应急服务流程:

主要是针对可能发生的各种意外情况设计应急的方案,以控制和规避突发事件带来的集中性风险,从而降低设备集中性风险所造成的损失,健康检查服务流程:

监控检查服务过程包括5个阶段:

准备阶段,现场交流与采集阶段,巡检问题现场处理阶段,技术交流与培训阶段,数据分析处理与报告生成阶段,第三方服务流程:

流程中制定了需要第三方实施厂商配合完成的工作内容和进度的相关要求,19、运维过程-运维流程,培训流程,1由业主单位和本公司提出培训需求;2向业主单位提供详细的培训大纲,并征得业主单位的同意;3由业主单位和本公司项目经理双方确认;4由业主单位发出培训通知,本公司提供师资力量进行培训;5业主单位工作人员对培训效果进行评估。

提出培训需求,提供培训计划,由业主方判定计划是否可行,发出培训通知,结束,改进建议,培训,改进建议,评估,20、运维监控-监控平台,运维监控-监控平台,目前系统应用较多。

影响业务流程可用性因子很多。

如何变被动为主动,对事件进行事前管理,快速发现问题,智能分析故障,减少运维过程中事件带来不良影响力以及大量运维工作量。

建立完善的运维监控平台,以电子监控的形式辅助运维,提升运维效率以及业务功能可靠性。

展现渠道,应用中心,监控中心,采集平台,监控对象,数据库,操作系统,业务系统,接口系统,采集工具集成,采集方式,采集调度,数据中心,监控规则,告警级别,告警调度,告警规则,监控视图,报表中心,安全审计,智能提数,信息推送,电脑,平板,手机,21、运维监控-监控平台,应用系统健康检查,业务可用性体检,巡检脚本录制,巡检脚本导入,业务检查点设置,交互数据管理,巡检流程编排,业务流程执行,业务流程巡检,业务可用性,敏感词监测,客户端性能分析,坏死链检查,僵尸门户监测,应用安全分析,业务状态分析,安装启动监测,兼容性适配,巡检脚本录制,跨设备巡检执行,移动应用巡检,遍历规则配置,遍历检查项设置,标准遍历在执行,深度遍历执行,系统遍历巡检,业务办理量分析,业务跳出率分析,业务访问量分析,区域用户量分析,HTTP请求分析,系统日志分析,系统状态报告,22、运维监控-监控平台,重复运维自动化,运维工作,枯燥、重复、不及时,提取,脚本发送由件.sh清理磁盘.sh重启服务.sh关闭服务.sh数据备份.sh.,任务自动巡检计划报表计划维护计划备份.,自动化,触发器,开始,结束,电子签章接口检查,通知本地运维人员,通知第三方接口人,重启本地服务或进程,通知运维负责人,接口状态检查,问题排查结束,第三方接口异常,本地异常,接口正常,23、软件过程管理,运维过程中,运维效率以及运维实际工作量是运维成本的两大关键因素。

对于运维实际工作量的决定因素为业务项目多少以及项目健康度。

因此,以CMMI为理论体系,注重软件过程管理,保证项目开发质量,减少项目运维过程中故障可以有效减少运维实际工作量。

当前系统大多数处于已管理级别-已定义级之间,初期目标为完全实现已定义级别。

实现软件过程文档化,后期由被动变主动,主动识别软件风险与缺陷,量化整个软件过程,最终实现优化管理级。

软件过程是无序的,有时甚至是混乱的,对过程几乎没有定义,取决于个人。

1、初始级,制定了必要的过程纪律,能重复早先类似应用项目取得的成功经验,2、已管理级,已将软件管理和工程两方面的过程文档化、标准化,并综合成该组织的标准软件过程。

3、已定义级,对软件过程和产品质量的详细度量数据,对软件过程和产品都有定量的理解与控制。

4、量化管理级,可集中精力改进过程,采用新技术、新方法。

拥有防止出现缺陷、识别薄弱环节以及加以改进的手段。

5、优化管理级,CMMI能力成熟度模型,24、软件过程管理,项目需求阶段,客户提出诉求,研发团队被动接受,然后通过软件手段将客户描述的诉求编写成计算机语言这种方式在目前移动环境中普遍存在。

诉求梳理,整理成需求是软件过程中非常重要一部分,诉求的理解偏差可能导致软件项目的延期甚至失败。

量化业务需求,多角色参与需求沟通评审是避免需求理解偏差有效手段。

鉴于业务之间相关性强,而业务需求人提出业务需求具有片面性,不完整性,所以在需求沟通中提出业务需求比较散乱,无体系。

故要求研发团队需求人员需要在项目需求阶段了解业务体系环境,正确定位当前业务具体内容,圈定业务范围,综合考虑业务扩展性以及预前提炼项目能力,加强团队需求理解能力,运维团队如何快速交接研发团队研发项目,关键因素是对于项目业务比较熟悉。

组建运维团队后,将运维团队在软件过程中定位另外角色-项目监理,实现项目过程B角角色,同时可以提升需求质量,引入项目监理角色,需求文档是项目团队与需求人员沟通的桥梁,当前主要模式是需求人员简单描述-项目团队细化,由于技术人员与业务人员理解业务角度不一致,往往需求阅读过程中存在难懂等问题。

需求文档中引入原型设计模型,实现需求视图化预先展现,加强关键业务逻辑流程图化,文字详尽化描述。

提升需求文档质量,强制业务人员,项目监理,研发团队对于需求文档业务内容进行会议沟通,新增需求会议评审团,重点审核需求中业务理解正确性,需求中业务量化性,原型设计模型合理性,减少需求理解偏差以及需求中模糊业务内容。

强制执行沟通评审,25、软件过程管理,项目开发阶段,需求确定产出需求说明书后,项目进入研发阶段,设计前识别研发过程中技术问题,设计中出具详细的设计文档,实现阶段严格按照统一编码规范进行编码是软件项目质量保证,风险规避关键因素。

沉淀技术研究成果,强制详细设计文档评审,代码走查常态化,26、软件过程管理,项目测试&运维,项目经过单元测试,集成测试,系统测试,验收测试测试方式主动识别软件故障。

改变测试观念,加强测试人员的程序测试的过程具有破坏性认知。

1,2,3,4,5,系统测试,加强用户验收环节,新增用户项目体验环节,增强项目的可操作性,易操作性。

针对立项管理的要点以及开发研发计划,进行结项审计,找出项目实际能力与预期目标的差异,总结差异原因,沉淀项目经验。

用户验收&结项管理,项目试运行期间,最大限度在实际生产环境中排查故障,保证试运行完毕后正式运行程序的稳定性,产出试运行报告。

试运行报告,试运行结束,实施运维交接,研发团队需要对运维团队进行项目培训,并提供常见问题说明书等文档。

运维交接,,,,,,等,项目产出文档,项目测试&运维,27、制度规范-现场维护管理,日常维护管理每周召开项目例会,与客户对近期工作重点、工作完成情况、存在问题以及下一步工作重点进行沟通汇报。

现场服务人员的变动,需经用户同意,用户有权要求对不合格人员的进行调整。

我公司现场人员必须遵守用户的管理要求,在关键时点,如假日或软件升级后第一天上班等,需要严格遵守作息时间,避免出现问题得不到及时

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 解决方案 > 学习计划

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1