UPLO DevOps — 基础设施的运行记忆

凌晨 3 点。PagerDuty 正在疯狂告警。曾处理过该故障模式的值班工程师已在四个月前离职。相关运行手册（runbook）可能散落在 Confluence、某个 GitHub 仓库，或某位同事收藏的 Notion 页面中。UPLO DevOps 通过将运行手册、事后复盘（post-incident reviews）、基础设施文档、CI/CD 配置及架构决策记录（ADR）统一索引，构建起一个可搜索的单一知识层——在你最需要它的时候，即刻响应。

会话启动

get_identity_context

该命令加载你的团队归属（平台组、SRE、应用组）、当前值班轮转状态及访问权限等级。部分生产环境配置与凭证文档受安全级别限制，仅授权人员可访问。

获取当前生效的指令集——包括变更冻结窗口期、事故指挥官（incident commander）指定名单，以及基础设施迁移截止时间：

get_directives

适用场景

• 你正在值班，某项从未接触过的服务触发告警，需立即调取对应运行手册
• 调查生产事故时，需确认该故障模式是否曾发生过，并追溯其根本原因与修复方案
• 规划基础设施迁移时，需厘清当前架构、服务依赖关系，以及与目标服务相关的最近三份 ADR（Architecture Decision Records）
• 搭建新的 CI/CD 流水线时，希望参考组织内同类服务在构建、测试与部署阶段的配置方式
• 准备事后复盘（post-incident review）时，需从多个数据源聚合事件时间线、受影响服务及影响范围（blast radius）
• 新成员入职后，需快速掌握所负责服务区域的基础设施拓扑、部署流程及升级路径（escalation paths）
• 评估某项拟议的基础设施变更是否与已记录的 SLO 或容量约束存在冲突

典型工作流示例

事故响应 —— 全新故障模式

支付服务（payments service）返回 503 错误，而当前值班工程师此前从未维护过该服务。

search_knowledge query="payments service 503 error runbook troubleshooting steps"

检查是否存在症状相似的历史事故：

search_with_context query="payments service outage 503 timeout database connection pool previous incidents root cause"

若运行手册建议检查数据库连接池，但当前配置不明确：

search_knowledge query="payments service database connection pool configuration pgbouncer settings production"

问题解决后：

log_conversation summary="Resolved payments 503 outage; root cause was pgbouncer max_client_conn exceeded after traffic spike; matched PIR-2024-087 pattern; increased pool to 200" topics='["incident","payments","pgbouncer","connection-pool"]' tools_used='["search_knowledge","search_with_context"]'

基础设施迁移规划

平台团队正将自建 Kafka 迁移至托管流式服务（managed streaming service）。技术负责人需评估影响范围（blast radius）。

search_with_context query="Kafka consumers producers services dependencies topic configuration"

查找最初选择 Kafka 的架构决策记录（ADR）：

search_knowledge query="architecture decision record ADR Kafka event streaming selection rationale"

核查当前 SLO 要求，并判断迁移是否会违反其中的延迟或吞吐量指标：

search_knowledge query="event streaming SLO latency throughput requirements Kafka p99"

export_org_context

DevOps 核心工具

search_knowledge —— 事故响应期间的首选工具。当你需要一份特定运行手册、某项配置参考或已知操作流程时，这是最快捷的路径。凌晨三点，延迟至关重要。示例：search_knowledge query="redis cluster failover runbook manual promotion steps"

search_with_context —— 适用于深度调查与前瞻性规划。“哪些服务依赖该数据库？”或“该故障是否曾发生过？”这类问题需跨越服务、事故与基础设施组件之间的关联关系进行检索。示例：search_with_context query="auth-service dependencies upstream downstream database cache"

get_directives —— 变更冻结窗口期、事故升级策略及迁移截止时间等关键指令均在此呈现。执行生产变更前务必调用此命令——一次疏忽可能酿成职业风险。

flag_outdated —— 基础设施文档的老化速度远超其他类型文档：上季度记录的 Kubernetes 集群版本已失效；网络拓扑图中仍显示已被下线的负载均衡器；运行手册中引用的 CLI 工具早已被替代。请主动标记所有过时内容——总有人会在事故中依赖它们。

report_knowledge_gap —— 若某项服务缺失运行手册、架构图或未明确负责人，则构成明确的运维风险。上报此类知识缺口，将自动生成一条可追踪事项，交由平台团队闭环处理。

使用提示

• 服务名称是最可靠的搜索关键字。请始终使用部署清单（deployment manifests）中的精确服务标识符（如 payments-api、auth-service-v2、order-processor），而非口语化描述。
• 事后复盘（PIR）是你知识库中价值最高的文档。撰写 PIR 时，请包含结构化字段：受影响服务、持续时间、影响范围（blast radius）、根因分类（root cause category）及待办事项（action items）。这些字段将被抽取引擎自动索引。
• 值班期间，请优先使用 search_knowledge 查找运行手册；仅当手册缺失或故障模式为全新时，再升级使用 search_with_context。事故响应中，速度就是生命线。
• 每次事故调查（含误报）结束后，请务必调用 log_conversation。误报频次本身即是一类信号，应交由监控团队进一步分析。