前言

在创建多租户环境时，您的重点之一是打造统一的操作体验，通过单一管理界面实现环境的统一管理、运维和部署。您需要高效、自动化、可重复的机制，这些机制专为多租户环境的独特特性而设计。您希望成为那家以能够用精简、专注的运维团队管理和运营环境而自豪的SaaS公司。

从许多方面来看，多租户解决方案的运维视角为评估系统是否实现了SaaS模式带来的敏捷性、创新性和效率优势提供了最深刻的洞察。本章的目标是深入探讨SaaS运营领域，分析构建最佳实践运营体验所需的思维方式、策略及考量因素。这意味着要挑战并拓展传统运营观念，更细致地考察多租户架构如何影响整个业务的运营特征。

我将从奠定基础开始，探讨SaaS运营思维的核心要义。目标是分析运营环境，并概述团队在设计和构建运营工具及体验时通常采用的思维模型。您将看到SaaS的零停机特性与企业当前及长期战略所需数据之间的交汇点。接下来，我们将聚焦于支撑业务和技术洞察的核心指标数据，这些洞察被用于分析SaaS业务的各个维度。

我们将超越传统基础设施指标，重点探讨用于衡量和分析租户活动、业务健康状况、运营健康状况、敏捷性等维度的更广泛指标集。探索这些不同类型的指标将帮助您更好地理解SaaS团队依赖的整体分析

SaaS团队依赖于评估SaaS业务状态的整体分析。作为此部分的内容，我们还将探讨成本建模策略，使您能够将消耗与成本关联到特定租户。本章还将回顾可用于实施此运营模型的不同策略，概述用于捕获、发布和聚合指标的各种工具、技术和技术。

这将自然过渡到探讨这些指标和洞察如何通过您的运营控制台呈现。在此，我将重点关注构建支持特定多租户功能的租户感知控制台的细节，这些功能对于管理和运营SaaS环境至关重要。最后，我们将探讨环境的构建和部署方面如何受到您可能需要支持的各种多租户部署模型的影响

SaaS运营思维

对于许多软件组织而言，运营的范围通常已较为明确。然而，在SaaS环境中，我认为成功团队更应采用更广阔的视角来定义其运营模型的范围。这正是从产品思维向服务思维转变的一部分，要求组织在运营模型中更加重视整个端到端客户体验。在这种模式下，你需要考虑客户旅程中的每一步，并持续监控、测量和分析客户在与系统互动的每个触点处的服务体验质量。

对于部分团队而言，这可能已成现实。然而，当我们深入探讨这种运营思维模式的细节时，你会发现该模型对团队在组织内应用相关概念的方式具有显著影响。这并非单纯为员工赋予新头衔，而是一种应贯穿组织各层级的思维方式，影响不同角色如何将SaaS运营原则融入其整体工作方法。为了更好地理解这一更广泛的运营模型，让我们看看SaaS如何影响组织不同部分的思维方式。

最容易入手的是经典运营视角，即技术团队站在前线，负责监控和衡量SaaS应用的活动、规模和健康状况。在SaaS环境中，该团队面临一系列新挑战，任何服务中断或性能下降都可能对系统中所有租户产生连锁反应。与管理一系列独立的客户环境不同，这些团队将与部分或全部租户共享的基础设施进行协作。这种动态为运营体验增添了新维度，需要新的工具、监控手段和架构，以分析系统活动和健康状况。根本上，团队需要对租户有更深入的了解，以便有效识别、响应并解决运营事件。

当我们关注传统视角之外的运营考量时，情况变得更加有趣。在此，我们不再局限于打造零停机环境的紧迫性，而是更加关注客户体验。核心理念是，我们必须识别并呈现能够反映租户整体体验的数据。例如，租户入驻流程对SaaS提供商而言是一个重要的运营节点。我们希望客户能够以尽可能少的摩擦完成入驻流程，并及时从入驻阶段过渡到实际获取价值。

这是您SaaS环境运营体验的一部分。您组织中的团队和多个角色应具备对这一入驻体验的洞察，以便在客户开始使用系统各模块时评估租户体验的质量。多个客户难以取得进展将构成需要关注的重大运营事件。这种思维方式可扩展至组织其他方面。例如，客户成功团队应能访问洞察数据，以监控客户的持续活动、使用功能、可能遇到的瓶颈等。这些洞察使团队能够基于数据分析客户行为模式，识别需由工程团队解决的问题，从而提升整体服务体验。产品管理团队也与这一运营故事紧密相连。例如，他们可能需要访问租户消费趋势数据，以影响环境的分层和定价策略。

他们可能希望通过在特定租户群体中部署金丝雀发布来测试新功能，或分析交互模式以发现用户体验中的摩擦点。这种思维方式的重要组成部分在于构建一个主动型模型，其中运营机制和企业文化更加注重在问题影响租户之前就识别出趋势和问题。当我们讨论系统健康时，这种主动性不难理解，因为主动检测和解决问题对您的SaaS业务价值影响明显。

然而，这种主动性对我们在此讨论的业务其他运营视角同样重要。识别一个正在经历糟糕入驻体验的租户对运营成功至关重要。同样，客户成功、产品管理以及其他可能需要主动识别需要解决趋势的业务部门也适用这一原则。核心要点是，SaaS运营应被视为贯穿组织多个角色的一体化体验。当然，这需要部分组织在文化上进行较大的转变。在许多环境中，运营往往被孤立视为纯技术领域。

如今，随着这一扩展模型的引入，我们要求业务其他部门对服务体验有更强的责任感。这意味着要求员工重新审视自身角色范围，并思考如何为业务整体运营表现做出贡献。对于部分员工而言，承担额外的运营视角可能并不自然。此时，领导层需要发挥作用，为组织设定正确的运营基调。在某些情况下，我看到领导层会为团队设定共享的运营目标。

这有助于团队更好地优先考虑对运营工具、机制和交付成果的投资。自上而下、由领导层驱动的共享目标视角，能更好地强调业务在推动以服务为中心的运营模式中所做的承诺。所有关于运营和新思维方式的讨论可能看起来相对直观。通常，让团队认同这种更广阔的运营视角的重要性并不困难。尽管在理念上达成一致，但我合作过的许多组织并未完全采纳这些概念。

急于构建功能和能力似乎不断将这些运营需求推向次要地位。它们成为“我们计划以后再做”的领域，却从未获得应有的关注。在我看来，如果你真正致力于打造丰富的SaaS服务体验，你的业务就应优先构建能够驱动SaaS业务增长与成功的运营基础和文化。

你的团队和组织应专注于提升服务运营能力——即使这意味着牺牲部分功能开发。需要特别指出的是，运营不应被视为静态的一次性投资。随着租户需求、架构、市场和团队的演变，你应持续重新评估用于管理和分析业务运营状态的运营工具、机制和指标。

多租户运营指标

作为SaaS企业，您必须时刻掌握服务运行状况。SaaS团队通常渴望获取涵盖业务与技术全维度的数据和洞察。产品所有者、架构师、开发人员、市场营销人员、CEO——所有这些角色都应以指标为驱动，利用数据持续评估业务表现及满足租户需求的情况。

这些数据将用于塑造架构决策、产品待办事项列表、分层模型、入驻流程、架构策略以及业务的其他诸多方面。我已将所有这些数据分类为“指标”数据。我将用于分析基础设施、租户和财务活动的任何数据都归入此类别。

这些数据可能来自应用程序和业务系统，用于驱动跨多个角色和使用场景的运营及战略决策。我将其与“计量”数据，后者用于跟踪生成租户账单所需的数据。这两个领域可能存在重叠，因为指标数据也可能在计量场景中被使用。

关键在于，指标和计量分别驱动两种不同的用例。为了更好地理解这一点，让我们先看看解决方案的指标模型中可能收集的各种数据类型。

租户活动指标

在SaaS环境中，您的团队需要了解租户的具体活动。这些数据将帮助您构建更完整的视图，了解租户如何使用环境中的各项功能，并在某些情况下将这些活动与其他指标相关联，以发现有趣的模式和趋势。图12-1展示了属于此类别的部分指标。

图12-1

您会发现，我将租户活动指标分为三个独立的类别，以便您更好地了解租户活动所涵盖的范围。在左上角，您会看到租户入驻。此处捕获的指标用于评估租户的整体入驻体验，识别流程中可能影响租户快速部署环境的潜在瓶颈。

尽管大多数团队都认识到拥有一个健壮、高效的入驻体验的重要性，但许多团队并未投入精力来捕获此领域的指标。衡量入驻的可重复性、稳定性和可扩展性对于评估您的SaaS业务状态至关重要。它也代表了您给新租户留下的第一印象。在任何自助式入驻流程中，入驻指标都具有重要意义。

即使是内部管理的流程，你也需要引入能够捕捉租户入驻体验关键数据的指标。这通常是企业重点关注的指标之一——每个客户的价值实现时间（Time to Value）。该指标衡量从启动入驻流程到实际开始体验解决方案价值之间的时间间隔。如果解决方案中的步骤过于繁琐，可能会降低客户采用率，甚至导致客户放弃服务。

租户活动指标的下一类，即租户应用分析，如图中所示。这代表了用于跟踪租户与实际应用程序互动的经典指标（类似于网页分析）。在此，我们评估单个租户在应用程序中的导航情况，识别可能影响租户生产力或整体体验的用户体验问题。

这是一个已被广泛理解的领域，但以分层或按租户为单位捕获这些数据，则增添了新的考量维度。最后，在图表的最右侧，您将看到租户生命周期指标或事件。在此处，系统会捕获有关租户可能即将进入或正在经历不同状态转换的数据。

例如，假设有一个指标显示某租户对系统的整体使用量正在下降。结合其即将到期续约的事实，这将帮助您的团队识别出正在考虑离开系统的租户。将这些数据与其他指标结合使用，可以为租户生命周期中的关键、可操作时刻提供洞察。图12-2展示了如何利用这些数据的一个示例。

图12-2

在该图表顶部，我展示了两种租户状态的示例。左侧为入驻状态，代表新入驻的租户。在此标题下，您将看到一系列用于评估其入驻体验成功与否的指标。每个租户的活动水平及其访问的功能将用于描绘其在入驻体验中的进展，并根据不同阶段分配红色（正方形）、黄色（三角形）和绿色（菱形）状态。

那些正在获取价值并使用系统功能的租户会被分配为“绿色”状态，而进展较慢的租户可能被标记为黄色或红色。这些指标帮助我们识别可能需要跟进的租户。在右侧，我展示了已在系统中使用一段时间的租户，并通过租户活动来分析其持续使用系统的情况。

在此阶段，跟踪活动跟踪发挥不同作用，揭示租户活动水平下降的租户。这可能与新挑战有关，也可能是团队正在减少对我们解决方案的依赖。无论哪种情况，此状态均可识别出可能需要进一步跟进的租户。

敏捷性指标

敏捷性可能并不像一种可以量化的东西。然而，当你审视运营活动的全貌时，你会发现存在一些机会，可以挖掘出可用于描述环境敏捷性的数据。如果作为一个组织，你正在投资于专注于最大化敏捷性的机制，那么你也应该同样致力于识别用于衡量你朝着这一目标进展的指标。

SaaS业务和技术领导者应该利用这些数据来持续评估敏捷性趋势和模式，识别任何可能削弱业务运营效率的新兴或持续挑战。敏捷性可用于提出各种运营问题。您在应对新客户激增时准备得如何？您推出新功能和能力的效果如何？团队在应对性能、规模或功能问题时能多快且主动地做出响应？这些都是您的运营经验机制和工具应发挥作用的领域。

现在，您只需添加能够为业务提供数据以衡量这些构造表现的指标。以下是一些用于衡量运营敏捷性的关键指标：

• 可用性 衡量运营敏捷性首先要从最基础的指标入手：可用性。可用性问题会削弱敏捷性故事的其他所有方面。面临可用性或稳定性挑战的团队更倾向于限制发布，因为他们担心引入任何新功能都可能导致更多服务中断。在某些情况下，可用性也是衡量您采用的多租户扩展策略的指标。您的架构需要采用能够抵御新租户引入、噪音邻居条件以及各种变化的租户消费模式的策略和政策，同时确保系统运行无缝。跟踪这些数据并测量系统的响应能力，将使您能够评估系统在租户受到干扰之前检测和响应挑战的能力。

• 部署/发布频率 在多租户环境中，构建和部署常面临新挑战。租户资源的孤岛化和池化特性意味着，部署工具需考虑如何根据每个租户环境的独特基础设施配置，实现上下文相关的更新部署。这可能部署自动化可能存在复杂性，若部署自动化存在缺陷，可能会引发问题。这包括在零停机环境中考虑如何应用配置或模式更改到租户。您对发布工具的信心越强，就越有可能在不担心影响环境稳定性的情况下，积极采用持续发布新功能的模式。这正是与许多人在衡量DevOps实践效果时常提及的DevOps研究与评估（DORA）指标产生重叠的领域。

• 部署失败 在某些情况下，您可能尝试进行部署，但部署工具或自动化流程中出现故障。此类故障可能不会直接影响租户，但仍代表着SaaS组织敏捷性的重要指标。它为您提供更具体的部署自动化稳定性评估，可能揭示影响环境整体可用性的潜在问题。

• 循环时间 如果您已构建了敏捷运营环境并能够频繁发布，那么您也应能够以更快速的试错模式运行。周期时间是衡量这一动态的关键指标，它衡量从提出新功能想法到该功能交付到客户手中的时间。其核心理念是借助敏捷性与客户进行实验和尝试新想法，并基于客户反馈快速调整方向。这促进了创新，并最终通过客户对反馈的快速响应提升客户忠诚度。

• 平均检测/恢复时间 敏捷性的另一个关键要素在于快速检测并恢复问题的能力。若系统中出现问题，您希望工具和机制能尽可能快速地检测到这些问题，并通过能够快速修复环境的机制进行处理。这可能是回滚操作，也可能是发布补丁。关键在于：您的工具和自动化流程能多快有效解决问题并恢复系统至健康状态？这对任何环境都是重大挑战，尤其在多租户环境中实施更为困难。

• 缺陷逃逸率 测试在您SaaS环境的整体敏捷性中发挥着重要作用。多租户模型的“全有或全无”特性可能需要您在整体测试覆盖范围上投入更多资源。通过测量环境中的缺陷逃逸率，您的团队将能更清晰地了解测试架构在捕获和识别问题，并在问题进入生产环境前及时发现。无论是否已建立完善的测试体系，团队都应持续监测并评估缺陷逃逸率的趋势。该指标的异常波动可能揭示需要立即处理的更广泛问题。

这是我观察到团队在评估敏捷性时通常关注的一些常见领域。这份清单主要聚焦于整体运营体验中的摩擦、稳定性和可靠性。显然，在SaaS环境中实现敏捷性高度依赖于对工具和机制的信任，这使团队能够在定期发布新版本时感到安心。这对一些团队而言可能是一个重大转变，需要愿意面对并在环境落地过程中解决一些自然出现的挑战。没有一蹴而就的解决方案能在第一天就让一切完美无缺。相反，必须致力于快速演进文化和工具。

使用指标

对于多租户环境，运维团队必须了解租户如何消耗其环境中的资源。通过监控这些消耗数据，团队可以分析与特定租户和层级相关的消耗模式，从而评估系统对不同租户配置、工作负载和使用场景的响应能力。这些指标对于分析扩展策略、评估基础设施消耗效率至关重要，同时也可能影响您的分层和限流模型。从许多方面来看，这些数据为您提供了架构和部署选择如何满足租户资源消耗需求的视角。

消耗指标适用于所有SaaS部署模型。然而，对于共享资源而言，这些指标具有额外的重要性。当租户资源处于孤岛状态时，您可以更轻松地将消耗映射到特定资源。而在共享资源环境中，由于多个租户共享同一资源，难以将消耗的百分比准确归因于单个租户。通常没有现成的工具能够提供更细粒度、租户范围的视图，以显示某个租户在特定时间点消耗了多少资源。

相反，这是一个需要您引入自有构造来捕获并归因于租户的消耗的领域。图12-3展示了与分析共享资源消耗相关的挑战的概念视图。在该图的中间部分，我展示了一个可能属于多租户环境的基础设施示例。我已将容器计算资源池化，这些资源运行着应用程序的微服务。这些微服务与一个池化的关系型数据库进行交互。

图12-3

现在，我们可以从两个角度查看资源消耗。左侧是传统资源级别的基础设施消耗视图。在此视图中，环境可以告诉您在给定时间窗口内消耗了多少资源。这使我能够访问总消耗量，但未将任何消耗与特定租户关联。右侧是租户级别的消耗视图。

在此视图中，对于给定的资源，我可以了解每个租户消耗了该资源的百分比。这包括分解关系型数据库的计算和存储消耗。捕获此类数据的方法多种多样。您的具体方法将根据解决方案的性质而有所不同。通常，最简单的方法是先考虑架构的各个层次，并确定在哪些位置引入能够捕获并发布消费指标数据的监控工具。图12-4展示了这种分层模型的示例。

图12-4

在图12-4的左侧，我展示了一个示例SaaS应用程序架构，其中一个Web应用程序通过API网关调用应用程序的微服务。这些微服务随后调用各种AWS服务。右侧是控制平面中的指标和分析服务，负责摄取和聚合消费指标数据。在这些基础架构已就位的情况下，我们可以开始探讨如何在架构的不同层级捕获消费指标。首先可以关注的层级是微服务中的API入口点。

在此处，您可以看到API事件被发布为消费指标。这无疑是捕获此类数据最简单轻量级的实现方式。然而，API请求可能无法提供足够的细节或洞察力，以准确分解租户的消费情况。例如，请求数量可能有用。然而，租户工作负载的某些方面可能需要更少的请求但消耗更多资源。

下一层是微服务层。在此层，您可以通过单个微服务的角度查看消耗情况，并根据特定微服务处理的负载和配置发布消耗数据。这使您能够以更具上下文和精确的方式呈现消耗指标。现在，您可以根据微服务的工作负载和配置，引入不同的模式来捕获消耗数据。在最后一层，我们深入到基础设施服务层面，对特定基础设施服务的消耗进行剖析。

例如，如果我的微服务与数据库、队列或其他基础设施资源交互，我可以在这一层捕获并发布租户的消耗数据。同样，这旨在获取更细粒度的数据，以便将租户消耗归因于特定的基础设施服务。在此处，我们同样可以根据工作负载的性质和所消耗的基础设施资源类型，决定最合适的消耗归因方式。这些层级并非相互独立。它们突出了架构中不同区域，这些区域可能适合捕获不同类型的消耗指标。制定最适合您环境实际情况的策略是您的职责。

需要注意的是，您可能选择将消耗指标的捕获范围限制在系统中某些高价值区域作为起点，随后在逐步深入理解需求后再添加更多细节。总体而言，这可能感觉有些繁重。然而，拥有这些数据对于构建和演进您的SaaS环境的足迹至关重要。它具有深远的价值和影响，能够塑造运营效率、成本效率、扩展性和分层考虑。

每租户成本指标

在分析消耗时，我们还需考虑租户的消耗与成本之间的关联。目标是为每个租户和层级分配成本，并利用这些数据更好地理解租户的基础设施成本如何映射到架构的定价和分层策略，从而更清晰地掌握SaaS环境的实际利润率。这些数据即我所指的“每租户成本指标”。

我们将基于之前讨论的消耗指标数据，将每个租户的消耗数据与对应的消耗相关基础设施成本关联，从而得出每租户成本分配，帮助您了解租户消耗如何影响SaaS环境的成本结构。按租户成本可以为多个领域带来价值。让我们看一个场景，说明按租户成本如何影响SaaS业务（如图12-5所示）。

图12-5

在此示例中，您将看到一个图表，展示了电子商务SaaS环境中三个不同租户层级的成本概况。对于每个层级，我分解了三个与租户层级映射的指标：基础设施成本、租户收入和目录大小（销售的产品数量）。每个指标所占的比例由各层级堆叠柱状图的大小表示。现在，如果我们从基础层级租户开始，你会发现他们拥有非常庞大的产品目录，但为业务带来的收入非常少。

与此同时，标准层级租户的产品目录规模与收入大致呈50/50的分配比例。而高级层级租户虽然产品目录规模较小，但销售这些产品非常成功，并为业务带来了更大比例的收入。关键要点是，标准层和高级层租户显然为业务贡献了更多收入。然而，当我们查看租户基础设施的每租户成本数据时，发现基础层租户实际上为我们的环境基础设施成本贡献了最大份额。这给业务带来了实际问题。

本质上，我们最低层级的租户支付给我们的费用最少，却为业务带来了最大的基础设施成本。我们的分层和定价策略中几乎没有任何内容能确保基础层租户不会对业务利润率产生负面影响。此示例仅以一个简单案例说明租户成本数据如何对企业战略产生重大影响。正是这些数据帮助团队明确分层策略与定价政策如何与整体基础设施成本相匹配。

更广泛而言，团队需要访问此类数据，以便在引入新功能和能力时持续分析成本变化环境中引入新功能和能力时，持续监控成本。例如，产品所有者应关注每个潜在新功能的预期每租户成本影响，并评估其在分层策略中的定位。要计算每租户成本数据，您需要为系统指标和分析服务添加额外功能。

在获取消耗数据（如前所述）后，您还需要访问基础设施计费信息。这些数据的来源将取决于环境的具体特性。然而，即使您在本地部署，也应能够汇总一些可用于租户成本计算的成本估算值。图12-6展示了这一流程的关键组成部分。

图12-6

为了更具体地说明，我展示了一个基于AWS的SaaS环境示例。左侧显示了环境中不同AWS基础设施资源的原始租户消耗指标。它展示了如何将消耗分配给这两个租户跨这些服务。如前所述，这些数据本身具有运营价值，无论是否与成本相关联。要计算每租户成本，我们需要摄取计费信息（步骤1）。

对于AWS，这可以通过访问原始计费信息实现，或通过第三方成本工具完成。获取汇总的成本数据后，即可使用消耗数据将这些成本分配给各租户，从而得出每租户的净成本（步骤2）。在此步骤中，您有许多选择。您可以按服务类型分解成本，然后计算所有服务的平均值，或采用两者的混合方法。

需要特别注意的是，每租户成本指标旨在提供成本的近似估算。这并非会计功能，也不是为客户生成账单的工具——而是为了从运营角度洞察租户成本，从而为环境的架构、定价和分层策略提供决策依据。该数据必然存在一定误差范围，但仍对业务决策具有参考价值。

对于许多企业而言，每租户成本策略可直接受基础设施整体成本结构的影响。例如，若计算资源占账单的80%，则投入大量资源捕获计算部分的每租户成本细节便具有合理性。然而，若对象存储和消息传递仅占账单的2%，您可能选择不投入资源进行这些基础设施组件的详细成本分析。

业务健康指标

在SaaS领域，最常讨论的指标更多地聚焦于我大致归类为“业务健康状况”的领域。这些指标主要关注收入、营销以及宏观客户信息，能够评估影响整体业务健康状况的趋势。由于这些数据通常与盈利能力和持续增长具有最直接的关联性，因此值得高度重视。与此同时，它们与我们在此讨论的技术策略之间关联性较弱。

然而，我认为有必要强调其中一些关键数据点，以完善我们对指标的整体视角。这些指标中许多与B2CSaaS领域有更强的对应关系，该领域存在巨额营销支出及大量租户进出环境的活跃度。即便在B2B场景中，团队也会关注这些指标。以下是对几个我认为值得在此提及的关键指标的简要回顾：

• 每月经常性收入（MRR） 大多数SaaS企业将MRR视为衡量财务健康状况的关键指标。它最直观地反映了组织收入的增长趋势。

• 流失率 在租户持续加入并可能定期离开的环境中，您需要跟踪整体流失率，以持续评估租户在环境中的流失速度。

• 客户获取成本（CAC） 这是经典的商业指标，用于评估获取新客户的成本。在您大量投入营销资源推广SaaS产品的情况下，您需要了解获取每位客户的平均成本。

• 客户终身价值（CLTV） 该指标用于衡量客户在使用您系统期间平均能为您带来的收入总额。

• CLTV/CAC比率 此指标用于评估获取客户的成本与客户为企业带来的整体价值之间的平衡。例如，1:1的比率表明，您为获取一位客户所花费的成本等于从该客户获得的收入。显然，这不是目标。您的任务是确定适合您业务的比率。有人认为是3:1，但关于这一目标值的讨论确实存在。

这组数据的有趣之处在于，其中大部分信息并不直接来源于您的应用程序、架构或租户的运行时活动分析。相反，这些数据可能来自会计系统、客户关系管理（CRM）工具等。您选择如何汇总并展示这些数据，将取决于信息来源的具体方式。有一些系统专门针对这一领域，而在某些情况下，您可能需要构建自己的解决方案。

复合指标

我们之前讨论过的许多指标代表了用于描述SaaS环境的基础性、基准数据。虽然这些指标具有一定价值，但您很可能还需要开发并引入自己的指标，以映射到您解决方案或领域的具体需求。这些指标可能完全独立存在，也可能作为其他指标的组合而创建。例如，您可能有一个公式，该公式将租户活动指标与资源消耗指标结合，计算出一个具有特定意义或价值的新衍生指标。

关键要点是，指标并不总是与租户活动或基础设施消耗直接相关。您引入的最佳指标可能来自于您创建的用于剖析工作负载、逻辑业务事件或其他更高层次环境活动的机制。

基线指标

我们之前讨论的指标故意聚焦于对SaaS运营体验具有特定意义和价值的领域。然而，还有一组更通用的指标也属于这一体验范畴。您的基础设施会自然产生反映架构各组件运行状况的基本指标。例如，环境的计算资源会自然产生关于CPU活动、内存消耗等数据。

这些数据仍应被视为本指标故事的范围之内。您仍需采集这些数据并将其与其他指标数据并列，用于关联租户模式与这些其他指标（在合理的情况下）。这些基线指标的挑战在于，它们无法始终与特定租户建立关联。然而，这些数据在更广泛的指标故事中仍扮演着明确的角色。

指标采集与聚合

引入我所概述的指标需要您触及SaaS环境中的两个不同领域。首先，您需要在应用程序服务中引入指标采集工具，以将指标数据发布到控制平面。指标采集的方式和位置将根据您的技术栈特性及指标数据的捕获位置而有所不同。我们在第7章中对指标采集过程的细节进行了更深入的探讨。指标故事的另一半是指标数据的采集与聚合。

在此阶段，您需要确定用于处理和存储这些指标数据的工具与技术。如您所想，用于构建采集与聚合体系的工具列表相当庞大。数据仓库、搜索技术、对象存储、分析工具——选择范围极为广泛。确定哪种工具组合最适合目标体验的特征，可能需要考虑不同角色（如开发人员、分析师、业务决策者）对数据的分析需求。图12-7展示了两种可能的指标采集与聚合实现方式。

图12-7

在该图的左侧，我展示了各种指标数据的来源。在左下角是您需要在SaaS应用程序中进行监控的指标数据的不同类别。我还标注了“系统”事件，以包含由基础设施服务生成的其他内置事件。这是捕获并发布常见基线指标概念（如CPU、内存等）的位置，这些指标将与其他指标一同发布。

这些数据将发布到控制平面的指标和分析服务中，该服务包含用于摄取和聚合这些数据的工具和服务（如图中间所示）。在此，我展示了两种可用于实现此服务的工具链。顶部展示了Amazon Kinesis Firehose作为数据摄取机制。该服务可大规模摄取数据并将其移动到Amazon Redshift，这是一个适合此用例的列式数据库。随后，可使用Amazon QuickSight的分析仪表盘构建指标的运营视图（最右侧）。

在底部，我展示了如何使用Logstash摄取数据并将其发布到Elasticsearch，这是一个可用于分析指标数据的搜索引擎。这套工具与Kibana结合使用，用于构建不同的仪表盘，以便您分析数据（最右侧）。需要特别注意的是，这里聚合的数据可以在组织内的多个场景和角色中被使用。

产品所有者、架构师、运维团队和领导层都可能对创建自己的数据视图感兴趣，以回答与其角色最相关的问题。关键在于，不应将这些指标数据视为仅由技术团队专有。作为该模型的一部分，您还需决定数据的保留时长。数据的生命周期将由业务的具体需求决定。

构建租户感知型运维控制台

我已经详细讨论过构建一个丰富的SaaS运营模型所需的要素。更具体地说，我详细探讨了用于持续评估多租户环境运营状态的指标。然而，我尚未真正探讨如何将这些概念付诸实践。现在，我希望探讨如何将这些指标和数据呈现出来，构建工具集，使团队能够打造一个管理体验，以满足多租户解决方案的独特需求。

当我与团队讨论构建SaaS运营控制台时，许多人认为他们已经拥有能够填补这一空白工具。市面上确实存在大量现成的工具，允许运维团队查看日志并获取系统核心指标的洞察。虽然这些工具在SaaS环境中确实能提供价值，但它们通常不包含租户上下文或分层概念作为解决方案的一部分。这通常是团队需要定制现有工具、构建自有控制台，或结合这些选项来创建真正支持租户意识的运维体验的地方。

为了进一步澄清这一点，让我们考虑一下负责主动管理SaaS环境健康状况的运维团队的日常工作。是的，该团队需要对系统整体状态有一个全局视图，以便识别任何潜在的全球健康或活动问题。而当考虑如何应对更具租户或分层特性的挑战时，情况就变得更有趣了。假设系统健康状况的整体视图显示为“绿色”。表面上，所有关键健康指标均表明系统未出现需要关注的性能、扩展性或故障问题。

与此同时，您接到通知称某个租户报告了性能问题。假设该租户使用的是与其他租户共享的池化基础设施，且该基础设施对其他租户运行良好。我们应使用何种工具或机制来确定导致该特定租户出现问题的根源？为了有效支持此类及其他租户感知型操作场景，您需要工具和机制，以便通过租户和层级的视角与我们的运营数据进行交互。在控制台中，您可能需要多种工具体验来实现这些租户上下文的运营视图。图12-8提供了一个概念示例，展示了如何将租户感知功能集成到运营工具中。

图12-8

此示例以微服务为中心展示了您的运维体验，通过右侧的热力图直观展示单个服务的健康状态。这些方块会根据健康状况改变颜色，颜色从绿色到黄色再到红色，反映服务当前的健康状态。左侧是一组高度简化的切换按钮，用于选择要显示的服务健康范围。在左上角，我已选择“最活跃服务”选项，以聚焦可能处于高负载状态的服务。其下方则提供了多种选项，用于进一步细化包含的租户范围。

我可以选择所有租户、特定层级或单个租户来更改评估数据的范围。在此示例中，我已将租户1设为过滤条件，视图正在显示该特定租户的状态。从这里，我可以识别该租户下所有处于红色状态的服务，并深入查看每个服务以获取更多上下文信息，了解该租户可能遇到问题的具体原因。这是一个高度简化的示例，但旨在说明在运营体验中嵌入租户和层级意识的重要性。如果无法以租户上下文查看运营数据，就很难快速定位任何租户特定问题。

在多租户运营环境中，这正是需要工具来及时检测并解决这些问题、避免其对多个租户产生连锁影响的关键场景。在设计（或配置）租户感知控制台体验时，您将发现许多可以将租户上下文作为核心视图呈现的场景。图12-9展示了租户信息在多租户运营仪表盘中可能呈现的几种方式。此视图包含三个多租户运营数据示例，这些示例可在SaaS环境中为用户带来价值。

在左上角，您将看到一个租户列表，这些租户代表了系统中活动最频繁的租户。这些租户产生了最多的系统负载和活动，因此也可能更容易遇到技术问题。基于此，我将此视图作为控制台的顶级构造添加，以便快速识别可能需要立即关注的租户。每个租户旁显示状态，指示其是否存在性能下降或问题。更高级的控制台版本甚至允许我点击其中一个租户，立即跳转到一个视图，快速查看该租户的当前活动和状态。

图12-9

在右上角，我还有一个视图，显示租户如何使用各个基础设施服务。这个视图的目的是让我能够轻松查看租户的负载如何分布在环境中关键的基础设施服务上。这将使我能够快速识别出某个租户可能正在以不合理比例消耗某项服务的场景。这可能表明该基础设施在扩展过程中存在潜在的短期或长期问题，并提示我们需要深入分析触发服务过度消耗的租户工作负载和趋势。

最后，底部有一个图表，展示了租户在解决方案中部分高关注度微服务中的活动情况。水平条形图显示了特定租户对微服务的消耗水平。这有助于评估租户如何消耗微服务，并识别微服务未能有效扩展以满足租户或层级服务水平协议（SLAs）的场景。

在本次讨论中，您会注意到我将层级纳入了运维叙述中。层级不仅仅是计费概念，它具有运维影响，且我们的环境通常配置为向不同层级提供差异化体验。这意味着，在运维体验的某些环节，我们可能需要通过单个层级的视角来观察系统活动和健康状态。例如，我可能希望查看高级层的微服务健康状况和活动，以确认架构是否有效防止这些租户受到“噪音邻居”条件的影响。

我们在此讨论的示例仅是可能性的冰山一角。目标是强调创建支持多租户环境独特需求的租户感知运营工具的重要性。在SaaS环境中，通过筛选海量数据来拼凑运营洞察已不再可行。您需要一个将租户和层级上下文置于核心的仪表盘和分析工具，提供经过精心设计的视图，使您能够快速评估和浏览具有租户意识的运营数据。您在此处的投入越多，就越有可能在问题浮出水面之前主动识别挑战。

结合经验与技术指标

在创建SaaS运营控制台时，您需要决定哪些数据应纳入此体验。在多租户环境中，可用于丰富运营体验的数据范围相当广泛。关键问题是：是否应将更多通用技术数据整合到控制台中，以展示与租户活动不一定直接相关的数据？CPU、内存、延迟——这些都是系统性能和资源消耗的通用指标，可以作为运营控制台的候选数据。

此外，您可能还在衡量一些业务指标（如敏捷性、价值实现时间等）。您是将所有这些指标都纳入控制台，还是将其保留在其他工具中？我认为有价值的是，有选择性地将部分指标整合到对环境的更广泛运营视图中。将这些数据纳入控制台可能使您能够自然地关联业务与技术事件。例如，新功能可能引入影响用户注册时间的性能问题。将这些更广泛的SaaS指标与传统健康和活动指标并列展示，可帮助您发现否则可能被忽视的模式。

这也有助于强化运营团队不仅负责监控健康状态的观念。展示并访问这些指标，强调了运营团队需扩展健康视图，纳入对更广泛SaaS运营考量进行分析的必要性。

租户感知日志

我之前尚未提及日志。日志是整体运营工具模型中不可或缺的一部分，而这又是一个需要能够轻松访问包含租户和层级上下文日志的领域。该问题有两个维度。首先，您的微服务需要确保生成的日志包含系统所需的所有租户上下文。我们在第7章中探讨了如何将这些日志引入多租户微服务。

如果您的日志包含租户上下文，那么这个挑战的另一半就是确定如何支持对这些日志的访问。一些团队会直接在控制台中构建日志视图，使用户能够根据租户或层级特定的条件轻松过滤和查看日志活动。其他团队则会依赖现有的、专为日志分析设计的工具。这两种方法都是可行的。关键在于确保您的工具能够轻松应用租户和层级上下文。

制定主动策略

在多租户环境中，为了尽可能避免服务中断，团队通常会更加重视实施主动运维策略，通过自动化和策略来检测并解决问题。这可能表现为在需要人工干预的条件下触发警报，以吸引更多关注；也可能表现为主动检测性能下降，并主动调整环境的扩展以限制对租户的影响。这些策略的引入位置和方式可能因环境而异。技术栈的特性、部署模型以及解决方案的性质都可能影响您构建主动策略的方法。

基于角色的仪表盘

关于指标和运维控制台的讨论可能让人觉得运维团队和该控制台是获取指标的唯一途径。实际上，不同业务角色可能需要查看这些数据的多种视图。我更倾向于让团队将所有指标数据视为存储在共享数据仓库中，这些数据可在不同场景下被调用（如图12-10所示）。

图12-10

你可以看到我建议的指标数据范围和角色模型。在理想情况下，您会看到企业中不同角色基于系统指标数据，开发各自的仪表盘，通过独特的视角分析趋势和模式，为其特定领域提供战略价值和洞察。这在促进SaaS组织中各角色共享运营责任方面发挥重要作用。随着更多团队采用这种模式，您将很可能看到对新增指标和洞察的需求日益增长。

多租户部署自动化

自动化配置和部署多租户环境是整体SaaS运营的关键组成部分。正是这种自动化在确保环境能够快速接入新租户并发布支持多租户模型特定需求的新功能方面发挥着至关重要的作用。您实施此自动化策略的方式将不可避免地对SaaS业务的敏捷性、创新能力和可用性产生重大影响。

在多租户环境中，基础设施自动化的性质、范围和作用往往要求团队调整思维方式，以支持SaaS配置和部署模型的独特结合。多租户可能需要您以不同的方式分解自动化，将自动化的一部分分离出来，以适应构成整体SaaSDevOps体验的流程和模式。为了更好地理解其中的细节，让我们考虑在多租户环境中可能需要的几个自动化组件（如图12-11所示）。

图12-11

我展示了一个示例，说明您的运维工具需要支持租户特定的资源分配和部署要求。基础设施资源分配的生命周期基本包含三个独立的阶段。首先是环境的初始配置阶段，在此阶段您需要分配基础架构资源以及共享的租户资源（步骤1）。如果采用完全共享的资源池模型，所有租户的基础架构资源均可在该阶段完成分配。环境设置完成后，我们的配置必须考虑在租户入驻过程中应用的自动化和配置（步骤2）。

如其他示例所示，入驻作为运行时过程触发，根据租户参数预配置和配置资源。在此过程中，系统执行所需的自动化操作以预配置和配置每个租户的基础设施。这里还有DevOps故事的最后一部分。我们还需考虑租户级基础设施的存在如何影响应用程序更新的部署（步骤3）。这更多是关于拥有一个能够将更新部署映射到每个租户资源的流程，而非单纯的资源配置。

您的部署流程可能需要多次部署服务以覆盖所有不同池化和孤立的租户基础设施。我们在无服务器SaaS架构中已经看到了一些这种趋势。然而，我希望特别指出这一点，因为它构成了多租户运营架构中的关键组成部分。在运行时动态添加针对每个租户的独立基础设施，对许多团队来说是一个全新的挑战。考虑到我们的高可用性和容错性目标，这意味着我们的基础设施自动化代码必须达到非常高的质量和可靠性标准，以确保在进行新用户接入和更新时，不会以任何方式影响整体环境的健康和性能。

部署范围划分

在SaaS环境中，团队常常寻求创意方式来控制功能和能力向租户的发布方式。此时，功能开关（feature flags）和金丝雀发布（canary releases）等概念便派上用场。功能开关允许我们在发布中启用或禁用单个功能，而金丝雀发布则允许我们将服务版本发布到部分租户。在SaaS环境中，这些概念的价值不言而喻。例如，团队可以通过功能开关为特定级别的租户选择性启用功能。

这使您能够避免为租户进行一次性部署，并通过单一管理界面持续管理和运营解决方案。功能开关可能成为某些组织面临的矛盾点。部分团队可能将其视为为单个租户创建一次性功能的手段。这可能是一个危险的倾向。若从我们更广泛的多租户SaaS目标出发，我们正有意避免任何基于租户的定制化概念。

若最终出现100个不同租户，每个租户都拥有独立的功能开关，这将削弱组织在敏捷性和效率方面的目标。你需要避免将功能开关视为绕过SaaS原则的工具，而是努力构建一个可供所有用户使用的系统，无需为每个租户的定制需求提供单独支持。

无论你最终如何选择，都必须确保功能开关以全局机制的形式实现，并可供所有租户使用。这将使你能够继续为所有租户提供单一部署。在理想情况下，功能开关应在层级（tier）级别分配，以区分不同的用户体验，而针对特定租户的临时开关应作为例外情况而非常规做法。

定向发布

默认情况下，当您在SaaS环境中发布新版本时，您实际上是在一次性将更新推送给所有租户。对于某些组织而言，这可能令人担忧。如果您对某些功能进行了修改或在系统中添加了新的流程，如果租户对您引入的更改不满意，可能会导致整个租户社区出现问题。如果发布存在问题，您可能会同时将所有租户暴露在该问题中。

这两种情况都可能给您的SaaS组织运营团队带来挑战，并可能损害租户社区对您的信任和忠诚度。这就是团队寻求通过分阶段发布来推出更新的地方，即先将更新发布给部分租户，以评估新发布的影响和反馈。在DevOps世界中，这一目标通过金丝雀发布实现：您识别出一组特定租户，向其部署更新以收集反馈或评估系统影响，而不会影响所有租户。

这种技术在DevOps领域已存在多年，对于SaaS环境尤为强大，因为部署的范围和潜在影响可能对业务产生深远影响。当考虑孤岛式和池化环境时，金丝雀发布变得更加有趣。在租户运行在共享基础设施的池化环境中进行金丝雀发布意味着什么？这是否意味着需要为金丝雀发布单独部署一个并行池化环境？或者，如果这仅涉及代码和功能，是否可以让池中部分租户运行新代码分支，而其他租户继续运行当前版本？答案，正如你可能猜到的，是这取决于具体情况。

任何给定发布的需求可能对金丝雀发布提出不同要求，如果在此处的努力过高或过于复杂，可能会削弱金丝雀发布的价值。这也是你可能需要引入功能开关的地方，通过在金丝雀发布中为租户启用特定功能。这些组件的运作方式相当直观，符合一些团队采用的典型目标发布策略。图12-12展示了在多租户环境中目标部署可能呈现的概念视图。

图12-12

在该图的右侧，您将看到一个采用分层模型的多租户环境，其中租户以混合模式部署，部分采用孤岛模式，部分采用池化模式。左侧是部署自动化工具的占位符。这里可以放置各种不同的DevOps工具和机制，用于向租户部署更新。该体验中包含一个配置描述，用于定义部署策略的结构，并详细说明发布如何分阶段推送到租户。

在此示例中，我创建了一些租户分组（在右侧）。这些分组代表部署配置中引用的不同租户集合。这些分组可能是根据特定的运营和发布目标选择的。例如，我可以将组1视为我们的“友好”租户，它们是首批接收更新的理想候选对象。或者，我们可能先向组2和组3发布，以避免影响共享资源的租户，因为如果发现问题，这些租户可能面临更大的业务影响。

核心思想是根据业务的特征和需求，制定发布分组策略。您可以想象，这种模型如何映射到我之前提到的各种目标发布策略。它与选择性地将更新部署到部分租户的理念非常契合。例如，这些分组可用于实施金丝雀发布或分阶段发布策略，逐步推进变更的发布，并限制潜在运营影响的范围。关键要点是，DevOps为我们提供了多种工具和策略，可以很好地适应您的SaaS部署模型需求。具体如何适用或是否适用，将取决于您的租户规模和特征，以及SaaS环境的部署模型。

分层策略——这些只是租户体验的示例，应引起产品所有者、战略领导者等关注。在这些核心原则确立后，我将关注点转向了SaaS的指标。这一目标是强调在多租户环境中，数据驱动决策的重要性。通常，当您集体运营和管理这些租户时，需要访问能够提供丰富洞察的数据，以了解租户如何使用您服务的各个组件。

正是这些信息能够提供全面的数据支持，既满足运维团队的即时需求，又能为业务整体战略布局提供必要的洞察。接下来，我开始考虑这些概念在实际的SaaS环境中如何落地。这促使我开始研究如何构建一个支持多租户解决方案独特需求的租户感知型运营控制台。在此过程中，我审查了多租户架构如何直接影响运营团队需要识别、分析和排查租户或层级问题的功能与能力。

在此过程中，我还研究了一些自定义的多租户运营视图示例，这些示例展示了如何揭示租户趋势和模式，从而更直接地了解租户如何对系统造成负载。整体重点在于突出多租户运营所面临的独特挑战，这些挑战需要采取更针对性、更租户感知的方法来打造SaaS环境所需的运营体验。最后，我简要回顾了SaaS运营中的基础设施自动化要素。

这主要涉及审查验证、配置和部署在构建支持SaaS环境特定需求的运营模型中所发挥的关键作用。SaaS环境的独特部署要求和入驻自动化在构建能够支持业务及其租户敏捷性、效率和创新需求的运营基础中发挥着重要作用。在与SaaS架构师和开发人员合作时，我最关心的问题是他们会忽视对这些运营架构的投资。我更倾向于看到团队并行推进运营架构与应用架构设计，将其视为一个综合交付成果，共同赋能业务增长与发展。

通常，推迟对运营工具和仪表盘的投资会对SaaS业务的成功产生重大影响。这会使组织失去对关键技术和业务战略塑造至关重要的工具。作为一条经验法则，SaaS是一个以指标为驱动的领域，这要求团队和领导层将指标作为优先事项——在某些情况下甚至优先于功能开发。您正在构建一项服务，因此需要丰富的运营洞察力，才能判断是否真正实现了服务体验的承诺。

本节对SaaS运营的探讨将架构原则与运营思维和实践经验相结合。截至目前，我们所探讨的概念大多适用于处于SaaS交付模型采用任何阶段的客户。现在，我希望开始更具体地探讨企业将现有解决方案迁移至SaaS的实际含义。目标是帮助您更好地理解可用于将解决方案迁移至多租户模型的策略与模式。这将是下一章的重点，我将探讨迁移到SaaS相关的技术和业务考虑因素。这应为您提供一系列可纳入自身迁移策略制定的选项。