回复

  • status: draft 罗总: 你好.
    今日再观看视频,已没有初接手时雾里看花的感觉. 现在多次反复观看,每次都有新的想法和思路涌现出来,受益良多.

    我先逐一回答罗总关注的问题: 不知一凡对如何建立这个模型有没有什么想法? 建立这个模型并目前看来没有任何明显的障碍,并且应该尽快建立和铺开到多个流程中来.(后面我再详述) 浙江公司在监控中使用的手段我们是如何实现的? 浙江公司第一周期,第二周期分别采用agent和Tivoli. 这一块我们去年狠下决心,抛弃了套用僵硬死板监控产品的模式,改用自主研发的程序进行监控.最大的困难在于,公司投入的人力,精力,时间是使用现成产品的很多倍,不过好处也是显著的: 监控指标的灵活性,精细度,可扩展性都不会再受产品的束缚,现在部分监控能力已经超出了浙江视频中体现出来的能力.这为今后开发协查定位,智能诊断打下了良好基础. 稳定性和可靠性也得到了大幅提升,监控本身出现问题时能迅速的修正和彻底解决. 不再会发生依赖的产品出现莫名问题,且产品厂家也束手无策,最后不了了之,下次又继续出现的情况.

    第三个周期,第四个周期的监控手段,我们通过开发vc充值流程,计费复机流程,网厅webservice接口监控,都已经成功落实了其监控手段(除了抽样单拨测因VC不具备条件而未能完成)

    如何在IT网管上实现对第三、四周期的统一监控、统一告警和统一派单有什么想法? 这个问题我想扩展开来说,有走偏和不正确的地方,希望罗总及时指正. 视屏的演示场景是一个典型的自底向上告警的过程,是最常产生的故障类型,也是监控能发挥最大作用的场景,含有预警的概念.视屏抓住了监控的核心.从视频的14:00仔细分析, 第一,二,三,四周期实际上对应的是: 主机监控,产品监控,应用监控,业务数据流监控 (第一,二划分的有些模糊) 需要重点关注14:20的内容:在第一周期监控到归档日志文件系统被填满,第二监控周期监控到数据库连接异常,此时马上根据系统的传递规则,自动更新其它节点的状态.可以看到,根据传递规则,从底层数据库开始,到应用层,到数据流层,到最顶点都已经被标志了异常. 第三个监控周期只是从应用层再次验证,jdbc连接数据库也异常.第四周期从数据流监控的层面再再次验证了确实出现了堵单(其实此时可能为时已晚,已经收到业务部门投诉了). 先跳出来说一下近期真实发生的一次事故,与视频演示相似度非常高:由于数据库连接数满了导致的问题. 套用视屏的周期来描述: 第一周期我们监控到了数据库连接数超过阀值.第二周期监控到了数据库连接异常.因为没有传递规则,此时我们嘎然而止,监控系统能做的仅仅是发语音告警给数据库维护人员,而数据库维护人员此时正好在家调休.最终数据库问题影响到了整个计费,计费影响到了VC充值/复机.我们对VC和复机做了数据流监控,此时也准确的告出了数据流异常的告警,但是此时数据流监控起到的作用在哪里呢? 说了半天,我想表达的意思是:基础监控(第一,第二周期)+完善的传递规则=80%的流程监控 ,从接触项目的第一个会议,主要商讨和推动的就是数据流的监控.似乎确定:流程监控=数据流监控 ,现在我认为这是偏颇的.
    数据流监控偏偏就是整个流程监控推进过程中最大的阻力和瓶颈,谁来给你理顺每个流程点的统计规则?厂家又如何愿意开放其数据接口让你监控?被监控系统的现状能不能给出数据流? 即便选择了最明晰的VC充值和复机,请最有力的人来协调和推动.受限于被监控系统和厂家,现在的数据流监控,距离理想要求仍然有差距. 这是一块硬骨头,按照目前试点的进度,完全将数据流铺开,会是一场艰巨漫长的战斗,估计90%的精力和时间都会花在协调推动被监控系统上. 回到视屏的分析来看,浙江公司到底有没有真正将这块硬骨头啃下来其实还值得商榷,至少从展现出的界面来看,客账户新建流程视图和业务建模视图中数据流部分的监控和告警都很粗略,没有详细堵单数量.只有大环节的粗略超时告警.演示场景中,直至数据流已经告警,IT服务台的人员才开始排查和处理的,作秀的成分更多.真实的故障中,此时为时已晚,业务部门已经有感受了.告警成为了鸡肋,仅剩下了协查问题的作用. 14:55开始,视屏重点强调的是其充分利用了明晰的根原因规则, 综合分析所有层的告警,根据传递规则分析反映出各节点业务能力的变化.(自底向上). 根据事件关联规则(和传递规则其实是一致的),定位到根原因(自顶向下).数据流监控不过是其中最后一层确认验证手段. 因此我觉得推动重点应该放在传递规则的梳理确认.这块应该并不困难.现在已经有了相对完善的基础监控信息,只要通过准确的传递规则与业务衔接起来,那么就不再仅是基础告警,很自然的就能进化过渡为业务告警.按此方式的话,能较为迅速的铺开覆盖大量的流程.数据流监控即使暂时不做,也能实现视屏中的主要功能.

若按此计划,功能上我们应该重点实现: 根据传递规则,对具体业务构建直观的业务影响视图/根原因视图 根据传递规则,智能对多个告警事件进行根原因归并(目前我们系统已经有告警事件池的概念,只要有规则,做起来并不困难.ps: 再想一下:送itsm工单,按规则归并/关联后,可以解决之前会议讨论中说到的对同一事故的多条工单如何并案的难题)