软件项目运维方案汇报材料课件.pptx

1、移动项目运维方案移动项目运维方案汇报材料汇报材料2011年12月目录目录现状分析01愿景目标02运维管理03软件过程管理04现状描述背景概述背景概述 目前移动市自建系统业务呈膨胀的趋势，承载的业务越来越多，但相应的系统维护管理却没有与时俱进，一直秉承谁开发谁维护的思想，维护工作由于开发商的多维度，业务多维度逐渐趋于混乱，降低整个IT支撑的效率。处理效率慢处理效率慢由于对自建系统业务不非常了解，工单总是需要转多次才能转正确人那边职责偏离职责偏离本应该对项目软件过程整体把控，但深陷维护漩涡出，做事太琐碎，偏离职责定位维护安排困难维护安排困难维护的不固定性，以及小项目维护量工作量偏少，对于团队的开发

2、经理维护人力合适安排是一个比较大的挑战工作工作延续中断延续中断在现有的环境中，开发人员常常需要参与维护。由于维护时间上不固定性以及忽然性，常常打断本职工作，导致思路中断工作强度大工作强度大维护域的缺失以及对维护工作的不重视，导致维护人员严重缺失，造成维护人员工作强度艰苦。做事累且杂业 支 服 务 台业 支 服 务 台ITC接口人接口人开发经理开发经理开发人员开发人员维护人员维护人员当前参与维护各当前参与维护各岗位人员现状岗位人员现状分析思路统一运维统一运维成立专业运维团队，负责整个维护相关工作.人机协作人机协作 通过程序系统对一些维护工作（监控类，审计类等），提高运维质量以及效率软件过程管理软

3、件过程管理 采用CMMI指导思想，面向软件过程管理，降低软件风险与减少程序BUG，大大降低维护工作量软件过程管理软件过程管理统一运维统一运维人机协作人机协作运维过程管理运维过程管理运维过程管理运维过程管理采用ITIL思想体系，通过建立系统流程规范运维过程，加强运维过程管控.对运维过程产生知识进行积累沉淀开发过程不规范导致程序质量较差，相应维护工作太多各开发商都参与维护，不利于管控维护只注重结果，过程未管控量多量多分散随意手工手工 主要症结解决思路维护纯人力手工，效率低下，效果很差目录目录现状分析01愿景目标02运维管理03软件过程管理04愿景目标 组建运维团队主要目的就是将运维进行规范，将各梯

4、队人员从运维中解放出来，运维团队保证运维95%以上工作。同时提升运维效率，提高运维质量。间接要求软件本身质量的提升，对软件质量起到项目监理作用。在保证运维结果的情况下，本次运维方案目标应达到以下目标:成立专业运维团队，团队内部职能明确，团队接管整个运维过程中90%以上以上工作，与维护相关梯队人员（开发人员，项目经理，业支人员）将维护相关工作缩短到目前的20%以下以下。整个软件过程规范，包含开发过程，运维过程项目开发采用CMMI成熟度模型成熟度模型，达到开发过程BUG，风险可控,开发轨迹可在文档中清晰呈现项目运维参照ITIL体系体系，运维过程事件，质量可管控。运维事件可追踪，可分析，流程轨迹可以

5、在系统中直观呈现。同时运维过程知识可传承整个运维事件中，时效性对于运维效果是一个非常重要的指标，运维事件相应及时包括运维事件触发及时，运维事件处理过程协作畅通，运维团队与对外反馈沟通及时。职能明确职能明确过程规范过程规范响应及时响应及时目录目录现状分析01愿景目标02运维管理03软件过程管理04运维管理体系运维团队运维团队运运维过程维过程团队角色角色职责素质要求人员组成运维规范质量考核规范工作内容界定制度规范制度规范运维流程运维流程运维监控运维监控ITIL 运维体系运维体系对象界定对象界定安安全全管管控控采集平台采集平台质质量量管管控控监控中心监控中心应用中心应用中心知识管理知识管理流程协作流

6、程协作协作监控协作监控事件升级事件升级团队建设角色角色职能职能素质素质运维经理主管运维团队内部管理，沟通，对外沟通工作5年以上移动项目运维管理经验。3年以上移动大型项目运维经验。分析师将运维事件原因分析，策略定制，运维项目设计合理性分析等6年以上移动项目经验。5年以上担任系统架构，系统分析师经验熟悉各种分析工具与方法ORACLE DBA对于运维项目数据库进行管理，包括巡检，故障处理，参数设置，热备等具有DBA专业证书3年以上oracle数据库管理经验服务台接收系统使用者反映事件，包含咨询，查证，故障，并对时间进行ITIL单初步填写以及相关症状初判良好的沟通能力以及服务态度项目故障相关基础故障知

7、识良好问题描述能力j2ee维护工程师相关j2ee项目故障，问题原因分析，故障处理等工作执行者2年以上移动项目开发经验熟悉oracle基础SQL,mvc模型框架知识C+维护工程师相关C+项目故障判断，故障处理等工作执行者4年以上C+项目经验，熟悉oracle数据库熟悉IBM MQ中间件，精通unix系统编程WIDGET维护工程师相关手机安卓系统WIDGET客户端相关故障判断，故障处理工作执行者2年以上手机软件开发经验1年移动项目经验测试工程师故障处理后测试，或者项目交接过程测试验收工作执行者3年测试经验，熟悉黑盒，白盒测试方法，熟悉各类测试工具团队建设是基础，运维团队必须团队建设是基础，运维团队

8、必须是一个多角色，角色人员素质高，是一个多角色，角色人员素质高，运维经验丰富的高效成熟团队！运维经验丰富的高效成熟团队！运维流程-概述FMKR运维流程管理：运维流程管理：结合实际按规范建立六大流程故障，问题，提数，发布，变更，交接流程。定义流程各角色职能协作流转。运维过程监控：运维过程监控：对于运维事件协作过程分层级（红色，橙色，黄色等）进行监控预警。触发点事件环节流传点通知提醒，事件处理时间超期提醒，事件紧急处理提醒，事件升级告警运维知识管理：运维知识管理：运维过程知识体系，包括项目文档，常见业务咨询问答，常见故障问题解决,支撑服务台人员对于事件甑别，事件初检。运维过程事件职能分析成知识。运

9、维事件升级管理：运维事件升级管理：事件在规定的时间内不能由一线支持小组解决，那么更多有经验的人员和有更高权限的人员将不得不参与进来。运维流程主要是通过流程协作的形式对于运维过程中运维事件进行处理。建立维护工作平台维护工作平台管理积累运维知识，记录运维流程轨迹，并对整个运维过程管控。包含四个部分：运维流程管理，运维知识管理，运维过程监控，运维事件升级管理。运维流程管理，运维知识管理，运维过程监控，运维事件升级管理。运维流程-流程呈现通过目前流行的地图呈现形式，将运维流程各关键流程节点直观展现，详细描述已经流转节点以及预计描述未来节点走向。节点中呈现相关节点信息。发起人:发起时间发起人描述到达时间

10、处理人预期完成时间实际完成时间处理情况描述处理评分预计到达时间预计处理时间流程发起节点一当前节点节点三 【MPT20122011200001】属于提数流程，目前处于正在处理状态，完成度为50%,当前处于第二节点，距离预警时间为2小时，工单紧急度为一般到达时间处理人预期完成时间实际完成时间剩余处理时间WEB门户手机WIDGET桌面WIDGET展现渠道运维流程-故障，问题流程一输入客户服务台维护工程师运维经理输出发起阶段处理阶段电话,邮件,QQ,工单开始开始事件发起事件发起有效有效性性ITIL单登记单登记FAQ解决解决单独单独处理处理编写处理方案编写处理方案执行处理方案执行处理方案事件升级事件升级

11、反馈客户结果反馈客户结果验证结果验证结果FAQITIL事事件单件单ITIL归档归档YNYNY 故障，问题流程根据发起人的不同分为外部流程与内部流程。外部流程发起人为运维项目使用人员，内部流程是运维团队内部人员在巡检，稽核，或者使用过程中发现的故障，问题。本流程为外部流程运维流程-故障，问题流程二团队成员服务台维护工程师运维经理输出处理阶段开始开始事件发起事件发起ITIL单登记单登记FAQ解决解决单独单独处理处理编写处理方案编写处理方案执行处理方案执行处理方案事件升级事件升级反馈结果反馈结果验证结果验证结果FAQITIL事事件单件单ITIL归档归档YNNY 本流程是内部流程运维流程-提数，发布，

12、变更流程流程规范1提数规范模式借鉴软件开发规范中的快速开发模式，必须由主提数人，副提数人各自提数进行对比校验，确定统一口径后由审核人员审核。风险评估1版本发布之前，需要对发布风险进行预前评估，包括发布版本导致业务风险，系统内风险，外围系统影响风险等，发布前出示风险评估文档以及发布操作步骤文档。恢复机制2发布过程具有不可控因素影响发布实际效果，在风险规避的基础上，对于不可以规避的突发风险需要预先设计恢复方案，以其风险发生可以恢复发布之前状态。提数要素2提数过程中，交接给下一审批人必须完成以下要素的填写:提数周期，数据简介，数据量，数据SQL脚本（包含SQL脚本注释），数据说明等提数流程提数流程发

13、布流程发布流程 目前提数流程目前有支撑系统综合支撑平台，一单清平台，两平台对于提数流程支撑能力充足。在现有资源的基础上，对于提数流程进行相关流程关键点进行强制执行，对流程短板进行补充，确保流程执行正确性以及可恢复性。变更流程在2011年综合支撑平台根据运营管理室意见进行改善，已经比较完善。暂时利用已有资源。发布流程也有相应流程易平台进行支撑，在原有基础上对于发布流程的短板进行补充。运维流程-运维交接流程开发团队运维团队提交运维提交运维申请申请提交软件提交软件文档文档检查文档检查文档质量质量合格？合格？测试软件质测试软件质量量填写填写 测试结测试结果果合格？合格？重新重新交接交接交接交接成功成功

14、输出 注注:交接过程中，提交的软件文档一般包含需求说明书，概要说明书，详细设计说明书，数据字典，测试报告，试运行情况报告分析，部署文档等，必须保持项目实际情况与文档一致性。运维团队测试包含功能测试，用户测试，业务逻辑测试，集成测试，压力测试，需要在流程中填写相关的测试总结以及上传测试报告，不合格需要说明不合格原因。以上过程需要再严格的规范下进行，不然，流程会因为只是个形式而失败，达不到预期效果 开发团队将软件项目交接给运维团队进行项目运维，该过程是一个责任过度的过程，需要严格的规范以及流程进行支撑。该部分叫做运维交接流程。运维流程-运维知识管理 整个运维过程中，知识的积累沉淀，传承至关重要，可

15、以有效的避免对同一事件重复运维以及由于人员流动导致知识流失。良好的知识库体系应当包含知识广泛的收集渠道能力，知识强大的管理能力，知识有效的应用能力。知识分类智能检索知识应用能力知识地图知识视图业务培训问卷调查知识采集知识共享知识审核知识评价知识推荐知识传播知识服务组件常用FAQ管理知识版本管理知识管理能力在线考试知识收集能力人工收集其他知识系统收集智能分析知识收集知识渠道展现运维团队成员使用用户客户电脑平板手机ITC人员运维流程-预警监控 预警监控主要对运维流程监控，通过设定预警规则，生成预警信息，后台自动调度的方式将预警信息推送。预警过程的紧急度以及影响度，根据具体处理情况以及历史预警日志，

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

17、人员和有更高权限的人员将不得不参与进来。这就是升级，它可能发生在事件解决过程的任何时间和任何支持级别,升级分为职能性升级和结构性升级。两者的区别如下：职能性升级:需要具有更多时间、专业技能或访问权限（技术授权）的人员来参与事件的解决结构性升级:当经授权的当前级别的结构不能保证事件能及时、满意地解决时，需要更高级别的机构参与进来运维过程中应当尽量在运维团队内解决，避免结构性升级运维工程师无法完成事件无法完成事件产出项目经理内部专业工程师外围开发团队/移动技术部门协调资源协调资源解决解决协调资源协调资源组织团队解决组织团队解决解决方案解决方案职能性升级职能性升级结结构构性性升升级级YN运维流程-制

18、度规范 运维过程中，运维工作如何界定，项目交接给运维团队时机以及交接要求，运维人员对事件如何正确处理等都属于运维制度规范内容。工作内容界定工作内容界定 交接规范交接规范管理制度规范管理制度规范 涉及运维过程中已经交接运维团队项目提数，咨询，查证，数据库库巡检，数据稽核，服务器巡检,服务器漏洞修复，应急演练，故障处理，故障发现，数据修改，项目报告等新项目需稳定运行3个月以上时间才能交接给运维组新项目交接给运维组必须对接手维护的同事做系统业务培训项目交接必须提供 项目需求文档.doc项目操作手册.doc项目维护手册.doc 项目常见问题处理.doc 项目详细设计文档.doc 项目数据字典服务时间响

19、应规范：规范服务方式，故障级别相应服务行为规范现场服务支持规范ITIL单操作规范运维监控-监控平台 目前ITC自建系统应用较多。影响业务流程可用性因子很多。如何变被动为主动，对事件进行事前管理，快速发现问题，智能分析故障，减少运维过程中事件带来不良影响力以及大量运维工作量。建立完善的运维监控平台，以电子监控的形式辅助运维，提升运维效率以及业务功能可靠性。展现渠道监控中心采集平台监控对象应用中心网络系统操作系统业务系统接口系统采集工具集成采集方式采集调度监控规则监控视图报表中心安全审计智能提数电脑平板手机数据中心告警级别告警调度告警规则信息推送运维流程-监控对象网络系统网络系统监控点:网络互通、

20、端口开放情况、网络权限、网络延迟等监控频率:实时监控操作系统操作系统监控点:CPU使用、内存使用、硬盘使用、用户数、进程数等适用系统:windows,unix监控频率:实时监控业务系统业务系统监控点:系统状态、占用内存、链接数、关键业务状态等监控方式:间隔频率监控接口系统接口系统监控点:FTP可用性、web service可用性、servlet等监控方式:间隔频率监控重点重点关注关注运维流程-监控中心 在IT日益发展的当今，业务与IT已经紧密结合.一个IT项目的关联着系统，数据库，应用，网络，业务，用户等多方面因素。对单个IT资源进行监控已经越来越满足不了IT运维需求。集成传统的监控方式，将整

21、体业务作为主体，构建业务监控视图。监控主要体现为四字原则:看、监、析、告看得见:可以的通过网络拓扑图的这种表现形式将检测点以及检测点周边环境直观呈现，一目了然监得到:对于监控点进行多层级别监控，通过监控规则快速识别监控点异常。析得清:通过对监控点设置规则，监控中心可以对故障进行智能分析，检查，主动将故障发生的关注点告知运维人员告得快:通过手机短信，手机widget监控视图，WEB视图，EAMIL等多种方式，将监控问题故障及时准确的发给运维人员。监控中心成功四要素1234运维流程-经典案例采集平台案例：支持开发接口采集，分布式采集等多种采集策略，自动将采集数据归类,监控平台案例：主要业务可用监控

22、，系统使用情况，占用资源监控,目标操作系统状态监控安全审计案例：模型视图化设置审计规则，自动审计目标数据，生成审计报告主动推送报表中心案例：模型视图化配置报表，选择报表样式，支持手机端，PC端报表预订与定制采集监控应用呈现体系目录目录现状分析01愿景目标02运维管理03软件过程管理04软件过程管理 运维过程中，运维效率以及运维实际工作量是运维成本的两大关键因素。对于运维实际工作量的决定因素为业务项目多少以及项目健康度。因此，以CMMI为理论体系，注重软件过程管理，保证项目开发质量，减少项目运维过程中故障可以有效减少运维实际工作量。当前东莞自建系统大多数项目处于已管理级别-已定义级之间，初期目标

23、为完全实现已定义级别。实现软件过程文档化，后期由被动变主动，主动识别软件风险与缺陷，量化整个软件过程。优化管理级优化管理级可集中精力改进过程，采用新技术、新方法。拥有防止出现缺陷、识别薄弱环节以及加以改进的手段。量化管理级量化管理级对软件过程和产品质量的详细度量数据，对软件过程和产品都有定量的理解与控制。已管理级已管理级制定了必要的过程纪律，能重复早先类似应用项目取得的成功经验已定义级已定义级已将软件管理和工程两方面的过程文档化、标准化，并综合成该组织的标准软件过程。初始初始级级软件过程是无序的，有时甚至是混乱的，对过程几乎没有定义，取决与个人。CMMI能力成熟度模型项目需求阶段 客户提出诉求

24、，研发团队被动接受，然后通过软件手段将客户描述的诉求编写成计算机语言这种方式在目前移动环境中普遍存在。诉求梳理，整理成需求是软件过程中非常重要一部分，诉求的理解偏差可能导致软件项目的延期甚至失败。量化业务需求，多角色参与需求沟通评审是避免需求理解偏差有效手段。加强团队需求理解能力引入项目监理角色强制执行沟通评审鉴于业务之间相关性强，而业务需求人提出业务需求具有片面性，不完整性，所以在需求沟通中提出业务需求比较散乱，无体系。故要求研发团队需求人员需要在项目需求阶段了解业务体系环境，正确定位当前业务具体内容，圈定业务范围，综合考虑业务扩展性以及预前提炼项目能力运维团队如何快速交接研发团队研发项目，

25、关键因素是对于项目业务比较熟悉。组建运维团队后，将运维团队在软件过程中定位另外角色-项目监理，实现项目过程B角角色，同时可以提升需求质量 强制ITC,业务人员，项目监理，研发团队对于需求文档业务内容进行会议沟通，新增需求会议评审团，重点审核需求中业务理解正确性，需求中业务量化性，原型设计模型合理性，减少需求理解偏差以及需求中模糊业务内容。提升需求文档质量需求文档是项目团队与需求人员沟通的桥梁，当前主要模式是需求人员简单描述-项目团队细化，由于技术人员与业务人员理解业务角度不一致，往往需求阅读过程中存在难懂等问题。需求文档中引入原型设计模型，实现需求视图化预先展现，加强关键业务逻辑流程图化，文字

26、详尽化描述。项目开发阶段 需求确定产出需求说明书后，项目进入研发阶段，设计前识别研发过程中技术问题，设计中出具详细的设计文档，实现阶段严格按照统一编码规范进行编码是软件项目质量保证，风险规避关键因素。代码走查常态化强制详细设计文档评审沉淀技术研究成果项目测试&运维测试&运维试运行结束，实施运维交接，研发团队需要对运维团队进行项目培训，并提供常见问题说明书等文档。运维交接项目经过单元测试，集成测试，系统测试，验收测试测试方式主动识别软件故障。改变测试观念，加强测试人员的程序测试的过程具有破坏性认知。系统测试 加强用户验收环节，新增用户项目体验环节，增强项目的可操作性，易操作性。针对立项管理的要点

27、以及开发研发计划，进行结项审计，找出项目实际能力与预期目标的差异，总结差异原因，沉淀项目经验。用户验收&结项管理，,，,，,，等项目产出文档 项目试运行三个月，最大限度在实际生产环境中排查故障，保证试运行完毕后正式运行程序的稳定性，产出试运行报告。试运行报告教你写字 下面是赠送的下面是赠送的PPT模板不需要朋友可以下载模板不需要朋友可以下载后编辑删除！谢谢！后编辑删除！谢谢！感恩 父母天冷时，是他们给你送来温暖有时，他们会对我们发火感恩父母感谢你们把我带到了这个世界感谢你们给了我自由的空气感谢你们 谆谆的教导 殷殷的嘱托 我长大了 而你们却老了 谁言寸草心 报得三春晖 我会向你们献上一片诚挚的

28、孝心 祝你们永远健康 对部门及岗位职责的理解 系统集成（SI，System Integration）：就是通过结构化的综合布线系统和计算机网络技术，将各个分离的设备(如个人电脑)、功能和信息等集成到相互关联的、统一和协调的系统之中，使资源达到充分共享，实现集中、高效、便利的管理。系统集成项目项目实施实施售后售后运维运维负责集成项目软、硬件产品与网络设备的安装、调试及使用培训、售前技术支持。负责项目及相关技术问题的跟踪和解决，售后设备维护工作。岗位职责三、工作总结 项目运维 项目实施 银青高速l 无线网桥l 视频监控 东毛隧道l 语音电话l 人员定位基站l 隧道监控l 停车场项目全面实施（IP设

29、置）银青路基五标贵州独平高速项目全面实施（监控室机柜布线）四、心得体会 在这段时间的学习过程中，我对部门很多产品从零学起，刚到公司的时候感觉压力很大，经过这些时间的认真学习和实际操作，调整心态，现已完全能融入公司的各项岗位职责和管理制度中。这些时间，感觉不仅仅是工作技能的提深，更宝贵的是对我人生观念和工作认识有了很大的改变，还让我对工作流程和工作方法有了深刻的体会。由于到达公司时间较短，不可能一下子将公司所有产品亲自操作一遍，但通过公司相关文档的学习收获颇多。希望以后有机会多多参加这些的项目。“九层之台，起于垒土；千里之行，始于足下”只有通过工作中的点点滴滴，脚踏实地做事，才能成为一名优秀的集成工程师。五、职业发展规划第二阶段低姿态起步、踏实做事虚心请教，加强相关产品学习成为一名优秀的集成项目管理工程师 相关证件的考取项目管理流程的学习第一阶段第三阶段