开篇小故事
下面的故事都是真实的，犹如雷同纯属同类，请仔细反思。
故事1：升级硬件
客户后台数据库存在性能问题，查询特别慢，长时间语句很多。客户因此而苦恼，咨询了软件厂商我该怎么办？软件厂商给出的答案：升级硬件吧，现在的资源不能满足了！
那么客户是什么硬件配置呢？数据库什么体量呢？
答：128的CPU、512的内存、高端的存储，跑了一个200G数据量的库，好像硬件满满的够用呀！
问题的根源就是最基本的大量少索引而已！
故事2：负载均衡
客户想做数据库的负载均衡，于是找到我们，各种方案各种高大上的说，我深深的被客户的前卫思想洗礼了一下，毕竟传统行业很多对数据库性能，安全方面的一些保障不是很完善。
前期谈的很愉快，然后我去检查客户的现有环境，更惊奇的事情发生了，2台跑在同一个物理机上的虚拟机要做负载均衡？
合久必分，分久必合的节奏？
故事3：高配更慢？
客户在原有64CPU、128内存的服务器进行升级变成128CPU、512内存，升级硬件也是软件厂商建议提高服务器配置，升级完成以后客户发现系统更慢了！这也可以？
正常的情况添加硬件资源不会出现这样的情况，那么这个客户是为什么呢？找了服务器的厂商各种检测，各种报告分析，无法得知原因，最终换回原配置的服务器。
这是为什么: 该软件厂商的程序基本是使用定制化模板，根据业务拼接，开发方便，但是后台语句条件复杂，语句庞大在数据量增大以后语句的执行变得很耗资源，也更依赖与CPU的并行，在没有设置并行度的情况下升级硬件（添加CPU），导致并行度过高，语句执行更慢。说白了就是简单的一个参数配置问题！
这些问题你是否有？
这样那样的问题到底是什么原因呢？谁又该来改善这样的现状呢？
用户的问题
在很多传统行业里，IT部门没有专门的DBA，或者所谓的DBA是这样一种角色：往往身兼数职（网管、项目管理、协调厂商、DBA、开发、应用、写报告），既有很多协调性的管理工作，又有一些专业技术工作。这其实和网上产品经理的段子很类似。
其实也就是说用户没有管理好自己的数据库，很多时候数据库的一些运维配置都停留在软件厂商部署时候的配置，经过几年的业务和数据的积累这些配置可能早就不适用了。再说日常的体检，随着业务增长的长期规划....好吧，那就更是没有了！
而且更糟的是，在日常的使用过程中对数据库还存在一些改造，比如毫无规划的添加数据表，一些周边功能的开发，其他方案的拼接。
所以问题慢慢的积累慢慢的爆发。
看到这有些看官自然会想，我们购买的软件，数据库不应该是软件厂商管的东西么？为什么我们要请DBA呢？
软件厂商的问题
我几年的开发经历中就有过在软件厂商做运维的经历，那个时候真的是头大，天天电话不断今天这问题明天那问题：业务问题，数据不一致问题，功能修改，新功能上线，无聊的会议，客户突发奇想我还得跟着听听吹牛。我可以夸大点说当时在做开发没有转到DBA的时候，我的数据库技能可能是整个运维团队里***的：基本的调优，索引的应用，一些系统视图的应用，指标的检测，听起来挺厉害了吧！
所以我就是运维中的DBA了？
现在回想起来，其实那个时候对数据库的了解根本没有成体系，对问题的分析也是比较片面的。解决问题也是东一锤子西一棒子，加个索引CPU指标降下来了，语句也快起来了，认为问题解决了，其实可能并没有。
呵呵，但是！在运维的时候我一天天忙的狗一样，客户不反应问题，我肯定不会主动做优化做体检，客户反映问题了，简单看一看能推就推，客户急眼了，能安抚就安抚，迫不得以出手解决一下，长期积累的问题花了很长的时间，还很可能解决不了[苦笑][苦笑]。
看到几个指标高，又解决不了，那么***反应基本就是加硬件吧。
矛盾点
用户不会配置专门的人干这样的事情，感觉都是厂商的问题，而厂商的人手技能也有限，很多软件厂商没有专业的数据库人员，又不一定能做这样的事情，最酷（苦）的就是运维人员、开发人员整天从早忙到晚连口水都喝不上，却被打上差评的标签。厂商在客户面前慢慢的失去了信服力，客户对于迟迟不能解决的问题更是很气愤，还想继续收运维费用？厂商有时也很无奈，很多时候又并不是软件的问题。
矛盾矛盾矛盾
扯皮扯皮扯皮
说说企业运维
也许是崇洋媚外，接触过几家国外的软件公司他们的运维保障服务做的确实好，但价钱也确实高，反观国内的一些软件公司很多公司在开发阶段基本是赔钱赚吆喝，而运维保障费用才是收入的开始，但是运维保障的效果确实不怎么理想，当然如果你是大客户给得起钱，那自然驻场工程师多多，服务周到，解决不了的问题也要死磕到天亮。
慢慢的国内协作运维服务已经热起来，专业的人干专业的事儿~也许这样的第三方运维引入可以解决上面的问题，一部分企业已经先行尝到了这种你好，我好，他也好的甜头。
企业运维服务已经是这个样子了：
企业服务市场，横向按客户规模分为大客户市场和中小客户市场，纵向目前最火的三大领域分别是大数据、云计算和运维服务市场，云再细分为SaaS、PaaS和IaaS，这样就构成了如下市场布局：
从运维服务产品角度来说，至少分为三层不同的能力，每一层都有各自不同的特点和要求：
-
可视化统一管理能力：从统一信息采集、监控告警到可视化运维管理能力，这个是ITOM的基础能力，做到运维服务的统一管理和可视化；
-
自动化运维服务能力：从运维自动化的统一控制、任务编排、网络业务开通和执行到自动化运维服务场景迭代，这是ITOM升级进化的必然之路，做到工具解放人力。
-
场景化驱动业务能力：运维产品最终要为运维服务、要为业务服务，从敏捷开发到敏捷运维，实现工具优化业务，让运维更敏捷。
--------------博客地址-----------------------------------------------------------------------------
