新闻动态

您的当前位置:w6609.com利来国际 > 新闻动态 >

监控告警产品专题(1):企业级监控产品设计基

发布时间:2019-06-11 17:37
分享到:

  这是监控告警产品专题系列第一篇文章,涉及的主要内容为监控产品设计的一些相关基础知识,算是这个系列文章的一个索引。

  以前做QQ业务运维的时候,有一类平台是自己天天会用,那这类平台是什么呢?就是监控告警平台,每天在上面查大量的业务视图、查异常、确认告警、处理告警等等。对于运维同学来说,如果从使用频率这个维度看,监控告警类平台的使用频率要大于自动化类平台,毕竟自动化类平台多数都是由例行变更触发,而监控告警平台是我们7X24小时都要使用的。

  当时自己名下有较多的业务和几千台机器,那时有过一天收1000多条告警的记录,相当崩溃。其实告警如果一天超过几十条就基本是无效的,即关注不过来,也处理不过来。在业务运维这个角色中,我更多的是从使用者这个视角去看监控的。

  去年下半年我从业务运维转型为产品经理,现在负责腾讯织云(企业级运维管理平台)监控告警产品线的规划与落地,对于业务运维同学想转型成产品经理的可以参考下我的另外一篇文章(从业务运维转到产品经理,我摸爬滚打的产品之路)。在产品经理这个阶段我更多的是从建设者这个视角去看监控的。

  使用者和建设者这两个视角去看待同一个事物监控告警这个产品,最大的差异点是什么呢?

  使用者是点,建设者是面,使用者只关注能服务到自己的功能点,而建设者尽量要更全面的抽象多数使用者所具化的场景,在抽象的基础上在去构建功能,力争满足大部分的使用者场景,解决实际的问题。

  基于这两种不同的视角与在实际建设途中遇到的各种实际问题,我萌发了写一个监控专题系列的想法,哈哈 脸皮蛮厚的的。自己以前都是写单篇的文章,这次也算是一个挑战了。希望通过这个专题能与大家交流下关于一款企业级监控产品是怎么样规划、设计与落地的。

  可能是当产品经理习惯了用户场景与角色的分析,如果把这个主题的文章当做一个产品来看,那么其中的角色与场景是什么呢?

  这系列的文章我也会尝试用开放式(类众筹)的方式去写,欢迎朋友们将日常使用监控告警产品的痛点与具体的场景在评论区留言,后续会统一评估这些反馈的场景,如果是典型共性场景或者是很小众,但是这个很小众的场景却能代表一个特定类型的业务的话,将会采纳您提供的场景,在后续的文章中会标明这是由那位朋友提供的,并且附上我的建议场景解决方案,供大家交流与讨论。

  本篇作为该系列的第一篇文章,也是最基础的一篇,老鸟们可以直接散了,等着看后续的文章,该篇会主要涉及到以下主要内容:

  因为我现在是织云监控告警产品线的产品经理,而且这部分的产品也在分版本的持续建设中。所以后续主要的产品规划、设计、实现的讲述都是基于织云这个载体上实现。

  平台级的监控产品如何更好的支撑五花八门,而且业务形态差别很大的组件监控?

  通过技术手段发现服务异常,持续优化业务可用性与用户体验。这句话的关键词是发现  持续优化 可用性与体验。

  那么这三类有优劣之分吗?其实没有,这里的方式都是针对于不同场景的,例如对域名的监控,就可以通过该域名的外部拨测来达到监控的目标,域名的访问耗时也可以通过不同的拨测点来监控。在我们腾讯内部QQ和Qzone两个海量业务对这三类监控都应用到了。

  在DevOps中,运维、开发、测试这三个角色应该视角统一,这里为什么说要视角统一,就是大家在监控这个层面关注的点应该是一致的,而不是你关注你的点,我关注我的点。例如所有的业务监控都可以抽象出三个核心指标:请求量、成功率、耗时。这三个关键指标来判断我们服务的可靠性,通过可靠性可以推算出可用性,并且可以间接反映用户使用我们产品的的体验。例如如果服务的可靠性不好,那么用户的产品体验肯定不会好。

  通过对上文的一些概念介绍,其实我们已经可以推导出应用监控告警的目的,就是持续优化业务服务质量,并建设质量体系。同样织云监控也是为了打造质量体系的闭环路径。

  监控告警是一款数据类属性的产品,既然是数据类产品,那么在产品设计的时候一定要注意这样的路径闭环数据生产-数据增值数据消费,围绕着这样的路径我们就可以勾勒出很多的用户故事,用户故事就是针对具体的角色,会有什么具体的活动,这个活动所产生的价值。

  这里举个简单的例子,来说明数据生产与数据消费。随着后面详细的讲述产品建设过程中会更加详细的阐述这个闭环的路径。

  :例如一台服务器上报的各种基本的OS指标数据,例如CPU使用率,内存使用量等。这就产生了若干待消费的原始数据,那么我们能用这些数据干什么呢?

  :对这些上报的原始数据整理可以用作视图展示,例如图形化展示该服务在最近一个小时的cpu使用率。 又或者对这些原始数据设定阈值,当超过某个阈值的时候,就产生告警通知。这些都是最直接的消费的场景。

  我们在延伸一步对于这些消费场景产生的告警数据,是否可以在进一步消费呢?答案是可以的,例如对若干承载Cpu计算型业务的服务器所产生的cup使用率告警(生产)时间进行分析统计(消费),是不是可以基本推导出该业务的服务高峰期是大概在那个时间范围呢?

  这里想说明的是多数原子数据并无单一的消费或者生产的属性,而是要取决于在具体的场景与所处的数据链条中的角色。

  并且监控告警的数据加上特定的流程(ITSM)也可以驱动监控告警+自动化的大的业务逻辑交互闭环,这个场景容我先买个关子,随着后面的叙述会再次提及到这部分。

  体系,泛指一定范围内或同类的事物按照一定的秩序和内部联系组合而成的整体,是不同系统组成的系统。其实这个描述是有些抽象的,咱们用大白话套用监控体系来解读下。

  对于一个有一定体量的公司,需要一些不同的监控系统,通过系统与系统间的内部交互来组成一个大的整体,从而完成对不同场景下的监控需求即监控体系。用我们内部来举例说,我们内部在现网上跑的监控系统也有快10套了,同样在构建体系时关键的部分也是要用动态的视角去看待这些系统所产生的数据,而不是每个系统都是一个孤立的数据孤岛。下图是织云整体的监控体系。

  在织云监控告警产品建设过程种,我们融入和很多关于海量运维的监控思考与经验沉淀。

  

  这里的监控体系是和公司体量大小有直接关系的,但是一般来说在这个体系中,应该有三类监控系统是必备的。

  通过上文的简单介绍,相信大家对监控告警会有个初步的宏观认识,随着后续文章的铺开,大家会逐步了解到一个企业级的监控产品是怎样从0到1演化而来的。同时下篇文文章就会进入到实战阶段。 建设监控告警是一条持续且漫长的路也是蛮复杂的,坑也很多,但还是有一些基本的方法论和规律可以遵循的。

  人人都是产品经理(是以产品经理、运营为核心的学习、交流、分享平台,集媒体、培训、社群为一体,全方位服务产品人和运营人,成立8年举办在线+期,线+场,产品经理大会、运营大会20+场,覆盖北上广深杭成都等15个城市,在行业有较高的影响力和知名度。平台聚集了众多BAT美团京东滴滴360小米网易等知名互联网公司产品总监和运营总监,他们在这里与你一起成长。

联系我们

地址:广东省广州市天河区88号
电话:400-123-4567
传真:+86-123-4567
邮箱:admin@baidu.com