“一顿海鲜引发”（2）“运维工具与DBA之间不打不相识”

❝

开头还是介绍一下群，如果感兴趣PolarDB ,MongoDB ,MySQL ,PostgreSQL ,Redis, OceanBase, Sql Server等有问题，有需求都可以加群群内有各大数据库行业大咖，可以解决你的问题。加群请联系 liuaustin3 ，（共3300人左右 1 + 2 + 3 + 4 +5 + 6 + 7 + 8 +9）(1 2 3 4 5 6 7群均已爆满，开8群近400 9群 200+，开10群PolarDB专业学习群100+)

“一顿海鲜引发”（1）：DBA、架构师与数据库运维工具的爱恨情仇

接着上篇说的事情继续，说请我吃海鲜吃是吃上了，可惜了，就请我吃了几个贝壳类生物，连生蚝和我心心念的鲽鱼都没吃上。就这样还是上了贼船，后续的一些事情也引发了我们的思考。

前架构师同事：礼拜日又给我打电话，上来就说，听说你人脉广，DBdoctor软件能找厂商过来给指导一下吗？

我：你看我脸大吗？ 我谁都认识，还指导一下，你买人家产品吗？ 不买把人家叫来。

前架构师同事：你别提了，我把这个软件拿回单位给我们那个老DBA看了，他说不行，说现在的软件都是骗子，还是自己研发的好。

我：那你是嘛意思，把人家厂商的人叫来和你们DBA PK。

前架构师同事：我们做架构的其实不是很懂数据库这块的事情，只是最近我们CTO对于现在的DBA团队不是太满意，希望他们能提高工作效率，同时能不能搞一搞AI，现在都和AI靠边，我们开发，架构都拿出与AI有关的新的想法和产品，DBA他们这方面没有动作，前两天会上让CTO 一顿K，还和我说了诸多的他觉得有问题的地方，希望我能给出出主意。

我：CTO 都说嘛了，什么问题让他不满现在的DBA Team。

前架构师同事：主要是两点，

1 解决问题速度慢，开发一些SQL语句的确需要改写，但是DBA忙不过来，现在系统的瓶颈多。 

2 出现问题，解决分析反馈的速度不够快。我们希望对系统本身稳定性的SLA提高了一个小数点，可数据库这块拖后腿了。

我：你们把这些问题都推到DBA的身上了？ 不都是你们开发搞出来的吗？ 

前架构师同事：你这样说就不对了，我们现在写代码都AI化了，很多开发人员都在往需求分析上走，CTO希望开发团队产出效率要高，我们现在压力非常大，我们也不好过。SQL那个部分的确我们不熟悉，所以我们希望有一个系统上线就能发现潜在问题，将问题消灭在萌芽期。我们也在往国产化上走，现在的DBA对国产数据库意见大，说问题多，对于国产数据库问题分析这块也在摸索。

我：那你是想让我，把厂商的人找来帮助你验证这个产品能不能解决你们的这个需求，做一个POC对吗？

前架构师同事：对对对，另外你也来一趟，帮我看看，我不是太放心我们这边DBA的一面之词。

我：行，但咱们说好，这次还的请海鲜，但说好不能是贝壳类动物，咱们的上点好的，我要海鲜大餐，龙虾就算了，但别在狗食馆拿贝壳类动物糊弄我。

前架构师同事：行，你只要把这事情搞定，请你。

话说到这份上，那就必须得做好准备，首先就是POC

我的列出来几个测试点来进行测试，通过测试结果来看看这个软件到底适不适合他们单位。

其实POC这个部分，要测准并不容易，我们来捋一捋大致的方向

1  突发问题发现的方式，速度，以及准确度

2  多种数据库类型的接入能力，线下，线上，各种国产，开源，商业的数据库产品

3  展示的方式，协助DBA综合处理问题的能力，建议信息的准确性等

后面我就通过关系和DBdoctor的老师沟通的一下，也把前同事他们单位的需求说了一下，然后我们就建群，把DBdoctor的老师和前同事等建立一个群，把想做的一些POC的需求说了一下，最后敲定的日子，去他们单位做一次数据库运维工具的POC。

在约定的日子，到了他们单位,在寒暄过后，我们开始POC

POC的第一个项目就要测试软件是否能及时发现数据库系统中发生的问题。这里我们和他们公司的DBA讨论，把一个PostgreSQL数据库加入到DBdoctor中，然后让这个DBA来模拟一些故障，看看DBdoctor能不能及时发现。

我们在这边盯着DBdoctor软件，那边他们的DBA在数据库上不知道在干什么，我们就看着屏幕。

不一会，系统就开始显示数据，问题清晰的展示在屏幕上，一条应该执行很快的SQL执行了300多秒，但问题很快就定位出来了，发生了锁等待，这条SQL被阻塞了。

问题是锁怎么形成的，以前全凭DBA口述，嘴说，这次好了软件给显示出来了，他们公司DBA 也看得目瞪口呆，我听见他小声的说，霍这就出来了。

前架构师同事：老李，你看这软件行不行。

前架构师同事公司DBA，姓李，年纪看上去也不小，估计比我前同事要大。

公司DBA老李：就这本事，这个我们自己写软件也能解决和查询这些问题。

前架构师同事：老李，我们现在是解决问题，你自己写软件解决问题，你这话去年你就说，今年都快过去了，你软件呢？现在生产问题那么多，你天天晚上干到10点多，你有时间写软件吗？

公司DBA老李：为什么我们不用开源的软件，能给公司省不少钱，你这找商业的不合算。

前架构师同事: 说这个就来火，你弄过多少软件，不是开源的软件开发跑路了，就是不维护了，要不就是这个软件只支持PG ，那个软件只支持MYSQL，弄一堆的软件，各干各的，你这像个正规公司干的活。

公司DBA老李：我给公司省钱了，我是公司的功臣。

前架构师同事: 老李，你知道去年，DBA小吴为什么走吗？

公司DBA老李：不还是公司给钱少了？人家干的不开心

前架构师同事：我可问人家了，人家对你不满，你是DBA的Team 负责人，人家小吴去年想调研国产数据库OceanBase 你非不干，抱着ORACLE 不撒手，说一库传万年。你看看现在不都在弄国产数据库，后续咱们公司CTO也说了，该上云的上云，该开源的开源，该国产的国产。灵活项目上云，周边业务开源数据库，公司核心的业务转到国产数据库。

诶对了，国产数据库你研究了吗，到底咱们ORACLE 转哪个库上。

公司DBA老李：你说这个了，来我问问那个什么公司，哦，DBdoctor你们支持多少数据库？国产支持什么？

DBdoctor 辛老师：我们这边支持的国产数据库种类比较多，主流的云上的数据库产品比如TDSQL, PolarDB ,还有 OceanBase, GaussDB, KingBase, 瀚高，海量等，开源的MySQL, PostgreSQL, Redis 都支持，具体的数据库列表您可以看我们公司的官网，有列表。

前架构师同事：诶，老李，咱们得PG数据库你POC一下，咱们那个AI数据库新上的是PG，你会吗？听开发小张说，经常出问题，你这边维护的了吗？

公司DBA老李：正好，那个PG经常出问题，正好拿你们这个软件看看，看看你们这个软件到底能不能解决问题。

DBdoctor 辛老师：李老师，你们数据库有一些长时间不commit的事务在数据里面，这个您知道吗？

公司DBA老李：啊，怎么会，都说从ORACLE转过来，数据库都是自动commit ，还有人显式事务，能帮我看看是哪个语句吗？

DBdoctor 辛老师： 您看系统上都有显示，这个是一个明显的执行语句，显示提交但是没有commit 的典型你看看 ！

公司DBA 老李：太好了，我们平时找这些东西太麻烦，有这个我要发现问题还真是一分钟就行。那我多问两句，咱们这个系统除了线下的产品，因为我们现在线上的数据库也越来越多，我之前的一些监控软件已经不奏效了，自己写软件对云上的数据库监控也不好看。咱们能监控云上的数据库吗？

DBdoctor 辛老师： 可以的，我们这边有文档，我们可以直接接入到云上的数据库产品，您看这里我们直接接入到阿里云内部，直接获取他们的后台数据库，这样您公司的复杂的线上，线下，还有国产数据库就都可以通过一个数据库运维软件管理起来了。

后面我明显感觉到，我前同事他们公司的DBA态度变好了，问的问题也多了，还给DBdoctor提了几个建设性的建议，还和DBdoctor的老师问了软件下载的地址，说让他们弟兄也都下载，回来一起都用用。https://www.dbdoctor.cn/?utm=45

整体的测试后，DBA和架构师对于软件都还挺满意，架构师对他们DBA说，有了这个软件，DBA以后是否可以贴近业务，对一些开发中的与数据库有关的部分管起来，公司现在对DBA的定位并不是一个单纯的运维角色，而是一个更加贴近业务，尤其把各个部门的软件开发中的一些不遵守数据库开发规范的事情管起来，同时CTO也提出的，希望DBA牵头数据库治理的问题，参加软件评审项目提出自己的意见，同时是不是也可以在软件上了以后，让DBA有更多的时间去研究公司更深层次的迁移数据库到国产数据库部分的工作等等，来平抑CTO对DBA部门天天救火，只提供基础运维低价值输出的诟病。

最后故事结尾，你猜我吃没吃到海鲜大餐！