美团 DBA 团队数据库智能运维探索与实践.docxVIP

美团 DBA 团队数据库智能运维探究与实践 2021-02-10 背景 近些年，传统的数据库运维方式已经越来越难于满足业务方对数据库的稳定性、可用性、机警性的要求。随着数据库规模急速扩大，各种 NewSQL 系统上线使用，运维渐渐跟不上业务进展，各种冲突暴露的愈加明显。在业务的驱动下，美团点评 DBA 团队经受了从“人肉”运维到工具化、产品化、自助化、自动化的转型之旅，也开头了智能运维在数据库领域的思考和实践。 本文将引见美团点评整个数据库平台的演进历史，以及我们当前的情况和面临的一些挑战，最终共享一下我们从自动化到智能化运维过渡时，所进行的思考、探究与实践。 数据库平台的演化 我们数据库平台的演进或许经受了五个大的阶段： 第一个是脚本化阶段，这个阶段，我们人少，集群少，服务流量也比较小，脚本化的模式足以支撑整个服务。 其次个是工具化阶段，我们把一些脚本包装成工具，围绕 CMDB 管理资产和服务，并完善了监控系统。这时，我们的工具箱也渐渐丰富起来，包括 DDL 变更工具、SQL Review 工具、慢查询采集分析工具和备份闪回工具等等。 第三个是产品化阶段，工具化阶段可能还是单个的工具，但是在完成一些简单操作时，就需要把这些工具组装起来构成一个产品。当然，并不是说这个产品肯定要做成 Web 系统的方式，而是工具组装起来构成一套流程之后，就可以保证全部 DBA 的操作行为，对流程的理解以及对线上的影响都是全都的。我们会在易用性和平安性层面不断进行打磨。而工具产品化的次要受益者是 DBA，其定位是提升运维服务的效率，削减事故的发生，并便利进行快速统一的迭代。 第四个是打造私有云平台阶段，随着美团点评业务的高速进展，仅靠十几、二十个 DBA 越来越难以满足业务进展的需要。所以我们就把某些日常操作开放授权，让开发人员自助去做，将 DBA 从繁琐的操作中解放出来。当时整个平台每天执行 300 多次改表操作；自助查询超过 1 万次；自助申请账号、授权并调整监控；自助定义敏感数据并授权给业务方管理员自助审批和管理；自定义业务的高峰和低峰时间段等等；自助下载、查询日志等等。 第五个是自动化阶段，对这个阶段的理解，其实是“仁者见仁，智者见智”。大多数人理解的自动化，只是通过 Web 平台来执行某些操作，但我们认为这只是半自动化，所谓的自动化应当是完全不需要人参与。目前，我们很多操作都还处于半自动化阶段，下一个阶段我们需要从半自动过渡到全自动。以 MySQL 系统为例，从运维角度看包括主从的高可用、服务过载的自我爱护、容量自动诊断与评估以及集群的自动扩缩容等等。 现状和面临的挑战 下图是我们平台的现状，以关系数据库 RDS 平台为例，其中集成了很多管理的功能，例如主从的高可用、MGW 的管理、DNS 的变更、备份系统、升级流程、流量安排和切换系统、账号管理、数据归档、服务与资产的流转系统等等。 而且我们依据规律对平台设计进行了划分，例如以用户维度划分的 RDS 自助平台，DBA 管理平台和测试环境管理平台；以功能维度划分的运维、运营和监控；以存储类型为维度划分的关系型数据库 MySQL、分布式 KV 缓存、分布式 KV 存储，以及正在建设中的 NewSQL 数据库平台等等。将来，我们期望打形成“MySQL+NoSQL+NewSQL，存储 + 缓存的一站式服务平台”。 挑战一：RootCause 定位难 即便我们打造了一个很强大的平台，但还是发觉有很多问题难以搞定。第一个就是毛病定位，假如是简约的毛病，我们有类似天网、雷达这样的系统去发觉和定位。但是假如毛病发生在数据库内部，那就需要专业的数据库学问，去定位和查明到底是什么缘由导致了毛病。 通常来讲，毛病的轨迹是一个链，但也可能是一个“多米诺骨牌”的连环。可能由于一些缘由导致 SQL 执行变慢，引起连接数的增长，进而导致业务超时，而业务超时又会引发业务不断重试，结果会产生更多的问题。当我们收到一个报警时，可能已经过了 30 秒甚至更长时间，DBA 再去查看时，已经错过了最佳的事故处理时机。所以，我们要在毛病发生之后，制定一些应对策略，例如快速切换主库、自动屏蔽下线问题从库等等。除此之外，还有一个比较难的问题，就是如何避开相像的毛病再次消灭。 挑战二：人力和进展顺境 其次个挑战是人力和进展的顺境，当服务流量成倍增长时，其成本并不是以相同的速度对应增长的。当业务规律越来越简单时，每添加一块钱的营收，其后面对应的数据库 QPS 可能是 2 倍甚至 5 倍，业务规律越简单，服务支撑的难度越大。另外，传统的关系型数据库在容量、延时、响应时间以及数据量等方面很简约达到瓶颈，这就需要我们不断拆分集群，同时开发诉求也多种多样，当我们尝试使用平台化的思想去处理问题时，还要充分思考如何满足研发人员多样化的