所谓架构大佬是研发部门说话算话的，我想架构大佬是每个程序员的梦想，那么怎么才能成为这样的人呢？我所在的公司也是一个知名的IT公司，而本人恰好在架构总监下面工作，我经常总结他的一些考虑问题的方式，以及一些流程，在这里给大家分享一下，今天分享技术引入/退出管理流程。
技术引入/退出管理流程
技术引入/退出需求评估
技术部任何部门任何人员都可以发起技术引入/退出的需求申请，在发起正式的技术引入/退出申请前，申请人应在部门团队内初步调研及确认可行性，并编制完成"技术引入/退出的可行性报告"后，组织进行技术引入/退出评估（会议或邮件均可）。
新技术引入的可行性报告中必须包括:
-
技术引入的必要性、优势、劣势或约束限制
-
测试结果分析
-
可运维/可观测性分析
-
风险评估，包括：身份识别、访问控制、操作日志等安全性风险、法律等风险。
开源软件的引入，采用《开源软件评估工具表》，对备选的开源软件进行评估。若评估结果低于60分，则不再考虑使用该开源软件；若备选开源软件评估结果均高于60分，则选择评估结果最高分的开源软件。
评估要点如下：
- 组织方：申请方发起并组织技术引入/退出；
- 参与方：申请方、架构部、SRE、安全管理团队、技术委员会核心成员。
注意：
- 申请方根据实际情况评估技术引入/退出的必要性；
- 架构部对所有技术的引入与退出负责，评估技术的必要性、可行性及对现有系统的影响等。
- 安全管理团队评估技术引入/退出是否存在安全 风险 ，输出《技术引入/退出风险评估表》；
- SRE评估引入的技术是否可维护，退出的技术是否影响线上运行的系统；
- 评估方除申请方和架构部是必须的，其他部门根据引入/退出的技术不同，自行选择是否需要参与评估。也可邀请多个业务条线研发leader/架构师参与评估。
- 输入：《技术引入/退出的可行性报告》（申请方编制）
- 输出："技术引入/退出评估报告/结论"、《开源软件评估工具表》（申请方编制并发布）
注意：原则上评估会成员一致通过，评估结论才能通过。任何一方有异议，在异议解决后，才能确定评估通过。 架构部有一票否决权，其认定不符合技术引入/退出要求的，可直接确定评估不通过 。
技术引入/退出申请
线下评估通过后，由申请方发起正式的技术引入/退出申请。
新技术引入审批流程如下：
申请人---申请人所在部门负责人---安全管理团队负责人---架构部部门负责人---CTO
已用技术退出审批流程如下：
申请人---申请人所在部门负责人---安全管理团队负责人---架构部部门负责人
流程审批通过后，申请方可正式实施技术引入或技术退出。
注意：
- 仅在新技术引入时，CTO进行审批。技术退出时，由相关部门负责人审批即可，无需CTO进行审批；
- 申请时明确：技术的名称、用途、优点、缺点、限制条件（引入/退出该项技术的限制因素）、影响分析（对现有系统的影响）、 风险 分析（对现有系统的风险）等；
- 暂定通过邮件申请的流程进行，申请中必须上传线下《技术引入/退出评估的报告/结论》作为附件，以便审批人作为审批的依据
更新技术基线
技术引入/退出申请审批通过后，由架构部的架构师更新技术基线，同时申请方着手实施新技术的引入或现有技术的退出。
注意：
-
现有技术的退出，若涉及到多个系统，如基础框架、基础组件类技术，由架构部拟定整体退出计划，并制定技术退出实施方案，有序地实施技术退出，避免对业务产生影响；
-
新技术的引入，若需要进行全公司的推广，由架构部拟定推广实施计划，在全公司实施新技术的引入。