文章经授权转自简书作者：董泽润

一、前言

2012年初入职赶集，当时处在流量讯猛增长的阶段，3年 DBA 生涯收获坡多，其实坑更多(泪… ) 后来在做开发时，慢慢体会到 ”运维“ 和 “开发” 确实存在沟通问题：知识不对称

如何解决呢？先总结下这三年吧

二、DBA职责

市面上招聘 JD 一大堆，随变找几个，马上能找出共性

  • 数据库系统的规划、设计、管理、迁移

  • 数据库的日常维护、备份、优化及恢复

  • Master-Slave架构搭建、维护

  • 业务系统上线支持，数据库设计评审，提供架构方案

数据库不局限于 MySQL、Oracle，如果分的不细，还会有 Redis、 MongoDB 等一系列 NoSQL。

工作内容都一样，首先是高可用稳定性，不能今天抖动明天宕机，涉及工作很多。

第二个是数据安全，比如备份及恢复，14年赶集审计，移动端的活跃用户数就是从备份中恢复来的，可见备份的有效性是重中之重。

最后一个当然是为业务服务，对接业务需求，不能因个人生活被打断就罢工，有一次刚看电影就被叫回去处理 DB 报警，骂娘的心都有了。

三、悲惨案例

先举一些悲惨案例，让看官们高兴一下~ 由于公司早就不在了，这里没有顾忌。

1. delete 删全表

二手车同学的锅，SQL 拼错不带 where 条件，编写线下脚本时出错… 最后DBA根据 row binlog 恢复。（至少2次）

反思：rd 新手一茬又一茬，规范讲再多也没用。最彻底的解决方式只有一个，接入 proxy, 限制一切非法 sql。另外 rd 上线验证也不到位，代码 review 肯定有缺失。

2. 大卖家问题

房产在14年开通免费端口，短短几个月时间房产商业表爆涨到 100G，个别中介帐号发贴超过10W，导致数据库异常抖动，威哥临时清理过多发贴记录解决。最后耗时三个月对这张表进行瘦身，拆分 text 字段。

反思：DBA 对大表监控不足

3. 大量子查询打跨主库

主站主库有一次被子查询打跨，事后排查，由于 RD 大量子查询导致。此类问题不是个案，有很多 RD 把本本该读 slave 的请求写到 master 上，只不过没有引起事故而已

反思：赶集 DB 典型 1 主 N 从，没有 proxy 保护的怀况下，经常出现此类问题，只靠规范制度基本解决不了。

4. 报表 olap 库问题

RP 库我和文武背锅，年底的绩效垫底。文武接手前的 RD 一个人开发中介商家报表系统，所有计算都是基于 DB，当免费端口开放后数据量爆涨，MyISAM 读写锁导致大量请求阻塞，听说公司因为报表连续问题赔商家300W。

反思：这个事故得站在高处去看，免费端口开放太突然，项目技术负责人考滤不全。报表系统没有经过设计，完全由一个新人 RD 去搞，也就大学毕生水平，回头再看，hadoop spark 完全搞定。最后 DBA 没有及时对大表进行跟踪，没有提前发现。

5. 50G的Redis

房产业务 Redis 眼看从 20G 爆涨到 50G，我离开后也一直没优化掉。听说，后来某次故障，数据清空了？

四、我的工作

大部份时间和开发沟通感情聊人生，后来 automan 上线很少有人找我了~ 每个阶段都有成长，都有感谢的人和事，赶集让我有平台去做感兴趣的事，很开心。

刚到赶集时，SQL 上线还走的 jira，半自动化由运维开发同学做的，经常在技术大群里被艾特，很简单的建表或是 DML 都要由 DBA 人工介入，很烦索。

另外很多建表语句不规范，打回让 RD 修改，他们对此很有意见，认为无所谓的修改，这就在 RD 和 DBA 之间产生了沟通成本，诗展在的时候还会定期做数据库开发培训，然后就没有然后了。

14年中着手 automan 平台开发，从前台页面到后端消息队列，到 sql parser 解析，从无到有，在刘军先河同学的帮助下最终上线完成。由平台去审核开发的 SQL，经过 sim 模拟环境，再到线上自动执行备份，比人工高效的多。

这个系统原理和市面上其它工具差不多，仍有很大改进的地方。后来在数据库大会分享了一次，诚惶诚恐没有被喷。

五、DBA心得

  • 夯实基础：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 更精，才能做好运维。

六、运维与RD的矛与盾

KPI 不同，关注点自然也不同，一线的同学经验也都有欠缺，特别是刚工作1~2年的，造成了信息与知识的不对称。解决这个问题也不难：

  • 新人要有导师带，对新人放手不管最不负责。这方面感觉 nice 做的不错。该夸还是要夸的。

  • 支撑团队要有足够的 wiki 业务文档说明。

  • 自动化用技术来约束，而不是人工。同比业务接口强约束，现在服务化都用 thrift 了。