FinOps如何管理共享云成本

简介: 本页面介绍共享云成本管理,涵盖其重要性、分配方法及各方职责。通过公平、透明的成本分摊,提升财务责任与预算准确性,推动组织优化云支出。

Managing Shared Cloud Costs(共享云成本管理)

本页面包含以下内容:

  • 引言
  • 共享成本分配的好处
  • 谁会关注共享成本
  • 推荐方法
  • 成功指标
  • 致谢

引言

FinOps 的一项基本原则是:“每个人都要对自己的云使用负责”。云成本透明度对于理解和明确云成本责任至关重要。未分配的共享成本会威胁到这一点。如果不能合理拆分共享成本,工程师、产品经理及其他相关人员将无法全面了解其产品的实际总成本。

共享成本(适用于云计算场景)指的是由多个所有者、应用程序或产品共同使用或归属的费用。

共享成本分配的好处

几乎每个组织都会产生需要在多个团队间拆分和分配的云费用。随着组织对公有云资源的采用度不断提高,将共享成本分配给具体业务所有者以准确掌握成本归属的难度也日益增加。一项共享资源可能仅在某个业务部门内部共享,而非跨其他分配层级共享。

尽管如此,共享云资源仍能带来更高的可扩展性和灵活性 —— 资源可根据用户需求动态分配和配置,且用户只需为实际使用的资源付费。通过以企业整体规模采购云基础设施和基于承诺的折扣(commitment based discounts),组织可借助采购实践、私有费率卡(private rate cards)及其他折扣方式降低单位成本。然而,要实现价值最大化并确保优化效果,必须将这些成本分配回产生资源消耗的业务领域。

因此,组织必须有效标记共享成本,避免大量成本处于未标记或未分配状态。如果共享成本分配不当且缺乏相应的成本管理责任机制,共享云成本可能会失控增长。最终,组织将从共享云基础设施中获得成本节约效益,因此应鼓励对共享云资源进行成本分配,以优化云支出。

准确分配共享成本能为组织带来诸多优势。通过将成本分配尽可能贴近实际支出,许多 FinOps 能力将得到强化和完善。这种方式可带来以下显著益处:

  • 公平性(Fairness) :合理标记共享成本可确保费用分配更加公平。若成本分配不准确,部分团队或业务部门可能需要承担超出或低于其实际使用量的成本。这一点在基础设施团队需承担其他团队 / 业务部门产生的成本时,或在核算单个客户 / 产品成本时尤为关键。
  • 责任归属(Ownership) :缺乏共享成本责任机制会降低团队降低成本和监控支出的积极性。通过准确分配共享成本,组织可以培养符合 FinOps 原则的责任文化。
  • 预测与预算编制(Forecasting and Budgeting) :未分配的共享成本会给不同团队和业务部门的预测、预算编制及财务规划带来困难。合理分配共享成本能确保使用情况在财务计划中得到充分反映,从而支持更明智的决策制定。此外,由于支出信息更具可追溯性,还能预防或减少云成本异常的影响。

共享成本分配正成为许多组织日益复杂且关注的问题。尽管过程复杂,但将共享成本在整个业务中进行分配的一个优势是,能更深入地了解底层单位成本(unit cost),推动决策更贴近产品层面。通过将共享成本分配回产生支出的业务领域,可实现成本透明度。

谁会关注共享成本分配?

FinOps 从业者(FinOps practitioners)、财务人员(finance)、产品 / 业务人员(product/business)、工程与运营团队(engineering & operations)及高管(executives)均与共享成本分配息息相关。以下角色矩阵示例列出了与共享云成本相关的常见职责,以及各角色在其中的负责(Responsible)、问责(Accountable)、咨询(Consulted)和知情(Informed)关系:

  • R(Responsible):负责执行任务以完成工作的角色
  • A(Accountable):对工作完成情况承担最终责任的角色
  • C(Consulted):参与决策过程的角色
  • I(Informed):需被告知相关详情的角色
事项 FinOps 从业者 财务人员 业务 / 产品负责人 工程与运营团队 高管
制定并完善共享成本分配的适当方法 R C C C A
生成共享成本分配的告知报表(showback) R I I I A
生成并实施共享成本分配的收费报表(chargeback) C R I I A
将共享成本分配结果纳入预测和预算更新 C R/A C I I
了解产品路线图对共享成本的影响 C R A C I
了解共享服务对产品 / 服务的影响 C I A R -
审核业务及汇总产品的损益表(P&L) I C R I A
协调 / 透明度:支持共享成本所有者的成本管理目标,并向他人说明共享成本分配的方式及原因 R/A I I I -
就共享产品和服务做出决策(如重复应用程序等) C C C R/A C*

*:是否需要高管参与取决于成本规模

推荐方法

共享成本分配流程的实施可拆分为多个逻辑步骤,便于理解。这些步骤可针对全部共享成本统一执行,也可根据不同成本的复杂性或一致性单独实施。尽管以步骤形式呈现,但由于最后一步强调了流程回顾与更新的重要性,因此也可将其视为一个循环过程 —— 持续优化分配流程是确保其有效性的关键。

1. 识别共享成本

共享成本的定义因公司而异,也取决于公司的成熟度和规模。不过,有一类标准成本通常会出现在每家公司的损益表中,公司需自行决定是否将其归为共享成本。不同公司的共享成本分配方式可能不同:部分共享成本适用于整个公司,而另一些则可能分配给使用该资源的团队、应用程序或产品。

跟踪是掌握共享成本分配进度的关键。除了跟踪成本分配情况,还应制定关键绩效指标(KPIs),以衡量共享成本的准确分配比例。例如,可通过 “共享成本与专用成本的标记覆盖率百分比” 这一 KPI 来评估本步骤的执行效果。

云服务提供商(CSP)的支持费用(Support charges)是许多组织都会产生的典型共享成本。支持费用通常在主账户层面产生,要么由集中式 IT / 云团队的预算支付,要么通过收费机制(chargeback mechanisms)按照成本分配策略分配给所有团队。

随着共享平台的兴起,现代架构也带来了更多共享成本。这些平台允许多个团队使用相同的核心资源,例如基于共享 S3 存储桶构建的数据湖(data lakes),或运行在共享集群上的 Kubernetes 系统。乍看之下,这些平台的收费(chargeback)和告知(showback)似乎难以实现,但通过合理标记和利用运营数据,可实现共享成本的公平拆分。

常见共享成本类型

共享成本示例 描述 详情及示例
第三方 SAAS 及市场服务(Third Party SAAS and Marketplace Services) 这类服务通常被归为共享成本,无论其通过云服务提供商(CSP)市场支付还是单独开具发票。 云提供商提供的监控与日志工具(Monitoring and Logging tools)、数据仓库(Data Warehouses)、安全工具(Security Tools)等。
基于托管服务的云基础设施(Cloud Infrastructure via Managed Services) 指云环境中由多个业务部门或应用程序共同使用的资源和服务,且属于托管服务(如 AWS RDS、DynamoDB、Azure Cosmos DB、Azure Analysis Services、Google Cloud SQL 等)。这类资源可能支持标记,也可能不支持。支持标记的示例:托管 Kubernetes 可在集群层面标记,但可能包含代表不同应用程序的命名空间或服务;托管数据库可能被多个业务部门使用;存储(Storage)、消息队列(Message Queues)或数据湖(Data Lakes)也属于此类。不支持标记的示例:云服务提供商(CSP)支持服务、CSP 安全服务、CSP 监控与日志服务、部分网络成本(network costs)。 -
自定义内置内部服务(Custom Built, Internal Services) 由组织内部的基础设施或平台团队构建、供其他团队使用的自定义服务。由于这类服务属于共享资源,其成本通常需要在受益部门间分配。 数据工程团队构建的数据湖(Data Lake),供多个业务部门用于数据分析、机器学习和商业智能任务;微服务(microservices),如用户管理或支付处理服务 —— 由内部团队开发一次后,可跨多个应用程序或项目使用。
基于承诺的折扣(Commitment Based Discounts) 与基于承诺的折扣相关的费用可能不会直接计入使用该折扣的账户或资源。部分组织可能希望根据使用情况重新分配这些费用,或将折扣在所有组织成员间平均分配(而非仅分配给享受折扣的对象)。 预留实例(Reserved Instances)、节省计划(Savings Plan)等;适用于 Windows 服务器的 Azure Hybrid Benefit。

2. 选择共享成本拆分策略

共享成本拆分主要有三种常见方法:

  • 平均拆分(Even split) :将总成本在目标对象间平均分配。
  • 固定比例拆分(Fixed Proportional) :基于成本、使用量或其他不常更新的指标所占比例进行分配。
  • 可变比例拆分(Variable Proportional) :基于成本、使用量或其他常用于支出拆分的指标所占比例进行分配,比例会动态调整。

固定比例和可变比例拆分方法需要借助某种指标来确定各团队的支出分配比例。尽管这两种方法相比平均拆分法需要更多工作量,但能更准确地反映共享资源的实际使用情况,且比例会随时间动态调整。

可用于确定比例拆分的指标示例包括:其他相关云资源的成本 / 消耗量、收入 / 销售额、支持工单数量、主机数量或虚拟 CPU 小时数(vCPU hours)等。

注:部分组织可能会选择结合使用多种方法或其变体。

以下以企业支持费用(Enterprise Support costs)为例进行说明:某月多个业务部门产生的云服务提供商(CSP)费用如下表所示,同时产生了 12,000 美元的企业支持费用。

业务部门 成本 占总费用比例(不含企业支持费用)
销售部(Sales) 50,000 美元 50%
产品部(Product) 30,000 美元 30%
工程部(Engineering) 20,000 美元 20%
企业支持费用 12,000 美元 -
总计 112,000 美元 100%

若不分配企业支持费用,各部门需支付的费用如下:

  • 销售部:50,000 美元
  • 产品部:30,000 美元
  • 工程部:20,000 美元

12,000 美元的企业支持费用尚未分配,需确定支付方式。

(1)平均拆分(Even Split)

在平均拆分策略下,12,000 美元的企业支持费用由所有业务部门平均承担。这种方法操作简便,在小型组织中较为常用,但在大型组织中可能被认为不公平或不合适。

业务部门 原始成本 共享成本分配比例 12,000 美元支持费用分摊 总成本
销售部 50,000 美元 33.3% 4,000 美元 54,000 美元
产品部 30,000 美元 33.3% 4,000 美元 34,000 美元
工程部 20,000 美元 33.3% 4,000 美元 24,000 美元
总计 100,000 美元 100.0% 12,000 美元 112,000 美元

平均拆分策略简化了共享成本分配流程,但会对不同业务部门的预算产生不同影响。在上述示例中,与比例拆分策略相比,工程部需多承担 13% 的共享成本:

  • 销售部:54,000 美元(50,000 美元直接成本 + 4,000 美元支持费用分摊)
  • 产品部:34,000 美元(30,000 美元直接成本 + 4,000 美元支持费用分摊)
  • 工程部:24,000 美元(20,000 美元直接成本 + 4,000 美元支持费用分摊)

企业支持费用已全部分配,无需额外确定支付方式。

(2)固定比例拆分(Fixed Proportion)

固定比例拆分策略基于固定百分比按月分配共享成本。通常,这些比例是通过分析历史支出(或收入)确定的公平分配方案。以下仍以 12,000 美元的企业支持费用为例,采用指定比例进行分配:

业务部门 原始成本 共享成本分配比例(系数) 12,000 美元支持费用分摊 总成本
销售部 50,000 美元 50% 6,000 美元 56,000 美元
产品部 30,000 美元 30% 3,600 美元 33,600 美元
工程部 20,000 美元 20% 2,400 美元 22,400 美元
总计 100,000 美元 100% 12,000 美元 112,000 美元

固定比例拆分策略相比平均拆分法更公平,且计算简便。该方法依赖历史数据分析确定分配系数,但组织需内部协商确定系数的更新频率。

各部门最终支付费用:

  • 销售部:56,000 美元(50,000 美元直接成本 + 6,000 美元支持费用分摊)
  • 产品部:33,600 美元(30,000 美元直接成本 + 3,600 美元支持费用分摊)
  • 工程部:22,400 美元(20,000 美元直接成本 + 2,400 美元支持费用分摊)

企业支持费用已全部分配,无需额外确定支付方式。

(3)可变比例拆分(Variable Proportional)

可变比例拆分法根据各业务部门的原始支出占比分配企业支持费用(12,000 美元),且比例会随每月云成本的变化而调整。成熟组织通常会按月根据各业务部门的直接费用比例分配共享成本。

业务部门 原始成本 共享成本分配比例(系数)—— 支持工单数量 12,000 美元支持费用分摊 总成本
销售部 50,000 美元 40 = 40% 4,800 美元 54,800 美元
产品部 30,000 美元 30 = 30% 3,600 美元 33,600 美元
工程部 20,000 美元 30 = 30% 3,600 美元 23,600 美元
总计 100,000 美元 100 = 100% 12,000 美元 112,000 美元

各部门最终支付费用:

  • 销售部:54,800 美元(50,000 美元直接成本 + 4,800 美元支持费用分摊)
  • 产品部:33,600 美元(30,000 美元直接成本 + 3,600 美元支持费用分摊)
  • 工程部:23,600 美元(20,000 美元直接成本 + 3,600 美元支持费用分摊)

企业支持费用已全部分配,无需额外确定支付方式。

确定共享成本分配方法后,FinOps 从业者需与所有业务预算所有者和相关方沟通,确保其理解变更内容及必要性。

3. 应对复杂共享成本分配:网络成本案例研究

前文通过固定比例和可变比例等策略演示了企业支持费用的分配,解决了共享成本分配的关键问题并提供了简单示例。但对于更成熟的组织,可能需要更复杂的分配方法。

为说明这一演进过程,以下将以网络成本(network costs)为例进行深入分析 —— 该示例虽非详尽无遗,但可直观展示共享成本分配策略如何随业务运营复杂度的提升而优化。

起步阶段(Crawl):基于总成本的比例分配

在 “起步阶段”,企业通常会根据易于衡量的指标(如各业务部门的总成本)分配网络成本。这种方法操作简便,但无法反映网络使用的具体模式。

业务部门 原始成本 共享成本分配比例(系数) 20,000 美元网络成本分摊 总成本
销售部 50,000 美元 50% 10,000 美元 60,000 美元
产品部 30,000 美元 30% 6,000 美元 36,000 美元
工程部 20,000 美元 20% 4,000 美元 24,000 美元
总计 100,000 美元 100% 20,000 美元 120,000 美元

发展阶段(Walk):基于数据量的比例分配

随着企业成熟度提升进入 “发展阶段”,可能会将数据量纳入网络成本分配考量,更贴近实际网络使用成本。

业务部门 原始成本 共享成本分配比例(系数)—— 数据传输量 20,000 美元网络成本分摊 总成本
销售部 50,000 美元 500GB = 25% 5,000 美元 55,000 美元
产品部 30,000 美元 800GB = 40% 8,000 美元 38,000 美元
工程部 20,000 美元 700GB = 35% 7,000 美元 27,000 美元
总计 100,000 美元 2TB = 100% 20,000 美元 120,000 美元

成熟阶段(Run):基于网络成本类型的比例分配

最终进入 “成熟阶段” 后,企业可能会利用先进的网络监控工具,根据具体网络成本类型(如跨区域 / 跨可用区数据传输、公网 IP 地址使用等)进行分配。这种方法能实现最准确的网络成本分摊。

网络成本分配的演进过程帮助组织确保各业务部门公平承担其网络使用成本。随着分配方法的日益复杂,其也更能反映各部门对网络的具体使用和受益情况。这种更公平、准确的成本分配方式有助于优化资源使用、鼓励成本节约行为,并提升整个组织的财务透明度。

4. 应用共享成本分配方法

根据上一步确定的策略,执行必要的收费(chargeback)或告知(showback)流程,完成共享成本拆分。

与财务和会计团队协作,制定共享成本拆分的时间节点、责任主体,以及将相关信息纳入预测和预算的流程。

不存在适用于所有组织的 “完美” 共享成本分配方法,但建议尽可能遵循 KISS 原则(Keep It Simple Stupid,即保持简洁)。公司需根据自身预算核算方法、组织目标和资源情况,选择最适合的方案。通常,成熟度较高的组织会采用可变比例拆分法。

仅将云资源标记为 “共享” 并不意味着已通过适当方法明确、准确地分配了这些成本。因此,建议制定 KPI 以跟踪所有共享资源的共享成本分配比例,从而掌握分配的完整性和成熟度。

注意事项:结合多种共享成本策略和拆分方法可能会导致流程迅速复杂化。例如,支持费用可能更适合采用比例分配法,而共享资源或开发 / 测试环境的成本则可能适合采用平均拆分或固定比例拆分法。

5. 共享成本报告

成功分配共享成本是重要一步,但向相关方展示分配金额、说明分配方法及背后的逻辑,能进一步发挥共享成本分配的价值。有效的共享成本报告应包含以下内容:

  • 成本趋势分析(总体趋势及按所有者、产品等维度的趋势),以显示成本增长或下降情况;
  • 共享成本实际值与预算值、预测值的对比;
  • 支出驱动因素识别(如产生支出的服务或团队)。

报告流程的关键在于,让影响成本的团队能够理解并利用报告数据,从而有效开展成本管理工作。报告必须准确、及时,并清晰展示共享成本的分配情况。

据 FinOps 基金会社区成员反馈,仅通过向相关方提供成本报告,就能发现当前企业会计政策中可能被忽视的费用。跟踪共享成本相对于专用成本的增长情况是一项有用的 KPI,但需先建立基准评估才能准确使用。

准确核算的一个挑战是 “何时停止划分共享成本”。将某项成本归为共享成本容易,但久而久之需要拆分的共享成本范围可能会变得过大。因此,应定期回顾共享成本,确保标记为 “共享” 的资源仍具有相关性且确有必要。由于没有任何业务部门直接承担这些成本,可能会导致资源长期闲置(因无人感受到成本影响)。

6. 维持分配方法的可持续性

完成上述步骤后,组织已成功制定并应用了共享成本分配方法,并开始进行数据报告 —— 这意味着大部分繁重工作已完成。但此时不应松懈,流程的可持续性是共享成本分配的关键。必须保持警惕,建立相应流程以维持成熟度,并及时发现可能退化的领域。在构建长期可持续的共享成本分配方法时,可考虑以下问题:

  • 若公司已采用标记标准进行成本分配,如何确保标记的准确性?
  • 如何处理因缺乏适当标记、异常情况等导致的未分配共享成本?
  • 当引入新的成本中心或业务部门时,回顾流程是什么?
  • 若采用固定比例分配法,比例的回顾频率是多少?
  • 数据建模方法是否具有可持续性?
  • 流程文档的完善程度如何?
  • 有多少人了解已实施的系统?
  • 是否存在足够的知识共享,避免关键知识集中在少数人手中?

成功指标

共享成本分配方法是一个迭代演进的过程。其目标是让团队、应用程序、服务或产品能够全面了解自身的实际运行成本。随着方法的成熟,人们对分配准确性的信心应不断增强,成本中心或团队也应具备更强的优化或影响这些共享成本的能力。

判断方法是否有效的最佳方式,是评估其与组织整体成本管理方法的契合度。共享成本分配方法是否有助于推动创新和理解?这是一个重要的考量因素。尽管共享成本分配本身是一种文化变革,但它应帮助所有人更好地决策支出及背后的原因。

我们制定了适用于共享成本管理 “起步(Crawl)、发展(Walk)、成熟(Run)” 三个阶段的里程碑,可为组织提供参考。该模型并非强制性要求 —— 许多公司可能先实施发展阶段的策略,再推进起步阶段的工作,反之亦然。成本管理具有复杂性,不同成本对公司基础设施的影响也各不相同。

以下表格具有迭代性:

步骤 起步阶段(Crawl) 发展阶段(Walk) 成熟阶段(Run)
重点与回顾 从企业协议(EA)、历史发票 / 账单中识别共享成本的一般类型 基于实际运行成本,聚焦高共享成本的关键详细领域 基于运行成本、承诺使用节省(committed use savings),进行全企业范围的共享成本循环回顾(采用告知制 showback)
选择共享成本分配方法 应用共享成本模型 —— 通常为平均拆分或固定比例拆分 固定比例拆分或可变比例拆分 基于可变比例、使用量 / 指标的拆分,或多种共享成本分配方法的组合
确定需要拆分的成本领域 企业支持费用、发票、订阅费用 按应用程序、项目或基础设施拆分共享资源支出,实现成本分配告知(showback) 利用指定方法(可变比例或使用量衡量)跟踪共享成本的工具或流程;目标可能包括实时趋势分析、预测和异常检测
共享成本报告 提供满足团队 / 相关方云成本管理基本需求的共享成本分配可见性报告 增加更及时、准确的细节,展示特定业务部门或其他所有者的共享成本分配情况 向财务部门提供准确跟踪数据,以便及时响应共享成本分配的变化;实现资源优化利用和效率提升
可持续性 记录并规划共享成本分配的成熟状态;识别 KPI 缺口 记录并维护标记的有效性;建立与相关方定期回顾共享成本分配效果的流程;部署并利用 KPI 确保标记准确性;持续使用 KPI 并强制执行,以保障成本分配效果

Janine Pickard Green、Amanda Dalton、Alex Dominic Savio、Amit Doshi

最后,感谢 FinOps 基金会的内部团队:Rob Martin(项目赞助人)、Samantha White(项目管理)、Tom Sharpe(设计)、Andrew Nhem(内容创作)。

原文地址:https://www.finops.org/wg/identifying-shared-costs/

相关文章
|
2月前
|
监控 Cloud Native 安全
FinOps云成本分配指南
成本分配是FinOps核心实践,通过层级结构、标签等元数据将云成本精准归因至部门、项目或所有者,实现成本展示与回收。需跨财务、工程、业务团队协作,建立强制标签策略并推动执行,提升财务透明度、问责制及优化能力。衡量指标包括标签合规率、成本分配时效等,成熟实施可显著增强组织云成本管控力。
|
运维 资源调度 Kubernetes
Kubernetes Scheduler Framework 扩展: 1. Coscheduling
# 前言 ## 为什么Kubernetes需要Coscheduling功能? Kubernetes目前已经广泛的应用于在线服务编排,为了提升集群的的利用率和运行效率,我们希望将Kubernetes作为一个统一的管理平台来管理在线服务和离线作业。但是默认的调度器是以Pod为调度单元进行依次调度,不会考虑Pod之间的相互关系。但是很多数据计算类的作业具有All-or-Nothing特点,要求所有的
3488 0
|
2月前
|
存储 人工智能 运维
云栖实录:重构可观测 - 打造大模型驱动的云监控 2.0 与 AIOps 新范式
大模型时代驱动智能运维变革,阿里云通过统一可观测平台、UModel数字孪生与AIOps Agent,实现数据、认知、决策的全链路升级,重构运维新范式。
417 0
|
2月前
|
人工智能 运维 监控
FinOps for AI 概述
本文探讨生成式AI带来的新型成本挑战,如cost-per-token计费、GPU资源稀缺与波动定价。提出通过FinOps实践实现AI支出管控:建立成本基线、优化资源分配、实施配额与标记、加强跨团队协作,并将财务监控与业务成果对齐,推动AI成本管理从“爬”到“跑”的渐进式成熟。
|
4月前
|
存储 人工智能 运维
日志服务&云监控全新发布,共筑企业智能运维新范式
阿里云推出Operation Intelligence新范式,通过日志服务SLS与云监控2.0,实现从感知、认知到行动闭环,推动运维迈向自决策时代。
374 1
日志服务&云监控全新发布,共筑企业智能运维新范式
|
1月前
|
存储 人工智能 运维
阿里云GPU服务器(EGS)核心功能:为高性能计算场景量身打造的弹性算力平台
阿里云GPU服务器(EGS)提供弹性算力,支持AI训练、推理、图形渲染等场景,具备多样实例、弹性调度、性能优化、全链路安全及生态集成五大优势,助力企业高效降本。
|
27天前
|
存储 人工智能 运维
阿里云全新发布的 UModel 是什么
当可观测数据被建模为可理解、可行动的上下文图谱,AIOps 才真正拥有了落地的土壤。
189 15
|
2月前
|
传感器 存储 搜索推荐
【开源代码】基于STM32的智能杯垫—喝水提醒系统设计与实现
基于STM32的智能杯垫,集成红外检测、OLED显示与语音提醒,实现喝水定时提醒功能。支持按键设置、多模态交互,提升饮水健康体验,开源设计,可扩展蓝牙/Wi-Fi,打造个性化智能健康设备。(239字)
【开源代码】基于STM32的智能杯垫—喝水提醒系统设计与实现
|
3月前
|
消息中间件 人工智能 运维
AI 原生应用开发实战营·京沪双城回顾 & PPT 下载
近日,阿里云AI原生应用开发实战营 · 北京站&上海站圆满落幕。继深圳、杭州、成都等城市之后,这两场活动吸引了250+名技术从业者深度参与。活动聚焦 AI Agent 领域的前沿技术与落地实践,深度分享AI Agent 架构趋势和演进、AI 开放平台、AI应用运行时、AI应用托管、大模型可观测&AIOps、异步化的Agent事件驱动等热门技术议题,并设置了动手实操环节。