1. 升级背景

合合信息是一家中国领先的人工智能(AI)产品公司，一直致力于通过 AI 技术赋能创新，为全球数亿用户和多元化行业提供产品服务。凭借超过 18 年的 AI 研究和应用专业知识，合合信息已成为全球多模态大模型文本智能技术的领先者，并自主研发推出了一系列产品，包括扫描全能王、名片全能王、启信宝、TextIn 和 Chaterm，公司业务遍及全球 200 多个国家和地区。

目前合合信息在海外区域有多套 Aurora MySQL 实例运行在 3.x 版本，计算节点的配置为 r6g。我们期望与亚马逊云科技合作达成以下目标：

1.1 借助 Graviton4 机型提升 Aurora 集群性价比

众所周知，Graviton 芯片的算力和性价比是相当出众的，曾有 Blog 提到次新一代 Graviton3 与高于 Graviton3 一代的 Intel r7i 机型相比，在.net 的测试场景中有 23～32%的性能提升，但价格却更便宜(可参考Blog)。在本次实验当中合合信息将在 Aurora 服务上验证最新的 Graviton4 的性能收益，也希望通过引入 G4 机型到 Aurora 服务中来提升当前数据库集群的处理能力，享受到最新 Graviton4 芯片所带来的大幅度性价比提升。

1.2 借助 Aurora 3.10 LTS 版本获得更长的生命周期

Aurora MySQL 3.10 版本在 2025 年 8 月份发布，这一版本与普通的发布版本仅支持 1 年不同，LTS 3.10 版本将提供近 3 年的支持时间，即到 2028 年。用户可以保持在 LTS 版本 3 年以避免每年一次的升级工作，同时因为升级切换带来的业务影响也被减少到最低。

1.3 借助 Q CLI 加速技术验证，支撑 Aurora 演进

在生产迁移前需要对 Graviton4 做性能验证，同时需要对节点切换的影响做深入的分析，最小化切换对应用访问的影响，但这些工作往往是需要繁杂的环境搭建和工具设计才能完成，本次合合信息的测试验证当中就大量使用了 Q CLI 来加速技术验证，甚至形成多维度的分析报告。让我们在接下来的章节里展示如何使用 Q CLI 来加速合合信息在 Aurora + Graviton4 上的技术验证。

📢限时插播：Amazon Q Developer 来帮你做应用啦！

🌟10 分钟帮你构建智能番茄钟应用，1 小时搞定新功能拓展、测试优化、文档注程和部署

⏩快快点击进入《Agentic Al 帮你做应用 -- 从0到1打造自己的智能番茄钟》实验免费体验企业级 AI 开发工具的真实效果吧

构建无限，探索启程!

2. Aurora 升级的版本选择

在本次技术验证当中，我们需要对 Aurora 的版本信息，支持时间，以及引擎与 R7g/R8g 的兼容信息做整理。如果使用人工，这将是非常耗时，且容易出错的，但当我们配置亚马逊云科技官方的 aws-knowledge-mcp-server，就可以比较方便的生成相关的版本信息。

2.1 Aurora R8g/R7g 与版本选择建议

当前最新的 Aurora mysql 版本是 3.10.1，当前 LTS 版本是 3.10，推荐生产系统使用 3.10.1 版本。

对于 Aurora MySQL 引擎推荐使用 3.10.0 (LTS)，获得近 3 年的支持周期。更长的周期意味着更少的运维工作，同时也能避免强制升级带来的业务影响。

2.2 Aurora R8g 机型按需/预留实例的可用性

结合 Q CLI 的 MCP 功能，借助于 Amazon Pricing API 完成 R8g OD/RI 在各区域的覆盖情况确认，并借助于 aws-knowledge-mcp-server 补充相应的发布时间信息。

2.3 Q CLI 辅助完成版本调研

可以参考以下提示词完成相关内容的生成：

Plain Text我需要对Aurora和版本和r7g/r8g的兼容性做分析，以下是分析要求：   - 基于Amazon CLI查询的实时版本兼容性分析，结合aws的在线文档和Blog，What'new资源；   - 当前可用Aurora版本总览：以表格呈现，包括引擎类型/最新版本/当前LTS版本/R7g最低版本要求/R8g最低版本要求   - 详细的Aurora MySQL和PostgreSQL版本发布时间线,以表格呈现，包括Aurora版本/发布时间/标准支持结束时间/是否LTS版本/R7g兼容/r8g兼容   - 如果需要渲染可以使用中国国内源的d3.js；   - 以html格式呈现，文件名为aurora-graviton-version.html;

注意：

1.为确保 R8g/R7g OD/RI 实例可用信息的准确性，这需要 aws cli 环境支持，profile 需要有 Pricing API 的访问权；

2.需要确保 Q CLI 配置了这两个 MCP Server

• core-mcp-server：亚马逊云科技相关的语义识别

• aws-knowledge-mcp-server：支持 streamablehttp

参考链接：https://awslabs.github.io/mcp/servers/aws-knowledge-mcp-server/

3. Q CLI 加速升级前的技术验证

合合信息在决定将 Aurora 迁移至最新的 Graviton4 平台之前，我们对两个维度的信息做了确认，这包括：

• 性能验证场景 – Graviton2/Graviton3/Graviton4 的数据库性能做测试；

• 应用切换验证 – 切换过程应用影响模拟与分析；

以下我们将通过 Q CLI 来加速这些维度的技术验证。

3.1 使用 Q CLI 加速 Aurora 的 G2/G3/G4 机型的性能对比

想到做一次数据库性能测试，相信大家会想到有这几类工作要做：

• 设计阶段： 设计并搭建测试环境，包括 VPC/子网/安全组，用于测试的堡垒机和 Aurora 集群；

• 测试阶段： 安装 sysbench，为 ARM 架构编译程序，创建测试数据，编写脚本，多次测试；

• 生成测试报告： 分析测试数据，用 Excel 画出表格，以此得出测试结论；

但使用了 Q CLI 之后以上除了实验设计，测试方法，测试报告要求需要明确外，其它工作都可以交给 Q CLI 来完成。它可以帮我们达成什么样的结果，我们一步步看。

3.1.1 Q CLI 创建的验证环境和验证流程图

1. 验证机型选择

2. 验证资源与架构图

借助于 Q CLI 的 xml 解析能力，在完成了测试环境搭建之后，它为本次测试环境生成了 drawio 格式的架构图(字体重叠问题需人工美化)：

3. 验证流程概要

对于本次测试需要测试人员与 Q CLI 紧密协作，因为 Q CLI 还不具备独立完成测试流程制订的能力，需要融合我们在性能测试的许多方法和经验积累。 以下为 Q CLI 根据多次的修改补充后完成的测试计划，并且使用 drawio 格式生成的测试流程图，为了美观总体布局做了少量调整。

3.1.2 使用 Q CLI 完成测试结果分析与报告展示

Q CLI 在本次的技术验证中发挥了重大的作用，尤其是在测试结果的分析和呈现上，可以生成非常美观的测试报告，而这些报告可以作为独立的交付物存档总结。

1. 性能验证总结

2. 测试各项指标情

3. 详细的测试数据与性价比折算

4. 验证总结

通过这次性能验证测试，我们可以按每百万 TPS 每美金的成本来对比不同机型的差异：

• r8g.2xlarge TPS 提升 113%:  最新一代处理器，在 128 线程高并发场景下表现优异，测试结果为 27.22 百万 TPS/$；

• r7g.2xlarge TPS 提升 40%:  平衡的性能表现，适合大多数工作负载，在 128 线程下，测试结果为 15.55 百万 TPS/$；

• r6g.2xlarge 测试基线:  128 线程并发下，测试结果为 13.88 百万 TPS/$；

5.Q CLI 提示词参考

以下是提示词参考

Bash我需要完成Aurora 3.10版本和Graviton2/Graviton3/Graviton4实例的性能测试项目，并生成完整的分析报告。## 环境配置- 当前环境：macOS，已配置AWS CLI和Python3- Python环境：source ~/Documents/VSCodeFolder/.venv/bin/activate- 包管理：使用 uv pip install 安装Python包- 密钥路径：~/Documents/VSCodeFolder/_aihome/kp-vgn.pem- 测试区域：us-east-1## 基础设施要求- 使用现有VPC（如满足要求）- 堡垒机：r6a.2xlarge，Amazon Linux 2023，开放22端口- Aurora集群：3.10版本，3个实例分别为 db.r6g.2xlarge(主), db.r7g.2xlarge, db.r8g.2xlarge- 安全组：不开放公网，但允许堡垒机访问Aurora（3306端口）## 软件安装要求（关键改进）- 堡垒机软件包：* MySQL客户端：使用 mariadb105 (Amazon Linux 2023兼容)* sysbench：从源码编译安装，需要先安装Development Tools和mariadb105-devel* 编译依赖：git, automake, libtool, openssl-devel- 安装顺序：先安装依赖包 → 编译sysbench → 验证安装## 测试数据要求- 使用sysbench oltp_read_write模板- 8张表，每表200万记录- 读写比例1:1- 数据准备时间：约15-20分钟## 测试执行要求- 测试线程：32, 64, 128- 每个测试：预热1分钟 + 测试2分钟 = 共3分钟- **关键**：每个实例必须通过主备切换作为主节点进行测试（因为sysbench包含写操作）- 测试顺序：r6g → r7g → r8g- 切换等待时间：failover后等待60秒稳定，测试间隔30秒## 定价数据（us-east-1，基于实时查询）- 按需价格：db.r6g.2xlarge=$1.038/h, db.r7g.2xlarge=$1.106/h, db.r8g.2xlarge=$1.104/h- 预留实例(1年)：db.r6g.2xlarge=$0.68/h, db.r7g.2xlarge=$0.851/h, db.r8g.2xlarge=$0.74/h## 报告生成要求（重要更新）需要生成3个不同类型的报告：### 1. 性能测试报告- 使用ECharts（中国国内CDN）进行图表渲染- 商务风格HTML报告- 包含：TPS/QPS/延迟P95对比、成本效益分析- 文件名：aurora_graviton_performance_report.html### 2. 架构分析报告- 商务风格HTML报告，包含：* Aurora版本兼容性详细分析（基于AWS CLI查询）* 全球区域可用性和定价对比* LTS版本发布时间线* 技术规格对比- 文件名：aurora_graviton_analysis_report.html### 3. Draw.io架构图（重要新增）- AWS官方风格架构图，使用标准AWS图标和颜色- 包含VPC、多AZ、安全组、Aurora集群的完整架构- 测试流程图，展示7个关键阶段和详细任务分解- 文件格式：.drawio (可在diagrams.net中打开编辑)- 文件名：aurora_graviton_architecture.drawio, aurora_graviton_test_process.drawio

3.2 Q CLI 加速应用切换透视与验证

Aurora 集群在节点切换或蓝绿部署的切换上提供非常好的体验， 从技术上我们也希望借助于 Q CLI 的能力，帮我们理清楚两个技术问题：

• 读写访问的影响机制： 在节点切换的整个过程，应用程序会经历哪些阶段，会有怎样的行为表现；

• 实例切换与 DNS 切换的时间关系： DNS 切换与实例切换的关系，以及哪些机制将有助于减少切换对业务的影响；

3.2.1 测试场景设计

3.2.2 测试的重要指标

3.2.3.测试的时间线

下图是切换过程操作的时间线与 3 种探针的表现

3.2.4 切换过程与应用行为

从上面的表格，在整个切换过程中读写探针和 DNS 探针所有的性能变化，报错类型，这些都尽收眼底，我们终于比较透彻了解切换过程应用程序的行为表现。

3.2.5 切换测试结论

通过上面的测试我们可以看出：

1. 业务的影响为 14s，其中读操作的影响为 9s，写操作的影响为 14s，这说明如果应用可以有读写分离，在节点切换时将能提供更高的可用性；

2. 在 Aurora 实例发生切换到 DNS 的 IP 映射真实切换之间，对于写操作都是不可用的，这期间的连接尝试也是无效和；

3. 在 DNS 切换完成后写操作完全恢复正常，这表明 DNS 切换是应用恢复的唯一标记；

3.2.6 应用切换的优化

既然 DNS 切换是应用恢复的唯一标记，我们可以通过以下两种方式使应用切换变得更快，更有效率：

1. 对于具备 DNS 检测的应用，它最终会通过 DNS 解析到新的 IP，连接到新的实例；

2. 对于没有 DNS 检测的应用，在切换发生后，将新的集群 IP 刷新给这些应用(reload 或重启服务)，这些应用也会连接到正确的实例；

3. 使用亚马逊云科技官方的驱动程序或 Wrapper 插件实现集群拓扑感知，在第一时间获知 IP 改变，第一时间恢复连接；

官方的数据库驱动加速切换的原理，可以参考这篇博客《Demystifying the Amazon advanced JDBC wrapper plugins》

3.2.7 Q CLI 的提示词参考

切换测试进行过许多次，提示词会根据 Q CLI 输出的不同根据测试目标做调整，所以这个提示词不是合并所有修改的版本，并且你使用它可能的输出不一定相同，需要结合你的测试环境，测试要求来确定。以下是一个供参考的版本。

Shell我需要完成Aurora 3.10版本和Graviton2/Graviton4实例的切换测试项目，我会提供测试工具，你熟悉它，并完成测试，最终生成完整的分析报告。以下是测试的详细描述：
## 环境配置- 当前环境：macOS，已配置AWS CLI和Python3- Python环境：source ~/Documents/VSCodeFolder/.venv/bin/activate- 包管理：使用 uv pip install 安装Python包- 密钥路径：~/Documents/VSCodeFolder/_aihome/kp-vgn.pem- 测试区域：ap-southeast-1
## 基础设施要求- 使用现有VPC（如满足要求）- 堡垒机：r6a.2xlarge，Amazon Linux 2023，开放22端口- Aurora集群：3.10版本，2个实例分别为 db.r6g.2xlarge(主),  db.r8g.2xlarge- 安全组：允许堡垒机访问Aurora（3306端口）
## 软件安装要求（关键改进）- 堡垒机软件包：  * MySQL客户端：使用 mariadb105 (Amazon Linux 2023兼容)  * sysbench：从源码编译安装，需要先安装Development Tools和mariadb105-devel  * 编译依赖：git, automake, libtool, openssl-devel- 安装顺序：先安装依赖包 → 编译sysbench → 验证安装- 测试程序：~/Documents/VSCodeFolder/tanzhen目录下    aurora_failover_monitor_3probes-v2.py - 包括MySQL读/写/DNS检测的3探针验证工具；    aurora_config.json - 测试的配置信息，包括集群/用户名/密码/超时设置等；    generate_html_report.py - HTML报告生成工具；    README.md - 探针工具介绍    aurora_probe_round2_20250918.jsonl - 之前的测试日志    aurora_failover_report_round2.html - 之前的分析报告
## 测试执行要求- 测试并发：使用测试程序模拟200个会话从堡垒机连接到Aurora集群- 测试方法：在预热30秒之后，发起节点切换，从r6g切换到r8g，程序继续运行1分钟- 测试评估：根据aurora_failover_monitor_3probes-v2.py的会话信息分析200个会话受影响的情况，包括受影响的时间点，影响的操作，恢复的时间，以及切换过程中会话的异常情况：中断/超时/重连等情况
## 报告输出1.使用html输出报告，需要Chart渲染请使用中国区的echarts；2.内容包括：实验设计，环境配置，操作时序图，会话随时间展示受影响的的情况，包括报错/超时/中断/恢复等情况；3.给出切换对于高并发业务的影响模式描述，消除客户对业务影响的顾虑；

4.升级方案选择与升级过程

借助于上面的技术验证，我们对将生产环境切换到 Aurora 的 Graviton4 机型更加有信心了，那么接下来我们要做的就是升级方案的选择，因为我们的 Aurora MySQL 数据库的主要版本在 3.04 上，需要升级到 Aurora 3.10 LTS 版本。

在升级方案的选择上，我们可以用 Q CLI 生成基本的方案建议，但同时我们需要考虑到目前的生产实况，把不常用的方案剔除，接下来我们将从多个维度对比 3 套升级方案：

4.1 升级方案选择

4.1.1 方案 1 – 蓝绿部署(推荐)

建议方式： 对于升级支持，Aurora 提供了蓝绿部署，它将自动创建绿环境(目标环境)，并自动同步数据修改，最终按照指令完成 DNS 指向的切换。。

以下是切换的核心代码，供参考：

Shell1. 创建蓝绿部署aws rds create-blue-green-deployment \  --blue-green-deployment-name "aurora-upgrade" \  --source "arn:aws:rds:region:account:cluster:source-cluster" \  --target-engine-version "8.0.mysql_aurora.3.10.0"
2. 升级绿环境实例到R8gaws rds modify-db-instance \  --db-instance-identifier "green-instance-id" \  --db-instance-class "db.r8g.xlarge"
3. 执行切换aws rds switchover-blue-green-deployment \  --blue-green-deployment-identifier "deployment-id"

4.1.2 方案 2 – 原地升级

直接在原集群上串行执行版本升级和硬件升级，读写业务会受影响，升级后无法回退。

以下是原地升级的核心代码，供参考：

Shell1. 升级引擎版本aws rds modify-db-cluster \  --db-cluster-identifier "cluster-name" \  --engine-version "8.0.mysql_aurora.3.10.0" \  --apply-immediately
2. 升级实例类型aws rds modify-db-instance \  --db-instance-identifier "instance-name" \  --db-instance-class "db.r8g.xlarge" \  --apply-immediately

4.1.3 方案 3 – 读复本提升

创建跨区域读副本集群(新版本+新硬件)，提升为独立集群后手动切换应用连接。该特性目前只在 3.10 上支持。

以下是读复本提升的核心代码，供参考：

Shell1. 创建跨区域读副本(新版本)aws rds create-db-cluster \  --db-cluster-identifier "replica-cluster" \  --engine-version "8.0.mysql_aurora.3.10.0" \  --replication-source-identifier "source-cluster-arn"
2. 添加R8g实例aws rds create-db-instance \  --db-cluster-identifier "replica-cluster" \  --db-instance-class "db.r8g.xlarge"
3. 提升为独立集群aws rds promote-read-replica-db-cluster \  --db-cluster-identifier "replica-cluster"

4.1.4 三种方案的对比

借助于 Q CLI 我们可以对三种典型的升级方案进行多维度的对比，对比维度包括停机时间/数据安全/回滚能力，以及适用的应用场景等：

根据目前我们过去的生产实践，结合业务停机时间要求，我们将选择蓝绿部署来实现数据库的升级和切换。

4.2 应用切换方案

借助于上面的技术验证结论，应用程序在实例切换时恢复的速度和 DNS 的变化感知有直接关系，我们对现有的应用进行梳理后，将应用分为两类场景：如果一个应用具备主动的 DNS 变化检测能力，它在连接重建上将是最有效的。如果应用不具备这样的检测能力，我们就可以结合手工 reload 配置文件的方式实现应用的快速切换。

根据这个因素我们将生产的业务分为两类场景：

• 场景 1 – 以 golang 为客户端的数据库中间层，具备 DNS 变化检测能力

• 场景 2 – 以 ngx+lua 为客户端的业务中间层，不具备 DNS 变化检测能力

根据我们的生产实践，这样的区分应用场景的切换虽然稍稍增加运维工作量，但它可以让应用程序在 10s 之内快速的恢复，这样的切换效率是相当高的。

4.2.1 场景 1 – 以 golang 为客户端的数据库中间层

能自主识别 RDS 域名后端 IP 地址变动，该场景下，在蓝绿切换后，客户端会立即将 90%到 100%的连接切换到绿实例，在域名稳定后(约 30 秒)，reload 客户端，完成剩余连接切换。

4.2.2 场景 2 – 以 ngx+lua 为客户端的业务中间层

不能自主识别 RDS 域名后端 IP 地址变动，需要提前解析 ip，然后在配置中心更新 ip，在蓝绿切换后，完成一致性校验，蓝只读，绿可写，约 5 秒内，reload ngx，实现快速切换。

4.3 完整的升级过程

结合我们对切换过程最佳实践的了解，可以使用 Q CLI 对整个升级过程做梳理，把相关工作按阶段划分，可以为我们生成清晰的 drawio 格式的升级与切换过程的展示。

在技术验证和方案整理上，Q CLI 是非常得力的助力，可以为我们提升数倍的工作效率。在生产集群的升级切换阶段，我们为了最大程度的过程可控性，仍然使用 Console 方式来实现集群的升级和切换。

4.3.1 开启 Binlog

如果在初次使用蓝绿部署，因为 Binlog 为静态参数，设置这个参数需要实例重启，请注意。

4.3.2 创建蓝绿部署

4.3.3 确认并创建

4.3.4 创建完成

4.3.5 修改绿实例类型

绿环境创建后，手动停止复制(CALL mysql.rds_stop_replication; show slave status\G)，记录复制位置信息，单独修改实例类型:

Plain Textaws rds modify-db-instance \--db-instance-identifier "green-cluster-instance-name" \--db-instance-class "db.r8g.large" \--apply-immediately

4.3.6 恢复 Binlog 同步

实例类型修改成功后，验证复制位置，手动启动复制(show slave status\G; CALL mysql.rds_start_replication;)验证数据同步后，安排窗口执行切换。

4.3.7 蓝绿集群切换

4.3.8 执行应用切换

根据 4.2 的方案，我们区分不同应用场景完成应用配置的 reload，此处需要确认应用操作的正确性。

4.3.9 删除旧集群

先关闭集群删除保护，使用以下命令或 console 完成旧集群的删除。

SQLaws rds delete-db-instance \  --db-instance-identifier aurora-test-304-traditional-instance-old1 \  --region us-east-1
aws rds delete-db-cluster \  --db-cluster-identifier aurora-test-304-traditional-old1 \  --region us-east-1 \  --skip-final-snapshot

4.4 升级过程中的关注点

我们在生产集群的升级切换当中，在同步环节曾经遇到 Relay Log 堆积的情况，我们借助于企业服务，在 TAM 的协助下，快速的定位原因，并实施的优化方案，这使同步延迟快速的解决，确保了应用切换前蓝绿集群可以达到同步状态。

4.4.1 同步延迟的优化

• binlog_transaction_dependency_tracking=WRITESET (源库跟目标库都要设置)

这个参数可以非常有效和提高复制效能：

a. 更精确地识别事务之间的依赖关系

b. 允许不相关的事务并行执行

c. 减少复制延迟

d. 改善并行复制

• aurora_binlog_replication_sec_index_parallel_workers=8

在 Aurora MySQL 3.06 及以上版本中，当复制具有多个二级索引的大表事务时，通过该特性引入线程池，在二进制日志副本上并行应用二级索引进行变更，有效提升同步速度

4.4.2 其它参数优化

• 关闭 Aurora 3.10 的新特性 Memory Relaylog ：aurora_in_memory_relaylog=OFF

避免绿实例报错：can’t find relay log

参数的功能描述请参考：https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/binlog-optimization.html

5.升级后的运行效果

我们在 9 月 9 号非常顺利的完成了 Aurora 数据库的切换，从按下来一周的系统负载数据看，CPU 负载和事务提交/DML 延迟都有近 50%的下降，这也和我们之前的技术验证结果完全吻合。

5.1 日间 CPU 高峰负载下降近一半(47%)

9 月 9 号 0 时，我们完成了数据库实例和 Aurora 3.10+Graviton4 机型的迁移，8 号与 9 号的业务负载模式其实是相同的(为工作日模式，7 号为周末模式)，所以从系统的峰值的变化可以得到引入 Aurora 3.10+Graviton4 带来的负载变化：CPU 的日间峰值从 8 号的 50%下降到 9 号的 27%左右，降幅为 47%；CPU 的凌晨高峰从 64%下降到 52%，降幅为 19%。

5.2 日间提交/DMLLatency 降低 50%

同样的，我们来看事务提交延迟，日间最大提交 Latency 从 8 号的 5ms 下降到 2.5ms，下降幅度为 50%，凌晨的最大提交 Latency 从 9 号的 27ms 下降到 5ms，下降幅度为 81%。

对于 DML 延迟也有相当明显的表现，日间最大 DML 延迟从 8 号的 2ms 下降到 1.7ms，下降幅度为 30%。凌晨 DML 延迟从 8 号的 3ms 下降到 1ms，下降幅度为 60%。

6. 回顾与总结

作为今年运维工作的重要部分，在过去的 2 个月，我们完成了对 Graviton4 的性能验证，生产业务模拟的切换验证，以及 Aurora 的版本选择和生产环境完成升级，而 Q CLI 也提供了直接或间接的支持。

6.1 Aurora 3.10 与 Graviton4 机型的综合表现

从最终的生产系统的负载信息，我们不难看出 Aurora 的 Graviton4 机型的引入相当明显把 CPU 使用率降低了 47%，事务提交和 DML 延迟也降低了近 50%，这意味着 Aurora 集群在成本没有显著增加的情况下，可以为业务提供近 1 倍的数据库计算能力。

Aurora 3.10 版本为业务提供了比常规版本更长期的支持周期，接近 3 年，这也意味着更少的停机时间，更少的业务中断和更低的运维成本。

6.2 TAM 与 Q CLI 在方案落地过程中的价值体现

在本项目中 Amazon Q CLI 以出色的架构感知和操控能力，相当大程度上加速了技术验证，版本分析，方案对比等工作：

• TAM 有力的支持 – 在技术验证和生产集群的切换期间，企业服务团队的 TAM 从前期的技术验证，到后期的切换过程的复制优化，体现了 TAM 自身扎实的技术能力，并且为客户发声，高效的协调前后端团队，提供了许许多多思路，解决了众多技术疑难问题；

• 性能与切换场景验证 – 在测试方案设计，方案补充，以及环境搭建，测试工具生成，测试数据分析与报告整理，Q CLI 可以提供非常好的协助，显著缩短测试周期，为生产切换做技术准备，让切换更有信心；

• 版本分析与建议 – Q CLI 可以更快速的从在线文档、Blog、What’s new、Pricing API 等官方资源、途径中提炼、汇总多方面的数据，形成完全适用于合合信息的版本建议，这节省了大量的人工查阅的时间，也提升了准确性；

• 数据分析与报告生成 – 我们可以使用 Q CLI 对多维度的测试数据进行分析，并且在架构图生成，流程图生成，分析报告呈现和渲染，这些工作上 Q CLI 都为我们大幅度提升了效率，也提升了交付物的质量；

6.3 未来探索 – Q CLI 在运维场景的应用

在本项目当中 Q CLI 在技术验证上是运维同学得力的助手，提升的效率，我们同时也会在以下运维场景中深度使用这个工具：

• 运维故障诊断 – 借助于 Q CLI 对亚马逊云科技资源的理解和强大的知识库支撑，加速运维故障分析与解决；

• 运维知识库 – Q CLI 提供了与 Bedrock KnowledgeBase 交互的 MCP Server 支持，可以将运维信息更充分的在团队内部分享；

• 运维工具开发 – Q CLI 提供了越来越丰富的代码编写支持，从 Todos/Hooks 到 Issue 的管理，降低运维开发门槛；

• 智能巡检 – 基于亚马逊云科技后端知识库，可以对生产、开发环境做深度的架构分析，发现更多可优化的技术项，提升运维水平；

以上是我们对 Q CLI 在未来运维价值的展望，相信熟练运用这些工具，会不断提升我们的运维水平、运维效率。

7.本文提到的技术资料链接

https://github.com/lvst-gh/qcli-aurora-graviton4/

*前述特定亚马逊云科技生成式人工智能相关的服务目前在亚马逊云科技海外区域可用。亚马逊云科技中国区域相关云服务由西云数据和光环新网运营，具体信息以中国区域官网为准。

本篇作者

本期最新实验为《Agentic AI 帮你做应用 —— 从0到1打造自己的智能番茄钟》

✨ 自然语言玩转命令行，10 分钟帮你构建应用，1 小时搞定新功能拓展、测试优化、文档注释和部署

💪 免费体验企业级 AI 开发工具，质量+安全全掌控

⏩️[点击进入实验] 即刻开启 AI 开发之旅构建无限, 探索启程！