萝卜快跑在武汉开展运营的新闻一石激起千层浪。人类之所以在自动化的道路上不断探索，是为了克服自身的各种局限性。
减少甚至免除人类的参与，不仅能把我们从繁琐的重复性劳动里解放出来，也大大降低了操作中的事故率和运营成本。不止于出行，这个道理适合于各个行业。
众所周知，数据是 IT 行业最宝贵的资产，数据库的一点风吹草动都可能引起线上系统的剧烈震荡。所以为了安全起见，基本所有的既有数据库都配备了 DBA（数据库管理员），无论是企业独享的 DBA 还是云计算提供给客户的共享 DBA 。
但再资深的 DBA 也不过是一个个活生生的人，他们会疲劳，会犯错，而且最重要的是，他们很贵。美国 DBA 的平均薪资在 12 万美元/年左右，而中国一线城市大约是这个数字的一半。所以给企业精简掉高薪DBA远比给网约车省掉月收入仅数千元的司机更能降本增效。而网约车面临的情况的复杂度其实远远比跑在标准操作系统里的数据库的复杂度要高，现在司机已经开始下车了，有什么理由让DBA继续“待在车上”呢？所以让数据库无人驾驶是行业必然的方向。
早就想到这一点的我们推出了 ClapDB——一个无人值守的真正的能够造福企业的数据仓库。ClapDB 在用户的云账户里工作，不需要任何人类参与它的运行和维护，只需要定期升级到最新版本即可。
作为 IT 领域最复杂的软件之一，如果你把数据库看作一辆高速行驶的汽车，在原有的模式下，驾驶位上坐的是使用数据库的程序员，而副驾上始终坐着 确保这辆汽车能正常行驶的安全员——DBA。
而现在，我们将坐在副驾上的 DBA 换成自动化的程序会有哪些收益呢？
删库跑路可能是一句笑谈，但对真正经历过删库风波的某些公司来说，比如微盟，至今仍心有余悸。所以关系到企业核心生命线的数据，仅仅控制在某个人的权限中，是不是过于草率了？如果压根没有人的存在，是不是就可以把来自人的风险彻底杜绝？
任何一名 DBA 都无法保证自己不会犯错，我们并不是不能宽容任何错误，而是要看解决问题的响应效率。所以我们所了解的 DBA 的日常，都是电脑二十四小时不离身，网络半秒钟都不能断，这种工作模式对其本人甚至家人的生活都造成了极大困扰。即便他本人足够肝，响应非常及时，但在业务压力最大的时候，VPN 未必能够连上，服务器未必能够登录成功，DBA 未必能准确的判断问题的真正原因。
而且，实际上 DBA 做的选择都是当时根据自己的经验和知识的赌博，再英明神武也总有失手的时候。我们不能苛肉体凡胎的人不犯错误，而应该把这件事交给永不知疲倦，总是能即时响应的计算机。
再小的公司也起码要有两名 DBA 来轮值，而对小公司来说，可能这两名 DBA 的薪资就超过了所有在数据库上投入的硬件和软件成本。
你可能会说，云厂商提供的 RDS 之类的托管数据库用共享 DBA 的模式，已经降低了每个企业的 DBA 成本负担，但 DBA 的成本终归要由用户分担，彻底没有DBA岂不是成本更低？
看到这里你可能会问，那之前的数据库为什么要有 DBA 呢？
核心原因是，数据库诞生的时代太早，是基于单机系统只能提供有限的资源这个前提来设计的，天然存在着无法应对起伏的 workload 以及 workload 之间会互干扰的问题。在这个问题没有得到解决的前提下，任何通过把 DBA 的工作“脚本化”的改造都是屎上雕花，不可能跳出数据库必须由人运维这个藩篱。
如果我们把 IT 行业面临的 workload 做一个简单的分类，可以大致分为 online 和 offline。online 是必须在一个较小的时间内处理完毕的任务，而 offline 相对没有严格的时间要求。传统数据库既无法保证所有合法请求在一个约定的时间内完成，也没有合格的资源隔离，这导致一颗老鼠屎坏一锅汤的事情时有发生。
除了数据库的安装和部署这种一次性工作来说，你可以抽象地认为 DBA 是同时维护一套 online 系统，并且在 online 系统上做一些 offline 的工作。然而从某种角度来说，无论是 DBA，还是脚本化的自动 DBA 都是在做”有损“的运维，资源和需求的不匹配根本没有完美解决方案。10 个人吃 9 碗饭，要么有一个人饿肚子，要么大家都吃不饱。
单机搞不定的事情，云厂商就能解决吗？很遗憾，并不是传统数据库上了云就可以无人驾驶的。数据库领域里的主流产品都太老了，都不是为了云这种新的计算机硬件设计的产品，在新的时代很多过去的优化反而会变成负累。
ClapDB 通过 BYOC（Bring Your Own Cloud）的方式交付我们的产品，它会部署在你的云账号里。我们不会也不能干预它的运行，同样你不能更不必去处理它的状态。
数据库是个复杂的领域，下文我们仅探讨类似 ClapDB 所在的场景，即一个可以对无限量数据进行多模态分析（关系/时序/文本搜索/图/向量/JSON/地理信息）的数据仓库，如何实现无人值守能力。
让我们从处理不同的 workload 的角度来简单解释对上文中固有问题的应对之策。
在我们之前介绍云的弹性的文章里，我们详细描述了如何利用好云的弹性和隔离性。我们将所有的 workload 都通过这样的方式隔离，互相之间并没有干扰，就不存在需要人为干预避免慢查询的问题。
Offline 系统显然不是常态运行的，所以利用云的弹性在需要的时候申请资源，执行后释放，更加不会干扰 online 系统。而且因为云上算力价格还有波动，我们可以利用价格的变化，找到更适合执行 offline workload 的时机，而不是在 DBA 有空的时候或者自己系统？。
数据库有很多时候是需要大量资源的，在传统数据库里要时刻注意不能让它们过度的占据资源，以免影响其他任务而做出大量牺牲。我们前文里介绍了把云看成一台超级计算机的视角，我们可以临时分配给这些 workload 海量的资源。比如我们可以执行多种查询计划，而不是让 optimizer 去猜谁是最优解；比如我们可以集中对某些数据做 reindexing 来让整个系统后续的表现变得更好。这些在传统的固定硬件上的数据库上都是不可能完成的任务。
我们当然不能说无人值守会替代所有传统数据库，洗衣机发明至今一百多年，依然有人在手洗衣服。现在西方很多机场仍然运行 windows 3.2，还有很多 COBOL 代码运行在日本的金融企业里，所以可能会有些古董数据库长期留在业界。但是新时代诞生的数据库应该是为了新时代的硬件设计的，而不是对原有的古董反复修复。有的人可能还在挣扎，但大多数人已经欣然接受了“萝卜”们带给我们的便利。
人类的历史就是不断用新的工具新的科技解放生产力的奋斗史，数据库也不例外。拥抱变化，体验ClapDB这样的新一代无人值守数据库带来的美丽新世界，让 DBA 们离开繁琐的重复的工作，将自己的时间和才华用在 AI / 星际探索 / 可控核聚变这些未来的领域，岂不美哉。