从程序员的尽头是业务说起
我感觉今日头条挺牛的，最近总是给我推送一些编程方面的文章，特别是和C/C++相关的，前阵子还给我推送过几篇数据库方面的文章，居然还是PostgreSQL相关的。我从来没有在今日头条里阅读过类似的文章，不知道这种推送是哪来的？是今日头条在窥视我的微信聊天记录呢还是它从网上搜罗到的我的PROFILE中分析出来的。反正是十分可怕，人的隐私已经基本被剥夺的差不多了，而且我们也无能为力。
今天今日头条推送的文章是挺JAVA，贬C/C++的，虽然写的不怎么样，不过有一句话挺不错的，那就是“程序员的尽头是业务”，大体意思是编程语言在功能、性能上的差异越来越小了，用什么语言编程并不重要，程序员的终极追求目标是业务。
和DBA圈子里满是某种数据库的拥趸，充满了对异种数据库的鄙视一样，码农的圈子也充满了各种语言之间的鄙视链。不过不管你用何种语言来编写程序，如果你对业务的理解不深，那么你也只能是一个初哥，成不了大家。
数据库运维要更复杂一些，掌握数据库运维的技术，技能要比掌握一门编程语言要复杂的多，因此在DBA圈子里并不存在“DBA的尽头是业务”的说法，虽然这些年这种说法在DBA圈子里也越来越多了，不过这些观点大多数来自于互联网企业。可能我上了点岁数，有些保守了，我甚至有一个观点是我们很多传统行业企业的数据库与数据库应用正在被互联网公司带到一条歪路上去了。传统企业的业务很难完全互联网化，因为业务不是完全互联网化的，因此IT系统也不可能是完全互联网化的。另外互联网企业在IT上的巨大投入，也不是传统企业能够学的来的。如果我们的高层领导了解了互联网企业在IT投入上的数额和占比，恐怕就不会整天对IT部门抱怨，你们怎么不好好学学互联网企业？我认识的一个企业的IT主管就是因为领导整天唠叨这句话，有一天搂不住了，就顶了一句：“那你倒是给我互联网企业的IT投入啊”。那个领导情商很高，听到这句话，立马就终止了讨论，并没有去深究互联网企业的IT投入是个什么情况。
对于一些管理核心业务系统的，整天盯着几套关键系统看着的DBA来说，“DBA的尽头是业务”这句话似乎是挨得上边的，如果DBA不能对核心业务有所了解，那么想要做好运维也是十分困难的。这种企业的DBA可能比研发人员更熟悉系统种的数据架构，一些数据的特征，增长率，变更率等情况。只有这样，才能更好的管理好数据库。有些优化、升级、调整工作，也必须根据业务的发展情况进行分析，才能得出比较准确的结论。前阵子有个客户的一套核心系统，对于交易的延时要求越来越高，RAC的GCS/GES等待会给每个核心交易带来差不多10%的延时。因此他们通过对业务的分析，以及每个数据库节点承担的交易量，得出一个结论，如果拆掉RAC，采用HA方式来实现高可用，那么单个节点完全可以承受未来五年的业务增长，而核心交易时间可以节约10多个毫秒。不管他们的方案是否正确，DBA做到这种地步，对业务的理解不够深入肯定是干不了的。
在另外一个极端，大多数DBA可能一辈子都不了解业务，不理解业务的细节。这些DBA也活得好好的，并没有失业的压力。他们只需要掌握数据库运维的关键技术，了解一点点自己管理的系统的业务特征就可以了。现在有些企业动则数千套系统，上万个数据库的运维规模，DBA能知道存在这么一套数据库就已经挺不错了，就不要说理解每个数据库后面的业务了。
所以说，DBA领域并不存在“DBA的尽头是业务”这一说法。DBA是企业IT运行支撑中的一个重要的独立环节，独立到社么程度呢？系统不出问题的时候，甚至很可能会被领导和同事遗忘；不过系统有活要加班的时候，好像哪个活都得找上你，好悲催的DBA。