移动项目运维方案汇报材料

1、«si«aw«引领3G生活愿景目标运维管理软件过程管理现状描述当前移动市自建系统业务呈膨胀的趋势，承载的业务越来越多，但相对应的系统维护管理却没有与时俱进，一直秉承谁开发谁维护的思想，维护工作因为开发商的多维度，业务多维度逐渐趋于混乱，、降低整个IT支撑的效率。当前参与维护各岗位人员现状处理效率慢 由于对自建系 统业务不非常 了解，工单总 是需要转多次 才能转正确人 那边职责偏离本应该对项目 软件过程整体 把控，但深陷 维护漩涡出， 做事太琐碎， 偏离职责定位维护安排困难 维护的不固定性， 以及小项目维护量 工作量偏少，对于 团队的开发经理维 护人力合适安排是 一

2、个比较大的挑战工作延续中断 在现有的环境中，开 发人员常常需要参与 维护。由于维护时间 上不固定性以及忽然 性，常常打断本职工 作，导致思路中断工作强度大维护域的缺失以及对 维护工作的不重视， 导致维护人员严重缺 失，造成维护人员工 作强度艰苦。做事累 且杂分析思路主要症结统一运维成立专业运维团队，负责整个维护相关工作.人机协作通过程序系统对一些维护工作（监控类，审计类等），提高运维质量以及效率软件过程管理采用CMMI指导思想，面向软件过程管理，降低软件风险与减少程序BUG,大大降低维护工作量运维过程管理采用ITIL思想体系，通过建立系统流程规范运维过程，加强运维过程管控.对运维过程产生知识进

3、行积累沉淀©9I«3G生潔现状分析软件过程管理愿景目标组建运维团队主要目的就是将运维进行规范，将各梯队人员从运维中解放出来，运维团队保证运维95%以上工作。同时提升运维效率，提高运维质量。间接要求软件本身质量的提升，对软件质量起到项目监理作用。在保证运维结果的情况下，本次运维方案目标应达到以下目标：成立专业运维团队，团队内部职能明确，团队接管整个运维过程中90%以上工作，与维护相关梯队人员（开发人员，项目经理，业支人员）将维护相关工作缩短到当前的20%以下。整个软件过程规范，包含开发过程，运维过程危项目开发采用CMMI成熟度模型，达到开发过程BUG,风险可控，开发轨迹可在文

4、档中清晰表现年项目运维参照ITIL体系，运维过程事件，质量可管控。运维事件可追踪，可分析，流程轨迹能够在系统中直观表现。同时运维过程知识可传承整个运维事件中，时效性对于运维效果是一个非常重要的指标，运维事件相对应及时包括运维事件触发及时，运维事件处理过程协作畅通，运维团队与对外反馈沟通及时。现状分析软件过程管理运维管理体系团队角色：角色职责素质要求人员组成ITIL运维体系团队建设运维经理主管运维团队内部管理，沟通，对外5年以上移动项目运维管理经验。沟通工作3年以上移动大型项目运维经验。分析师将运维事件原因分析，策略定制，运6年以上移动项目经验。维项目设计合理性分析等5年以上担任系统架构，系统分

5、析师经验熟悉各种分析工具与方法服务台j2ee维护工程师C+维护工程师WIDGET维护工程师测试工程师接收查证,步填写验团队建设是基础，运维团队必须是一个多角色，角色人员素质高，运维经验丰富的高效成熟团队！相关j故障处理等工作执行2年以上手机软件开发经验1年移动项目经验mvc模型框架知识,熟悉oracle数据库精通unix系统编程相关C+项目故障判工作执行者相关手机安卓系统WIDGET客户端相关故障判断，故障处理工作执行者故障处理后测试，或者项目交接过程3年测试经验，熟悉黑盒，白盒测试方法,测试验收工作执行者熟悉各类测试工具运维流程主要是通过流程协作的形式对于运维过程中运维事件进行处理。建立维护

6、工作平台管理积累运维知识，记录运维流程轨迹，并对整个运维过程管控。包含四个部分：运维流程管理，运维知识管理，运维过程监控，运维事件升级管理。运维流程管理：结合实际按规 范建立六大流程故障，问题， 提数，发布，变更，交接流程。 定义流程各角色职能协作流转。运维知识管理：运维过程知识 体系，包括项目文档，常见业 务咨询问答，常见故障问题解 决支撑服务台人员对于事件甑 别，事件初检。运维过程事件职能分析成知识。运维过程监控:对于运维事件 协作过程分层级（红色，橙色, 黄色等）进行监控预警。触发 点事件环节流传点通知提醒， 事件处理时间超期提醒，事件 紧急处理提醒，事件升级告警9I«3G生潔

7、运维事件升级管理：市廿仕人定的时间内不能由一线支持小组解决，那么更多有经验的人员和有更高权限的人员将不得不参与进来。通过当前流行的地图表现形式，将运维流程各关键流程节点直观展现，详细描述已经流转节点以及预计描述未来节点走向。节点中表现相关节点信息。MPT20122011200001属于提数流程，当前处于正在处理状态，完成度为50%,当前处于；1第一节点，距离预警时间为2小时，1!工单紧急度为一般1111111流程发起节点一当前节点节点三!丄111>：1发起人：到达时间到达时间预计到达时间发起时间处理人处理人预计处理时间111预期完成时间预期完成时间1111111实际完成时间实际完成时间1

8、11!1处理情况描述剩余处理时间11111处理评分111故障，问题流程根据发起人的不同分为外部流程与内部流程。外部流程发起人为运维项目使用人员,内部流程是运维团队内部人员在巡检，稽核，或者使用过程中发现的故障，问题。本流程为外部流程客户运维流程-故障，问题流程二团队成员服务台维护工程师运维经理输出运维流程-提数，发布，变更流程当前提数流程当前有支撑系统综合支撑平台，一单清平台，两平台对于提数流程支撑能力充足。在现有资源的基础上，对于提数流程进行相关流程关键点进行强制执行，对流程短板进行补充，确保流程执行正确性以及可恢复性。提数要素变更流程在2011年综合支撑平台根据运营管理室意见进行改善，已经

9、比较完善。暂时利用已有资源。发布流程也有相对应流程易平台进行支撑，在原有基础上对于发布流程的短板进行补充。流程规范是数流程;提数规范模式借鉴软件开发规范中的快速开发模式，必须由主提数人，副提数人各自扌数进行对比校验，确定统一口径后由审核员审核。数过程中，交接给下一审批人必须完成以素的填写：提数周期，数据简介，数据数据SQL脚本（包含SQL脚本注释），据说明等风险评估恢复机制i布过程具有不可控因素影响发布实际效果,估，包括发布版本导致业务风险，系统内（发布流程）风险规避的基础上，对于不能够规避的突险，外围系统影响风险等，发布前出示风评估文档以及发布操作步骤文档。i风险需要预先设计恢复方案，以其风

10、险发：生能够恢复发布之前状态。运维流程-运维交接流程开发团队将软件项目交接给运维团队进行项目运维，该过程是一个责任过度的过程，需要严格的规范以及流程进行支撑。该部分叫做运维交接流程。«交接过程中，提交的软件文档一般包含需求说明书，概要说明书，详细设计说明书，数据字典，测试报告，试运行情况报告分析，部署文档等，必须保持项目实际情况与文档一致性。运维团队测试包含功能测试，用户测试，业务逻辑测试，集成测试，压力测试，需要在流程中填写相关的测试总结以及上传测试报告，不合格需要说明不合格原因。«以上过程需要再严格的规范下进行，不然，流程会因为仅仅个形式而失败，达不到预期效果运维流程-

11、运维知识管理整个运维过程中，知识的积累沉淀，传承至关重要，能够有效的避免对同一事件重复运维以及因为人员流动导致知识流失。良好的知识库体系理应包含知识广泛的收集渠道能力，知识强大的管理能力，知识有效的应用能力。客户ITC人员平板知识地图知识视图业务培训问卷调查知识分类知识采集知识共享知识审核知识版本管理知识推荐知识评价知识传播知识服务组件常用FAQ管理日手机I运维团队成员运维流程-预警监控预警监控主要对运维流程监控，通过设定预警规则，生成预警信息，后台自动调度的方式将预警信息推送。预警过程的紧急度以及影响度，根据具体处理情况以及历史预警日志，系统智能将预警信息升级。监控点采集 、预警分析自动调度

12、!涉及到运维流程：中的事件到达提：醒，事件将超期"是醒，事件逾期|通告I1对采集点进行监：控，通过预设定规则，区分紧急度，信息接收对；：象生成预警信息I!j：依据时间，事件;紧急程度等实际：情况，系统智能;按频率触发监控，：推送流程I'信息推送依据接收人不同I的角色信息，推i送相对应的预警信!自L耳。按运维流程紧急度，严重度，相对应处理时间限制将预警级别划分为红，橙，黄警告二根据流程紧急度严重度，处理时间限制等规则化时间升级条件，满足条件事件流程自动升级，并进行预警项目经理 1 I 内部专业工程.职能性升级解决结构_性升运维流程->事件升级如果某一事件不能在规定的时间内

13、由一线支持小组解决，那么再多有经验的人员和有更高权限的人员将不得不参与进来。这就是升级，它可能发生在事件解决过程的任何时间和任何支持级别I升级分为职能性升级和结构性升级。两者的区别如下：职能性升级：需要具有更多时间、专业技能或访问权限（技术授权）的人员来参与事件的解决结构性升级：当经授权的当前级别的结构不能保证事件能及时、满意地解决时，需要更高级别的机构参与进来运维过程中理应尽量在运维团队内解决，避免结构性升级运维工无法完成事件外围开发【移动技术卜解决方案运维流程。制度规范运维过程中，运维工作如何界定，项目交接给运维团队时机以及交接要求，运维人员对事件如何正确处理等工作内容界定交接规范，新项目

14、需稳定运行3个月以上时间才能交接给运维组分新项目交接给运维组必须对接手维护的同事做系统业务培训，项目交接必须提供项目需求文档.doc项目操作手册.doc项目维护手册-doc)项目常见问题处理.doc项目详细设计文档.doc项目数据字典管理制度规范服务时间响应规范：规范服务方式，故障级别相对应服务行为规范A现场服务支持规范ITIL单操作规范运维监控->监控平台当前ITC自建系统应用较多。影响业务流程可用性因子很多。如何变被动为主动，对事件进行事前管理，快速发现问题，智能分析故障，减少运维过程中事件带来不良影响力以及大量运维工作量。建立完善的运维监控平台，以电子监控的形式辅助运维，提升运维效

15、率以及业务功能可靠性。：网络系统监控点：网络互通、端口开放情况、网络权限、网络延迟等监控频率：实时监控操作系统监控点：CPU使用、内存使用、硬盘使用、用户数、进程数等，适用系统：windows,unix监控频率：实时监控:业务系统监控点：系统状态、占用 监控方式:间隔频率监控关键业务状态等;接口系统监控点：FTP可用性、web service可用性、servlet等监控方式:间隔频率监控©9I«3G生潔运维流程。监控中心在IT日益发展的当今，业务与IT已经紧密结合.一个IT项目的关联着系统，数据库，应用，网络，业务，用户等多方面因素。对单个IT资源进行监控已经越来越满足不了

16、IT运维需求。集成传统的监控方式，将整体业务作为主体，构建业务监控视图。监控主要体现为四字原则：看、监、析、告A看得见：能够的通过网络拓扑图的这种表现形式将检测点以及检测点周边环境直观表现，一目了然监得到:对于监控点进行多层级别监控，通过监控 规则快速识别监控点异常。析得清:通过对监控点设置规则，监控中心可以对 ®故障进行智能分析，检查，主动将故障发生的关注点告知运维人员监控中心成功四要素告得快：通过手机短信，手机widget监控视图，WEB视图，EAMIL等多种方式，将监控问题故障及时准确的发给运维人员。运维流程经典案例eoss*»I?oS«4»

17、87;*it :ss事紅号:至眼旦小专什为日FStlWlB?0监控平台案例：主要业务可用监控，系统使 用情况，占用资源监控，目标操作系统状态监控安全审计案例：模型视图化设置审计规则, 自动审计目标数据，生成审计报告主动推送 东懸动火版持中心安全哦gBugnos support Ctnter-sacurity avdtlcx5fRIWBC.bSSJSRISWBe.kE8«ff JMIffff WSS9««9KX Riir« ，一痛对核敏、定M夢.采集平台案例：支持开发接口采集，分布式采集等多种采集策略，自动将采集数据归类，体系报表中心案例：模型视图化配置报

18、表,选择报表样式，支持手机端，PC端报表预订与定制©目录软件过程管理运维过程中，运维效率以及运维实际工作量是运维成本的两大关键因素。对于运维实际工作量的决定因素为业务项目多少以及项目健康度。所以，以CMMI为理论体系，注重软件过程管理，保证项目开发质量，减少项目运维过程中故障能够有效减少运维实际工作量。当前东莞自建系统大多数项目处于已管理级别-已定义级之间，初期目标为完全实现已定义级别。实现软件过程文档化，后期由被动变主动，主动识别软件风险与缺陷，量化整个软件过程。应用项目取得的成功经验项目需求阶段客户提出诉求，研发团队被动接受，然后通过软件手段将客户描述的诉求编写成计算机语言这种方

19、式在当前移动环境中普遍存在。诉求梳理，整理成需求是软件过程中非常重要一部分，诉求的理解偏差可能导致软件项目的延期甚至失败。量化业务需求，多角色参与需求沟通评审是避免需求理解偏差有效手段。引入项目监理角色鉴于业务之间相关性强，而业务需求人 提出业务需求具有片面性，不完整性， 所以在需求沟通中提出业务需求比较散 乱，无体系。故要求研发团队需求人员 需要在项目需求阶段了解业务体系环境, 正确定位当前业务具体内容，圈定业务 范围，综合考虑业务扩展性以及预前提 炼项目能力提升需求文档质量需求文档是项目团队与需求人员沟通的 桥梁，当前主要模式是需求人员简单描 述-项目团队细化，由于技术人员与业务 人员理解

20、业务角度不一致，往往需求阅 读过程中存在难懂等问题。需求文档中 引入原型设计模型，实现需求视图化预 先展现，加强关键业务逻辑流程图化， 文字详尽化描述。强制执行沟通评审运维团队如何快速交接研发团队研发项 目，关键因素是对于项目业务比较熟悉。 组建运维团队后，将运维团队在软件过 程中定位另外角色-项目监理，实现项 目过程B角角色，同时可以提升需求质强制ITC,业务人员，项目监理，研 发团队对于需求文档业务内容进行会 议沟通，新增需求会议评审团，重点 审核需求中业务理解正确性，需求中 业务量化性，原型设计模型合理性， 减少需求理解偏差以及需求中模糊业 务内容。项目开发阶段需求确定产出需求说明书后，项目进入研发阶段，设计前识别研发过程中技术问题，设计中