Railyard 推出 MCP 服务器，让 Claude 接入部署日志排查失败发布

Almokhtar Bekkour，创始人、系统架构师 在你自己的服务器上跟着做。免费开始，无需信用卡 部署在最糟糕的时刻变红。修复通常只是一行，但要找到那一行，意味着打开部署页面、滚动 2000 行的构建日志、检查旧版本是否仍在提供服务，并在切换后的运行时日志中 grep 第一个错误。一个能读取这些相同来源的 agent 会在几秒内完成这一轮排查，并带着那一行回来。 本教程在 Railyard 上展示这个工作流：该问什么、agent 使用哪些工具、如何解读它发现的内容，以及何时回滚而不是向前修复。 将 Railyard 连接到 Claude。在 Claude 中，转到 Customize → Connectors → Railyard → Connect。在 Claude Code 中： claude mcp add --transport http railyard https://app.railyard.run/api/mcp 诊断只需要读权限。要让 Claude 也修复原因并重新部署，请以 deploy 权限连接；如果需要更改变量，则用 write 权限。 Railyard 的 MCP server 自带一个名为 debug_failed_deploy 的 prompt。在会显示 MCP prompt 的客户端中，从 prompt 菜单里选择它（在 Claude Code 中，输入 / 并查找 Railyard 的 prompt），填入应用名称，然后发送。它会指示 Claude： 本文其余部分就是手动完成同一工作流的过程，这样你就知道每一步会发现什么。 #1214 失败的 git_push a91c3e2 开始于 14:02，结束于 14:05 get_deploy 会补充记录的错误、触发者或触发原因，以及运行时长。错误行本身往往就能回答这个问题： error: "Release command failed: bin/rails db:migrate exited 1" 第 2 步：阅读构建和发布日志 deploy_logs 默认返回部署自身日志的最后 200 行，最多 500 行。真正的原因就在这里： == 20260729140122 AddIndexToOrdersEmail: migrating =========================== -- add_index(:orders, :email, {:unique=>true}) rails aborted! PG::UniqueViolation: ERROR: could not create unique index "index_orders_on_email" DETAIL: Key (email)=(sam@example.com) is duplicated. Claude 从中读出：这次迁移添加了唯一索引，而现有数据中存在重复。这是数据问题，不是代码笔误，而这会改变修复方式。 在 Railyard 上，部署失败会让上一个版本继续提供服务。在惊慌之前先确认这一点： 如果流量和错误率看起来正常，就没有火情。你有时间向前修复。 当原因很小且已理解时，向前修复，比如上面的重复数据。Claude 可以用只读查询展示重复项： SELECT email, count() FROM orders GROUP BY email HAVING count() > 1; 如何清理数据由你决定。这部分仍然归你。然后推送修复后的迁移并重新部署，或者让 Claude 用 deploy_app 和 ref 重新部署特定 commit。 当生产环境确实已经损坏时回滚，也就是说，一次糟糕的部署确实已经发出去了： 重新部署后，让 Claude 用 get_deploy 和 deploy_logs 跟踪它直到结束，然后重新运行第 3 步的健康检查。用 list_activity 收尾，它会显示部署、触发者或触发原因，以及任何变量变更。写事故记录时这很有用。 相关阅读：从 Claude Code 一步步部署，以及 MCP server 如何工作。