前段时间看一个小伙伴的系统设计。他从系统的设计目标开始讲：第一，完成核心业务功能；第二，有监控；第三，出现问题能追溯…… 刚讲到这里就被我叫停了：真正投入实用的任何一个软件系统，监控和可追溯都应该是基础要求，这是常识，怎么好意思和“完成核心业务功能”列在一起？但是转念一想，或许对很多人来说，这也算不上“常识”，它们固然很重要，但 学校里根本没教这些内容，怪不得大家。
况且，我自己也在监控上吃过很多的亏，深一脚浅一脚走过来，才会懂得这种“常识”。为了避免大家少走弯路，我来讲讲关于监控的几个基础问题吧。
监控是系统设计的必备要求
谈到监控，通常是广义的“监控”，它包含“监控”（monitor）和“报警”（Alert）。按照Effective Monitoring and Alerting这本书的解释，二者的定义如下：
监控：其作用是对既有系统维持认知，并衡量系统中的数据流转和状态改变。目的在于发现异常，在排障过程中提供帮助。
报警：报警系统应当具有这样的能力，能侦测到显著的状态变化对应的事件，并将事件告知操作和维护人员。
如果我们承认，软件工程不只是“开发软件的工程”，合格的软件开发人员必须关心软件运行情况，对软件的全生命周期负责，那么我们就应当承认，监控和报警是内嵌在软件开发中的，是系统设计的底限要求。运行再迅速、功能再强大的系统，没有监控和报警（以下简称监控），都是残缺的。
有很多开发人员也在一定程度上懂得监控的重要性，但他们并不重视，因为现成的监控系统很多，搭起来接入就好了。这样的态度是不对的，这样的设计是不合格的。按照上文的定义，合格的监控必须能持续提供对于既有系统运行状态的认知，而系统“运行状态”往往并不是现成监控系统、监控项所能覆盖的，因为“系统”并不能还原为一堆零件。比如说，如果你开发的是某种存储系统，单纯衡量CPU占用率、磁盘占用率、网络吞吐率，而忽略了每秒上传文件数、平均文件大小、平均存储事件、失败重试次数等等，那么你是无法建立对于存储“系统”的认知的。
所以，尽管有现成的监控系统可以帮一些忙，但更重要的是，在系统设计之初就问自己几个问题：如果要了解我的系统的运行状态，应当借助哪些指标？这些指标如何统计，以什么方式和频率统计？…… 如果开发人员不能很好地回答这些问题，最终开发出来的产品很可能会有问题，而且很可能是“莫名其妙”的问题，极难排查。
监控必须有足够存在感
我遇到过好几次这样的情况：系统上线了，监控也上线了，平时根本没有人看。甚至出现问题了，问对应人员平时运行情况是怎么样的，也拿不到满意答复，因为平时根本不关心。大家想的是：反正系统也上线了，也有监控了，就交给对应的人去关心就好了。结果监控系统成了僵尸，对真正应当关心监控信息的人来说，它没有什么存在感。
这样造成的直接后果是：排查问题的成本极高。因为设计数据统计和提供机制的与真正观察数据的是两拨人，而出现问题之后，又必须双方协同解决。毕竟，有产品意识的开发人员本来就少，有意愿又有能力把监控信息和监控系统设计到“傻瓜都能看懂”的开发人员就更稀少了。很多时候，监控系统里的数据不准还是其次，单纯一个不知所云的统计项就能让人完全抓瞎，根本谈不上有效监控、迅速定位。
之所以出现这种问题，通常都是因为监控系统缺乏存在感，平时没有人去关心。也就是说，光有监控系统是不够的，还应当让关心监控的人关心监控信息，给予足够的重视。
当然，如果应该关心的人有很好的职业素养，或者有上级明确的压力，这个问题不难解决，但很多时候这样的前提并不存在，应该怎么办？
其实已经有不少办法，最常见的就是变被动为主动，让监控主动来刷存在感。很多软件开发团队会专门安排几块屏幕放在大家都能看到的地方，上面实时显示系统的各种监控数据。这样的存在感会大大提升，总有人在路过或者放松的时候去留意它，有问题也会及时发现。即便“不是自己的问题”，也更愿意报告出来，提醒对应的人。比起那种“被动等待用户登录查看”的监控系统，这样的做法效果要好成千上万倍。
我有时还会推荐另一种“变被动为主动”的做法，就是让监控系统用邮件主动发监控的日报、周报。邮件这种形式有几个好处：第一，相比电话和短信，它对接收人的干扰比较小；第二，阅读时间比较自由，上线班路上花三五分钟看看邮件，就可以了解大致的情况；第三，既然是邮件，内容肯定会脱敏，避免在服务器端进行复杂的账号设置；第四，邮件天生是多副本的，查询历史数据的时候可以避免因为历史数据问题而扯皮。
当然，邮件通报监控信息也有天生的不足，因为邮件没法控制也没法追踪，很可能泄露秘密；同时，邮件里也无法进行复杂的查询。所以，邮件一般只用来做日常数据的报告。
监控系统缺乏存在感的另一个常见原因是，监控系统没有随被监控系统更新。被监控系统往往直接承担业务职能，所以总在不断变化的过程当中。如果监控系统不能随着被监控系统更新，要么成为无足轻重的路人甲，要么成为累赘最终被抛弃。总之，监控系统逐渐和被监控系统脱钩，失去存在感，被监控系统逐渐“解放”出来，回复到裸奔的状态。这种局面，相信任何人都不想看到。
监控必须系统化运作
“系统化运作”的第一重含义是，监控信息是分层次分渠道的。
我见到很多人拒斥监控系统的原因是：信息太多了，看不过来，重要信息反而被淹没。出现这种问题的原因通常就是监控信息没有分层，各种信息混杂在一起。结果要么是铺天盖地的信息让人一看就如坠五里雾中，要么是“狼来了”喊得太多导致真正出问题了反而没有人相信。
对正常的监控系统来说，信息一定是分层次分渠道。什么样级别的信息以什么方式传达给哪些人，这是在设计监控系统时应当仔细考虑的问题。具体的方案各种各样，总的宗旨是统一的：最有用的信息能以最短的路径、最简洁的方式提供给最需要的人，让他能迅速作出判断，识别问题。
“系统化运作”的第二重含义是，监控系统不容许开例外。
监控标准定出来之后，我见过各种解释：这里报错是误报，那里统计有问题…… 总的诉求都是希望在监控系统里开口子，让监控数据“看上去正常”，或者即便显示不正常，让大家知道“这是正常的”。
对正常的监控系统来说，这种诉求是很大的危害。既然有标准在，就不容许有那么多例外。否则，监控系统的复杂性和维护成本必然大大上升，因为新接触监控系统的人无法按公认普适的规则来理解各种数据。更重要的是，长此以往监控系统的可信度会受到严重影响，“既然你的数据不对有解释，那么我的数据不对也可以解释”，“既然你的出错可以说是误报，我的出错也不用那么准确”，这就是破窗理论的活生生的例子。
以上是关于监控系统的三个基础问题，最后我想说的是：监控系统与被监控系统是共生关系，应当同步演进和重构。理想情况下这是一个闭环，每出现一次事故，每发生一点故障，我们都需要反思整个发现、排障的流程，看看是否有漏掉了某些监控项，或者某些监控项还不够完善，以后持续验证这些改进是否有效…… 如果系统改进没有终点，监控系统的改进也没有终点。
推荐大家阅读O'Reilly的Effective Monitoring and Alerting（目前没有中文版）。我相信，即便你是“单纯的”开发人员，也会从中收到很多启示。
另：我之前写过《 名不副实的“软件工程”》，引起很多争议和讨论，没读过的朋友可以参考。
优秀人才不缺工作机会，只缺适合自己的好机会。但是他们往往没有精力从海量机会中找到最适合的那个。
100offer 会对平台上的人才和企业进行严格筛选，让「最好的人才」和「最好的公司」相遇。
扫描下方二维码，注册 100offer，谈谈你对下一份工作的期待。一周内，收到 5-10 个满足你要求的好机会！
