作为DB2 DBA的一些从业经验与体会

今天是4月1号，算起来进入新公司两年啦，黄历上说今天宜写日志宜作经验总结 ，那就总结下自从做DBA来的一些经验和体会吧。

DBA的个人定位
How do you spell DBA ? Here is my answer：G--O--D, GOD

有人会说啊，一个DBA有什么好自恋的啊。嗯，作为DBA，还真应该自恋，因为DBA跟GOD的确有很多相似之处：
1.全能
  一名高级DBA，不光要懂自己所管理的数据库产品的相关知识，还要了解操作系统，存储设备，网络，数据库上层所支撑的应用程序等多个层面和多个种类的软硬件方面的东西。除了这些知识储备，DBA还要善于与人沟通，有较好的分析和解决问题的能力。DBA所拥有的知识结构和软硬技能，在IT界，就是一名综合性的全能人才。
2.客户对DBA的认知就是DBA是无所不能的GOD
  硬件问题，找DBA。操作系统问题，找DBA。中间件问题。。。也是DBA。在客户眼里，DBA就是无所不能的。无所不能的，除了上帝，还能有谁？
3.DBA作为资源协调者的角色
  神说要有光，于是就有了光；又说要有空气，就有了空气。。。DBA在解决问题的时候说要加CPU，就加了CPU，要加内存，于是又加了内存，DBA在“创系统”的时候，是很有上帝创世纪的气派的

作为一名DBA，你有没有把自己当上帝？
我们每个人都存在能力短板的。按照木桶原理，一个人能力的大小，是由自己的短处而不是长处决定的。DBA的能力短板常见于对操作系统原理的理解和表达沟通的能力。 当然，全能是个方向，不是个实践。DBA是份对综合能力要求比较高的工作，让我们从自身的短处入手，不要让它成为工作能力的瓶颈。
对待客户的无理要求时，记住自己的身份，原谅这些无知的凡人吧。
遇到紧急case的时候，敲键盘时手抖的DBA有没有？我是见到过。。。请记住对自己身份的认同，相信没有自己解决不了的问题，这样手就不会抖了，哈哈。

沟通
沟通是解决问题的第一要务。沟通包含与人的沟通和与机器的沟通。较好的沟通需要遵循一些原则和应用一些技巧。
1.与人的沟通
惭愧啊，这点是哥做得不太好的地方，哥脾气暴躁，喜欢骂人 ，不过在怎么和人沟通上也还是有一些体会的。
沟通的过程中，请始终记住“KISS”，这是沟通的大原则。 不要想歪哦，此KISS非彼KISS。此处的“KISS”是说"Keep it simple, stupid!" 当为一个问题要花费很多口舌的时候，你就要反省下是不是把case给弄复杂了。理解客户的真实需求，不要提供过量的信息，一次只讨论一个case，对于复合式的问题，分解成为不可再分解的单个问题后一个个的讨论。举个例子吧。客户感觉系统慢，问DBA表A上是不是有锁？从DBA的视角来讲，这是一种相当不专业的问法，因为就算是UR隔离级别，查询也会在相应对象上加一个IN锁。客户毕竟不是DBA，这时我们要懂得其实客户的真实需求是想知道有没有锁等待，那么作为DBA，我们只要去检查下有没有锁等待，如果没有，就告诉客户没有锁等待，或者更简单一点，没有锁就OK了。但是如果DBA真的去查看表A上面所加的锁，然后告诉客户有个IN锁，就把问题复杂化了。因为客户会接着认为系统慢就是这个锁导致的，然后DBA要跟着解释这个锁不是导致系统慢的原因以及为什么不是。这就是不遵循KISS原则导致的。
我们该和客户沟通些什么呢？当一个问题发生的时候，一般我们可以使用5W1H来询问客户--What's the issue and what changes made to the system,when did the issue happen,where in the system did the issue happen,who reported the issue,why DBA is engaged and how to reproduce the issue。这样DBA对这个问题就能形成一个比较清晰的概念了。
跟客户沟通了，客户反馈了我们需要的信息，但是这些信息能全信吗？当然不能了。那些没有提供证据的更不能相信。还记得吗？客户不是上帝，我们才是！有次我被客户骚扰，说他们的网站打不开了，让他们找WAS，然后WAS说是DB的问题，然后我傻，上DB SERVER一通trouble shooting，找不到问题我还觉得罪过，最后他们找到问题说是因为http服务没起来。后来我学乖了，只要是WAS的人找，先让他们去console测试数据库连接。。
沟通过程中免不了要提问。提问也是非常讲究技巧的，比较重要的技巧之一就是要注意提问的导向性。相信大家都听说过那个卖蛋的故事。面馆里，问顾客需要不需要加鸡蛋的服务员跟问顾客是要加一个还是两个鸡蛋的服务员相比，卖出去的鸡蛋要少得多。这种技巧在由多个不同团队支持一个复杂系统，容易发生扯皮的情况下是比较有用的。
最后，不要跟人族说精灵族的语言，避免使用客户不懂的专业术语，如实在需要，将专业术语翻译成客户能听懂的语言。
2. 与机器的沟通
相较之下，与机器的沟通比与人的沟通要容易多啦。
我怀疑DBA有种原罪感。一旦一个问题发生的时候，DBA往往会自动地认为这个是DB的问题，一开始就对数据库发难，最后发现问题其实发生在操作系统层面。这大概是没有“与机器沟通”的意识。
这里的“与机器的沟通”，包括对系统硬件的认识，操作系统的了解和DB本身的情况的掌握。注意这里的先后顺序，一切系统都是附着在硬件之上的，而DB又是建立在操作系统上层的。问题发生时，不妨先排除硬件方面的限制，操作系统的问题，然后再看是不是DB本身的问题。
程序员跟系统沟通使用API，DBA跟系统沟通则使用各种各样的管理工具和日志等。作为一名DBA，对ps，iostat，vmstat，errpt等产生的各种报告的解读能力，至关重要。

分析和解决问题
问题产生了，如何分析解决呢？我总结了24个字的原则跟大家分享：大胆假设，彼此独立；小心求证，无限穷尽；他山之石，可以攻玉。
大胆假设好理解，就是列举所有的可能性。什么是彼此独立呢？彼此独立是说将一个复合的对象或者问题细分成一个个没有重叠领域的不可再分的小对象/问题。比如说一个性能问题，我们大胆假设它是因为硬件资源不足导致的，“硬件资源”这个概念太笼统，我们可以将它细分成存储，CPU，内存和网络四个彼此独立的对象。又比如说客户说他们的系统变慢了，这时候我们要进一步了解“系统慢”这一问题，就可以使用5W1H的方法将这个复合问题分解成若干个独立的小问题。如何大胆假设貌似没有什么现成的方法，这个一是靠自己的经验积累，另外不妨做做头脑风暴。
如果说“大胆假设，彼此独立”是做加法，那么“小心求证，无限穷尽”就是做减法挨个排除种种可能性了。排除可能性的过程可以说是诊断问题的核心。小心求证的过程就是这个做减法的过程，这里没什么可以多说的，纯粹是对DBA综合技能的应用了。“无限穷尽”则是需要被强调的。无限穷尽是说对一个问题要追根究底，找到解决问题的根本原因然后彻底解决问题。一般我们可以通过5个WHY甚至更多WHY的办法找到根本原因。这里我就不举例了，Tao的这个案例是“小心求证，无限穷尽”的经典中的经典。传送门 ==> http://www.itpub.net/thread-1108225-1-1.html
虽然我们自认为是上帝，不过就算是玉帝级别的DBA，也要明白天有九重，天外有天的道理 。有句话叫“他山之石，可以攻玉”，作为一名DBA，不要所有问题都自己扛，独自一个人流泪到天亮。碰到不懂的问题，求救吧！求救顺序：旁边的死胖子==》information center ==》DB2 product support central ==》论坛，goole ==》PMR，如果没买PPA，那你还是继续哭吧

Visibility
这次看ITIL，什么都不记得了，就记得一句，service operation's contribution to adding value to business is "service value is visible to customers". 我对这句话的理解就是DBA做的贡献要是没被客户看到，那就等于什么都没做！于是我懂了，ITIL叫做DBA的做事高调点，DBA不能老是埋头做事啊，有点鸡毛蒜皮的贡献我们必须得大叫这个问题是我们搞定的啊，不说铺红地毯开香槟庆祝，但群发邮件并且CC给客户的经理是必须的啊 。

就写到这吧。末了想说的是，得道成仙者能自由出入人鬼神三界。得道DBA应是能自由游走于硬技能和软技能之间的，愿大家早日得道，成为一名高级DBA。

转载：http://www.db2china.net/home/space.php?uid=31229&do=blog&id=13382