软件开发管理规定_第1页
软件开发管理规定_第2页
软件开发管理规定_第3页
软件开发管理规定_第4页
软件开发管理规定_第5页
已阅读5页，还剩11页未读， 继续免费阅读

下载本文档

版权说明：本文档由用户提供并上传，收益归属内容提供方，若内容存在侵权，请进行举报或认领

文档简介

软件开发管理规定第一章总则1.1目的本规定的唯一目标是：让任何一名工程师在任意一台电脑上，都能在30分钟内把代码安全、合规、可追踪地交付到生产环境，且全年生产故障率低于0.1%。1.2适用范围适用于公司所有产生或可能产生二进制、脚本、配置、SQL、基础设施即代码等可执行交付物的项目，包括外包、实习生、AI辅助生成代码。1.3效力层级本规定与《网络安全法》《数据安全法》《个人信息保护法》《密码法》、ISO27001、等保2.0、GDPR、SOX、PCI-DSS、客户合同条款冲突时，以更高要求为准；其余场景以本规定为准。1.4术语•主库：GitLab上受保护的分支，默认main。•制品：编译、打包、加密签名后待部署的不可变文件，存储在Nexus私有仓库。•变更单：Jira中类型为“Change”且关联代码提交记录的单据。•热修复：生产环境紧急缺陷，需在24小时内上线，跳过迭代排期。•featureflag：运行时开关，使用Unleash服务统一管理。第二章组织与角色2.1软件治理委员会（SGC）主任：CTO；常设成员：法务、安全、运维、QA、PMO、财务、审计。每月第一个工作日召开，30分钟，仅决策“是否同意变更”与“是否同意例外”。2.2产品负责人（PO）对需求池排序、ROI、用户故事验收标准负责，可否决开发团队任何不符合业务目标的技术任务。2.3技术负责人（TL）对架构、性能、安全、成本、可维护性负责，拥有代码审查否决权。2.4安全合规代表（SCR）专职安全工程师，对任何代码拥有“blockmerge”权限，可直接在MR里插入安全评论。2.5运维代表（SRE）对SLI/SLO、容量、发布窗口、回滚方案拥有一票否决权。2.6QA代表制定测试策略、维护自动化用例库、出具质量报告，对“是否达到放行标准”拥有签字权。2.7审计代表每季度抽查10%项目，出具合规报告，可直接要求项目停工整改。第三章需求与立项3.1需求准入任何需求必须先进入JiraProductBacklog，字段必须填写：业务价值（货币化）、目标用户、失败影响（货币化）、法务/合规/安全标签。3.2可行性评审PO、TL、SCR、SRE、财务五方在48小时内完成线上评审，结论只有“Go”“NoGo”“NeedInfo”。3.3立项编号通过评审后，Jira自动生成PROJ-XXXX编号，作为后续代码、分支、资源、预算的唯一前缀。3.4预算锁定财务在立项同时冻结人力+云资源预算，误差>10%需重新评审。第四章版本策略4.1版本号格式语义化版本：主版本.次版本.修订-先行版本+构建元数据，例：3.2.7-rc1+20250625.1。4.2发布列车每年固定4个常规窗口：3月、6月、9月、12月的第二个周四02:00—04:00（GMT+8）。热修复不受窗口限制，但需在SGC次日例会上补录。4.3支持周期主版本支持24个月，次版本支持12个月，修订版本支持3个月。到期前30天SRE发送EOL邮件，逾期自动关闭漏洞通道。第五章分支与合并策略5.1永久分支main：生产代码；develop：集成代码；hotfix：热修复代码。5.2临时分支feature/PROJ-XXXX-short-desc、release/vX.Y.Z、hotfix/PROJ-XXXX-short-desc。5.3生命周期临时分支存活≤30天，逾期由GitLabBot自动删除（已合并）或发出警告（未合并）。5.4合并请求（MR）必须关联Jira编号；必须包含“变更类型”标签（feature/bugfix/refactor/docs/config）；必须通过CI全部阶段；必须2名代码审查人，其中至少1名TL或SCR；必须rebase后的线性历史；Squash合并，提交信息模板如下：PROJ-XXXX<type>:<subject><body>Reviewed-by:<GitLabID>Security-risk:[none/low/medium/high]Performance-impact:[none/low/medium/high]5.5代码审查红线•出现硬编码密码直接拒绝；•出现copyleft许可证（GPL、AGPL）直接拒绝；•单MR>500行有效代码需拆分；•单元覆盖率<80%直接拒绝；•新增≥3级日志必须包含trace_id。第六章配置与密钥管理6.1十二因子配置任何可能因部署环境而变化的值必须外部化到环境变量，禁止出现ifenv=="prod"硬编码。6.2密钥分级•A级：对称密钥、私钥、OAuthclient_secret；•B级：数据库连接串、APIToken；•C级：业务开关、功能灰度比例。6.3存储与轮换A级使用HashiCorpVaultKV-v2，开启自动轮换≤90天；B级使用KubernetesSecret+SealedSecret；C级使用ConfigMap。6.4加密要求传输层TLS1.3，必须开启HSTS、OCSPStapling；静态数据AES-256-GCM，密钥由KMS管理。6.5泄漏响应10分钟内禁用泄漏密钥，30分钟内轮换，1小时内出具事件报告，24小时内向监管机构报备。第七章构建与持续集成7.1构建环境使用公司统一BaseRunner（Ubuntu22.04+Docker24.0），任何项目不得自建Runner。7.2构建脚本必须在项目根目录放置/.gitlab-ci.yml，阶段包括：lint→unit→sonar→build→container_sign→deploy_staging。7.3质量门禁SonarQube质量阈：Bug≥A、漏洞≥E、代码异味≥B、覆盖率≥80%、重复度≤5%。未通过自动失败。7.4容器签名使用Cosign+Kyverno，镜像必须附加sigstore签名和SBOM（SPDXJSON格式），否则无法推入生产仓库。7.5构建缓存Maven/Gradle/NPM缓存统一挂载到分布式MinIO，保留7天，项目可声明自定义缓存Key，但不得包含SNAPSHOT。7.6构建审计每次构建生成BuildProvenance，上传至Rekor透明日志，供审计代表随时校验。第八章测试管理8.1测试金字塔单元:集成:端到端=70%:20%:10%，预算与工期按此比例分配。8.2单元测试使用JUnit5、PyTest、Jest，必须包含正向+异常+边界，单测文件与源码同目录，命名Test.java/_test.py。使用JUnit5、PyTest、Jest，必须包含正向+异常+边界，单测文件与源码同目录，命名Test.java/_test.py。8.3集成测试使用Testcontainers启动真实数据库、Kafka、Redis，测试结束后必须清理容器，运行时间≤10分钟。8.4端到端测试使用Cypress，在staging环境运行，覆盖P0场景（登录、下单、支付、退款），失败即阻塞发布。8.5性能基线每个API接口的P99响应时间不得劣于上一版本105%，由K6脚本在CI中自动对比。8.6安全测试SCR在release分支使用OWASPZAP做BaselineScan，High及以上漏洞必须修复后方可发布。第九章发布与部署9.1制品晋级只有从main分支构建、且通过全部CI阶段的制品才能晋级到production仓库。9.2蓝绿发布前端静态资源使用CDN+边缘规则，后端服务使用Kubernetes原生蓝绿，切换窗口5分钟，失败自动回滚。9.3金丝雀发布使用ArgoRollouts，按10%、30%、50%、100%四阶段，每阶段持续30分钟，需人工点击Promote。9.4数据库迁移使用Flyway，版本号格式V<版本>__<描述>.sql，必须提供回滚脚本，且先在影子库执行性能验证，>5分钟拒绝上线。9.5发布审批发布前24小时由SRE创建ReleaseTicket，需PO、TL、SCR、QA、SRE五方电子签字，缺任何一人系统拒绝执行kubectlapply。9.6回滚策略提供一键回滚脚本helmrollback<release><revision>，目标RTO≤15分钟，RPO≤5分钟。第十章运行时治理10.1可观测性三大件日志：Loki，保留30天；指标：Prometheus+Thanos，保留1年；链路：Jaeger，保留7天。10.2SLI/SLO•登录接口可用性SLO99.9%；•下单接口P99延迟≤600ms；•每月错误预算=43.2分钟，耗尽即触发“变更冻结”，非热修复禁止发布。10.3告警分级P0：全站不可用，5分钟内电话+短信；P1：核心功能降级，15分钟内飞书；P2：非核心异常，30分钟内工单；P3：一般优化，24小时内邮件。10.4容量管理SRE每月执行一次HPA/VPA巡检，CPU>60%或Memory>70%触发扩容，云账单超预算110%时自动关闭非核心Pod。10.5故障演练每季度一次“GameDay”，随机注入Podkilled、AZdown、数据库慢查询，要求MTTR≤30分钟，事后出具复盘报告。第十一章数据与隐私合规11.1数据分级L4：国密、PCI、GDPRSpecialCategory；L3：PII、KYC；L2：业务日志；L1：公开数据。11.2加密与脱敏L4必须国密SM4加密，密钥存于硬件加密机；L3使用AES-256，展示层脱敏，脱敏算法需可逆申请。11.3跨境传输任何数据离开中国境内需通过SCR评估并签订SCC（标准合同条款），同时在数据流图标注。11.4用户权利响应收到“删除权”请求后，24小时内定位数据，72小时内完成删除，出具回执，全程录像日志保存3年。11.5合规审计每年7月聘请第三方做GDPR/PCI/等保测评，发现问题需在30天内关闭，否则暂停新功能上线。第十二章开源与第三方组件治理12.1准入流程创建ComponentTicket，提供许可证、CVE历史、社区活跃度、Star数、是否双重许可，SCR在3个工作日内批复。12.2黑名单GPL、AGPL、SSPL、WTFPL、任何包含“CommonsClause”的组件一律禁止。12.3版本跟踪使用Dependency-Track，每24小时同步NVD，High及以上漏洞需在14天内升级或打补丁。12.4源代码义务使用MIT/Apache2.0组件需在发布包根目录放置NOTICE文件，列出所有第三方名称与许可证。12.5贡献上游员工向上游提交PR必须经SCR预审，禁止泄露业务逻辑、密码、内部接口。第十三章热修复与应急13.1触发条件P0或P1故障，且影响>30%用户或>10%收入。13.2口述审批TL电话通知SGC主任，获得口头“Go”后，即可从hotfix分支开始，事后补录变更单。13.3流程1.创建hotfix/PROJ-XXXX-YYYYMMDD分支；2.修复代码≤50行；3.MR仅需1名TL+SCR审批；4.跳过staging，直接部署蓝绿；5.验证10分钟无异常后，合并回main并打tag；6.24小时内出具Post-mortem。13.4补偿措施若热修复引入新缺陷，SRE可立即执行rollback，事故等级上调一档，相关责任人当月绩效清零。第十四章配置漂移与基础设施14.1GitOps所有K8sYAML、Terraform、AnsiblePlaybook必须保存在git，main分支即唯一真实来源。14.2漂移检测使用ArgoCD每5分钟做一次diff，发现漂移即自动修复并告警。14.3变更窗口基础设施变更只允许在周二、周四06:00—08:00（GMT+8），其余时间系统自动拒绝apply。14.4状态锁定Terraform使用RemoteState+DynamoDB锁，apply前必须获得MR审批，任何force-unlock需SGC主任书面同意。第十五章质量回溯与持续改进15.1复盘模板1.事故描述（5W1H）；2.时间线（精确到秒）；3.影响范围（用户/金额）；4.根本原因（至少问5个Why）；5.修复方案；6.跟进Action（责任人+Deadline）。15.2改进闭环Action必须录入Jira“Improvement”类型，逾期未完成自动升级至部门总经理。15.3度量指标•千行缺陷率≤0.3；•平均修复时间MTTR≤2小时；•需求响应时间（LeadTime）≤7天；•技术债占比≤5%。15.4激励与惩罚年度质量冠军团队奖励10万元；同一项目一年出现2次P0，TL强制轮岗。第十六章培训与考核16.1入职必修新员工30天内通过“SecureCoding101”考试≥90分，未通过延长试用期。16.2年度演练全员通过“钓鱼邮件+社工

人人文库> 全部分类> 教育资料 > 考试试卷

温馨提示

  • 1. 本站所有资源如无特殊说明，都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等，如果需要附件，请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸，网页内容里面会有图纸预览，若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间，仅对用户上传内容的表现方式做保护处理，对用户上传分享的文档内容本身不做任何修改或编辑，并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容，请与我们联系，我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

最新文档

评论

0/150

提交评论