法律行业软件公司 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 │ │
│ └─────┴─────┴─────┴─────┴─────┴─────┘ │
└─────────────────────────────────────────────┘
关键设计决策:
- 数据源直连而非数据搬运:Amazon Q Business 通过原生 connector 接入各系统,不需要先把数据 ETL 到 S3 再索引。这减少了数据同步延迟和维护负担。
- 权限继承:Q Business 继承各数据源的访问控制——工程师只能搜到自己有权限看的内容,不会因为统一搜索而泄露跨系统权限边界。
- 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)
运行前需要:
- 替换
APP_ID为你实际创建的应用 ID。 - 确保
userId对应的用户在 IAM Identity Center 中已注册且有数据源访问权限。 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 减少了幻觉概率,但不等于零幻觉。
上手清单
如果你也想在自己的运维环境中落地类似方案,建议按这个顺序推进:
- 盘点数据源:列出运维团队日常要查的所有系统,标注优先级。先接入最高频的 2-3 个(通常是工单 + 知识库 + 代码仓库)。
- 梳理权限:每个系统的访问控制模型是什么?哪些角色能看到哪些内容?把映射关系文档化。
- 创建 Q Business 应用 + 索引:用上面脚本的步骤,先搭一个最小可用版本。
- 小范围试跑:选 5-10 个工程师,用真实问题测试统一搜索的准确性和覆盖率。记录"搜不到"的案例,反推是数据源缺失还是索引配置问题。
- 接入文档自动化:搜索稳定后,再叠加 chat + 生成能力,从变更文档这种格式最固定的场景开始。
- 逐步扩展数据源:每接入一个新系统,重复权限验证和覆盖率测试。
统一搜索和文档自动化不是一次性项目,而是持续迭代的数据接入 + 权限治理 + AI 调优过程。Aderant 的 90% 和 75% 是在六套系统全部接入、权限模型梳理清楚之后才达到的数字。先从两套系统、一个场景开始,比一口气全铺更可靠。