CNPG 扩展目录：Cluster 清单只需写扩展名

CloudNativePG 的 ClusterImageCatalog 现在能随操作数镜像一起携带扩展镜像，当前所有受支持版本均已具备此能力。Cluster 清单只需声明扩展名，其余全部由 operator 解析。

本配方部署社区扩展目录，演示 operator 如何按 PostgreSQL 主版本从单一版本化来源解析 pgvector 的镜像、路径与依赖。扩展一旦进入目录，所有引用该目录的 Cluster 自动继承，无需再改任何清单。

前置条件与 Recipe 23 相同，但有一处变化：ImageVolume 已在 Kubernetes 1.35+ 默认启用并正式可用，1.33/1.34 需手动开启特性门控。容器运行时需 containerd 2.1.0+ 或 CRI-O 1.31+。扩展目录功能自 CloudNativePG 1.29 起可用，当前 1.29 和 1.30 均支持。PostgreSQL 18 提供 extension_control_path，低于 18 的主版本社区不提供此机制。

部署社区扩展目录只需一条命令：
kubectl apply -k GitHub

该 kustomize 目标将 extensions 数组补进 Debian Trixie 和 Bookworm minimal 目录的对应主版本条目。目前仅 PostgreSQL 18 条目带 extensions 数组，因为 extension_control_path 是 18 的特性。PostGIS 的 ld_library_path 和 env 覆盖直接打包在目录条目里，无需在每个 Cluster 重复配置。

使用目录后，Cluster 清单从显式 image.reference 简化为：
imageCatalogRef 指向 postgresql-minimal-trixie 的 major 18，postgresql.extensions 只需写 - name: pgvector。operator 从目录条目解析镜像、ld_library_path、extension_control_path 和 dynamic_library_path。需要单独覆盖时仍可在 Cluster 本地覆写，目录值只是默认值而非锁定。

验证方式：检查 /extensions 目录挂载、用 \dx 确认扩展激活，以及通过 status.pgDataImageInfo 查看 operator 从目录解析出的实际镜像引用。

架构意义在于：Recipe 23 已解耦 PostgreSQL 核心与扩展二进制，但 Cluster 清单仍需显式写镜像引用。目录机制把扩展分发变成真正的生态——扩展进入目录后，所有引用 Cluster 免费继承，清单永不需再改。

#DevOps #运维 #CloudNativePG #PostgreSQL #Kubernetes #K8s #pgvector #ClusterImageCatalog #ImageVolume #Postgres18
@DevOpsTalkCN

AWS DevOps Agent 接入 ServiceNow，实现故障自动调查与处置

AWS 官方博客介绍了如何将 AWS DevOps Agent 与 ServiceNow 集成，通过 MCP 协议打通 ITSM 流程与自动化事件响应。核心价值在于：当 ServiceNow 产生 incident 时，Agent 自动关联 CloudWatch 遥测、部署数据和代码变更，完成根因分析并把结论写回工单，同时通过受治理的 Action Fabric 执行授权操作（如创建变更请求）。

对运维团队来说，这解决的是跨系统人工关联数据的痛点——以往工程师需要在 AWS、可观测性工具和 ServiceNow 之间来回切换，手动比对信息才能定位问题，MTTR 自然被拉长。集成后，SRE 接手工单时已自带根因分析和影响范围，triage 时间能明显缩短。

集成要点如下：

• 认证：AWS DevOps Agent 与 ServiceNow 之间走 OAuth 2.0，带 scoped Permissions，每次工具调用都在工具和技能级别鉴权，并留有可审计轨迹

• 工具治理：ServiceNow MCP Server Console 负责暴露和管理工具（incident 读写、CMDB 查询、变更请求创建等），通过 ACL 和角色掩码限制 Agent 权限

• 动态发现：Agent 作为 MCP 客户端，运行时动态发现 ServiceNow 暴露的工具，可基于 NowAssist Skills 创建

• 触发方式：支持手动对话测试，也可在 ServiceNow 创建 Business Rule，incident 创建时自动触发 Agent 调查

配置流程分三步：先在 ServiceNow 实例的 MCP Server Console 创建 Server 并配置工具和入站 OAuth；再在 AWS 控制台创建 DevOps Agent Space 并配置 IAM 角色；最后在 Agent 控制台的 Capability Providers 中注册 MCP Server 端点，选择需要的工具即可。

这套方案适合已经在用 ServiceNow 做 ITSM、且应用跑在 AWS 上的团队。前置条件是 ServiceNow 实例需具备 AI Native 订阅（Foundation、Advanced 或 Prime）或独立 MCP 插件，Agent 侧需要创建 Space 和对应 IAM 角色。安全模型上，ServiceNow 不只是存储 Agent 输出，而是实际控制和执行授权操作，AI Control Tower 可观测全部调用记录。

#DevOps #运维 #AWS #ServiceNow #MCP #ITSM #自动化运维 #AIOps
@DevOpsTalkCN

Postgres 19 语法糖盘点：DO SELECT、GROUP BY ALL 与 COPY JSON

Postgres 19 带来了一批不起眼但实用的语法改进。作者梳理了三个最值得关注的变化：ON CONFLICT DO SELECT 终于支持 get-or-create 语义，GROUP BY ALL 免去手动罗列分组列，COPY 新增 JSON 格式输出。这些改动单看每条只省几行 SQL，但累积起来能省下大量样板代码。

先说 ON CONFLICT DO SELECT。过去想实现"插入新行，若冲突则返回现有行"，只能靠 DO UPDATE 做一次无意义的更新来触发 RETURNING，这会产生多余写入、膨胀表并消耗 tuple。Postgres 19 新增 DO SELECT 子句，冲突时直接返回已存在的行，无冲突时正常插入并返回新行，一次语句两种结果。它还支持 FOR UPDATE、FOR SHARE 等行级锁，可在事务中锁定返回的行防止并发修改；可选 WHERE 条件过滤返回结果。注意两点：该语句需要表的 SELECT 权限而非仅 INSERT，且 RETURNING 子句必填。

其次是 GROUP BY ALL。它自动收集 select 列表中所有非聚合表达式作为分组键，计算表达式和窗口函数也会被正确处理——窗口函数与聚合一样被排除在分组推断之外。缺点是可能"过于好用"：当 select 列表变化时，结果集会悄悄多出列而不是报错，下游按位置解析的脚本可能踩坑。

最后是 COPY 的 JSON 格式。新增 FORMAT json 选项，默认输出 newline-delimited JSON，每行一个完整对象，适合流式处理。支持列名列表限定键，嵌套数据（数组、对象）自动转为真正的 JSON 结构，无需字符串拼接。新增 json_array 参数可将整体输出为单个 JSON 数组，配合 psql 的 \copy 也能直接生成合法 JSON 文件，全程无需应用层代码。

三个特性中，GROUP BY ALL 可能是日常收益最大的——以后增删 select 列时再也不用同步改 GROUP BY 子句，一类语法错误直接消失。Postgres 19 目前处于 beta 阶段，值得提前试用。
@DevOpsTalkCN

DRA 来了，HAMi 还活着吗

Kubernetes 的 GPU 共享一直靠绕路实现。设备插件接口只能数整卡，nvidia.com/gpu: 1 就是全部词汇——要么整卡，要么没有。HAMi 用一整套旁路管道（mutating webhook、调度器扩展、注解、容器内强制）来表达 API 表达不了的事：给这个 Pod 8000 MiB 显存和 10% 算力，并且让限制真正生效。

DRA 在 v1.34 GA、v1.35 起默认锁定。consumable capacity 功能让 Pod 能直接向调度器要设备的一部分内存，原生支持，不再需要注解。HAMi 的维护者把这视为收敛而非竞争：上游 Kubernetes 采用了这个绕路方案一直在实现的模型。

核心 DRA 本身不提供 HAMi 式共享。它的基础共享模型是多个 Pod 引用同一个 ResourceClaim，共享同一份分配，而不是各自拿到有记账的切片。真正对应 HAMi 模型的是 consumable capacity，v1.34 引入 alpha，v1.36 起 beta 且默认开启。它加了两样东西：驱动可标记设备允许 allowMultipleAllocations，声明独立 claim 可同时落在同一设备上；claim 可携带容量请求，按命名资源要具体数量而不是整台设备。调度器对 GPU 内存做它一直对节点内存做的事：记账，保证授予容量总和不超过设备通告值。HAMi 的 nvidia.com/gpumem: 8000 变成对内存的容量请求，nvidia.com/gpucores: 10 变成对算力的容量请求，调度器扩展的过滤步骤变成上游调度器自己的计算，CardInsufficientMemory 变成标准的不可调度 claim。

调度只是半个问题

DRA 是承诺跟踪器，保证调度器不超卖，但不管容器在运行时违约。CUDA 不认 ResourceClaim，一个贪婪的 cudaMalloc() 循环就能抢走邻居在等的显存。强制是 HAMi 的第二份工作，在 HAMi-core 里：一个预加载进容器的 C 库，拦截 CUDA 和 NVML 调用，从用户空间执行授予的限制。给两个 Pod 各 8000 MiB，让一个故意超限分配，越界者会在正好 8000 MiB 处拿到 CUDA OOM，邻居不受影响——即使物理卡还有空闲显存。这是软件强制，靠库拦截实现，但每个容器独立限额，正是多团队共享集群需要的。

HAMi 的应对是拆分：保留强制部分，把编码部分重建在 DRA 之上，跨 3 个仓库推进。2026 路线图把完整 DRA 标准适配列为目标。生产环境跑 DRA 栈今天还需要哪些组件，素材里没展开，但方向已经清楚：调度归上游，强制留 HAMi。

#DevOps #运维 #Kubernetes #DRA #HAMi #GPU #CUDA #CNCF #调度器 #资源管理
@DevOpsTalkCN

Shadow AI 威胁建模：从开发者笔记本到 K8s 的完整路径

AI 工具进入软件交付的速度往往快于安全架构的更新，这个空档就是 Shadow AI——未经正式批准、无归属、无风险评估、无监控的 AI 工具、模型、代理或集成。对平台和安全团队而言，这不是"开发者用聊天机器人"的问题，而是访问控制问题：不受治理的 AI 可以触达源码、密钥、客户数据、云环境和部署流程。一旦 AI 被允许调用工具并采取行动，它就不再是生产力软件，而是变成拥有权限、爆炸半径和威胁模型位置的非人类身份。

本文对一条典型的云原生交付路径做威胁建模，从开发者笔记本到 Kubernetes Pod 中的工作负载，逐阶段映射可落地的控制措施，全部基于 CNCF 和开源项目。

风险从"建议"升级为"行动"时急剧上升

只给代码建议的助手，风险是数据越界或错误建议被无审查信任；而持有 Git token、云凭证或 K8s ServiceAccount 的代理，则能高速创建、修改、删除资源，Kubernetes 不会区分攻击者的恶意操作和过度授权的自动化身份。需要回答的是操作性问题：哪些 AI 工具在用？它们接收什么数据？能触达哪些系统、持什么权限？每个代理的归属人是谁？行为异常时能否立即撤销访问？可行的模型是：每个代理有明确的人类负责人，注册为可识别的工作负载，按最小权限约束，并监控实际行为。

各阶段攻击路径与防御控制

1. 开发者笔记本：开发者安装 AI 编码扩展，或将含 API token、内部主机名、客户标识的错误日志粘贴到公共服务，组织即失去对专有数据流向的可见性。另一风险是助手建议的依赖或命令未经验证就被信任。

防御：提供经批准的 AI 工具让使用可见，全面禁止反而会将其推向更隐蔽处。配合 pre-commit 密钥扫描（如 gitleaks 作为 git hook），确保 token 不进入共享面；强制签名提交。Gitsign（Sigstore 项目）用短期、基于身份的证书替代长期 GPG 密钥，使"谁产生了这个变更"可审计，包括代理作者。需要自主运行命令的代理应隔离在一次性 VM 工作区：代理拥有独立内核和文件系统，宿主的 SSH 密钥、云凭证文件、仓库检出都不在其中。代理被操纵做破坏性操作时，直接丢弃环境即可止损。

2. 源码控制：未批准的 AI bot 以过宽权限接入 Git 主机，可读所有仓库、评论 PR、建分支或推代码。集成 token 被盗，或 bot 被恶意 issue/PR 描述操纵，可引入不安全变更或泄露仓库内容。

防御：每个 AI 集成有具名负责人、独立身份、最小仓库范围和短期凭证。只审查单团队代码的代理不应持有组织级仓库访问权。所有合并需审查门禁和来源追踪，代理生成的 PR 视同不可信贡献者：强制人工审查，禁止自我批准。

3. CI 流水线：CI 持有源码控制 token、仓库凭证、云密钥和签名密钥等最强凭证。检查构建日志、生成脚本或自主"修复"失败构建的 Shadow AI 能力，会成为不受治理的特权操作者。藏在源码、README 或构建日志中的提示注入载荷可改变其行为。

防御：长期密钥不进入提示词、日志和构建环境。AI 相关任务在隔离环境中运行。

4. 制品仓库：AI 辅助选择镜像或依赖，可能将易受攻击、恶意或不可追踪的依赖带入生产。

防御：对制品来源和完整性做验证，建立依赖的可追溯性。

5. CD 平台：AI 代理批准、修改或发布版本，可能绕过变更控制、产生未授权部署、缺乏可追溯性。

防御：变更审批保留人工环节，发布流程记录完整审计轨迹。

6. Kubernetes 运行时：代理查询集群、修复告警、扩缩工作负载，可能因过度授权的 ServiceAccount 造成破坏性操作或横向移动。

防御：ServiceAccount 按最小权限配置，代理行为全程监控，异常可即时撤销。

威胁模型核心

需保护的资产：源码和专有算法、API 密钥和证书、客户和员工数据、CI/CD 配置和签名密钥、云和 K8s 身份、镜像和供应链完整性、生产可用性和声誉。

威胁者通常不是恶意内部人员，而是善意工程师为提速采用工具，攻击者利用由此产生的盲区。
相关角色：
• 针对暴露 AI 集成或窃取凭证的外部攻击者
• 滥用治理不善权限的恶意内部人员
• 被攻陷的第三方或 AI 工具提供商
• 用提示注入操纵代理的攻击者，以及因指令模糊
• 上下文不安全或权限过大而误操作的合法代理

提示注入是贯穿主线。代理经常读取不可信内容：issue 描述、README、依赖变更日志、构建日志，任何内容都可能引导代理泄露数据或采取不安全行动。因此仅靠提示过滤永远不够，纵深防御才是正解。OWASP 关于 AI 代理和 LLM 应用的指南是这些失败模式的良好基线。

关键原则：给每个代理一个人类负责人，注册为可识别工作负载，最小权限约束，监控实际行为。代理拥有广泛自主权时，不应直接运行在持有凭证的机器上。防御纵深而非单一控制，是应对 Shadow AI 的根本思路。

#DevOps #运维 #ShadowAI #CICD #Kubernetes #安全 #威胁建模 #Sigstore #gitleaks #供应链安全
@DevOpsTalkCN

PostgreSQL ACE 张晨：为什么敢自称“数据库恢复专家”

成为 PostgreSQL ACE 后，张晨解释了“PostgreSQL 数据库恢复专家”这个头衔的由来，以及 PDU 如何从离线抽取、WAL 挖掘，演进到碎片扫描和无数据字典恢复。

为什么敢自称专家

在西安邮电大学的活动中，张晨被问到“这么年轻怎么敢自称专家”。他的回答是：当你在某个领域相信没人做得比你好，直到有人站出来挑战你，就可以自称专家。目前还没有人在 PostgreSQL 非常规恢复领域质疑他的专业能力，所以他继续使用这个头衔。

PostgreSQL 非常规恢复缺什么

Oracle、MySQL、SQL Server 的恢复都有大量从业者，淘宝一搜一大把。PostgreSQL 非常规恢复则尴尬得多——很多人不知道哪些场景可恢复、哪些不可。网上搜相关场景，多数文章只是工具展示：罗列开源工具，告诉你什么情况试哪个。但准确率呢？可靠性呢？坦率说，没什么可夸的。大多数工具从数据库内核视角设计，很少有人真正考虑用户处境：事故现场实际发生了什么、还剩多少数据、如何判断能否恢复、如何有信心地导出尽可能多的数据。

为什么长期被忽视

主要原因是缺乏商业激励。PostgreSQL 用户既没有 Oracle 用户成熟的付费意愿，也没有 MySQL 在 LAMP 时代积累的海量用户。需求有限，自然缺乏持续投入的动力。张晨 2025 年初进入这个领域时，PostgreSQL 非常规恢复仍依赖社区开源生态的无序生长，没有真正属于它的方法论。

PDU 的演进

PDU 一步步走来：先是离线数据抽取，然后通过 WAL 数据挖掘恢复，最后是碎片扫描恢复和无数据字典恢复。张晨把遇到的案例、犯过的错误、可复用的经验都融入了 PDU。

开源、竞争与真正的壁垒

前两个能力已开源免费供大家使用。这确实会帮助潜在竞争者，但张晨从 PostgreSQL 开源生态受益良多，愿意回馈社区让良性循环继续。当然，自称专家也要留些核心技术在手——他确信在磁盘碎片扫描和无数据字典恢复方面，社区目前没人做得比他好。如果社区外有高手已经掌握这些技能并默默赚钱，他乐意私下交流切磋。

PDU 开源仓库：GitHub

#DevOps #运维 #PostgreSQL #数据库恢复 #PDU #WAL #数据救援 #开源
@DevOpsTalkCN

PostgreSQL 的 integer_datetimes：一个永远为 on 的参数

每个 PostgreSQL 连接在握手时都会收到服务器宣告的 integer_datetimes 参数。自 10.0 起，这个参数只有一个可能的值：on。它是个只读的预设参数，报告日期/时间类型的内部表示方式。

timestamp 和 timestamptz 用 64 位整数存储，从 2000-01-01 午夜起按微秒计数，整个范围内精度都是微秒级。替代方案是双精度浮点，从同一纪元起按秒计数——浮点数和计时是糟糕的组合：精度在纪元附近是微秒级，越远离越差，而且大多数秒的小数部分没有精确的二进制表示，导致算术运算时数值偏移，不同路径计算的 timestamp 做相等比较全靠运气。

整数格式在 7.x 时代作为编译选项引入，8.4 成为默认构建方式，10.0 时 Tom Lane 移除了 --disable-integer-datetimes，成为唯一选项。提交信息说得很直白：复制协议把时间戳字段定义为整数，浮点构建上转换代码有多个 bug，内部浮点泄漏到线上字段，而没人发现说明根本没人跑浮点构建。

那为什么每个客户端还要被告知这个参数？答案是二进制线上格式。文本模式下 timestamp 是字符串，没人关心服务器怎么存；二进制模式下，线上 8 字节就是存储格式——int64 微秒，或曾经的 float8 秒。客户端猜错不会报错，只会得到错误的时间戳。服务器在连接开始时就通过 ParameterStatus 消息声明 integer_datetimes，二进制驱动的解码器据此选择。

旧格式唯一还能咬人的地方是 pg_upgrade：它比较两个集群的 pg_controldata 中 "Date/time type storage" 行，不匹配就拒绝运行。今天构建的集群全是整数格式，幸存下来的浮点构建集群（8.4 前手工编译，或 10.0 前用逃生舱构建）完全无法 pg_upgrade，只能 dump 和 restore。

这个参数没有可设置、可监控的东西。它存在是因为 8.0 协议承诺了它，驱动在解码二进制 timestamp 前仍会检查；移除它会破坏工作正常的客户端，只为省几字节启动流量。所以每次连接仍以服务器郑重宣告一个 2017 年就结束的争论结果开场——答案是 on，而且永远是 on。

#DevOps #运维 #PostgreSQL #数据库 #参数解析 #协议兼容 #pgupgrade
@DevOpsTalkCN

选错分区键，PostgreSQL 分区白做

分区常被当成性能开关：大表一分，慢查询就快了。但有一种情况是，你费劲把大表拆成干净的分区，慢查询却依旧慢。表是分区了，什么都没变好。这时候，问题几乎总出在分区键上。

分区机制本身不难，PostgreSQL 处理得很好。选哪一列做分区键才是关键决策，而且表一大，这个决定基本无法回头。核心就一句话：分区裁剪只在查询过滤分区键时才生效。键选对了，PostgreSQL 只读一个小分区；选错了，它照样读全表，只不过现在是读散落在众多子表里的全表，可能比原来那张大表还慢。

所以真正的问题不是"该不该分区"，而是"我的重要查询过滤什么列，能不能按它分区"。提交前快速自查：拉出表上最频繁、最昂贵的十条查询，看 WHERE 子句。如果几乎都过滤同一列或同一小组列，那就是候选键；如果过滤十种不同列，分区只会帮到其中一部分查询，对其他的毫无作用。

Hash 分区是重灾区。它的卖点是均匀分布：取一个多值的列做 hash，PostgreSQL 把行分散到固定数量的分区。但关键不是不同值的数量，而是行在这些值上的分布。多租户 SaaS 表里可能有几百个租户，看着分布很好，但真实客户群是倾斜的——少数大租户产生大部分行。Hash 按值分布，不按数据量分布，于是几个大租户被 hash 进两三个分区，堆了 80% 的数据，其余分区几乎空着。你做了分区的工作，却保留了本想消除的热点。

Hash 只在键天然均匀时是好工具：UUID 主键、无业务含义的代理 ID、真正均匀分布的客户 ID。在倾斜列上，它只分散了标签，没分散负载。

修正倾斜键的办法不是更聪明的 hash，而是选一个与表实际查询方式、数据增长方式对齐的键。两种模式覆盖大部分真实场景：无自然顺序的均匀分布用 hash 均匀键；按时间查询、随时间增长的表用 range 时间戳分区。时间序列和事件负载里，按时间 range 分区还能让老化数据变成廉价的分区删除，而不是一次 I/O 密集的 DELETE。

分区键不是普通调优旋钮，而是 schema 承诺。加一个新 range 分区很容易，可以用 pg_partman 建规则或计划。但改 hash 分区数量是另一回事：模数（hash 桶数量）决定了每个现有行的位置，改了就得重排所有行，意味着复制整张表，通常要停机或做复杂的在线迁移。换分区列更是整表重建。表小的时候便宜，等它攒了几十亿行再改就痛苦了——而这恰恰是最需要分区正确的时候。

提交前过一遍清单：确认前十查询过滤你计划分区的列；检查候选键上的实际数据分布，别只看不同值数量；按访问模式匹配策略——均匀键用 hash，时间驱动用 range，小固定类别集用 list；在数据量有代表性的生产环境副本上测试，一万行的行为说明不了十亿行的行为；分区数量控制在几十到几百个，几千个小分区会带来自己的规划器和维护开销。

键选对了，换来的是几年的余量：查询快、归档便宜、能一个分区一个分区地做维护。选错了，换来一次迁移。好在这是可判断的决策，不是猜——工作负载告诉你键，数据分布告诉你策略，真实数据量的测试告诉你对不对，而且是在表还小、答案还便宜的时候。
@DevOpsTalkCN

把团队知识库接进 IDE：Kiro 用 MCP 连 Bedrock Knowledge Bases

开发时查架构决策记录、API 规范或编码标准，通常要切到 wiki 搜半天，再切回编辑器改代码，一次上下文切换就是十几分钟。Kiro 这个 agentic IDE 通过 MCP 协议把 Amazon Bedrock Knowledge Bases 接进编辑器，让开发者直接用自然语言查团队文档，答案带引用来源。

这套方案解决四个具体问题：上下文切换（不用离开编辑器查文档）、知识碎片化（文档散落多个系统）、新人生效慢（熟悉文档结构要几天）、合规滞后（代码评审时才暴露规范违反）。

实现上，官方 awslabs.bedrock-kb-retrieval-mcp-server 做桥接：Kiro 通过 MCP 连本地子进程，服务端调用 Bedrock Knowledge Bases 的 Retrieve API（不是 RetrieveAndGenerate），用 Titan Text Embeddings v2 做向量检索，返回带引用的段落。

已有 Knowledge Base 的团队不用重建，给现有 KB 打上 mcp-multirag-kb=true 标签，MCP 服务器会自动发现，多个 KB（API 文档、架构决策、runbook）可以一起打标，Kiro 跨库查询。从零开始的话，示例仓库提供完整 AWS CDK 应用，一键部署 S3 存储桶、OpenSearch Serverless 向量库和 Bedrock Knowledge Base，几分钟搞定。

典型场景：问"我们的错误处理模式是什么"直接返回团队定的异常类结构；问"Orders API 要什么认证"直接给出 OpenAPI spec 里的 JWT scope 和限流要求；还能在 CI/CD 里用 Kiro CLI 跑无头查询，PR 评审时自动校验代码是否符合安全规范。

Kiro 自带的 Steering 文件（静态项目规则）和 Agent Skills（工作流指引）管行为，Knowledge Bases 存组织知识，MCP 是连接层——三者分工不同，这套方案是互补不是替代。适合文档量大、靠人记不住的团队。

#DevOps #运维 #Kiro #MCP #Bedrock #KnowledgeBases #RAG #Amazon #IDE #向量检索
@DevOpsTalkCN