重新定义可观察性 ： 以经验为中心的方法

重新定义可观察性：以经验为中心的方法 您的业务需要以体验为中心的运营 虽然在过去的十年中，可观察性和应用性能监控（APM）工具已经改变了工程和运营团队的运作方式，但每个运营副总裁和CTO仍然面临着几个挑战，没有明确的解决方案： •对社交媒体上的客户问题、客户支持电话或首席执行官的问题感到惊讶，即使他们的工具说一切都很好。 •每当重大事件发生时，都需要一支专业工程师队伍来调试。 •可观察性工具的成本爆炸，以监控其不断增长的基础设施。 断开操作工具和客户体验之间的连接 性能 完全断开 用户体验 图1 经验-中心操作 这些挑战都植根于相同的潜在问题。现有的可观察性工具和使用它们的团队与对业务真正重要的东西脱节：用户体验和参与。 运营需要从关注低级系统性能发展到更高级别的用户体验。以经验为中心的运营是一个新的范式 2这将使运营和工程团队变得更有效率，更与业务相连，更具成本效益。 什么是以体验为中心的运营？ 以体验为中心的运营是一种方法论的转变，用户体验是运营的核心。当然，系统级监控是需要的，但并不总是实时保存在用户体验的上下文中。通过用户体验，我们不是在谈论页面加载时间和崩溃的一小部分用户。我们谈论的是以量化的方式实时监控应用程序中每个用户的每个用户流。如果用户无法在预期的时间段内登录、注册或查找内容，我们应该收到此问题的警报。如果无论出于何种原因，成功注册的百分比突然从98％下降到94％，我们应该立即知道-而不是因为我们在社交媒体上阅读投诉。 以体验为中心的运营通过内在地将用户体验的全面测量与系统和应用程序性能联系起来，消除意外升级，通过本地连接点实现诊断民主化，并通过关注重要数据来降低成本，从而规避了这些问题。 这是一个简单的现实世界的例子。 在下面的图片中，我们正在查看ConvivaUI的实时体育应用程序，特别是跟踪称为登录处理时间在一个大事件之前。此度量度量在用户输入其凭据并单击登录后完成登录过程所需的时间。它将包括任何SSO集成，第三方身份验证检查和其他活动，以完成登录过程并启动工作应用程序。重要的是要注意 经验-中心操作 ，这并不像测量单个API调用的响应那么简单。 在监控指标时，我们会在事件即将开始之前看到突然的峰值。因为我们直接测量登录处理时间， 我们立即知道用户受到影响，以及有多少用户受到影响。 3 只需点击两次，在图片下一页，我们确定只有特定iPhone15版本和两个特定设备型号的用户遇到登录问题。 如果不立即解决，这将对试图观看事件的用户造成重大干扰，从而导致客户流失和品牌损害。因为我们直接测量登录处理时间，所以我们立即知道用户受到影响以及受到影响的数量。只需点击两下 ，在上图中，我们确定只有特定iPhoe15版本和两个特定设备型号的用户遇到登录问题。 iPhone11 7.32K 93.8K 0 0.625秒 43.5秒 30.2秒 iPhone13Mini 2.39K 5.67K 0 1.06秒 87.8秒 18.3秒 设备操作系统版本 平均网络请求持 续时间 网络请求计数 事件总数 应用程序崩溃 完整登录时间 登录处理 时间 平均网络请求持 续时间 Total 143K 2.09M 0 0.345秒 36.6秒 5.62秒 网络请求计数 事件总数 应用程序崩溃 完整登录时间 登录处理 时间 Total 143K 2.09M 0 0.345秒 36.6秒 5.62秒 iOs15.6.1 2.27K 27.4K 0 1.02秒 51.6秒 18.3秒 iOS16.6 121K 1.7M 0 0.318秒 37.8秒 3.2秒 iPhone13Pro 3.81K 60.6K 0 0.425秒 13.1秒 1.13秒 iPhone8Plus iOS15.7.8 1.97K 35.9K 0 0.711秒 28.4秒 0.412秒 5.01K 20.7K 0 0.183秒 39.1秒 0.0691秒 iPhone12 7.26K 95.9K 0 0.432秒 26.7秒 0.592秒 iOS16.5.1 1.84K 22.3K 0 0.611秒 6.27秒 0.407秒 在i下Phone13面的图片中4.35K，我14们3K再单击0 两0.2次86秒，3就3.3秒可以0.517秒确定对第三方iOS16.0身份验证服务511的缓9.2慢9K调用。0在0这.357秒种情29.7况秒 0.358秒 下，没有任何细致的后端监控可以帮助我们找到根本原因，因为这是第三方问题。 但是，通过以用户为中心的运营监控，我们可以轻松地将登录处理时间具体的设备型号到具体的 经验-中心操作 网络调用，让我们清楚地了解问题及其影响，并采取具体行动解决问题。 网络请求URL路径 网络请求URL主机 网络 请求计数 事件总数 应用程序崩溃 平均网络请求持续 时间 网络请求计数 事件总数 应用程序崩溃 平均网络请求持续时间 Total 36 61 NA 20.3秒 Total 2.05K 5.35K NA 1.19秒 /reggie/v1/acme/regcode 14 14 NA 48.4秒 sp.auth.reggie.com 44 73 NA 16.6秒 /adobe-services/usermetad... 3 7 NA 5.02秒 目录-服务-cdn.api.reg... 16 19 NA 3.61秒 /adobe-services/sessionDev... 1 1 NA 4.49秒 image-resizer-cloud-dcn.reg... 24 44 NA 3.56秒 /adobe-services/authorizeD... 1 2 NA 3.33秒 control.reggie.com 19 38 NA 3.41秒 /adobe-services/deviceShor... 11 13 NA 2.21秒 test.reggie.com 8 10 NA 3.41秒 新的操作方法 以经验为中心的运营是一种新的思维方式，确实需要一些时间来适应。与所有范式转变一样，必须有一个显著的好处。图3说明了这种差异和巨大的好处。左边是以基础设施为中心的当前范式。监控主要是从后端系统通过日志、指标和跟踪进行。运营团队监控 4这些定期，但惊喜仍然发生，许多经验问题仍然存在 在雷达下。当客户或社交媒体升级时，它会引发对潜在问题的疯狂搜索。对问题的规模或影响没有了解，也没有明确的优先级指导。 这意味着在许多情况下，运营团队和系统多个领域的专家工程师团队会被引入来诊断问题。最终，当发现并修复问题时，团队不确定客户问题是否得到解决，因为没有直接监控客户体验 。这种方法会导致更多的客户影响和更高的成本。 TherightsideofthefigureishowthingsworkinanExperience-Centricapproach.Thereisanequalemphasisonmeasurementofuserexperienceandsystemperformance.Whenuserexperienceisimmediately 并自动检测，然后通过与系统性能相关来诊断，精确定位导致问题的一个或多个组件。这意味着只需几个团队成员就可以快速解决问题。 以经验为中心 快速|主动|低成本 58%更长38%更长 第一次玩的时间 10.2分钟 修复CPU问题 修复应用程序版本问题修复播放器版本问题 不知道问题的严重性和严重性！ 痕迹 Logs Metrics 经验问题 从消费者和社交媒体升级 以基础设施为中心 慢速|反应性|昂贵 经验-中心操作 团队只需要查看重要的数据，从而降低成本。随着监控系统了解影响用户体验的系统性能模式，它可以在影响体验的问题发生之前开始预测这些问题，并将系统性能问题分类为影响客户或非影响客户，以帮助确定优先级和投资。 5图3 新的技术范式 不幸的是，现有的可观察性工具无法解决经验与绩效之间的脱节，也无法实现以经验为中心的运营方法。他们无法衡量经验指标，如实时连续登录处理时间并且无法将它们与性能原因联系起来 。需要一种新的技术范式来解锁 以经验为中心的运营。该技术必须支持一种灵活且简单的方法，以实时计算所有用户的体验指标，根据异常情况自动发出警报，然后将它们与客户端和后端中的性能联系起来，以快速诊断它们。这些操作中的每一个都非常有价值，但它们共同实现了一种转变，可以显著改善用户体验并降低运营成本。 可观察性工具无法桥接体验断开连接 当今的监控工具几乎只关注后端服务器和应用程序。不幸的是，这意味着运营团队与用户体验完全脱节，让他们在黑暗中猜测，没有关于如何优先排序的上下文。当由于用户无法注册而导致升级时 ，必须引入一支专业工程师队伍来发现问题，从而中断他们的高价值工作。由于没有明确的路径通过数据的根本原因，甚至工程师也减少了猜测和搜索所有系统的路径上的一些解决方案。这是缓慢 、昂贵和破坏性的。一旦他们找到一个可能的原因，花一些时间，并修复它，他们仍然不确定他们是否解决了真正的问题，因为没有直接验证用户体验。 经验-中心操作 与用户体验的脱节以及需要找到一种直接衡量它的方法对公司来说是一个已知的问题，可观察性工具一直试图通过两种方法来解决它。 1.通过从后端服务器和应用程序获取更多数据，可观察性解决方案希望捕获更高百分比的用户影响问题。 这意味着捕获更多日志，更多指标，并引入跟踪或捕获更多跟踪。这种膨胀导致公司的成本更高，但最终无法解决他们的问题：仅仅从后端来源理解经验是不可能的。 6 2.可观察性解决方案引入了RealUserMonitoring(RUM)工具来尝试捕获用户体验。遗憾的是 ，RUM在解决问题方面明显不足，因为这些工具是建立在非常有限的技术上的，这些技术使用昂贵，缺乏功能，并且只能在少量用户样本上运行。阅读有关RUM工具局限性的更多信息在这里. 这两种昂贵的方法都无法解决绩效与体验的脱节。这仍然是公司的主要压力点，因为尽管人力，技术和财务资源被抛在了问题上，但每天仍在发生意外的升级，使专家工程师远离业务创新。 遗留可观察性工具有什么问题？ 最大的缺点是根本性的：当今的解决方案无法实时计算真实的体验指标，因为它们根本没有任务所需的基础技术。所有这些工具都是为了计算事件，例如崩溃，错误，页面加载等而构建的-甚至它们很难大规模完成。 但是，经验不能作为事件的简单计数来计算。了解用户旅程的复杂性需要我们根据时间，时间间隔，序列和状态来计算复杂的指标。我们将整个过程称为状态分析或基于此的度量为有状态度量. 让我们更深入地看看这个： 经验-中心操作 错误计数是一种无状态度量，它不依赖于对序列、时间间隔或状态的理解。 注册时间是一个有状态的度量（授予，一个相当简单的度量，但是RUM工具甚至不能计算这个）。它可以被认为是有状态的，因为监控系统必须识别sign的开始和成功完成- 对于特定的会话(我们称之为会话），然后为每个会话计算两者之间的时间差，然后跨会话聚合 它们-所有这些都是实时的。 我们可以为注册时间指标通过排除在应用程序之外花费的任何时间。假设用户在注册时收到了文本，因此他们在注册过程中花费了一分钟在其消息应用程序中对其进行响应。这一分钟应该从注册时间您可以看到用户会话如何迅速变得比简单地计算两个事件之间的时间复杂得多。 7 也许你在问为什么你不能简单地计算客户端中的注册指标并将其作为事件发送。虽然这在一开始听起来可能是可行的,但它在实践中不起作用,因为在客户端中跨所有设备类型和用户流和版本的变化来计算所有相关的有状态度量,并且随着时间的推移来维护这产生了过高的开销,从而导致不准确的度量。 和缺乏信任，同时不断恶化的客户绩效。即使公司认真地致力于这种方法，他们也很快被迫放弃它，让运营团队从它开始的地方-坚持低水平的性能可见性和对用户体验的不了解。 图4显示了视