刹车失灵，数据的刹车是否也会失灵？

最近上海车展中，特斯拉车主维权事件闹得沸沸扬扬。事件主要争议点在于：车主表示行车时无法刹车要求维权，特斯拉拒绝提供维权人的行车数据或用其他形式证实非产品质量问题，从而引发的争议。作为吃瓜群众的一员，试问如果产品质量没问题，数据不心虚，特斯拉为什么不提供相关数据证实自身清白？再者汽车用户自己的行车隐私数据为什么不属于自己？特斯拉高管明确表示的“无法妥协”，如此没有根据且漠视人命的“无法妥协”究竟是哪里来的底气？车企又当运动员又当裁判员，智能汽车的数据监管何时才能跟上？？

由上述事件不禁联想到整个 IT 行业的“数据刹车失灵”，微盟事件、链家事件等造成的严重问题，似乎更加屡见不鲜，那么作为现代企业，究竟怎样才能刹住数据的车呢？？

数据的刹车是什么？

首先解释一下刹车。刹车：通俗来讲就是指把运行中的车强制停止或降低速度的一种装置。数据运行的刹车大致也相似，试想你管理着一个庞大的数据库集群运行，现在有很多开发测试人员正在操作运行着这些数据，但做为数据库管理员的你意识到目前可能会出现数据泄露问题，请问怎样才能让数据快速刹车呢？

答案：登录控制。禁掉所有用户与数据库之间的连接，让用户无法登录数据查询操作系统，那数据的运行就会停下来。

请看统一数据管控工具 CloudQuery 的实践案例：

可通过锁定用户的登录账号和密码暂停数据的运行，这样即使有数百位用户操作数据，管理员都可以一个点击把刹车踩到底，顷刻间停止任何人对数据的任何操作。

数据刹车应该有 ABS 防抱死系统！

数据在刹车时紧急制动是必要的，但是尽量不要经常使用，因为一旦紧急制动，车轮被锁死，行车的方向就不好控制，会给企业运行带来严重影响。那么如果排查问题发现数据异常时，能不能尽快尽量缩小排查范围，粗略定位到较小的范围中呢？

答案：可以。

例如当系统管理员给予了用户「添加连接」「审计分析」的系统权限后，发现此用户添加连接时不能高效管理或者正在大量导出审计分析数据时，系统管理员就可以启动数据的「ABS 防抱死系统」，暂停此类用户对系统的操作权限，让数据的行车方向虽略有摆动，但仍能保持系统整体方向稳定。

实践案例请看下图：

这样可以保证在系统运行不受大范围干扰的情况下，采用点刹的方式踩住数据运行的刹车。

数据的刹车力度需要有精准的控制！

我们知道，行车过程中如遇到冰雪路段，毫厘之差的刹车力度也会影响到行车安全，就算经验丰富的老司机，也很难精准控制刹车力度，百分之百保证行车安全。那么如果是对数据的精准刹车，则更是难上加难，稍微多一点或少一点的刹车力度，就可能意味着企业的损失或业务的停滞。

那么能不能做到最精准的刹车控制呢？怎样才能做到？

答案：可以。如果用户对于数据的操作权限是在非常精准细致的范围内，如精确到某一连接的某一数据库的某一个具体的表，一旦发现某一用户的操作有潜在风险时，就可以立即收回此用户对该数据的具体操作权限。

以下是 CloudQuery 的实践案例：

例如上图中，分配给某用户的 MySQL_001 连接中 infromation_schema 数据库中查看和插入表的权限，如果想要收回，一键点击即可。

如何查看数据的行车记录？

正如再好的刹车系统也挡不住碰瓷一样。当数据运行时可能会出现一些当时没发现但却随着时间而暴露出的严重问题。那么作为数据运行的管理者，我们如果想定期审计用户在系统内执行的所有 SQL 来确保数据稳定，是否可以实现？怎样才能实现呢？

答案：可以。CloudQuery 将会审计在系统内所有用户执行过的 SQL 并保留数据。（未来将会审计一切）

所有的用户在 CloudQuery 系统内所执行的所有 SQL 语句将会都被记录。管理员可以在审计分析界面随时查看用户所执行的语句和操作。

数据行车过程中被删，是否有备份、可立刻恢复？

假设数据正在运行过程中遭遇极端情况，例如所有数据被黑客全部删除，那么我们系统中是否有备份？能够立刻恢复呢？

答案：可以。

如图所示，你可以在 opt/cloudquery/backup 目录中找到自己定期备份的数据；可以在相同或不同 CloudQuery 部署节点恢复副本。

结语：

无论是车辆的刹车系统，还是数据的刹车系统，作为关键时刻救命的东西，无论何时都是重中之重。不论做汽车还是做软件产品，强大的功能和技术当然是我们共同追求的，但生命和安全必须要放在一切技术和功能之上，容不得半点马虎。

统一数据库管控工具 CloudQuery 官网地址：https://cloudquery.club/