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

开篇小故事

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

故事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升级进化的必然之路,做到工具解放人力。
  • 场景化驱动业务能力:运维产品最终要为运维服务、要为业务服务,从敏捷开发到敏捷运维,实现工具优化业务,让运维更敏捷。

作者:Double_K

来源:51CTO

时间: 2024-10-26 05:40:49

为什么我们用的系统这么烂?的相关文章

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

作者介绍 吴虞,SQL专家云团队成员,擅长解决SQL Server数据库性能.高可用.负载均衡等问题.   开篇小故事    下面的故事都是真实的,犹如雷同纯属同类,请仔细反思.   故事1:升级硬件   客户后台数据库存在性能问题,查询特别慢,长时间语句很多.客户因此而苦恼,咨询了软件厂商我该怎么办?软件厂商给出的答案:升级硬件吧,现在的资源不能满足了!   那么客户是什么硬件配置?数据库什么体量?   答:128的CPU.512的内存.高端的存储,跑了一个200G数据量的库,好像硬件满满的够

Linux桌面系统离你还太远

当XP系统退出历史舞台的时候,众多的Linux爱好者就撰文列举Linux替代XP的种种可能.虽然讲得很有道理,加上我是一个Linux的忠实用户,但我觉得Linux桌面系统拥抱普通大众还为时尚早,在大众心中已有千万的理由.这种等待的时间会很长,可我并不觉得它不可能成为一种替代的方案. 我使用Ubuntu作为我工作和平时娱乐的系统已快三年,但我并不敢说自己熟悉它,也只是在他人的指引下完成一些东西.相比较开始的阶段,现在的进步主要是对它有了更进一步的了解.起先是看看他人写的东西,经过这些年的折腾,自己

XP进程优化

  评价一个操作系统,最常用的指标包括安全性.稳定性.易用性和运行效率等.下面,就按照这个顺序,对WINDOWS XP系统的服务分类进行逐一说明. 一.关系到系统安全的服务 在病毒横行的今天,系统安全可能是最受关注的问题了,除了病毒.外来恶意程序以外,微软默认开启的系统服务也存在一些值得反思的问题. 1.Portable Media Serial Number Service 描述:Retrieves the serial number of any portable media player

基于Google Reader发展起来的个性化推荐系统之三大问题

郑昀@玩聚SR 20091003     中科院的xlvector(即项亮,他所在的团队The Ensemble在7月份获得Netflix大奖赛公开测试排名第一,但在9月22日Netflix宣布BPC获胜,原因据说只是因为项亮他们提交结果晚了20分钟)最近发布了一个小工具GRSuggest,有点像之前Kuber在FeedzShare所做过的"个性化阅读",都属于"基于某个Google Reader用户的Shared Items中的文章,为该用户推荐他可能感兴趣的其他文章&qu

整洁之道 如何让代码更明确、简单、有力

中介交易 SEO诊断 淘宝客 云主机 技术大厅 这篇文章摘录自<代码整洁之道>第一章,这本书被看作是程序员必读的书籍之一.但好的书不只是交给你工具.技术,更多是思维过程,近乎禅学.至理,这本书符合这样的定义.本章技术元素最少,适合每一个领域的人阅读. 阅读本书有两种原因:第一,你是个程序员;第二,你想成为更好的程序员.很好.我们需要更好的程序员. 这是本有关编写好程序的书.它充斥着代码.我们要从各个方向来考察这些代码.从顶向下,从底往上,从里而外.读完后,就能知道许多关于代码的事了.而且,我们

程序猿日记S01E06-共识机制

"Be yourself." 评分 <黑镜>从第一季第一集开始,就是能看出是一个脑洞特大的剧集.每一集都是独立的剧情,涵盖了当前一些热门的人类行为和科技理念.比如社交网络.虚拟现实.记忆读取.人工智能.因为剧情脑洞很大,所以看起来比较怪诞哈.最近一位好朋友推荐看看第三季的第一季<急转直下>,因为里面提到的一个社交评分理念比较有意思."故事讲述的是在未来世界里,科技的发展改变了人们的社交方式,当一个人和另外一个人接触之后,可以马上通过手机给对方打分,满分

一个女人的机器人日记

自五月开始,我在某种程度上变成了机器人. 内置陀螺仪的自动稳定轮子代替了我的脚,iPad 的屏幕代替了我的脸,非广角摄像头代替了我的眼,我听不到的喇叭代替了我的口,每当收到高音就会发出爆裂声和嘘声的小麦克风代替了我的耳朵. 我是一个远程工作者,当大多数其它 WIRED 工作人员都在美国西部旧金山的时候,我则住在东部的波士顿.通常我们通过即时信息.电话.Twitter 来保持联系.但是我经常无法出席重要的面对面会议.员工自发的头脑风暴和厨房里的八卦谈话. 针对这样的情况,我的老板找到了一个解决办法

“动态流、瀑布流、奖章”,三种流行的产品要素

根据我的研究和发现,得出了三种流行的产品要素"动态流.瀑布流.奖章",而我称之为产品三俗,因为容易流行而被滥用.而PM选择它们有可能是因为"时髦""标配""别人都在用",但是这很糟糕.又恰好动态流和奖章其实我都折腾过,所以多多少少吃过一点亏,现总结如下. ▎动态流 其实动态流能够给产品带来的好处有很多,比如以用户为节点实现了近乎于完美的信息分发网络.但是,在采用这个设计之前,我觉得我们首先应该要理解,在用户层面上,其本质就是&

《代码整洁之道》—第1章1.3节混乱的代价

1.3 混乱的代价只要你干过两三年编程,就有可能曾被某人的糟糕的代码绊倒过.如果你编程不止两三年,也有可能被这种代码拖过后腿.进度延缓的程度会很严重.有些团队在项目初期进展迅速,但有那么一两年的时间却慢如蜗行.对代码的每次修改都影响到其他两三处代码.修改无小事.每次添加或修改代码,都得对那堆扭纹柴了然于心,这样才能往上扔更多的扭纹柴.这团乱麻越来越大,再也无法理清,最后束手无策. 随着混乱的增加,团队生产力也持续下降,趋向于零.当生产力下降时,管理层就只有一件事可做了:增加更多人手到项目中,期望