上云之后 DBA 会原地失业？

上云之后 DBA 会原地失业吗？其实多数情况都不会，那上云后还有哪些事需要 DBA 去做的呢？这节内容就来扯一扯。

1 恢复演练

对于 MySQL 实例、单库、单表，定期进行恢复演练，现在很多云厂商的数据库服务虽然自带这些功能，但是根据以往的经验，第一次恢复多多少少还是会遇到一些问题的。

如果有开发能力，后续可以写成程序，通过程序调用云厂商接口的形式实现。

2 资源缩减

很多业务上线之后，往往达不到当时预估的峰值，我们可以做的就是对资源使用率进行评估，然后进行资源缩减，从而节约成本。

3 答疑

跟以前一样，DBA 工作的一部分就是答疑。比如：数据库默认存储引擎、隔离级别，实例对应的 QPS，当然这类重复性的问题可以整理成文档。

4 增加监控/告警处理

云厂商自带的监控不能适用于所有场景，所以我们总要增加一些特有的监控项，并及时处理告警。

5 Redis 大 key 分析

在之前的内容（Redis 运维实战 第06期：Bigkey），有聊到 Redis 大 key 分析，使用云 Redis 之后，也是要关注的，但是很多云厂商自带 Redis 大 key 分析结果，如果我们要按业务集中展示出来，可以通过调用云厂商的接口，获取大 key 分析结果，然后基于业务分组，并展示给研发。

6 数据库巡检

比如巡检 RDS、Redis 的付费方式，剩余时间，时区等。有异常发送给 DBA，防止出现线上数据库服务到期未续费或者时区不统一的低级错误。

7 评分系统

对于每个 RDS 或者 Redis 或者 MongoDB，形成一个评分，具体打分维度比如：Slow Log 条数、CPU 最大使用率、大表数量、表数量、磁盘使用率、连接数使用率、IOPS 使用率等。

8 迁移支持

有时需要从机房迁移到云上，或者在不同云厂商之间迁移。需要找到合适的数据迁移方案（很多云厂商都有 DTS，一般支持很多场景的数据迁移），并且参数要统一（比如时区、SQL Mode 等）。

9 资源申请/扩缩容

经常会遇到一些资源申请或者扩缩容的需求。可以在页面点，可以调云厂商的接口，也可以借助其他工具（比如 Terraform）。

10 分库分表支持

通常情况也是能不分就不分，如果业务实在有分库分表的需求，需要 DBA 配合他们做。

11 SQL 审核

很多云厂商都有自己的 SQL 审核产品，比如阿里云的 DMS，如果公司采购了，需要 DBA 熟悉他的使用，以方便日常的审核或者答疑。当然 DMS 不便宜，如果有条件，可以自行开发一个 SQL 审核工具。

12 SQL 优化

SQL 优化也是要继续做的事情，尽管有些云厂商自带慢查询优化建议，但是也要 DBA 去验证优化建议是否可行，并且需要跟进研发后续是否优化了。

13 架构设计

可以给业务一些架构设计上的建议（比如某项功能使用哪种数据库最好，当然，前提是我们要学习更多的数据库）。

14 开发规范

可以结合公司场景制定一个数据库开发规范，定好规范并真正实施之后，其实很多问题都可以避免的。

当然，可能还有很多其他的事情要做，总结的并不完整