研发文档管理规定

研发文档管理规定第一章总则1.1目的为统一公司研发文档的创建、评审、存储、变更、归档与销毁全过程，确保技术资产安全、知识可传承、审计可追溯、合规可验证，特制定本规定。1.2适用范围适用于××公司研发中心（含硬件、软件、算法、测试、运维、数据、AI、平台、质量八部）及所有外协团队。1.3法规依据《中华人民共和国档案法》《网络安全法》《数据安全法》《个人信息保护法》《GB/T19001-2016/ISO9001:2015》《GB/T22080-2016/ISO27001:2013》《GB/T29490-2013知识产权管理规范》《公司商业秘密分级保护制度》《公司信息安全等级保护2.0实施细则》。1.4术语定义RDMS：Research&DevelopmentManagementSystem，公司统一研发文档管理系统，基于GitLab+MinIO+ElasticSearch自研封装。主文档：项目生命周期内必须交付且纳入质量审计的文档，包括需求、设计、代码、测试、验证、发布、运维、退市八类。辅助文档：不直接纳入质量审计但对研发有支撑作用的文档，如会议纪要、技术调研、实验记录、竞品分析。密级：公开、内部、秘密、机密、绝密五级，按《公司商业秘密分级保护制度》执行。版本号：采用语义化版本规范“主.次.修订-构建号+后缀”，后缀用“a”表示Alpha，“b”表示Beta，“r”表示Release，“h”表示Hotfix。1.5权责矩阵文档作者：对内容正确性、合规性、密级标识负全责。评审负责人：组织评审、收集缺陷、跟踪关闭，对评审结论负全责。文档管理员：负责命名、编号、上传、归档、权限、备份、销毁，对系统数据完整性负全责。QA：对文档符合质量体系要求负审计责任。信息安全部：对密级标识、加密、脱敏、水印、日志负监督责任。法务：对知识产权、出口管制、开源协议负审核责任。第二章文档分类与编码2.1分类体系采用“项目-阶段-类型-模块”四维分类法，共256个叶子节点，编码长度固定18位，全公司唯一。示例：PRJ20250601-DRS-HLD-PAI001，表示2025年立项的第0601号项目，在DRS（Design）阶段的高层次设计文档，面向PAI（AI平台）模块001子系统。2.2编码规则第1-10位：项目编号，由PMO统一发放，终身不变。第11-12位：阶段码，需求RQ、设计DR、实现IM、测试TE、验证VA、发布RL、运维OP、退市RT。第13-15位：类型码，HLD高层设计、LLD详细设计、SRC源码、UT单元测试、IT集成测试、ST系统测试、RP报告、MN手册。第16-18位：模块码，由系统架构师在立项评审时确定，后续新增需走ECR（EngineeringChangeRequest）。2.3辅助文档编码在主文档编码后追加“-S”后缀，再补4位流水号，例如PRJ20250601-DRS-HLD-PAI001-S0001。2.4密级与编码绑定绝密文档在编码前加“TOP_”，机密加“SEC_”，秘密加“PRV_”，内部与公开不加前缀。系统通过钩子脚本强制校验，未标识无法上传。第三章文档创建与模板3.1模板管理模板库位于RDMS“template”组，仅模板管理员可写。模板分中文、英文双语，含页眉、页脚、密级、水印、公司Logo、修订表、目录、参考章节。3.2模板选用需求类：采用“RQ-V1.4.docx”模板，必须包含背景、范围、角色、用例、非功能需求、验收标准、反向需求、风险、假设、依赖。设计类：采用“DR-HLD-V2.1.drawio+md”组合，必须在drawio中给出0级、1级架构图，md文件说明设计决策、权衡、废弃方案、性能预算。测试类：采用“TE-ST-V1.9.xlsx”模板，必须包含追溯矩阵、用例ID、前置、步骤、预期、实测、结果、BugID、是否阻塞。3.3创建流程1)作者Fork模板库到个人空间；2)按“文档编码-作者缩写-日期”建分支；3)使用OnlyOffice在线编辑或本地Office+GitLFS；4)保存后触发CI，自动跑“文档体检”：命名、密级、字数、图片分辨率、链接有效性、敏感词、开源许可证冲突；5)体检报告100分方可提交MR（MergeRequest），低于90分自动打回。第四章评审机制4.1评审分级一级评审：作者自评，检查拼写、格式、链接、版本、密级。二级评审：同伴评审，至少1名同模块高级工程师，使用MRComment模式，缺陷等级分致命、严重、一般、提示。三级评审：跨部门评审，涉及硬件、算法、法务、信息安全、运维、市场、客服，使用Confluence+Jira评审插件，必须提前48小时发送材料。四级评审：高层评审，预算≥500万元或涉及新商业模式、新法规、出口管制的项目，需CTO、CFO、法务VP、信息安全VP、知识产权VP五方会签。4.2评审通过标准致命缺陷=0，严重缺陷≤1，一般缺陷≤3，提示缺陷≤5；全部缺陷必须在24小时内关闭或降级；评审结论分“通过”“有条件通过”“不通过”。4.3评审记录评审表、签到表、录音、录像、截图、会议纪要全部以PDF/A格式归档，命名规则：文档编码-REV-日期-序号，保存15年。第五章版本与变更控制5.1版本策略采用GitFlow主干模型：master、develop、feature、release、hotfix五类分支。文档与代码同分支管理，确保可追溯。5.2变更分级A类：影响安全、合规、外部接口、合同交付，需ECR+四级评审。B类：影响性能、功能、用户体验，需ECR+三级评审。C类：仅文字、格式、错别字，作者自评+二级评审即可。5.3变更流程1)作者在Jira创建“DOC-变更”工单，选择A/B/C类；2)系统自动生成变更影响分析表，列出受影响文档、代码、测试用例、用户手册、培训材料；3)评审通过后，RDMS自动打Tag，旧版本置为“已废弃”状态，并添加“废弃原因”字段；4)变更完成24小时内，作者需发送邮件通知所有干系人，邮件模板由系统自动生成。第六章存储、备份与权限6.1存储架构生产库：阿里云OSS标准存储+多可用区冗余，12个9持久性。冷归档库：阿里云OSS深度冷归档，保存7年，取回时间≤1小时。本地缓存：深圳、上海、成都三地机房各部署只读MinIO集群，用于CI/CD高速拉取。6.2备份策略实时：OSS跨区域复制，RPO<15秒。每日：凌晨02:00全量快照，保留30天。每周：周一凌晨03:00冷备到磁带库，保留5年。每月：月末最后一天做LegalHold，用于合规审计，保留10年。6.3权限模型采用RBAC+ABAC混合：RBAC定义角色，ABAC定义属性（项目、模块、密级、环境）。角色清单：访客、作者、评审人、模块Owner、项目管理员、QA、信息安全审计、法务、文档管理员、系统管理员。默认权限：作者对自己文档拥有读写，同项目成员拥有读，跨项目需申请；机密以上文档强制水印+下载审批；绝密文档禁止下载，仅在线浏览，且浏览时自动录屏。第七章审计与合规7.1审计频率项目里程碑审计：需求评审后、设计评审后、发布评审后，共三次。质量体系外审：每年一次，由DNV执行ISO9001&27001双证审核。内部审计：信息安全部每季度抽查10%项目，全年全覆盖。7.2审计内容文档完整性：是否缺需求、设计、测试、验证、发布、运维、退市任一环节。版本一致性：代码Tag与文档Tag是否一一对应，MR是否闭环。密级合规：是否误标、漏标、高密低传、低密高传。知识产权：是否违规使用GPL、LGPL、AGPL、SSPL、商业闭源组件；是否完成OTRS审批。出口管制：是否涉及EAR、ITAR清单；是否完成商务部备案。7.3审计问题分级重大：可能导致罚款≥50万元或停业务，必须在7天内整改并提交证据。一般：可能导致客户投诉或内部效率下降，必须在30天内整改。轻微：格式、模板、命名不规范，必须在90天内整改。7.4审计报告报告模板由QA统一维护，包含问题清单、证据截图、整改措施、责任人、截止日期、验证人、验证结果。报告需上传RDMS并设置“只读”权限，保存15年。第八章知识传承与培训8.1新人入职必须完成“研发文档规定”线上考试，90分及格，不及格重考，三次不过延长试用期。8.2技术沙龙每月最后一个周五下午举办“文档之美”沙龙，分享优秀案例、踩坑实录、工具插件。8.3导师制度新人入职第一周分配文档导师，两周内完成第一个MR，导师需在48小时内给反馈。8.4经验库建立“文档反模式”库，收录历年审计发现的典型错误，配漫画、视频、Quiz，确保有趣可记。第九章工具链集成9.1统一入口RDMS与Jira、Confluence、GitLab、Jenkins、SonarQube、Nexus、OnlyOffice、企业微信、钉钉、SSO、PKI、VPN、DLP、CASB深度打通，实现单点登录、消息推送、水印穿透。9.2CI流水线文档MR触发“doc-ci”流水线，Stage包括：Lint、Link、Pic、Sec、Lic、Tra、Met、Pdf。Lint：检查模板、命名、密级、字数、图表分辨率。Link：检查外部链接200OK。Pic：压缩图片<300KB，转WebP，加盲水印。Sec：跑敏感词、正则、AI模型识别泄密。Lic：扫描开源许可证冲突。Tra：检查需求-设计-测试追溯矩阵完整性。Met：提取元数据写入ElasticSearch，供全局搜索。Pdf：生成PDF/A-2b，加UDF加密，上传OSS。9.3IDE插件提供VSCode、IntelliJ、PyCharm、CLion、Eclipse插件，一键创建文档、自动填充编码、实时提示规范、本地预览水印、一键提交MR。9.4命令行工具提供rdms-cli，支持Linux、macOS、Windows，核心命令：rdmsinit：克隆模板，生成分支。rdmscheck：本地跑Lint。rdmssubmit：打包上传MR。rdmsdiff：对比版本差异，支持Word、Excel、PDF可视化。rdmsbackup：一键冷备到本地磁盘加密压缩包。第十章灾难恢复与业务连续性10.1RPO与RTO文档库RPO≤15秒，RTO≤30分钟；审计证据RPO≤1小时，RTO≤4小时。10.2灾难等级D1：单可用区故障，自动切换，无需人工。D2：区域级故障，启用冷备OSSbucket，人工确认后切换。D3：阿里云全球故障，启用本地磁带库+离线硬盘，由CTO授权激活。10.3恢复演练每半年执行一次“文档库断网”演练，模拟黑客加密、管理员误删、OSS回收站清空三重灾难，必须在2小时内恢复至可读状态，演练报告上传RDMS“disaster”目录，保存10年。第十一章离职与移交11.1移交清单文档作者离职前必须完成《研发文档移交表》，包含：项目、模块、文档编码、最新版本、未关闭MR、未关闭Bug、未关闭ECR、知识库链接、密码、密钥、样机、账号。11.2移交评审由模块Owner+文档管理员+HRBP三方现场评审，逐项打勾，缺一项HRBP可暂停离职流程。11.3权限回收离职当日18:00前，信息安全部批量撤销VPN、SSO、RDMS、Jira、GitLab、Confluence、Nexus、OSS、MinIO、企业微信、钉钉、邮箱、门禁、PCA证书、硬件Token，日志保存10年。第十二章奖惩与绩效考核12.1奖励年度“文档之星”评选，设金、银、铜奖，分别奖励3万元、2万元、1万元+股票期权+CEO签名证书。12.2处罚未按模板创建、未评审上传、未标识密级、未关闭缺陷、未按时归档，每次扣绩效500元；造成泄密、合规事件，按《公司信息安全奖惩条例》顶格处理，情节严重者移交公安机关。12.3绩效权重文档质量占研发人员年度绩效15%，评分公式：文档绩效=（评审通过率×0.4+审计整改完成率×0.3+工具链及时上传率×0.2+知识库贡献度×0.1）×15%。第十三章持续改进13.1度量指标文档缺陷密度=致命+严重缺陷数/千行；目标≤0.1。文档及时率=按时上传数/应上传数；目标≥98%。文档复用率=被引用次数/总文档数；目标≥30%。13.2反馈通道RDMS每页底部嵌入“一键吐槽”按钮，提交后自动创建Jira工单，分类“功能、性能、易用、安全、合规、