技术管理计划共享：技术部门结构管理流程

目的

• 为了严格控制公司使用到的所有技术，保证技术的先进性、统一性和规范性，所有技术的引入与退出均需经过严格的评估与审批，确保技术架构的一致性。
• 为了加强系统新增或变更的研发管理力度，整体层面管控技术&架构的合理性，提高系统设计质量，降低研发成本，确保系统新增或变更的可控性、规范化、流程化。

适用范围

本规范适用于技术部门所有技术的引入与退出；

本规范适用于应用系统及子系统的新增或变更。

术语解释

• 新技术：公司目前技术部未应用到的技术，需要从外部引入，均统称为新技术。包括但不限于：硬件、开源软件、商用软件，中间件，开发语言、基础组件等。

• 系统：由一些相互联系、相互制约的若干子系统组合而成，能够完成一种或多种功能的一个整体。注意区分系统、关联系统、子系统间的关系。

• 子系统：系统的组成部分，一个或多个子系统组成完整的系统；

• 新增系统/子系统：指现有应用架构，已无法满足新需求的实现或实现起来应用架构存在不合理，需要增加新的系统/子系统来满足需求；

• 变更系统/子系统：指现有应用架构虽可以满足需求，但从应用架构整体层面出发，存在架构优化的可能，比如：系统间的合并，系统定位的变化，系统级别的变更、系统的重新划分等。

技术管理

研发各个团队使用到的所有技术实行管控机制，由架构部负责梳理公司应用到的所有技术，并形成技术基线。后续所有技术的引入/退出，均按照要求走相关的评估和审批流程，由架构部更新技术基线后，技术才能正式引入/退出。

技术引入/退出管理流程如下：

技术引入/退出需求评估

技术部任何部门任何人员都可以发起技术引入/退出的需求申请，在发起正式的技术引入/退出申请前，申请人应在部门团队内初步调研及确认可行性，并编制完成“技术引入/退出的可行性报告”后，组织进行技术引入/退出评估（会议或邮件均可）。

新技术引入的可行性报告中必须包括:

• 技术引入的必要性、优势、劣势或约束限制

• 测试结果分析

• 可运维/可观测性分析

• 风险评估，包括：身份识别、访问控制、操作日志等安全性风险、法律等风险。

开源软件的引入，采用《开源软件评估工具表》，对备选的开源软件进行评估。若评估结果低于60分，则不再考虑使用该开源软件；若备选开源软件评估结果均高于60分，则选择评估结果最高分的开源软件。

评估要点如下：

• 组织方：申请方发起并组织技术引入/退出；
• 参与方：申请方、架构部、SRE、安全管理团队、技术委员会核心成员。

注意：

• 申请方根据实际情况评估技术引入/退出的必要性；
• 架构部对所有技术的引入与退出负责，评估技术的必要性、可行性及对现有系统的影响等。
• 安全管理团队评估技术引入/退出是否存在安全 风险 ，输出《技术引入/退出风险评估表》；
• SRE评估引入的技术是否可维护，退出的技术是否影响线上运行的系统；
• 评估方除申请方和架构部是必须的，其他部门根据引入/退出的技术不同，自行选择是否需要参与评估。也可邀请多个业务条线研发leader/架构师参与评估。
• 输入：《技术引入/退出的可行性报告》（申请方编制）
• 输出：“技术引入/退出评估报告/结论”、《开源软件评估工具表》（申请方编制并发布）

注意：原则上评估会成员一致通过，评估结论才能通过。任何一方有异议，在异议解决后，才能确定评估通过。 架构部有一票否决权，其认定不符合技术引入/退出要求的，可直接确定评估不通过 。

技术引入/退出申请

线下评估通过后，由申请方发起正式的技术引入/退出申请。

新技术引入审批流程如下：

申请人—申请人所在部门负责人—安全管理团队负责人—架构部部门负责人—CTO

已用技术退出审批流程如下：

申请人—申请人所在部门负责人—安全管理团队负责人—架构部部门负责人

流程审批通过后，申请方可正式实施技术引入或技术退出。

注意：

• 仅在新技术引入时，CTO进行审批。技术退出时，由相关部门负责人审批即可，无需CTO进行审批；
• 申请时明确：技术的名称、用途、优点、缺点、限制条件（引入/退出该项技术的限制因素）、影响分析（对现有系统的影响）、 风险 分析（对现有系统的风险）等；
• 暂定通过邮件申请的流程进行，申请中必须上传线下《技术引入/退出评估的报告/结论》作为附件，以便审批人作为审批的依据

更新技术基线

技术引入/退出申请审批通过后，由架构部的架构师更新技术基线，同时申请方着手实施新技术的引入或现有技术的退出。

注意：

• 现有技术的退出，若涉及到多个系统，如基础框架、基础组件类技术，由架构部拟定整体退出计划，并制定技术退出实施方案，有序地实施技术退出，避免对业务产生影响；

• 新技术的引入，若需要进行全公司的推广，由架构部拟定推广实施计划，在全公司实施新技术的引入。

系统架构管理

系统架构管理流程

需求评估

提出需求

由业务方提出原始需求到技术部或项目管理部。此处定义的业务方是广义的说法，涵盖公司所有提出需求的部门，例如：产品、技术部内部、运营、法务、财务、合规、信息安全等部门。需求既包含了业务系统需求，也包括了一些基础系统或自非业务系统。

接收需求

原始需求接收部门可能是项目管理部或者技术部各研发条线。某些规划设计类的大型产品项目，可能优先会提交到项目管理部，若是项目经理先技术部各条线接收到此原始需求，需要尽快将需求信息同步给技术部对应条线，以便技术部对需求进行初步评估。

内部需求评估

技术部相关条线接收到此需求后，经过初步的分析与评估，发现现有应用架构已经无法满足需求，或者需求在现有应用架构中实现起来不友好，需要进行系统/子系统的新增或变更。

若确认需要新增系统、子系统或变更系统、子系统的划分，根据新增/变更的不同类型，系统技术负责人的指派应遵循以下原则：

• 新增系统：前期无系统技术负责人，需要技术负责人指派新的系统技术负责人来负责此系统的研发过程；
• 新增子系统：因前期该子系统所属系统已存在技术负责人，所以无需发起新的技术负责人指派申请，由所属系统的原技术负责人负责即可；
• 变更系统/子系统：无论是变更系统还是子系统，因前期都有相应的技术负责人负责，因此也无需发起新的技术负责人指派申请，由所属系统的原技术负责人负责即可。

初步评估不通过，流程直接终止。

系统架构评审

  指派/知会项目经理

若确认需要新增系统、子系统或变更系统、子系统的划分，根据新增/变更的不同类型，项目经理的指派/知会应遵循以下原则：

• 新增系统：前期无项目经理，需要技术部系统技术负责人向项目管理部发起项目经理指派请求，由项目负责人指派新的项目经理来进行此新系统的管理活动；

• 新增子系统：因前期该子系统所属系统已存在项目经理，所以由所属系统的原项目经理担任即可，系统技术负责人仅知会该项目经理将开发新的子系统；

• 变更系统/子系统：无论是变更系统还是子系统，因前期都有相应的项目经理管控，所以依然由所属系统的原项目经理担任即可，系统技术负责人知会该项目经理将变更系统/子系统。

  组织架构评审

项目经理接收到新增系统、子系统或变更系统、子系统的划分的需求时，发送架构评审会议通知。通知内容包括但不局限于以下内容：

• 会议时间；
• 会议地点；
• 必须参会人员：项目经理、系统技术负责人、架构部架构师、信息科技安全管理团队、业务方（包括原始需求提出方、产品经理）、系统运营；
• 选择性参会人员：项目负责人、技术负责人、应用架构负责人、信息科技安全管理团队负责人以及涉及的开发人员；
• 会议资料：需求说明文件、《系统架构设计方案（接收需求研发方编制）

注意：需求说明文件由产品方初步拟定，技术提案由技术方初步拟定，两份文件作为架构评审的基础资料。

3. 架构评审会决议

项目经理按照架构评审会通知，组织相关人员召开架构评审会。架构评审会中应明确：

• 新增系统、子系统或变更系统、子系统划分的必要性；
• 新增系统、子系统或变更系统、子系统划分的可行性；
• 新增系统、子系统或变更系统、子系统划分的合理性；
• 新增系统、子系统或变更系统、子系统划分的风险性。

架构部架构师从公司整体架构层面出发，评估新增或变更系统/子系统的必要性和合理性，且架构部架构师有一票否决权。架构评审报告结论为通过，项目经理/系统技术负责人可以发起新增/变更系统申请；架构评审报告结论为不通过，流程直接终止。

运维/SRE团队作为系统上线后的主要负责人，负责维护系统正常的运行、日常巡检、容量监控、可用性监控、主动预防等，在系统存在重大变更或者新增子系统的情况下，必须要求运维/SRE人员参与架构评审。

新增/变更系统申请与审批

  发起新增/变更申请

系统架构评审会决议通过的情况下（评审报告结论为通过评审），由项目经理/系统技术负责人发起正式的新增系统、子系统或变更系统、子系统划分的申请。

系统设计与评审

  系统详细设计

系统/子系统新增或变更申请通过审批后，由项目经理通知技术负责人组织人员编制系统详细设计说明书，详细设计中应包括以下内容：

• 若是新增系统，应明确说明此系统包含了哪些子系统，各子系统的功能划分；
• 若是新增子系统，应明确说明此子系统实现的功能，在系统中的功能划分；
• 若是变更系统、子系统，应明确说明变更前后的功能对比，以及系统功能划分差异；
• 应明确系统设计的要点（包括数据库设计、API接口设计等）、流程逻辑；
• 应明确系统或子系统中使用到的所有技术、组件与版本、框架等；

备注： 应用架构 师应重点关注，使用到的技术、组件、框架是否符合公司现有要求

• 系统上线的资源配置要求。（提供给运维/SRE团队评估）

  组织详细设计评审

系统详细设计编制完成后，由系统技术负责人告知项目经理，项目经理发起详细设计评审会议通知。通知内容包括但不局限于以下内容：

• 会议时间；

• 会议地点；

• 必须参会人员：项目经理、系统技术负责人、核心开发人员、核心测试人员、业务架构师（由架构部指派）、业务方（主要是产品经理）、运维/SRE；

• 会议资料：系统详细设计文档

  详细设计评审会决议

项目经理按照详细设计评审会通知，组织相关人员召开详细设计评审会。设计评审应重点关注以下内容：

• 设计中使用到的技术进行评估，确保不与现有应用架构中的要求相悖；
• 设计中使用到的组件以及版本，尽量确保是目前架构部推荐使用的组件及版本；
• 系统设计的框架，确保是架构部推荐使用的框架；
• 上线的资源配置，确保取得业务运维的认可；
• 确保系统设计中的定位，与前期的架构评审会以及新增/变更申请中的内容保持一致。

系统详细设计评审过程中，架构部有一票否决权。详细审计评审报告结论为通过，系统正式进入开发过程；详细设计评审报告结论为不通过，则技术负责人安排人员根据评审意见修订详细设计，修订完成后通知项目经理再次发起详细设计评审。

系统研发

系统详细设计通过评审后，系统正式进入研发阶段，包括开发、测试、业务验证、上线部署、线上验证等环节。