资源描述
单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,#,#,单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,1,用户案例故事分析,1,目录,北京邮政灾备切换事故,需求迫切性、监控可靠性、马上监控起来,北京邮政,tuxedo,监控，自行脚本利用,安徽邮政,自行监控扩展、脚本利用、经验沉淀,北京报刊发行局,订阅量实时监控、报警、考核,业务监控,邮储银行,网点开通率考核,业务管理,邮储银行,制定应用监控开发标准,应用监控体系化建设,邮储银行,报警内容的个性化需求,北京邮政,机房资源管理,某省信息中心,公共信息发布平台，网站内容更新情况考核,应用监控,某高校,网站内容变更监控,2,目录北京邮政灾备切换事故需求迫切性、监控可靠性、马上监控,北京邮政灾备切换,北京邮政信息技术局，,2009,年，上一套灾备系统，上线时，不稳定，后来无意中发现日志中出现一行提示后，,20,分钟，就会切换到有问题的灾备系统上。规律找到一部分，但这行提示什么时候出现还是没有规律。,用户很着急，问能不能马上监控起来？,需求迫切性、突发性,正好当时我们有实施人员在现场，用了,20,分钟，就配好了。日志监控,告诉用户配好了，用户依然不放心。,监控是否有效，担心的心理，虽然监控了，但是不是管用？,当天晚上就报警了。用户很满意，感觉很实用，想监控什么就能做到。,总结：监控需求具有迫切性、突发性特点，监控需求能否马上实现,？监控,不可能面面俱到，但出了问题，能不能有效预警下次的出现是着重考虑的,3,北京邮政灾备切换北京邮政信息技术局，2009年，上一套灾备系,北京邮政,Tuxedo,监控,2010,年，邮政综合网监控，在北京邮政信息技术局上线。,Tuxedo,监控，原本我们的平台提供了一套监控方式（,ATMI,接口）。,北京局的人说了，我们原来都是用,Unix,命令行，监控系统信号灯的，很实用，我们也习惯了，能不能还用上？,一方面是用户的习惯，另一方面也反映了用户潜意识对新的东西不放心，怎么办？最好的办法是让他保留原来的习惯,实施人员和局方人员一起，了解他的命令行，解析命令行结果，配置的方式教给他们。两天左右，就把原来的全部脚本配到监控平台上了。,他们感觉很实用。一方面原来的监测命令都用上了，同时监控平台定期轮询，能解放他们原来手工执行脚本，提高生产率。,总结：沉淀用户的经验，能让用户更放心。也是监控系统扩展性的体现。同时，也是对用户原有经验的充分认同和尊重。,4,北京邮政Tuxedo监控2010年，邮政综合网监控，在北,安徽邮政,自行脚本利用,2010,年，邮政综合网在邮政集团公司全国信息中心、,33,个省中心上线。,年底，开了上现总结交流会，准备进一步培训。培训内容就是如何通过监控平台，进一步开展深入监控。如何通过配置方式进行。,会上，安徽邮政信息技术局的代表就说了，“我们已经把我们原来的对中心局、电子化支局监控的脚本，配到平台中了，已经用起来了”,领导很惊讶，“你们怎么会知道呢？”“公司的人在实施的时候教给我们了，我们就自己调整了，还不错，挺实用的”。领导很高兴,“综合网内设备非常多、监控需求复杂多变，未来我们还会有很多新的业务系统上线，因此，监控需求具有很多不确定性。因此，我们对监控平台的扩展性要求很高。,WisentSoft,监控平台通过配置方式实现监控扩展的特点非常突出。这个平台技术上不一定是最先进的，但对我们来说，确实是非常实用的”,邮政集团运维部,周主任,总结：用户存在原有经验沉淀的需求，应充分尊重并满足这种需求,5,安徽邮政自行脚本利用2010年，邮政综合网在邮政集团公司,报刊发行局,订阅量实时监控,北京报刊发行局，承担主流媒体的纸介质发行任务。每年任务,8,亿。任务很重。,每年年底都是报刊发行的营销旺季,。,现在的报刊订销系统里的数据虽然也能反映一些，但都不是直接的数据，每天还需要科里专门人员重新做报表统计，很麻烦。，非常需要实时掌握各部门的营销动态,。,这个系统大约,9,年前开发商去开发的。,也不可能要求开发商去修改报刊订销系统。,综合网,监控系统,上线后，通过配置，直接监控报刊系统里的几张数据表记录，,就可以直接掌握我们想要的数据。确实方便很多。,而且，在旺季，针对每个区局、网点班组，设置每天任务完成情况告警阀值，低于阀值时就报警。发行科的管理人员可以非常有针对性的督促、指导具体人员，非常实用。,总结：监控原本从技术监控延伸到业务管理，考量系统的扩展性。,6,报刊发行局订阅量实时监控北京报刊发行局，承担主流媒体的纸,邮储银行,网点开通考核,全国共有约,6,万多个网点。领导,很,关心：网点是否正常、准时营业？直接影响到业务开展。如何考核呢？,2011,年上线省前置服务器运行监控系统,。原本目的是为了对服务器、网点画面进程等进行监控。,后来发现，可以监控网点终端接入前置机的进程状态。可以知道何时接入？是否发生交易？何时退出等。,通过这些,监控，就知道什么时候网点开通？是否服务受理？何时下班等？,总结：监控原本用于技术监控，延伸到业务管理，而且很方便,7,邮储银行网点开通考核全国共有约6万多个网点。领导很关心：,邮储银行,制定应用开发标准,邮储银行先后上了：全国中心集中监控系统、省前置服务器集中监控系统。这,两,大监控系统基本上覆盖了从后台到前置的全部硬件、软件系统的监控，包括,20,多个核心应用系统的监控,原有建设模式：应用开发,+,应用监控,全部,委托给开发商。逐步认识到弊端：,开发商擅长的是应用开发，不是监控；应用上线后，还会有新的应用监控需求怎么办？时效性难以满足。,有多少,个应用系统，就有多少个应用监控子系统。来回切换，很麻烦的,。仅,2012-2013,年，就要上大大小小,63,个系统。如此下去，简直难以想象。,目前，正逐步改变原有开发模式，以我们的平台为,核心，正在制定应用开发标准,，在应用开发设计时，需满足应用监控需求的一系列设计规范：应用状态分类、输出内容、格式、编码规则等,总结：监控的个性化需求贯穿各个方面,8,邮储银行制定应用开发标准邮储银行先后上了：全国中心集中监,邮储银行,报警内容个性化,邮储银行先后上了：全国中心集中监控系统、省前置服务器集中监控系统。这,两,大监控系统基本上覆盖了从后台到前置的全部硬件、软件系统的监控，包括,20,多个核心应用系统的监控,曾经有一段时间，用户反映，在小额信贷系统里总出现误报。,后来实施,人员发现，不是误报，监测到的故障是对的，但报警内容有些含混。原因是，监控系统对故障报警内容，有一套默认的标准报出模板：设备,+,设备部位,+,指标,+,正常值,+,异常值。,这套,标准报出内容，在这个地方容易误解。后来，针对这个设备的这个部位，可单独修改其模板。问题解决了。,总结：监控个性化需求体现在每一细小地方，确实需要精细化处理,9,邮储银行报警内容个性化邮储银行先后上了：全国中心集中监控,北京邮政,机房资源管理,以前曾经出现过：房山的几个网点网络断了，知道肯定是网络故障，但哪台设备不知道，只好在信息局大楼内，沿着走线，一个个地方查。后来发现，,5,楼楼梯拐角处，网络交换机脏了,2010,年底，机房搬迁，网线、电力线全部重新走线。,需要：直观地知道网线是怎么走的、电线怎么走的、每个机柜里的服务器是干什么的、服务器出问题了，怎么能快速找到这台服务器，近距离维修。,我们的,IT,资源管理平台，提供了可视化方式管理机房、机柜的空间资源、布线资源管理，可以很好地、图形化操作方式满足需求。,服务器预上,架：可预先知道应该放到哪个机柜合适：机柜空间能较好地利用，供电是否三项均衡分配，也可根据这台服务器的重要性，进一步看看它的供电线路上，由于没有单点故障点，网络线路上有没有单点风险等,资源分配的冲突分析,总结：机房辅助资源的配置管理管理很重要,10,北京邮政机房资源管理以前曾经出现过：房山的几个网点网络断,某,省信息中心,应用监控需求,某省信息中心：有一套公共信息发布门户系统，对公众发布各委办局的公开信息。门户系统下面连接几十个局的系统。由各局将要发布的信息，主动放到门户系统中。,由于行政管理划分的原因，各委办局对公共信息发布不是很主动，信息中心也不好经常催。后来，信息中心搞了个考核办法，要求各局每月完成内容更新至少多少次，量化考核。,上有政策，下有对策。有的局，只是把同一条新闻改个字，改个时间等，就发布了。结果还是没有起到促进信息发布的作用。,用了我们的监控系统，网页内容监控：更新次数记录，更新内容比对，相似度超过多少就判为假更新。,总结：,技术,监控用于业务管理,11,某省信息中心应用监控需求某省信息中心：有一套公共信息发布,某高校,网站监控需求,某高校，校园网建设后，关心网站内容,12,某高校网站监控需求某高校，校园网建设后，关心网站内容12,
展开阅读全文