这个月一直在构思一篇和技术关联不太多的文章,导致了我临近月底,才发现自己完成的文章是0,恰好最近在给朋友传授一些转行dba的讲一下我自己的经验之谈,正好拿过来用一下。这些是同行们总结出来的经验,也有一些是我自己的切身体会,希望对你有所帮助。
总则
- 备份。永远不要让你的生产库处于没有备份无法恢复的状态,在资源允许的情况下,确保你的备份集时间戳是连续的。只有这样才能让你在最坏的情况下仍然有机会重来。
- 冗余。备份仅仅是提供了最后一道防线,但是仍然需要对重要的生产库提供冗余,既有实例级别的冗余,又包括了数据级别的冗余。
用户管理
- 密码复杂度。超级管理员的密码,永远不要敷衍了事,要确保长度、大小写数字字符组合,生产环境最好是12位起步。并且除非有正规流程,不要交给别人,哪怕是你的直属领导。
- 最小权限分配。给你的每一个非管理账号分配它完成正常业务的最小权限,而不要给任何冗余权限,因为你永远无法判断,这个账号会被拿来做什么匪夷所思的事情。
- 权责分离。不要用个人用户登录管理,也不要给个人用户分配管理员权限,而是用专门的管理用户,这之间可以使用各类安全策略例如跳板机或者其他方式实现鉴权。
- 定期演练。无论是备份恢复还是灾备演练,都要定期做,少则一个季度,多则一年。否则真到了需要使用这些手段的时候,会出现很多你没有预判到的问题。
- 及时下线。已经不再使用的数据库账号及时锁定并排期删除,不要一直以开放状态允许访问数据库。
- 业务分离。不同的业务系统,绝对不允许使用同一个账号,即便是两个业务系统是同一个部门同一批人在使用。
监控管理
- 无监控不上线。所有在生产上线的数据库,一定要有监控,确保随时掌握每个生产环境的数据库状态,以便于未来的排查以及追踪,甚至关系到权责纠纷。
- 动态调整。监控指标不是一成不变的,需要在未来长年的运维中不断动态调整,以适应自己的运维团队配置以及业务要求。
- 防患于未然。无论你作为dba,处理各类问题有多及时多专业,都不如从不让数据库出问题来得好。疾在腠理才是治疗的最佳时机,而不要等到滚出个大雪球。
访问安全
- 环境隔离。生产库和测试库严格地隔离开,不仅仅是账号和服务器,甚至连网络防火墙以及账号都要严格隔离好。
- 跨库访问控制。尽量避免直接数据库层面的跨库访问,例如dblink,而是用api等其他方式,对数据库的安全隐患也更低。
- 审计。对于重要的业务系统,要确保有足够的审计手段,让你知道谁在什么时候登录了数据库做了什么事情。
成本管理
- 有限分配。对于一些重要度很低并且业务量又不大的系统,如果没有专门的预算,分配有限的资源,算力、内存、存储够用即可。
- 利用好冗余资源。备库的冗余资源,可以用来做其他业务,例如只读的standy用来做报表,灾备中心的服务器可以把一些边缘服务也部署上。
- 冷热数据分离。冷数据使用成本更低的存储来保存,高性能存储用于存放热数据,当然伴随着ssd价格不断走低,这个以后可能不再适用。
- 做好利旧。生产环境淘汰的设备,在符合公司流程和标准的情况下,可以继续用于测试,
流程管理
- 无工单不变更。所有对生产环境配置、账号、启停都需要工单,即便是事出紧急也一定要事故之后尽早补一个。
- 标准化部署。新环境的部署,可以是手动也可以自动,无论哪种,都要做成标准,并且落诸文档,不但降低了以后的部署风险和成本,也可以便于交接。
- 事故报告。每一次生产环境的事故,务必写一份报告,将来龙去脉交代清楚,附上日志,并且将解决办法描述到尽量详尽。
「喜欢这篇文章,您的关注和赞赏是给作者最好的鼓励」
关注作者
【米乐app官网下载的版权声明】本文为墨天轮用户原创内容,转载时必须标注文章的来源(墨天轮),文章链接,文章作者等基本信息,否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容,欢迎发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。