大数据平台开发规范示例
一、前要
内容包括但不限于平台对内和对外的需求、代码开发、测验和上线流程规范。
以大数据技术平台架构的视角，梳理如何与数仓、数据分析同学协作的规范示例，仅供参考。
二、环境信息
首先需要梳理出各组件的部署方式、host及版本等信息，让其他平台、数仓或数据分析同学了解平台底座的部署情况。
三、需求流程
3.1 主流程
整体需求主流程如下。
3.2 需求发起
3.2.1 需求发起人
包括但不限于如下人员。
- 数仓开发
- 数据分析
- 数据产品
- 内部人员（主动挖掘）
3.2.2 需求类型
- 业务需求：需要通过组件支撑的业务需求，例如应用脚本开发
- 组件功能需求：组件功能扩展，例如connector扩展或造轮子
- 组件bug需求：由于组件设计缺陷或版本自身缺陷导致的bug，需要结合社区和源码进行解决
3.2.3 需求渠道
Tapd/DevOps/禅道（协作管理平台）
主要为组件bug需求，例如提交地址：数据平台_线上BUG汇总
飞书/钉钉/企业微信（企业办公平台）
主要为紧急且重要的问题/需求，可通过DA（数据需求入口群）、问题群或私聊反馈（允许私聊/私活，但需要内部互通，避免信息差），当前相关问题会记录于统一锚点：新集群问题记录
线下沟通
较为繁杂的需求可通过线下沟通，需要进行拆解和确认，例如：数仓需求记录
3.2.4 需求对接人
如果团队当前还处于发展中未成熟阶段，不建议采用【统一对接人】的方式，可采用【一主多从】的策略，即除团队负责人外，其他成员都可以为’需求对接人’，但无论谁是’需求对接人’，都需将需求记录于【需求池】，避免信息差。
- 团队负责人
- 组件责任人
- 每个组件的管理（技术支持/答疑）需要指定第一责任和第二责任人
- 需求池
- 对需求的记录，避免需求丢失，有助于建立清晰的需求回溯，需求池记录列表：大数据平台需求池
3.3 需求处理
3.3.1 内部评估
对于可快速响应和处理的小需求可跳过这步及后续的流程，例如doris因为大sql内存oom而导致读写失败的问题
对于无法快速响应和处理的需求，需要由对接人组织临时会议，进行内部评估，例如doris升级事项
内部评估需要确认事项
需求是否合理及是否需要进行后续处理
明确需求优先级
明确需求处理人
3.3.2 计划排期
- 由需求处理人根据需求优先级进行排期，并反馈给内外部相关人员
3.3.3 方案评审
- 由需求处理人输出方案，方案形式可采用列表、123陈述、流程图或文档形式
- 对于复杂需求/项目可先后输出概要和详细方案，例如需要自研中间件或应用系统底座等
- 由需求处理人组织，评审方式可在座位上或会议等形式进行
- 参会人员必须两人或两人以上，视需求而定是否需要拉上发起人
3.3.4 开发交付
- 根据排期时间进行开发、测试及交付，如若因其它紧急事项需优先处理，可协调顺延
- 具体流程参考如下【开发流程】
