写给运维兄弟

写给运维兄弟

写在前面的故事

首先，给看官们讲个故事：最近遇到过一个客户，系统上线三年变的越来越慢，直到前几个月全面爆发，系统前端使用人员不断抱怨，甚至已经达到了不能使用的程度。这个时候他们的IT主管也是决策者无法忍受这种情况，就召集下面的运维开会，询问情况。

领导：现在系统这么慢，前端都无法使用了，到底什么情况？

运维人员A：我们的服务器CPU压力太大，一直处于90%以上！

运维人员B：我们的服务器内存不足总是90%以上！

运维人员C：我们的磁盘速度跟不上了，换SSD会有很大提高！

领导：啥都不行了？那我们换高配服务器！

。。。。。。。。。。。。。。

换了服务器，好了半个月又开始慢...和之前一样基本没有任何缓解...领导又召集运维人员开会。

领导：服务器都换了，配置增加了一倍还多，为什么还慢？

运维人员：我们需要做读写分离，做集群分担压力！

运维人员：软件不行了，这个软件太差！

领导：。。。。

如果你是领导，那么你该如果决策呢？ 如果你是运维人员，你会有上面的回答么？

可能你看完会笑，认为这是不可能发生的故事，然而这个故事确实是真实的！反之如果这个故事中看到了自己,那么请仔细地往下看喽！

--------------博客地址---------------------------------------------------------------------------------------

废话不多说，直接开整-----------------------------------------------------------------------------------------

数据库在系统中的角色

这个可能不用多说，大家都知道，一般系统慢都是慢在后端，而后端主要慢在与数据库的交互！

数据库可以理解成独立于你的系统，成为一个单独的系统。无论从数据库的物理设计，与前端的交互方式，自身的参数设置，索引的设计，维护方案等都影响着你整个系统中最慢的环节（可以说整个系统中数据库就是最慢的环节）！

同样通过数据库的状态，也能很大程度上判定出你系统的问题到底在哪。尤其能界定清的一点就是软件真的慢么？软件设计的不好？还是数据库年久失修？

几个问题

你了解你的数据库么

了解决定效率

也许很多老司机有这样的感觉，我运维的效率如何，这取决于我对系统的了解！出现什么样的情况，我就知道是哪里的问题，代码在哪里，问题在哪里！看错误号、看异常便知问题，也就是未出茅庐，已知三分天下！反过来新手可能需要debug跟一遍还一知半解。对于数据库道理也是一样的，数据库系统出现什么问题你是否能很准确的定位的可能发生问题的几个点？或者我需要查看系统哪些指标？系统中存在着哪些隐患？哪些功能慢？哪些语句需要优化？哪些运维策略做的不合理？

出现问题能从容面对么

从容出自积累

从容面对这个词说起来容易,但是我自身从小白的开发到现在的DBA一路走来真的是积累了很多，坑也踩了很多才能做到从容面对。

这里举几个现象 :

当你的CPU从稳定的30% 飙升到90%以上,你能想到的可能原因是什么? 怎么样快速排查?

当你平稳的业务出现大面积超时,你能想到的可能原因是什么? 怎么样快速排查?

真的了解么

习惯至深入

在很多次和运维人员交流的过程中发现，我知道的名词和他知道的名词完全不是一个东西！比如：死锁。同样提到索引，他会说不用讲，这我都懂。那么什么是联合索引，什么是覆盖索引？覆盖索引怎么能降低你的死锁概率？ 这时他的反应才是：哦...原来还可以这样，原来还有这么多东西！

模拟一个场景，领导开会的时候问你如下问题：

领导问：

数据库有多大 ？ 每天增长多少 ?高峰时间卡慢么 ? 为什么慢 ? 数据库问题还是软件或硬件？系统中那些语句慢 ? 慢到什么程度？系统中哪些资源是瓶颈 ?存在死锁情况么？ 怎么产生的？有什么潜在风险 ？怎么解决 ？

很多人运维人员的回答可能是：

。。。。。。。。。。

而问题发生的时候可能发生的情况就是这样的：

你是哪一类？

背景：今天，数据库普遍存在问题，如：性能问题、安全问题、可靠性问题、数据备份问题、结构设计问题等。

结论：

当出了问题时，用户不知道是谁的原因，系统的真实状况如何？问题一大堆，多数人没意识到是数据库问题，很多人想弄但不会弄，还有一部分人会弄但传统的方法不方便。

你是下面那个角色？

你是否像救火队员？牺牲着自己的休息时间随叫随到的运维这你的系统？你是否像拆弹兵一样维护着一个随时爆炸的系统？你是否又像一个保姆，寸步不离的呵护着你的系统？

怎么办？

可能不少看官就是上面的一员，但是又很迷惑，我该怎么办？我要从头深入学习数据库？学个几年到精通？ 当然不需要，其实数据库运维很简单！你只需要了解常规的运维套路，常规的系统指标，和常规的问题排查方式，这样已经可以解决80%的问题。如果出现搞不定的20%你需要的数据库专业人员的协作。

运维三步走:

发现问题　　解决问题　　预防问题

是不是感觉说的很轻巧...本文除了让运维人员了解数据库在系统中的重要，多关注数据库，多了解一些数据库的运维方式外，也推荐一款工具，所谓工欲善其事，必先利其器！

推荐一款工具

Expert for SQLServer 一款SQLSERVER的体检诊断专家。

发现问题

全面体检（不仅仅是性能），让你知道数据库的真实运行状况、存在的问题及潜在风险

按照6大维度， 108项指标（软硬件环境、参数配置、结构设计、性能、可用性、备份、安全）建立体检标准，定期对数据库进行全面体检，客观呈现数据库的真实运行状况，所有问题一览无余。

解决问题

快速诊断，分析出系统的主要问题并进行分类，同时提供解决之道

通过数据分析，将数据库的问题按照严重程度进行分类，按照提示的方式进行调整，所有问题。不管你懂数据库还是不懂数据库，你都可以清晰地知道，应该从哪入手，进而快速地解决问题，让天下没有难用的数据库。

预防问题

定期体检，才能消灭隐患，买辆车还定期保养呢，这就是所谓的防患于未然，把问题消灭在萌芽中。

个人建议，不管你用什么工具，或使用脚本。

核心系统体检：1月/次

重要系统：2月或3月/次

有功能上线，或结构变更等都需要做一次体检。

多人或大牛协作

就像一个系统运转有硬件，网络，程序，数据库，需要多方、多人协作一样，数据库的问题一样，每个人都有擅长的部分，那么多人协作就是可以更全面的解决系统问题，这款工具的最大优势在于提供了多人协作的基础数据。这份体检数据包含了数据库运行中的大部分指标，所有时间点的状况，计数器的指标，语句间的阻塞等等信息，这远胜于传统运维中拼凑堆砌出来的脚本数据。

这就像医院的电子病历，对全身有了全面的检查，X光片子、各种检验、化验数据在手，可能你去到哪个医院，找哪个专家或医生汇诊都可以作为他们协作的依据！

--------------博客地址---------------------------------------------------------------------------------------

-----------------------------------------------------------------------------------------------------

总结 ： 亲身处理了上百家客户的系统，大部分系统数据库都存在着各种数据库问题，而数据库问题往往被忽视，直接被归结为软件的问题，厂商的问题！

数据库应该被我们重视起来，很多时候只是在数据库上做一些常规的配置或简单的优化，就能让系统有几倍甚至几十倍的提升，而这些优化可能只是简简单单的数据库层面完全不用改代码的行为！

系统运维需要定期体检，这点真心希望运维人员能够重视起来，也真心希望系统运维人员可以加深一下对数据库的了解，多掌握一些常规的手段和必要的运维策略。

工欲善其事，必先利其器，运维同样需要一些简单方便的工具！

本文提到的工具下载链接：

本人使用工具优化的相关文章链接 ：

----------------------------------------------------------------------------------------------------

引用高大侠的一句话 ：“拒绝SQL Server背锅，从我做起!”