写在前面

　　上一篇我主要分享了架构的一些选型之法，架构之路不是简单的技术，而是多方的协调，业务的理解、技术的沉淀、经验。

　　架构文章链接：如何规划、建设你的数据库架构

　　架构涉及系统的安全、连续、高效状态，一般来说仍然需要很专业的架构规划人介入，另外除了架构层面数据库的管理也是非常重要的一部分，那么我们今天来聊聊数据库的管理。

　　本文也是精炼多次在各行业演讲的内容，分享给博友！

普遍的问题

　　博主就职于一家专注数据库产品及服务的公司，见过上千家的客户场景，和各行业的人、系统打过交道，那么我们来看看普遍遇到的问题。

为什么会这样？

　　我认为造成现在数据库问题频发的原因有 4 点：

• 传统的IT建设方式、管理方式导致了今天的问题

　　　　传统的建设方式：一大堆厂商的产品简单堆叠、松散拼凑。
　　　　传统的管理方式：用户的运维人员+一大堆厂商。

• 缺乏专业规划的IT架构，缺乏稳定性，增加管理复杂性

　　　　架构缺乏规划和合理化设计，借助一大堆厂商提供的分散的单机、双机、备份一体机、虚拟化、超融合等技术的简单堆叠，参见 ：如何规划、建设你的数据库架构

• 传统的数据库管理方式无法满足今天的业务要求

• 高速的业务增长导致数据平台面临巨大挑战　　

　　今天，业务高度依赖IT，IT的重要程度。。。
　　今天，IT系统的使用者、数据量的规模一直在快速增长，且体量空前的大；

愿景——大逻辑

　　说到数据库管理，有合理规划的架构必然是前提，架构是基础，在稳定的基础上配备合理的管理手段，管理制度，在上层要有及时的服务（很多企业没有DBA、没有懂得人也许这是最大的问题）

细化管理

　　架构层面不再赘述，如何可视化管理？ 如何制定管理制度？如何快速准确消灭问题？如何轻松、简单？

　　工具篇

　　首先普遍缺乏DBA的企业中是否可以找到一个称手的工具，正所谓 "武林至尊，宝刀屠龙，号令天下，莫敢不从，倚天不出，谁与争锋"

　　称手的工具产品对于管理数据库更为重要，对于武林高手（资深DBA）工具能起到的作用——方便，对于非专业数据库人员起到的左右——一个DBA小秘书

　　那么现在的数据库称手兵器应该做到什么？？ （个人觉得至少要下述内容）

1. 统一管理，统一呈现
2. 实时知道复杂的数据库运行状态，运行了哪些语句，运行的怎么样？
3. 告警，问题及时自动报告
4. 知道过去发生了什么，就像“摄像头” 记录分分秒秒，记录案发现场
5. 指标全面，支撑解决问题，可以应对数据库的复杂场景，生僻问题
6. 智能化，自动化巡检，一键发现潜在隐患
7. 智能化，解决问题（性能、日常运维）

　　这样的工具也许就是知道数据库的“昨天、今天、明天”，也就是“过去、现在和将来”

　　　当然，现在的运维管理工具产品越来越强大，强大到甚至让我这10年的老司机都感觉到要被取代，往往非专业的DBA缺少的是：

1. 解决问题所需要的数据支撑
2. 分析问题的逻辑
3. 解决问题的手段

　　那相应的工具产品中也要做到数据指标全面，而且对分析问题的流程和逻辑做到只需 “按步骤点击” ，比如突然一个时间点系统慢了，要帮助管理人员清晰的展示出分析问题的逻辑！

　　也许这就是所谓的 “工欲善其事，必先利其器”

　　管理篇

　　除了称手的工具外，标准化管理流程也是必要的，再牛逼得工具不用也是白扯，博主之前做DBA的时候的管理流程分享给大家，很多人也问DBA都要做些什么，统一回答：

• 　　日常巡检，保证系统稳定（DBA最重要的工作），经常会有客户的数据库，备份策略错误，作业失败，磁盘空间爆满等等一系列的基本问题，这些都应该通过日常巡检处理

　　　　　　注：不是流于表面CPU、IO、内存，而要深入数据库各项指标，并生成报告，汇报

　　　　　　周期：每周/每月

• 　　新上线系统/功能的评估，现在的企业系统中经常会有新接口的上线，这些功能是否会对原有系统造成性能影响？

　　　　　　注：企业对新功能的上线过程要严格把控，严格控制风险，往往问题都是日积月累不重视而产生的

　　　　　　周期：每次

• 　　日常性能优化，数据库是动态的过程，需要不断的优化，而不是一次优化以后就没问题了，买车还需要定期保养吧！
• 　    应急问题处理，突发问题是避免不了的，但是要做到少突发，提前消灭（这也是巡检的左右），突发问题一旦产品，数据记录、问题日志就是必要的，快速处理问题、减少损失是必须的
• 协作（开发部门、软件厂商、集成商）处理各种花式问题

　　专业服务篇

　　数据库是整个IT系统的最底层，而漏斗形的IT结构让数据库成为整个IT的瓶颈，在没有DBA的企业中对数据库的管理更为重要，常见的管理一般只有定期的巡检，软件厂商、集成商等等，而且是简单的巡检，这样对隐患的排查极其弱，无法起到该有的效果，而在数据库的专业服务中，博主认为应该做到下述方面：

1. 　　定期的深度、有效巡检
2. 　　通过专业管理工具产品让多人协作、及时分析、高效解决
3. 　　对多系统趋势分析，何时瓶颈
4. 　　根据压力、业务如何系统的整合、拆分，对基础架构进行不断升级
5. 在问题发生前解决而非在发生时救火

　　服务中也许只有三点：及时、专业、懂得客户

总结

　　大多数企业存在这样的问题：我们没DBA，我们只对业务精通，对程序了解，但数据库我只懂一点

　　数据库指标多而杂，出现问题不知道怎么排查

　　因为错过问题出现的时间点，问题原因无法得知，问题无法解决

　　长期“头疼医头”的“救火”运维留下了病根

　　巡检？啥是巡检？根本没做过

　　总来说，数据库管理要有明确的规划，如何构建平稳的架构，如何有一套轻松、简单的管理方法，如何借助专业的工具、公司或人来管理。

　　也许很简单

　　早发现早治疗——预防机制

　　当场发现及时治疗——实时机制

　　彻底治疗而非缓解——全面、重视

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

原文地址: http://www.cnblogs.com/double-K/

如有转载请保留原文地址! 

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

注：此文章为原创，欢迎转载，请在文章页面明显位置给出此文链接！
若您觉得这篇文章还不错请点击下右下角的推荐，非常感谢！