随着业务场景的多元化，我们负责管理和维护的服务也越来越多，目前覆盖了当前大部分企业都会采用的标准数据库类型：MySQL、Redis、Tidb、ES、Mongodb等，同时集群规模也越来越大。在架构层面，作业帮已经基本完成了基于云原生的多云架构建设，我们为数据存储设计统一的Proxy层，将Proxy容器化，数据库层我们选择使用标准数据库版本自建，以此消除多云间的差异。各个数据库服务对应的Proxy，我们基本上是采用开源+自研的方案，其中我们DBA团队为Rediscluster自主研发并开源了一个名为"recuffer"的Proxy。它能够有效地管理和路由流量，提高可控性和易用性，有兴趣的同学可以关注下这个开源项目。为了提高效率和稳定性，团队耗费大量时间和精力打造了"journey"数据库智能运维平台，它基本覆盖了各个数据库类型的整个生命周期的各个活动。这使得我们能够更快速地响应需求，并确保服务的稳定运行。关于数据库智能运维，无论是对公司、团队还是个人，都非常有价值。提升DBA的工作效率，让DBA从大量的运维工作中解放出来，投入到技术的升级迭代中，从而实现良性循环，提升资源使用效率，缩减空闲资源，降低资源成本。设置安全检查机制，保障每一个运维动作是在合理的条件下进行。其次限制操作时间，避免高峰期执行具有风险的操作增加审核机制，做到多人check。设置告警规则，捕抓错误日志，链路探测，定期巡检，提前发现问题，提前预警，从而及时进行处理，避免故障发生。数据库版本、数据库架构、配置能够完成统一，避免个性化配置的服务出现。操作权限统一限制，避免过大权限的情况出现，规避安全风险。所有上下线操作均进行审核与留痕，让数据库服务整个运行期间都透明、可控。一个是要结合DBA的智慧，把DBA的经验总结和应用起来，包括对风险的判断，故障的处理流程，问题的定位策略，服务优化建议，开发规范，设计规则等等。第二个是丰富、全面的基础数据和实时的时序数据，包括服务器的资源信息，数据库服务的资源信息，实时使用情况，使用趋势，业务线等等，能够帮助我们对集群的具体情况进行分析。第三个算法模型设计，把DBA运维经验转化为适当的运维模型，比如部署集群如何选择服务器进行部署，DBA会考虑内存、磁盘、cpu的分配情况、已部署实例数量，主从数量，亲和度，超卖比例等的综合情况，将这个经验公式转化为资源自动分配的模型，从而完成资源智能分配这一功能。最后还需要的是，不断地迭代，打磨，在实践过程，很多功能在测试、上线、大量使用等不同情况会暴露不同的问题，根据实际的反馈进行优化和迭代，才能更好地完成智能化运维。整个智能运维平台划分为了五个层级，这五个层级分别是用户层、基础架构层、数据库服务层、中间件层以及工具层。
主要的就是权限控制，是通过角色给不同的用户分配不同的权限，将菜单、页面、按钮、接口等交互方式划分了不同的范围，每个用户只能看到自己角色限制的内容。是一些通用的模块，也是整个平台运行的基础，其中配置管理是各个功能模块所需要用的的一些参数变量，通过这个配置管理可以灵活地对一些功能进行实时地调整，日志功能是方便快速定位问题的关键，任务和工单以及Agent是完成数据库运维功能的关键，这个在后边章节再详细展开介绍，CMDB主要是进行服务器资源管理、数据库实例管理，与数据库服务关联紧密，资源的智能分配也包括在内，监控&告警模块将平台与监控系统关联起来的，从而实现监控告警上的交互，这个在后边监控系统部分具体展开。主要是对各个数据库类型的运维管理，每个数据库类型下都会有各自的一些运维服务，可以查看集群详细信息，进行主从切换、扩缩容操作，还可以变更数据库配置，查看实时连接，杀连接，还可以关联监控系统，查看数据库集群的监控大盘，查看告警配置策略，并可以进行变更，也可以配置备份的策略，对集群的备份进行调整，同时配置自助查询功能，方便业务对集群进行数据查询，也方便进行限制和审计，每个数据库类型会根据各自的运维特点在整体的架构规范下进行功能的设计，并且可以随着需求不断扩展和迭代。在数据库架构中Proxy都统一进行了容器化，所以平台为Proxy的管理添加了：Ø K8S集群管理，能够快速添加、删除指定云的K8S集群Ø 流量控制，能够将Proxy到数据库的流量进行控制，可以讲指定数据库服务进行摘流处理，当我们需要对某个数据库实例进行运维变更的时候，通常就会先进行摘流，降低影响为了数据库服务能力的扩展，平台还集成了一些工具类型的服务，包括DTS、数据校验、巡检服务、审核工具等比较独立的模块，这些模块基本上都是可以独立部署，并且不影响数据库服务本身的运行，但却会给业务、运维带来极大的便利。最开始做平台的时候是使用Django的ORM框架，框架本身在数据库平台建设上也是比较适合的，所以在重构的新平台上虽然使用了Go语言进行开发，但还是沿用ORM的框架。
最顶层的APP层把整个平台的主体进行了划分，包括数据库服务类型，CMDB，监控系统 ，任务系统，工单系统，都划分到单独的APP中。在APP内，链路层级分别是API-Controller-任务-工单，Controller完成主要的逻辑交互和数据变更，工单完成审核与管控，Task、Worker包括Manager-Agent都是任务体系的成员，在这把运维动作封装为任务，进行任务管理，以及任务的执行。工具类主要分为两种，一种是采集类，比如慢日志采集、大KEY采集、操作系统信息采集（区分于监控的数据采集），另一种是辅助服务类型的工具，比如SQL审核工具、DTS、数据校验工具、监控系统等等，这些工具通过接口或者ssh进行交互，单独部署，相关工具的信息均在配置中心进行配置。这就是整个智能运维平台的架构，尽可能地做到低耦合，易扩展，易迭代的特性。Ø 可定制化、可扩展、支持复杂任务编排、支持长耗时任务执行的任务系统
任务系统，目标是可定制化、可扩展、支持复杂任务编排、支持长耗时任务执行。为了能够兼容适配各种任务，通过设计了这三种任务模式来实现。Ø 第一个是Ansible-PlayBook，针对复杂的、剧本类型、以及自定义任务，实现任务的可定制化以及支持复杂任务编排，还可以复用任务模块。Ø 第二个是平台任务，主要是一些相对固定的、进行平台数据变更、接口关联外部工具和平台、单一ssh命令等类型的任务。Ø 第三个是Agent任务，执行一些长耗时、高频率、相对固定的、特定任务，比如备份任务，还有故障自愈，基础数据采集等。在任务的流程上，为了进一步提升任务的编排能力，除了Ansible本身的剧本式任务以外，任务链路还进一步进行了设计：分别为单一任务、单一任务+回调任务，任务链，任务组任务+回调的方式，更好地针对成功、失败后的任务进行额外处理。而任务组和任务链是针对一些无法在Ansible剧本上实现的任务编排的补充，通过这样的任务编排完成更多复杂度高的工作在任务的形式上，除了平台本身运转需要的平台任务形式，平台还补充设计了定时任务和自定义剧本任务。平台任务，也就是运维模块生成的任务，通常会伴随着工单以及审批流之后有需求发起者触发完成。自定义的剧本任务，通过编写对象、变量、角色（角色里定义了具体的工作），通过这种方式可以定制各种批量执行的任务来完成一些临时的、一次性的工作。定时任务方式，配置的定时任务通过Cron和Interval方式触发，取代服务器上的Crontab任务，更便于管理。这些就是任务系统的运行机制，从任务的发起、编排和执行都根据我们实际工作遇到的场景需求进行了设计。之前也设计过Tcollector+Open-Falcon+Grafana的组合，基本上也能满足需求，但是在告警规则的定制和管理方面不够方便，所以在新平台中采用当前比较流行的Prometheus。通过定制Exporter采集器来采集所需的指标，而且Prometheus的热度比较高，各个类型的开源采集器都很多，只需要把相对较好的Exporter项目拿来，再根据自己的需求补充一些采集指标，就能够完成Exporter的定制，如果没有合适的开源项目，Prometheus也提供了比较丰富的api帮助我们定制和开发采集器，而采集对象上，通过控制Target来决定Exporter采集的对象（集群、机器、实例等对象），从而实现通过平台能够对监控对象进行管理。在告警上，采用比较热门的AlterManger作为告警组件，对告警组件的需求是能够通过配置控制告警规则与告警形式（电话、钉钉）与告警接收人三者关联，AlterManger能够完全满足我们的需求，通过控制ruler来决定告警内容、阈值,通过alterManger的路由规则和接受者组配置决定告警形式和接收人，从而实现通过平台能够对告警规则、告警形式、告警对象进行管理。在可视化上，Grafana应该是除了自研以外的最佳答案了，并且Prometheus的PromSQL也非常的灵活，通过PromSQL去定制Dashboard，基本上可以配置任何我们想看的监控数据，包括一些多指标综合性数据，比如Mysql内存磁盘使用比例、QPS偏移量、容量偏移量等，能够快速地看到异常的分片、节点，还可以配置总体的资源概览便于进行统计规划。通过这样的搭配，实现的这个监控系统，具备了低耦合、可自定义程度高，管理便捷等非常多的优点，配合平台的管理也非常方便。资源管理部分是提升资源效率的关键。我们相同数据库类型的不同集群实例是混部署在同一台机器上的。这种混部方法能够大大提高资源利用效率。比较重要的是如何分配这些资源。平台结合了资源已分配情况、服务器亲和度、实际资源使用情况、业务需求以及配置中心设定的决策参数（超卖系数、排序优先级）来决定选择哪些服务器进行资源分配。根据实际运行情况，还会对机型进行调整，调整机型的资源配比，以提高资源利用效率。对于某些特殊的集群，还可以设置独享，使整个集群不受资源策略调度的影响。为了保证备份的可用，一般大家都会配置远程备份，避免机器故障而丢失备份。而为了进一步确保有备份，且备份是可用的，我们设计了这样的备份系统。整个备份包括了整个完整的闭环：备份节点的选择、本地备份、远程备份、备份校验、过期备份清理。1．平台定时任务触发备份，备份开始会选择合适的备份节点，这里会考虑机房优先级、磁盘容量、已分配的备份任务数量来综合考虑将备份任务分配到哪个节点上，这样做的好处就是集群的节点变更之后不需要对备份任务进行调整。2．选好备份节点后，平台通过Manger给Agent发送备份任务。4．远程备份的Producer会监听这个备份记录，如果有完成的本地任务，就会把该备份任务信息发送到队列中。5．远程备份的Consumer会监听这个队列，有需要远程备份的记录，就会将该备份拉取到远程备份机。6．在远程备份机上，会配置备份校验工具，定时将已完成的远程备份进行校验，并将校验结果更新到备份记录中，然后触发过期备份的清理，将超过保留天数的备份进行清理。7．最后是定时的备份巡检任务，会把这一天的备份记录进行统计，发送给DBA，让DBA能够清晰地看到当天的备份情况。这个系统针对集群规模比较大的情况，通过扩展远程备份的Consumer数量来提升传输效率。第一块是机器替换，因为使用云服务器，遇到机器故障的频率就比较高。所以针对这个场景，我们做了机器替换的功能，如果有主节点，高可用会自动failover进行切换，故障处理的需求就转换为故障集群上从节点的补充，为故障集群重新分配一个新的节点，这个重新分配的逻辑就是前边资源管理部分介绍的，节点补充玩之后，再把这些故障节点删除，这整个故障就处理好了。第二部分就是集群故障、数据故障的情况下，做了一个兜底的处理方案。方案是把数据恢复到新集群上，然后根据实际情况，通过DTS同步数据，或者通过业务逻辑进行数据修复。在故障的预防上，我们做了一些比较简单的告警自动处理机制，比如Redis 内存达到上限后的自动调整、连接数打满后自动清理一些连接。链路探测、抓包功能、慢日志、实时连接信息、定制化的一些监控数据，这些能够帮助快速地进行问题的分析排查。多云环境下的管控策略部分的内容，首先简单介绍一下作业帮数据库服务的多云架构。第一种是跨云主从架构，也就是在数据库层面还是通过主从的方式同步。Proxy层全部进行了容器化，每个云在各自的K8s集群内构建Proxy，通过统一的SVC地址路由到不同的Proxy，而Proxy再转发到各自云内的节点上，当然会有一侧的云的写会有跨云的情况。第二种是单元化架构，数据库层面是两个单独的集群，通过DTS进行双向同步，DTS由DBA团队进行了自研改造，主要解决双向同步的一些问题。容器化的Proxy层，因为是两个不同的数据库集群，所以对应的是两个不同的SVC，未来能够对业务无感，所有加了统一的Cname，根据各自的云路由到对应的SVC，然后解析到同侧Proxy上。4、节点管理方便扩缩容，也能够让我们快速地拉起某个云的Proxy，提供服务不同级别的切云能力，可以再业务无感的情况下，进行切换。针对第一种跨云主从架构，主要是分正常情况下主节点切换，以及故障情况下的强制切换，针对第二种单元化架构，可以根据需求将流量切到目标云所在一侧。还有一块是故障演练，主要是针对单云故障、专线等场景进行模拟演练，有助于我们在真正遇到故障时快速应对响应。为了降低故障演练的影响，演练前置工作，平台设置了禁写控制，避免演练期间双写造成的数据冲突，演练期间使用切云能力进行切换，让故障期间服务能正常运行，最后是故障恢复之后，快速恢复多云架构，这里是根据不同的数据库类型需要做不同的恢复策略，所有的操作均可以批量进行，大大缩减故障演练的时长。除了数据库服务的多云管控，在平台层面也针对性地做了设计。不同区域：国内、国外的也分进行开部署，每个平台运维各种区域的服务，这样做更好地进行隔离管控。每个区域平台的部署基本上是一致的，关联组件都需要单独部署。只有配置中心不一样，通过配置中心控制不同区域平台的参数。相同区域，为了避免单云故障，我们也把平台在每个云上进行部署，但是在部署方式上跟前边分区域部署的方式不同，其中管理组件只在一个云上部署，因为这些外部组件基本上都是一些外部功能，不影响对集群的一些运维操作。数据库层是两个独立集群，通过各自平台进行写入，通过DTS双向复制。每个云部署自己的worker，执行自己平台发布的任务。这样在单侧云故障的情况下，整个平台也能够执行一些基础、核心的任务。为了提升工作效率，降低DBA的工作负担，平台对服务进行了开放和分级管控，也就是把数据库运维服务对研发同学开放使用。这样做还有一些好处，就是控制风险，根据不同等级的服务进行权限上的划分，让DBA进行把关。所有操作都通过平台进行，提升服务的同一性，规范操作。自助式的方式也进一步提升满意度，提高双方的工作效率。低风险的服务完全开放给研发同学，完全自助，无需DBA介入。中风险服务，开放给研发同学，但是审核环节需要DBA介入把关。整体的处理流程是通过平台控制来生成工单和任务，通过管控单进行审核，通过审核分类来进行分级。整个流程都是低耦合的，可以灵活地进行封线管控的管理。一个是自动化与人工结合的优化，在没有实现完整闭环的智能运维系统前，总会有一些自动化运维平台无法覆盖的问题，遇到这样的问题，需要结合日志和工作流程，人为地去做修复和调整。所以一个方向就是提供更多的可视化的数据支持，加上更小单元化的功能可以任意组合，加上人的决策，以此来解决这样的问题。第二个就是继续提升故障自动处理的能力，针对常发故障进行总结，精确故障发生的规则，提炼故障处理的标准操作流程，从而补充故障自动处理的能力。第三个是智能巡检报告，当前的巡检还只是对数据进行一个总结展示，需要将监控数据和元信息以及DBA总结的数据模型进行结合，根据数据推断服务健康情况以及优化建议，生成智能报告。第四个是资源调度的智能化，资源的使用情况会随着业务发展、故障等情况会有比较大的变化，当出现资源紧张的情况的时候，系统能够发现，并进行相应地、平滑地调度处理，均衡资源使用。平台的开源正在进行中，未来将会在这进行开源，有兴趣的同学可以关注：https://github.com/zyb-dba| 1024丨与14位程序员老师一起聊聊智能图书
| 受邀参加2023GET大会 作业帮首席科学家宋旸分享教育场景下的科技力量
| 作业帮运维转型的思考和实践