点击查看目录
本文译自：Reducing the Cognitive Load Associated with Observability - The New Stack
译者注：本文讨论了降低可观测性对认知负荷的影响。在处理大量数据时，我们需要过滤和转换数据点以生成适当的信号，并依赖警报系统来进行人类干预。游戏日是测试响应能力的好机会。在团队中培养协作文化对每个人的福祉至关重要。通过实施这些策略，软件工程团队可以确保他们具备使用和有效理解可观测性信号所需的知识和技能。
你能想象在没有现代可观测工具的情况下开发或操作分布式系统吗？我们知道可观测性是一项关键的实践，可以让我们提高系统的可靠性，减少服务停机时间，可视化使用模式，提供性能见解并促进问题解决。
随着过去十年微服务架构和全球“shift left”的意图的广泛采用，工程师的角色——从开发人员和运维人员到 DevOps、站点可靠性工程和平台工程——发生了巨大变化。许多人被赋予更多的责任，并增加了工作量。
什么是 Shift left？
“Shift left” 是一种软件开发术语，它指的是在开发生命周期的早期阶段引入测试和安全性措施，以便更早地发现和修复潜在问题，从而减少开发成本和增强产品质量。
传统的软件开发过程中，测试和安全性通常是在开发周期的后期才被考虑，这意味着潜在的问题可能已经存在于系统中并且需要更多时间和成本来修复。而“Shift left”意味着在开发过程的早期引入这些步骤，以便更快地发现并解决潜在的问题。
作为软件工程组织，我们的工作是构建满足特定业务需求的高质量系统。为了实现这一目标，我们已经对我们的应用程序进行了仪器化，设置了分布式跟踪以及集中式日志收集，并不断监视延迟、错误率和吞吐量，并在此之上设置了警报。现在呢？我们可以依赖我们组织中的一个英雄专家来处理警报，诊断系统故障并防止停机。或者我们可以将这种知识传播给所有工程师并分享工作负载。
要求每个人都能熟练掌握现有的工具和理解生成的大量数据不可避免地会导致焦虑、沮丧和疲劳。我们能否以某种方式降低与可观测性相关的认知负荷？
理解可观测性数据
可观测性有一些硬技能。工程师需要接受训练以解密基本数据类型。希望工具能在这项任务中协助人类。难怪我们看到了大量的供应商工具涌现，旨在提供最佳的解释和可视化分布式跟踪、指标和日志体验。这是一项复杂的任务！分布式跟踪只是一大块链接时间戳和元数据；指标可以是测量仪、计数器或直方图；日志语句可以根据受众和使用者而是结构化或非结构化的。即使是最常见的日志语句在没有受过培训的人的眼中也可能看起来很陌生。只要问问 Java 开发人员如何解开 Python 堆栈跟踪！
然后我们面临“太多数据”的问题。我们依赖工具来在大海捞针并过滤噪声，并使其清晰明了，即在任何时候，收集但未在任何可视化中公开或由任何警报使用的信号都是删除的候选信号。
信号：在大海中找到触发事件的针头
需要过滤和转换数据点才能生成适当的信号。没有人想每天 24x7 小时盯着仪表板或日志，因此我们依赖警报系统。当警报触发时，它旨在进行人类干预，这意味着将原始信号转换为带有上下文数据的可操作事件：警报的重要性、环境、描述、注释、链接等。必须提供足够的信息来引起对问题的关注，但不要提供太多的信息以避免被淹没在噪音中。
页面警报需要人工响应。否则，工程师如何证明他们已经中断了他们的流程？
当警报触发时，分析开始了。虽然我们热切地希望通过人工智能的出现实现异常检测和自动化分析，从而完全消除人为因素，但我们可以使用一些技巧来帮助我们的大脑快速识别问题所在。
可视化：不要低估平台 - 人类交互的价值
需要警报信号触发的阈值。在可视化方面，调查和检测异常的人员也需要考虑这些阈值。这个数据值是否过低或者出乎意料地高呢？
在这个非常普遍的图表中，图表标题、轴标签和描述被故意删除了。我们缺乏上下文，但我们的大脑可以立即发现异常。导致图表的警报应该始终包含一个视觉指示器。它们对于突出趋势和异常模式是至关重要的，即使对于未受过训练的人。
积极学习：避免英雄文化；训练你的团队
在出问题时，你的团队中的谁是事实上的第一响应者和可观测性专家，当事情变得不好时会挺身而出呢？也许是你。要求他退缩，尽管越来越渴望恢复服务的正常运行时间并挽救局面。问问自己这些问题：
- 最坏的情况是什么？
- 是否会有其他人挺身而出？
- 这对团队中其他人来说是个学习机会吗？
- 这是一个教学机会吗？在这种情况下，跟随经验丰富的团队成员的阴影工作是否可行？
让其他人变得擅长工作。调整期望并给自己和团队调查的空间是减轻压力和应对紧急情况的关键。在控制的无压力环境中实时响应真实事件和生产系统中的数据是最终的训练。这就是为什么我们有 Game Days。
Game Days
游戏日是消防演习。我们需要接受故障和故障将发生的事实。游戏日的目标是通过提前练习我们的响应能力来减少实际事件的压力。我们希望在危机时能够快速自信地行动，并建立一些直觉和反应能力，这些能力在凌晨 4 点非常有用。练习使人完美！
首先选择一个游戏大师和必要的同谋。通常，这些是域或系统的主题专家。他们需要仔细选择在游戏日活动期间将接受测试的系统和场景。以下情况非常普遍：
- 重播以前的事件场景。这会测试事件响应过程是否得到改进，人们是否知道要关注哪些可观测性信号并了解如何相关数据点。这也是测试后期学习和纠正行动后系统更具弹性的好机会。
- 确保一个新的系统或服务在进入生产之前具有正确的监控、警报和度量衡。这会测试您是否准备好操作系统，以及人们是否知道如何发现可观测性数据并知道如何响应警报。
- 校准安全、优雅降级、高可用系统等方面的过度自信偏见。这会测试您是否实际了解系统的故障模式，以及工程师是否有能力诊断未知问题。
然后要求游戏大师提出一组假设并预测演习的预期收益。评估演习对业务的影响（爆炸半径），并确定如果/需要采取的步骤以将其最小化（例如，通过将演习限制在时间框中，如果发生意外情况则中止它等）。
然后开始游戏！故意破坏并引入一些混乱。我们希望人们在处理事件时依靠理性、专注和深思熟虑的认知功能。压力和恐惧会影响认知功能和决策能力。
观察人类互动在这个解决问题的练习中如何发挥作用。这个练习是否促进了协作文化？团队成员是否互相支持？
协作文化：不再保留数据
在团队中培养协作文化对每个人的福祉至关重要。分享数据、见解和问题将从团队成员中获得更多的参与、好奇心和信任。信息应该被共享，应避免保密。这些是简单的原则，但很少有组织符合这个标准，当从事事故学习时。透明的后期检查可以推动有意义的变革，我们应该庆祝失败！指责和指责的文化只会加速焦虑和意外的恶性循环。
每个事件响应过程都应包括事后检查。有效的无指责事后检查将确保团队成员有权提出对过程、工具或系统的更改。这项活动通过纠正措施和质量改进使人们有能力做出改变。后期检查还应受益于组织中可能没有直接涉及领先事件的其他成员，因为书面记录应该广泛共享并作为学习材料。
在值班时
工程师有能力理解可观测性数据。在团队的每个成员都积极学习如何应对游戏日事故的情况下，分享整个工程组织的值班任务非常重要，而不是只由少数精选人员负责。这也有助于减轻可能随时到来的重负和压力。当值班时，不应让任何一名工程师独自面对。角色和升级路径需要明确定义和理解。从第一响应者（911 调度员）到事故指挥官（专业人士）和升级经理（通常是负责沟通的工程经理），都不应要求他们成为英雄，而应要求他们协调和组装最适合解决问题的团队。
在值班时，检查清单可以被称为“运行簿”或其他名称。这些清单可以作为认知援助，卸载完成复杂教学任务的思维过程。游戏日是测试这些清单的完美场所。
因为我们已经通过消除信号噪声来确保减少虚假警报，并且每个人都了解自己在值班轮换中的角色，所以警报疲劳应该成为过去式。
人仍然是分布式系统的核心
通过实施这些策略，软件工程团队可以确保他们具备使用和有效理解可观测性信号所需的知识和技能。充分利用收集的数据对于提高分布式系统的整体性能和可靠性至关重要。教学和学习将使人因素超越单个个体。虽然我们仍然必须依靠人类大脑来诊断和解决问题，但让我们确保我们可以可持续地这样做。