云数据库厂商除了卷技术，下一个阶段还可以卷什么？

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

在多年的工作中，尤其是最近一段4年完整的数据库云上的经验，让我获得了很多非云数据库工作者没有的知识，这对我来说是宝贵的，从客户的对于云厂商的需求，使用的感受，云厂商与客户之间的工作方式，以及数据库需求的产生，实现到功能的推出等等，我有了新的对云数据库产品新的认识。

这里我想引用一段国际大厂，AWS的一段数据库新闻来说说，对于云上的“大客户”，我们需要什么，或者云厂商自己意识到这个问题，尤其中国的云厂商，你们有这个意识吗？

企业现在可以通过 CloudWatch 的 Database Insights 模块，监控其 Aurora Limitless 数据库集群的运行状况，并排查相关问题。

Amazon Web Services（AWS）为其托管的 Aurora PostgreSQL Limitless 服务新增了可观测性（Observability）支持，帮助企业了解数据库集群的运行健康状况，并进行问题排查。

对于企业中的 DevOps 工程师、应用开发人员以及数据库管理员（DBA）而言，数据库的可观测性至关重要，因为它可以让他们深入了解数据库的内部状态，便于进行预防性维护和及时处理问题。

据 AWS 介绍，这项对 Aurora PostgreSQL Limitless 的可观测性支持，可以通过 Amazon CloudWatch 内的 Database Insights 模块访问。这个模块于去年推出，旨在帮助用户监控和排查 AWS 各类数据库的问题，包括 Amazon Aurora MySQL、Aurora PostgreSQL、RDS for SQL Server，以及 RDS for Oracle 和 RDS for MariaDB 等关系型数据库。

Database Insights 模块的工作机制 是将来自应用程序、数据库以及其运行的操作系统的日志和指标整合到一个统一视图中，为企业用户提供全局监控能力。

AWS 在博文中表示：“借助预构建的仪表板、推荐告警以及自动化的遥测数据收集功能，企业可以监控数据库实例的健康状态，并通过引导式排查体验，深入定位具体实例，进行根因分析。”

Database Insights 提供两种模式 企业可以选择“标准模式（Standard）”和“高级模式（Advanced）”来使用 Database Insights，其中标准模式为默认模式。

如需使用以下功能，必须开启高级模式：

在“数据库健康仪表板（DB Health Dashboard）”中查看数据库指标的整合视图；

配置并查看数据库的遥测数据和日志；

在 Database Insights 中查看 Amazon RDS 事件；

可视化查询统计信息；

分析慢 SQL 查询等。

对于 Aurora PostgreSQL Limitless，Database Insights 将在 分片组级别 追踪以下指标：

数据库负载（Database Load）：衡量数据库中的平均活跃会话数；

最大 CPU（Max CPU）：衡量数据库可用的计算资源。

数据库负载还可以细分为：

Top 实例（资源占用最多的实例）

等待事件（Wait Events）

基于我上一篇对于这些年上云企业的变化的分析，上云企业的质量水平在大幅度提高，如同以前去云厂商那里的都是幼儿园的等级的小朋友，他们要求低，资质也低，俗称好骗。 可当今上云的很多企业，具备专业的数据库工作者，云厂商的一些手段和常规操作已经不能满足客户的需求。云厂商也要进行2.0的变化了，根据我的了解现在国内的云厂商的一些意识还没有转化过来。

他们的意识水平集中在

1  评测和对比：把自己的数据库产品和其他的竞品对比，然后得出我们第一，或者我们有优势

2  功能的基建：数据库云厂商的基建能力是要被认可的，他们的基建已经复杂到，超乎我们想象的地步。

3  服务的优化：这点对于大客户的确是这样的，大客户有点可以为所欲为的状态，这也是上了云下不去的一个重要的原因，因为服务的到位，或者以及超越线下服务的水平。

但这还不够，让客户的知情权会是下一步云厂商应该意识到的问题，这与技术本身有关，但又没有特别大的关系，可这与我们用这云，而不用那个云有着很大的关系。

现在企业衡量上云的成本很复杂，不是用硬件+开源数据库计算成本的时代了，成本的计算已经到了要由财务部门进行统计的水平，而更重要的非成本衡量的一部分，尤其对于运维评价一个云产品好不好的关键部分之一，就是知情权。

这也是云厂商一直在做，也一直做太好的地方，简述就是，不好做，不能做，不敢做。

不好做：让客户知道更多数据库运行的情况，的确不好做。我们举一个例子，你的数据库实例运行在硬件上的情况，到目前为止任何客户是无法获得的，你的硬件如何，我的数据库运行在几代硬件上，你们的网络延迟多少等等这些参数和信息是不会提供给客户的，客户一直抱怨，自己就像一个只会掏钱和购买服务的“傻大款”，其实从成本的核算来说，云成本在大型机构中一定会比自建要便宜，这是通过财务部门核算和验证过的事情，成本的组成部分很多，尤其对大型企业来说。

而云厂商内部的各个部门本身之间也并非完全能进行良好的沟通和协同，这就让一些数据库部门想做的事情，他们做不了，因为另一个部门不认同这些信息应该提供给数据库部门，或者数据库部门本身也对这部分的信息本身没有认知，所以提供很难，比如硬件的损坏，硬件的损坏是有先兆的，对于云厂商替换硬件都有自己的标准，和监控而这些是不会提供给客户的，甚至数据库部门本身也得不到这些原始的信息。

不能做：不能做这里有两层含义，一个指的是技术水平有限，目前从人力和物力上不能支持开放这些监控的信息并提供有效的手段给客户进行数据的获取，第二个不能做来自于，本身一些技术问题还在模糊和摸索的阶段，暴露一些信息回产生各种各样的问题，比如友商拿着这些数据说事，或者引起一些不必要的麻烦和问题，所以不能做。

不敢做：这是商业问题，不能说的太深，一句带过，客户知道这些对于云企业运营有干扰，有些事情知道的越多不一定越好，一个企业运营是要有隐私的，这点我非常理解，且支持，因为我既是甲方，我也是乙方。俗话说站着说话不腰疼，我一直蹲着，所以这方面我理解。这就不多说了。

在三个不中，云企业应该有自己的认知，对于一些可以开放给客户的数据，应该尽早的开放，哪怕一些信息是收费提供的，也可以。对于大型企业，客户服务的完善度，也是考量我们要在那个云上进行工作的一个标准，越公开透明的云厂商，会在下一个云数据库竞争中，脱颖而出。人最大的怕，来自于认为你对他不真诚，云客户和云厂商之间的关系应该是客户一直认为你是真诚的，而这些真诚不光从技术和沟通中，也应该从暴露的信息的种类和数量上提供。

这里我举一个简单的例子，云系统突发不稳定，这并不应该完全对客户遮掩，而是应该快速的通过监控或者通知告知给客户，因为客户也有自己的客户，那些人不知道为什么自己的业务停止了，或者出现抖动，作为基于云服务作为基础架构的服务商，是需要快速获取这些信息的，那么这些信息怎么快速透明到客户手里，应该是云厂商，云数据库厂商应该做到的。

这里简单的举几个小例子：

1  数据库的参数：数据库参数的解释是衡量云数据库厂商对客户开放信息的一个窗口，好的云数据库产品对于参数的使用和调整都有详细的说明，如果想判断一个数据库产品的好坏，作为客户可以通过一个云数据库产品的参数解释来感知。换言之如果一个数据库产品本身连自己自身的参数都说不清，道不明那么很可能这个参数他们自己本身也没有摸清楚，或者是新功能等待用户来佐证这些参数的用法。

2 API 接口的开放：云厂商对外的开放程度中重要的一环就是API接口，通过API接口，云数据库客户可以获得很多的操作自动化和方法，同时获取自动化管理云产品的能力，这里如果你在对比到底选择那个云厂商的数据库产品，你可以通过对比各个云厂商的API开放的程度来进行了解和比对，越是细致，条目多的API开放性，越证明这个云数据库产品是被打磨的。

3  数据库功能界面完善：这点对于数据运维和操作人员异常重要，很多情况下云数据库的账号权限以及操作范围都被限制，不少情况下，通过完善的界面来进行处理和工作是一个云数据库产品对客户友好和成熟程度的一个衡量标准。

综上所述，云厂商，云数据库厂商在对待客户公开信息和展示上，是下一个云产品的竞争点，更好的客户感受，完善的信息流控制和信息的输出，是大型云客户评选云产品的优良的风向标。