本架构框架部分探讨了可提供商业价值的高效运行、管理和监控系统如何实现卓越运营。
框架由以下系列文章组成：
- 概览
- Google Cloud 系统设计注意事项
- 卓越运营（本文）
- 安全性、隐私权和合规性
- 可靠性
- 性能和费用优化
卓越运营可帮助您为另一项关键原则（即可靠性）打好基础。（如需了解有关在 Google Cloud 上构建和运营可靠服务的相关技术和过程要求，请参阅可靠性部分。）
策略
使用这些策略实现卓越运营。
自动构建、测试和部署。使用持续集成和持续部署 (CI/CD) 流水线将自动测试内置到您的发布中。执行自动集成测试和部署。
监控业务目标指标。定义和衡量相关业务指标，并发出相关提醒。
执行灾难恢复测试。不要等待灾难发生，而应当定期验证灾难恢复流程可正常运行，并定期测试这些流程。
最佳做法
请遵循以下做法，以实现卓越运营。
- 提高软件开发和发布速度。
- 监控系统运行状况和业务运行状况。
- 针对故障进行规划和设计。
以下部分详细介绍了最佳做法。
提高开发和发布速度
使用 CI/CD 方法提高速度。首先，您需要提高软件开发团队的工作效率，并在构建流程中实现集成测试自动化。您可以在构建满足特定测试条件后自动执行部署。您的开发者可以更频繁地进行较小的更改。对更改进行全面测试，缩短了部署时间。
本部分介绍 CI/CD 方法的要素：发布工程、自动化、中央代码库、构建流水线、测试和部署。
发布工程
发布工程是一项监督软件的构建和交付方式的作业功能。发布工程遵循以下四种做法：
- 自助模式。制定指南，帮助软件工程师避免常见错误。由自动化流程强制执行。
- 频繁发布。快速发布有助于排查问题，更轻松地解决问题。频繁发布依赖于自动化单元测试。
- 封闭构建。确保与构建工具保持一致。对现在（与一个月前相比）用于构建版本的构建编译器进行版本控制。
- 强制执行政策。所有更改都需要经过代码审核，最好包含一系列准则和政策以加强安全性。这样可以改进代码审核、排查问题和测试新发布。
自动化
自动化构建和发布流水线，扫描任何已知问题并执行快速测试。您还可以使用自动化功能来消除重复性任务。
中央代码库
将代码存储在中央代码库中，根据需要进行版本控制并添加标签（例如 test、dev、prod）。采取这些步骤有助于确保您的构建流水线生成一致的结果。在 Google Cloud 中，您可以将代码存储在 Cloud Source Repositories 版本中，并将其与各种产品集成。
构建流水线
对构建配置进行版本控制，确保所有构建都保持一致并且在必要时可以回滚到上一个已知配置。在 Google Cloud 中，Cloud Build 可帮助您定义用于构建应用软件包的依赖项和版本。您可以使用 Cloud Functions 定期触发构建流程，或者在签入新代码时触发特定事件的构建。您还可以使用 Cloud Functions 来触发测试并自动执行整个流水线。
测试
测试是成功发布的关键环节。测试示例包括：
- 单元测试。单元测试速度很快，可帮助您执行快速部署。
- 集成测试。当您测试与互连服务的集成时，这些测试可能会比较复杂。
- 系统测试。系统测试非常耗时且复杂，但可帮助您在部署之前识别边缘情况并解决问题。
在将应用部署到生产环境前，您可以执行其他测试，包括静态测试、负载测试、安全性等。自动执行测试后，您可以更新并添加新测试，以改进和维护部署的运营状况。
部署
您可以选择应用的发布方式。最佳做法是执行 Canary 测试并观察您的系统是否存在任何错误，如果您有可靠的监控和提醒系统，会更加方便。在 Google Cloud 中，您可以使用代管实例组 (MIG) 进行 A/B 测试或 Canary 测试，还可在必要时执行缓慢发布或回滚。
设计问题
- 您的开发团队如何管理构建和发布？
- 您的开发团队采用什么集成和安全测试？
- 如何回滚？
建议
- 将 CI/CD 流水线用作部署到生产环境的唯一方式。
- 隔离并保护您的 CI/CD 环境。
- 仅构建一次，通过流水线提升结果。
- 使 CI/CD 流水线保持较高的速度。
- 最大限度减少版本控制系统中的分支。
关键服务
Cloud Source Repositories 是一项 Google Cloud 上托管的功能齐全的专用 Git 代码库服务。您可以使用 Cloud Source Repositories 协作开发任何应用或服务。
借助 Container Registry，您的团队可以在同一个位置集中管理 Docker 映像、执行漏洞分析，并通过精细的访问权限控制机制来决定谁可以访问哪些内容。现有的 CI/CD 集成让您可以设置完全自动化的 Docker 流水线，以快速获取反馈。
Cloud Build 服务可供您在 Google Cloud 基础架构上执行构建。Cloud Build 可以从 GitHub、Bitbucket、Cloud Storage 或 Cloud Source Repositories 导入源代码，根据您的规范执行构建，并生成 Docker 容器或 Java 归档等工件。
监控系统运行状况和业务运行状况
DevOps 资源和评估 (DORA) 项目对监控的定义如下：
监控是收集、分析和使用信息跟踪应用和基础架构以指导业务决策的过程。监控是一项关键功能，因为它可以让您深入了解您的系统和工作。
通过监控，您可以决定更改对服务的影响，将科学的方法应用于突发事件响应，并衡量服务与业务目标的一致性。启用监控后，您可以执行以下操作：
- 分析长期趋势。
- 比较不同时间段内的实验。
- 定义针对关键指标的提醒。
- 构建相关的实时信息中心。
- 执行回顾性分析。
监控业务驱动的指标和系统运行状况指标。业务驱动的指标可帮助您了解您的系统对业务的支持程度。例如，您可以监控应用中为用户提供服务的费用，重新设计后网站流量的变化，或客户在您的网站上购买产品所需的时间。系统运行状况指标可帮助您了解系统是否正常运行以及是否在可接受的性能水平内。
使用以下四个黄金信号来监控您的系统：
- 延迟时间。处理请求所需的时间。
- 数据流量。对您的系统的需求量。
- 错误。请求失败率。失败的请求可分为以下几种：显式（例如 HTTP 500）、隐式（例如 HTTP 200 成功响应，但内容有误）或政策导致（例如，如果承诺 1 秒响应时间，响应时间超过 1 秒的请求即视为错误）。
- 饱和度。您的服务的覆盖程度。对受限程度极高的资源的衡量。（即在内存受限的系统中显示内存；在 I/O 受限的系统中显示 I/O）。
日志记录
日志记录服务对于监控系统至关重要。虽然指标是监控特定项目的基础，但日志包含您进行调试、安全相关分析和遵循合规性要求所需的有价值信息。Google Cloud 包含 Cloud Logging，这是一项集成式日志记录服务，可用于存储、搜索、分析、监控来自 Google Cloud 的日志数据和事件，并发出提醒。Cloud Logging 会自动从 Google Cloud 服务中收集日志。您可以使用这些日志来构建监控指标，以及将日志记录导出到外部服务，例如 Cloud Storage、BigQuery 和 Pub/Sub。
指标
定义指标以衡量部署的行为。请确保您的指标定义始终能够反映业务需求，并考虑提升或组合一些指标来形成服务等级指标 (SLI)。如需了解详情，请参阅可靠性。
从基础架构和网络到业务逻辑，您的所有服务等级都会生成指标。示例如下：
- 每秒请求数，由负载平衡器测量。
- 每个磁盘的读取的总磁盘块数。
- 通过指定网络接口发送的数据包。
- 给定流程的内存堆大小。
- 响应延迟的分布。
- 数据库实例拒绝的无效查询数。
监控
监控复杂应用本质上就是一项需要付出努力的重大工程。Google Cloud 提供 Cloud Monitoring，这是一项代管式服务，属于 Google Cloud 运维套件的一部分。您可以使用 Cloud Monitoring 来监控 Google Cloud 服务和自定义指标，Cloud Monitoring 提供用于与第三方监控工具集成的 API。
Cloud Monitoring 可将来自基础架构的指标、日志和事件汇总在一起，为开发者和运营人员提供一组丰富的可观测信号，帮助您加快根本原因分析并缩短平均解决时间 (MTTR)。您可以定义提醒和自定义指标，以满足业务目标并帮助您汇总、直观呈现和监控系统运行状况。
Cloud Monitoring 为云端和开源应用服务提供默认信息中心。借助指标模型，您可以使用强大的可视化工具创建自定义信息中心，并在 Metrics Explorer 中配置图表。
信息中心
启用监控后，您可以构建相关的信息中心，以采取相应措施。使信息中心简单易读。您应该执行短期/实时分析和长期分析，并将其直观呈现出来。如需了解详情，请参阅可靠性。
提醒
请确保提醒系统与监控系统的四个黄金信号直接对应，以便您比较不同时段的性能，以确定功能的速度或回滚更改。
让提醒具有实用性。当您发送提醒时，请添加一个说明并提供所有必要的信息，以便待命人员立即采取措施。只需点击几下并浏览，即可了解如何针对提醒采取措施。
应始终尽量减少繁复操作，例如，消除经常发生的错误或实现自动修复。让待命人员专注于确保运营组件的可靠性。如需了解详情，请参阅可靠性。
上报路径
明确定义的上报路径对于减少您在获取 Google Cloud 产品支持方面的工作至关重要。此路径包括学习如何与 Google 支持团队合作、查找为支持工程师优化的架构文档、定义服务中断期间的通信方式，以及设置监控和日志记录以诊断问题。
若要开始定义上报路径，您需要确保正确设置安全、网络和系统管理员，使其能接收来自 Google Cloud 的重要电子邮件和提醒。这有助于管理员作出明智的决策，并尽早解决问题。同样，请确保项目所有者具有可路由的电子邮件地址的用户名，以便他们能够接收到重要电子邮件。
建议
- 选择与您的业务需求相对应的相关指标。
- 使用 Cloud Monitoring 并根据需要为自定义指标部署监控代理。
- 确保已为所有日志条目配置 Cloud Logging。
- 设计明确定义的提醒，例如成功或失败百分比。
- 提醒应包含关于要采取的措施的信息。
- 考虑购买基于角色的软件包或企业支持服务软件包。
- 定义上报路径，并在使用 Cloud Support 时提供有用的指标，例如时间、产品和位置。
关键服务
Cloud Monitoring 为 Web 应用和其他可通过互联网访问的服务提供指标收集、聚合和信息中心，以及提醒框架和端点检查。
借助 Cloud Logging，您可以从云端和开源应用服务过滤、搜索、查看并导出到 BigQuery、Cloud Storage 或 Pub/Sub 日志。您可以根据集成到信息中心和提醒中的日志内容定义指标。
Cloud Debugger 可让您在生产环境中的任意代码位置检查应用状态，从而将应用的生产数据连接至您的源代码。在此过程中，您无需停止或者减缓应用请求。
Error Reporting 可分析并汇总云端应用中的错误，并在检测到新错误时向您发出通知。
Cloud Trace 提供 App Engine 延迟采样和报告功能，其中包括每个网址的统计信息和延迟分布。
Cloud Profiler 可以持续分析生产应用中的资源使用情况，从而帮助您识别并消除性能问题。
资源
灾难恢复设计
通过对系统进行设计以预测和处理故障场景有助于确保在发生灾难时将系统受到的影响降至最低。为正确应对故障，请确保您有明确定义并定期测试的灾难恢复 (DR) 计划，可用于备份和恢复服务与数据。
服务中断事件可能随时发生。您的网络可能会中断，您的最新应用推送可能会引发严重错误，或者您可能需要应对自然灾害。出意外时，拥有一个有针对性且经过良好测试的强大 DR 计划非常重要。
规划
DR 是业务连续性规划的一部分。 DR 规划的起点是业务影响分析，该分析定义了两个关键指标：
恢复时间目标 (RTO)，即可以接受的最长应用宕机时间。此数值通常作为服务等级协议 (SLA) 的一部分进行定义。
恢复点目标 (RPO)，即可能由于重大突发事件而丢失应用中数据的最长可接受时长。此指标因数据的使用方式而异。例如，经常修改的用户数据的 RPO 可能仅为几分钟。不太关键、不经常修改的数据的 RPO 可能为几个小时。此指标仅描述时长；它不会涉及已丢失数据的数量或质量。
通常，RTO 和 RPO 值越小（应用必须越快地从中断中恢复），应用运行费用越高。下图显示了费用与 RTO/RPO 的比率：
由于较低的 RTO 和 RPO 值通常意味着较高的复杂性，因此管理开销遵循类似的曲线。例如，高可用性 (HA) 应用可能需要您管理两个物理上分离的数据中心之间的分配、管理复制等。
RTO 和 RPO 值通常汇总到另一个指标：服务等级目标 (SLO)，它是 SLA 的关键可测量元素。
- SLA 是指定要提供的服务、支持方式、时间、地点、费用、性能、处罚和相关各方的责任的整个协议。
- SLO 是 SLA 的特定可测量特征，例如可用性、吞吐量、频率、响应时间或质量。
一个 SLA 可以包含许多 SLO。RTO 和 RPO 是可测量的，应被视为 SLO。
基础架构要求
在灾难恢复中，最佳做法是考虑多种要求，包括以下各项：
- 容量：获取充足资源以按需扩缩。
- 安全性：提供物理安全性以保护资产。
- 网络基础架构：包括防火墙和负载平衡器等软件组件。
- 支持：提供熟练的技术人员，以进行维护并解决问题。
- 带宽：为峰值负载规划合适带宽。
- 设施：确保包括设备和电力在内的物理基础设施。
Google Cloud 上的灾难恢复
与在本地满足 RTO 和 RPO 要求相比，Google Cloud 可以帮助您减少满足 RTO 和 RPO 要求所需的费用。Google Cloud 可帮助您避开与物理硬件相关的大部分或所有复杂因素，从而消除流程中的许多业务费用。此外，Google Cloud 还重视管理简单性，可以帮助您降低复杂应用的管理费用。
Google Cloud 提供了几项与灾难恢复规划相关的功能：
全球网络。Google 拥有全球最大、最先进的计算机网络之一。Google 骨干网采用先进的软件定义网络技术，且提供边缘缓存服务，可实现快速、一致和可扩缩的性能。
冗余。全球的多个入网点 (PoP) 可确保强大的冗余能力。您的数据会自动镜像到多个位置中的存储设备。
可扩缩性。Google Cloud 像其他 Google 产品（例如搜索和 Gmail）一样具备可扩缩性，即使您遇到巨大的流量高峰，也能应对自如。App Engine、Compute Engine 自动扩缩器和 Datastore 等代管式服务提供自动扩缩功能，使您的应用可以根据需要进行扩缩。
安全性。我们在 Gmail 和 Google Workspace 等 Google 应用中保护客户安全，拥有超过 15 年的丰富经验，Google 安全模型正是基于这些经验构建而成。此外，Google 的站点可靠性工程团队可帮助确保高可用性并防止平台资源的滥用。
合规性。Google 会定期接受独立的第三方审核，以验证 Google Cloud 符合安全性、隐私和合规性规定以及最佳做法。Google Cloud 符合 ISO 27001、SOC 2/3 和 PCI DSS 3.2.1 等认证标准。
建议
- 定义 RTO 和 RPO 目标。
- 根据数据和应用解决方案设计灾难恢复计划。
- 每年至少手动测试一次灾难恢复计划。
- 评估受控的故障注入的实现，尽早发现回归问题。
- 利用混沌工程，找出存在风险的方面。
关键服务
Persistent Disk 快照提供 Compute Engine 虚拟机的增量备份或快照，您可以跨地区复制并将其用于在发生灾难时重新创建 Persistent Disk。
实时迁移可确保即使发生主机系统事件（例如软件或硬件更新），虚拟机实例仍能正常运行。
Cloud Storage 是一种提供 Nearline 和 Coldline 等存储类别的对象存储，非常适合特定使用场景（例如备份）。
Cloud DNS 提供了在自动恢复过程期间管理 DNS 条目的程序化方式。Cloud DNS 使用 Google 全球任播域名服务器网络，从遍布全球的冗余位置提供您的 DNS 地区信息，为您的用户提供高可用性和低延迟的 DNS 服务。
资源