文章经受权转自简书做者：董泽润sql
2012年初入职赶集，当时处在流量讯猛增加的阶段，3年 DBA 生涯收获坡多，其实坑更多(泪… ) 后来在作开发时，慢慢体会到 ”运维“ 和 “开发” 确实存在沟通问题：知识不对称数据库
如何解决呢？先总结下这三年吧后端
市面上招聘 JD 一大堆，随变找几个，立刻能找出共性安全
数据库系统的规划、设计、管理、迁移架构
数据库的平常维护、备份、优化及恢复app
Master-Slave架构搭建、维护运维
业务系统上线支持，数据库设计评审，提供架构方案异步
数据库不局限于 MySQL、Oracle，若是分的不细，还会有 Redis、 MongoDB 等一系列 NoSQL。数据库设计
工做内容都同样，首先是高可用稳定性，不能今天抖动明天宕机，涉及工做不少。ide
第二个是数据安全，好比备份及恢复，14年赶集审计，移动端的活跃用户数就是从备份中恢复来的，可见备份的有效性是重中之重。
最后一个固然是为业务服务，对接业务需求，不能因我的生活被打断就罢工，有一次刚看电影就被叫回去处理 DB 报警，骂娘的心都有了。
先举一些悲惨案例，让看官们高兴一下~ 因为公司早就不在了，这里没有顾忌。
二手车同窗的锅，SQL 拼错不带 where 条件，编写线下脚本时出错… 最后DBA根据 row binlog 恢复。（至少2次）
反思：rd 新手一茬又一茬，规范讲再多也没用。最完全的解决方式只有一个，接入 proxy, 限制一切非法 sql。另外 rd 上线验证也不到位，代码 review 确定有缺失。
房产在14年开通免费端口，短短几个月时间房产商业表爆涨到 100G，个别中介账号发贴超过10W，致使数据库异常抖动，威哥临时清理过多发贴记录解决。最后耗时三个月对这张表进行瘦身，拆分 text 字段。
反思：DBA 对大表监控不足
主站主库有一次被子查询打跨，过后排查，因为 RD 大量子查询致使。此类问题不是个案，有不少 RD 把本本该读 slave 的请求写到 master 上，只不过没有引发事故而已
反思：赶集 DB 典型 1 主 N 从，没有 proxy 保护的怀况下，常常出现此类问题，只靠规范制度基本解决不了。
RP 库我和文武背锅，年末的绩效垫底。文武接手前的 RD 一我的开发中介商家报表系统，全部计算都是基于 DB，当免费端口开放后数据量爆涨，MyISAM 读写锁致使大量请求阻塞，据说公司由于报表连续问题赔商家300W。
反思：这个事故得站在高处去看，免费端口开放太忽然，项目技术负责人考滤不全。报表系统没有通过设计，彻底由一个新人 RD 去搞，也就大学毕生水平，回头再看，hadoop spark 彻底搞定。最后 DBA 没有及时对大表进行跟踪，没有提早发现。
房产业务 Redis 眼看从 20G 爆涨到 50G，我离开后也一直没优化掉。据说，后来某次故障，数据清空了？
大部份时间和开发沟通感情聊人生，后来 automan 上线不多有人找我了~ 每一个阶段都有成长，都有感谢的人和事，赶集让我有平台去作感兴趣的事，很开心。
刚到赶集时，SQL 上线还走的 jira，半自动化由运维开发同窗作的，常常在技术大群里被艾特，很简单的建表或是 DML 都要由 DBA 人工介入，很烦索。
另外不少建表语句不规范，打回让 RD 修改，他们对此颇有意见，认为无所谓的修改，这就在 RD 和 DBA 之间产生了沟通成本，诗展在的时候还会按期作数据库开发培训，而后就没有而后了。
14年中着手 automan 平台开发，从前台页面到后端消息队列，到 sql parser 解析，从无到有，在刘军先河同窗的帮助下最终上线完成。由平台去审核开发的 SQL，通过 sim 模拟环境，再到线上自动执行备份，比人工高效的多。
这个系统原理和市面上其它工具差很少，仍有很大改进的地方。后来在数据库大会分享了一次，坐卧不安没有被喷。
夯实基础：DB 的基础天然是稳定，稳定，再稳定。实例数一多，基本天天都会遇到各类故障。主挂了就用 MHA 切换(最新的有 gtid)，slave 挂掉就由 lvs 自动摘掉读流量。还有一个就是备份，全量增量，按期备份有效性检测，每一块都须要人力的投入。
硬件优先：DB 扩容有 scale up 和 scale out 两种，通常优先堆硬件。buffer 不够加内存，128G 不够就 192G，磁盘阵列卡性能不行就上 SSD，再不行就上 flash 板卡。总之优先考滤硬件，争取架构优化的时间。
未雨绸缪：慢 SQL 优化，按期出报表让 RD 调优，通常出问题都是索引没加，99%的大 SQL 都是这样，少部份由于表设计不合理(没有自增主键，或是频烦修改)。大表监控，该瘦身的瘦身，字段该拆的拆，横竖两刀，过时数据按期归档，基本上就这些事。
结合业务：有些优化 DBA 累的半死，不如 RD 修改一行代码。DBA 也要多和业务接触，了解业务实现，不求给业务贡献多少，不背锅就好… 开玩笑。了解业务，就能站在更高的角度去思考，颇有意义。
学会拒绝：这个拒毫不是罢工不干活，而是要分清哪些需求的合理性与紧急性，不合理也不紧急的直接干掉，紧急但不合理的能够临时经过，快速解决问题，过后再确掉也能够。好比 olap 跑在了线上库，count(*) 计数 SQL 彻底能够异步走计数器，Redis 是好东西。
学会沟通：工做也有些年头了，这一点仍然在学习，也犯过很多错。沟通好权责，定下时间表。
踏实学习：回头看当年 DBA 作的不够好，有些缘由在于没有开发能力，不少想法止步于此。运维人员必定要有开发功力，而且要比业务 RD 更精，才能作好运维。
KPI 不一样，关注点天然也不一样，一线的同窗经验也都有欠缺，特别是刚工做1~2年的，形成了信息与知识的不对称。解决这个问题也不难：
新人要有导师带，对新人放手无论最不负责。这方面感受 nice 作的不错。该夸仍是要夸的。
支撑团队要有足够的 wiki 业务文档说明。
自动化用技术来约束，而不是人工。同比业务接口强约束，如今服务化都用 thrift 了。