一次群晖多套件异常的排查

前段时间陆续遇到几个群晖套件的问题。

先是 iPhone 上的 Synology Drive 突然无法正常登录团队文件夹，后来又发现 Synology Office 无法启动，提示要先启动 Synology AI Console，但 AI Console 启动后马上又会自己停止。继续检查时，还发现 Synology Photos、Drive 的部分后台服务也处于异常状态。

这些问题一开始看起来彼此没有关系：Drive 像是客户端问题，Office 像是 AI Console 的问题，Photos 又像是另一个独立故障。

最后排查下来，原因其实是同一个。之前 NAS 的一个存储卷曾经完全没有剩余空间，导致系统底层的数据库服务启动失败。后来虽然已经清出了足够的空间，但这个服务因为连续启动失败，仍然停留在失败状态，并没有自动恢复。而 AI Console、Office、Drive、Photos 等多个套件都依赖这个底层服务，于是就出现了看起来完全不同的一系列异常。

解决方法并不复杂：先恢复底层数据库服务，然后依次重启受影响的群晖套件。之后 AI Console 和 Office 恢复正常，Drive 的同步服务也重新运行，Photos 的异常状态同样消失。最后检查系统服务，已经没有残留的失败项。

回头看，这次最麻烦的其实不是修复，而是找到这些现象之间的联系。表面上是几个完全不同的套件各自出了问题，真正的原因却只是更底层的一个服务没有从之前的磁盘空间耗尽中恢复。所以使用群晖还真不能把存储空间占满。某个存储卷一旦被占满，影响的可能并不只是文件写入，还可能波及数据库、索引、同步和套件后台服务。即使后来清出了空间，之前失败的服务也未必会自动恢复。

此次故障排查在 ChatGPT 的帮助下几分钟就搞定了。果然，AI 对效率的提升越来越明显，让很多原本需要大量经验和搜索才能解决的陌生技术问题，也变得可以比较从容地处理。