How we built an automation platform for 600+ managed servers

我是 Savvii 的 CTO，这是一家位于荷兰的托管托管服务公司。我们专注于基于 PHP 的网站——电子商务、WordPress 及类似工作负载——并服务于三类客户：小型客户、分销商和代理商。每一类都有不同的需求、不同的规模和不同的期望。

代理商这一客户群是我们感受到压力最大的地方。代理商是成熟的客户，但他们的内部团队往往是技术与非技术人员的混合体。他们需要一个图形界面。他们无法靠命令行生存。我们接入的代理商越多，一件事就越发明显： 我们需要一个由真正的自动化支撑的合适的控制面板。

Ansible Tower 及类似工具曾在我们的考量范围内，但它们要么设置过于复杂，要么文档不一致，要么带有性能和数据主权方面的顾虑。 我们想要一个可以自托管、升级时不会带来麻烦的东西， 并且能够移交给我们的支持团队，而无需一周的培训。

在做出任何决定之前，我们进行了一次全面的比较。有两个因素很快缩小了选择范围。

数据主权。 不接受任何会把状态或凭证存储在第三方云中的工具。自托管是不可妥协的。

面向非工程师的用户体验。 一线支持团队是优秀的沟通者，而非系统管理员。无论我们选择什么，都必须能够在不把每个事件升级给 DevOps 的情况下使用。我们评估的工具包括：

Semaphore UI 在这两方面都胜出。安装很简单。升级毫无痛苦。界面足够清晰，连非工程师都能理解正在发生什么。接入我们现有的 Ansible 清单几乎没有摩擦——唯一需要帮助的地方是连接清单，而这通过支持团队很快得到了解决。Semaphore 的文档很扎实，这给了我们信心。

最初的架构使用 n8n 作为 HostBill（计费）、Semaphore UI 和 CMDB 之间的编排层。在纸面上看起来很干净——低代码、可视化，无需开发人员维护。

n8n 的可视化界面对于简单的线性流程非常出色。但一旦条件判断、错误处理、多步回调和状态管理进入画面——全局视图就消失了。原本干净的图示变成了一块超现实主义的电路板。

我们用一个 Laravel 应用替换了 n8n。它是真正的中间件——不是无代码工具，而是我们团队完全拥有并理解的东西。

我们起步的代理商客户群，通过这套架构运行着约 600 台服务器。三类客户群的总体规模最终将达到 3,000 到 4,000 台服务器，我们正在逐步推广这一平台。

Semaphore 的调度器是下一个要上线的功能，用于服务器更新——目前由外部工具处理，但将转向由调度器驱动的 Ansible。

我们会做出的最大改变是： 在写下一行自动化代码之前，花更多时间进行架构设计。 我们不止一次从头再来，因为我们没有足够仔细地思考哪些流程能够扩展，以及哪些流程能够优雅地处理失败。