写给数据库运维的兄弟
写在前面的故事
首先，给看官们讲个故事：最近遇到过一个客户，系统上线三年变的越来越慢，直到前几个月全面爆发，系统前端使用人员不断抱怨，甚至已经达到了不能使用的程度。这个时候他们的IT主管也是决策者无法忍受这种情况，就召集下面的运维开会，询问情况。
领导：现在系统这么慢，前端都无法使用了，到底什么情况？
运维人员A：我们的服务器CPU压力太大，一直处于90%以上！
运维人员B：我们的服务器内存不足总是90%以上！
运维人员C：我们的磁盘速度跟不上了，换SSD会有很大提高！
领导：啥都不行了？那我们换高配服务器！
。。。。。。。。。。。。。。
换了服务器，好了半个月又开始慢...和之前一样没有任何缓解...领导又召集运维人员开会。
领导：服务器都换了，配置增加了好几倍，为什么还慢？
运维人员A：我们需要做读写分离，做集群分担压力！
运维人员B：软件不行了，这个软件太差！
运维人员C：他们说的对！
领导：。。。。
如果你是领导，那么你该如果决策呢？如果你是运维人员，你会有上面的回答么？
可能你看完会笑，认为这是不可能发生的故事，然而这个故事确实是真实的！反之如果这个故事中看到了自己,那么请仔细地往下看喽！
数据库在系统中的角色
这个可能不用多说，大家都知道，一般系统慢都是慢在后端，而后端主要慢在与数据库的交互！
数据库可以理解成独立于你的系统，成为一个单独的系统。无论从数据库的物理设计，与前端的交互方式，自身的参数设置，索引的设计，维护方案等都影响着你整个系统中最慢的环节（可以说整个系统中数据库就是最慢的环节）！
几个问题
了解决定效率
也许很多老司机有这样的感觉，我运维的效率如何，这取决于我对系统的了解！出现什么样的情况，我就知道是哪里的问题，代码在哪里，问题在哪里！看错误号、看异常便知问题，也就是未出茅庐，已知三分天下！反过来新手可能需要debug跟一遍还一知半解。对于数据库道理也是一样的，数据库系统出现什么问题你是否能很准确的定位的可能发生问题的几个点？或者我需要查看系统哪些指标？系统中存在着哪些隐患？哪些功能慢？哪些语句需要优化？哪些运维策略做的不合理？
从容出自积累
从容面对这个词说起来容易,但是我自身从小白的开发到现在的DBA一路走来真的是积累了很多，坑也踩了很多才能做到从容面对。
这里举几个现象 :
当你的CPU从稳定的30% 飙升到90%以上,你能想到的可能原因是什么? 怎么样快速排查?
当你平稳的业务出现大面积超时,你能想到的可能原因是什么? 怎么样快速排查?
习惯至深入
在很多次和运维人员交流的过程中发现，我知道的名词和他知道的名词完全不是一个东西！比如：死锁，接触的很多技术人员把阻塞理解成死锁。同样提到索引，他会说：“不用讲，这我都懂！”，那么什么是联合索引，什么是覆盖索引？覆盖索引怎么能降低你的死锁概率？这时他的反应才是：哦...原来还可以这样，原来还有这么多东西！
模拟一个场景，领导开会的时候问你如下问题：
领导问：
-
数据库有多大 ？每天增长多少 ?
-
高峰时间卡慢么 ? 为什么慢 ? 数据库问题还是软件或硬件？
-
系统中那些语句慢 ? 慢到什么程度？
-
系统中哪些资源是瓶颈 ?
-
存在死锁情况么？怎么产生的？
-
有什么潜在风险 ？
-
怎么解决 ？
很多人运维人员的回答可能是：
。。。。。。。。。。
而问题发生的时候可能发生的情况就是这样的：
背景：今天，数据库普遍存在问题，如：性能问题、安全问题、可靠性问题、数据备份问题、结构设计问题等。
结论：
-
当出了问题时，用户不知道是谁的原因，系统的真实状况如何？
-
问题一大堆，多数人没意识到是数据库问题，很多人想弄但不会弄，还有一部分人会弄但传统的方法不方便。
-
人手有限，往往身兼数职（网管、项目管理、协调厂商、DBA、应用、写报告），既有很多协调性的管理工作，又有一些专业技术工作，尤其是数据库，短时间是很难深入掌握的。
-
自己开发系统，擅长程序开发，对于数据库，了解的不深，更多的是业务逻辑，比如表结构设计、如何写存储过程等，导致后期很多业务存在性能瓶颈。
-
买的软件厂商的，在他们的行业里，IT运维人员对系统进行的往往是简单维护，做的最多的是和业务功能相关的事情，很多数据库的专业问题困扰着他们，招聘资深数据库专家吧，人家不来，自己解决吧，又很吃力，寻求厂商，他们也没有好的方案，集成商就是换硬件。
可能不少看官就是上面的一员，但是又很迷惑，我该怎么办？我要从头深入学习数据库？学个几年到精通？当然不现实，下面就说一说我从业十年从小白到技术支持的感悟。
其实数据库运维很简单！你只需要有一个好的工具，了解常规的运维套路，常规的系统指标，和常规的问题排查方式，这样已经可以解决80%的问题。如果出现搞不定的20%你需要的数据库专业人员的协作。深入学习
如果对技术感兴趣想在数据库这条路上长久的走下去，并且也想成为独挡一面的大神，那么耐下心来看书学习是必经之路，并且在实际的项目中不断积累慢慢的在坑中成长。
自己的SQL学习之路有好多个Level下面具体说一说：
LV1 ：程序开发中写过大量比较复杂逻辑的SQL语句，报表查询，如2000行以上的存储过程，存储过程嵌套存储过程等等。
写过这种复杂SQL程序的开发人员也许都会有一种 我数据库已经无敌了什么都会了的感觉。
在项目中特别爱写SQL，有的老员工一些复杂SQL也会让你帮忙。
这个时候的感觉真好！
LV2 ：开始学习SQL语句的优化，慢慢开始分析执行计划。
虽然执行计划看的不是很明白但是已经知道语句慢在哪里，知道使用索引，临时表等一些简单的优化手段。
慢慢的知道了什么是缓存计划，什么是参数嗅探。
SQL语句几分钟变成几秒钟，感觉真奇妙~~哈哈~~
LV3 ：开始学习数据库体系架构了解原理，学习使用系统表视图查看当前状态
这个阶段是痛苦而漫长的需要看大量的书动手实践也是必不可少的。
当看完2005技术内幕的4本书，可以给身边的人从原理讲讲什么是SQL 怎么运行的~飘飘的感觉又来了。
这个阶段是兴奋又迷茫的，感觉自己会了很多东西但与此同时又感觉到自己什么都不会了...
LV4 ：几条线开始显现出来，SQL开发，优化，集群技术，故障排查。
很多SQL开发的较为高级应用。
profiler、perfmon的基本应用（虽然很多参数指标看不懂）、能读懂较为简单的执行计划并根据情况做语句优化。
能搭建事务日志传输、镜像、发布订阅、故障转移群集。
简单的故障可以解决。
我就走上了初级DBA的道路....
LV5 ：依然不断学习SQL原理，深扣细节，多看博客文章自己动手模拟情景。
了解更多的数据库功能应用。出现问题有更多的知识储备处理问题。
熟悉常规套路，找出的系统瓶颈及有哪些处理办法，语句的优化提示等等。
漫长漫长又漫长的积累经验。
LV6 ：作为技术支持，见过上百家客户的系统，见过大量的情景，依然不断的积累经验。
协作运维
已经过去的2016年被称为VR元年、intelligence元年，其实也是IT运维的元年，国内协作运维服务已经热起来，专业的人干专业的事儿，也许这样的第三方运维引入可以解决上面的问题，协作运维的好处不用过多说明，即可节约成本，又能找到专业的人做专业的事情，用户和厂商只需要关注自身业务，而不需要过多的参与到细节的运维工作中。
很多企业已经先行尝到了这种你好，我好，他也好的甜头。
工具化运维
所谓工欲善其事必先利其器，各行各业都一样，一款合手适用的工具帮助提高效率，节约成本，在专业领域运维中尤为突出。以我们的”SQL专家云“来说，数十位资深SQL Server领域专家根据自身运维技术经验，打造出的SQL Server体检、诊断、监控一体化平台，用专业与专注解放IT运维人。
小感悟
运维三步走:
发现问题
解决问题
预防问题
亲身处理了上百家客户的系统，大部分系统数据库都存在着各种数据库问题，而数据库问题往往被忽视，直接被归结为软件的问题，厂商的问题！
数据库应该被我们重视起来，很多时候只是在数据库上做一些常规的配置或简单的优化，就能让系统有几倍甚至几十倍的提升，而这些优化可能只是简简单单的数据库层面完全不用改代码的行为！
系统运维需要定期体检，这点真心希望运维人员能够重视起来，也真心希望系统运维人员可以加深一下对数据库的了解，多掌握一些常规的手段和必要的运维策略。
北京格瑞趋势科技有限公司是聚焦于数据服务的高新技术企业，成立于2008年，创始团队及核心技术人员来自微软和雅虎。微软数据平台金牌合作伙伴，卫宁健康数据平台战略合作伙伴。通过产品+服务双轮驱动的业务模式，14年间累计服务4000+客户，覆盖互联网、市政、交通、电信、医疗、教育、电力、制造业等各个领域。
