团队的积极参与是确保建立“刚刚好”监控的关键，能够在真实问题出现时提供主动警报，而不至于让人感到不堪重负。
译自 Improving the On-Call Experience with Alert Management，作者 Paige Cruz 是 Chronosphere 的高级开发者倡导者，她职业生涯的第一部分是在 New Relic 和 Lightstep 等公司担任软件工程师转型为站点可靠性工程师。
您的应用程序面临用户问题，时间紧迫。谁先知道 — 您还是您的客户？
答案取决于您的组织在监控和可观测性方面的投资有多少。在理想的情况下，您应该在整个堆栈上设置全面的监视器，覆盖用户体验的关键方面。它们还应在适当的紧急情况下，及时通知正确的工程师，以减轻任何问题对客户体验的影响。
如果您正在阅读此文，您知道我们并不生活在一个完美的世界中。远非如此。许多组织依赖于同事、客户或用户的报告，以了解是否存在应用程序问题。
谨防低估故障、中断和故障的影响。新的研究显示，客户可能会原谅偶尔的故障，但这可能会损害您的组织的信誉并失去一些客户。监控可以成为建立或破坏客户信任以及使工程师充实或筋疲力尽的区别。
虽然在找到正确平衡并配置“刚刚好”监视可能有些棘手，但了解要提出的问题和要查找的反模式可以帮助您为改善值班体验的投资提出论据。
我们为对我们重要的事物设置监视器，比如为了准时上班设置闹钟，或者报告家中的烟雾或一氧化碳。当涉及到技术时，我们使用监视器来了解系统是否按预期运行。与烟雾警报不同，针对技术堆栈的监视器没有标准的一刀切集合。你应该监视什么信号在公司、部门甚至团队之间可能有所不同。如果你意外收到两封相同的营销电子邮件并不会有害，但如果你因意外收取两次房租费用，那绝对是不可接受的。在这里，背景信息非常重要。
对于监控的期望是，当您被呼叫时，问题是紧急的、真实的，并且需要您直接的调查和干预。但期望与现实之间的差距比大峡谷还要大：调查显示，59%的云原生开发人员表示，他们收到的警报中只有一半是有用或可用的。
我怀疑监控存在问题的一部分原因在于其主动性质。要设置或评估监视器，您需要知道正在寻找的条件以及何种阈值表示存在问题。这需要关于正在监视的技术、监视库或技术、运维经验以及访问或权限的知识。没有人会刻意创建糟糕的值班轮换 — 只是很难搞定监控。
追求调整“刚刚好”的监控，让客户满意、工程师高效充实，这是一个永无止境的任务。随着您的公司经历不同阶段、采用新技术和架构，以及拥有主观看法的工程师的加入或离开，这是一个不断变化的目标。一个今天有效的、良好调校的监视器可能在八个月后不再适用，随着时间的推移，个别服务、监视器或团队轮换可能会偏向于两个极端之一：过度监控或不足监控。
不足监控是指没有足够的监视来观察重要的操作或工作流程。这使得发现和调查的负担，本应由自动监视器承担，落到了客户和工程师身上。残酷的事实是，当他们在应用程序或网站上遇到问题时，客户很快就会指责。超过一半的人将责任归咎于品牌，而不是诸如互联网服务提供商或硬件之类的因素。
虽然我不相信“无压力”的事故，但我的经验是，被主动警报的工程师（当来电是来自内部时）在调查问题时比那些被动地尝试修复已经影响客户的问题时更轻松。
不足监控的症状包括：
- 依赖用户或客户告诉您何时出现问题。
- 轮换的情况可疑地安静，队友们习惯在主要轮班期间不随身携带笔记本电脑。
- 使用“尖叫测试”（取消访问以查看是否有人投诉）来验证更改的有效性。
- 问题几乎总是在有人通知您时被动地解决。
过度监控是指有大量警报触发，警报重复或分组不当（“页面风暴”），或大量误报。最大的影响在于开发人员的值班体验。与因为没有监视而错过问题不同，他们可能会因为警报表明一切都坏了而错过问题。
过度监控的症状包括：
- 认为某些警报是正常的，可以安全忽略。
- 收到页面后，您的第一直觉是调查其是否有效。
- 很少调整或删除警报。
- 永久静音的警报被允许滞留而不是清理。
- 监视器是从互联网复制的，其默认阈值保持不变，而不是适应您的环境或系统，或者没有重命名以反映监控的内容。
如果您认识到存在过度监控或不足监控的迹象，并需要制定“刚刚好”监控的行动计划，这个指南适用于您。请注意，这并未解决更大的问题，比如您的团队拥有太多服务或可靠性受到架构和设计的影响。
如果您准备改善值班工作，我首先的建议是不要独自进行。有效的监控需要所有参与过程的人持续、有意识的努力。值班和警报管理是您的团队或轮换（如果涉及多个团队）的共同责任。在深入了解 PromQL 和呼叫器统计之前，考虑如何让您的团队或轮换参与进来，以及在引入他们时可能遇到的挑战。
抵制以查看您拥有的庞大查询集并开始随意修改的冲动。您是一个庞大拼图中的一部分。从您轮换的其他人、依赖团队的工程师和管理层引入不同的视角对于影响变革和解决实际问题至关重要。
为了全面了解您的警报环境 — 并改善整体的值班体验 — 向自己、您的团队和管理层提问是很重要的。这些问题的答案可以突显值班操作的影响，帮助您倡导更大的投资和变革。以下是一些问题可供参考。
是时候照照镜子，对自己诚实一点了。
- 在值班时，管理警报方面有什么让您感到痛苦的经历？这在个人和职业方面对您有何影响？
- 您具体想要改进什么？降低呼叫器风暴的频率？减少在工作时间之外频繁的页面？缺乏文档和运行手册？
- 在您下次担任主要值班工程师之前，您认为可以实现的目标是什么？在本季度内可以实现什么？
- 您所在的轮换或公司对变革的兴趣如何？
在同一轮换中，对于糟糕的值班经历，人们的容忍度存在很大差异。值班工作涉及从专业工作时间延伸到我们宝贵的个人时间。正因为存在这种宽泛而深刻的个人差异，因此重要的是要讨论您特定值班轮换的标准和期望。
我设计了一个非常简单的值班“感受”调查，可作为进一步讨论您的团队在值班轮换体验方面状况的起点：
请让每个人对以下陈述进行评分：
非常同意 || 同意 || 不确定 || 不同意 || 非常不同意
- 我能够在需要时获得覆盖和交换。
- 我可以在主要轮换期间拒绝项目冲刺工作和面试。
- 我有信心拿起呼叫器并值班。
- 我确信当我接到呼叫时，警报是可以采取行动的。
- 在我的主要轮换周结束时，我因值班工作的要求感到疲惫不堪。
- 我能够投入时间主动改进主要轮换期间的生产值班。
- 我觉得我的经理对我的值班职责有足够的了解。
- 本季度应重新审视的前三个流程是什么？例如，部署冻结，值班交接，调整警报，标准化运行手册，值班假期补偿，生产就绪检查表等。
如果您在一个具有许多容器化微服务的云原生环境中工作，您熟悉管理和了解依赖关系。您的服务与其他团队之间存在技术依赖关系，云基础设施与您的应用程序之间存在依赖关系，以及您的服务与第三方 API 之间存在依赖关系。您的轨道涉及依赖于您的团队和服务，以及您依赖的团队和服务 — 我称之为您的“服务领域”。
如果您是应用程序开发者，了解您与您正在为其管理基础架构的团队（例如，Kafka 团队，Kubernetes 团队）之间的责任范围至关重要。您应该收到哪些警报，他们应该收到哪些警报，以及什么情况下双方都应该收到页面呼叫？他们能否共享任何运行手册、有用的查询或书签的仪表板？他们是否会审查您的监视器集并提供反馈？
谁离组件或技术最近，最适合提供监控建议。
与管理层讨论对您和您的工作、客户体验以及执行组织业务目标的影响，将有助于您更有效地改善值班体验。这不是关于工程经理或产品或项目经理不够“技术化”或不能体会到值班职责的要求，而是要弥合您关心的事物与他们关心的事物之间的差距。
向管理层提问：
- 反应性的应急工作有多少次导致未能按时完成项目截止日期或交付物？
- 值班工作如何影响了您履行工作或工作与生活的平衡？
- 不解决值班和监控问题会带来哪些业务风险？
这次对话是双向的。请工程经理和产品经理帮忙回答一个问题：“在我们团队领域内，对用户体验或产品功能有多大影响足以叫醒某人？” 这有助于确定和优先处理您的工作。
有效的监视器可以决定是动员主动的事故响应还是杂乱无章的被动响应。顾客和具有机构知识的经验丰富的工程师并不是无穷无尽的可再生资源，公司有责任通过投资有效的监控来履行对他们的责任。在启动改进项目之前，从各种角度收集要求，为改善您的值班体验奠定基础。