做物流网站有哪些内容,中国联通 网站备案,安徽省建设工程招标网官网,企业建站公司实力对比从自动化到智能化运维过渡时#xff0c;美团DBA团队进行了哪些思考、探索与实践#xff1f;本文根据赵应钢在“第九届中国数据库技术大会”上的演讲内容整理而成#xff0c;部分内容有更新。 背景 近些年#xff0c;传统的数据库运维方式已经越来越难于满足业务方对数据库的… 从自动化到智能化运维过渡时美团DBA团队进行了哪些思考、探索与实践本文根据赵应钢在“第九届中国数据库技术大会”上的演讲内容整理而成部分内容有更新。 背景 近些年传统的数据库运维方式已经越来越难于满足业务方对数据库的稳定性、可用性、灵活性的要求。随着数据库规模急速扩大各种NewSQL系统上线使用运维逐渐跟不上业务发展各种矛盾暴露的更加明显。在业务的驱动下美团点评DBA团队经历了从“人肉”运维到工具化、产品化、自助化、自动化的转型之旅也开始了智能运维在数据库领域的思考和实践。 本文将介绍美团点评整个数据库平台的演进历史以及我们当前的情况和面临的一些挑战最后分享一下我们从自动化到智能化运维过渡时所进行的思考、探索与实践。 数据库平台的演变 我们数据库平台的演进大概经历了五个大的阶段 第一个是脚本化阶段这个阶段我们人少集群少服务流量也比较小脚本化的模式足以支撑整个服务。 第二个是工具化阶段我们把一些脚本包装成工具围绕CMDB管理资产和服务并完善了监控系统。这时我们的工具箱也逐渐丰富起来包括DDL变更工具、SQL Review工具、慢查询采集分析工具和备份闪回工具等等。 第三个是产品化阶段工具化阶段可能还是单个的工具但是在完成一些复杂操作时就需要把这些工具组装起来形成一个产品。当然并不是说这个产品一定要做成Web系统的形式而是工具组装起来形成一套流程之后就可以保证所有DBA的操作行为对流程的理解以及对线上的影响都是一致的。我们会在易用性和安全性层面不断进行打磨。而工具产品化的主要受益者是DBA其定位是提升运维服务的效率减少事故的发生并方便进行快速统一的迭代。 第四个是打造私有云平台阶段随着美团点评业务的高速发展仅靠十几、二十个DBA越来越难以满足业务发展的需要。所以我们就把某些日常操作开放授权让开发人员自助去做将DBA从繁琐的操作中解放出来。当时整个平台每天执行300多次改表操作自助查询超过1万次自助申请账号、授权并调整监控自助定义敏感数据并授权给业务方管理员自助审批和管理自定义业务的高峰和低峰时间段等等自助下载、查询日志等等。 第五个是自动化阶段对这个阶段的理解其实是“仁者见仁智者见智”。大多数人理解的自动化只是通过Web平台来执行某些操作但我们认为这只是半自动化所谓的自动化应该是完全不需要人参与。目前我们很多操作都还处于半自动化阶段下一个阶段我们需要从半自动过渡到全自动。以MySQL系统为例从运维角度看包括主从的高可用、服务过载的自我保护、容量自动诊断与评估以及集群的自动扩缩容等等。 现状和面临的挑战 下图是我们平台的现状以关系数据库RDS平台为例其中集成了很多管理的功能例如主从的高可用、MGW的管理、DNS的变更、备份系统、升级流程、流量分配和切换系统、账号管理、数据归档、服务与资产的流转系统等等。 而且我们按照逻辑对平台设计进行了划分例如以用户维度划分的RDS自助平台DBA管理平台和测试环境管理平台以功能维度划分的运维、运营和监控以存储类型为维度划分的关系型数据库MySQL、分布式KV缓存、分布式KV存储以及正在建设中的NewSQL数据库平台等等。未来我们希望打造成“MySQLNoSQLNewSQL存储缓存的一站式服务平台”。 挑战一RootCause定位难 即便我们打造了一个很强大的平台但还是发现有很多问题难以搞定。第一个就是故障定位如果是简单的故障我们有类似天网、雷达这样的系统去发现和定位。但是如果故障发生在数据库内部那就需要专业的数据库知识去定位和查明到底是什么原因导致了故障。 通常来讲故障的轨迹是一个链但也可能是一个“多米诺骨牌”的连环。可能因为一些原因导致SQL执行变慢引起连接数的增长进而导致业务超时而业务超时又会引发业务不断重试结果会产生更多的问题。当我们收到一个报警时可能已经过了30秒甚至更长时间DBA再去查看时已经错过了最佳的事故处理时机。所以我们要在故障发生之后制定一些应对策略例如快速切换主库、自动屏蔽下线问题从库等等。除此之外还有一个比较难的问题就是如何避免相似的故障再次出现。 挑战二人力和发展困境 第二个挑战是人力和发展的困境当服务流量成倍增长时其成本并不是以相同的速度对应增长的。当业务逻辑越来越复杂时每增加一块钱的营收其后面对应的数据库QPS可能是2倍甚至5倍业务逻辑越复杂服务支撑的难度越大。另外传统的关系型数据库在容量、延时、响应时间以及数据量等方面很容易达到瓶颈这就需要我们不断拆分集群同时开发诉求也多种多样当我们尝试使用平台化的思想去解决问题时还要充分思考如何满足研发人员多样化的需求。 人力困境这一问题从DBA的角度来说时间被严重的碎片化自身的成长就会遇到瓶颈比如经常会做一些枯燥的重复操作另外业务咨询量暴增尽管我们已经在尝试平台化的方法但是还是跟不上业务发展的速度。还有一个就是专业的DBA越来越匮乏越来越贵关键是根本招聘不到人手。 在这种背景下我们必须去思考如何突破困局如何朝着智能化转型传统运维苦在哪里智能化运维又能解决哪些问题 首先从故障产生的原因来说传统运维是故障触发而智能运维是隐患驱动。换句话来说智能运维不用报警通过看报表就能知道可能要出事了能够把故障消灭在“萌芽”阶段第二传统运维是被动接受而智能运维是主动出击。但主动出击不一定是通过DBA去做可能是系统或者机器人操作第三传统运维是由DBA发起和解决的而智能运维是系统发起、RD自助第四传统运维属于“人肉救火”而智能运维属于“智能决策执行”最后一点传统运维需要DBA亲临事故现场而智能运维DBA只需要“隐身幕后”。 从自动化到智能化 那么如何从半自动化过渡到自动化进而发展到智能化运维呢在这个过程中我们会面临哪些痛点呢? 我们的目标是为整个公司的业务系统提供高效、稳定、快速的存储服务这也是DBA存在的价值。业务并不关心后面是MySQL还是NoSQL只关心数据是否没丢服务是否可用出了问题之后多长时间能够恢复等等。所以我们尽可能做到把这些东西对开发人员透明化提供稳定高效快速的服务。而站在公司的角度就是在有限的资源下提升效率降低成本尽可能长远地解决问题。 上图是传统运维和智能运维的特点分析左边属于传统运维右边属于智能运维。传统运维在采集这一块做的不够所以它没有太多的数据可供参考其分析和预警能力是比较弱的。而智能运维刚好是反过来重采集很多功夫都在平时做了包括分析、预警和执行智能分析并推送关键报表。 而我们的目标是让智能运维中的“报警分析执行”的比重占据的越来越少。 决策执行如何去做呢我们都知道预警重要但不紧急但报警是紧急且重要的如果你不能够及时去处理的话事态可能会扩大甚至会给公司带来直接的经济损失。 预警通常代表我们已经定位了一个问题它的决策思路是非常清晰的可以使用基于规则或AI的方式去解决相对难度更小一些。而报警依赖于现场的链路分析变量多、路径长所以决策难间接导致任何决策的风险可能都变大。所以说我们的策略就是全面的采集数据然后增多预警率先实现预警发现和处理的智能化。就像我们既有步枪也有手枪和刺刀能远距离解决敌人的就尽量不要短兵相接、肉搏上阵。 数据采集从数据库角度来说我们产生的数据分成四块Global Status、VariableProcesslist、InnoDB StatusSlow、Error、General Log和Binlog从应用侧来说包含端到端成功率、响应时间95线、99线、错误日志和吞吐量从系统层面支持秒级采样、操作系统各项指标从变更侧来看包含集群拓扑调整、在线DDL、DML变更、DB平台操作日志和应用端发布记录等等。 数据分析首先是围绕集群分析接着是实例、库最后是表其中每个对象都可以在多项指标上同比和环比具体对比项可参考上图。 通过上面的步骤我们基本可以获得数据库的画像并且帮助我们从整体上做资源规划和服务治理。例如有些集群实例数特别多且有继续增加的趋势那么服务器需要scale up读增加迅猛读写比变大那么应考虑存储KV化利用率和分布情况会影响到服务器采购和预算制定哪几类报警最多就专项治理各个击破。 从局部来说我们根据分析到的一些数据可以做一个集群的健康体检例如数据库的某些指标是否超标、如何做调整等等。 数据库预警通过分析去发现隐患把报警转化为预警。上图是我们实际情况下的报警统计分析结果其中主从延迟占比最大。假设load.1minPerCPU比较高我们怎么去解决那么可能需要采购CPU单核性能更高的机器而不是采用更多的核心。再比如说磁盘空间当我们发现3T的磁盘空间普遍不够时我们下次可以采购6T或更大空间的磁盘。 针对空间预警问题什么时候需要拆分集群MySQL数据库里拆分或迁移数据库花费的时间可能会很久。所以需要评估当前集群按目前的增长速度还能支撑多长时间进而反推何时要开始拆分、扩容等操作。 针对慢查询的预警问题我们会统计红黑榜上图是统计数据也有利用率和出轨率的数据。假设这是一个金融事业群的数据库假设有业务需要访问且是直连那么这时就会产生几个问题第一个有没有数据所有者的授权第二个如果不通过服务化方式或者接口发生故障时它可能会导致整个金融的数据库挂如何进行降级所以我们会去统计出轨率跟慢查询如果某数据库正被以一种非法的方式访问那么我们就会扫描出来再去进行服务治理。 从运维的层面来说我们做了故障快速转移包括自动生成配置文件自动判断是否启用监控切换后自动重写配置以及从库可自动恢复上线等等。 报警自动处理目前来说大部分的处理工作还是基于规则在大背景下拟定规则触发之后按照满足的前提条件触发动作随着库的规则定义的逐渐完善和丰富可以逐步解决很多简单的问题这部分就不再需要人的参与。 展望 未来我们还会做一个故障诊断平台类似于“扁鹊”实现日志的采集、入库和分析同时提供接口供全链路的故障定位和分析、服务化治理。 展望智能运维应该是在自动化和智能化上交叠演进在ABCAI、Big Data、Cloud Computing三个方向上深入融合。在数据库领域NoSQL和SQL界限正变得模糊软硬结合、存储计算分离架构也被越来越多的应用智能运维正当其时我们也面临更多新的挑战。我们的目标是希望通过DB平台的不断建设加固平台能自己发现问题自动定位问题并智能的解决问题。 作者简介 应钢美团点评研究员数据库专家。曾就职于百度、新浪、去哪儿网等10年数据库自动化运维开发、数据库性能优化、大规模数据库集群技术保障和架构优化经验。精通主流的SQL与NoSQL系统现专注于公司业务在NewSQL领域的创新和落地。
