一、 目的
为了在软件生命周期内规范数据库相关的设计、开发、运维工作，便于不同团队之间的沟通及协调，制定此文档，以期在相关规范上达成共识和默契，提升相关环节的工作效率及系统的可维护性。同时好的规范，在执行的时候可以培养出好的习惯，好的习惯是软件质量的很好保证。
二、 使用范围
本文档适用于研发人员、运维开发成员、DBA等所有能接触数到据库的人员。
三、 数据库管理人员规范
3.1、环境信息介绍
DEV:开发环境
SIT：系统集成测试环境
UAT：用户验收测试环境
PRD：生产环境
PET：压测环境
TEP:临时测试环境，主要用于及时回收
OTHER：其他环境，JenKins、Airflow，不涉及数据库组件相关
3.2、实例申请流程&标准架构
3.2.1、申请流程
【要求】申请实例请注意如果没有使用量情况下尽量复用，可以后续迁移/独立出来；同时实例申请时给出业务量、QPS、TPS预估、特殊跑批情况说明等。
案例：一个数据库实例一张表，3.6W数据，造成资源浪费及增加不必要的维护成本。
【要求】资源申请流程
3.2.2、部署架构
【要求】标准部署架构及实例数量参考标准如下：
【要求】切记UAT环境需要保持和生产环境一致；并且涉及到生产环境改造，必须在UAT环境先进行改造验证，之后升级生产环境。
【建议】针对产品型系统、非供应商驻场开发、迭代缓慢（例如：一年例行更新一次）的情况，可以酌情及时释放非PRD环境，如有需要再申请重建数据库相关资源；需要BA确认。
【建议】对于开发人员dev等开发环境申请，尽可能复用现有自己已有环境；比如：开发团队A，已有环境DEV_A,现在另外项目需要MySQL_B,项目组成员尽可能在DEV_A新建schema即可完成项目需求；无限再次申请。若项目上线期间，两个完成不同的项目可以单独申请单独部署。
【建议】DEV、SIT环境如果没有特殊要求，尽可能保持一个一套环境。
3.2.3、基础架构变更
【要求】如遇到数据库、中间件、分布式、大数据等参数调整、重启服务、配置文件修改、优化、升级等涉及基础架构变更，需要进行OA工单申请，经审批后方可操作。
【要求】申请内容包含变更原因、影响范围、变更影响时间、操作人、关联方等主要内容。
【要求】OA工单入口：ITSM-》基础架构变更流程
3.3、部署
3.3.1、配置模板、系统参数调整
【要求】标准参数配置模板，详细见confluence体现，避免随意修改；如有必要提出标准化调整。
【建议】部署方式1、参考现有Ansible脚本推送方式；2、手工部署；但前提必须配置、系统参数按标准化模板
【要求】如超出标准范围，需要邮件申请，（比如：Redis生产环境只支持单机模式，不支持sentinel模式）。
【要求】UAT、PET、PRD环境保持一致、DEV、SIT尽可能单机即可。
【要求】如模板参数需要变更、或部署方式变更等等，需要团队成员会议讨论后，形成标准，记录在confluence；例如mysql5.7集群模板_20210314
3.3.2、部署
【要求】针对MySQL高可用集群（VIP+Proxysql+Orchestrator+MySQL），部署架构如下：
1、 业务无单独从库使用：主+备+从（DBA）+北京从库。
2、 业务抽数、读写分离主：主+备+从（DBA）+北京从库；只读、读写分离从库不参与切换。正常情况下3+1模式。 如自动切换后，待原主库恢复正常之后手工切回。
其中：主备可以互切换
3.3.3、实例版本
特别在业务招标过程中，经常会遇到供应商系统过于老化，给出的标配版本过于老旧；使用过旧的版本很大程度上供应商没有精力迭代自己的产品，或投入过少。
【要求】所有版本组件避免过于老旧（官方已放弃更新、版本更新频繁，使用N年前版本）。
【要求】所有版本组件避免过于最新版本，最多可以选择次新稳定版本，除非特殊需求外（如系统漏洞）避免踩坑。
【要求】当前各个组件版本列表，资源配置默认最小化，运行过程中如有需要增加走OA单独申请。默认资源配置:开发环境应低一档次。
【建议】非功能性评审过程中增加对组件版本要求，避免供应商要求的组件版本过低。
3.3.4、实例规格参考
3.3.4.1、MySQL规格
3.3.4.2、MongoDB规格
3.3.4.3、Redis规格
3.3.4.1、ElasticSearch规格
3.4、账户权限
【要求】严格把控好管理权限，只将管理权限赋予管理员。
【要求】禁止有 super 权限的应用程序账号存在。
【要求】禁止有 DDL、 DCL 权限的应用程序账号存在。
【要求】部署完系统，给出的账号DEV、SIT至少两个（应用账号、个人使用账号），并注明账号用途；对于UAT、PET、PRD默认１个应用账号，如需个人账号单独申请，且权限最小化。
3.4.1、个人账户
【要求】DEV、SIT：数据库Owner权限。
【建议】UAT、PET、PRD： 仅SELECT权限，超出范围OA另外单独申请。
3.4.2、应用账户
【要求】DEV、SIT、UAT、PET、PRD：INSERT/DELETE/UPDATE/SELECT/EXECUTE；
【要求】如需要超出增删改查之外，如DDL权限应做以下限制：
1、 上会评审，确认业务需求，明确使用范围；并且在授权时限制白名单。
2、 限制使用场景
由于：大表增加列、索引等情况可能会造成线上阻塞情况；增加字段如before、after场景不适用等等……
3.4.3、账户命名规则
【要求】个人账户：精确到个人；比如GRANT SELECT ON TEST.* TO ’qiaoyujin’@’%’;
【要求】应用账户：应用、业务名称；
【要求】其他应用类似抽数使用，需要精确到具体表名；比如数仓抽数使用GRANT ALL SELECT ON table.* TO ’dwh’@’%’;
【建议】应用本身使用，应使用应用缩写；比如cbp_write
3.4.4、权限申请
【要求】OA提交变更申请（OA->基础架构->数据库）
【建议】必要条件：业务系统、schema、业务表名（不建议全部授权），特殊需要，特殊审批。
【要求】UAT、PRD环境一致，在创建PRD环境时，直接将UAT环境权限、用户COPY到PRD 环境。后续变更需业务团队单独提出申请。比如：业务运行一段时间，业务提出UAT增加drop权限，PRD环境需要业务团队OA申请单独授权。
【要求】权限最小化原则
【要求】访问路径除DEV环境外，本地办公环境禁止开通数据库相关端口访问，必须指定通过堡垒机访问数据库。
3.4.5、密码规则
【要求】 所有组件需要密码认证的情况下，必须适配认证机制；且密码不能过于简单（123456、888888等等）。
【要求】密码要求8位以上，包含数字、字母（大、小写）、特殊字符
【要求】密码特殊字符“！”，“@” ，“#” ，“$” ，“%”等除外，只允许包含指定下划线“_” ，如7yrREE123_123
3.4.6、账号申请模板
事由：XXXX
账号类型：应用使用/个人使用
数据库类型：Oracle/MySQL/SQLServer
绑定白名单：数据库访白名单（127.0.0.1
数据库地址：127.0.0.1
数据库名称:db1
申请表名:ALL/table_1;table_2;table_3…………（遵循权限最小化原则）
账号名称：应用账号（应用名称_标识符）、个人账号（个人姓名小写全拼）
账号权限：(如:SELECT, INSERT, UPDATE, DELETE, EXECUTE/SELECT/其他)
说明:一般个人仅只读SELECT权限；
应用账号：SELECT, INSERT, UPDATE, DELETE, EXECUTE
3.4.7、账号回收
【要求】 用户因离职、岗位调动等原因而不允许使用原账号时，不论原用户是否知晓或同意，系统管理员应当及时注销该用户个人账号并回收权限。禁止将原个人账号转交其他人员继续使用。
【要求】账号回收涉及对象包含内部员工、外包员工，凡涉及到数据库账号者。
3.5、发版
3.5.1、变更申请
【要求】需要提前和数据平台同学预约，以便留人值守，特殊情况除外。
【要求】评审完之后，建议BA同学提前发出上线脚本，便于提前审核评估。
【要求】OA提交变更单入口：
注意:所有流程待审批完成之后方可执行。
【发版】发版流程如下：待确认
【要求】脚本变更后，如业务需要增加变更脚本，需重新提交变更单。
【要求】业务团队目前只有DEV、SIT脚本执行权限；UAT、PRD执行权限全部由数据平台团队完成；区别在于UAT：邮件申请；PRD需要OA申请审批。
【要求】若DBA同学开发代码需要线上执行，必须由另外一个同学协助执行，便于互审。
【要求】如发布单子漏发SQL，需要重新提交OA申请。
【要求】申请模板如下：
应用名称：新核心
IP：127.0.0.1
数据库：cbb
变更原因：由于新核心上线移植数据中存在部分还款方式为等额本息，但是含有尾款的合同；会导致新核心对应的尾款展期业务无法处理；因此需要修正此部分合约；
附件SQL：上传SQL脚本
【要求】数据变更，需要单独申请数据库变更单，禁止和业务发布单合并发布，DDL变更可以可业务变更合并发布。
3.5.2、执行变更
【要求】对于普通主从复制，进入主库执行；采用show salve hosts、show processlist查看
【要求】对于高可用集群proxysql,避免
