资源预览内容
第1页 / 共29页
第2页 / 共29页
第3页 / 共29页
第4页 / 共29页
第5页 / 共29页
第6页 / 共29页
第7页 / 共29页
第8页 / 共29页
第9页 / 共29页
第10页 / 共29页
亲,该文档总共29页,到这儿已超出免费预览范围,如果喜欢就下载吧!
资源描述
移动项目运维方案汇报材料2011年12月目录现状分析01愿景目标02运维管理03软件过程管理04现状描述背景概述目前移动市自建系统业务呈膨胀的趋势,承载的业务越来越多,但相应的系统维护管理却没有与时俱 进,一直秉承谁开发谁维护的思想,维护工作由于开发商的多维度,业务多维度逐渐趋于混乱, 降低整个IT支撑的效率。处理效率慢由于对自建系 统业务不非常 了解,工单总 是需要转多次 才能转正确人 那边职责偏离本应该对项目 软件过程整体 把控,但深陷 维护漩涡出, 做事太琐碎, 偏离职责定位维护安排困难维护的不固定性, 以及小项目维护量 工作量偏少,对于 团队的开发经理维 护人力合适安排是 一个比较大的挑战工作延续中断在现有的环境中,开 发人员常常需要参与 维护。由于维护时间 上不固定性以及忽然 性,常常打断本职工 作,导致思路中断工作强度大维护域的缺失以及对 维护工作的不重视, 导致维护人员严重缺 失,造成维护人员工 作强度艰苦。做事累 且杂业支服务台ITC接口人开发经理开发人员维护人员当前参与维护各岗位人员现状分析思路统一运维 成立专业运维团队,负责整个维护相关工作.人机协作 通过程序系统对一些维护工作(监控类,审计类等),提高运维质量以及效率软件过程管理 采用CMMI指导思想,面向软件过程管理,降低软件风险与减少程序BUG,大大降低维护工作量软件过程管理统一运维人机协作运维过程管理运维过程管理 采用ITIL思想体系,通过建立系统流程规范运维过程,加强运维过程管控.对运维过程产生知识 进行积累沉淀开发过程不规 范导致程序质 量较差,相应 维护工作太多各开发商都参 与维护,不利 于管控维护只注 重结果, 过程未管 控量多分散 随意手工主要症结解决思路维护纯人力手工 ,效率低下,效 果很差目录现状分析01愿景目标02运维管理03软件过程管理04愿景目标组建运维团队主要目的就是将运维进行规范,将各梯队人员从运维中解放出来,运维团队保证运维95%以上工作。同时提升运维效率,提高运维质量。间接要求软件本身质量的提升,对软件质量起到 项目监理作用。在保证运维结果的情况下,本次运维方案目标应达到以下目标:成立专业运维团队,团队内部职能明确,团队接管整个运维过程中90%以上工 作,与维护相关梯队人员(开发人员,项目经理,业支人员)将维护相关工作 缩短到目前的20%以下。整个软件过程规范,包含开发过程,运维过程 项目开发采用CMMI成熟度模型,达到开发过程BUG,风险可控,开发轨迹可 在文档中清晰呈现 项目运维参照ITIL体系,运维过程事件,质量可管控。运维事件可追踪,可 分析,流程轨迹可以在系统中直观呈现。同时运维过程知识可传承整个运维事件中,时效性对于运维效果是一个非常重要的指标,运维事件 相应及时包括运维事件触发及时,运维事件处理过程协作畅通,运维团队 与对外反馈沟通及时。职能明确过程规范响应及时目录现状分析01愿景目标02运维管理03软件过程管理04运维管理体系运维团队维团队运维过程团队 角色角色职责素质要求人员组 成运维规 范质量考核规范工作内容界定制度规规范运维维流程运维监维监控ITIL 运维维体系对对象界定安 全 管 控采集平台质质 量 管 控监监控中心应应用中心知识识管理流程协协作协协作监监控事件升级级团队建设角色职职能素质质运维经理主管运维团队 内部管理,沟通,对 外沟通工作5年以上移动项目运维管理经验。 3年以上移动大型项目运维经验 。分析师将运维事件原因分析,策略定制, 运维项目设计合理性分析等6年以上移动项目经验。 5年以上担任系统架构,系统分析师经 验 熟悉各种分析工具与方法ORACLE DBA对于运维项目数据库进行管理,包 括巡检,故障处理,参数设置,热 备等具有DBA专业证书 3年以上oracle数据库管理经验服务台接收系统使用者反映事件,包含咨 询,查证,故障,并对时间进 行 ITIL单初步填写以及相关症状初判良好的沟通能力以及服务态度 项目故障相关基础故障知识 良好问题描述能力j2ee维护工程师相关j2ee项目故障,问题原因分析 ,故障处理等工作执行者2年以上移动项目开发经验 熟悉oracle基础SQL,mvc模型框架知识C+维护工程师相关C+项目故障判断,故障处理等 工作执行者4年以上C+项目经验,熟悉oracle数据 库 熟悉IBM MQ中间件,精通unix系统编 程WIDGET维护工程 师相关手机安卓系统WIDGET客户端 相关故障判断,故障处理工作执行 者2年以上手机软件开发经验 1年移动项目经验测试工程师故障处理后测试,或者项目交接过 程测试验 收工作执行者3年测试经验 ,熟悉黑盒,白盒测试方 法,熟悉各类测试 工具团队建设是基础,运维团队必须 是一个多角色,角色人员素质高 ,运维经验丰富的高效成熟团队 !运维流程-概述FMKR运维流程管理:结合实际按规 范建立六大流程故障,问题, 提数,发布,变更,交接流 程。定义流程各角色职能协作 流转。运维过程监控:对于运维事件 协作过程分层级(红色,橙色 ,黄色等)进行监控预警。触 发点事件环节流传点通知提醒 ,事件处理时间超期提醒,事 件紧急处理提醒,事件升级告 警运维知识管理:运维过程知识 体系,包括项目文档,常见业 务咨询问答,常见故障问题解 决,支撑服务台人员对于事件甑 别,事件初检。 运维过程事件职能分析成知 识。运维事件升级管理:事件在规 定的时间内不能由一线支持小 组解决,那么更多有经验的人 员和有更高权限的人员将不得 不参与进来。运维流程主要是通过流程协作的形式对于运维过程中运维事件进行处理。建立维护工作平台管理积累 运维知识,记录运维流程轨迹,并对整个运维过程管控。 包含四个部分:运维流程管理,运维知识管理,运维过程监控,运维事件升级管理。运维流程-流程呈现通过目前流行的地图呈现形式,将运维流程各关键流程节点直观展现,详细描述已经流转节点以及预计描述未来节点走向。节点中呈现相关节点信息。发起人:发起时间发起人描述到达时间处理人预期完成时间实际完成时间处理情况描述处理评分预计到达时间预计处理时间流程发起节点一当前节点节点三【MPT20122011200001】属于提数流程,目前处于正在处理状态,完成度为50%,当前处于第二节点,距离预警时间为2小时,工单紧急度为一般到达时间处理人预期完成时间实际完成时间剩余处理时间WEB门户手机WIDGET桌面WIDGET展现渠道运维流程-故障,问题流程一输入客户服务台维护 工程 师运维经 理输出发 起 阶 段处 理 阶 段电话 ,邮 件,QQ, 工单开始事件发发起有效 性ITIL单单登记记FAQ 解决单单独 处处理编编写处处理方案执执行处处理方案事件升级级反馈馈客户结户结 果验证结验证结 果FAQITIL事 件单单ITIL归归档YN YNY故障,问题流程根据发起人的不同分为外部流程与内部流程。外部流程发起人为运维项目使用人员,内部流程是运维团队内部人员在巡检,稽核,或者使用过程中发现的故障,问题。本流程为外部流程运维流程-故障,问题流程二团队 成员服务台维护 工程 师运维经 理输出处 理 阶 段开始事件发发起ITIL单单登记记FAQ 解决单单独 处处理编编写处处理方案执执行处处理方案事件升级级反馈结馈结 果验证结验证结 果FAQITIL事 件单单ITIL归归档YN NY本流程是内部流程运维流程-提数,发布,变更流程流程规范1提数规范模式借鉴软件开发规范中的快速开发模式,必须由主提数人,副提数人各自提数进行对比校验,确定统一口径后由审核人员审核。风险评估1版本发布之前,需要对发布风险进行预前评估,包括发布版本导致业务风险,系统内风险,外围系统影响风险等,发布前出示风险评估文档以及发布操作步骤文档。恢复机制2发布过程具有不可控因素影响发布实际效果,在风险规避的基础上,对于不可以规避的突发风险需要预先设计恢复方案,以其风险发生可以恢复发布之前状态。提数要素2提数过程中,交接给下一审批人必须完成以下要素的填写:提数周期,数据简介,数据量,数据SQL脚本(包含SQL脚本注释),数据说明等提数流程发发布流程目前提数流程目前有支撑系统综合支撑平台,一单清平台,两平台对于提数流程支撑能力充足。在 现有资源的基础上,对于提数流程进行相关流程关键点进行强制执行,对流程短板进行补充,确保流程 执行正确性以及可恢复性。变更流程在2011年综合支撑平台根据运营管理室意见进行改善,已经比较完善。暂时利用已有资 源。发布流程也有相应流程易平台进行支撑,在原有基础上对于发布流程的短板进行补充。运维流程-运维交接流程开发 团队运维 团队提交运维维 申请请提交软软件 文档检查检查文档 质质量合格 ?测试软测试软 件质质 量填写 测试测试 结结果合格 ?重新 交接交接 成功输出注:交接过程中,提交的软件文档一般包含需求说明书,概要说明书,详细设计说明书,数据字典,测试报告, 试运行情况报告分析,部署文档等,必须保持项目实际情况与文档一致性。运维团队测试包含功能测试,用户测试,业务逻辑测试,集成测试,压力测试,需要在流程中填写相关的测 试总结以及上传测试报告,不合格需要说明不合格原因。以上过程需要再严格的规范下进行,不然,流程会因为只是个形式而失败,达不到预期效果开发团队将软件项目交接给运维团队进行项目运维,该过程是一个责任过度的过程,需要严格的规范以及流程进行支撑。该部分叫做运维交接流程。运维流程-运维知识管理整个运维过程中,知识的积累沉淀,传承至关重要,可以有效的避免对同一事件重复运维以及由于人员流动导致知识流失。良好的知识库体系应当包含知识广泛的收集渠道能力,知识强大的管理能力,知识有效的应用能力。知识分类智能检索知识 应用 能力知识地图知识视图业务培训问卷调查知识采集知识共享知识审核知识评价知识推荐知识传播知识服务组件常用FAQ管理知识版本管理知识 管理 能力在线考试知识收集能力人工收集其他知识系统收集智能分析知识收集知识 渠道 展现运维团队成员使用 用户 客户电脑平板手机ITC人员运维流程-预警监控预警监控主要对运维流程监控,通过设定预警规则,生成预警信息,后台自动调度的方式将预警信息推送。预警过程的紧急度以及影响度,根据具体处理情况以及历史预警日志,系统智能将预警信息升级。预警分析监控点采集自动调度信息推送预警 流程涉及到运维流程 中的事件到达提 醒,事件将超期 提醒,事件逾期 通告对采集点进行监 控,通过预设定 规则,区分紧急 度,信息接收对 象生成预警信息依据时间,事件 紧急程度等实际 情况,系统智能 按频率触发监控 ,推送流程依据接收人不同 的角色信息,推 送相应的预警信 息按运维流程紧急度,严重度,相应处理时间限制将预警级别划分为红,橙,黄警告根据流程紧急度,严重度,处理时间限制等规则化时间升级条件,满足条件事件流程自动升级,并进行预警流程升级运维流程-事件升级如果某一事件不能在规定的时间内由一线支持小组解决,那么再多有经验的人员和有更高权限的人员将不得不参与进来。这就是升级,它可能发生在事件解决过程的任何时间和任何支持级别,升级分为职能性升级和结构性升级。两者的区别如下:职能性升级:需要具有更多时间、专业技能或访问权限(技术授权)的人员来参与事件的解决结构性升级:当经授权的当前级别的结构不能保证事件能及时、满意地解决时,需要更高级别的机构参与进来运维过程中应当尽量在运维团队内解决,避免结构性升级运维工程师无法完成事件产出项目经理内部专业 工程 师外围开发团队 / 移动技术部门协调资协调资 源解决协调资协调资 源组织团队组织团队 解决解决方案职能性升级结 构 性 升 级YN运维流程-制度规范运维过程中,运维工作如何界定,项目交接给运维团队时机以及交接要求,运维人员对事件如何正确处理等都属于运维制度规范内容。工作内容界定交接规范管理制度规范涉及运维过程中已经交接运维团队项目提数,咨询,查证,数据库库巡检,数据稽核,服务 器巡检,服务器漏洞修复,应急演练,故障处理,故障发现,数据修改,项目报告
网站客服QQ:2055934822
金锄头文库版权所有
经营许可证:蜀ICP备13022795号 | 川公网安备 51140202000112号