翻译自 DevOps as a Graph for Real-Time Troubleshooting 。更多链接请查看原文。
所有数据中都存在隐藏的关系，只能通过工程师的知识图谱来表达。
每个 DevOps 工程师自然而然地在他们的脑海中保留了所有基础设施和互连服务的知识图谱。这张图是支离破碎的，需要时间来学习和记录，也需要脑力来保留。需要熟悉系统，有丰富的运营管理经验才能完成这些人工对接。
但是，当今复杂且动态的微服务架构使得我们无法跟上我们周围所有软件和基础设施的变化。这种认知负荷因增加上下文切换的孤立监控和可观测性工具而变得更加复杂，这对我们快速解决问题和避免停机的能力产生了负面影响。
所有数据中都存在隐藏的关系，只能通过工程师的知识图谱来表达。当我们从数据中提取关系以形成实时动态图时，生产问题的影响和相关原因会更加明显。我们希望从观察单个数据点，然后在脑海中慢慢将它们连接起来，转变为观察同一上下文中的所有数据点和连接。这样一来，我们识别和解决问题的过程就会更快、更准确。
在现代 IT 环境中，我们不断进行改变以提高应用程序性能和强化系统。这些变化通常会导致失败。拥有一个将所有基础设施和微服务链接在一起的 DevOps 图可以让团队看到隐藏的关系。当我们通过可观测性工具中的可视化将此图表变为现实时，运维人员和 SRE 可以快速找到生产问题的原因。
SRE 在事件响应期间面临的一个常见挑战是将客户问题或性能问题转化为特定的服务和团队。通过 DevOps 图的强大可视化，这种第一级分类变得更加容易，允许 SRE：
- 使用显示 IT 环境中组件之间关系的动态拓扑在运营数据之间建立关联。
- 通过用户或脚本可搜索和过滤的实时事件时间线查看新代码或配置更改的意外后果。
- 为开发人员提供关键事件时间线信息和拓扑结构，以主动对他们的代码进行故障排查和调试。
- 让团队对事件负责，并通过运营活动和变更管理的记录系统专注于信息共享。
开始问正确的第一个问题：是什么导致了变化？与其问发生了什么（指标）、为什么（日志）或在哪里（分布式跟踪），不如问是什么导致了变化，这有助于我们从整体上解决复杂的故障。例如，每个事件工作流程看起来都像这样：
- 值班工程师收到警报并宣布事件。
- 他们检查一些指标仪表盘以了解异常行为。
- 他们可能会将事件上报给基础设施、云网络和安全团队，以排除这些领域是根本原因。
- 这些团队深入研究各种日志和跟踪以获取更多详细信息。
- 图表和数据片段通过 Slack 在团队成员之间来回发送。
- 在找到问题的原因之前，团队会多次返回指标图表和日志。
这个流程有什么问题？几件事：
- 此事故工作流程可能需要数小时或数天才能缓解和解决问题。
- 团队在没有上下文的情况下立即挖掘日志会浪费时间和资源。
- 团队正在通过 Slack 处理数据片段，这既不高效也不可持续。
在将其他团队的成员拉入事故响应之前，我们需要提供上下文。什么情况（变化）形成了事故的背景？涉及哪些组件，依赖性是什么？服务所有者可以使用哪些有用的日志或跟踪来有效地进行故障排查？通过在具有可操作数据的仪表盘中捕获事件发生时的上下文，知识共享变得更加容易。这会在整个组织内带来更好的故障排除体验。
在容器化环境中提供可靠的服务并保持正常运行时间是一项艰巨的任务。如果发生事故或重大中断，最重要的是我们能以多快的速度从中恢复。可观测性数据的增长可以提高或阻碍可观测性。组织面临的一个主要挑战是使用他们的数据来改善平均恢复时间 (MTTR) 的能力。是时候重新考虑我们首次排除故障和连接因果关系的方法了。当我们将 DevOps 视为图时，我们最终超越了传统的可观测性支柱，开始以新的思维方式处理事件。
数据连接：许多用于可观测性的数据是相互关联的，但我们当前的工具不允许我们将指标、日志和分布式跟踪视为连接的信息源。这些数据类型通常是在孤岛中收集的，并且数据的关联是手动完成的。例如，要了解一项服务指标的峰值是否与另一项服务的指标峰值有关，我们通常会搜索指标图表以找到相关性。
您需要一个从一开始就连接运营数据的解决方案。可视化应用程序及其所在基础架构的图，可以通过事件实时建模因果关系，从而消除了处理我们头脑中隐藏的连接的精神负担。该解决方案还需要解决我们当前工具中的另一个关键差距：缺失的变更数据。
变更影响：Digital Enterprise Journal 最近的 IT 绩效报告发现，变更是生产问题的最大来源。 75% 的性能问题最终都可以追溯到环境的变化。当简单的配置错误可能导致多米诺骨牌效应时，需要吸取更广泛的教训。如果您没有将捕获代码或配置更改作为可观测性策略的一部分，那么是时候缩小差距了。
知识共享：对许多组织而言，跨团队一致地记录和共享知识是一个痛苦的过程。随着时间的推移，高级工程师和经验不足的工程师之间的知识差距越来越大，使实时故障排除更具挑战性。经验不足的工程师通常不知道哪些数据对特定事件很重要，并且缺乏理解因果关系的能力。
这是一个组织问题，因为它会影响开发、运营和管理。大多数每天部署的公司都报告说，他们的工程师至少有一半的时间用于故障排查和调试。如果我们不为工程师提供学习联系、建立因果模型并允许跨团队共享“图”的工具，这种“故障排除税”将会变得更高。
在不断变化的 DevOps 环境中，再多的测试或自动化也无法阻止缺陷进入生产环境。再多的混沌工程也无法预测所有可能的故障。最后，我们必须认识到，中断很少会因为单一故障而发生。它通常是同时发生的“预事件”（例如，配置更改、代码提交、脚本执行）的组合。无论您向左移动多少，当您向右移动时总会出现问题——如何管理变化并连接因果关系将推动更好的结果。