Q CLI助力合合信息实现Aurora的升级运营

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上的技术验证。

2. Aurora升级的版本选择

在本次技术验证当中，我们需要对Aurora的版本信息，支持时间，以及引擎与R7g/R8g的兼容信息做整理。如果使用人工，这将是非常耗时，且容易出错的，但当我们配置AWS官方的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功能，借助于AWS Pricing API完成R8g OD/RI在各区域的覆盖情况确认，并借助于aws-knowledge-mcp-server补充相应的发布时间信息。

2.3 Q CLI辅助完成版本调研

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

Plain Text
我需要对Aurora和版本和r7g/r8g的兼容性做分析，以下是分析要求：
   - 基于AWS 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相关的语义识别
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 切换测试结论

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

业务的影响为14s，其中读操作的影响为9s，写操作的影响为14s，这说明如果应用可以有读写分离，在节点切换时将能提供更高的可用性；
在Aurora实例发生切换到DNS的IP映射真实切换之间，对于写操作都是不可用的，这期间的连接尝试也是无效和；
在DNS切换完成后写操作完全恢复正常，这表明DNS切换是应用恢复的唯一标记；

3.2.6 应用切换的优化

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

对于具备DNS检测的应用，它最终会通过DNS解析到新的IP，连接到新的实例；
对于没有DNS检测的应用，在切换发生后，将新的集群IP刷新给这些应用(reload或重启服务)，这些应用也会连接到正确的实例；
使用AWS官方的驱动程序或Wrapper插件实现集群拓扑感知，在第一时间获知IP改变，第一时间恢复连接；

官方的数据库驱动加速切换的原理，可以参考这篇博客《Demystifying the AWS 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指向的切换。。

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

Shell
1. 创建蓝绿部署
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. 升级绿环境实例到R8g
aws 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 – 原地升级

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

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

Shell
1. 升级引擎版本
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上支持。

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

Shell
1. 创建跨区域读副本(新版本)
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 Text
aws 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完成旧集群的删除。

SQL
aws 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对AWS资源的理解和强大的知识库支撑，加速运维故障分析与解决；
运维知识库 – Q CLI提供了与Bedrock KnowledgeBase交互的MCP Server支持，可以将运维信息更充分的在团队内部分享；
运维工具开发 – Q CLI提供了越来越丰富的代码编写支持，从Todos/Hooks到Issue的管理，降低运维开发门槛；
智能巡检 – 基于AWS后端知识库，可以对生产、开发环境做深度的架构分析，发现更多可优化的技术项，提升运维水平；

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

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

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

亚马逊AWS官方博客