# 一分钟精华速览 #

去哪儿数据库团队管理的MySQL与Redis集群规模庞大，且疫情期间团队精简与资源整合后，团队面临运维效率低、异常感知晚以及处理分析慢的问题。2023年团队启动稳定性治理，应对旅游业复苏带来的业务增长挑战。通过在监控告警、防御优化、备份恢复、压测与容灾演练，以及抓包审计等方面进行治理后，故障率降低50%，故障时间缩短70%，实现了“四个九”的高可用性标准，为业务增长提供了坚实的数据服务支持。详细的解决策略和方法，请参阅文章正文。

作者介绍

去哪儿网数据库团队负责人——冷正磊

TakinTalks稳定性社区特邀专家，去哪儿网数据库技术总监。负责数据库团队运维与开发工作，深耕MySQL、Redis技术领域。具备十年以上的数据库运维与管理经验，曾在传统软件企业与央企科技公司锤炼技艺。专长于MySQL和Redis服务稳定性治理及性能优化，同时致力于自动化平台的研发工作。多年的沉淀与实践，积累了较丰富的经验。

温馨提醒：本文约8500字，预计花费13分钟阅读。

后台回复 “交流” 进入读者交流群；回复“Q109”获取课件；

背景

去哪儿数据库团队主要维护MySQL和Redis两种数据库，其中MySQL的集群规模大约有1000多套，集群实例数大约2600多个；Redis集群规模大约1300多套，实例数量超过16000个，基本覆盖了去哪儿网所有的业务线。

回顾2021年和2022年，我们的数据库服务在故障率与稳定性方面的表现并不太理想，稳定性始终徘徊在“三个九”的境地。2023年我们开始深刻反思并付诸实践，全力推进数据库稳定性的治理工作。然而，就在我们致力于提升数据库稳定性的同时，后疫情时代的挑战也悄然而至。旅游业的快速复苏，特别是在2023年春节期间，业务规模迅速扩大，不仅恢复到了疫情前2019年的水平，更是超越了当时的巅峰。这一突如其来的变化，无疑给我们DBA团队的资源配置和数据库服务稳定性带来了前所未有的考验。

一、去哪儿数据库稳定性治理面临哪些问题与挑战？

1.1 遇到的挑战

过去的三年受疫情影响，全球的经济形势发生了巨大的变化，各行各业都受到了不同程度的冲击。在这个背景下，去哪儿网也面临了前所未有的挑战。为了应对疫情带来的运营压力，公司进行了部分人员和服务器资源的精简优化，以降低成本。DBA团队的规模也进行了相应的缩减，缩减幅度达到了30%至40%，这对于整个团队来说，无疑是一次严峻的考验。同时，由于是自建的数据库，为了降低机柜和租赁成本，公司实施了大规模资源整合策略，整合优化分布在不同机房的服务器资源。

然而，人员减少也带来了一系列的问题，运维自动化平台的维护和功能升级变得尤为困难，因为缺乏足够的人力资源来支撑这些工作。此外，人手短缺还导致日常数据库巡检过程中一些风险点的及时发现和解决变得困难，不仅影响了整个团队的工作效率，同时对线上数据库服务稳定性带来隐患。

接下来，我将详细阐述我们团队如何应对这些挑战和考验，以及我们采取了哪些具体措施来提高数据库的稳定性和性能。

1.2 待解决的问题

1）如何利用现有资源来应对业务增长的需求？

由于服务器资源的增长受到采购周期的限制，我们必须迅速找到一种策略，充分利用现有资源基础，以迅速响应业务需求。尤其是在流量高峰时段，如五一、暑假和十一等节假日，这一需求尤为迫切。

2）如何让有限的人员高效运营数据库服务?

这个问题的核心在于提升DBA团队的工作效率，确保我们的数据库服务能够稳定、高效地运行。

3）如何改善数据库异常感知晚、分析慢、定位难问题?

针对数据库可能遭遇的异常或故障，当前我们的感知、分析和定位效率尚待提升。因此，我们需要着重考虑如何通过自动化开发和工具优化来解决这些问题，以尽可能缩短故障响应时间，甚至预防故障的发生。

二、去哪儿数据库稳定性治理做了哪些事？

2.1 稳定性治理过程

我们的稳定性治理过程大致分为三个阶段：

阶段一（分析阶段）：经过对历史故障和业务反馈的细致回顾，我们深入剖析了数据库异常问题。在全面评估当前风险点后，我们决定采取针对性的治理措施，并确保相关工具能够支持我们的持续运营。我们设定了明确的目标：将故障恢复时间缩短至5分钟内，将服务可靠性提升至99.99%，以确保全年业务影响不超过52分钟。我们将以此为动力，不断优化和完善数据库管理，为业务的高效稳定运行提供坚实保障。

阶段二（规划阶段）：经过初步分析，我们确定了治理方向，细化了涵盖报警监控、资源管理和备份恢复等方面的措施，并制定了具体的治理方案，其中包括针对不同需求量身定制的巡检规则。

阶段三（实施验证阶段）：执行方案并与业务部门合作监测实施效果，如响应时间和故障率，并在高峰期前进行全链路压力测试以确保数据库性能。此外，还要注重日常运营的持续优化，避免问题发生。

2.2 风险梳理

我们从六个主要方面进行了风险识别和处理。

1）运行环境。数据库运行环境依赖于众多硬件和软件要素，例如服务器、交换机、操作系统、网卡等，这些因素都曾不同程度地引发过数据库故障。

2）集群部署。我们提供三种MySQL集群的高可用架构：同步复制的PXC、异步复制的QMHA（自研）和较旧的异步复制MMM架构。然而，异步复制的QMHA和MMM架构在故障转移时可能遭遇秒级不可用，甚至故障转移失败的风险。目前，多数集群尚未实现多机房容灾部署，所有节点集中在单一机房。这意味着一旦机房发生故障，整个集群将陷入瘫痪，对应用造成潜在的巨大影响。此外，核心与非核心应用混用的问题亦不容忽视，非核心应用的高访问量时常干扰核心业务的稳定运行。

3）业务调用。慢查询是MySQL数据库常见的性能瓶颈，也是引发数据库故障的普遍原因。此外，合理配置连接池、有效管理并发数以及均衡读写操作同样至关重要。尤其在应用程序迁移至云端后，发布和扩容的频繁操作可能导致数据库连接数激增。因此，确定适当的日常连接数，并及时监测和调整连接池配置，成为我们亟待解决的问题。同时，管理并发数和均衡处理读写请求也极为重要。若处理不当，如连接池配置不合理或并发控制执行不力，均可能引发集群访问堵塞，从而影响数据库性能和稳定性。

4）运维平台。当前，我们的巡检和监控机制存在明显不足。巡检项不足和巡检标准单一，导致关键指标巡检存在盲区；监控报警系统同样面临挑战，数据采集粒度较粗，可能错过数据库性能的瞬态变化或尖峰时刻。此外，报警延迟或未触发的情况时有发生，使得业务部门先于我们察觉问题，这不仅影响了业务的稳定运行，也暴露了我们在监控和报警机制上的短板。为此，我们亟需重新审视并改进监控和报警机制，以提升对数据库性能变化的敏感度。同时，我们也认识到自动化处理能力的重要性，通过增强自动化处理功能，我们能够更高效地管理日常运维任务，快速响应潜在的数据库问题，从而确保业务的稳定运行。

5）运营管理。我们曾经在数据库变更管理上存在一些疏忽，部分变更操作未能及时通知业务方，导致业务问题发生时，数据库问题难以被迅速识别。业务方对我们后台数据库的变更缺乏了解，可能导致故障排查的时间延长。此外，我们的备份系统效率和有效性都有待提高。旧系统备份成功率低，且备份完成后缺乏定期恢复验证，无法确保备份有效性。同时，单一的备份速度在流量高峰时可能造成线上数据库服务性能下降。在压测演练方面，我们之前的测试主要关注数据库本身，与业务方配合不足。压测性能标准与业务方要求不一致。为提升压测相关性和有效性，我们需与业务方更紧密合作，确保压测环境与业务场景一致，从而更准确地评估数据库在实际工作负载下的性能和稳定性。

6）其他因素。作为数据库服务的提供方，我们深知服务稳定性对业务线使用方的重要性。如果服务稳定性出现波动或者异常情况过多，可能引发对我们服务可靠性的质疑。这种信任危机在故障沟通过程中尤为突出。由于缺乏统一的标准和一致的沟通口径，争议和辩论难以达成共识，这不仅影响问题的迅速解决，还可能加剧双方的分歧。

2.3 稳定性标准

在确立我们的治理手段时，我们基于系统稳定性的多个关键方面来衡量和确定我们的数据库稳定性治理手段和措施。

通过确立这些稳定性标准，我们能够更全面地评估和提升我们的数据库服务质量，确保我们的系统在提供高效、稳定服务的同时，也能保持数据的安全性和完整性。这些标准将指导我们在治理过程中采取有针对性的措施，以达到我们设定的目标。

2.4 治理手段和方向

基于上述标准，在提升数据库稳定性的治理工作中，我们采取了几种关键手段并明确了治理方向：

监控与告警优化：监控是预防故障的关键，也是数据库稳定性治理的基础。我们意识到现有的监控系统存在缺失，因此我们强化了监控措施，使其成为预防故障和数据库治理的基础。通过细致监控数据库的各项指标，我们能够及时发现异常并采取措施，优化并优先处理这些风险点。
压力测试：压力测试是评估数据库稳定性和性能的重要手段。虽然单纯的本地压测存在局限性，但我们通过模拟真实场景的压力，可以测试数据库的高负载和高并发处理能力。我们认识到，为了更准确地反映数据库的负载能力，需要定期与业务线合作进行全链路压测，以验证数据库性能。
应急预案与演练：演练是确保应急预案有效性的关键步骤。我们定期执行备份恢复演练、单机故障演练和单机房故障演练，以确保我们的高可用性和灾备方案的有效性。

监控是发现问题进行治理，压测是探查系统薄弱瓶颈，而演练则是在生产上真实的创建故障，用来发现系统稳定性、鲁棒性和自动恢复性，还能检测应用负责人是否有快速响应系统异常的能力、止血和修复的能力。通过模拟真实的故障场景，我们可以检验现有的应急预案是否有效，提高应急响应的速度和准确性。同时，演练还能加强团队协作和沟通能力，确保在真实故障发生时能够迅速、准确地应对。

有了治理方向后，我们细化了具体的治理措施，包括监控告警、防御优化、备份恢复、全链路压力测试、容灾演练，以及抓包审计等方面。这些措施旨在构建一个更加健壮和可靠的数据库服务环境。接下来，我将对每一项措施进行详细说明，以便大家更好地理解我们的治理方法和实施细节。

2.4.1 治理措施-监控告警

2.4.1.1 监控告警治理策略

1）策略一：健全告警项目

我们发现对MySQL网络流量监控并及时告警，可以避免过往的一些故障。同样，Redis实例的CPU使用率之前也未设有告警，而这是准确评估其性能负载的关键。我们还关注了Redis实例的网络流量，这有助于我们识别实际请求量和潜在的大key或热点key问题，考虑到单台服务器上可能部署了多达50个Redis实例，合理控制网络流量对于保持数据库整体性能至关重要。

2）策略二：重构监控平台

不仅要整合监控指标，还需增加细致的监控层级，以便能够捕捉到以往分钟级监控中可能被忽略的异常情况。此外，还要设计特定的仪表板，从多个维度展示数据，包括集群维度、实例维度，甚至是针对特定问题的深入分析。例如，可以针对常见的Top问题进行监控，一眼识别出当前哪些集群指标存在异常。

3）策略三：提高告警有效性

实施告警降噪，过滤掉无效或不紧急的告警，提升告警的质量和紧急性。同时，增强告警系统的动态屏蔽功能，在服务器维护等特定情况下，临时屏蔽某些告警，减少误报和干扰。此外，定制阈值的功能也是必须的，允许我们根据服务器、集群或实例的具体情况设定个性化的告警阈值，使告警更贴合实际运行状况。

4）策略四：提高响应及时性

监控系统触发告警时，内部IM工具能自动通知相关人，如DBA团队、业务使用方负责人，实现快速的信息传递和协同响应。还要能用IM工具迅速组建讨论组，实现在手机端进行问题分析和处理，减少响应延迟。对于复杂问题，要在手机端提供更新分析功能，快速识别问题源头，加速决策和行动。最后，告警运营团队要每日分析告警情况，不断优化告警系统，提升告警准确性。

以上策略的详细落地经过，请查看往期分享：告警数量减少95%：去哪儿数据库巡检报警系统做了哪些优化？

2.4.1.2 落地案例

接下来，我将通过两个实际案例来展示我们的监控告警治理措施是如何落地实施的。

案例1：通过增强监控粒度，我们能够发现以往可能被忽视的风险

例如，在原有的监控系统中，某个集群实例的负载看起来并不高，通常不到10%。

但当我们实施了更细致的十秒级监控后，我们发现实际上存在短时间内负载迅速上升至25%以上的情况。

按照我们的定义，10%的负载是一个相对安全的水平，但如果CPU负载接近或达到我们日常巡检设定的30%阈值，这就需要我们立即采取行动来处理这一潜在风险。

案例2：内部即时通讯(IM)工具在提高响应及时性方面发挥了重要作用

当收到报警信息时，系统会自动弹出通知，点击后可以快速查看相关主机上部署的集群状态，包括是否有慢查询发生。

通过这个工具，我们可以直接进行慢查询的查杀，查看集群的并发数，以及当前正在运行的查询。对于长事务报警，我们能够判断出事务开始的时间和请求方，如果需要，可以截图保留证据。在必要时，我们可以通过点击一个按钮来终止长事务，从而迅速恢复正常的数据库操作。

2.4.2 治理措施-防御优化

我们的目标是在风险达到告警阈值之前发现并解决这些问题，这依赖于我们建立的巡检平台。

2.4.2.1 防御优化治理策略

1）策略一：健全巡检项目

通过分析历史故障，我们需更新巡检项，包括之前被忽视的内存使用细节。不仅关注内存总量，还要关注内存的 buffer 释放情况，以避免数据库稳定性波动。我们还要改进连接数的监控策略，设置更早的巡检提醒，比如从过往仅在70%时报警，提前到30%就开始关注，以防止连接数饱和导致业务影响。

还要监控Redis的热点分片和单核CPU使用率，以及服务器配置对性能的影响。限制单个服务器上的分片数量，避免因服务量突增而对服务器造成过大压力，确保集群的合理分布。

2）策略二：制定巡检标准

我们为不同的监控指标设定分级标准，并与研发团队和业务方共享，确保对数据库健康状况有统一的评判标准。对于特殊集群，即使CPU使用率较高，但若业务未受影响，我们会根据实际情况进行个性化调整，以提高巡检的有效性。我们还要优化监控系统，通过设定阈值，直观地识别出需要关注的集群，快速定位问题，提前采取行动，防止问题恶化。

3）策略三：提升自动化率

该策略的详细落地经过，请查看往期分享：业务增长挑战：去哪儿如何通过自动化高效管理Redis，实现资源快速交付？

目前我们的MySQL实现了高达90%的核心变更操作自动化，包括MySQL的部署、迁移、节点调整和跨机房迁移，简化为一键式命令。Redis的操作已实现100%自动化，所有任务通过平台执行，包括自动负载均衡，减少了人工干预。例如，我们实现了自动的负载均衡功能，当系统检测到某台服务器的内存使用率过高时，我们只需输入服务器的名称，系统便会自动迁移那些需要负载均衡的集群和分片到压力较小的服务器上，所有这些操作都会在后台自动执行。

此外，我们持续对自动化系统进行优化，与业务团队紧密合作，了解他们的需求，并共同开发相关的项目，以进一步提升我们的服务质量和运维效率。

4）策略四：标准变更流程

所有变更操作都记录并推送至公司统一事件平台，使业务方能够及时了解并订阅数据库变更，快速识别变更引发的异常。不论是数据表的修改、迁移操作还是其他类型的切换，业务方都可以通过事件平台的看板一眼看出是否是数据库变更导致了异常。我们遵循“安全第一、效率第二”的原则来安排变更操作，一方面避免业务高峰时段，另一方面在执行重大变更前，与业务方进行充分的沟通，确保双方都清楚变更的影响，并制定相应的监控措施和应急计划。

2.4.2.2 落地案例

案例1：巡检标准

我们制定了一套内巡检标准，这些标准覆盖了我们关注的主要指标，并为每个指标设定了低、中、高三个阈值级别。一旦监测到的指标达到或超过这些预设的阈值，我们会有一系列相应的操作自动触发。

这些巡检标准已经与相关的业务团队达成共识，并得到了他们的认可。这意味着，当数据库的某个指标，比如CPU使用率或内存使用量，达到某个阈值时，业务团队明白这将触发特定的预警或维护操作。这种共识确保了巡检工作的顺利进行，并帮助业务团队理解我们的运维决策。

案例2：巡检看板

这个看板能够展示MySQL数据库的Top指标，例如QPS或更新操作的记录。通过这个看板，我们能够迅速识别出特定实例的关键性能指标，无论这些指标是高还是低。

除了MySQL，我们还有针对Redis的看板，它们能够显示不同集群的使用率和其他重要性能参数。这些看板不仅提供了实时数据，还能够通过排序机制让我们快速了解到哪些集群可能需要关注。

此外，我们的看板还包括了内存使用情况和网络流量等关键指标。这些看板的设计非常灵活，可以根据我们的特定需求进行定制化开发。例如，如果我们发现某个特定的性能问题，我们可以开发一个新的看板来专注于那个问题，以便更好地监控和解决它。

2.4.3 治理措施-备份恢复

2.4.3.1 备份恢复治理策略

过去，我们面临的备份成功率不高、备份操作影响业务运行、以及缺乏对备份文件有效性验证等问题，现在已经通过重构MySQL备份恢复平台使得这些问题得到了显著改善。例如，我们通过动态限速技术，根据服务器的实际负载动态调整备份速度，避免了对正常业务的干扰。我们还实现了一种通用存储方案，无论是本地HDFS还是云端对象存储，都能够灵活应对不同的存储需求。我们的备份策略也更加灵活，可以根据需要进行调整。

2.4.3.1 图 – 灵活的备份策略，可按需调整

2.4.3.2 落地案例

我们建立了一个备份恢复统计系统，该系统能够详细展示每天备份任务的成功率和状态。通过这个系统，我们能够直观地查看每次备份任务的具体情况，包括它们的详细信息和状态。

2.4.3.2 图1 – 备份任务统计可查看所有备份任务详情

我们已将备份恢复机制深度融入日常运营流程之中，确保能够迅速捕捉备份过程中的任何异常状况。同时，恢复演练已成为我们日常工作不可或缺的一环，通过模拟多样化的故障场景，我们能够精准评估恢复过程所需时长及效果。

此外，我们还充分利用恢复任务的数据，与业务团队保持紧密沟通与同步。例如，当某个大型集群的恢复时间超出预期，我们会及时与业务团队共同探讨，评估集群规模是否适宜，是否需要对集群进行拆分或进行更深入的数据治理，以便减小集群规模，优化恢复时间，确保业务运行的流畅与高效。

2.4.3.2 图2 – 备份任务统计可查看恢复演练任务数据

2.4.4 治理措施-其他

除了上述核心的治理举措，我们还积极推行了一系列精细化的治理方法，如全链路压测、容灾演练以及抓包审计等，从而为业务的稳定运行提供了更加坚实的支撑和保障。这些措施的实施，不仅有效提升了数据库服务的稳定性和可靠性，更为业务的快速发展奠定了坚实的基础。

2.5 专项治理

在数据库稳定性治理初期，我们对服务器、MySQL、Redis等实施了多项专项措施。

在专项治理中，我们特别关注MySQL慢查询的问题，这是影响数据库性能的主要因素之一。为此，我们采取了以下措施：

2.5 图2 – MySQL慢查询专项治理

风险指数模型：我们开发了一个风险指数模型，旨在量化慢查询的潜在风险。这个模型通过分析大量慢查询数据，确定查询因子的95分位值，并据此设定权重。每个慢查询都会根据这个模型被打分，并在详情页面展示风险指数，帮助业务方识别处理的优先级。

2.5 图3 – MySQL慢查询风险指数

慢查询统计数据推送：我们定期向业务方推送慢查询的统计数据，从数据库集群的维度提供信息，协助他们进行慢查询的排期治理。
接口提供：我们提供了一套接口，使业务方能够开发定制化功能，从他们的视角出发，更好地发现和处理慢查询问题。
发布阻断机制：在发布过程中，如果接口检测到应用存在未解决的慢查询，将触发阻断发布机制，直到问题得到妥善处理。
数据库守护者系统：我们的机票业务开发了一套系统，用于从应用请求端监测和预警慢查询，及时发现并处理潜在的性能问题。
每日TOP报表：我们生成的报表可以从多个维度展示慢查询情况，包括部门、应用负责人、风险指数和其他相关信息，使业务方能够根据风险指数排序，确定处理慢查询的顺序。这些措施的实施显著降低了因慢查询导致的数据库故障，近年来，我们几乎没有因为慢查询而引发的故障，有效提升了数据库的性能和稳定性。

2.5 图3 – MySQL慢查询详情页面

2.6 治理效果

经过长达一年多的深入专项治理，我们数据库的稳定性治理成效达成了预期目标。在2023年，故障数量已锐减至个位数，故障率降低了50%以上，更值得一提的是，与上一年相比，故障恢复时间及持续时长均大幅缩减了70%。目前，我们已建立起一套高效快速的故障处理机制，确保能够在短短5分钟内精准定位并妥善处理各类故障。在稳定性方面，我们更是达到了“四个九”的服务水平，即全年业务受影响的时间严格控制在52分钟以内。而实际上，我们的稳定性表现远超预期，全年业务受影响时间甚至低于30分钟。

三、个人总结和未来计划

3.1 管理经验总结

在治理过程中，我想分享几个关键的管理心得。首先，在项目起步之初，确保各方对项目的目标有着清晰且一致的认识，是确保后续沟通顺畅的基石。其次，我们始终坚持以数据为沟通的依据，这样不仅能增强我们话语的权威性，更能让业务方快速而准确地把握问题的实质，进而更有效地解决问题。再者，我们注重每一次会议的策划与组织，确保每次会议都有明确的目标，并邀请合适的参与者参与，以最大化会议的效率和成果。

我也认识到，数据库稳定性治理工作不是一项一劳永逸的工作，而是一个持续的挑战，新问题总是不断出现。因此，我们将持续努力，不断寻找改进的机会，以确保我们的数据库和系统能够稳定运行。

3.2 近期规划

3.2.1 驼迹问题追踪平台

我们正在计划构建一个全链路的问题追踪平台，这个平台旨在实现对于数据库报警、监控数据、变更记录、业务发布信息以及数据库和系统日志等关键信息的全面整合。通过这一系统，我们能够更快速、更准确地定位和解决异常，从而提升整个系统的稳定性和可靠性。

全链路问题追踪平台的主要功能包括：

实时报警与监控。系统能够实时接收并处理来自数据库的报警信息，同时监控关键指标的变化，确保在问题发生时能够及时发现并作出响应。
变更记录与业务发布信息整合。通过整合变更记录和业务发布信息，系统可以帮助我们追踪每次变更对系统的影响，从而更好地理解问题的来源和演变过程。
日志分析与诊断。系统能够收集并分析数据库和系统日志，提取出有用的信息，为问题的诊断提供有力支持。

除了以上核心功能外，我们还将在平台上提供丰富的数据统计和自助分析功能。通过对收集到的数据进行深入挖掘和分析，能够识别出潜在的问题和风险，为优化治理措施提供数据支持。同时，系统还会定期生成报告，总结过去一段时间内的系统运行情况和问题处理情况，帮助我们更好地了解系统的运行状态并进行持续改进。

3.2.2 优化集群服务器类型

针对我们自建数据库的特点，我们将根据数据库的使用场景优化集群服务器，提高资源利用率，并降低成本。例如，根据不同的业务场景、请求数据库QPS的高低以及集群数据量的大小，我们将采购不同类型的服务器，并进行相应的调整和优化。我们还会制定不同的管理和治理标准，以提升问题处理效率，增强服务质量和系统稳定性。（全文完）