规划高峰流量和发布事件

Last reviewed 2023-06-25 UTC

Google Cloud 架构框架中的本文档介绍了如何规划高峰流量和发布事件,以避免中断您的业务。

峰值事件是与业务相关的主要事件,导致流量激增,超出应用的标准基准。这些峰值事件需要计划内扩缩。

例如,拥有在线业务的零售商家预计会在节假日期间出现峰值事件。黑色星期五是美国感恩节的次日,属于一年中最繁忙的购物日之一。对于美国的医疗保健行业,由于福利登记的在线流量激增,10 月和 11 月可能会出现峰值事件。

发布事件是生产环境中新功能的任何重大发布或迁移事件。例如,从本地迁移到云,或者发布新的产品服务或功能。

如果您要发布新产品,则应该会预料到系统负载在公告期间和(可能情况下)之后有所增加。这些事件通常可能会导致前端系统的负载增加 5-20 倍(或更多)。增加的负载也会增加后端系统的负载。通常,这些前端和后端负载的特点是随着 Web 流量的事件打开而在短时间内快速扩容。发布事件涉及流量随后下降到正常水平。这种下降的速度通常比扩容到峰值的速度要慢。

峰值事件和发布事件包括三个阶段:

  • 规划和准备发布或峰值流量事件
  • 发布事件
  • 查看事件性能和事件后分析

本文档中介绍的实践可以帮助每个阶段顺畅运行。

为发布和峰值事件创建常规 Playbook

构建一个常规 playbook,可以长期了解当前和未来的峰值事件。请继续向该文档添加获得的经验教训,以便可以作为未来峰值事件的参考。

规划发布和峰值事件

未雨绸缪。为即将进行的发布以及预期(和意外的)峰值事件创建业务预测。如何准备好系统以应对扩容峰值取决于您对业务预测的了解程度。对之前的预测了解得越透彻,针对新业务的预测就越准确。这些新预测是预测系统预期需求的关键输入。

在整个组织中以及与第三方供应商确定计划管理和协调规划也是成功的关键。请尽早建立相关团队,以便您的计划管理团队可以设置时间表、节省预算,以及为额外的基础架构、测试支持和培训收集资源。

建立清晰的沟通渠道非常重要。沟通对发布或峰值事件的所有阶段都至关重要。尽早讨论风险以及所关注的领域,并在问题成为障碍之前加以解决。创建事件规划文档。压缩有关峰值事件的最重要信息并分发。这样做有助于用户了解规划信息并解决基本问题。此外,新人也可以通过查阅该文档掌握有关峰值事件规划的详情。

记录针对每个事件的规划。在记录规划时,请确保执行以下操作:

  • 识别任何假设、风险和未知因素。
  • 审视过往事件,以确定即将进行的发布或峰值事件的相关信息。确定哪些数据可用以及这些数据在过去提供的价值。
  • 详细说明发布事件和迁移事件的回滚计划。
  • 执行架构审核:
    • 记录关键资源和架构组件。
    • 使用架构框架查看环境的所有方面以发现风险和规模问题。
    • 创建展示架构主要组件如何连接的图表。您可以查看该图表以便隔离问题并更快地解决问题。
  • 如果适用,请将服务配置为使用提醒操作,以便在发生故障时自动重启。使用 Compute Engine 时,请考虑使用自动扩缩来处理吞吐量高峰。
  • 为确保 Compute Engine 资源在需要时可用,请使用预留。预留为获取 Compute Engine 可用区级资源的容量提供了极高保障。您可以使用预留来确保项目有可用资源。
  • 识别要跟踪的指标和提醒:
    • 识别要针对事件监控的业务和系统指标。如果未收集任何指标或服务等级指标 (SLI),请修改系统以收集此数据。
    • 确保您有足够的监控和提醒功能,并且已审核正常和以前的峰值流量模式。确保正确设置提醒。 使用 Google Cloud Monitoring 工具查看应用使用情况、容量以及应用和基础架构的整体健康状况。
    • 确保通过感兴趣的监控和提醒级别捕获系统指标。
  • 与您的 Google Cloud 客户支持团队一起审核增加的容量要求,并规划所需的配额管理。如需了解详情,请参阅确保您的配额符合容量要求
  • 确保您能获享适当级别的云支持服务,您的团队了解如何发起支持请求,并已建立上报路径。如需了解详情,请参阅建立云支持和上报流程
  • 定义沟通计划、时间表和责任:
    • 与跨职能利益相关方互动,以协调沟通和安排规划。这些利益相关方可包括来自技术、运营和领导团队以及第三方供应商的相应人员。
    • 建立包含关键任务和拥有这些任务的团队的明确时间表。
    • 建立责任分配矩阵 (RACI),以便传达团队、团队领导、利益相关方和责任方的所有权。
    • 您可以使用高级支持服务的事件管理服务来管理计划的峰值事件。使用此服务时,客户服务团队与您的团队一起制定计划,并在整个活动过程中提供指导。

建立审核流程

当峰值流量事件或发布事件结束时,请查看该事件以记录经验教训。然后,根据这些经验教训更新您的 Playbook。最后,将经验教训运用到下一个重大事件中。从先前的事件中吸取经验教训很重要,尤其是在这些事件强调了系统在压力下的限制条件时。

对于峰值流量事件或发布事件,回顾性审核(也称为事后分析)是一种捕获数据和理解突发事件的实用方法。对于预期峰值流量和发布事件以及导致问题的任何突发事件,请完成此审核工作。在此过程中,请培养无责备文化。

如需详细了解事后分析,请参阅《事后分析文化:从失败中吸取经验教训》

后续步骤

  • 打造自动化文化(本系列中的下一个文档)
  • 探索架构框架中的其他类别,例如系统设计、安全、隐私权、合规性、可靠性、费用优化和性能优化。