我们不是不够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到没有思考（我们的这种状态正常吗？需要反思吗？需要改进吗？什么是我们的追求？）