GoogleSRE每周十次故障告警运维工程师面试官第一个问题是：需要值班吗？笔者自己也经历过月入十万的时期，几个系统同时发布了次世代版本，老系统还需要很长时间的过渡，工作量直接成倍增加。每个人都勉强应付一线的运维工作。团队成员开始陆续离开，新人短时间内无法上手。整体情况继续恶化，大约用了半年时间才恢复过来。下面两张截图是我选择的两支队伍在一周内的报警次数对比。前者单日最高报警次数为55348次，后者单日最高报警次数为34次。两者相差1600倍，而前者只是国内众多互联网运维团队的真实写照。在管理大规模集群的情况下，多少告警是合理的？GoogleSRE每周只有十个警报。如果超过十个告警，说明没有过滤掉无效的告警（GoogleSRE只负责99.99%Serve的SLA要求）。作者团队的要求是每周最多有两个晚上有告警，单日告警次数不能超过50次（比GoogleSRErelease多很多）。通过控制单日报警次数，严格限制夜间报警天数，保证至少4人值班，笔者所在的团队近年来不仅很少因值班压力而离开学生，而且每年还持续招收985所前20名学校的多名研究生。那么，如何去做呢，下面是笔者的一些经验分享。从运维工程角度优化告警1)告警值班和告警升级基于值班表。每天安排两个人值班处理告警，值班压力从整个团队压缩到两个人的范围内，让团队有足够的时间和人力做优化工作。同时，为了防止两个值班人员响应报警，可以使用报警升级功能。如果告警5分钟内值班人员未响应，或15分钟内未处理完毕，或出现严重故障，则可升级告警，通知团队其他成员协助处理。如果公司的监控系统不支持值班表功能，则需要定期手动修改报警接收器来完成。至于监控系统不支持告警升级的问题，也可以通过自己开发脚本来一定程度上解决。也可以通过向商业平台发送告警信息来实现。一句话，解决办法永远比问题多。对于值班报警，需要随时随身携带笔记本，方便处理业务故障。这个要求与告警的数量和告警的自动处理程度无关，只与业务的重要性有关。对于节假日仍需值班的学生，公司或部门也应设法通过多种方式给予补偿。2）请根据不同的重要性，思考如何在不同的层次上处理一个问题。如果所有在线服务器都断电，并通过短信通知值班人员，那么一台在线机器的根分区已满，是否需要也会通过短信通知。上述问题在日常工作中也经常出现。对于问题、异常、故障，我们都采取了同样的处理方式，所以才会有这么多无效告警。GoogleSRE的做法是将监控系统的输出分为三类，告警、工单、记录。SRE的要求是，所有故障级别的告警，如果已经收到告警，有明确的非机械重复的事情要做，并且必须立即完成，就必须称为故障级别告警。其他的要么是门票，要么是唱片。在波音的多发飞机上，发动机熄火只会产生“提醒”级别的警报（最高级别为警报，依次为警告、提醒、建议）。对于各种警报，中心屏幕上会自动弹出一份清单，以指导飞行员找到解决方案。如果是最高级警戒，则会有红色信息提示，语音报警，飞行器摇杆剧烈震动。如果此时你什么都不做，飞机就会坠毁。3）故障自愈重启作为单机方案，可以解决不少业务线至少50%的告警。无反应，尝试重启，请求异常，尝试重启，资源占用异常，尝试重启，各种问题，重启已多次尝试。换句话说，自动化是更好的报警解决方案，对于简单的场景有明确的解决方案，可以将人力从大量重复性的工作中解放出来。在告警自动处理过程中，需要注意以下问题：自动处理比例不能超过服务的冗余度（默认串行处理最安全）；机器上的特定进程）；在某些情况下，可以快速全局终止自动处理机制；尽量避免高危操作（如删除操作、重启服务器等）；每进行一次操作，都需要确保上一次操作的结果和效果的收集分析完成（如果某个服务重启，需要10分钟）。4）告警仪表盘，持续优化TOP-3告警如下图，每年TOP-3告警占比30%，通过跟进优化TOP-3告警，可以大大提高短时间降低报警音量。TOP-3只是告警仪表盘数据分析的典型场景之一。TOP-3之后还可以分析告警特征，比如哪些模块告警最多，哪些机器告警最多，哪个时间段告警最多，哪些告警类型最多，然后再细-进行了粒度优化。同时，告警仪表盘还需要提供告警查看功能，可以根据各个维度展示当前有哪些告警，方便短时间内接到大量告警，或者警报处理期间和警报恢复后的状态概览。确认等5)基于时间段的分治法下图是中国非常典型的一种流量图。每天晚上是交通高峰，每天早上是交通低谷。从冗余的角度来看，如果在流量高峰有20%的冗余，那么在流量低谷，至少有50%的冗余。基于冗余的变换，相应的监控策略的阈值也应该发生一系列的随机变化。比如在高峰期，如果有20%的实例出现服务故障，可能需要干预，那么在低谷期，可能有50%的实例出现故障，不需要立即处理，依靠自动告警处理函数逐渐修复就是这样。在实践中，一种比较简单的方法是在低流量时段只接收故障级别告警，其余告警转为静默模式或自动处理模式，在流量高峰期前几个小时恢复，这样即使在低流量时期出现了一些严重的隐患，也还有几个小时的时间去修复。这种方式之所以大受欢迎，是因为这种策略可以显着减少清晨报警的次数，让值班人员可以正常休息。6)优化报警周期，避免即时报告在监控趋势图中，您会偶尔看到一些毛刺或抖动。这些故障和抖动是即时报告的主要原因。这些故障和抖动充其量被定义为异常，而不是服务故障，因此应作为非紧急通知处理。以CPU即时上报为例，如果设置采集周期为10s，监控条件为CPU使用率大于90%并设置告警，如果每次满足条件都设置告警，会产生大量告警。如果设置报警连续5次满足条件，或者连续10次中有5次满足条件，则报警会大大减少。对于重要业务，一般建议3分钟内至少出现5次异常才发出告警。7）预警，防患于未然对于很多有规律趋势的场景，可以通过预警来降低问题的紧迫性和严重性。下图是一周内两台机器的磁盘使用监控图。可以预见，按照目前的增长趋势，在某个时间点会触发剩余磁盘空间5%的告警。当剩余空间小于10%时，通过工单或其他非紧急方式的提醒，可以在工作时间段内相对从容地处理。毕竟10%到5%还是需要一个时间过程的。8）日常巡检的预警针对的是常规场景，日常巡检也可以发现不规律的隐患。以CPU使用率为例。最近有一个业务上线后，CPU使用率偶尔会升高，但是无法触发告警条件（比如3分钟内使用率超过70%时有5次告警），所以无法通过告警。洞察力。放任不管，问题严重到只能报警才能发现。这时候，如果每天都有例行检查工作，那么就可以提前发现此类问题，尽快解决，避免出现更严重的问题。9）比例为主，绝对值与辅线上机器规格不同。如果从绝对值的角度进行监控，将无法适应所有的机器规格，必然会产生大量无意义的告警。以监控剩余磁盘空间为例，网上规格从80GB到10TB不等。从下表可以看出，比例模式比绝对值模式更能适应各种规格（默认为EXT4文件系统预留空间5%，也基于比例设置，可以通过tune2fs进行调整）。对于某些特殊场景，也以磁盘剩余空间为例。例如，计算任务要求磁盘至少有100GB的空间用于存放临时文件。这时可以调整监控策略为：磁盘剩余空间小于5%告警，如果磁盘剩余空间绝对值小于100GB则告警。10）CodeReview前人埋的坑，后人挖的坑。在解决库存问题的情况下，如果不控制增量问题，那么告警优化必然会进入螺旋式缓慢上升的过程，这对于告警优化等项目来说无疑是致命的。通过新监控的CodeReview，团队成员可以快速达成共识，避免出现千人千面的监控配置情况。11）沉淀标准和最佳实践仅仅进行代码审查是不够的。一堆人开会，面对一行监控配置，面面相觑，对不对，为什么不对，如何做比较好？没有一个人人适用的标准，这样又在不断的讨论中浪费了很多时间。这时候如果有一个标准告诉大家什么是好，那么就会有一个评价标准，很多事情就会好办了。标准本身也需要迭代完善，所以大家不用担心说我的标准不完善。在标准的基础上，给出一些最佳的监控时间，实施起来会比较容易。以机器监控为例，机器监控必须涵盖以下监控指标，阈值设置也给出最佳实践，如下：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_IORCUPNET_UTILP(可选);optional).12)彻底解决问题不等于自动处理问题举两个例子，我们来分析一下这个问题是否已经彻底解决：如果一个模块经常崩溃，那么我们可以通过添加一个定时拉起脚本来解决问题.模块崩溃的问题解决了吗？事实上，它没有。你加个上拉脚本，就说不用去机器上处理。但是，为什么模块经常崩溃是一个没有人关注的问题。更别提彻底解决了。如果一台机器经常出现CPU_IDLE告警，那么我们可以调整当前的监控策略。比如以前5分钟内触发5次报警，现在可以调整为报警前10分钟内触发20次，或者直接删除这个报警策略，或者将报警短信调整为报警邮件，或者各种类似的手段。但是为什么这台机器出现了CPU_IDLE告警，却没有人关注，更不用说解决了。通过以上两个例子，大家可以明白，自动解决问题不等于解决问题，欺骗不等于解决问题。什么是解决问题？只有找到问题的根源并加以排除，才能保证问题的彻底解决。会再次发生。还是上面自动拉起的例子，如果仔细分析，发现是内存泄露导致的进程频繁crash，或者是程序bug导致的coredumps，那么解决这些问题就完全可以避免了。如何解决团队内部拒绝值班每一个运维团队迟早都会面临团队高层对值班工作的拒绝，这也是人之常情。辛辛苦苦工作了几年，还是要值班的。老婆孩子各种抱怨，有时候我的身体条件不允许。这不简单。不同的团队有不同的解决方案，但有些方案会让人觉得你不想值班，你天天打我们说值班很重要。更严重的是，会让团队成员感到不公平。为什么他不能值班？下次我们都能找到同样的理由吗？笔者所在团队明确表示，值班人员不得少于四人。短时间内不足四人的，需临时补充二线工程师到一线值班，时间不超过三个月。对拟退出值班名单的中级工程师，给予三个月的停职时间。如果他们能将当前的报警短信数量优化20%-50%，他们就可以退出值班序列，但如果情况反弹，就需要返回值班工作。如果团队工程师达到一定级别，可以调到二线，不参与日常值班工作，只接收核心告警，对核心告警的有效性负责。服务故障不发出核心报警，每次罚款两百元。组长不参与值班工作，但对单日报警次数负责。一周内报警次数超过规定值的，每次罚款200元。如果团队成员人数少于四人，则需要加入值班名单。写在最后，在团队告警数量明显减少后，需要对告警的准确率和召回率提出要求，才能持续进行告警优化。所谓准确率就是有报警就会有损坏，召回率就是有损坏就一定要报警。最后祝大家不再为上班值班而烦恼！
