报警
报警时我们保证稳定性的最后一道坎， 如果进入了报警的阶段，应用离Down掉就不远了。 报警也是我们保障稳定性的一个重要的环节。
对于报警的设置是比较考究的， 下面主要会分析一下报警的几个方面。
报警的及时性 ★★★★★
对于报警，笔者认为最应该优先保障的就是及时性， 试想一个应用已经被用户反馈挂了的情况下， 这个时候就算不用报警，开发者应该也已经知道了。 这个时候报警存在的意义就是0了。因此报警最重要的一个特性就是要能及时地反馈问题，让应用开发者能够在用户发现之前发现问题，处理问题和解决问题。
报警的准确性 ★★★★☆
很多人会碰到收到的报警太多的情况， 也有很多人会碰到收不到报警的情况。这两种情况基本上来讲都是不太正常的， 当然不排除后者是在应用非常良好的情况下，有一堆其他措施能够保证不需要走到报警这个环节。对于过多的报警，很多人往往容易麻木， 这样就容易造成人们心理的一种懈怠， 反正之前报警什么事情也不会发生， 现在报警应该也不会发生什么事情，一旦到了关键时候，警也报了，但没有相应的人员去处理，最终酿成应用挂掉影响用户的惨剧。 所以报警不光是要能及时， 也要能准确， 能够区分报警的优先级别，用不同的方式来警告开发者， 并正确反馈情况。
报警的渠道和高可用 ★★★★☆
说到报警的高可用， 除了报警服务本身的架构之外，本文更关注的是多渠道。
因为任何渠道都有阻塞或者down掉的可能性， 而且不同的渠道的触达及时性不同。
一般而言，电话报警的触达及时性是最高的，有电话大家往往能够及时看到。 其次，短信也是一个报警经常选择的手段， 因为短信也是会在比较短的时间内可以被开发者察觉到， 而且手机是随身携带的，不管在上班还是下班都能相对及时的收到。第三开发者往往会使用一些聊天软件如企业微信与钉钉， 这些软件在开发者使用电脑的时候可以比较及时的收到，因为性格不同， 一般开发者下班不太会关注这类软件的通知与消息，因此这类软件的有效性只能排到第三。最后一个也是一个很常见的手段：邮件。 邮件对于大家来说都不陌生， 但邮件的实时性一般会比较差一点， 但邮件有一个好处：可以沉淀比较多的内容，一起发送。
不同的渠道的作用与及时性也不一样，一般报警会选择多渠道结合， 科学合理的利用与选择这些渠道。
报警的科学性与智能性 ★★★☆☆
最后一点也是不太好做的一点， 但一旦做好就会让人感觉比较舒服。试想一下，利用机器学习的方式，回顾监控需要关注的各个指标，以及当时的处理情况，通过与往期数据的结合分析， 最终做出决定是否要报警。 这类服务一般的研发成本也比较高， 但它确实可以让人感觉比较有用，比较舒服。 如果做的好， 可以在各项指标都还正常的情况下，会更早的报警，更早的反馈问题， 可以留给开发者更多的时间处理问题，这在极大程度上能减少损失；另外这类报警一般也可以比较人性化一点： 比如可以根据报警的优先级以及时间段决定是否去烦扰正在熟睡中的开发者。
总之这个领域可以做的比较多，但做的好往往会要求比较高的投入与比较精致的设计。
