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