余鸿靖的手册小站

# 前端技术方案模版

# 模版声明

规范的目的：旨在统一认知和标准化，以及形成技术文档可沉淀、可追溯、可参考。

要求：

  • 针对有重大变更的业务和技改项目，要求提交完整技术方案，由架构师、技术主管等完成review。
  • 本文档包含部分区块可能不涉及到所有项目，请同学选择相关区块填写。
  • 请开发同学尽可能完整的填写，但不是每项必填，针对方案相关性进行考虑。

提交范围：

  • 高投入：涉及到超过30人日以上开发周期的需求，技术主管可以判断
  • 影响大：对业务有重大影响的需求
  • 有重大技改：包括领域模型的改造、基础设施选型变化、有重大容量变化的
  • 有新增成本：如新申请应用、重大的扩容需求等

原则上仅有评审通过的技术方案可以申请新的资源、申请变更、进行发布。

# ChangeLog变更记录

技术方案也要有变更记录，记录关键性的变更内容摘要说明。

版本号 变更人 变更时间 变更备注
V 1.1 XX 2022-04-01 初始化版本
V 1.2 XX 2022-11-22 3、4 章节结构调整

# 1. 业务背景和目标

# 1.1 需求背景

概要描述需求内容。这里可以放上需求设计稿的附件地址等

可以包括业务/系统现状、需求分类和拆解、需求必要性等信息

# 1.2 衡量标准

业务价值：业务需求上线后衡量标准，提供价值公式，并提供每个变量的业务口径、取数逻辑。需要和产品确认。

技改项目：明确技改针对系统稳定性、可扩展性、性能、效率、安全等几个维度的提升

# 2. 相关人员

明确项目PM、测试、PD等责任人

# 3. 整体技术方案

# 3.1 技术调研和选型

参考业界案例和技术选型进行对比分析，针对需求确定最终的技术方案

可选择2+的方案进行对比和分析，最终确定整体架构设计以及设计内容

明确以下内容：

  1. 投放场景
  2. 容器类型
  3. 开发模式（搭建、源码）
  4. 模块方案

# 3.2 架构设计

涉及上下游页面、模块以及其变化

针对需求依托技术实现角度考虑进行业务细化分析，参考以下几项按需填写即可：

# 3.2.1 技术大图

# 3.2.2 功能拆解

页面、模块拆分

# 3.2.3 数据输入输出

页面数据来源

页面、模块间数据流转

# 3.2.4 关键 UI、交互

定制容器、组件

动画

# 3.2.5 外部依赖

关键组件

客户端能力

# 3.3 接口字段/数据协议等变更

若有变更，进行数据兼容的详细设计分析。包含新代码对老数据兼容处理方案，以及一旦回滚老代码处理新数据的兼容处理方案。

  • 关键数据结构

# 3.4 数据指标方案

明确录入需要采集的业务和技术指标，如埋点、监控、报表等，确保项目上线后有必要的数据支撑。

尽量避免先上线，后补数据的场景。

  1. 业务埋点：关键指标涉及的埋点
  2. 技术监控指标：性能、稳定性
  3. AB实验指标

# 3.5 灰度、兼容方案

明确要求：实现代码变更及配置变更均需要具备可灰度能力（可考虑选项：beta、安全、业务白名单、人群圈选、百分比等）。

评估要包含以下几个维度：

  1. 接口兼容性：要求涉及到系统间数据传递的场景要保障数据结构兼容，如消息体、接口返回值等
  2. 数据兼容性：要求新代码兼容老数据、老代码兼容新数据
  3. 容器兼容性：客户端、浏览器版本要求、降级兼容方案
  4. 回滚策略：如果出现任何问题，是否有快速回滚/降级能力，是否对业务有损

若无法做到灰度需要有变更审核机制

# 3.6 性能评估

描述实现需求涉及到的影响性能关键因素，包含：

  • 加载性能

    • 代码加载（页面、动态模块）
    • 数据加载
    • 资源加载（图片、字体、动画等）

  • 渲染性能

    • 复杂计算逻辑（CPU、 内存、FPS）
    • DOM 操作

# 3.7 迁移方案

重点描述系统迁移涉及到的改造点，至少包含以下几点：

  1. 代码迁移方案

# 4. 详细设计【可选】

建议以业务模块为维度，选择关键模块，详细描述实现方案、改造点，包含以下内容：

  1. 数据输入输出

    1. mock 数据
    2. 模块间通信

  3. 关键 UI、交互实现

    1. 定制容器、组件
    2. 动画

  5. 外部依赖

    1. 关键组件
    2. 客户端能力

# 4.1 业务模块 A

# 4.2 业务模块 B

# 5. 技术风险分析

# 5.1 稳定性风险评估

# 5.1.1 页面稳定性评估（异常监控）

稳定性分析，需要包含以下部分：

  1. 关键异常处理（接口异常、交互输入输出异常、模块加载异常等）
  2. 部署相关风险（域名跨域、缓存离线包 到达率等）

# 5.1.2 监控完整性和有效性（业务监控）

要求明确具备业务核心指标的监控能力，包括：业务量级、业务成功率、业务响应时间、趋势、时效等

要求明确完成核心告警项的配置

有P级故障可能性的要重点review

#

# 5.2 安全风险评估

# 5.2.1 资金安全

如果业务涉及到资金、权益等链路，需要完成资金安全评估，需要明确包含几部分：

  1. 价格相关，不允许前端价格计算

# 5.2.2 内容安全

  1. 内容安全：需要明确内容安全方案。

# 5.2.3 系统漏洞

  1. CORS、XSS 等安全风险
  2. 接口安全：建议对外接口增加基于业务身份的权限控制和限流，保障无预期外的调用，避免接口被滥用
  3. 操作记录：针对人工操作的系统，要有操作记录日志。
  4. 权限控制&审批流：针对配置系统，要求有明确操作链路，不允许未经审批的配置变更
  5. 防爬：确保对外读接口有防爬机制，用户侧接口权限控制

# 5.2.4 合规安全

  1. 用户隐私：是否涉及用户隐私类数据，要明确数据收集链路和下游数据使用链路，确保用户授权的有效性
  2. 价格歧视：针对和价格、优惠相关的业务，要避免针对不同的用户产出不同的价格或优惠。如果有业务必要性必须报备审核。
  3. 数据隔离：针对平台型应用，要确保上层支撑业务的数据可以被隔离

# 5.3 应急方案设计

  1. 涉及业务关键链路节点的代码及配置变更（存在高级别故障风险的）具备1分钟发现、5分钟止血、10分钟修复/回滚的能力，方案包括：开关控制、版本控制、动态加载等动态变更方案。
  2. 如涉及资金处理或客诉场景，要明确具备：安全布防、核心数据具备数据捞取、业务熔断、差错处理（撤销、重做、订正）等设计

# 5.4 开关 / 预案清单

开关 / 预案名 系统 类型 描述（包含影响范围） 链接
switch：放量 / 降级预案：提前 / 紧急

# 5.5 技术风险review检查清单（待逐渐完善）

清单 结论(是/否/不需要)

# 6. 测试范围分析

# 6.1 关键测试点

在此强调开发希望测试能关注的关键测试点

如果有测试用例可以贴入链接

如果是可以自测的需求，要明确自测方案

# 6.2 验收标准

  1. 预发：

    1. 自动化测试回归完成
    2. 预发产品预演、PD验收完成
    3. 视觉走查完成
    4. 配置项检查完成，重点关注预发和线上配置不一致的场景（如url）
    5. 运营设置检查，特别是涉及到时间、资金等配置

  3. 发布上线：

    1. 安全生产环境验证
    2. 线上业务方验证（5G环境下）
    3. 发布后1小时内日志监控
    4. 发布后页面巡检

# 7. 发布计划流程

# 7.1 发布时间和顺序

服务端和前端/客户端的发布时间节奏、依赖关系、重点执行事项等

要求在最终发布前完成Code Review流程，确保实现和方案的一致性。需要邀请主管、技术主管、架构师

分支/配置 发布时间

# 7.2 灰度/放量过程

如果有多次灰度、放量的过程，增加灰度方案，监控项等

灰度比例 时间
0.1%
1%
10%
20%
50%
80%
100%

# 7.3 回滚方案

  1. 发布期间的回滚方案
  2. 放量期的回滚方案

# 8. 评估意见

评审日期 参与人员（包括主管、TL、架构师） 评审意见（通过/不通过）
包括具体需要完善的事项

# 9. 技术方案申请变更

核心流程如下：

技术方案review--> 安全生产接口人 && 技术主管/主管等评估 && 邀请架构师评估--> 老板

最近更新时间: 2023/7/24 20:46:22

← 更新日志规约 →