我们不是不够skill,我们只是have no time

这篇文章不是关于技术的,而是关于工作的一些思考。

起因是这样的,5月底6月初开始,某个客户上海的项目遭遇客户抱怨,SDM异常紧张,现场的PM压力也非常大,召集各个team频繁会议,最终在网络工程师的努力下,发现系统变慢是由于某个感染病毒的客户端连接上来,造成了应用服务器的cpu消耗过高,当隔离该客户端之后,问题就解决了。

问题解决后,客户要求提供相关的文档,说明解决思路和日后的处理方法。ok,这也没问题,客户的要求很合理,考虑也很周到,因为万一相关人员离职了,后续的工作谁来做,没有文档记录,每个人有每个人的处理方法,就没有了标准的作业流程。于是,大家就是忙着准备各自领域内的操作文档。

本来,事情应该告一段落,但是又跳出一个架构的项目经理,说数据库也存在性能问题,列举了几条performance issue。我不太清楚当初的这几条performance issue是怎么提交上去的,首先说说这几条issue,从我的观点看,表空间的大小调整,死锁的发生,还有数据的加载时间段——这些,其实应该算是一个troubleshooting的问题,而不是放到performance tunning来做。所以,第一,问题的引入就不是非常的恰当。因为performance tunning,必须是有一个明确的问题和目标,比如,cpu idle过小,内存使用率过高,应用的某个模块执行过慢。通过tunning,我系统cpu idle达到多少,内存使用率降低到多少,应用模块执行在多少秒内完成,等等。有了具体的目标,我们才能针对目标进行tunning。而不是说你去查一下数据库中的parameter,看看有没有设置不合理的,我们调整这些参数来改变数据库。tunning的第一步,就是应该设立一个明确的问题和目标。

当确立tunning目标之后,开始tunning。就tunning的工作来说,这是一个没有尽头的工作,谁也无法说,我将这个tunning的工作做到了极致了,已经没有可以再优化的东西了。正确的tunning,应该是根据之前确立的目标,一旦到达这个目标,后续的事情就应该停止了。而在这个案例中,系统的瓶颈不是出在数据库,而是一个感染病毒的客户端,查出问题,解决问题,ok,tunning就应该到此为止。

退一步讲,如果数据库确实存在问题,而且客户提出了tunning要求,ok,那么dba进行介入。这里就涉及到一个用人的问题。我向来的观点是:用人不疑,疑人不用。但是在我收到邀请我参加performance issue meeting之后,我得知还有一个北京的DBA会来参与这个tunning。本来,多一个人,多一种思路,大家集思广益,观点和思想互相交锋,这是有好处的。但是当我了解到,这是因为上面的领导觉得我们team不够skill去做这个事情,特地的从北京的team要了一个dba来临时帮忙cover这个事情,我就觉得非常的气愤了。

我们不是不够skill,我们只是have no time。进入IBM之后,我就发现大家的工作量非常的饱和,当然,这个工作量不仅仅是在处理事情上,也有很大的一部分时间,是在会议上,在写报告上,在参加公司政策的培训上,在对流程的熟悉上,在不断的填写自己的个人信息个人计划个人目标个人总结上,在不断的create change,approve change和做change上(当然很多change不是在上班时间做,很多change是在下班时间做,连alter tablespace add datafile这样的常规维护操作,也要安排到晚上,也有人会跑过来问你这个操作有没有在测试环境上做过——虽然可能他也不知道我们有没有测试环境)。在team中,似乎流行着一种心态,就是我加班你不加班,我就嫉妒你,你应该留下来陪我们一起加班。这本来就是一种不正常的心态,之前在推上听过一句话,不希望别人幸福的人,自己永远得不到幸福。由于这种变态的加班心理存在,感觉每次上班的心情和上坟差不多了。但是,为什么会有这样的心态产生呢?说到底,还是工作量的缘故。从数据库的数量上来说,我们已经接近快500个instance了,但是维护的人员只有4个。IBM的库虽然都不大,也就几十百来G,但是由于数量多,出问题的概率就大了。而且不仅仅是出问题,平常的一些简单操作,比如执行某个应用的脚本,也需要dba,这就造成了dba在整个系统中充当的角色,是个消防员。

在进一步想一下,是什么造成了我们这么大的工作量?是近500台db吗?其实不是,500台的db,如果一开始的架构做的好,就完全不会有那么多的麻烦。在我接触到的这个项目中,一台sever上多个instance比比皆是,某项目一台server上有24个instance,另外还有生产库和测试库混杂在一起,oltp和dss混杂在一起。作为一开始的架构,db服务器就应该是一个专用的机器,一般情况下,都是可以一个instance里面多个schema来解决,如果真的不行,需要分离,那么比如像上面说一台server上24个db,可以采用intel的虚拟化技术,通过建立多个虚拟机来实现。操蛋的架构,导致了后续维护成本的升高。

除了架构,还有什么?除了架构,还是架构!不过这个架个不是系统的架构,而是项目管理的架构。这个项目中的哪个项目经理是老大?我该听谁的话,我该对谁负责?PM M?PM L?还是PM J?每一个都会蹦出来邀请我参加会议,会议完之后一堆任务。项目管理架构的混乱,导致人员疲于准备会议、参加会议、总结会议、完成会议的任务、汇报任务的情况、最后在召开会议大家一起回顾。

除了架构,还有什么?除了架构,还是架构!不过这个架个不是系统的架构,而是人员的架构。由于在外企,人们都是被摁在一个框一个框之内,接触到的东西就只有眼前的那么一点,要站在整体的角度去看问题,就非常困难,成本很高。很多情况下,会出现这样的问题:客户抱怨说系统慢的不行了,然后应用检查说没问题,网络检查说没问题,主机检查说没问题,数据库检查说没问题,中间件检查说没问题。那么既然大家都没问题,为什么客户那边就发生了问题?那是因为大家都只盯着眼前的一块,没有站在高处去看这个问题,没有一个能掌控整个架构的人出现。

作为一个dba,应该有整体运维的思维,而不仅仅局限在db上的一点。从开始的容量预估,架构设计,高可用方案设计,容灾设计,备份设计,集成部署,到中间的日常维护,监控(监控数据库、监控集群情况、监控网络、监控备份、监控主机三驾马车:cpu、内存、io),从监控的数据得到性能的基线和波动曲线,了解业务的峰值和空闲时间,定期的巡检,还有性能优化,到后来,还要关注补丁计划,迁移计划,版本升级计划,以及容灾演练的操作……

回到之前的那个performance issue,其实我挺佩服北京的dba那哥们,他确实是一个很不错的dba,站的角度也很高,从主机参数到磁盘IO各项性能指标都进行询问。另外,我们深圳dba team的内部也对这个case进行了讨论,在讨论中,大家都对该issue发表了很有针对性的看法,Dean、Rainny都是一等一的好手,我觉得我们的team完全有实力去解决这个问题!我不知道为什么在我接手之前,上面的领导会觉得我们team不够skill。我只是觉得:我们不是不够skill,我们只是have no time——no time到没有生活(同事去东部华侨城玩的时候还背着笔记本电脑),no time到没有自我提升(晚上做完change回到家基本可以洗洗睡了,不用看什么书了),no time到没有改进(工作就是让你去完成的,你想改进,连个测试的时间都没有),no time到没有思考(我们的这种状态正常吗?需要反思吗?需要改进吗?什么是我们的追求?)

相关文章

13条评论

  1. 我也觉得在计算机行业用另A技术的思想去使用B技术是非常恶心的事情
    应该的情形是学习需要使用的技术设计是假设场景,理解使用技术的设计目标,
    应用的环境应该尽量满足使用技术的假设场景
    要是应用的场景和使用技术的相差太多,那就要换中解决方案了。

  2. 刚看完javaeye robbin的文章: 去跨国公司还是去创业公司?,再看你这篇文章
    现在已经直接无语了

  3. 尝试改变环境吧. 或者换个新环境.

    鄙人作为DBA,主要工作是设计和编码,自己负责,自己控制.

    Facebook的总结说的对.

  4. 这也许是他们企业文化的一部分,生根低估。这种公司改变他们的环境似乎很困难,但可以尝试一下。

  5. 这个抱怨很正常。
    MBI 大多的项目都这样,切身体会,如果不换个环境,这样的状况是改变不了的。
    很多项目都是specialist ,consultant + sub ,sub的人水平好点还行,遇
    上水平差的你就痛苦吧。

  6. 考ocm之前跟ibm说了等考完后再跟他们联系,现在看到楼主这遭遇,看来到哪都一样啊!

发表评论

电子邮件地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据