DBA不仅仅是管理数据库--也要管理好需求

看到这个标题可能觉得我在乱说，其实只管数据库其实管不好的，树欲静而风不止。

有很多时候我被问能不能保证数据库稳定？这真不好说。我说如果能按照开发规范（我制定过一个数据库设计开发规范）做是可以的。请注意我这个不是说数据库开发规范。数据库开发规范是告诉开发人员如何写SQL的。而我的这个规范还有设计规范。先设计再开发。我多年经验告诉我，在设计一塌糊涂的前提下，优化显得苍白无力。

这种情况下SQL改写可以做一些，但是收效有限。只能期盼类似Exadata这种大杀器来解决问题了。只是我比较穷买不起这种。只能看别人羡慕。多年前听我老师说用上这个就是“咖啡运维”。我问什么是“咖啡运维”？答：喝着咖啡就（行了）运维了。言下之意是基本不用你管。后来我了解过得出结论。一般的企业除非遇到事务完成就是不提交这种以外，基本他都不用DBA或者运维人员操什么心。基本（我说的是差不多没说100%不要揪着这个不放）做到了“咖啡运维”。

那么那种事务完成不提交怎么办？基本都是设计或者业务上有问题导致的。所以回到今天主题就是这种必须管啊。否则就是什么硬件和架构都解决不了。其实我后来想过一个问题。如果应用程序update一张表，没带where条件怎么办？必然就出事了。而且是立竿见影的就马上保障。不同的数据库有不同的处理方式，不少数据库都有自己的解决方案。这里可能类似Oracle闪回这种对业务影响最小。但是应该也是多少会影响到。

这种只能保证说影响程度最小，解决最快。但是不能保证不出问题。还是那句话什么架构和硬件都无法避免这种问题。不少领导希望由架构或者运维兜底保证。实际上这种根本兜不住。

曾经有一个笑话摆在我面前。（我把这个笑话加工以及扩展了一下）。古代一支部队驻扎在村庄附近。将军严格规定士兵不许拿老百姓东西，比如说偷鸡。这对我们现在的人民子弟兵来说这是基本要求，三大纪律八项注意中有不拿群众一针一线。但是以前的部队未必能做得到。尽管将军还是说了不允许偷鸡。但是还是有士兵去偷鸡了。估计读到这里的朋友大部分都应该说是士兵问题吧。但是可能会有人说，你怎么把扎个篱笆防止士兵去偷鸡？对，马上扎篱笆。但是偷鸡的情况还是有。篱笆都扎了呀。有人会说，这个篱笆不够高，如果足够高他就翻不出去了。故事到这里差不多结束了。我想说就是如果砌的墙比紫禁城还高，但是就是有人就是要去偷鸡，他可以挖地道。

将军可以理解为DBA等维持规范的人。而士兵指的是不靠谱的业务或者按照这种不靠谱的业务照单全收的开发人员。

所以我觉得正确的做法要么是有惩罚，而且够重。比如有人酒驾了，入狱半年。现在酒驾的人少多了，但是依然有。你看这样都不能杜绝。

还有一种做法就是从源头管理起来。比如不是什么人都能提需求，那种不靠谱或者不着调的人提的不靠谱、不着调的需求就要扼杀在摇篮里。比如笛卡尔积或者任性的全表查询。这些都是规矩。

你去理发时候，理发师说请坐正。你不能说，爷我就找站着或者说姑奶奶我就要躺着。如果业务就是这么任性，那么代价就是用各种技术投入。增加存储计算资源用最好的软硬件。比如曾经有个用户结算很长时间，最后换了Exadata，快了10几倍。这里我不确定这个用户是不是合理。但是软硬件提升的情况下，业务和SQL什么都不改，问题就解决了。所以有钱有有钱的做法，有些都惹不起的情况下，就用钱来解决吧。话说回来，协调各方解决的代价估计比买Exadata的成本要高。因为在toB业务场景中，你和业务讲技术讲道理。业务教你怎么做人。