作者：来自 Elastic Karolina Kurstak
14 次企业访谈、两轮原型设计、一次重构的 APM 服务地图。Elastic Observability 9.5 背后的设计故事。
Elastic Observability 9.5 发布了 APM 服务地图自推出以来最大规模的一次全面改造。这次重构基于 14 次企业访谈、两轮原型设计，以及人们真正会带着什么问题来到服务地图这一核心问题：出问题了，情况有多严重，我应该先从哪里查？ 这就是这次设计背后的故事。配套文章介绍了发布了哪些内容以及如何使用以及它是如何构建的。
APM 服务地图的重新设计始于倾听
在设计任何东西之前，我们先观察现有地图是如何被使用的，更重要的是，了解客户对它的反馈。我们得到的信号非常一致：这张地图给人的第一印象很好，但在企业规模下，它还没有真正成为人们日常调查工作中的一部分。解决方案架构师告诉我们，它在只有 12 个服务时表现得非常出色，但还无法如此干净地扩展到 200 个服务（很不巧，客户就是坚持要有 200 个服务）。而规模化后的性能问题也被反复提及。很多次。
机会并不在于打造一张更好看的地图，而在于打造一张更有帮助的地图。我们开始研究，想弄清楚"有帮助"究竟意味着什么。
研究优先，像素其次
我们对 6 家企业客户进行了 14 次访谈，同时也采访了 Elastic 自己的 SRE、顾问和解决方案架构师。我们有意采用了一种不同的方式。我们没有问"你想要一张更漂亮的地图吗？"（每个人都会说想要一张更漂亮的地图），而是问："带我回顾一下你上一次调查的事件。"
三个发现完成了大部分工作：
-
没人会在一切正常的时候打开服务地图。 人们通常是在收到告警后匆忙赶来，有时甚至是在凌晨 3 点。第一项任务，正如一位工程师所说，是 "证明自己的清白"：我是原因，还是受害者？而在那个时刻，地图还无法显示健康状况或告警上下文。
-
上下文胜过完整性。 没有人想要完整的拓扑；他们想要的是问题周围的邻域，以及地图一直没有展示的业务上下文。
-
健康状况必须直接存在于地图上。 告警、异常、SLO。地图知道你的拓扑；现在它还需要知道哪里出了问题。
研究的好处在于，到了某个时候，你可以停止表达自己的观点。当有人问我们为什么要在告警页面中放置一个预览地图时，我们不需要争论或费力解释。我们直接播放了一段录音。
设计 APM 服务地图的使用流程，而不只是设计一个页面
基于这些发现，我们在 Figma 中设计了端到端流程：告警触发 → 显示以受影响服务为范围的预览地图 → 点击节点，获取上下文 → 通过分组和过滤展开完整地图。
我们录制了粗略的演示视频，并将它们发布到公开渠道。这个过程有点令人害怕，但绝对值得：反馈在几小时内就收到了，而此时修复还只是一次 Figma 编辑，而不是一个 PR。
两轮验证
3 月中旬，我们将端到端设计分享给了在大型、高要求生产环境中工作的集群管理员和 SRE。两周后，同一批人开始点击体验可运行的 Kibana 原型。
几个塑造了 9.5 的瞬间，以下内容均已匿名处理：
蜷缩成一团哭泣？这可能会是我的第一反应。...... 我首先想做的事情，是开始过滤红色或黄色 ------ 把所有健康的东西都过滤掉 ------ 然后把这个庞大的单体东西聚焦起来。------SRE，在看到一个包含约 100 个节点的生产规模地图时
它让我们知道需要和哪些团队沟通 ------ 而不仅仅是知道应用程序的名字，然后希望我们能记得是谁在负责。------ 平台工程师，在按负责团队进行分组时
这条路径正是我希望做的事情 ------ 点击节点，然后查看事务。------ 集群管理员，第一次点击体验原型时
还有一个让我们颇受教育的反馈，针对的是一个我们非常喜欢的展开/折叠控件：
到了这里，我完全不知道那里实际上还有更多内容。我只能盲目地逐个点击这些控件，展开和折叠，只是为了查看更多地图内容。------SRE，在看到我们的逐节点展开/折叠控件时
我们砍掉了这个控件。它的动画非常漂亮。我们不再谈论它。
每次访谈结束后，我们都会记录笔记、进行调整，并预约下一次跟进。参与者在两周后就能看到自己的反馈得到体现；几个人说，这正是他们一直愿意参与的原因。
核心三人组
团队由一名 PM、一名工程师和一名设计师组成，这大概是最不花哨的组合了。我们始终保持持续的沟通，同时还有更大的工程师团队与我们并行构建。Jenny（工程）参与研究访谈。Roshan（PM）在公开渠道发布粗略的视频。我在功能还处于不断变化的阶段就开始阅读 PR。当我们产生疑问时（经常如此），没有人试图争个输赢。我们一起头脑风暴、交换知识，然后回到用户告诉我们的内容。
不需要为决策进行辩护，是一种被低估的生产力工具。当负责构建设计的人参与了决策过程，就没有人需要通过编写规格说明来保护设计。
Cytoscape 到 React Flow 的迁移也源于同样的沟通。Jenny 在她的文章中讲述了这个故事。
以一种无聊的方式赢得信心
到了构建阶段，9.5 中的每一个想法都已经在用户面前验证过五六次。我们不再只是抱有希望；我们已经亲眼看到它能够奏效。
然后在 6 月，一封未经邀请的邮件发了过来，来自一位甚至还没有看到大部分地图改进内容的客户：
这些新更新太棒了！这是我们很长一段时间以来看到的最棒的东西，我们非常喜欢 Observability/APM 仪表板全新的外观和体验！------企业客户（哇。）
我很想说这是因为我们的才能。但其实只是一个循环。我们从第一次访谈一直到发布分支，都在不断地询问、倾听、构建，然后再次询问。无聊，不花哨。但有效。就像你想吃得健康时早餐吃一碗粥。或者你想要攀登高山时，在楼梯机上锻炼几个小时。
顺便说一句，我们还不知道这会走多远；9.5 才刚刚开始进入人们的集群。但我们知道，目前为止，没有任何内容是在未经测试或凭借猜测的情况下发布的，而对我来说，现在这样就足够好了。
我会从我们这里 "偷走" 的经验（我确认过，它确实有效！）
从真实信号开始（使用模式、客户反馈），即使这些信号有时令人难受。 "这并没有像我们希望的那样帮助人们"比任何"我认为我们应该......"都更适合作为工作简报。
围绕场景进行访谈，而不是围绕功能。 "带我回顾一下你上一次事件"让我们看到了人们实际会打开、跳过和难以处理的内容。而"地图上需要哪些功能？"永远不会告诉我们这些。
在未经润色的 Figma 中测试流程，在尚未完成的代码中验证决策。 单独进行任何一轮都不够，而且两轮都不需要漂亮。没人需要一个凭感觉编码出来的、可以点击的东西；一个清晰的流程就足以开始。像素是最容易处理的部分，而当体验很差时，它们也是最不重要的部分。
当天就在公开渠道分享粗略的工作成果。 尴尬感会在当天结束前消退；反馈会留下来（还有你建立起来的人际联系！）。
让你们三个人保持紧密合作，持续沟通。 沟通、信任和透明度。这里所有好的成果都来自这种团队结构。
新的 APM 服务地图今天已经在 Elastic Observability Serverless 中提供，并将随 9.5 进入 Elastic Cloud Hosted 和自管理部署。如果它让你的下一次事件处理稍微容易一些，这在很大程度上要归功于那些参与塑造它的 SRE、管理员和顾问，他们有时会劝我们放弃自己最喜欢的想法。
感谢 Jenny Pavlova（工程）、Roshan Gonsalkorale（产品），以及将这一切变成 9.5 的更广泛工程师团队。
原文：APM service map redesign in Elastic Observability 9.5 --- Elastic Observability Labs