为什么我们用的系统这么烂?谁的锅?

吴虞 2017-01-11 09:58:15

作者介绍

吴虞SQL专家云团队成员,擅长解决SQL Server数据库性能、高可用、负载均衡等问题。

 

开篇小故事
 

 

下面的故事都是真实的,犹如雷同纯属同类,请仔细反思。

 

故事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升级进化的必然之路,做到工具解放人力。

  • 场景化驱动业务能力:运维产品最终要为运维服务、要为业务服务,从敏捷开发到敏捷运维,实现工具优化业务,让运维更敏捷。

 
最新评论
访客 2023年08月20日

230721

访客 2023年08月16日

1、导入Mongo Monitor监控工具表结构(mongo_monitor…

访客 2023年08月04日

上面提到: 在问题描述的架构图中我们可以看到,Click…

访客 2023年07月19日

PMM不香吗?

访客 2023年06月20日

如今看都很棒

活动预告