翻译自 Reducing the Cognitive Load Associated with Observability 。

有助于确保软件工程团队具备有效使用和理解可观测性信号的知识和技能的技巧。

你能想象在没有现代可观测性工具的情况下开发或运行分布式系统吗？我们知道，可观测性是一项关键的实践，它可以帮助我们提高系统的可靠性，减少服务停机时间，可视化使用模式，提供性能洞察，并促进问题解决。

过去十年中，随着微服务架构和全球化“左移”意图的广泛采用，从开发人员和运维人员到DevOps、站点可靠性工程和平台工程师等工程师的角色发生了巨大变化。许多人承担了更多的责任，工作量也增加了。

作为软件工程组织，我们的工作是构建满足特定业务需求的高质量系统。为实现这一目标，我们对我们的应用程序进行了检测，设置了分布式跟踪和集中日志收集，并持续监控延迟、错误率和吞吐量，并在此基础上发出警报。那现在呢？我们可以依靠我们组织中一位英勇的专家来处理警报、诊断系统故障并防止中断。或者我们可以将这些知识传播给所有工程师并分担工作量。

要求每个人精通现有的工具，并理解产生的大量数据，必然会导致焦虑、沮丧和疲劳。我们能否以某种方式减少与可观测性相关的认知负荷？

可观测性涉及到一些硬技能。工程师需要接受培训，以解密基本的数据类型。希望工具能帮助人类完成这项任务。难怪我们看到了众多供应商的工具不断涌现，旨在提供最佳的体验，以解释和可视化分布式跟踪、指标和日志。这是一项复杂的任务！分布式跟踪只是一大块链接的时间戳和元数据；指标可以是 gauges、 counters 或 histograms 。一条日志语句可以根据受众和使用者而结构化或非结构化。即使是最常见的日志语句，对于未经训练的人来说也可能会看起来陌生。只需问一下 Java 开发人员如何解读 Python 堆栈跟踪！

然后，我们面临“数据过多”的问题。我们依靠工具大海捞针并过滤噪音，并明确表示在任何时间点，收集到的信号，但未暴露在任何可视化中或未被任何警报使用的信号，都是要删除的候选信号。

数据点需要经过过滤和转换才能生成适当的信号。没有人希望 24/7 盯着仪表盘或跟踪日志，因此我们依靠报警系统。当警报触发时，它旨在进行人为干预，这意味着将原始信号转换为带有上下文数据的可操作事件：警报的严重程度、环境、描述、注释、链接等。它必须有足够的信息来指导注意问题，但不要淹没在噪音中。

最重要的是，页面警报应该需要人工响应。如果警报不可操作，还有什么理由打断工程师的流程？

当警报触发时，分析开始。虽然我们热切地期待异常检测和自动化分析（随着人工智能的出现）能够完全从这个方程式中消除人的因素，但我们可以使用一些技巧来帮助我们的大脑快速识别问题所在。

阈值是触发警报信号所必需的。在可视化方面，调查和检测异常的人也需要考虑这些阈值。这个数据的值是太低了还是意外地太高了？

在这个过于常见的图表中，图表标题、轴标签和描述被故意删除了。我们缺乏上下文，但我们的大脑可以立即发现异常。导致图表的警报应该始终包含一个可视化指标。它们对于突出趋势和异常模式至关重要，即使对于不熟练的人眼也是如此。

在你的团队中，谁是事情不顺利时事实上的第一响应者和可观察性专家？当事情不顺利时，他们会迎接挑战？也许是你。尽管恢复服务的正常运行时间并挽救局面的呼声越来越高，但还是请那个人退缩。问自己这些问题：

• 可能发生的最坏情况是什么？
• 还有其他人能应对这种情况吗？
• 这是团队中其他人的学习机会吗？
• 这是一个教学机会吗？在这种情况下，跟随一位经验丰富的团队成员进行学习是否可行？

让其他人变得熟练起来。放手并不容易，调整你的期望值，给自己和团队留出调查的空间，是减少情况的感知压力和紧迫性的关键。通过在受控、无压力的环境中使用真实数据响应真实生产系统中的真实事故进行积极学习，是最终的训练。虽然这可能看起来有些像“以火试金”，但这就是为什么我们有“游戏日”的原因。

游戏日类似火灾演习。我们需要接受故障和停机的发生。游戏日的目标是通过提前练习应对能力来减轻实际事件中的压力。我们希望在危机中能够快速自信地行动，同时建立一些直觉和反应，，这些直觉和反应能力将在凌晨 4 点派上用场。熟能生巧！

首先选择一个游戏主持人和必要的协助者。通常，这些人是某个领域或系统的专业人员。他们需要仔细选择在游戏日活动中要测试哪个系统和场景。以下场景非常常见：

• 重现之前的事件场景。这会测试应急响应流程是否得到改进，人员是否知道要注意哪些可观察信号以及如何相关联数据点。这也是测试经过事后总结学习和纠正措施后系统是否更具有弹性的好机会。
• 在生产环境中启动新的系统或服务之前，确保所有必要的监控、警报和指标都已经就位。这会测试你是否准备好操作该系统，以及人员是否知道如何发现可观测数据并知道如何响应警报。
• 在安全、优雅降级、高可用系统等方面，校准过度自信的偏见。这将测试你是否真正了解系统的故障模式，以及工程师是否有能力诊断未知问题。

然后请游戏主持人提出一组假设，并预测练习的预期收获。评估练习对业务的影响（影响范围），并确定如有必要采取的步骤来将其最小化（例如通过将练习限制在一个时间框内，如果发生意外情况，则中止它等等）。

让游戏开始吧！故意破坏事物并引入一些混乱。我们希望在处理事件时，人们依靠理性、专注和故意的认知功能。否则，压力和恐惧会影响认知功能和决策。

观察人际互动在这个问题解决的练习中如何发挥作用。这个练习是否培养了合作文化？团队成员是否相互支持？

培养协作文化对每个人的福祉都是必不可少的。分享数据、见解和问题将带来更多团队成员的参与、好奇心和信任。谁会对开发人员隐藏他们的可观测性仪表盘？信息应该被分享，避免保密。这些是简单的原则，然而很少有组织在从事事故学习时遵循这一标准。我们应该庆祝失败！我们需要在事故后分析中透明，以推动有意义的改变。指责和指责他人的文化只会加速焦虑和差错的恶性循环。

每个事故响应流程都应包括一份事后分析报告。在事后分析报告中，收集信息、想法、反馈和感知再次成为团队活动。有效地进行无过错事后分析将确保团队成员有余地提出对流程、工具或系统的更改。这种活动使人们通过纠正措施和提高生活质量来进行改变。事后分析报告还应受益于组织中其他成员，他们可能没有直接参与事故处理，因为书面记录应广泛分享，并作为学习资料。

工程师具备理解可观测性数据的能力。在游戏日中，所有团队成员积极学习如何应对事故时，将值班工作分配给整个工程团队而不是少数人非常重要。这也有助于减轻与即将到来的不幸的负担和压力。当值班时，不应让任何一个工程师独自承担。必须明确定义和理解职责和升级路径。从第一响应者（911 调度员）到事故指挥官（专家）和升级经理（通常是负责沟通的工程经理），不应让任何人承担英雄任务，而应让他们协调和组织最适合解决问题的团队。

在值班期间，清单（称之为“运行手册”或其他名称）也可以作为认知辅助工具，以在完成复杂的指导任务时卸载思考过程。 Game Days 是测试这些清单的完美场所。

由于我们已经通过消除信号噪声来确保减少虚报，而且每个人都了解他们在值班轮换中的角色，因此警报疲劳应该已成为过去。

通过实施这些策略，软件工程团队可以确保他们掌握了使用和有效理解可观测性信号的知识和技能。充分利用收集到的数据对于提高分布式系统的整体性能和可靠性至关重要。教授和学习将人的因素扩展到一个单独的个体之外。虽然我们仍然必须依靠人类大脑来诊断和解决问题，但让我们确保我们可以持续地做到这一点。