很早前就想写篇文章介绍一下互联网DBA需要干的一些事情，但苦于没有时间，忙于平台建设，最近，各个模块都初具规模，故有时间静下心来，介绍一下。
众所周知，互联网DBA与传统行业DBA有很大的不同，那就是管理的机器多，新技术更新快，面对的开发多、网络环境复杂、要求7*24待机；这样就导致互联网DBA的工作在传统DBA工作之上，增加了更多的复杂性，我们必须考虑如何大批量部署，如何集中化监控、如何解决单点故障而保障7*24，而为了做到这些，不是靠堆人力，我们必须有一个完整的平台作为支撑，那么数据库平台到底要建成什么样子呢？
1、强有力的监控系统（监+控）：
监控是我们的眼睛，我们不可能7*24个小时盯着我们的DB，所以，我们需要监控系统来帮我们盯着，一旦异常，监控不仅仅通知我们，而必须要有控制，例如：MySQL 从库宕机了我们通过监控自动让其下线；从库同步状态失效了，可以自动修复同步等；并且，随着机器的增加、实例daemon的增加，我们会发现我们的手机报警会急剧增加，为了我们自己晚上能睡一个安稳觉，我们怎么去降低我们的报警，例如：哪些该短信，哪些该邮件；所有机器的磁盘空间报警是否可以整合后在报呢？这就是我们监控系统必须考虑的，
2、自动审核系统：
开发很多，项目很多，但是开发的习惯都不一致，可能会导致我们审核表结构的时头都看大了，为了保证线上的统一，为了保证不被开发的神奇SQL搞伤，不被N多的项目审核压垮，我们必须有一个自动建表审核系统，我们定义一些规则，如：不能用预留字段、主键必须为INT，BIGINT等，然后开发填写准备上线的表结构，通过系统自动审核，审核通过的，自动上线，审核不通过的，给出建议；
3、慢日志分析系统：
随着自动审核系统的上线，我们可能会漏掉一些索引使用不太好的SQL，那么我们就需要慢日志分系统帮助我们，在设计该系统时候，我们需要考虑是实时抓取慢日志，还是每天定期推送慢日志、慢日志抓取后是立即推送给开发还是自动分析完以后给出建议给开发、慢日志还要考虑一些SQL是否需要过滤，因为他可能是每天的统计，当然这些都是自动的，设计完后，不需要人工介入；
4、统计系统：
我们必须清晰的知道线上DB的整体运行情况，访问量的变化、写入量的变化、图是死的，他不会欺骗任何人；我们能通过访问统计知道是否有恶意访问、是否需要优化，是否需要增加节点抗住更大的压力；
5、备份系统：
不管你信不信，我是信了，冷备份总是我们的救命草，不管我们做的多么好，故障总会有，drop database也会发生，所以，一个完整的备份系统，势在必行，我们的备份是否正常，备份的数据是否能恢复，恢复需要多少时间，都是我们备份系统需要考虑的；
6、管理系统：
我们机器少则上百台，多则可能好几千，如何清晰知道每台机器跑了多少daemon，DB Proxy下面有哪些机器，如何能对主库机器、从库机器进行脚本分别分发等；都需要管理系统来帮我们完成；
7、中间层：
是把双刃剑，他能给我们带来好的扩展，例如：动态添加从库、主库失效检测等；但是他带来了DBA管理的复杂性、带来了更多的故障点、带来了更多的bug、如果DB Proxy性能不好的话，那就更糟了，并且为了解决client透明，我们必须考虑很多，例如：连接保持，如：字符集、last_insert_id、use dbname等；如果我们有人力开发维护，那么我相信Proxy会带给我们欢乐；
以上各个系统都是为我们管理DB提供支持，如果没有这些系统支持，那么数据库管理就谈不上平台，谈不上批量管理，谈不上承载百亿访问量，百T数据量的数据库；当然在涉及这样的系统时候，我们也要考虑新技术的引进，例如：如果能快速的打造NoSQL 平台等；当然在部署这些模块的时候，我们时时刻刻记得，所有的模块都是会变的，我们需要不停的学习，不停的改进，才会打造宕机时间更低的数据库服务。
后续会慢慢分享出，我们这些模块是如何做的，及其进度如何。
