正文
评委C：
这个设计有问题么？
工程师小黄：
故障可能得不到及时解决
。由于报警发送通道只有邮件和短信，如果故障发生晚上凌晨，大家都在睡觉的时候，即便收到邮件和短信告警的，基本不可能叫起来去处理故障。所以出现的情况是第二天一早就收到了用户的投诉。一看手机发现收到了N条报警短信，故障时长已经非常久了，一份故障总结报告在向你招手！时间一长，故障报告写到了手软之后，每当到了上线日，晚上都会睡不踏实，一段时间就要看看手机没有短信告警，害怕出问题。每当半夜听到手机的震动或者叮的响声，心里就一紧，常常失眠。
评委C：
那这个问题你们是怎么解决的，为什么要这么这么做？
工程师小黄：
我们加入了电话报警机制，而且是追命连环call，务必要保证把负责人从梦里叫醒，去解决问题。
当然也不只是简单加上了电话报警这个通路。报警规则往往是分钟级别的，不能一直触发一直报警，所以也加入了电话应答后自动静默的特点，同时伴随着故障升级的特性，后续会再讲。
评委D：
除了电话报警的问题，你们还遇到了别的问题了么？
工程师小孙：
主要是职责不够明确
。虽然电话告警，能够让故障得到及时的解决。但是早期的告警指标大多数都是兜底监控，监控指标都是监控全量的报错情况，比如sentry(
https://sentry.io/
)报错全量监控，status状态非0全量监控。报警接收人基本为系统架构部人员和运维人员。导致系统架构部和运维同学频繁的接到电话告警，先判断问题，再找业务部门沟通，效率非常低成本又高，似乎又回到了类似之前值班运维人工值守的状况。
评委D：
那你们是怎么解决这个问题的？
工程师小孙：
我们抽象了用户、团队、应用、监控项等等基本概念，做到告警规则->团队->对应负责人的自由匹配。每当告警事件产生后，就可以直接找到对应的告警负责人，进行精准告警。
评委D：
这个问题给你们最大的感受是什么？
工程师小孙：
如果你是运维或者架构师，有没有晚上频繁接到电话告警，担心家人晚上睡不好，自己“主(bei)动(gan)”去另外一个卧室睡觉的！这个功能上线后，世界又回归清静了，当然更多的工程师同学要起来查问题了。。。系统感知能力越强（监控项加的越多），工程师提前消除潜在风险、bug的能力就越强，长期看其实是更有利于大家节假日休息的。
评委E：
那之前说的自动升级报警又是什么？
工程师小孙：
当故障产生的时候，系统的直接负责人开始排查解决故障，但有时候问题不是很好解决，相关负责人在聚精会神解决问题时，往往又忘了反馈问题，就会导致故障长时间得不到的解决，影响的用户越来越多，投诉也越来越多，直到某个大牛医生将问题私信给了老板，老板叫来技术领导，问咋回事，这个时候技术领导才开始加大资源投入去排查解决问题。针对这类问题，尽管定了相关流程，如10分钟如果没解决要上报，谁跟进，谁协调资源等等，但是一旦故障发生时，很容易忽略时间，最终导致各方都不满意，绩效当然不合格了。
评委E：
那你们是怎么解决的？
工程师小孙：
我们加入了告警自动升级机制。当故障产生后，系统直接负责人（必须有第一、第二负责人）首先会同时接收到告警信息，一段时间（如15分钟）后，如果问题还没有得到解决，团队技术负责人和系统架构师就会收到告警信息，可以进行协助或者干预了。又过去一段时间（如30分钟）后，问题还是没有得到解决，CTO将会收到报警信息，问题会自动升级上报。
升级的好处是技术负责人可以视报警严重程度，决定是否加大资源去排查问题，同时向老板汇报原因，即做到了及时感知问题，不掩盖问题，也不耽误事。
当然，这样的后果是系统负责人的压力直接就上去了，他们要花更多的时间去关注系统的稳定性、错误率和bug等，你也不好意思总让CTO接到你们团队的报警是吧？
评委E：
这个问题给你们的感受是什么？
工程师小曹：
流程还是靠系统保障更靠谱，技术要对业务负责，故障都不感知怎么能行？故障、bug出了不可怕，大家第一时间止损，然后总结就行了。不要怕，更不能掩盖问题。
评委F：
真是问题推着设计走啊，那整体来看，新监控系统大体是什么样的？
工程师小曹：
整体的架构如下图：
dolphin的主要的新特性如下：
