这是学习笔记的第 2045 篇文章

  本周参加了社群组织的DAMS峰会，我负责了数据库专场的主持和一个主题分享，整体来说还是收获不小。

今年上海站的峰会算是第5年了，1个主会场9个分会场，2天近40个演讲主题，涉及数据智能，AIOps，金融科技， 区块链，  数据库，运维等。

主会场的主题必然是大手笔，有院士振场子。

对于数据库场来说，整个主题的设计更多是从架构设计和优化层面来展开的。而其中对于分布式架构的讨论内容相对更为集中，有一个很核心的点，那就是存储和计算分离的实现，而在关系型和NewSQL，云厂商的实现（比如AWS）来说，思路都是不同的。 在这一部分，我持有一些保留意见，至少从关系型层面，对于MySQL来说，它的数据架构策略是基于复制，所以数据延迟和数据冲突检测机制的处理就是很重要的问题，分布式架构的实现目前依然是在探索的路上，NewSQL方向是一个很不错的切入点，而且在现在技术自主可控的背景下，是一件值得尝试的事情。

  我对自己的主题做一些小结，选择了部分ppt的内容。

首先对于DBA来说，我在开场就提出了三点建议：

1. 忘记你不单单是一个DBA

2. 你的核心价值是什么

3. 运维开发应该是你的附属加分技能

我来展开解释一下，随着现在的业务快速发展，DBA的市场行情还不错，但是竞争是很激烈的，所以我们在工作中要忘记你不是一个传统理解中的DBA,我们过去的工作都是一些相对被动的处理方式，而现在要转换为主动，或者更明确一些，我们要适配业务需求，提供数据服务。

对于核心价值，可以认为是那些DBA能做的更加专业的事情，如果是写一个运维页面，其实不是DBA的核心价值，因为这个工作其他团队也可以完成，而在这个层面，我认为架构设计，优化是DBA最核心的价值，其中架构设计中的重点是分布式架构和高可用架构。分布式架构在很多公司都有不同场景的落地，但是没有一劳永逸的万金油方案，一定要结合业务场景来选型，可能对于那些看起来不是那么主流的方案会有偏见，但是落到自己头上时，你的考虑不仅仅是技术层面，需要结合业务特点。

最后是运维开发能力，这是很多DBA欠缺的，也是淘汰传统DBA的一个很好的衡量标准，在此的重要性就不展开了。 

既然刚刚说了运维服务要由被动变为主动，我们就需要完善两部分的工作内容，第一部分可以理解为主食，即那些日常工单，这是DBA事务性工作的重要一部分。第二部分可以理解为配菜，生活健康都需要配菜，可以让我们的生活更加丰富，这是相对更加定制化的服务内容。

我的分享内容会主要从以下的四个方面来展开。

对于SQL审核，其实规范好定，但是能够踏踏实实的落实下来，这是更有技术含量的。所以对于审核服务，我们选择了开源项目Inception作为基础工具，把它作为审核服务的一个组件，然后开发了新的模型和规则处理，让审核服务更加容易落地。

要落实SQL审核，自动化上线是一个很好的接合点，因为审核服务做得再好，业务可以选择用也可以选择不用，我们没法去规范，只能去引导，而接入了流程之中，就可以约束和规范，我们通过打分机制让SQL质量更加清晰，也可以通过这种方式推动业务侧改进，把一些潜在问题推进到更早的时间前置解决。

对于自动化上线来说，我们可以提供丰富的审核机制，但是最好的审核是没有审核，这一点我们可以通过如下的方式来理解，即通过平台化处理让整个变更处理更加可控和容易理解。

对于业务巡检来说，这是我们需要重点完善的一个部分，之前的巡检更多是系统巡检，和业务是脱钩的，我们也做了一层尝试和业务侧进行结合，从业务的角度来得到他们更关心的指标和信息。

而在这个基础上，把监控，报警和巡检结合起来就可以达到三位一体的设计方式，这一部分还在改进的路上。

对于慢日志需求来说，严格意义上就是伪需求，我们很多开发同学对于慢日志的处理是不够规范合理的，我们可以通过汇报思维来理解慢日志需求，即这个慢日志报告要说明什么，到底有没有问题，问题严重不严重，哪些地方需要关注，哪些地方需要改进，怎么改进。

按照这个思路可以完善慢日志平台的设计，如下是一个实现的页面。

而对于每一条SQL我们都可以下钻，得到更加详细的信息，比如执行计划，执行历史信息，表属性信息，相关SQL等，这样一来我们对于每一条SQL都可以下钻，得到一个相对完整的页面，从这个角度来看，其实这就是SQL自助优化的一个雏形。

从实践的效果来看，还是不错的，自助服务从数量上明显占据了优势，而且在短时间内能够推广开来，也说明了对于业务侧的习惯需要慢慢培养。

此外大会准备了很多有意思的活动，可以抽奖，在休息的时候放松一下。

组委会的礼品很用心，原来我的名字有这么高大上的含义。

感谢各位行业大咖的支持，在一起聚会互相认识，都是圈内人，少不了互相支持和帮助。

感谢社群的组织，我们期待下一场峰会。

相关链接：