以下开篇短篇故事皆为真实，如同类，请慎重反省。案例一：升级硬件客户后台数据库出现性能问题，查询极慢，长期语句较多。客户为此苦恼，咨询了软件厂商，怎么办？软件厂商给出的答案：升级硬件，当前资源不够用！那么客户有什么样的硬件配置呢？数据库的大小是多少？答：128个CPU，512内存，高端存储，运行200G的数据库，看来硬件够用了！问题的根源是最基本的大小索引！故事二：负载均衡客户想做数据库负载均衡，找我们。各种节目，各种高层都说我深受客户前卫思想的洗礼。毕竟很多传统行业都比较关心数据库的性能和安全性。有些保证并不完美。前期我们聊的很愉快，后来我去查看了客户的现有环境，更让我惊喜的事情发生了。运行在同一台物理机上的两个虚拟机需要做负载均衡？长线的节奏一定要分，长线一定要合？故事三：高配置更慢？客户将原64CPU、128内存的服务器升级为128CPU、512内存。硬件升级也是软件厂商建议的，以提高服务器配置。升级完成后，客户发现系统更慢了！这也行？一般情况下，增加硬件资源是不会出现这种情况的，那么为什么是这个客户呢？找了服务器厂商各种测试，各种报告分析，都查不出原因，最后还是用原来的配置更换了服务器。这是因为：软件厂商的程序基本都是采用自定义模板，容易根据业务拼接开发，但后台语句条件复杂，语句庞大。数据量增大后，语句的执行变得非常耗资源，更加依赖CPU并行度，升级硬件（加CPU）不设置并行度，导致并行度高，语句执行速度变慢。说白了就是一个简单的参数配置问题！你有这些问题吗？出现这些问题的原因是什么？谁应该改善现状？用户的问题在很多传统行业中，IT部门并没有专门的DBA，或者说所谓的DBA就是这样一个角色：往往身兼数职（网络管理、项目管理、协调厂商、DBA、开发、应用、写报告），不仅有很多协调管理工作，还有一些专业技术工作。这其实很像线上产品经理的笑话。其实就是用户没有管理好自己的数据库。很多时候，数据库的一些运维配置停留在软件厂商部署的配置上。经过几年的业务和数据积累，这些配置可能不会长期适用。除了每天的体检，随着业务的增长做长远的规划……好吧，那就没有了！而且更糟糕的是，在日常使用过程中，还会对数据库进行一些修改，比如无计划地添加数据表，开发一些外围功能，拼接其他方案等。于是问题慢慢积累，慢慢爆发。看到这里，有些评委自然会想，我们买的软件和数据库不应该由软件厂商来管理吗？为什么我们需要DBA？软件厂商的问题在我几年的开发经历中，我有过为软件厂商做运维的经历。那时候我真的是受不了了，每天都不停地打电话。今天的问题将是明天的问题：业务问题、数据不一致和功能修改，新功能上线，无聊的会议，客户心血来潮的时候我还得听吹牛。我可以夸张地说，在我做开发没转DBA的时候，我的数据库技能可能是整个运维团队里最好的：基础调优，索引的应用，一些系统视图的应用，检测指标，听起来很棒！所以我是运维的DBA？现在回过头来看，其实当时对数据库的理解一点也不系统，对问题的分析也比较片面。解决问题也是东锤西棒。加了一个指标，CPU指标下降了，语句快要上升了。我认为问题已经解决了，但实际上未必。哦，但是！运维期间，我每天忙得跟狗一样。如果客户不回应问题，我肯定不会主动优化和做体检，我别无选择，只能采取行动解决。长期积累的问题拖了很久，很可能解决不了[苦笑][苦笑]。看到几个指标偏高，解决不了，那最大的反应基本就是加硬件了。矛盾的地方在于，用户不会指派专人去做这样的事情。感觉是厂家的问题，厂家的人力技能也有限。很多软件厂商没有专业的数据库人员，他们不一定能做这样的事情。最爽（苦）的是运维人员和开发人员，他们从早忙到晚，口水都喝不下，却被贴上差评的标签。厂家在客户面前慢慢失去了信誉，长期解决不了的问题客户更是气愤不已，还想继续收运维费？厂家有时候也很无奈，很多时候不是软件的问题。矛盾与矛盾矛盾与冲突。谈天说地谈企业运维，可能是在鼓吹老外。我接触过几家国外的软件公司。开发阶段基本上是亏本赚钱，运维支持费是收入的开始，但是运维支持的效果不是很理想。当然，如果你是出得起钱的大客户，那自然是现场工程师多，服务周到，解决不了的问题就得砸到天亮。慢慢的国内协同运维服务开始普及，专业的人做专业的事~或许引入这样的第三方运维可以解决以上问题。一些公司已经尝到了这种你好，我，他的甜头。企业运维服务已经是这样了：企业服务市场按客户规模横向分为大客户市场和中小客户市场，最热门的三个垂直领域分别是大数据、云计算和运维服务市场。进一步细分为SaaS、PaaS和IaaS，从而形成如下市场布局：从运维服务产品来看，至少分为三层不同的能力，每一层都有自己不同的特点和需求：统一可视化管理能力：从统一信息采集、监控告警到可视化运维管理能力，这是ITOM实现运维业务统一管理和可视化的基础能力；自动化运维服务能力：从统一管控运维自动化、任务编排、网络服务发放和执行，到自动化运维服务场景迭代，这是ITOM升级演进的必经之路，让工具得以解放人手。场景驱动的业务能力：运维产品最终要服务于运维和业务。从敏捷开发到敏捷运维，落地工具优化业务，让运维更敏捷。--------------博客地址--------------------------------------------------------------------------博客地址http://www.cnblogs.com/double-K/
