底稿系统之于项目组就像源码管理系统之于软件开发团队，为了更好的定义底稿系统的产品特性，我们继续用数学中的逼近理论进行阐述，由于源码管理系统不管是从目的上，还是从功能上都和底稿系统极为相似，所以我们用源码管理系统去逼近底稿系统，以便理解。对于软件开发团队来说，源代码管理系统是核心系统，任何的协作、项目管理、CI/CD、自动化测试等研发活动都基于此，源码管理不但提供了基础的存储功能，还进一步增加了版本控制、版本比对、团队协作、快照、Hook等一系列便利化工具，方便研发团队对于源代码进行管理，提高开发效率。同样的，源码管理系统有像git这样的分布式存储方案，也有像perforce、svn、vss这样的中心存储方案。对于源码管理系统的描述到此为止，下面我们来具体讨论底稿系统。
底稿系统作为投行IT系统的重要组件，应具备以下特性：
文件存储及传输保证安全合规并且拥有高速的网络连接项目组往往是要在客户现场进行工作，长期出差，客户现场以及差旅途中的网络情况差异较大，出差地点遍布全国，网络接入及网络稳定性问题突出，如果在保证高速的网络连接同时，对信道进行加密，防止敏感信息泄露，是个需要重点考虑的问题，解决方案往往是要参考国内外头部云厂商的方案进行，例如AWS Global Accelerator、阿里云全球加速、腾讯云全球应用加速等服务，可以有效地提升底稿系统的接入速度，其原理是就近接入物理节点，然后通过云服务商的内部高速通道进行数据传输，快速到达核心机房，可以实现在中国大陆从南到北、从东到西的快速通信，同时采用符合国密局要求和金融行业规范的数据加密服务，保障数据安全，规避风险。
考虑到项目组出差场景的特殊性，传统的中央存储方案可能不能满足实际的生产需求，项目组在跨部门进行协作的时候，中央存储的方案是必须的，因为需要和总部的质控、合规等部门进行交流沟通，但是在客户现场，尤其是网络条件存在刚性中断的情况时，需要保证项目组的的工作不中断，同时能够进行一定限度的协作，这就需要设计边缘存储的方案，这套方案目前来看有两个实现路径，第一个路径是底稿文件存在项目组个人PC上，然后通过部署类似网盘App的软件，实时监控本地底稿目录，在网络畅通后进行数据传输。第二个路径是提供项目组本地NAS系统，项目组成员可以在客户现场基于NAS进行底稿整理工作，待网络条件好转时进行数据同步。
支持文件版本管理文件版本管理顾名思义，就是对文件进行版本管理，同一个底稿目录下的相同文件，可能因为各种信息修正要上传多次，但是有时候我们还希望对历史版本进行查询与对比，或者查看某个时刻的全部底稿状态，方便进行分析，这时候我们就需要对底稿文件的版本做出记录，同时支持时间切面上的文件展示。
项目组对于底稿的处理分为内部和外部两方面，对内要对底稿收集和处理进行分工，跟踪进度，确保底稿工作扎实，对外要和发行人进行沟通，收集各种资料，同时还要和律师会计师进行合作，交换底稿文件。这就需要底稿系统对协作和分享进行支持，项目组长可以将不同的底稿目录分配给不同的成员，项目组成员可以对底稿目录以及底稿文件的状态进行调整，实现项目组各角色之间的协作，同时可以将底稿系统中的文件进行分享，供第三方机构进行使用。
提供对多种底稿类型的识别及要素提取提供便利工具，实现对合同、银行流水等多种类型的底稿进行结构化信息抽取，这部分内容是金融科技类公司主攻的重点方向，相关内容也会在后面的文章中重点介绍，这里不做展开。
支持多种格式的文档浏览与批注要考虑到底稿系统的不同使用角色，项目组在处理底稿的同时，质控人员也应该可以在底稿上进行协同工作，标注底稿的问题，对文件以及文件内部的特定信息进行评论，项目组可以基于这些信息做出回复，以及文件更新。
支持二次开发支持尽量丰富的Restful API，可以对底稿进行不断扩展。
支持日志审计功能支持日常审计工作，记录底稿系统上产生的所有日志。
说完这些底稿系统的特性，大家头脑中可能都形成了初步的产品模型，这个系列的文章写完之后，我会再写一个产品的系列，提供高保真的产品原型图，供大家参考。
下面再写一些存储方面的技术方案：
存储的建设方案一般有三种方式：
传统NAS及云原生对象存储方案这个方案主要是购买存储，通过后续的开发定制底稿系统功能，这种方案一般应用于有一定研发能力，不进行产品输出的组织。
开源存储方案基于采用ceph或者Gluster等方案开发底稿系统，这种方案一般适用于需要进行产品输出的公司，便于对产品进行整体把控，降低成本，但是需要较强的研发和运维实力。
企业网盘整体采购方案适用于通用解决方案，能够提供稳定且标准的产品体验，但是在扩展性上有所不足。
底稿系统的基础架构可能有些乏味，但是为了保证完整性还必须要写，后面的文章会越来越有意思，会介绍文档的解析、客户端的选型、RPA、自动撰写等内容，争取能够描述投行IT的全貌。
