转行DBA，给你分享数据库运维的N条建议（随时更新）

这个月一直在构思一篇和技术关联不太多的文章，导致了我临近月底，才发现自己完成的文章是0，恰好最近在给朋友传授一些转行DBA的讲一下我自己的经验之谈，正好拿过来用一下。这些是同行们总结出来的经验，也有一些是我自己的切身体会，希望对你有所帮助。

总则

1. 备份。永远不要让你的生产库处于没有备份无法恢复的状态，在资源允许的情况下，确保你的备份集时间戳是连续的。只有这样才能让你在最坏的情况下仍然有机会重来。
2. 冗余。备份仅仅是提供了最后一道防线，但是仍然需要对重要的生产库提供冗余，既有实例级别的冗余，又包括了数据级别的冗余。

用户管理

1. 密码复杂度。超级管理员的密码，永远不要敷衍了事，要确保长度、大小写数字字符组合，生产环境最好是12位起步。并且除非有正规流程，不要交给别人，哪怕是你的直属领导。
2. 最小权限分配。给你的每一个非管理账号分配它完成正常业务的最小权限，而不要给任何冗余权限，因为你永远无法判断，这个账号会被拿来做什么匪夷所思的事情。
3. 权责分离。不要用个人用户登录管理，也不要给个人用户分配管理员权限，而是用专门的管理用户，这之间可以使用各类安全策略例如跳板机或者其他方式实现鉴权。
4. 定期演练。无论是备份恢复还是灾备演练，都要定期做，少则一个季度，多则一年。否则真到了需要使用这些手段的时候，会出现很多你没有预判到的问题。
   
5. 及时下线。已经不再使用的数据库账号及时锁定并排期删除，不要一直以开放状态允许访问数据库。
6. 业务分离。不同的业务系统，绝对不允许使用同一个账号，即便是两个业务系统是同一个部门同一批人在使用。

监控管理

1. 无监控不上线。所有在生产上线的数据库，一定要有监控，确保随时掌握每个生产环境的数据库状态，以便于未来的排查以及追踪，甚至关系到权责纠纷。
2. 动态调整。监控指标不是一成不变的，需要在未来长年的运维中不断动态调整，以适应自己的运维团队配置以及业务要求。
3. 防患于未然。无论你作为DBA，处理各类问题有多及时多专业，都不如从不让数据库出问题来得好。疾在腠理才是治疗的最佳时机，而不要等到滚出个大雪球。

访问安全

1. 环境隔离。生产库和测试库严格地隔离开，不仅仅是账号和服务器，甚至连网络防火墙以及账号都要严格隔离好。
2. 跨库访问控制。尽量避免直接数据库层面的跨库访问，例如dblink，而是用API等其他方式，对数据库的安全隐患也更低。
3. 审计。对于重要的业务系统，要确保有足够的审计手段，让你知道谁在什么时候登录了数据库做了什么事情。

成本管理

1. 有限分配。对于一些重要度很低并且业务量又不大的系统，如果没有专门的预算，分配有限的资源，算力、内存、存储够用即可。
2. 利用好冗余资源。备库的冗余资源，可以用来做其他业务，例如只读的standy用来做报表，灾备中心的服务器可以把一些边缘服务也部署上。
3. 冷热数据分离。冷数据使用成本更低的存储来保存，高性能存储用于存放热数据，当然伴随着SSD价格不断走低，这个以后可能不再适用。
4. 做好利旧。生产环境淘汰的设备，在符合公司流程和标准的情况下，可以继续用于测试，

流程管理