2026 看板协作服务器租用测评：Planka 与 Focalboard 资源模型 8 项对比 + 避雷攻略

2026 看板协作服务器租用测评：Planka 与 Focalboard 资源模型 8 项对比 + 避雷攻略

自建看板这件事，几乎每一个中型团队都会经历一次：先用 SaaS，觉得数据在别人那里不放心，或者觉得按人头收费不划算，于是找一台服务器，把 Planka 或 Focalboard 装上。装机过程通常半小时就结束了，真正的麻烦在三个月以后——有人反馈「早上打开看板要转十秒」，有人在群里说「拖卡片拖不动」，运维登上去看，CPU 不高、内存不满、磁盘也没爆，一切指标看起来都正常。这类故障最后追下去，八成不是硬件不够，而是资源模型从一开始就估错了方向。

估错方向的根源在于一个普遍的心理惯性：大家习惯用「注册用户数」去推服务器规格。这套逻辑在 OA、在邮件系统里勉强成立，在自建看板里几乎完全不成立。注册用户数只决定了用户表里有多少行，一行用户名加一个密码哈希，几百字节而已，五百人和五千人对硬件的差别小到可以忽略。真正在吃资源的，是另外三件事：某一刻同时打开看板的人数、这些人维持的常驻长连接数、以及两年下来堆在磁盘上的附件。这三件事的量级，和注册人数完全不成比例。

下面这份测评不谈功能清单，只谈资源模型。把 Planka 和 Focalboard 这两个代表性实现拆开，看清楚服务器的每一个核、每一 GB 内存、每一个文件描述符到底被谁占着，再给出可以照着算的估算式与临界点。文中所有数字都是经验区间与工程估算，不是跑分实测；真实项目里请按自己的并发形态再打折或加码。

看板系统的第一变量是「同时打开的板」

先给一个具体的场景，把抽象的数字落到实处。一家五百人规模的产品公司，研发、设计、运营加起来注册了四百多个账号，其中真正每週会用看板的人大概三百人。如果按「四百人」去选服务器，很容易一口气上到十六核三十二 G，实际用起来发现资源闲置一大半。反过来，如果按「早上十点早会结束后同时打开看板的人」去算，答案会完全不同：那个时间窗口里，同时在线的可能只有六十到八十人，其中一半人只开着浏览器标签并没有在操作。

为什么「同时打开」才是第一变量？因为看板类系统的交互模型是「页面一直开着」。用户打开一个板，就是为了盯着它看，一边开会一边拖动卡片，一边等别人更新。页面不会像报表系统那样查完就关，它会挂在那里一上午。挂着的页面要维持和服务端的联系，要么靠一条长连接推送事件，要么靠定时轮询拉增量。无论哪种，服务端都要为这个「还开着」的状态保留内存、文件描述符和一份订阅关系。人走了，标签页不关，这条连接就一直存在。所以看板的负载曲线和工作时间高度重合，中午吃饭时会掉下去一截，晚上八点以后接近归零。

这里给一个可以直接套用的估算：经验区间上，一个团队的活跃用户中，任意时刻真正打开着看板页面的比例大约在百分之八到百分之十五之间，早会前后、迭代评审当天会冲到这个区间的上沿；每个人平均会开一点二到两个标签页或者同时开手机端，折算下来连接数大约等于同时在线人数乘以一点五。五百人的团队，按百分之十二的同时在线比例估算，是六十人，乘一点五，大约九十条常驻连接。这个数字听起来很小，但它对应的内存占用和连接管理开销，已经足够决定你该选两核还是四核。

把这个估算再往前推一步：如果你服务的不是一个团队，而是一个集团下的十几个事业部共用一套看板，注册人数可能到三千，但同时在线的高峰依然集中在每天上午十点和下午两点两个窗口，峰值连接数大概在三百到五百条之间。这种情况下真正需要重新计算的不是 CPU，而是重连处理和附件磁盘。判断规则可以写得很直白：先去问「你们早会几点开、开多久、开会时是不是所有人都盯着同一个板」，这个答案比注册人数有用十倍。

Planka 的形态：Node 常驻 + PostgreSQL + Socket.IO

Planka 的技术栈很典型：服务端跑在 Node.js 上，前端是 React 写的单页应用，业务数据放在 PostgreSQL 里，实时协作通过 Socket.IO 完成——正常情况下走 WebSocket，遇到代理不支持或者网络环境受限时会自动降级成长轮询。它的数据模型是四层嵌套：项目下面挂看板，看板下面挂列表，列表下面挂卡片，卡片再挂成员、标签、清单、附件和评论。这个结构非常直观，和大多数人脑子里「看板」的样子一致，也意味着一次「打开看板」的请求，服务端要把这四层结构连同卡片上的各种附属对象一起组装出来。

Node 的运行模型决定了这台机器的资源画像。JavaScript 主线程是单线程事件循环，所有的请求处理、JSON 序列化、Socket.IO 的事件分发都排在这一个线程上。这类负载的特点是「不吃算力吃调度」：CPU 使用率常年不高，可能只有百分之十几，但一旦某一刻有几千条连接同时有事件要广播，事件循环会被塞满，表现为所有请求一起变慢，而不是某个请求特别慢。这就是为什么很多人看监控觉得「CPU 才百分之二十，怎么会卡」，因为瓶颈在事件循环的队列长度，不在核的利用率。

PostgreSQL 是另一个必须单独规划的部分。它不能和 Node 抢同一份内存预算，因为数据库有自己的共享缓冲区、连接进程和 WAL 写入。经验区间上，一个五百人团队、卡片总量几万条的看板库，数据本身加索引大概在几百 MB 到两三 GB 之间，给 PostgreSQL 分配一到两 GB 的共享缓冲区就相当宽裕。要注意的是数据库连接数：Node 侧的连接池如果开得太大，反而会把 Postgres 的进程数顶上去，每个后端进程都要一份私有内存，很容易在内存不大的机器上触发 OOM。

所以 Planka 的典型部署形态是三件套：一个 Node 进程、一个 PostgreSQL 实例、一个反向代理。容器化以后就是三个容器加一个数据卷。资源分配上，经验区间可以这样估：常驻连接在一百条以内、卡片几万条的小团队，两核四 G 够用，其中 Node 占一 G 左右，Postgres 占一 G 到一 G 半；连接数上到三百到五百条、附件开始堆积的时候，四核八 G 是更稳妥的档位。再往上走，就不是加内存能解决的了，得考虑拆进程或者上多实例，这一点在后面讲重连风暴时会展开。

Focalboard 的形态：单二进制 + 可换数据库

Focalboard 走的是另一条路。服务端是 Go 编译出来的单个二进制文件，前面挂一层 Web 前端，数据库可以在 SQLite、PostgreSQL、MySQL 之间选。它的默认形态非常轻：一个二进制、一个 SQLite 文件、一个附件目录，拷贝到服务器上改个配置文件就能跑起来。这种「一个文件搞定」的部署体验对运维极其友好，尤其是那些没有专职 DBA 的中小团队，装完就能用，备份就是打包两个目录。

它的数据模型和 Planka 有一个本质区别：卡片是「属性化的」。一张卡片不是固定的标题加描述，而是一组属性的集合，同一批数据可以用看板视图、表格视图、画廊视图、日历视图来呈现，切视图只是换了一种渲染方式，底层数据不动。这个设计对磁盘很友好——同一个对象只存一份，不会因为多建了几个视图就多出一份数据。经验区间上，几万张属性化卡片的库，SQLite 文件大概在几百 MB 量级，换成 PostgreSQL 也差不多，数据量从来不是这类系统的瓶颈。

Go 的运行模型和 Node 完全不同。每个连接对应一个 goroutine，goroutine 的初始栈很小，按需增长，调度器把大量 goroutine 复用到少量系统线程上。这意味着在连接数维度上，Focalboard 的伸缩性天然比 Node 好，几千条并发连接对它是常规负载，对 Node 就要开始考虑拆分了。但要注意，Focalboard 的实时性本来就偏弱，它更接近「定时刷新」而不是「事件推送」，一端改了卡片，另一端可能要等下一次拉取才看到。如果你的团队对「别人一动我立刻看到」有强需求，这一点在选型时就要想清楚，它节省的连接管理开销是拿实时性换来的。

SQLite 的边界必须说透。SQLite 是单写者模型，所有写操作串行化，写的时候会对数据库文件加锁。小团队完全够用，十几个人零星改卡片，一辈子也碰不到锁冲突。但一旦并发写升高——比如几十个人同时在做批量拖拽、批量改属性，或者有个脚本在导入历史数据——就会出现「database is locked」这类错误，表现为页面卡住、提交失败。经验区间上，持续并发写超过每秒十几次、或者同时有二十人以上在密集编辑，就该考虑换 PostgreSQL 了。换库本身不难，难的是换库之前的那个阶段，故障是间歇性的，很难复现，容易被误判成网络问题。

如果你正在为这套系统找落地机房，需要把「常驻连接不掉线」和「附件盘能扩」这两件事同时考虑进去。一万网络深耕 IDC 行业 19 年（成立于 2007 年），在华南、华东、华北及中国香港、海外多地整合自营节点与 BGP 多线资源，提供服务器租用、机柜托管与带宽接入的一体化交付；具体机型、带宽与报价以官网实时信息或咨询确认为准。对看板这类「连接敏感、磁盘渐长」的负载来说，机房的网络稳定性比单机配置更值得花时间核对。

一条长连接到底占多少：内存、句柄与 GC

「一条 WebSocket 到底吃多少内存」这个问题，网上的答案从几 KB 到几 MB 都有，差异之大是因为大家算的不是同一笔账。一条连接在服务端的开销至少分四块：内核为这个 socket 保留的发送和接收缓冲区、应用层为这个会话建的对象（用户身份、订阅了哪些看板、最后心跳时间）、订阅关系表里的引用、以及为推送消息准备的序列化缓冲。这四块里，内核缓冲区是最容易被忽略的，因为它不算在进程的堆里，用 top 看进程内存根本看不见。

经验区间上，一条空闲的、只订阅了一个看板的连接，在服务端的综合开销大致在几十 KB 到一两百 KB 之间，具体取决于框架的实现方式和缓冲区配置。按这个区间推算，一千条常驻连接对应的内存大约在几百 MB 到一 GB 之间。这个数字要和基础开销叠加：Node 进程本身跑起来，加上 V8 堆、模块加载、连接池，空载就要两三百 MB；PostgreSQL 空载也要一两百 MB 加上共享缓冲区。所以一台四 G 的机器，跑一千条连接是可以的，但没有多少余量给附件缓存和突发的序列化峰值。

文件描述符是第二个隐形天花板。每一条连接在操作系统层面就是一个 fd，Linux 默认的单进程上限通常是一千零二十四，这个默认值对看板系统来说太低了。一千条连接加上日志文件、数据库连接、监听端口，很容易把这个数顶满，表现出来的症状是「新用户连不上，老用户正常」，日志里一堆「too many open files」。改 ulimit 是必须做的，但同时要相应调高内核的全局文件句柄上限和反向代理的连接数上限，三层要一起改，只改一层等于没改。经验区间上，按「预期峰值连接数乘以二，再加五百」去设上限比较稳妥。

垃圾回收是第三个容易被低估的因素，这一点在 Node 上尤其明显。V8 的垃圾回收需要扫描存活对象，堆越大、存活对象越多，单次回收的停顿就越长。连接本身是长期存活的对象，它们不会被回收，但会在堆里占据空间，把堆撑大。堆大了以后，每次新生代回收要处理的对象更多，停顿从几毫秒涨到几十毫秒，表现出来就是「每隔一段时间所有请求集体慢一下」。这不是内存泄漏，是负载形态导致的必然结果，缓解办法是控制单进程的连接数上限，超过就拆进程，而不是一味加内存。

把上面几块合起来，可以得到一个粗略的估算式：单进程所需内存约等于「连接数乘以单连接开销」加上「运行时基础堆」加上「数据库共享缓冲区」，再留百分之三十的余量给突发。按单连接一百 KB、基础堆三百 MB、缓冲区一 G 计算，一千条连接需要约一百 MB 加三百 MB 加一 G，再乘一点三，大约一 G 八。这是一台四 G 机器能舒服承载的规模。连接数翻到三千，同样的公式算出来接近三 G，四 G 机器就开始紧张，八 G 才是合理档位。

重连风暴：网络抖一下，服务端要被问一遍

前面所有的估算都是按「稳态」算的，而自建看板最常见的「莫名卡死」，几乎都发生在非稳态。典型场景是这样：机房侧网络抖了一下，或者运维发了个新版本重启了容器，几千条连接在几秒之内同时断开。断开以后客户端不会就此罢休，它们会在几百毫秒到几秒的随机间隔内发起重连。于是原本分散在一整个上午的握手、鉴权、拉数据，被压缩到了十几秒里全部重放一遍。

重连的成本远高于稳态。稳态下一条连接只需要偶尔发个心跳、偶尔推一条事件；重连时每条连接要走完整的路径：TCP 握手、TLS 握手（如果走 HTTPS）、身份校验（大概率要查一次数据库或者校验一次令牌）、订阅恢复、然后拉一份当前看板的完整快照。这份快照对 Planka 来说就是项目、看板、列表、卡片四层结构连同附属对象的组装，一次可能几百 KB 的 JSON。一千条连接同时重连，等于在十几秒内产生了几百 MB 的序列化输出和上千次数据库查询，瞬时负载可以是稳态的十到五十倍。

Planka 在这个环节上要格外小心，因为 Socket.IO 的连接状态是进程内的。如果你的部署是多实例加负载均衡，而负载均衡没有做会话保持，同一个看板的两个用户可能被分到不同进程，各自订阅各自的，互相收不到对方的事件——用户看到的现象是「我改了别人不变，刷新一下才出来」。要解决就得加粘性会话，或者引入 Redis 适配器把事件广播到所有进程。这两条路都有代价：粘性会话会在某个实例重启时把一批用户整体甩到别的实例上，制造一次小型重连风暴；Redis 适配器则多了一个必须高可用的组件，运维复杂度上升一档。

Focalboard 因为实时性偏弱，重连风暴的压力相对小一些，但它的压力转移到了别处：如果客户端是靠定时拉取来同步，那么每次拉取都是一次完整的接口请求，几百个客户端在同一个刷新周期上对齐，会形成周期性的小尖峰。这种情况下缓解手段是把刷新间隔打散，让不同客户端错开几秒，而不是所有人在同一秒去问服务端。

真正有效的缓解措施有几条，按性价比排序。第一，发布用滚动方式加优雅退出，让进程在关闭前先给客户端发断开通知并把连接逐步迁走，而不是一刀切断。第二，重连加随机退避，客户端不要用固定间隔，否则所有客户端会在同一时刻一起回来。第三，鉴权结果做短时缓存，令牌校验不必每次都打数据库，缓存个几十秒就能把重连峰值削掉一大半。第四，负载均衡的空闲超时要设得比心跳间隔长，否则连接会被中间设备静默掐断，客户端还以为连着，等到真正发消息才发现断了，又触发一次重连。经验区间上，一个五百人团队的看板，把这四条做到位，重连峰值可以从稳态的几十倍压到五倍以内。

卡片很小，附件不小

把注意力从连接转到磁盘，会看到一个完全不同的增长曲线。卡片本身的信息量很小：一个标题、一段描述、几个属性字段、若干标签引用，一条记录序列化下来几百字节到几 KB。一个五百人团队用了两年，卡片总量大概在几万条的量级，全部塞进数据库，加上索引和 WAL，占用的空间也就是几百 MB 到两三 GB。这个量级对任何一块盘都不构成压力，甚至放在系统盘里都感觉不到。

附件是另一回事。看板的实际使用场景决定了附件会不断堆积：需求卡片里贴设计稿、缺陷卡片里贴复现截图、评审卡片里贴录屏。一张高清截图两三 MB，一段三十秒的录屏几十 MB。Planka 和 Focalboard 的默认行为都是把附件落在本地文件系统的目录里，数据库只存一个路径和元信息。这意味着数据库会一直很小，而附件目录会一直变大，两者的增长速度差着两三个数量级。

给一个经验区间的估算：一个活跃使用看板的团队，人均每月产生的附件量大约在五十 MB 到两百 MB 之间，取中间值一百 MB 算，五百人团队一年就是六百 GB 左右，两年超过一 TB。这个估算的波动很大，取决于团队里有没有人习惯往卡片上贴录屏——只要有那么两三个人这么做，总量就会翻倍。所以磁盘规划不能按「数据库多大」来做，必须按「附件年增量乘以保留年限」来做，并且预留出至少百分之三十的余量给临时文件和备份快照。

磁盘布局上有一条硬性建议：附件目录必须单独挂一块数据盘，不要和系统盘、数据库盘混在一起。理由有三个。第一，附件增长不可预测，单独一块盘方便在线扩容，不用动系统。第二，容器部署时附件目录必须挂持久卷，否则容器一重建，所有附件全丢，而数据库里还留着指向这些文件的路径，页面上显示一堆裂图。第三，备份策略不同，数据库适合做逻辑备份加快照，附件适合做增量同步，混在一起只能整盘备份，效率极低。

还有一个细节值得提前想：附件目录的层级。如果所有文件都堆在同一个目录里，文件数上到十万量级以后，目录遍历会明显变慢，备份工具的扫描时间也会急剧上升。主流的实现一般会按哈希前缀或者日期分一级子目录，部署时确认一下这一点，如果没有，就在挂载点前面加一层按年月的目录规划。这个动作在做的时候只要几分钟，等到目录里堆了二十万个文件再想改，就得停机迁移了。

看板系统的硬件六维：连接数、附件目录与机位

CPU 这一维，看板系统是典型的「低利用率、高敏感」负载。稳态下两核的利用率可能长期在百分之十以下，看起来浪费，但你不能只给一核，因为重连风暴和备份压缩这类瞬时任务会把单核打满，而单核打满在 Node 上等于全站卡顿。经验区间上，五百人团队、峰值连接一百到两百条，两核起步；上千人、峰值连接三百到五百条，四核；再大就要考虑横向拆分了，而不是继续堆核，因为 Node 的单进程用不满太多核。

内存这一维完全由连接数决定，前面已经算过：一千条连接大约需要四 G，三千条大约需要八 G。这里要提醒的是「内存不是越大越好」这件事在看板场景下并不成立——内存大一点确实能让页缓存更有效，附件读写更顺，但如果你的连接数只有一百条，加到三十二 G 也只是让空闲内存更多，对体验没有实质帮助。合理的做法是按估算式算出需求，再加百分之五十的余量，剩下的预算留给磁盘。

SSD 这一维要分两块看。数据库盘看重的是随机写的延迟和写入耐久，附件盘看重的是顺序读写和容量。经验区间上，几万条卡片的数据库在 SATA 固态上完全跑得动，换成 NVMe 带来的提升主要体现在备份和恢复的时间上，而不是日常交互；附件盘则相反，容量比速度重要得多，一块大容量的 SATA 固态或者大容量机械盘加缓存，比一块小容量 NVMe 更实用。如果预算有限，优先把钱花在附件盘的容量上。

带宽这一维经常被高估。看板的实时消息是小包、低频次，一千条连接的心跳和事件推送加起来，占用的带宽可能只有几百 Kbps 到一两 Mbps。真正吃带宽的是附件上传和下载，而且是突发性的：一个人上传一段五十 MB 的录屏，几十秒内就把链路占满了。经验区间上，一百人规模的团队，峰值带宽需求大约在十到二十 Mbps；五百人规模、附件使用频繁的团队，五十到一百 Mbps 更稳妥。选带宽时不要按平均值买，要按「同时有几个人在上传大文件」来买。

电力和机位这两维在自建看板里往往被忽略，但它们直接影响总成本。一台两路配置的中端服务器，整机功耗大概在三百到五百瓦的量级，加上交换机、存储，一个机柜的功耗预算要提前算清楚。机位方面，看板系统通常一到两台机器就够（应用加数据库，或者合并成一台），用一台 1U 或者 2U 机架式放进去最经济；拿塔式服务器托管在机房里是浪费机位空间的做法，除非你只是临时验证。把六维合起来看，会发现一个规律：真正需要花钱的地方是内存和附件盘，CPU 和带宽都可以按较低档位起步，电力和机位是一次性决策，选错了后期改起来最麻烦。所以询价时最该问清楚的不是「多少钱一个月」，而是「内存能不能在线加、附件盘能不能单独扩、机位能不能从 1U 换成 2U」。这三个问题的答案，决定了这套系统两年后还能不能平稳扩下去。

Planka 与 Focalboard 的四维对比

把前面几节的分析压缩成一张表，按八个维度对照两个实现。需要强调的是，这张表里的「适用团队规模」是经验区间，不是产品能力上限——两个系统在技术上都能支撑更大的规模，区别在于支撑到那个规模需要付出多少运维代价。选型时要看的不是「谁更强」，而是「谁在你这个规模上不需要你做额外的事」。

另外提醒一句：这张表里的每一条都可以在部署后被验证，但验证的成本不一样。技术栈和数据库选择是部署当天就能确认的，实时协作机制和附件存放是配置阶段确定的，而多实例扩展方式、备份复杂度、升级路径这三项，往往要等到第一次扩容或者第一次出故障时才会暴露。这也是为什么选型时要提前把这三项问清楚，而不是等踩了坑再回头改。

读这张表有一个容易走偏的方式：把每一行都当成优劣判断。实际上多数行是「代价转移」，不是「谁更好」。比如实时协作机制这一行，Planka 的即时推送是优点，代价是每一条连接都要维持、每一次重连都要重建；Focalboard 的拉取模式省了连接管理，代价是用户感知到的延迟。选型的本质是判断「你这边的代价更能承受哪一个」，而不是找一个全维度都占优的选项。

升级与备份：看板系统最容易踩的两个坑

升级这件事在看板系统上有一种欺骗性：它不像数据库那样听起来吓人，装起来也确实简单，所以很多人直接在生产环境上拉新版本、重启、看能不能打开。能打开就认为成功了。问题在于，很多结构变更不是「能不能启动」级别的，而是「旧数据能不能正确读出来」级别的。升级脚本跑完了，服务也起来了，但某张卡片上的清单项丢了顺序，或者某个附件路径指向了不存在的目录，这类问题不会立刻报错，会在几周后被人偶然发现，那时候已经很难回溯是哪次升级引入的。

Planka 的升级要跟着镜像版本和底层依赖走，升级前必须确认目标版本对 Node 主版本和 PostgreSQL 版本的要求。数据库迁移脚本通常只能向前执行，跑完以后旧版本的镜像不一定能读新结构，所以「出问题就回滚镜像」这条路经常走不通。比较稳妥的做法是升级前对数据库做一次完整备份，并在测试实例上先跑一遍完整流程，确认业务数据能正常读出，再动生产。经验区间上，这类系统的升级窗口按半小时到一小时规划比较合理，其中大部分时间花在验证而不是执行上。

Focalboard 的升级看起来更简单，因为服务端就是一个二进制文件，替换掉重启就行。但它的风险点恰恰在这里：动作太轻，容易让人跳过备份。单二进制加 SQLite 的形态下，如果新版做了结构变更，SQLite 文件被就地改写，想退回旧版就没那么容易了——旧版二进制可能读不懂新结构，而文件已经被改过。所以哪怕升级动作只有十秒，也要先把数据库文件和附件目录一起复制一份出来。

备份这一块要讲的其实只有一句话，但这句话必须说透：数据库和附件目录必须一起备，只备库等于丢文件。数据库里存的是附件的路径和元信息，真正的字节在磁盘目录里。如果你只做了数据库的逻辑备份，恢复以后所有卡片都在，但每一张带附件的卡片都显示裂图，用户会以为你恢复失败了。反过来，只备附件目录而不备数据库，那堆文件就是一堆没有归属的二进制。

备份的一致性也值得花点心思。如果备份的时候系统还在写，数据库的备份点和附件目录的备份点会错开几分钟，恢复以后可能出现「数据库里有这条附件记录，但目录里没有这个文件」的情况。解决方法有三种：备份前短暂停止写入，用文件系统或者存储层的快照保证同一时间点，或者接受几分钟的错位并在恢复后做一次对账清理。经验区间上，看板这类系统的可接受数据丢失窗口通常按小时级设定就够了，不必追求秒级一致性，但恢复演练必须做——没演练过的备份，等于没有备份。

看板协作落单前的五个核对项

第一项，把峰值连接数算出来，而不是把注册人数报出去。具体做法是找一个普通工作日的上午十点，统计一下同时打开看板页面的浏览器会话数，再乘以一点五的标签页系数。这个数字才是你真正要买的规格的依据。如果算不出来，就按活跃用户的百分之十二估，宁可略高不要略低，因为重连风暴时的瞬时压力是稳态的好几倍。

第二项，确认附件盘的容量规划和扩容方式。按人均每月一百 MB 的经验区间，乘以团队人数，再乘以你打算保留的年数，得出一个基数，然后加百分之三十余量。重点不是这个数字本身，而是问清楚「这块盘能不能在线扩、扩的时候要不要停机、扩完文件系统能不能直接识别」。这三个问题的答案在不同机型上差别很大，问晚了会被动。

第三项，把单进程的文件描述符上限和反向代理的连接数上限一起核对。这两个值必须匹配，只调其中一个的话，瓶颈只是从一个地方挪到另一个地方。经验上按「预期峰值连接数乘以二再加五百」设定，并且用压力测试或者模拟重连验证一次，确认调完以后真的生效，而不是改了配置文件但服务没重载。

第四项，确认发布和重启的方式。如果你的部署是「停掉旧容器、起新容器」，那么每次发版都是一次全量重连风暴。要问清楚能不能做到滚动发布、进程退出前能不能优雅关闭连接、负载均衡的健康检查间隔是多少。这几项在采购阶段看起来和服务器无关，实际上它们决定了你那台机器的内存要按稳态算还是按峰值算，两者差着一个档位。

第五项，也是最容易被跳过的一项：备份的恢复流程要走一遍。不是看文档，是真的找一台空闲机器，把数据库和附件目录恢复上去，登录看板，打开一张带附件的卡片，确认图片能显示。这个动作大概花两小时，但它能在真正出事之前暴露出所有问题——备份文件不完整、附件路径写的是绝对路径、权限不对、数据库版本不匹配。所有这些问题在演练时发现都是小事，在故障时发现都是事故。

什么团队该选 Planka、什么团队该选 Focalboard

先说该选 Planka 的。第一类是对实时性有硬需求的团队：多人同时在一个板上协作，一个人拖了卡片，其他人必须立刻看到，中间隔着几秒的延迟就会导致重复劳动或者冲突。这类团队通常是产品研发、设计评审、线上故障处理，他们的工作节奏是「同步」的，看板就是一块共享的白板。第二类是已经有一定运维能力、能接受 PostgreSQL 这套东西的团队，他们不介意多维护一个数据库实例，换来的是一套结构清晰、扩展路径明确的技术栈。

再说该选 Focalboard 的。第一类是十几人到几十人的小团队，没有专职运维，希望装完就能用、备份就是打包两个目录、出问题重启一下就好。第二类是看重「同一批数据多种视图」的团队，卡片带属性、可以随时切成表格视图做统计、切成日历视图看排期，这种属性化的模型在跨职能协作里很实用。第三类是对实时性要求不高的团队，比如周级别的项目跟踪，一天看两次板，几分钟的同步延迟完全不影响工作。

有一类团队我建议两边都不要急着上，就是人数过千、且要求强实时的组织。这个规模下，Planka 需要做粘性会话或者 Redis 适配器改造，Focalboard 需要把 SQLite 换成 PostgreSQL 并加前置负载均衡，两边都要投入不小的工程成本。这时候更现实的做法是先按部门拆成多个实例，每个实例服务一两百人，用独立的数据库和附件目录隔离，比硬撑一个大实例要稳得多，故障的爆炸半径也小。

最后一个判断依据是预算的分配方式。看板系统的钱应该这样花：内存买够、附件盘买大、CPU 和带宽按低档起步、机位一次到位。一万网络深耕 IDC 行业 19 年（成立于 2007 年），在华南、华东、华北及中国香港、海外多地整合自营节点与 BGP 多线资源，提供服务器租用、机柜托管与带宽接入的一体化交付；实际可选机型与带宽档位随时段变化，落单前建议按官网实时信息核对，并把附件盘的扩容方式单独问清楚。把这笔账算明白，比在两个系统之间反复比较功能要值钱得多。