用 Amazon Q 统一六套系统搜索、自动化文档流程——Aderant 的云运维实践

2026-05-19 17 预计阅读时间:1 分钟
来源:aws.amazon.com AI 摘要 原文链接

免责声明:本文为 AI 摘要整理,建议结合原文阅读。摘要可能省略上下文、版本差异或边界条件,不作为官方说明。

预计阅读时间:11 分钟

法律行业软件公司 Aderant 运维团队每天要跨六套不同供应商系统查信息、写文档:工单在 ServiceNow,知识库在 Confluence,代码在 GitHub,资产台账在另一套 CMDB……搜索一个问题的完整上下文,往往要手动跳转多个平台,耗时数分钟甚至更久。文档编写更是重复劳动——同样的变更记录,要在不同系统里各写一遍。

他们用 Amazon Q Business(原文称 Amazon Quick)的 AI 能力,把六套系统的搜索统一到一个入口,并把文档生成流程自动化。结果是:搜索速度提升 90%,文档产出加速 75%。这篇文章拆解他们做了什么,以及你如何在自己的运维环境中复用这套思路。

痛点:碎片化系统里的"人肉胶水"

Aderant 的运维团队面对的典型场景:

  • 搜索碎片化:一个生产故障的根因可能横跨工单、日志、变更记录和知识库。工程师要分别登录六套系统,各自搜索,再人工拼凑上下文。
  • 文档重复:每次变更完成后,需要在 Jira 写变更记录、在 Confluence 更新知识库、在 ServiceNow 关联工单——三处内容本质相同,格式不同。
  • 响应慢:平均一次完整信息检索要 5-8 分钟,文档撰写要 30-45 分钟。

这不是个例。大多数中大型企业的运维团队都面临类似的"系统多、入口多、人工串联"问题。

解法:Amazon Q Business 作为统一智能层

Aderant 的核心架构并不复杂——用 Amazon Q Business 连接多个企业数据源,让 AI 在统一索引上做检索和生成:

┌─────────────────────────────────────────────┐
│           Amazon Q Business 应用             │
│  ┌─────────┐  ┌──────────┐  ┌────────────┐  │
│  │ 统一搜索 │  │ 文档生成 │  │ 对话式问答 │  │
│  └─────────┘  └──────────┘  └────────────┘  │
│                     │                        │
│          ┌──────────┴──────────┐             │
│          │   统一索引 + RAG    │             │
│          └──────────┬──────────┘             │
│                     │                        │
│   ┌─────┬─────┬─────┬─────┬─────┬─────┐     │
│   │ SNow│Jira │Conf │Git  │CMDB │Logs │     │
│   └─────┴─────┴─────┴─────┴─────┴─────┘     │
└─────────────────────────────────────────────┘

关键设计决策:

  1. 数据源直连而非数据搬运:Amazon Q Business 通过原生 connector 接入各系统,不需要先把数据 ETL 到 S3 再索引。这减少了数据同步延迟和维护负担。
  2. 权限继承:Q Business 继承各数据源的访问控制——工程师只能搜到自己有权限看的内容,不会因为统一搜索而泄露跨系统权限边界。
  3. RAG 而非纯生成:所有回答都基于检索到的真实文档片段,附带来源链接,避免 AI "编造"运维指令。

实践:搭建一个多源统一搜索应用

下面用 AWS CLI 和 boto3 演示如何创建一个 Amazon Q Business 应用并接入多个数据源。这是 Aderant 方案的简化版本,你可以直接改造运行。

前提条件:已配置 AWS CLI,有 qbusiness 相关权限,IAM Identity Center 已启用。

第一步:创建 Q Business 应用和索引

# 创建应用
aws qbusiness create-application \
  --display-name "ops-unified-search" \
  --identity-center-instance-arn "arn:aws:sso:::instance/ssoins-xxxxxxxxxxxxx" \
  --region us-east-1

# 记下返回的 appId,例如:appId=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

# 创建索引
aws qbusiness create-index \
  --application-id "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" \
  --display-name "ops-index" \
  --type ENTERPRISE \
  --region us-east-1

# 记下返回的 indexId

第二步:接入数据源(以 ServiceNow 和 Confluence 为例)

# ServiceNow connector
aws qbusiness create-data-source \
  --application-id "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" \
  --index-id "yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy" \
  --display-name "servicenow-incidents" \
  --data-source-type "SERVICENOW" \
  --configuration '{"servicenowConfiguration":{"instanceUrl":"https://yourorg.service-now.com","authType":"basic","secretArn":"arn:aws:secretsmanager:us-east-1:123456789012:secret:snow-creds"}}' \
  --region us-east-1

# Confluence connector
aws qbusiness create-data-source \
  --application-id "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" \
  --index-id "yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy" \
  --display-name "confluence-kb" \
  --data-source-type "CONFLUENCE" \
  --configuration '{"confluenceConfiguration":{"instanceUrl":"https://yourorg.atlassian.net/wiki","authType":"apiToken","secretArn":"arn:aws:secretsmanager:us-east-1:123456789012:secret:confluence-creds"}}' \
  --region us-east-1

注意:每个数据源的认证信息需要提前存入 AWS Secrets Manager。secretArn 指向包含用户名/密码或 API Token 的 Secret。

第三步:用 Python SDK 执行统一检索和文档生成

import boto3
import json

q_client = boto3.client("qbusiness", region_name="us-east-1")

APP_ID = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"

def unified_search(query: str, user_id: str = "ops-engineer@example.com"):
    """跨所有已接入数据源统一检索"""
    resp = q_client.search(
        applicationId=APP_ID,
        queryText=query,
        userId=user_id,
    )
    results = resp.get("results", [])
    for r in results:
        source = r.get("sourceAttribution", [{}])[0].get("sourceLocation", "unknown")
        snippet = r.get("documentExcerpt", {}).get("text", "")
        print(f"[{source}] {snippet[:200]}")
    return results


def generate_change_doc(change_id: str, user_id: str = "ops-engineer@example.com"):
    """基于检索结果自动生成变更文档草稿"""
    # 先检索关联信息
    context_parts = []
    for q in [f"change record {change_id}", f"incident related to {change_id}", f"KB article about {change_id}"]:
        results = unified_search(q, user_id)
        for r in results:
            context_parts.append(r.get("documentExcerpt", {}).get("text", ""))

    # 用 Q Business 的对话能力生成文档
    prompt = (
        f"根据以下运维上下文,生成一份标准变更文档草稿,包含:变更背景、影响范围、执行步骤、回滚方案。\n"
        f"上下文:\n{json.dumps(context_parts[:5], ensure_ascii=False)}"
    )
    resp = q_client.chat(
        applicationId=APP_ID,
        userId=user_id,
        userMessage=prompt,
    )
    return resp.get("systemMessage", "")


# 使用示例
if __name__ == "__main__":
    # 搜索某个故障的完整上下文
    print("=== 统一搜索 ===")
    unified_search("production database connection timeout last week")

    # 自动生成变更文档
    print("\n=== 自动生成变更文档 ===")
    doc = generate_change_doc("CHG-2024-0089")
    print(doc)

运行前需要:

  1. 替换 APP_ID 为你实际创建的应用 ID。
  2. 确保 userId 对应的用户在 IAM Identity Center 中已注册且有数据源访问权限。
  3. pip install boto3 已安装。

第四步:定时同步与文档自动化触发

数据源同步可以设置为定时触发,保持索引新鲜度:

# 为数据源创建定时同步计划(每6小时)
aws qbusiness update-data-source \
  --application-id "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" \
  --data-source-id "ds-servicenow-id" \
  --sync-schedule "cron(0 0/6 * * ? *)" \
  --region us-east-1

文档自动化可以对接 EventBridge——当 ServiceNow 中变更状态变为"Completed"时,自动触发 Lambda 调用上面的 generate_change_doc,把草稿推回 Confluence。

效果与边界

Aderant 报告的核心数据:

指标 改善幅度
跨系统搜索耗时 减少 90%(从分钟级降到秒级)
文档撰写耗时 减少 75%(从 30-45 分钟降到 7-10 分钟)

但需要注意几个现实边界:

  • 数据源覆盖率决定效果上限:如果某套关键系统(比如内部监控仪表盘)没有 connector,统一搜索就仍有盲区。Amazon Q Business 目前支持约 40+ 种原生 connector,覆盖主流 SaaS,但自研系统需要通过 API / S3 自定义接入。
  • 权限模型必须提前梳理:统一搜索放大了权限配置错误的影响。上线前务必逐系统验证:用不同角色账号测试,确认敏感内容不会越权露出。
  • 生成内容需要人工审核:变更文档草稿、故障总结等 AI 产出,必须经过工程师确认后才能正式发布。RAG 减少了幻觉概率,但不等于零幻觉。

上手清单

如果你也想在自己的运维环境中落地类似方案,建议按这个顺序推进:

  1. 盘点数据源:列出运维团队日常要查的所有系统,标注优先级。先接入最高频的 2-3 个(通常是工单 + 知识库 + 代码仓库)。
  2. 梳理权限:每个系统的访问控制模型是什么?哪些角色能看到哪些内容?把映射关系文档化。
  3. 创建 Q Business 应用 + 索引:用上面脚本的步骤,先搭一个最小可用版本。
  4. 小范围试跑:选 5-10 个工程师,用真实问题测试统一搜索的准确性和覆盖率。记录"搜不到"的案例,反推是数据源缺失还是索引配置问题。
  5. 接入文档自动化:搜索稳定后,再叠加 chat + 生成能力,从变更文档这种格式最固定的场景开始。
  6. 逐步扩展数据源:每接入一个新系统,重复权限验证和覆盖率测试。

统一搜索和文档自动化不是一次性项目,而是持续迭代的数据接入 + 权限治理 + AI 调优过程。Aderant 的 90% 和 75% 是在六套系统全部接入、权限模型梳理清楚之后才达到的数字。先从两套系统、一个场景开始,比一口气全铺更可靠。


相关推荐