一直在思考一个问题，为什么很多单位的运维和数据库不能放到一起，数据库部分都是独立的。为什么数据库发生生产问题后，故障的级别都是特别高的。企业对于数据库本身的观点是否与时俱进，还是留在了上个世纪。

我们来看看某些领导对于数据库本身的看法

1  放数据的地方，只要数据库不出问题，系统就很少出问题，数据库怎么老出问题

2   数据库和大数据比，没有什么意思，大数据能衍生出很多的项目，数据库就是一个运维的

3   数据库无非就是ORACLE ，硬件配置提高点，问题就解决了，没有那么难

4   数据库就是运维的事情，找点运维的，开发的管管算了，没有必要投入太大

估计有些同学看完上面的一些上层对DB的本质工作的看法，会有同感，幸好目前单位对于数据库的重视程度不存在上面的问题。

从事这个行业有些年头了，实际上运维管理好的，开发管理好的，相对于数据库本身来说，数据库管理到位的单位相对上面两种管理好的单位，要少。

从单位的角度

1  对于数据库本身的轻视，和误解，对于数据库是什么本身就不懂

2  不能与时俱进的认知数据库在现代开发项目中起到的作用和重要性

3  无法找到适应现代数据库管理方面的人员，能找到的大多还是老观念的DB人员

这些事情其实从多个角度可以分析出来

大部分单位的CTO 很少有从数据库方面出身而来的人员，大多数可能的出身是，程序员，项目经理，产品经理 类似这样的人。软件开发可能是非常杰出的专家，对于数据库的看法其实就不那么专业了，大部分对于数据库的理解还是一个辅助软件开发的部分，或者数据库是运维的部分的思维模式，这还是与数据库最接近的 程序员领导的想法。如果换成其他类型的CTO 那么可想而知，数据库就是运维这样的思路估计是根深蒂固的。

那么现代的数据库到底应该是什么样子的，在项目中承担了什么。

1  数据库的种类多，NOSQL,NEWSQL, RDBMS, 分布式，很少有人能掌握整体的数据库类型，随着项目的分化和项目本身的需求多变，项目中使用的数据库产品是以爆发型方式增长的， 每个项目都存在  几种传统型的数据库，几种NOSQL 类型的数据库包含缓存型的，同时数据量大，分布式的数据库也可能被引入其中。

2  数据库介入到开发项目中，现在的软件开发项目中，大部分都是在搭积木，数据库算是软件项目中的积木，积木放对地方，形状选的对，整体的项目就稳固，可以持续很长时间不出大问题，或者可以随着项目的变化而变化，具有灵活性。数据库同时也承担部分软件项目中的逻辑实现，和部分基础架构的作用。 上到架构中选择数据库的类型，下到使用数据库中的接口的API 中的参数，一个JAVA 中产生的语句的方式， 数据存储的逻辑形式。软件设计中必然会有一块数据库应该做的设计和估量。

3  数据库与业务是紧密结合，与运维不同，属于静态，数据库与业务是息息相关的，业务量大，数据量就变大，数据的存储时间数据的处理模式，数据与程序之间的交互等等都会随着量变变成质变，而不是与运维中的静态产品，可以随意的扩展或收缩。

4   数据库是程序稳定运行中的一块基石，软件设计的在好，数据库类型选择错误，或者设计上出现误差，后续管理上的缺失，都是一个项目崩塌的开始。

所以数据库到底是不是运维，是不是一个简简单单存储数据的东西，值得领导层深思和考虑，如果你看轻他，必然他会找上门，最终和你讨账，让你死去活来。

至于数据库的周边，如自动化管理，智能化管理，和更靠近业务的方的数据治理等等都是在领导重视后，才能有的后续。

所以，在领导眼里，你是一个“运维吗” ？