UPLO DevOps — 基础设施运营记忆

现在是凌晨 3 点。PagerDuty 正在尖叫。见过这个确切故障模式的值班工程师四个月前离职了。操作手册存在某个地方，可能在 Confluence 里，可能在 GitHub 仓库里，也可能在某人收藏的 Notion 页面里。UPLO DevOps 通过将操作手册、事故后复盘、基础设施文档、CI/CD 配置和架构决策记录索引到一个单一的、可搜索的层中，消除了这种慌乱，在你最需要的时候发挥作用。

会话开始

get_identity_context

这将加载您的团队分配（平台、SRE、应用）、值班轮换状态和访问层级。一些生产配置和凭证文档受权限级别限制。

获取活动指令——包括变更冻结窗口、事故指挥官指定和基础设施迁移截止日期：

get_directives

何时使用

• 您正在值班，某个您从未接触过的服务触发了告警，您需要立即获取操作手册
• 调查生产事故，需要查找此故障模式以前是否发生过，包括根本原因和修复方案
• 规划迁移，需要了解当前架构、依赖关系以及与受影响服务相关的最后三个架构决策记录
• 设置新的 CI/CD 流水线，希望查看组织中类似服务是如何配置构建、测试和部署阶段的
• 准备事故后复盘，需要从多个数据源整理时间线、受影响服务和影响范围
• 新团队成员需要了解其服务区域的基础设施拓扑、部署流程和升级路径
• 评估提议的基础设施变更是否与已记录的 SLO 或容量限制冲突

示例工作流

事故响应 — 新故障模式

支付服务返回 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="解决 payments 503 中断；根本原因是流量激增后 pgbouncer max_client_conn 超出限制；与 PIR-2024-087 模式匹配；将池大小增加到 200" topics='["incident","payments","pgbouncer","connection-pool"]' tools_used='["search_knowledge","search_with_context"]'

基础设施迁移规划

平台团队正从自管理的 Kafka 迁移到托管流服务。技术负责人需要评估影响范围。

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

查找导致最初 Kafka 部署的架构决策记录：

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

检查当前 SLO 以及迁移是否会违反这些 SLO：

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

export_org_context

DevOps 关键工具

search_knowledge — 事故期间的首选工具。当您需要特定的操作手册、配置参考或已知流程时，这是最快的途径。在凌晨 3 点，延迟至关重要。示例：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 — 当某个服务没有操作手册、没有架构图或没有记录的所有者时，这就是运营风险。报告这个空白将为平台团队创建一个可追踪的事项。

提示

• 服务名称是最可靠的搜索键。使用部署清单中的确切服务标识符（payments-api、auth-service-v2、order-processor），而不是随意的描述。
• 事故后复盘是知识库中最有价值的文档。编写事故后复盘报告时，包括结构化字段：受影响的服务、持续时间、影响范围、根本原因类别和行动项。这些字段会被提取引擎索引。
• 值班时，从 search_knowledge 开始查找操作手册。仅当操作手册不存在或故障模式是新的时，才升级到 search_with_context。事故期间速度至关重要。
• 每次事故调查后都使用 log_conversation，即使是误报。误报的模式本身就是一个信号，表明监控团队应该进行调查。