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

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

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

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

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

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

　　“出了任何故障，其他环节都是可能有问题，唯独监控是一定有问题!”

　　—— 乔治·背黑锅

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

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

　　梳理一下自己在建设织云监控告警产品线的一些经验和思考

　　对于刚入行对监控告警这个产品还不太熟悉的新业务运维同学。

　　想自己建设监控告警的运维同学或者运营建设同学。

　　正在建设监控告警平台的运维同学或者产品经理。

　　对监控告警产品天天使用的业务运维同学

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

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

　　后续三篇文章讲述的核心内容(这个系列会比较长，先暂定了后面三篇的内容)

　　关于监控告警一些需要提前交代的概念

　　立体化监控体系的阐述

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

　　预告后续系列头三篇文章核心内容

　　IAAS层监控(服务器性能、网络设备、网络流量分析)等如何设计与实现?

　　一个企业级监控告警产品需要设计怎样的cmdb?(在云化时代CMDB所扮演的角色越来越核心，我以前也设计过织云的CMDB)

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

　　万丈高楼平地起

　　监控的定义

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

　　监控的方式

　　主动：程序内部埋点，服务主动上报自身的运行情况，一般都是具化为业务的各个属性或者指标，这种方式准、快，灵活性好，指标丰富。但是在非标准框架下会有一定的代码改造成本。

　　被动：无需埋点，从外部探测或获取服务的运行情况，例如ping探测、日志采集分析等等。

　　旁路：与程序逻辑无关，对服务质量与口碑的监控，例如舆情分析。