春节在即 RIIL助企业避免网络“节后综合症”

  • 来源: CCTIME   2013-01-31/10:02
  • 忙碌的一年即将结束,春节长假将至,人们终于可以放松紧绷的神经放松几天了。然而,大多数企事业单位的网络却不会因假期停止运转,当一些小的问题或故障在节日期间发生,而IT管理人员又不能第一时间发现的话,节假日结束后,可能就会花费大量工作时间来处理积累的问题,恢复业务系统,给年初紧张的工作带来压力。如何避免网络的“节后综合症”,在保证IT管理人员安心过年的基础上,让企业网络业务系统在龙年有一个完美的结尾、在蛇年有一个闪亮的开始呢?锐捷网络推出的RIIL(RealtimeIntelligentInfrastructureLibrary)IT综合业务管理平台,给出了自己的答案。

    节前:做好IT与业务系统检测

    现如今,企事业单位中的CIO、信息中心主任都纷纷提出“主动运维”的口号,其目的在于保护IT系统的正常、有效运行,在事故发生之前侦测出潜在危机,而类似“春节”这种长假前,正是主动运维管理发挥作用的最佳时机。在节前进行一次彻底、全面的检查工作必不可少,然而,面对大量的纸质表单和电子表格,很多IT运维管理人员很可能没有时间和耐心看完那些积攒成堆的报表。这就使得看似“主动运维”的大扫除工作,其实背后却没有落地工具和效果支撑。

    锐捷网络认为:节前的这种全面性的检查工作,应属于预防性检查(PM)的一部分。预防性维护可对网络和业务系统运行环境主动地找出可能会影响系统可用性和性能降低的原因,发现影响软硬件故障的潜在因素,以及业务系统性能的瓶颈。其实,IT部门完全可以利用支持自动化巡检的工具替代手工劳动,例如锐捷网络的RIILIT综合业务管理平台可以对以下内容进行自动检测,如:机房场地环境、硬件状态检查、系统日志、存储、系统备份及安全状态检测等等。接下来,IT部门就可以利用这些数据得到系统总体性能评估,在节前做好调整和优化工作。

    节中:预警管理与避免告警“洪灾”

    节日期间IT运维人员也许会轮班、值班,但如果没有一个监控能力支撑到位的运维平台,由于没有业务人员再打电话来报修,一旦网络环境出现异常,这个“值班”也就成为了“摆设”,很有可能在节后出现业务瘫痪故障的情况。因此,IT运维人员必须在第一时间就能知道业务系统异常的信息,以便值班人员通过智能化告警处理中心提示的内置故障根源分析做出处理,恢复业务系统正常运行。并且,根据警告的级别,RIIL系统还可以将值班人员不能处理的故障事件,自动派给相应的高级IT管理人员进行分析处理。

    针对告警管理,RIIL可帮助CIO快速探明IT基础架构的异常事件,采用6级分类区别事件不同的严重等级,精细化的规则定义实现了智能解析,确保事件、告警的准确性、及时性。同时,在第一时间便可通过邮件、短信等多种告警方式使相关技术人员及时获知,迅速做出响应,在对业务产生致命影响前采取措施、有效解决,从而保障业务的连续运行。并且,RIIL可以将事件与告警分离,针对节假日自定义告警的规则,过滤无用信息,避免告警“洪灾”在春节期间打乱IT部门的休假安排。

       节后:业务健康指数避免“节后综合症”

    春节过后,很多单位很快需要进入正常的工作状态,作为网络运维管理员,假期结束后上班的首要任务就是要马上检测网络运行是否正常,以免给企业员工的工作带来诸多不便。我们知道,现在员工工作的“节后综合症”十分常见:疯狂购物、外出旅游、纵情娱乐、亲友聚餐等过后,剩下的是身心疲劳,肠胃不适,不想上班。这种现象一般在节后一周左右才会慢慢恢复,但业务网络系统显然容不得这样“养病”的时间。

    为了避免节后无法及时了解每个运维对象和业务系统潜在故障情况的发生,RIIL平台中首创了“IT健康指数”。它是一条类似股票大盘指数的曲线,如果出现下行趋势,则说明IT系统在春节这段时间运行状况出现了异常,需要警惕。此时,运维人员就可以根据IT健康指数相关联的业务“雷达”,寻找当前健康指数下行是由于哪一个业务系统的健康发生变化造成的,同时可以追溯到故障源头,明确是在长假的哪个时间点发生了问题。

    伴随着IT技术的迅猛发展,以及企业核心业务的集成程度更加紧密,如何把这些IT系统在统一的平台上实现整合、监管和优化,发挥业务系统效能最大化,进而达到最优化管理,已成为了IT部门的首要任务。因此,不论是春节、国庆,或是教育行业中的寒暑假,RIIL都会是CIO最得力的“值班人员”,避免网络和员工一起“放假”,造成业务运营的潜在风险。


    评论 {{userinfo.comments}}

    {{money}}

    {{question.question}}

    A {{question.A}}
    B {{question.B}}
    C {{question.C}}
    D {{question.D}}
    提交

    驱动号 更多