不知道你是否也在企业中使用过 Confluence，或者其他类似的 Wiki 工具。刚接触它时，我觉得这玩意儿真不错：功能强大、支持各种排版样式、可以插入图片、视频、图标，还能查看历史版本，使用体验比 Git 轻松太多了。
但慢慢地，我也发现了它的一个巨大问题：每个人都可以创建并维护自己的 Wiki 页面。
一开始，这种自由看起来是优势。但时间一长，问题就来了 —— 同一个主题的内容，往往被不同的人写了多个版本。尤其是在项目或产品从一个团队转交到另一个团队时（在外企这是很常见的操作），新团队通常不会在原有文档上继续维护，而是习惯另起炉灶，记录自己的理解。
于是，旧的 Wiki 随着人员流动逐渐失效（原作者可能早已离职），新的 Wiki 内容又不够完善甚至有误。这样一来，知识沉淀不仅没有统一，反而更混乱了。
我始终认为 Wiki 工具本身是好的，但如果缺乏统一的管理机制、没有像 Git 那样的 Pull Request 审批流程，那最终它就容易沦为垃圾信息的生产场。
相比之下，开源社区在这方面反而做得很好。
以 Python 社区为例：
- Python 官网（www.python.org）的内容，是通过 GitHub 上的 python/pythondotorg 仓库维护的；
- 开发者指南（https://devguide.python.org/）也托管在 python/devguide 仓库。
不管是谁，只要对这些文档有修改建议，都必须通过 PR 提交，经过审查后才能合并。而且因为是开源项目，社区用户也会主动参与反馈和改进，这也帮助文档长期保持高质量。
但反观企业内部，就完全不同了：
- 多人各写各的 Wiki，质量参差不齐；
- 内容孤岛多，缺乏维护，一旦人员流动，旧文档就“失效”；
- 更重要的是，内部文档缺乏公开审核机制，也没有外部反馈入口，错误不容易被发现或纠正。
还有一点可能更真实也更残酷：在企业内部，员工缺乏维护文档的动力。因为一个写得面面俱到、毫无遗漏的“满分文档”，可能在某天就意味着你可以被无缝替换。相比之下，把关键细节掌握在自己脑子里，才更有“工作安全感”。
所以文档治理这件事，本质上和工具无关，关键在人。在没有文化和流程支撑的前提下，再先进的工具也可能变成信息垃圾的堆放地。
你所在的公司又是怎么做文档管理的呢？欢迎在评论区分享交流。
转载本站文章请注明作者和出处，请勿用于任何商业用途。欢迎关注公众号「DevOps攻城狮」