这是关于系统管理员基础知识系列文章的第一篇。如今，DevOps 的兴起甚至使“系统管理员”这个职位名称都显得有些过时，就像它所取代的“系统分析师”头衔一样。这些 DevOps 职位与过去典型的系统管理员工作截然不同，因为它们更加强调远远超出基本 shell 脚本的软件开发。因此，这些职位通常由具有软件开发背景但没有太多先前系统管理员经验的人员担任。过去，系统管理员会在初级职位入职，并由团队中的高级系统管理员指导，但在许多情况下，目前公司在首次招聘 DevOps 工程师之前，会进行相当长一段时间的云外包。因此，DevOps 工程师可能会在没有导师的情况下，以初级职位匆忙上岗，只能依靠搜索引擎和 Stack Overflow 帖子。在本系列文章中，我将阐述多年来我学到的一些经验教训，这些经验教训对于资深系统管理员来说可能是显而易见的，但对于刚入职此职位的人来说可能是新鲜事。

在第一篇文章中，我将介绍随叫随到的警报。与任何职位名称一样，赋予系统管理员、DevOps 和站点可靠性工程师的职责可能有所不同，在某些情况下，如果您幸运的话，可能不涉及任何类型的 24x7 随叫随到职责。但是，对于其他人来说，组织随叫随到警报的方式有很多种，而自找麻烦的方式也有很多种。

随叫随到警报的主要敌人是误报，主要风险是团队成员忽视警报或倦怠。本文讨论了一些您可以应用于警报策略的最佳实践，这些实践有望减少倦怠并确保警报不会被忽视。

警报阈值

系统管理员在设置监控系统时遇到的常见陷阱是对太多事物发出警报。如今，监控服务器运行状况的几乎任何方面都很简单，因此很容易用各种系统检查来过度加载您的监控系统。任何监控系统的主要持续维护任务之一是设置适当的警报阈值以减少误报。这意味着您设置的检查越多，维护负担就越高。因此，在确定通知阈值时，我对监控检查应用了一些不同的规则。

严重警报必须是我希望在凌晨 3 点被吵醒的事情。

系统管理员倦怠的常见原因是因不重要的系统警报而被吵醒。如果您没有 24x7 全天候国际开发团队，您可能不在乎构建服务器在凌晨 3 点出现问题，或者即使您在乎，您也可能会等到早上再修复它。通过将严重警报限制为仅限于必须 24x7 全天候在线的系统，您可以帮助减少误报并确保快速解决实际问题。

严重警报必须是可操作的。

有些组织会在系统上发生几乎任何事情时发送警报。如果我在凌晨 3 点被吵醒，我希望有一个与该警报相关的特定行动计划，以便我可以修复它。同样，过多的误报会使随叫随到的系统管理员感到倦怠，没有什么比被无法解决的警报吵醒更令人沮丧的了。每个严重警报都应该有一个明显的行动计划，供系统管理员遵循以修复它。

警告警报告诉我如果不修复它们将会变得严重的问题。

系统上有很多问题我可能想知道并且可能想调查，但它们不值得在凌晨 3 点起床。警告警报不会触发寻呼机，但它们仍然会向我发送更安静的通知。例如，如果负载、已用磁盘空间或 RAM 增长到某个点，系统仍然健康，但如果不加以检查可能会不健康，我会收到警告警报，以便我可以在有机会时进行调查。另一方面，如果我只收到警告警报，但系统不再响应，则表明我可能需要更改我的警报阈值。

定期重复警告警报。

我将警告警报视为在工作日唠叨您查看并修复它的东西。如果您发送警告警报过于频繁，它们只会向您的收件箱发送垃圾邮件并被忽略，因此我发现将它们间隔开来每小时左右发出警报就足以提醒我问题，但又不会太频繁以至于我完全忽略它。

其他一切都被监控，但不发送警报。

我的监控系统中有许多东西可以帮助在调查问题时提供整体上下文，但就其本身而言，它们是不可操作的，也不是我想要收到警报的任何东西。在其他情况下，我想从我的系统中收集指标，以便稍后构建趋势图。我完全禁用了这些类型检查的警报。它们仍然显示在我的监控系统中，并在我调查问题时提供良好的审计跟踪，但它们不会用无用的通知来打扰我。

Kyle 的规则。

关于警报阈值的最后一点说明：在我作为系统管理员的多年工作中，我养成了一种做法，我发现这种做法非常重要，可以减少倦怠，因此我将其带到我所在的每个团队。我的规则是这样的

如果系统管理员因为误报而在夜间被吵醒，他们可以清除第二天的项目，并花时间调整警报阈值，以便这种情况不再发生。

没有什么比因为误报警报而被吵醒一整夜，并且知道第二天晚上会重复发生，而您却无能为力更糟糕的了。如果这种情况继续下去，它将不可避免地导致倦怠或系统管理员关闭寻呼机。留出时间让系统管理员修复误报会有所帮助，因为他们有机会改善下一晚的睡眠。作为团队负责人或经理，有时这意味着我会在白天承担系统管理员的任务，以便他们可以修复警报。

寻呼

发送警报通常被称为寻呼或被寻呼，因为过去，系统管理员像医生一样，随身携带寻呼机。他们的监控系统设置为在出现问题时向寻呼机发送基本的数字警报，以便即使系统管理员不在电脑旁或在睡觉时也能收到警报。尽管我们仍然将其称为寻呼，并且一些老派团队仍然传递实际的寻呼机，但如今，通知更常通过移动电话警报处理。

您在设置警报时需要回答的第一个问题是您将使用什么方法进行通知。当您决定如何设置寻呼机通知时，请寻找一些特定的品质。

无论您身在何处都会提醒您的东西。

网络上存在许多很酷的办公室项目，其中一个损坏的软件构建会触发办公室中一个大的红色闪烁灯。这种通知对于非关键系统的办公时间警报来说很好，但即使在白天，它也不适合作为寻呼机通知，因为在会议室或午餐的系统管理员不会收到通知。如今，这通常意味着需要将某种通知发送到您的手机。

警报应该从其他通知中脱颖而出。

误报可能是寻呼系统的一个大问题，因为系统管理员自然会开始忽略警报。同样，如果您将警报的铃声与您用于任何其他电子邮件的铃声相同，您的大脑将开始忽略警报。如果您使用电子邮件进行警报，请使用过滤规则，以便随叫随到警报生成与常规电子邮件完全不同且更响亮的铃声，并使手机振动，以便即使您将手机静音或身处嘈杂的房间也能收到通知。过去，当黑莓手机流行时，您可以设置规则，使某些电子邮件生成与常规电子邮件通知不同的“一级”警报。

黑莓时代已经过去，目前，许多组织（尤其是初创公司）使用 Google Apps 作为其公司电子邮件。Gmail Android 应用程序允许您设置每个文件夹（称为标签）的通知规则，因此您可以创建一个过滤器，将所有随叫随到警报移动到特定文件夹，然后将该文件夹设置为生成唯一的警报、振动，并为发送到该文件夹的每封新电子邮件执行此操作。如果您没有该选项，大多数支持多个帐户的电子邮件软件都允许您为每个帐户设置不同的通知，因此您可能需要求助于仅用于警报的单独电子邮件帐户。

可以整夜叫醒您的东西。

有些系统管理员是深度睡眠者，无论您选择什么通知系统，都需要能够让他们在半夜醒来。毕竟，服务器似乎总是在凌晨 3 点左右表现异常。选择一个响亮的铃声，必要时可以是很刺耳的，并确保启用手机振动。还应配置您的警报系统，以便在警报在几分钟内未被确认时重新发送通知。有时，第一个警报不足以完全唤醒人们，但它可能会将他们从深度睡眠转移到浅睡眠，以便后续警报能够唤醒他们。

虽然 ChatOps（使用聊天作为获取通知和执行管理任务的方法）可能适用于一般的非关键白天通知，但它们不适合寻呼机警报。即使您的手机上安装了应用程序，设置为在聊天中有未读消息时通知您，但许多聊天应用程序默认在半夜处于“安静时间”。如果您禁用该功能，您可能会冒着在半夜被寻呼的风险，仅仅是因为有人给您发送了消息。此外，许多第三方 ChatOps 系统的任务关键可靠性不一定为人所知，并且曾发生过持续数小时的中断。您不希望您的关键警报依赖于不可靠的系统。

快速且可靠的东西。

您的通知系统需要可靠且能够随时快速提醒您。对我而言，这意味着警报是在内部完成的，但许多组织选择第三方来接收和升级其通知。您可以添加到警报中的每个额外层都是另一个延迟层，也是可能丢弃通知的另一个位置。只需确保您选择的任何方法都是可靠的，并且您有某种方法可以发现您的监控系统本身何时脱机。

在下一节中，我将介绍如何设置升级——这意味着，如果随叫随到的人员没有响应，您如何提醒团队的其他成员。设置升级的部分内容是选择辅助的、备份的通知方法，该方法依赖于与您的主要方法不同的基础设施。因此，如果您使用您的公司 Exchange 服务器作为主要通知，您可能会选择个人 Gmail 帐户作为辅助帐户。如果您有 Google Apps 帐户作为您的主要通知，您可以选择 SMS 作为您的辅助警报。

电子邮件服务器像其他任何东西一样会发生中断，这里的目标是确保即使您的主要通知方法发生中断，您也有一些替代方法可以了解它。我曾多次遇到我的 SMS 辅助警报在我的主要警报之前到达的情况，这仅仅是由于电子邮件同步到我的手机的延迟。

创建某种方式来提醒整个团队。

除了拥有会寻呼随叫随到人员的个人警报规则外，在发生“全体人员出动”危机时，拥有某种方式来寻呼整个团队也很有用。这可能是特定的电子邮件别名或电子邮件主题中的特定关键字。无论您如何设置它，重要的是每个人都知道这是一个“火警时拉动”通知，不应将其滥用于非关键消息。

警报升级

设置警报后，下一步是配置警报升级。即使是设计最完善的通知系统提醒最善意的系统管理员，也偶尔会失败，这可能是因为系统管理员的手机崩溃、没有手机信号，或者由于任何原因，系统管理员没有注意到警报。当这种情况发生时，您需要确保团队中的其他人（以及随叫随到人员的第二个通知）收到警报，以便有人可以处理警报。

警报升级是某些监控系统比其他系统做得更好的领域之一。尽管与其他系统相比，配置可能具有挑战性，但我发现 Nagios 提供了丰富的升级计划集。其他组织可能会选择使用第三方通知系统，特别是因为他们选择的监控解决方案不具备定义强大升级路径的能力。一个简单的升级系统可能如下所示

• 初始警报发送给随叫随到的系统管理员，并每五分钟重复一次。

• 如果随叫随到的系统管理员在 15 分钟内未确认或修复警报，则警报将升级到辅助警报，并升级到团队的其他成员。

• 这些警报每五分钟重复一次，直到它们被确认或修复。

这里的想法是给随叫随到的系统管理员时间来处理警报，这样您就不会在凌晨 3 点吵醒所有人，同时还为团队的其他成员提供了一种在第一个系统管理员无法及时修复或无法使用时了解警报的方式。根据您的特定 SLA，您可能希望缩短或延长这些升级之间的时间段，或者通过添加在整个团队之前收到警报的随叫随到备份来使它们更加复杂。总的来说，组织您的升级，使其在给随叫随到的人员在寻呼整个团队之前有时间做出响应之间取得适当的平衡，但不要让太多时间过去，以防万一随叫随到的人员无法响应。

如果您是大型国际团队的一员，您甚至可以设置遵循太阳的升级。在这种情况下，您将为每个地理区域选择随叫随到的管理员，并设置警报，以便他们了解这些区域的不同时段和一天中的时间，然后首先提醒相应的随叫随到系统管理员。然后，您可以进行升级，在警报未解决的情况下，寻呼团队的其余成员，无论地理位置如何。

随叫随到轮换

在第一次世界大战期间，在前线战壕中的恐怖经历导致了一系列新的心理问题（被标记为炮弹休克），随着时间的推移，这些问题甚至影响了最坚强的士兵。持续不断的爆炸、枪声、睡眠剥夺和恐惧日复一日地夺走了他们的生命，最终战争双方都意识到将部队轮换出前线进行休养的重要性。

将随叫随到与战争的恐怖经历相提并论是不公平的，但即便如此，它也会带来一种心理上的损失，如果不加以控制，它会使您的团队精疲力竭。即使在特定时期内没有收到警报，随叫随到的责任也是一种负担。这通常意味着您必须始终随身携带笔记本电脑，并且在某些组织中，它可能会影响您是否可以去看电影或度假。在一些管理不善的组织中，随叫随到意味着一场警报噩梦，您每次都可能期望有一个被救火毁掉的周末。由于随叫随到可能会带来压力，尤其是当您收到大量夜间警报时，因此轮换出随叫随到的系统管理员以便他们休息一下非常重要。

随叫随到的时间长度将因您的团队规模以及随叫随到的负担程度而异。一般来说，一到四周的轮换很常见，两周轮换通常会达到最佳点。对于足够大的团队来说，两周轮换足够短，任何单个团队成员都不会承担过多的负担。但是，即使您只有一个三人团队，这也意味着系统管理员可以整整一个月不用担心随叫随到。

节假日随叫随到。

节假日对您的随叫随到轮换提出了特殊的挑战，因为最终对于轮到哪个系统管理员来说都是不公平的。特别是，在 12 月下旬随叫随到可能会扰乱各种家庭时光。如果您有一个专业、值得信赖且团队合作良好的团队，我发现效果很好的是在特定的已知节假日（例如感恩节、圣诞节前夜、圣诞节和新年前夜）在整个团队中分担随叫随到负担。在这种模式下，警报会发送给团队的每个成员，每个人都会根据自己的空闲时间响应警报并相互响应。毕竟，并非每个人都在同一时间吃感恩节晚餐，因此如果一个人正坐下来吃饭，但另一个人还有两个小时才吃晚餐，当警报发出时，第一个人可以回复“在吃饭”，但下一个人可以回复“我来处理”，这样就可以分担负担。

如果您是随叫随到警报的新手，我希望您发现这份实践列表很有用。您会在许多拥有经验丰富的系统管理员的大型组织中发现许多这些实践，因为随着时间的推移，每个人都会遇到相同类型的监控和警报问题。无论您是在大型组织还是小型组织中，大多数这些策略都应该适用，即使您是唯一的 DevOps 工程师，也仅仅意味着您在创建警报策略方面具有优势，该策略可以避免一些常见的陷阱和整体倦怠。