掌握这些监控报警优化技巧，百万年薪不在话下！

运维工程师面试者第一个问题是：须要值班吗？笔者本身也曾经历过月入十万的时期，在那个时候，数个系统同时发布下一代版本，而老系统还须要过渡很长时间，工做量直接翻倍。

图片来自 Pexels

你们只能勉强应付一线运维工做，团队成员开始陆续离职，而新人又没法在短期内上手，总体状况不断恶化，持续半年左右才缓过劲来。

下面两张截图是我挑选的两个团队一周报警数的对比图，前者的单日报警量最高是 55348 条，后者单日的报警量最高为 34 条，二者相差 1600 倍，而前者才是国内不少互联网运维团队的真实写照。

在管理大规模集群的状况下，究竟有多少报警量才是合理的呢？

Google SRE 每周十条故障报警

Google SRE 每周只有十条报警，若是超过十条，说明没有把无效报警过滤掉（Google SRE 仅负责 SLA 要求为 99.99% 的服务）。

笔者所在的团队要求则是，每周至多两晚有报警，单日报警量不能超过 50 条（比 Google SRE 放水好多啊）。

经过控制单日报警数量，严格约束夜间报警天数，确保最少不低于四人参与值班。

笔者所在的团队，近几年来，不只少有由于值班压力而离职的同窗，并且咱们每一年都能持续招聘到 985 前 20 名学校的多个研究生。

那么，怎么作到呢，如下是笔者的一些经验分享。

运维工程角度看报警优化

①报警值班和报警升级

基于值班表，天天安排两人进行值班处理报警，将值班压力从全团队压缩在两人范围内，从而让团队可以有足够的时间和人力进行优化工做。

同时，为了不两个值班人员都没有响应报警，可使用报警升级功能，若是一个报警在 5min 内值班人员均未响应，或者 15min 内未处理完毕，或者有严重故障发生，均可以将报警进行升级，通告团队其余成员协助处理。

若是公司的监控系统暂不支持值班表功能，则经过人工按期修改报警接收人的方式进行。

而对于监控系统不支持报警升级的问题，经过自行开发脚本的方式，也能在必定程度上获得解决。

也能够将报警短信发送至商业平台来实现。总之一句话，办法总比问题多。

对于报警值班人员，须要随时携带笔记本以方便处理服务故障，这个要求，和报警数量多少以及报警的自动化处理程度并没有关系，仅和服务重要性有关。

对于节假日依然须要值班的同窗，公司或者部门也应该尽可能以各类方式进行补偿。

②基于重要性不一样，分级应对

一个问题请你们思考一下，若是线上的服务器所有掉电后以短信方式通知值班人员，那么线上一台机器的根分区打满，也经过短信来通知是否有必要。

上述的问题在平常工做也屡屡发生，对于问题、异常和故障，咱们采起了一样的处理方式，所以产生了如此多的无效报警。

Google SRE 的实践则是将监控系统的输出分为三类，报警、工单和记录。

SRE 的要求是全部的故障级别的报警，都必须是接到报警，有明确的非机械重复的事情要作，且必须立刻就得作，才能叫作故障级别的报警。其余要么是工单，要么是记录。

在波音公司装配多个发动机的飞机上，一个发动机熄火的状况只会产生一个”提醒“级别的警示（最高级别是警报，接下来依次是警告、提醒、建议），对于各类警示，会有个检查清单自动弹出在中央屏幕上，以引导飞行员找到解决方案。

若是是最高级别的警报，则会以红色信息，语音警报，以及飞机操纵杆的剧烈震动来提示。若是这时你什么都不作，飞机将会坠毁。

③故障自愈

重启做为单机预案，在不少业务线，能够解决至少 50% 的报警。没有响应，重启试试，请求异常，重启试试，资源占用异常，重启试试，各类问题，重启都屡试不爽。

换言之，针对简单场景具备明确处置方案的报警，自动化是一个比较好的解决方案，可以将人力从大量重复的工做中解放出来。

自动化处理报警的过程当中，须要注意如下问题：

• 自动化处理比例不能超过服务的冗余度（默认串行处理最为稳妥）。

• 不能对同一个问题在短期内重复屡次地自动化处理（不断重启某个机器上的特定进程）。

• 在特定状况下能够在全局范围内快速终止自动化处理机制。

• 尽可能避免高危操做（如删除操做、重启服务器等操做）。

• 每次执行操做都须要确保上一个操做的结果和效果收集分析完毕（若是一个服务重启须要 10min）。

④报警仪表盘，持续优化 TOP-3 的报警

以下图示，整年 TOP-3 的报警量占比达到 30%，经过对 TOP-3 的报警安排专人进行跟进优化，能够在短期大幅下降报警量。

TOP-3 只是报警仪表盘数据分析的典型场景之一，在 TOP-3 以后，还能够对报警特征进行分析。

如哪些模块的报警最多，哪些机器的报警最多，哪一个时间段的报警最多，哪一种类型的报警最多，进而进行细粒度的优化。
同时，报警仪表盘还须要提供报警视图的功能，可以基于各类维度展现当前有哪些报警正在发生，从而便于当短期内收到大量报警，或者是报警处理中的状态总览，以及报警恢复后的确认等。

⑤基于时间段分而治之

下图是国内很是典型的一类流量图，流量峰值在天天晚上，流量低谷在天天凌晨。

从冗余度角度来分析，若是在流量峰值有 20% 的冗余度，那么在流量低谷，冗余度至少为 50%。
基于冗余度的变换，相应的监控策略的阈值，随机也应该发生一系列的变化。
举例来讲，在高峰期，可能一个服务故障 20% 的实例，就必须介入处理的话，那么在低谷期，可能故障 50% 的实例，也不须要当即处理，依赖于报警自动化处理功能，逐步修复便可。
在具体的实践中，一种比较简单的方式就是，在流量低谷期，仅接收故障级别的报警，其他报警转为静默方式或者是自动化处理方式，在流量高峰期来临前几个小时，从新恢复，这样即便流量低谷期出现一些严重隐患，依然有数小时进行修复。
这种方式之因此大量流行，是由于该策略可以大幅减小凌晨的报警数量，让值班人员可以正常休息。

⑥报警周期优化，避免瞬报
在监控趋势图中，会看到偶发的一些毛刺或者抖动，这些毛刺和抖动，就是形成瞬报的主要缘由。
这些毛刺和抖动，至多定义为异常，而非服务故障，所以应该以非紧急的通知方式进行。
以 CPU 瞬报为例，若是设置采集周期为 10s，监控条件为 CPU 使用率大于 90% 报警，若是设置每次知足条件就报警，那么就会产生大量的报警。
若是设置为连续 5 次知足条件报警，或者连续的 10 次中有 5 次知足条件就报警，则会大幅减小无效报警。

对于重要服务，通常建议为在 3min 内，至少出现 5 次以上异常，再发送报警较为合理。

⑦提早预警，防患于未然
对于不少有趋势规律的场景，能够经过提早预警的方式，下降问题的紧迫程度和严重性。
下图是两台机器一周内的磁盘使用率监控图，能够预见，按照目前的增加趋势，必然会在某一个时间点触发磁盘剩余空间 5% 的报警。

能够在剩余空间小于 10% 的时候，经过工单或者其余非紧急方式提醒，在工做时间段内，相对从容的处理完毕便可，毕竟 10% 到 5% 仍是须要一个时间过程的。

⑧平常巡检
提早预警面向的是有规律的场景，而平常巡检，还能够发现那些没有规律的隐患。
以 CPU 使用率为例进行说明，近期的一个业务上线后，CPU 使用率出现偶发突增的状况，可是没法触发报警条件（例如 3 分钟内有 5 次使用率超过 70% 报警），所以没法经过报警感知。
听任无论的话，只能是问题足够严重了，才能经过报警发现。
这个时候，若是天天有例行的巡检工做，那么这类问题就可以提早发现，尽快解决，从而避免更加严重的问题发生。

⑨比例为主，绝对值为辅
线上机器的规格不一样，若是从绝对值角度进行监控，则没法适配全部的机器规格，势必会产生大量无心义的报警。

以磁盘剩余空间监控为例，线上规格从 80GB 到 10TB 存在多种规格，从下图表格看，比例比绝对值模式能更好的适配各类规格的场景（EXT4 文件系统的默认预留空间为 5%，也是基于比例设置的并可经过 tune2fs 进行调整）。

对于一些特殊场景，一样以磁盘剩余空间为例进行说明，例如计算任务要求磁盘至少有 100GB 以上空间，以供存放临时文件。

那这个时候，监控策略就能够调整为：磁盘剩余空间小于 5% 报警且磁盘剩余空间绝对值小于 100GB 报警。
⑩Code Review
前人埋坑，后人挖坑。在解决存量问题的状况下，不对增量问题进行控制，那报警优化，势必会进入螺旋式缓慢上升的过程，这对于报警优化这类项目来讲，无疑是致命的。
经过对新增监控的 Code Review，可让团队成员快速达成一致认知，从而避免监控配置出现千人千面的状况出现。
⑪ 沉淀标准和优秀实践
仅仅作 Code Review 还远远不够，一堆人开会，面对一行监控配置，大眼瞪小眼，对不对，为何不对，怎么作更好？你们没有一个标准，进而会浪费不少时间来进行不断的讨论。
这时候，若是有一个标准，告诉你们什么是好，那么有了评价标准，不少事情就比较容易作了。
标准自己也是须要迭代和进步的，所以你们并不须要担忧说个人标准不够完美。
基于标准，再给出一些最佳的监控时间，那执行起来，就更加容易了。 以机器监控为例进行说明，机器监控必须覆盖以下的监控指标，且阈值设定也给出了优秀实践。

具体以下：

• CPU_IDLE < 10

• MEM_USED_PERCENT > 90

• NET_MAX_NIC_INOUT_PERCENT > 80 （网卡入口/出口流量最大使用率）

• CPU_SERVER_LOADAVG_5 > 15 

• DISK_MAX_PARTITION_USED_PERCENT > 95 （磁盘各个分区最大使用率）

• DISK_TOTAL_WRITE_KB（可选项）

• DISK_TOTAL_READ_KB（可选项）

• CPU_WAIT_IO（可选项）

• DISK_TOTAL_IO_UTIL（可选项）

• NET_TCP_CURR_ESTAB（可选项）

• NET_TCP_RETRANS（可选项）

⑫完全解决问题不等于自动处理问题

举两个例子，你们来分析一下这个问题是否获得完全解决：
若是一个模块常常崩掉，那么咱们能够经过添加一个定时拉起脚原本解决该问题。
那这个模块崩掉的问题解决了吗？其实并无，你增长一个拉起脚本，只是说本身不用上机器去处理了而已，可是模块为何常常崩掉这个问题，却并无人去关注，更别提完全解决了。
若是一个机器常常出现 CPU_IDLE 报警，那么咱们能够将如今的监控策略进行调整。
好比说，之前 5min 内出现 5 次就报警，如今能够调整为 10min 内出现 20 次再报警，或者直接删除这个报警策略，或者将报警短信调整为报警邮件，或者各类相似的手段。
但这个机器为何出现 CPU_IDLE 报警，却并无人去关注，更别提解决了。
经过上面两个例子，你们就理解，自动化处理问题不等于解决问题，掩耳盗铃也不等于解决问题，什么叫作解决问题，只有是找到问题的根本缘由，并消灭之，才能确保完全解决问题，轻易不会再次发生。
仍是上面自动拉起的例子，若是仔细分析后，发现是内存泄露致使的进程频繁崩掉，或者是程序 Bug 致使的 Coredump，那么解决掉这些问题，就可以完全避免了。

如何解决团队内部的值班排斥情绪

每一个运维团队迟早都会面对团队高工对值班工做的排斥，这也是人之常情。
辛辛苦苦干了几年了，还须要值班，老婆孩子各类抱怨，有时候身体情况也不容许了，都不容易。
不一样的团队，解决方式不一样，但有些解决方案，会让人以为，你本身都不想值班，还每天给咱们打鸡血说值班重要。
更严重一些的，会让团队成员感觉到不公平，凭什么他能够不值班，下次是否是咱们你们也能够找一样的理由呢。
笔者的团队是这样明确说明的： 保证值班人员数量不低于四人，若是短期内低于四人，那么就须要将二线工程师短暂加入一线值班工做中，为期不超过三个月。

对于但愿退出值班列表的中级工程师，给三个月不值班时间，若是能将目前的报警短信数量优化 20%-50%，则能够退出值班序列，但若是状况反弹，则须要重回值班工做。
团队达到必定级别的工程师，就能够转二线，不参与平常值班工做，仅接收核心报警，且对核心报警的有效性负责，若服务故障核心报警未发出，则每次罚款两百。

团队负责人不参与值班工做，但须要对单日报警数量负责，若是当周的日报警数量大于要求值，则每次罚款两百元。若是团队成员数量低于四人时，则须要加入值班列表。

写在最后

在团队的报警量有了明显减小后，就须要对报警的准确性和召回率进行要求了，从而才能持续的进行报警优化工做。
所谓的准确性，也就是有报警必有损，而召回率呢，则是有损必有报警。
最后，祝愿你们都不在由于值班工做而苦恼！