基于Django的运维故障管理系统设计与实现.docVIP

基于Django的运维故障管理系统设计与实现.doc

  1. 1、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。。
  2. 2、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  3. 3、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
  4. 4、该文档为VIP文档,如果想要下载,成为VIP会员后,下载免费。
  5. 5、成为VIP后,下载本文档将扣除1次下载权益。下载后,不支持退款、换文档。如有疑问请联系我们
  6. 6、成为VIP后,您将拥有八大权益,权益包括:VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。
  7. 7、VIP文档为合作方或网友上传,每下载1次, 网站将根据用户上传文档的质量评分、类型等,对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档
查看更多
基于Django的运维故障管理系统设计与实现 摘 要:随着时代的高速发展,全面信息化时代逐渐来临,国内企业信息化越来越深入, 这是一个很好的局面,随之而来也产生了很多问题,IT运维部门的负担越来 月严重,IT设备和软件的运行维护工作都是他们负责,在新形式下,这份工作变得越来越复杂,技术难度也提高了不少档次,所以成为一个优秀的运维人员并不是一个轻松的活,要求严格已经到了一个新高度。首先,无法否认的是IT设备与软件越来越大程度地参与到实际的生产过程中并且承担的角色也越来越重要。当生产过程中这些设备与软件发生故障时,将对企业造成不可避免的巨大影响,那么如何快速的捕获故障信息并且定位故障原因,对于运维人员来说,是能极大提高解决故障效率的因素,从而降低企业损失,很多企业更愿意投资部署一套运维管理系统来提高运维效率,本课题就是基于Django框架所设计的运维故障管理方案。 通过在企业实际生产环境上的运维需求调研,运维故障管理系统需要实现一些基本功能,诸如:故障管理,故障统计,用户管理以及邮箱管理。 本系统开发过程,经过学习,以软件工程项目开发过程标准为参考,遵循开发步骤。参考面向对象的方法设计数据库,系统的设计与实现运用了Python语言中的Django网页应用开发框架并采用B/S网络应用结构,数据库使用开源数据库MySQL。 关键词:Django ; Python; B/S; MySQL 前 言 运维是企业内比较常态的事务,也许并没有主功能系统使用那么频繁,但是其频率也是比较高的。信息化时代下,IT运维更显重,当IT运维故障发生时,如何有效地通知到运维人员,并详细描述故障发生时的现象,可以很好地帮助运维人员排查故障原因并实施解决方案。在运维故障处理思路中,基本的方法是:首先,确定故障现象并初判问题影响,故障现象直接决定了故障应急解决方案的制定。其次,应急恢复,故障发生后,并且故障无法立刻解决,那么系统是否能保证可用就全靠应急方案的合理了,然后快速定位问题,最后解决故障。解决故障之后,能够完善监控对未来运维中可能出现的故障起着非常关键的作用。 运维故障管理系统是为满足故障解决思路中的基本方法的基础需求所设计的方案。系统设计了一些基本模块,这些模块将作为实现运维故障管理的功能,包括故障管理,故障统计,以及故障反馈等功能,在理想情况下,系统算是完成了运维故障管理的基本任务。 本文主要介绍系统功能的设计与实现,以及数据库的搭建,阐述了需求分析,系统设计与系统实现的全过程。 本系统采用B/S结构(Browser /Server 结构),采用Pycharm作为开发工具,Mysql作为后台数据库,通过该系统能够提高运维人员在日常运维中的效率,从而进一步保障企业的正常运作,对于企业本身而言,在生产环境中运用该系统是极具意义价值的。该系统的定位并非企业生产环境中的主功能系统,而是作为辅助工具,帮助企业提高运作效率。 第一章 绪论 在本章中会介绍系统开发研究背景,简单地说明了本文所做的主要工作和以及在企业日常运维中系统所起到的意义,最后介绍了一下本文的组织目录,以供参考。 1.1 论文研究背景 运维故障是日常运维中比较高频发生的且具有损害影响的事件,涉及故障解决,通常都会有常见方法,这些方法都是常识性的认知,并没有特殊的优良效果,在故障发生时,当然应该以解决故障为首要目标,至于采取何种手段,作为决策人员并不关心,当故障解决之后,情况并没有那么的紧急,这才考虑方法优化的问题。故障解决的常见方法,我们将假设一条工作流来进行说明,按步骤分解,工作流的第一步,确定故障现象,初判问题影响,这将是处理问题的基础,运维人员如果无法得知故障现象,解决故障从何谈起,只有知晓了故障现象才能制定一些应急方针,来降低损失,一个熟悉整套系统功能运作的运维人员必然能从故障现象中判断出故障影响。第二步,故障发生后,也许有些故障可以立即恢复,但仍然有一些故障并不能立刻解决,这与运维人员的能力无关,那这种故障也不能一直挂着处于未修复状态,不然会一直影响着线上生产。这是就需要应急恢复,保证系统是否可用,这绝对关乎运维人员的能力问题,或者说是运维团队,应急恢复的有效性是检验系统可用的关键指标。应急方案根据第一步的现象来制定,需要额外注意的是,在故障应急恢复之前,如果条件允许,应当尽可能保存当前场景。第三,快速定位故障原因,可以通过几个逻辑:是否为偶发、是否可重现,是否进行过变更,是否可缩小范围,是否有足够的日志等等。故障现象是否可以重现,对于快速解决问题很重要,如果故障为、偶发性,对运维人员是一件十分头疼的事,不仅时时刻刻担心着故障是否会再次发生影响系统运行,还要纠结于故障定位,因为偶发的故

您可能关注的文档

文档评论(0)

潇湘画里 + 关注
实名认证
文档贡献者

该用户很懒,什么也没介绍

1亿VIP精品文档

相关文档