软件运维方案.ppt

单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,*,*,单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,*,*,单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,*,*,单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,*,*,单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,*,*,单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,*,*,单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,*,*,单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,*,*,单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,*,*,单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,*,*,软件运维方案,目录,现状分析,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,年测试经验，熟悉黑盒，白盒测试方法，熟悉各类测试工具,团队建设是基础，运维团队必须是一个多角色，角色人员素质高，运维经验丰富的高效成熟团队！,运维流程,-,概述,F,M,K,R,运维流程管理：,结合实际按规范建立,六,大流程故障，问题，提数，发布，变更，交接流程。定义流程各角色职能协作流转。,运维过程监控：,对于运维事件协作过程分层级（红色，橙色，黄色等）进行监控预警。触发点事件环节流传点通知提醒，事件处理时间超期提醒，事件紧急处理提醒，事件升级告警,运维知识管理：,运维过程知识体系，包括项目文档，常见业务咨询问答，常见故障问题解决,支撑服务台人员对于事件甑别，事件初检。,运维过程事件职能分析成知识。,运维事件升级管理：,事件在规定的时间内不能由一线支持小组解决，那么更多有经验的人员和有更高权限的人员将不得不参与进来。,运维流程主要是通过流程协作的形式对于运维过程中运维事件进行处理。建立,维护工作平台,管理积累运维知识，记录运维流程轨迹，并对整个运维过程管控。,包含四个部分：,运维流程管理，运维知识管理，运维过程监控，运维事件升级管理。,运维流程,-,流程呈现,通过目前流行的,地图呈现,形式，将运维流程各关键流程节点直观展现，详细描述已经流转节点以及预计描述未来节点走向。节点中呈现相关节点信息。,发起人,:,发起时间,发起人描述,到达时间,处理人,预期完成时间,实际完成时间,处理情况描述,处理评分,预计到达时间,预计处理时间,流程发起,节点一,当前节点,节点三,【MPT20122011200001】,属于,提数流程,，,目前处于,正在处理,状态，完成度为,50%,当前处于,第二节点,，距离预警时间为,2,小时,，工单紧急度为,一般,到达时间,处理人,预期完成时间,实际完成时间,剩余处理时间,WEB,门户,手机,WIDGET,桌面,WIDGET,展现渠道,运维流程,-,故障，问题流程一,输入,客户,服务台,维护工程师,运维经理,输出,发起阶段,处理,阶段,电话,邮件,QQ,工单,开始,事件发起,有效性,ITIL,单登记,FAQ,解决,单独,处理,编写处理方案,执行处理方案,事件升级,反馈客户结果,验证结果,FAQ,ITIL,事件单,ITIL,归档,Y,N,Y,N,Y,故障，问题流程根据发起人的不同分为外部流程与内部流程。外部流程发起人为,运维项目使用,人员，内部流程是,运维团队内部人员,在巡检，稽核，或者使用过程中发现的故障，问题。本流程为外部流程,运维流程,-,故障，问题流程二,团队成员,服务台,维护工程师,运维经理,输出,处理,阶段,开始,事件发起,ITIL,单登记,FAQ,解决,单独,处理,编写处理方案,执行处理方案,事件升级,反馈结果,验证结果,FAQ,ITIL,事件单,ITIL,归档,Y,N,N,Y,本流程是内部流程,运维流程,-,提数，发布，变更流程,流程规范,1,提数规范模式借鉴软件开发规范中的快速开发模式，必须由主提数人，副提数人各自提数进行对比校验，确定统一口径后由审核人员审核。,风险评估,1,版本发布之前，需要对发布风险进行预前评估，包括发布版本导致业务风险，系统内风险，外围系统影响风险等，发布前出示风险评估文档以及发布操作步骤文档。,恢复机制,2,发布过程具有不可控因素影响发布实际效果，在风险规避的基础上，对于不可以规避的突发风险需要预先设计恢复方案，以其风险发生可以恢复发布之前状态。,提数要素,2,提数过程中，交接给下一审批人必须完成以下要素的填写,:,提数周期，数据简介，数据量，数据,SQL,脚本（包含,SQL,脚本注释），数据说明等,提数流程,发布流程,目前提数流程目前有支撑系统综合支撑平台，一单清平台，两平台对于提数流程支撑能力充足。在现有资源的基础上，对于,提数流程进行相关流程关键点进行强制,执行，对流程短板进行补充，确保流程执行正确性以及可恢复性。,变更流程在,2011,年综合支撑平台根据运营管理室意见进行改善，已经比较完善。暂时,利用已有资源,。发布流程也有相应流程易平台进行支撑，在原有基础上对于,发布流程的短板,进行补充。,运维流程,-,运维交接流程,开发团队,运维团队,提交运维申请,提交软件文档,检查文档质量,合格？,测试软件质量,填写 测试结果,合格？,重新,交接,交接,成功,输出,注,:,交接过程中，提交的软件文档一般包含需求说明书，概要说明书，详细设计说明书，数据字典，测试报告，试运行情况报告分析，部署文档等，必须保持项目实际情况与文档一致性。,运维团队测试包含功能测试，用户测试，业务逻辑测试，集成测试，压力测试，需要在流程中填写相关的测试总结以及上传测试报告，不合格需要说明不合格原因。,以上过程需要再严格的规范下进行，不然，流程会因为只是个形式而失败，达不到预期效果,开发团队将软件项目交接给运维团队进行项目运维，该过程是一个责任过度的过程，需要严格的规范以及流程进行支撑。该部分叫做,运维交接流程。,运维流程,-,运维知识管理,整个运维过程中，知识的积累沉淀，传承至关重要，可以有效的避免对同一事件,重复运维,以及由于人员流动导致,知识流失,。,良好的知识库体系应当包含,知识广泛的收集渠道能力，知识强大的管理能力，知识有效的应用能力,。,知识分类,智能检索,知识应用能力,知识地图,知识视图,业务培训,问卷调查,知识采集,知识共享,知识审核,知识评价,知识推荐,知识传播,知识服务组件,常用,FAQ,管理,知识版本管理,知识管理能力,在线考试,知识收集能力,人工收集,其他知识系统收集,智能分析知识收集,知识渠道展现,运维团队成员,使用用户,客户,电脑,平板,手机,ITC,人员,运维流程,-,预警监控,预警监控主要对运维流程监控，通过设定,预警规则,，生成,预警信息,，后台,自动调度,的方式将预警信息推送。,预警过程的,紧急度,以及,影响度,，根据具体,处理情况,以及,历史预警日志,，系统智能将,预警信息升级,。,预警分析,监控点采集,自动调度,信息推送,预警流程,涉及到运维流程中的事件到达提醒，事件将超期提醒，事件逾期通告,对采集点进行监控，通过预设定规则，区分紧急度，信息接收对象生成预警信息,依据时间，事件紧急程度等实际情况，系统智能按频率触发监控，推送流程,依据接收人不同的角色信息，推送相应的预警信息,按运维流程紧急度，严重度，相应处理时间限制将预警级别划分为,红，橙，黄,警告,根据流程,紧急度，严重度，处理时间限制,等规则化时间升级条件，满足条件事件流程自动升级，并进行预警,流程升级,运维流程,-,事件升级,如果某一事件不能在规定的时间内由一线支持小组解决，那么再多有经验的人员和有更高权限的人员将不得不参与进来。这就是升级，它可能发生在事件解决过程的,任何时间,和,任何支持级别,升级分为,职能性升级,和,结构性升级,。两者的区别如下：,职能性升级,:,需要具有更多时间、专业技能或访问权限（技术授权）的人员来参与事件的解决,结构性升级,:,当经授权的当前级别的结构不能保证事件能及时、满意地解决时，需要更高级别的机构参与进来,运维过程中应当尽量在运维团队内解决，,避免结构性升级,运维工程师,无法完成事件,产出,项目经理,内部专业工程师,外围开发团队,/,移动技术部门,协调资源,解决,协调资源,组织团队解决,解决方案,职能性升级,结构性升级,Y,N,运维流程,-,制度规范,运维过程中，,运维工作如何界定,，,项目交接给运维团队时机以及交接要求,，,运维人员对事件如何正确处理,等都属于运维制度规范内容。,工作内容界定,交接规范,管理制度规范,涉及运维过程中已经交接运维团队项目提数，咨询，查证，数据库库巡检，数据稽核，服务器巡检,服务器漏洞修复，应急演练，故障处理，故障发现，数据修改，项目报告等,新项目需稳定运行,3,个月以上时间才能交接给运维组,新项目交接给运维组必须对接手维护的同事做系统业务培训,项目交接必须提供,项目需求文档,.doc,项目操作手册,.doc,项目维护手册,.doc,项目常见问题处理,.doc,项目详细设计文档,.doc,项目数据字典,服务时间响应规范：规范服务方式，故障级别相应,服务行为规范,现场服务支持规范,ITIL,单操作规范,运维监控,-,监控平台,目前,ITC,自建系统应用较多。影响业务,流程可用性,因子,很多。如何变,被动为主动,，对事件进行,事前管理,，快速发现问题，,智能分析故障,，减少运维过程中事件带来不良影响力以及大量运维工作量。,建立完善的,运维监控平台,，以电子监控的形式辅助运维，提升运维效率以及业务功能可靠性。,展现渠道,监控中心,采集平台,监控对象,应用中心,网络系统,操作系统,业务系统,接口系统,采集工具集成,采集方式,采集调度,监控规则,监控视图,报表中心,安全审计,智能提数,电脑,平板,手机,数据中心,告警级别,告警调度,告警规则,信息推送,运维流程,-,监控对象,网络系统,监控点,:,网络互通、端口开放情况、网络权限、网络延迟等,监控频率,:,实时监控,操作系统,监控点,:CPU,使用、内存使用、硬盘使用、用户数、进程数等,适用系统,:,windows,unix,监控频率,:,实时监控,业务系统,监控点,:,系统状态、占用内存、链接数、关键业务状态等,监控方式,:,间隔频率监控,接口系统,监控点,:FTP,可用性、,web service,可用性、,servlet,等,监控方式,:,间隔频率监控,重点关注,运维流程,-,监控中心,在,IT,日益发展的当今，业务与,IT,已经紧密结合,.,一个,IT,项目的关联着,系统，数据库，应用，网络，业务，用户,等多方面因素。对单个,IT,资源进行监控已经越来越满足不了,IT,运维需求。集成,传统的监控方式,，将整体业务作为主体，构建,业务监控视图,。,监控主要体现为四字原则,:,看、监、析、告,看得见,:,可以的通过网络拓扑图的这种表现形式将检测点以及检测点周边环境直观呈现，一目了然,监得到,:,对于监控点进行多层级别监控，通过监控规则快速识别监控点异常,。,析得清,:,通过对监控点设置规则，监控中心可以对故障进行智能分析，检查，主动将故障发生的关注点告知运维人员,告得快,:,通过手机短信，手机,widget,监控视图，,WEB,视图，,EAMIL,等多种方式，将监控问题故障及时准确的发给运维人员。,监控中心成功四要素,1,2,3,4,运维流程,-,经典案例,采集平台案例：,支持开发接口采集，分布式采集等多种采集策略，自动将采集数据归类,监控平台案例：,主要业务可用监控，系统使用情况，占用资源监控,目标操作系统状态监控,安全审计案例：,模型视图化设置审计规则，自动审计目标数据，生成审计报告主动推送,报表中心案例：,模型视图化配置报表，选择报表样式，支持手机端，,PC,端报表预订与定制,采集,监控,应用,呈现,体系,目录,现状分析,01,愿景目标,02,运维管理,03,软件过程管理,04,软件过程管理,运维过程中，,运维效率,以及,运维实际工作量,是运维成本的两大关键因素。对于运维实际工作量的决定因素为业务项目多少以及,项目健康度,。因此，以,CMMI,为理论体系,，注重,软件过程管理,，保证项目开发质量，减少项目运维过程中故障可以有效减少运维实际工作量。,当前东莞自建系统大多数项目处于,已管理级别,-,已定义,级之间，初期目标为完全实现,已定义级别,。,实现软件过程,文档化，,后期由被动变主动，,主动识别,软件风险与缺陷，量化,整个软件过程,。,优化管理级,可集中精力改进过程，采用新技术、新方法。拥有防止出现缺陷、识别薄弱环节以及加以改进的手段,。,量化管理级,对软件过程和产品质量的详细度量数据，对软件过程和产品都有定量的理解与控制,。,已管理级,制定了必要的过程纪律，能重复早先类似应用项目取得的成功经验,已定义级,已将软件管理和工程两方面的过程文档化、标准化，并综合成该组织的标准软件过程,。,初始级,软件过程是无序的，有时甚至是混乱的，对过程几乎没有定义，取决与个人,。,CMMI,能力成熟度模型,项目需求阶段,客户提出诉求，研发团队被动接受，然后通过软件手段将客户描述的诉求编写成计算机语言这种方式在目前移动环境中普遍存在。,诉求梳理，整理成需求是软件过程中非常重要一部分，诉求的理解偏差可能导致软件,项目的延期,甚至,失败,。,量化业务需求,，,多角色参与需求沟通评审,是避免需求理解偏差有效手段。,加强团队需求理解能力,引入项目监理角色,强制执行沟通评审,鉴于业务之间相关性强，而业务需求人提出业务需求具有片面性，不完整性，所以在需求沟通中提出业务需求比较散乱，无体系。故要求研发团队需求人员需要在项目需求阶段了解业务体系环境，正确定位当前业务具体内容，,圈定业务范围，综合考虑业务扩展性以及预前提炼项目能力,运维团队如何快速交接研发团队研发项目，关键因素是对于项目业务比较熟悉。组建运维团队后，将运维团队在软件过程中定位另外角色,-,项目监理,，实现项目过程,B,角角色,，同时可以提升需求质量,强制,ITC,业务人员，项目监理，研发团队对于需求文档业务内容进行会议沟通，新增需求,会议评审团,，重点审核需求中,业务理解正确性,，需求中,业务量化性，原型设计模型合理性，,减少需求,理解偏差,以及需求中,模糊业务内容,。,提升需求文档质量,需求文档是项目团队与需求人员沟通的桥梁，当前主要模式是需求人员简单描述,-,项目团队细化，由于技术人员与业务人员理解业务角度不一致，往往需求阅读过程中存在难懂等问题。需求文档中引入,原型设计模型,，实现需求视图化预先展现，加强关键业务逻辑流程图化，文字详尽化描述。,项目开发阶段,需求确定产出需求说明书后，项目进入研发阶段，设计前,识别研发过程中技术问题,，设计中出具,详细的设计文档,，实现阶段严格按照,统一编码规范进行编码,是软件项目质量保证，风险规避关键因素。,代码走查常态化,强制详细设计文档评审,沉淀技术研究成果,项目测试,&,运维,测试,&,运维,4,试运行结束，实施运维交接，研发团队需要对运维团队进行项目培训，并提供常见问题说明书等文档。,运维交接,1,项目经过单元测试，集成测试，系统测试，验收测试测试方式主动识别软件故障。改变测试观念，加强测试人员的,程序测试的过程具有破坏性认知,。,系统测试,2,加强用户验收环节，新增用户,项目体验,环节，增强项目的可操作性，易操作性。,针对立项管理的要点以及开发研发计划，进行结项审计，找出项目实际能力与预期目标的差异，,总结差异原因，沉淀项目经验,。,用户验收,&,结项管理,5,，,，,，,，,，,，,等,项目产出文档,3,项目试运行三个月，最大限度在实际生产环境中排查故障，保证试运行完毕后正式运行程序的稳定性，,产出试运行报告,。,试运行报告,感谢您的聆听！,