1. 银行复杂架构下的数据库敏捷运维 演讲人：王鹏冲 全球敏捷运维峰会 广州站

2. 王鹏冲 平安银行总行科技运营中心数据库技术总监 个人简介： 16年数据库领域工作经验，历任多家公司数据库技术负责人、团队总监 Oracle 10g OCP，MySQL OCP 2015-2017连续三届PostgreSQL全国大会演讲嘉宾 2018年MongoDB中文社区演讲嘉宾 GOPS、dbaplus、Gdevops等技术社区分享讲师 微信公众号《数据库技术圈》发起人 全球敏捷运维峰会 广州站

3. 目 录 CONTENT 1 概论 2 开发 3 运维 4 展望

4. 01 概论 Database DevOps 全球敏捷运维峰会 广州站

5. 银行数据库架构有多复杂？ 1 DB类型 10-20种 DB类型不同，人员技能、开发设计、发布部署、配置规范、运维工 具、变更方案、自动化流程等，都会有差异 2 实例规模 数以万计 生产、同城、异地、开发、测试、灰度等不同环境的大量实例，带 来的是运维管理的复杂度、标准化落地的难度 3 DB版本 新旧并存 4 OS类型 Unix、Linux、Windows 不同平台的配置基线、采集监控、报警指标、应急处理等都要有针 对性设计 5 开发模式 外购+自研 大量外购商业软件的存在，使得对DB的应用层的优化手段有限，DB 重构、去IOE困难重重 6 DB架构 集中式、分布式 分布式架构的数据库运维带来与传统集中式架构不一样的需求与问 题，比如审核、灰度发布、批量回滚等。 01 概论 新旧版本并存，对补丁管理、安全漏洞、迁移升级等都带来挑战 全球敏捷运维峰会 广州站

6. 数据库怎样 融入DevOps基因 全球敏捷运维峰会 广州站

7. 传统数据库开发、发布方式 存在的问题 全球敏捷运维峰会 广州站

8. 将数据库集成到 DevOps流水线的挑战 全球敏捷运维峰会 广州站

9. 企业实施DevOps的 阻碍因素 全球敏捷运维峰会 广州站

10. DevOps 谁说了算？ 全球敏捷运维峰会 广州站

11. 02 DevOps：面向开发 打造涵盖数据库开发设计、代码审核、 部署测试、生产发布的一条龙生产流水线 全球敏捷运维峰会 广州站

12. 以前的发布流程： 1. 开发人员将应用程序打包，并按顺序汇总并整理数据库发布脚本。线下传递 脚本或缺乏审核。 2. DBA拿到数据库发布脚本检查、备份、执行，以完成数据库发版。 3. 部署人员拿到应用部署包，备份、替换，以完成应用程序发版。 引入DevOps之后的发布流程： 1. 开发人员将应用程序、DB代码在CI工具中完成上传、代码审核、打包。 2. 部署人员拿到部署任务，在发布系统中完成DB发版以及应用包部署。 全球敏捷运维峰会 广州站

13. 数据库制品流水线 建模工具 测试环境 集成测试平 台 生成DDL、DML 数据库审核与 发布工具DBgo 移交发布 全球敏捷运维峰会 广州站 代码库 集成发布平台 Lotus 生产环境

14. 一、数据建模工具-DDM 目标 问题 快速建模 缺少统一工具支持 数据标准落地 ● 支持逻辑模型和物理模型的可视化建模， ● 与数据标准库、词根库拉通，可实现 快速编辑表，字段，主外键索引，视图等 数据标准智能发现及数据标准引用， 对象，支持模型全生命周期管理 提升建模质量。 建模与数据标准脱节 模型共享 数据模型无法共享 ● 模型可以跨系统、团队共享，支持多方参与 数据标准的定义，制定业务规则。 设计驱动开发 ● 先设计、再开发，根据设计结果生 成数据库部署脚本 ● 确保数据库开发规范落地 全球敏捷运维峰会 广州站

15. DDL的现状及问题 当前DDL现状 导致的问题 p 手工书写 p 质量问题、效率问题 使用excel建模，手工书写DDL； 质量参差不齐，手写效率低； p DDL校验放在开发环节之后 p 返工风险高，风险后置 即将转测试或者即将发版时进行DDL的校验； 即将转测试或者即将发版时进行校验才发现问题，一旦发现问题就要返 p DDL相关的工具或平台没有互通 工，如果涉及代码修改，返工成本更高； p 多工具切换，效率低 数据库相关的模型设计，脚本编写，脚本上传，脚本执行分别要在多个 工具之间进行切换（Excel/文版编辑器/gitbash/dbgo平台/邮件/PLSQL等）。 用户的DDL的完成及校验部署需要在多个平台/或工具中切换，使用复杂， 效率低，多工具维护复杂，实时性差。 DDL当前主要流程 需求 设计-评审环节 设计 开发 DDL不规范被打 回 DDL Excel powerdesign er 手工 测试 手工 /gitbash Gitlab 邮件 DDL不规范被打 回 LOTUS等 发布 Dbgo校 验 运维 生产 环境

16. DDM工具方案及收益 需求 设计环节 开发 测试 收益 发布 DDM 工具 p 批量生成，高效高质量 工具批量自动一键生成，避免人为疏忽 模型产出 导致的问题。提高效率，提高质量； 逻辑模型 物理模型 不通 过 模型2 通过 DBgo校验 模型N p 提前感知风险，提前解决 与Dbgo平台对接，将DDL规则校验前置， 模型1 自动生成DDL 提前察觉问题，提前解决问题；并且达 到实时校验实时修改，提高脚本质量， 降低投产风险； p 一站式开发，减少开发成本 模型设计 导入 Excel 逆向 数据库 (逆向抽取模型) DBgo平台 建模，校验，修改，上传Git库，部署 （部分开发环境及测试环境）全部都在 DDM工具内一站式完成，提高开发效率， 降低开发成本。

17. DDM工具- 1 快速建模 1.Excel导入 ① 导出模板； ② 完善模板； ③ 导入数据字典； 2.手工新建 ① 新建； ② 选择数据库类 型； 3.逆向工程 ① 逆向； ② 输入数据库连接串； ③ 选择表；

18. DDM工具- 2 模型落标 1.直接引用内置标准库的数据标准 2.自动使用内置词根进行翻译 3.直接使用共享模型

19. 二、DB发布工具总览 完成1000万 dbgo lotus 否 解压缩 01_....sql zip zip 02_....sql 03_....sql 数 据 库 预审检查 语法检查 通 过 语义检查 否 豁 免 否 规范检查 性能检查 是 空间检查 是 …… 封版 移交生 测试环境顺序执行 是 否 产发布 生产环境顺序执行 是 发布完成 全球敏捷运维峰会 广州站

20. 二、数据库发布工具DBgo（1） 背景说明 随着银行业务高速发展，越 来越多的系统的上线，数据 人工执行 库版本发布的局限性越来越 常在河边走，哪能不湿 鞋。人工执行脚本容易出 现人为错误 突出，风险越来越高，构建 一个高可用、自动化、安全 01 02 可控、规则可扩展的数据库 脚本发布平台越来越重要。 回退时间 环境混乱 指定错误环境执行 的风险高 通常发版出错，如果进行回退，时间 会很长，窗口无法保证 04 03 过程记录 非平台发布，无法保证执行 过程被完整记录，追溯困难 全球敏捷运维峰会 广州站

21. 二、数据库发布工具DBgo（2） 建设目标 02 01 高可用 平台7*24小时稳定运行 打造7*24小时高可用的自 动化部署平台。 自动化 任务提交时设定执行时 间，到点自动化执行 版本任务可编排，，若出 现任务按照时间窗口自动 执行问题，自动智能回 滚。 04 03 安全可控 用户只可查看或执行与 授权的菜单或操作 根据权限最小化原则，适 当分配各种角色用户的权 限，严格控制权限，杜绝 安全隐患。 可扩展 可以根据需要添加或修 改响应检验规则 SQL解析规则引擎的规 则，可以根据需要动态添 加、修改、删除，方便查 询。 全球敏捷运维峰会 广州站

22. 二、数据库发布工具DBgo（3） 分步实现 1期 2期 DDL新增 1、只发DDL、不发DML 2、只做备份、不做回滚 DDL其他 1、DDL修改 2、DDL删除 3期 4期 DML DML 1、INSERT 2、UPDATE 3、只做新增，不做删改 1、DELETE 2、exec procedure、 func 3、匿名块plsql 1、只发DDL，以及简单的DML 2、只做备份，不执行回滚，所有回滚操作都是触发通知到人工判断、执行。 3、一期只做新增，不做删、改（比如只做create,或alert * add；不做alter * drop、alter * modify、rename、drop、truncate） 全球敏捷运维峰会 广州站

23. 二、数据库发布工具DBgo（4） 设计要点 1 文件命名 序号_属主_SQL类型_动作类型_对象类型_表名_UMID 001_dbgodata_ddl_create_table_t_order_rocky068.sql 2 文件编码格式 6 操作数据条数 1000条 7 属主前缀 每个文件里面，对象前面必须要包含属主前缀 文件编码格式需要统一成：UTF-8格式 8 文件内容 Dml语句内容不要太多，不要超过 500个语句，解析比较慢 3 压缩包 9 事务提交 支持多个文件，以压缩包的形式发布 文件里面不能存放commit 4 DDL/DML拆分 DDL与DML语句拆分开成2个文件 5 不能包含任何DROP/DELETE Drop、alter drop、delete语句不允许 10 多表拆分 对多个表的操作，不要放到一个sql文 件中 11 不支持多表关联 多表关联语句不支持 全球敏捷运维峰会 广州站

24. 二、数据库发布工具DBgo（5） 工具原理 解析SQLType 根据数据库类型和SQL语句两个 参数，解析出sql类型 拆分SQL 不同sql类型的语句，使用不同方法分 01 解成若干小零件，最终组合成易于程 序理解的JSON串 02 静态检查 对SQL文本解析出来的JSON串，根 SQL Parser 05 04 03 据预定义的规则进行检查，并返回 确认检查状态 如果结果JSON串判断返回方式 动态检查 连接到数据库，对解析出来的JSON 检查结果及违规描述 串，根据预定义的规则进行检查对比DB 内的实际数据，返回检查结果及违规描 述 全球敏捷运维峰会 广州站

25. 二、数据库发布工具DBgo（6） 工具流程 2.backup 3.run 确定该语句是否需要备份 按顺序执行语句 5.after_check 确定语句是否执行成功 4.rollback 确定该语句是否需要回滚 1.pre_check 预检查部分，静态检查： 检查语法、语义等不连库 的规则；动态检查：检查 需要连库查的空间、性能 等 全球敏捷运维峰会 广州站

26. 二、数据库发布工具DBgo（7） oracle create_table static precheck 1 create_as_exist 检查create table as select… 直接reject,由dba审核 oracle create_table static precheck 2 owner_exist 检查表名前面是否有属主前缀 CREATE TABLE UOPDATA.T_ABC 若无,则reject oracle create_table static precheck 3 name_lowerline_exist 检查表名是否至少包含一个_(规范) 若无,则reject oracle create_table static precheck 4 key_exist 检查主键是否存在 PRIMARY KEY(A),ALTER TABLE ADD CONSTRAINT PRIMRY KEY 如不包含，则reject，可请dba审核是否豁免 oracle create_table dynamic precheck 5 name_exist_indb 检查库表、同义词、视图或物化视图在库级别是否存在 对于表： 1、本owner下存在，就reject 2、其他owner下，则提示，进入dba审核 对于同义词、视图或物化视图，存在则reject oracle create_table static precheck 6 tablespace_exist 检查是否有tablespace语句，不可包含tablespace 如包含,reject oracle create_table static precheck 7 initrans6_exist 检查是否有initrans 6 如不是，则reject oracle create_table static precheck 8 varchar_over3col 检查多余3个字段以上所有字段varchar/varchar2字段是否一样长 如是，则reject oracle create_table static precheck 9 4keepcol_exist 是否包含create_date,create_by,update_date,crete_by字段 若不包含，则提示 oracle create_table static precheck 10 colnum_over100 字段数量是否超过100 超过，提示 oracle create_table static precheck 11 varcol_over2w varchar或varchar2总长度是否超过20000 如超过，提示 oracle create_table static precheck 12 bloblong_exist 判断是否包含blob,long类型 如包含，则reject oracle create_table static precheck 13 clob_over2 clob>=2 如超过2个，则reject，可请dba审核是否豁免 oracle create_table static precheck 14 foreign_uniq_check_const_exist 判断是否包含外键、唯一、检查约束 如包含，则reject,请dba申请是否豁免 oracle create_table static precheck 15 default_null_exist 判断是否包含default '' 和default null 如包含，则reject,请dba申请是否豁免 oracle create_table static precheck 16 if_pk_notnull 判断primary key是否定义成not null 如未定义，则reject,可请dba审核是否豁免 oracle create_table static precheck 17 pk_name_prefix 主键约束命名规则：pk_表名 如是命名的primary key constraint，若名称不以pk_开头，则reject oracle create_table static precheck 18 range_contain_inteval 若是范围分区，且分区字段是date或timestamp类型，则必须包含interval， 若无interval，则reject oracle create_table static precheck 19 list_contain_default 若是list分区，则必须包含default分区 若不包含，则reject oracle create_table static precheck 20 over_128 若是hash分区，则必须是2的n次方幂，且不超过128个 若非n次方，或超过128个，则reject oracle create_table static precheck 21 notnull_set 分区列必须定义成not null 若非，则reject 审核规则样例

27. 三、SQL代码审核流程集成 开发阶段 测试阶段 SQL编码及创 建审核工单 测试 生产阶段 投产/运行 提交审核 未通过 开发处 理 豁免 规则 SQM审 核与优化 SQM自动 动态审核 流程控制点 比对 流程控制点 EasyDB监控 流程控制点 未通过 驳回 DBA 审批 通过 SQL审核记录 未找到匹配记录 工单关 联版本 投产版 本管理 通 过 审核记录 比对 违规记录 隐患SQL 低效SQL 流程控制点 生成测试隐患SQL 创建生产缺陷工单 优化 DLM系统 SQM系统 全球敏捷运维峰会 广州站 EASYDB系统

28. 三、SQM审核规则举例

29. 三、 SQM审核工具：支持多种格式的SQL导入 创建好工单后，导入将要审核的SQL。可用直接添加SQL语句、excel文件格式、SQL *.sql 文件格式、MyBatis xml格式和MyBatis zip压缩包文件格式导入，可参考模板格式。

30. 三、 SQL审核工具：隐患SQL监控

31. 03 DevOps：面向运维 打造融合不同DB类型的一站式数据库自动化运维平台

32. DB自动化运维工具生态圈

33. DB自动化运维数据架构图

34. 1，配置信息、监控报警 配置信息是基石，标准化是基础 监控报警的重点是如何避免遗漏、如何收敛 4，一站式查询DB 10几种数据库、数千名开发运维人员，如 何满足他们访问DB的日常需求 全球敏捷运维峰会 广州站 2、自动化运维 海量数据库的运维，靠工具 3、自愈-AIops 状态类、容量类的报警，实现自愈

35. 监控大屏 全球敏捷运维峰会 广州站

36. 敏捷入口 全球敏捷运维峰会 广州站

37.

38. 1，配置信息、监控报警 配置信息是基石，标准化是基础 监控报警的重点是如何避免遗漏、如何收敛 4，一站式查询DB 10几种数据库、数千名开发运维人员，如 何满足他们访问DB的日常需求 全球敏捷运维峰会 广州站 2、自动化运维 海量数据库的运维，靠工具 3、自愈-AIops 状态类、容量类的报警，实现自愈

39. 全球敏捷运维峰会 广州站

40. 全球敏捷运维峰会 广州站

41. 1，配置信息、监控报警 配置信息是基石，标准化是基础 监控报警的重点是如何避免遗漏、如何收敛 4，一站式查询DB 10几种数据库、数千名开发运维人员，如 何满足他们访问DB的日常需求 全球敏捷运维峰会 广州站 2、自动化运维 海量数据库的运维，靠工具 3、自愈-AIops 状态类、容量类的报警，实现自愈

42. AIOps的一小步 背景： ✓目前对于日常告警的分析及消除，仍需要人工介入，存在夜间及节假日可能处理不及时、工具使 用不熟练等人为原因造成处理延迟或引发生产故障的风险。 ✓为进一步深化自动化运维，并逐步向AIOps转型，本项目在DBA已积累的日常运维经验知识库基 础上，探索并实践基于决策树模型的故障自愈解决方案。 ✓本项目的主要目标是通过机器学习的方式，基于运维知识库，迭代生成数据库常见故障或告警的 原因分析及告警消除的决策树，并通过调用一系列现有的集成工具接口实现故障的自愈操作以及 告警的自我消除。 主要过程： 1）根据运维知识库的内容梳理形成常见故障的决策表； 2）导入决策表并通过机器学习迭代生成决策树； 3）对接kafka告警工作流，获取对应类型的紧急告警，触发自愈系统； 4）通过对接一系列实时接口获取系统运行状态，组合生成测试集通过决策树获取解决方案及辅助根 因分析； 5）对接变更流程及自动化工具接口，对告警对象进行干预，实现告警消除。 全球敏捷运维峰会 广州站

43. 以Oracle数据库FRA区的空间使用率报警为例 FRA使用 ARCH是否有空余空 DATA是否有空余空 率 间 间 备份是否成功 是否有大量数据更 新 策略 <90% Yes No Y Y NoAction <90% No No Y N NoAction <90% No Yes Y Y NoAction >=90% Yes Yes N N Increase-FRA & 调起备份 >=90% No Yes Y Y Migrate_to_DATA & 发送具体SQL >=90% Yes Yes N N Increase-FRA >=90% No No Y Y 调起备份 & 发送具体SQL 全球敏捷运维峰会 广州站

44. 全球敏捷运维峰会 广州站

45. 全球敏捷运维峰会 广州站

46. 全球敏捷运维峰会 广州站

47. 1，配置信息、监控报警 配置信息是基石，标准化是基础 监控报警的重点是如何避免遗漏、如何收敛 4，一站式查询DB 10几种数据库、数千名开发运维人员，如 何满足他们访问DB的日常需求 2、自动化运维 海量数据库的运维，靠工具 3、自愈-AIops 状态类、容量类的报警，实现自愈 全球敏捷运维峰会 广州站

48. 1 开发 运营 人员 申请权限 问题背景 经理审批 进入操作间 问题描述： 1、只读的用户，一月申请一次；非只读的，每次使用均需走一遍流程 2、审批时效慢 登陆远程桌面 3、在工位上无法处理，要去操作间room 4、不同种类数据库，打开不同terminal、不同客户端 5、只能做录屏、字符审计，无法做到结构化审计、不利于事后追查 6、无容易做到表级的访问权限控制、敏感信息屏蔽 END 执行查询 全球敏捷运维峰会 广州站 登陆堡垒机 打开客户端

49. 2 功能需求 多种类型的库快速切换查询 安全审计、操作日志、行为分析 避免反复提单的工作量 便于分析统计操作趋势等 随时查询以方便工作支持 避免低效sql影响生产性能 一站式的工具 全球敏捷运维峰会 广州站

50. 全球敏捷运维峰会 广州站

51. 全球敏捷运维峰会 广州站

52. 全球敏捷运维峰会 广州站

53. 04 展望 AI + DevOps 全球敏捷运维峰会 广州站

54. 1. 运维不做背锅侠 • 变更要有回滚方案 • 生产要有应急预案 • 容量要有预测机制 • 工具要有防呆机制 2. 开发是友军 • 践行DevOps不是一句口号 • 运维要更多、更密切地跟开发并肩战斗 全球敏捷运维峰会 广州站

55. THANK YOU！ 全球敏捷运维峰会 广州站