云厂商的数据库，麻烦您靠点谱 Please pay attention，无力感满满

是什么让我写这篇文字，愤怒，无奈，还有一点点的希望他们更好，就一点点。换了单位和实体的数据库相行见远，和云数据库，各种云的数据库越来越来越近，有大，有小，大的可以说认为是NO.1 小的也上市了。

先说说让我 angry 的几件事，

1 重启数据库要通过短信验证，没有使用过云的数据库的同学不要怀疑，你重启一个数据库那么是一件非常困难的事情，你重启数据库要通过短信验证，并且你在一个云里面的账号如果不是主账号，你是无法重启数据库的，OMG。

有的同学说，那你就短信验证就好，如果你有30多套数据库，都要重启，每个都要短信验证，并且你的那个手机还是CTO 的收集，在半夜12点你需要联系你的CTO ，把他摇醒，说来我们ONE BY ONE 的把数据库从起一下，来告诉我你的短信验证。

这样的设计是不是有毛病，并且是脑子灌了水银的毛病，我就想问问需求经理，安全部门，我想抽你，下次你在设计这样的东西，每个客户重启都要把你叫起来，陪绑，你就知道这是什么滋味了。

后来给我一些方案，可以跳过，那么我就想问了，设计这样的功能是为了跳过，那还安全吗，怕某些客户删除数据，然后还可以逃过，OMG ，我不理解，也永远不会理解。

这里我给的四个字 ，多此一举。

（附：设计思路是，最近发生的一些删库跑路的问题，实际上我想问的是那怕是要防止这样的问题，设置一个开关短信验证的人通过总账号关闭或打开短信验证功能，没有必要都要这样做，另外社会问题，都要技术方式来解决，这本来就是一个吃力不讨好的事情，贵司的法律部门是摆设吗）

2 自研的P 系列数据库，OMG ，里面的问题我就不说的（随着越深入，越有一些intresting 的问题），我其实对他还颇有好感，的确解决了想使用 MYSQL 但又不想受到某些性能问题骚扰的，和对MYSQL 不能进行正常应用设计的 “开发” ，有针对性的优化的数据库 ，但麻烦你们，能不能不自作聪明。

你们以为使用 P 系列的数据库用户，特别需要你告诉我 Performance_ schema 使用起来有性能消耗，蛤， ，我已经很小心的设计配置参数，基本和MYSQL一致，当然我低下的人太忙，没看住，最终P S 默认给我关闭了，并且还要重启后才能打开，OMG OMG OMG

你知道两位数的 P 系列数据库我都要重启，不要和我说 很快，我真希望你们来你们用户的企业来工作来试试， 我去和谁解释，谁能理解为什么要重启，本来主打和MYSQL 兼容的云原生数据库，在参数上不兼容， funny. 你面对的用户不仅仅是有白痴，也有像样的。

这里我也给你四个字， 自作聪明。

3 还是这个P 系列的数据库，之前和开发沟通中，问其中的性能参数调整，我都进行了调整并咨询，给我的一个非常 “官方” 的答复，就是不同配置，不同的性能，不建议我改参数。

我特别想问，OK ，如果我是小白，去胡改乱改，你当然可以这样去搪塞，我都把每个参数的功能，以及值的范围都列的很明确了，还这样搪塞。

不是我傻，而是你根本就没有做功课，你们数据库不做测试的吗，每个参数的调整的范围与影响，哪怕你可以给一个说明也是可以的，我们也可以自己做测试，实际上我们做了，并且就在很低的配置上，调整部分参数已经有性能的不同了，虽然不是很明显，但已经说明问题了。

这里我也给你三个字，不专业

4 还是这个A 云，的Postgresql 数据库，之前添加磁盘空间要等到晚上进行，必须是指定的时间，后面升级了系统，也不说，然后我们按照之前一直的经验操作，我们没有错，我们不能每次添加空间还要请示你，麻烦告诉我，你们有没有升级，有没有进步，然后拍手鼓掌。

我们傻傻的等待，批准价格等等信息，然后傻傻的等晚上，国内最大的CY机构的甲方还要我们确认晚上的工作，然后就在工作时间就加上了，留下一脸懵逼。我做事从来都要求专业，这次真的是不专业了。

还要去和人家道歉，检讨。

这里我也给你一个 无声的 五指印。

5 接着说 A 云更可气的，就是他们的客服，我非常理解服务的模式成本的控制，我一周 两次的投诉 估计也算他们的黑户了，我来总结他们的所作所为

1 所答非所问

2 链接党，问问题，直接给一个连接，让自己看

3 态度不好，问点专业的问题，就没有反映

4 转接，转接 ，转接

5 沟通成本极高

这样让我想起他们的TB，想要真正的有效沟通，那是很困难的。

这里画圈的是，使用他们的客户， 你一定是要大客户，一年几千万的那种，服务会上N 个档次，会有专人进行沟通和服务，会更专业，更快速，别问我怎么知道的。

这里还是四个字，必须有钱

说完最近和 A云的不愉快，在说说 Q 云

对比 A 云 ，服务积极，沟通简单。 但基于本身的 POWER ， 的确技术层面需要提高的地方很多，但体量在那里。

1 积极服务，但需要更多的思考，和更多的技术能力，一个云本身，不光是买几台机器，整体是一个很复杂的工作，部门之间对接不好，出现异常的情况多，那么客户怎么能放心将核心的业务放到这里呢

技术第二，稳定性才是第一，道歉再多，也不能改变每次出现故障后的信心丢失，有时很心痛，感觉他们很尽力，但就是差那么一点点，可这一点点就足以致命。

2 硬件问题导致数据库异常，这点是在处理一个MONGODB 时发生的，一个工作人员，在不懂MONGODB 的情况下，就把所有的节点 在同一个时间点给我重启了，OMG 麻烦有点常识好不好，一个 基于分布式的数据库，在同一个时间点，全部重启节点，是不是太不专业了。

然后硬件底层也有问题，导致长期的MOGNODB 的性能出现问题，而监控还有问题，无法感知问题，导致客户自己发掘自己的问题并摸索了2个礼拜， 然后最终爆发问题，停止工作 2个小时之久。

作为技术者我理解，任何稳定都是要经历不同的问题发生和解决的过程，积累经验，但对于客户只有一个感受，痛苦和信任的丢失，市场是残酷的，竞争激烈，机会稍纵即逝。

3 基于之前的体量和资源，需要客户在资源上需求量大的情况下，需要整体在重新分配资源，客户需要配合调整转移某些数据库产品的物理资源， 这点理解，但不能接受。

这其实就是上层规划的问题，和下面工作的人员关系不大，有些就是命中注定，无法改变。

这里只能送四个字 ，危险边缘

云有各种各样的问题，是产品就有问题，反观作为云的使用者我们有没有自己的问题，云厂商怎么看待用户，是否有分类，其中有一类就是，根本不懂，蛮横无理，胡作非为的客户，这样的客户不是少数。

还有一类，懂得如何使用云，对云产品有认知（至少是数据库）举例 我们在 ORACLE TO MYSQL , TO POLARDB ，我们做了很多工作，拆分，测试，到底一个业务拆多少库，并发要打散，数据要打散， 表设计要重新评估。

很多使用者是不管这些的，最终将之前的数据应用塞入到一个 POLARDB 或者 MYSQL 将罪责责怪到 数据库本身 也不是少数，这就是刚才提到的第一类客户。

如何做一个 体面的 ，有技术 ，能和云厂商进行 fight 的高姿态的使用者，也是使用云的人 ，应该具备的素质， 否则你只能被愚弄，被嘲笑，被欺骗， 同时人家背后还说一句 ，傻帽。

最终送给自己一句，不断提高自己 ，做一个让让云厂商，爱不起来，也恨不起来的使用者，互相成就，互相进步，在这个 糟糕的 时代，继续好好活着。

同时一些妄图上云就觉得 database operation or operation 就可以不在需要专人或团队维护的思维方式，也可以歇歇了，两字 做梦。