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

您的业务需要以体验为中心的运营 虽然在过去的十年中，可观察性和应用性能监控（APM）工具已经改变了工程和运营团队的运作方式，但每个运营副总裁和CTO仍然面临着几个挑战，没有明确的解决方案： •对社交媒体上的客户问题、客户支持电话或首席执行官的问题感到惊讶，即使他们的工具说一切都很好。•每当重大事件发生时，都需要一支专业工程师队伍来调试。•可观察性工具的成本爆炸，以监控其不断增长的基础设施。 这些挑战都植根于相同的潜在问题。现有的可观察性工具和使用它们的团队与对业务真正重要的东西脱节：用户体验和参与。 运营需要从关注低级系统性能发展到更高级别的用户体验。以经验为中心的运营是一个新的范式这将使运营和工程团队变得更有效率，更与业务相连，更具成本效益。 什么是以体验为中心的运营？ 以体验为中心的运营是一种方法论的转变，用户体验是运营的核心。当然，系统级监控是需要的，但并不总是实时保存在用户体验的上下文中。通过用户体验，我们不是在谈论页面加载时间和崩溃的一小部分用户。我们谈论的是以量化的方式实时监控应用程序中每个用户的每个用户流。如果用户无法在预期的时间段内登录、注册或查找内容，我们应该收到此问题的警报。如果无论出于何种原因，成功注册的百分比突然从98％下降到94％，我们应该立即知道-而不是因为我们在社交媒体上阅读投诉。 以体验为中心的运营通过内在地将用户体验的全面测量与系统和应用程序性能联系起来，消除意外升级，通过本地连接点实现诊断民主化，并通过关注重要数据来降低成本，从而规避了这些问题。 这是一个简单的现实世界的例子。 在下面的图片中，我们正在查看ConvivaUI的实时体育应用程序，特别是跟踪称为登录处理时间在一个大事件之前。此度量度量在用户输入其凭据并单击登录后完成登录过程所需的时间。它将包括任何SSO集成，第三方身份验证检查和其他活动，以完成登录过程并启动工作应用程序。重要的是要注意，这并不像测量单个API调用的响应那么简单。 只需点击两次，在图片下一页，我们确定只有特定iPhone15版本和两个特定设备型号的用户遇到登录问题。 如果不立即解决，这将对试图观看事件的用户造成重大干扰，从而导致客户流失和品牌损害。因为我们直接测量登录处理时间，所以我们立即知道用户受到影响以及受到影响的数量。只需点击两下，在上图中，我们确定只有特定iPhoe15版本和两个特定设备型号的用户遇到登录问题。 29.7秒0.358秒0.357秒09.29K511iOS16.00.517秒33.3秒0.286秒0143K4.35KiPhone13在下面的图片中，我们再单击两次，就可以确定对第三方身份验证服务的缓慢调用。在这种情况下，没有任何细致的后端监控可以帮助我们找到根本原因，因为这是第三方问题。但是，通过以用户为中心的运营监控，我们可以轻松地将登录处理时间具体的设备型号到具体的网络调用，让我们清楚地了解问题及其影响，并采取具体行动解决问题。 新的操作方法 以经验为中心的运营是一种新的思维方式，确实需要一些时间来适应。与所有范式转变一样，必须有一个显著的好处。图3说明了这种差异和巨大的好处。左边是以基础设施为中心的当前范式。监控主要是从后端系统通过日志、指标和跟踪进行。运营团队监控这些定期，但惊喜仍然发生，许多经验问题仍然存在 在雷达下。当客户或社交媒体升级时，它会引发对潜在问题的疯狂搜索。对问题的规模或影响没有了解，也没有明确的优先级指导。 这意味着在许多情况下，运营团队和系统多个领域的专家工程师团队会被引入来诊断问题。最终，当发现并修复问题时，团队不确定客户问题是否得到解决，因为没有直接监控客户体验。这种方法会导致更多的客户影响和更高的成本。 TherightsideofthefigureishowthingsworkinanExperience-Centricapproach.Thereisanequalemphasisonmeasurementofuserexperienceandsystemperformance.Whenuserexperienceisimmediately 并自动检测，然后通过与系统性能相关来诊断，精确定位导致问题的一个或多个组件。这意味着只需几个团队成员就可以快速解决问题。 团队只需要查看重要的数据，从而降低成本。随着监控系统了解影响用户体验的系统性能模式，它可以在影响体验的问题发生之前开始预测这些问题，并将系统性能问题分类为影响客户或非影响客户，以帮助确定优先级和投资。 新的技术范式 不幸的是，现有的可观察性工具无法解决经验与绩效之间的脱节，也无法实现以经验为中心的运营方法。他们无法衡量经验指标，如实时连续登录处理时间并且无法将它们与性能原因联系起来。需要一种新的技术范式来解锁 以经验为中心的运营。该技术必须支持一种灵活且简单的方法，以实时计算所有用户的体验指标，根据异常情况自动发出警报，然后将它们与客户端和后端中的性能联系起来，以快速诊断它们。这些操作中的每一个都非常有价值，但它们共同实现了一种转变，可以显著改善用户体验并降低运营成本。 可观察性工具无法桥接体验断开连接 当今的监控工具几乎只关注后端服务器和应用程序。不幸的是，这意味着运营团队与用户体验完全脱节，让他们在黑暗中猜测，没有关于如何优先排序的上下文。当由于用户无法注册而导致升级时，必须引入一支专业工程师队伍来发现问题，从而中断他们的高价值工作。由于没有明确的路径通过数据的根本原因，甚至工程师也减少了猜测和搜索所有系统的路径上的一些解决方案。这是缓慢、昂贵和破坏性的。一旦他们找到一个可能的原因，花一些时间，并修复它，他们仍然不确定他们是否解决了真正的问题，因为没有直接验证用户体验。 与用户体验的脱节以及需要找到一种直接衡量它的方法对公司来说是一个已知的问题，可观察性工具一直试图通过两种方法来解决它。 1.通过从后端服务器和应用程序获取更多数据，可观察性解决方案希望捕获更高百分比的用户影响问题。 这意味着捕获更多日志，更多指标，并引入跟踪或捕获更多跟踪。这种膨胀导致公司的成本更高，但最终无法解决他们的问题：仅仅从后端来源理解经验是不可能的。 2.可观察性解决方案引入了RealUserMonitoring(RUM)工具来尝试捕获用户体验。遗憾的是，RUM在解决问题方面明显不足，因为这些工具是建立在非常有限的技术上的，这些技术使用昂贵，缺乏功能，并且只能在少量用户样本上运行。阅读有关RUM工具局限性的更多信息在这里. 这两种昂贵的方法都无法解决绩效与体验的脱节。这仍然是公司的主要压力点，因为尽管人力，技术和财务资源被抛在了问题上，但每天仍在发生意外的升级，使专家工程师远离业务创新。 遗留可观察性工具有什么问题？ 最大的缺点是根本性的：当今的解决方案无法实时计算真实的体验指标，因为它们根本没有任务所需的基础技术。所有这些工具都是为了计算事件，例如崩溃，错误，页面加载等而构建的-甚至它们很难大规模完成。 但是，经验不能作为事件的简单计数来计算。了解用户旅程的复杂性需要我们根据时间，时间间隔，序列和状态来计算复杂的指标。我们将整个过程称为状态分析或基于此的度量为有状态度量. 让我们更深入地看看这个： 错误计数是一种无状态度量，它不依赖于对序列、时间间隔或状态的理解。 注册时间是一个有状态的度量（授予，一个相当简单的度量，但是RUM工具甚至不能计算这个）。它可以被认为是有状态的，因为监控系统必须识别sign的开始和成功完成-对于特定的会话(我们称之为会话），然后为每个会话计算两者之间的时间差，然后跨会话聚合它们-所有这些都是实时的。 我们可以为注册时间指标通过排除在应用程序之外花费的任何时间。假设用户在注册时收到了文本，因此他们在注册过程中花费了一分钟在其消息应用程序中对其进行响应。这一分钟应该从注册时间您可以看到用户会话如何迅速变得比简单地计算两个事件之间的时间复杂得多。 也许你在问为什么你不能简单地计算客户端中的注册指标并将其作为事件发送。虽然这在一开始听起来可能是可行的,但它在实践中不起作用,因为在客户端中跨所有设备类型和用户流和版本的变化来计算所有相关的有状态度量,并且随着时间的推移来维护这产生了过高的开销,从而导致不准确的度量。 和缺乏信任，同时不断恶化的客户绩效。即使公司认真地致力于这种方法，他们也很快被迫放弃它，让运营团队从它开始的地方-坚持低水平的性能可见性和对用户体验的不了解。 图4显示了视频流应用程序的体验指标的含义。左边是低级性能指标（RUM工具的重点）。中间是关键体验指标，按用户流程的每个部分进行分类。右边是参与度指标（产品分析的重点）。A全面了解用户体验需要以连接的方式实时测量这三者： •敬业度反映了对业务至关重要的结果。它帮助我们理解体验的影响，并定义什么是好的体验。•性能有助于诊断为什么我们有一个经验问题。•经验是绩效和参与度之间的联系。它是当今每个企业中最重要的缺失部分，今天的可观察性工具无法提供。 Conviva的以体验为中心的运营和状态分析方法 Conviva构建以体验为中心的运营平台的方法涉及两个关键技术：1）瘦SDK（我们称为Sensor），这是一种从应用程序端点收集数据的新方法；2）时间状态技术，这是一种新的抽象和系统，用于大规模高效，实时和有状态的数据处理。 瘦SDK策略可实现轻量且准确的体验监控 将用户体验与系统性能联系起来的第一个挑战是需要部署SDK，这是任何应用程序开发团队想要做的最后一件事。 我们明白了这一点。我们已经经历了15年，因为我们目前在数千个应用程序和设备模型，Web浏览器，手机，平板电脑，智能电视，机顶盒，游戏机甚至汽车上管理着大约70亿个SDK实例。从这种经验中，我们可以自信地说，当您尝试衡量真实用户时，无法避免从应用程序收集数据然而，我们也知道，我们可以比所有的RUM和产品分析SDK做得更好。 我们学到的关于SDK的第一课是，它们必须非常简单，尽可能少做工作。这意味着我们必须抵制在SDK中对数据进行任何计算或操作。这是违反直觉的，因为乍一看，这似乎是更便宜的选择，因为我们使用设备的CPU周期而不是我们的后端，而更容易的选择，因为指标直接应用于数据。然而，实际上，这会使SDK更重，这会减慢应用程序的速度，并且更容易过时，因为指标实施将过时并在数周内变得不准确。 如果您正在计算十几种设备类型的20个指标，那么240个指标实现可能已经过时，甚至是错误的。 为了解决这个问题，我们的SDK只收集事件，而不执行任何语义模式。我们完全按照设备操作系统和您的应用程序所暴露的事件来摄取事件。这意味着开发人员不必像他们想要在Adobe或GoogleAalytics中处理数据或将自定义事件发送到RUM工具那样对每个事件进行检测。相反，他们可以通过我们的SDK简单地将他们的应用程序连接到Coviva平台，我们可以在没有采样的情况下提取所有事件数据。这里的神奇之处在于，开发人员可以控制他们想要拉入的事件，映射和重命名事件，并从这些事件中创建任何有状态（或无状态）指标-所有这些都在后端。 这种方法确实意味着我们在后端承担了比其他系统更多的处理负载。动态事件映射和有状态度量计算不是现有工具可以在数百万个端点规模上实时执行的操作，但它们是我们需要完成的解决以体验为中心的操作的操作。事实证明，没有大数据技术（开源或专有）可以处理我们需要的东西，所以我们必须从头开始创建它。 时间状态技术实现以体验为中心的操作 让我们重申一下企业在数字环境中面临的问题：他们需要能够在大数据后端以数百万个端点的规模实时进行有状态度量计算，并且必须具有足够的成本效益才能成为实用的解决方案。 我们试图通过每个主要的大数据平台-Spark，Flink，Kafka，Druid，Clickhouse等来解决这个问题。他们都无法单独解决整个问题。他们为解决方案提供了良好的组件，但他们无法成为核心引擎，以大规模和高效地实时计算原始事件流的有状态指标。 这