请选择 进入手机版 | 继续访问电脑版
发帖
开启辅助访问
 找回密码
 立即注册
取消
搜索
热搜:
活动 交友 discuz
分享到

选择网管系统应该避开哪些方面?

#新人报道#时间:2019-06-10 阅读:58 回复:0

547

主题

547

帖子

3075

积分

管理员

Rank: 9Rank: 9Rank: 9

积分
3075
  目前市面上有层出不穷的网管产品,在选购之前,就应该考虑如何做到多维信息在一个逻辑维度上的有效展示,将最终用户群体最关心的信息,第一时间以最易接受的形式展现、告知出来。因此,购买网管系统应先综合设计,别让钱包里的银子白白浪费掉。
  网管系统的死穴
  网管软件的死穴就是: 错误在哪,软件知道,网管人员找不到。
  “你想要的管理数据信息我们网管系统里都有,你找不到不能怨我; 网管系统是一个专业化很强的系统,你不会用不能怨我; 网管系统的数据展现方式挺丰富的,你不会看不能怨我。” 这种三个“不能怨”的网管产品是不是真是用户需要的?技术工程师难免会面临不同层次上的短板,我们并不能强求人人具备万事通的能力,能否做到网管产品的直观、易用,用户需要的是应用系统人员也可借鉴来分析问题的一个有力工具。
  以业务驱动为主导
  目前网管的范畴逐步扩充,外延涉及面越来越广、越来越深。从当初着眼于网络链路、网络设备和附属相关设施,到如今面向业务系统的全业务监控管理体系; 从单纯的关心网络通断和业务数据的通达,到目前网络流量的精细化分析、故障定位的跟踪、BT等特定流量的控制。更进一步的,还有服务器性能、关键应用进程、数据库的监控、IT资产管理、业务流程的规范化梳理等,这些多维信息在各层次均不同程度地体现出了应有的价值,但正因为其多维性,使得实际网络管理变得就不那么简单了。
  “原来没有这样或那样的运维系统时,维护工作运转得也挺正常。现在给你们配套了那么多的管理平台和工具,再出那么多问题就说不过去了。”持这种观念的领导不在少数,从投资回报率上考虑确实也合情合理。然而,在这种多维信息的集中轰炸下,技术人员有一种被戴上紧箍咒的感觉,遇到突发事件时往往很难把各类信息源统筹考虑分析,事件风暴的形成使得众多的模块功能成了漂亮的摆设,即便各模块均能从不同角度呈报故障因素,但并不能像预期的那样快速定位问题根源,要将这些综合因素排查清楚势必需要一定的时间,从而延误问题的解决。
  有没有可能把这种多维度的信息通过一定的技术方法,依照业务自身运维特点展现在一个逻辑维度里呢?可以考虑以熟悉的业务逻辑展现用户关心的特定视图,把与业务密不可分的诸如网络、服务器性能、数据库等作为业务顺利运行的IT基础架构配套设施放到后台,使管理员把关注点集中到业务自身的特定领域; 而当发生故障时又能及时地通过告警判断出故障原因来自于业务自身还是IT基础设施的问题,从而让各个领域的专业人员能有所针对地快速解决问题。
  业务服务管理BSM(Business Service Management)所经常提及的业务服务视图BSV(Business Service Views)与这种需求在某种程度上不谋而合。它可以使我们把关注点放到长期监控业务服务的状况,保证对关键业务快速、安全地访问。将IT资源与关键的业务目标对应起来,以应用业务的观点来运营维护企业的IT系统,从而最大化发挥IT对企业业务的推动作用。
  不过,在选购并设计一套网管系统时,从传统的IT服务向以业务驱动为主导的多维信息集成迁移并非是一个一蹴而就的过程,这中间存在着许多技术和管理的改进细节,需要做大量诸如业务逻辑调研、流程建立与梳理、IT基础设施监管与调优等前期基础准备工作。在此基础上完善集成的业务处理、业务数据、服务通道三个方面应用, 使得业务逻辑、业务数据、业务表示方式三者既互不依赖、相互分离,又可灵活联系,成为一个和谐的有机整体。目前诸多知名厂商IBM、HP、BMC、MO(奥美)等均先后推出了相应的应对方案和产品,虽然实际应用效果未必尽如人意,但这种理念的推出和持续不断的调优改进也让我们看到了光明的前景,在我们实际的部署应用中也逐步实现着预期价值,验证了这种发展方向的可取之处。
  建立业务视图的四点要求
  实际上网管系统的真正受众是包括IT基础设施运维在内的各业务技术运维人员。它不是专家决策系统,也不可能通过几张定制化的视图就短时间内普及专业业务背景知识。所以在做多维信息的整合之前要搞清楚成果的最终受益者是谁,能使相关技术人员得到什么实质性的技术维护便利。在发现服务出现问题时,要同时具备业务维度的服务影响评估能力和技术维度的问题根源定位分析能力。只有这样,才能在发生问题时有效判断,采取相应的技术操作降低可能发生的业务损失。 缺失准确目标的管理活动,都是低效甚至无效的,所以在建立业务服务视图时,应特别注意以下几点。
  1. 不要眉毛胡子一把抓,凭主观感觉替实际业务技术人员做出判断,认为他们应该关心什么、不应该关心什么。从特定业务角度出发,他们的日常运维经验远胜于我们来自教科书或厂商的概念炒作。需要与业务技术人员充分交流,使最终的视图满足其日常最为迫切的运维需求。
  2. 与业务技术人员一同清晰地勾画其业务逻辑的工作流走向及相互影响关系,尽可能充分考虑到影响业务正常运转的各环节因素,并依此在关键业务点上加上不同的权重关系,使关键点能第一时间得到响应,在此不妨称之为业务逻辑中 “VIP”角色的定位。
  3. 在清晰化业务逻辑关系之后,依托先前部署的各网管功能模块,有所针对地采集关键性能数据,为最终权重关系分析奠定基础。BSM聪明就聪明在它是在别人的基础之上做综合性分析,是个“脑力劳动者”,各采集功能模块,虽然也有“思维能力”,并且功劳不小,但终因无法把结果很好地呈现出来,而沦为“体力劳动者”。例如,在双链路冗余的网络环境中,单链路的通断虽然重要但远不及链路延迟、丢包对视频会议的影响来得重要。所以,对于视频会议业务系统,双链路冗余情况下单链路的通断不是权重比最高的,只要不全断,链路质量又没问题,那么视频会议业务系统并不会受多大影响,所以这部分业务运维人员大可不必惊慌失措。与之相反,网络运维团队此时就成了热锅上的蚂蚁。因此,关注点不同导致的响应就会有天壤之别,所以业务视图的建立要考虑到业务自身的运维特点,不能人为创造出众多的惊弓之鸟。
  4. 业务逻辑的细化和业务视图的建立要尽可能考虑到与业务相关的细枝末节,再微小的隐患如果不根除,最终都势必会积累爆发出来。不能抱着侥幸心理: 你报你的警,反正我的业务能正常运转,孰不知软件程序其实就是个耿直的“傻子”,它报错固然有它的道理,无论是误报还是配置错误,终归要规避“狼来了”喊多了造成的麻痹大意。否则,“狼真来了”也就晚了,这点对于ERP、CRM等关键业务尤为重要。
  选择恰当的监控运维手段
  符合业务自身运维特点的各专业业务服务视图的定制是一个较为漫长的艰苦工作,需要反复推敲完善。即便这个视图做得相对比较完善了,多维信息有效地整合在一个直观的维度上了,我们还有一项重要的工作要做,那就是如何保证关键应用的7×24小时运维保障的有效实现。
  任何时间我们都无法保证能全天候死盯着屏幕,所以一方面需要制定相应的运维管理制度和轮班值守职责,另一方面则需要选择更加人性化的运维管理方式。我们在实际部署过程中发现,大家不但需要声、光、邮件的告警触发通知,也迫切需要在移动办公状态或休假状态第一时间得到预警,从而做出应有的反应,这样大家不约而同地想到了手机短信这一公认的快捷通信方式,无论在非工作时间还是休假期间,运维人员均会在故障发生的第一时间收到告警信息,从而通过现场或VPN手段及时响应处理故障。在为运维做需求分析的过程中也需要关注几点。
  1. 告警事件的有效归并和根源事件的有效判断、触发是最为关键的一点,如果这个工作做不到位,这种告警信息势必形成疯狂的轰炸效应,那么运维人员就被这种大量的事件风暴骚扰得要摔手机了。
  2. 运维手段的丰富替代不了人工的直接介入,虽然运维的自动化是较为理想的状态。但实际运维环境中这种自动化还没有人敢轻易尝试,所以针对关键应用,必要的轮班制度还是要建立并逐步完善。
  3. 对于关键应用必须制定紧急故障处理预案,在故障真的发生时,除了能第一时间告知相关运维团队技术人员到位以外,故障的处理步骤、各部门的协调联动都对及时恢复业务应用起着至关重要的作用。

  在建立多维信息整合的各业务服务视图过程时,不宜一开始就确立庞大的目标。因为这种整合实施不仅是选购一套网管软件就能完成的事,更是一种管理变革过程。要注意循序渐进,开始时可以粒度比较粗,后续逐步螺旋迭代完善,并随时根据企业业务的变化进行相应调整。前期各采集模块的有效部署、告警事件的有效归并、分析等都是不可或缺的一环。在一个周密计划的信息化建设大架构下,做到分期、分步骤、有阶段性明确目标的建设实施,则会使我们少走弯路,有效地保证投资的高回报率。

回复
使用道具 举报
快速回复
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

客服电话
173-6185-1240
发布 快速回复 返回顶部 返回列表