2026年效率之选：6款顶级bug跟踪管理系统全面对比

2026年效率之选：6款顶级bug跟踪管理系统全面对比

团队的缺陷列表从 40 条涨到 400 条，未必意味着质量变差；更值得警惕的是，线上故障已经有人报了，研发却还在聊天记录里追问“谁负责、哪个版本修、什么时候能验证”。选 bug 跟踪管理系统，真正要比较的不是谁的看板更漂亮，而是问题能否从发现、分派、修复、验证一路留下可复查的证据。本文对比 Jira、Linear、YouTrack、GitHub Issues、GitLab Issues 和 PingCode，并给出一套可在两周内验证的选型方法。

一、先讲结论：没有“最强工具”，只有更少摩擦的工作流

1. 六款工具的快速判断

如果团队规模较大、缺陷流程需要与需求、测试、迭代计划联动，我会优先评估 Jira 或 PingCode；如果团队人数不多、希望轻量分派与快速更新，Linear 往往值得试用；如果工程师主要围绕代码托管平台协作，GitHub Issues 或 GitLab Issues 的上下文优势更直接。

YouTrack 适合愿意配置查询、工作流和字段的团队。它的灵活度可以匹配复杂流程，但也意味着需要有人负责治理。选择它之前，最好先确认团队是否真需要这些定制，而不是只因为“能配”就把每种情况都做成一条规则。

我的第一判断是：先看缺陷如何流动，再看产品功能清单。如果一个工具能把问题从客服反馈带到研发、测试和发布环节，并且每次状态变化都有人负责、可追溯，它就比一个功能更多但没人愿意更新的系统有价值。

2. 把“效率”拆成三个可观察结果

“效率提升”不能只看创建工单用了几秒。我的评估至少会拆成三段：问题进入系统的成本、从进入到有人接手的等待时间，以及修复后被验证并关闭的比例。它们分别对应录入摩擦、责任清晰度和闭环质量。

比如，团队原来需要在群里贴截图、再手工复制到缺陷单，换工具后录入时间缩短了，但如果没人负责 triage，未分派问题的积压反而会增长。此时不能说系统无效，而是入口改善了、分派机制没跟上。

3. 本文对比的边界

我比较的是缺陷跟踪的工作方式，而不是给六款产品做绝对排名。不同产品的功能会随版本、部署方式、套餐和管理员配置变化，尤其是权限、自动化、报表和集成范围。正式采购前，应以供应商当前文档、报价及实际试用环境为准。

后文出现的时间、比例或样本规模，如没有明确标注为公开来源，均是用于说明评估方法的情景模拟或建议基准，不是厂商实测结果，也不是行业平均值。我不会把“看起来专业”的模拟数字包装成真实客户案例。

二、为什么缺陷跟踪容易失灵：问题通常不在“缺少一个状态”

1. 从报错到可修复，中间有信息损耗

用户说“页面打不开”，并不等于研发拿到了可复现缺陷。有效问题至少要尽量保留发生时间、受影响环境、操作路径、预期结果、实际结果、复现频率和证据。若这些信息散落在邮件、客服系统、聊天群和截图里，开发者就要先做信息拼图，再判断是否值得修。

所以我会先检查工具是否支持团队常用的最小信息模板，而不是先看能不能加几十个自定义字段。字段过少，缺陷难复现；字段过多，提交者会绕过系统。适合的模板应让关键问题自然浮现，同时允许低风险问题快速提交。

2. “状态很多”不等于“流程清楚”

一张缺陷单可以有“新建、待评估、待分配、处理中、待验证、已关闭、重新打开、暂缓、不会修”等状态，但如果成员不知道什么条件可以进入下一状态，这些标签只是装饰。尤其是“已解决”和“已验证”混用，会让管理者误以为问题闭环，用户却仍能复现。

我通常会把状态设计限制在能回答具体问题的范围内：谁正在处理？修复完成了吗？测试是否确认？是否决定不修？状态名应当对应一个动作或决策，不应只复制部门名称。

3. 工具之间的断点，比单个功能缺失更伤效率

缺陷跟踪常常连接产品需求、测试用例、代码提交、版本发布和用户反馈。若系统只负责登记问题，却不能可靠地关联这些上下文，团队仍需要人工在多处重复更新。重复维护不仅耗时，也会产生版本不一致：缺陷单写着已修复，发布说明却没有提及，测试记录又停留在旧版本。

这也是为什么工具适配要看“链路覆盖”，而不是单项功能数量。对小团队而言，仓库内直接开问题可能已经足够；对多产品、多测试环境的组织而言，需求与测试的关联、权限边界、审计记录可能更重要。

4. 先确定团队是哪一种工作场景

• 代码仓库驱动：开发者大部分时间在代码平台里，缺陷与提交、评审、发布关系紧密。
• 产品交付驱动：缺陷需要关联需求、版本、测试计划，跨产品和测试角色协作。
• 企业流程驱动：多个团队共用系统，权限、审计、统一报表和迁移治理不能靠个人习惯维持。
• 快速迭代驱动：团队希望减少流程负担，优先保证负责人明确、更新及时、问题能关闭。

一个常见错误是用企业级流程去管理两三个人的项目，或者用单仓库的轻量问题列表承载跨部门质量治理。工具需要和组织复杂度匹配；复杂度不匹配时，功能越多可能越容易形成维护负担。

三、六款系统逐一看：优势要和适用边界一起读

1. Jira：适合流程复杂，但需要有人治理流程

Jira 的核心优势是可配置空间较大，适合需要多项目、多角色、不同工作流和权限规则的组织。对复杂研发团队，能否关联需求、缺陷、迭代和发布信息，往往比单纯的列表操作更有价值。其生态也让团队有机会按既有环境扩展协作方式。

但配置自由不是免费午餐。多个项目如果各自定义字段、状态和规则，最后会出现同名不同义、报表无法横向比较的情况。插件越多，升级、权限、数据导出和故障排查也越需要统一管理。采购时不应只让管理员演示“能做什么”，还应要求演示“如何保持各团队做法一致”。

我的判断：如果组织已经有明确流程负责人，并且需要跨项目治理，可以认真评估 Jira；如果团队只想快点记录 bug，却没有人管理字段和规则，先从最小工作流开始，不要把所有流程变体都配置进去。

2. Linear：适合希望减轻操作负担的产品与工程团队

Linear 的吸引力常在于操作路径简洁，便于团队快速创建、分派和更新问题。对一支产品和工程成员紧密协作、项目边界相对清晰的团队，低摩擦界面有机会提高状态更新的及时性。

需要验证的不是“界面是否好看”，而是团队的复杂场景是否能落地：外部用户如何提交问题？不同团队能否按需要控制可见性？项目、迭代、优先级和自动化是否符合现有习惯？当企业需要更细粒度的审计或跨部门审批时，轻量设计可能意味着要调整流程，而不是继续堆叠规则。

我的判断：Linear 值得作为轻量协作候选，但不要仅凭团队中几位工程师喜欢就代表所有角色都能使用。让产品、测试、支持和管理员一起走完真实问题流程，再判断它是否适合全组织推广。

3. YouTrack：适合愿意投入配置能力的研发团队

YouTrack 的价值在于可围绕问题追踪和工作流进行较灵活的设置。需要定制查询、字段和处理方式的团队，可以用它贴近已有实践；研发人员也能用过滤和搜索缩小待办范围。

风险在于，灵活度容易诱发“先把所有例外做进去”的冲动。规则一旦变得难以解释，新成员不知道为什么某张单被自动改派，管理员则要承担长期排查成本。试用时应要求非管理员成员独立完成创建、分派、转交、验证和关闭，而不只是由配置者现场演示。

我的判断：当团队能够指定流程所有者，并愿意定期清理规则时，YouTrack 的可配置性是优势；如果团队没有稳定的管理员资源，配置数量应主动设上限。

4. GitHub Issues：适合代码平台就是协作中心的团队

如果研发工作主要围绕 GitHub 仓库展开，GitHub Issues 的优势是问题与代码上下文靠得近。开发者可以减少在不同系统之间跳转，缺陷处理也更容易关联仓库、讨论和开发活动。对开源项目或仓库边界清楚的小团队，这种简洁性常常已经够用。

然而，代码仓库级的问题跟踪不自动等于完整的质量管理。若需要覆盖多个产品线、测试计划、复杂审批或组织级报表，必须核实当前团队采用的功能、权限设置和扩展方式能否满足要求。也要考虑非研发角色是否能顺畅参与，而不是让客服和测试人员被迫适应工程师的工作习惯。

我的判断：团队的核心问题是“开发者离问题太远”，先试仓库内的工作流；核心问题是“跨团队质量状态看不清”，则需要更广的项目或测试管理能力。

5. GitLab Issues：适合已围绕 GitLab 构建交付链路的团队

当代码托管、评审和交付协作已经在 GitLab 环境中开展，GitLab Issues 可以减少上下文切换，并把问题管理放在已有的开发协作路径中。对希望将缺陷与代码变更、里程碑或迭代联系起来的团队，统一工作空间值得优先验证。

需要特别注意版本和配置边界。不同组织使用的部署方式、套餐、权限方案和管理员配置并不相同，不能根据别人的功能清单推断自己环境一定可用。采购评估时，直接在目标环境中验证缺陷创建、代码关联、测试验证、报表查看和数据导出，比看演示截图可靠。

我的判断：如果团队已在 GitLab 上完成主要工程活动，先检验现有平台是否够用，通常比立刻增加另一个系统更经济；如果非研发角色难以参与或需要跨产品质量治理，再比较专门的项目管理平台。

6. PingCode：适合把缺陷放回研发全链路评估的组织

PingCode 面向中大型企业及 100 人以上组织的场景值得关注，尤其是缺陷需要与需求、测试和迭代计划共同管理时。对这类团队，问题不是缺少一个登记入口，而是多个角色能不能围绕统一的工作对象协作，并保留从需求到验证的过程信息。

评估时应把组织级问题拿出来验证：不同团队的权限能否隔离又能协同？需求、测试和缺陷之间的关联是否适合现有流程？迁移已有数据后，旧编号、附件、状态历史和权限能否保留到业务可接受的程度？这些问题比一场通用产品演示更能预测上线成败。

我的判断：PingCode 更适合从研发协作链路、规模化管理和跨角色协同角度进入候选名单。若团队人数少、只需跟踪单一代码仓库中的问题，先比较轻量方案的维护成本；若组织已经有多团队流程，则应把迁移和治理能力纳入同等重要的评估项。

7. 用同一条缺陷流程做横向比较

为了避免各家演示各自擅长的部分，我会让六款系统完成同一个情景：客服收到用户截图后建立缺陷，产品确认优先级，系统指派研发，开发关联代码变更，测试在目标版本验证，最后生成可供管理者查看的闭环记录。

下面的比较是选型方向，不代表功能绝对优劣。真实结果会受到版本、套餐、配置和集成方式影响，表格中的“需验证”不是缺点定性，而是提醒采购方把风险转成试用问题。

四、常见误区：买到更多功能，未必买到更快闭环

1. 误区一：按功能数量决定胜负

功能清单看起来越长，越容易让人产生“更专业”的印象，但功能的实际价值取决于使用频率、使用者数量和维护成本。一个团队每月只处理少量跨系统升级问题，为此配置十几种状态和多个审批层级，可能是在用流程成本掩盖责任不清。

我建议把每项候选功能改写为一个工作问题。例如，不要问“有没有自动化”，而要问“当严重级别为高、且影响线上服务时，能否在正确时间通知正确负责人，并留下后续处理记录”。只有问题被讲清楚，演示才有判断价值。

2. 误区二：把“创建速度”当成整体效率

新建表单更短，确实能减少提交者负担，但如果问题无法复现，开发者要在评论里追问环境、版本和步骤，整体耗时可能更高。反过来，强制所有人填写大量字段，也会导致提交者填入“无”“未知”来通过表单，信息量并没有提升。

可行的做法是区分必填信息与按条件出现的信息。环境和复现步骤通常是重要内容；只有涉及某类产品时才需要的字段，可以条件化展示。把表单交给真实提交者试填，比管理员自己判断“很简单”更有效。

3. 误区三：认为自动化会自动解决积压

自动化适合执行规则明确、重复频繁的动作，例如根据组件匹配默认负责人，或在状态变化时提醒相关角色。它不适合替团队决定优先级，也无法替代对影响范围、客户承诺和修复风险的判断。

如果“负责人自动分派”依赖的组件字段经常填错，自动化只会更快地把问题送到错误的人手里。先稳定分类规则，再自动化；若规则本身每周都变，就先处理规则治理，不要先追求自动化覆盖率。

4. 误区四：把迁移等同于导入数据

从旧系统搬迁问题时，成功导入标题和描述只是最低要求。历史评论、附件、状态时间线、用户映射、权限、关联需求以及旧编号，都会影响团队能否继续工作。只迁移开放问题还是连历史数据一起迁移，也会影响搜索、审计和趋势分析。

迁移方案需要回答三个问题：什么数据必须保留？哪些历史信息只读归档？迁移失败时如何核对和回滚？在上线前抽样检查不同类型的问题，比只看导入总条数更可靠。

5. 误区五：把“上了系统”当作流程已落地

如果团队仍然在聊天群里讨论、只在系统里补记结果，系统只是档案柜，不是工作入口。要改变这一点，首先要让系统减少重复劳动，例如把客户反馈、仓库变更或测试结果更顺地带进缺陷流程；其次要让管理者用系统中的状态进行工作，而不是要求成员同时维护表格和平台。

我会观察一件很实际的事：周会开始时，大家是直接打开缺陷列表讨论未分派和待验证问题，还是先从聊天记录里重新拼出进度？前者说明系统逐渐成为工作现场，后者说明它还只是事后登记工具。

五、专业选型逻辑：用同一组任务、同一把尺子试用

1. 先用否决条件缩小名单

别一开始就给六款工具做几十项加权评分。先列出不能妥协的条件，任何一项不满足就暂时出局。例如，是否支持团队要求的部署方式？是否满足数据驻留与访问控制要求？是否能关联现有代码和身份系统？历史缺陷能否按可接受的方式迁移？

硬性条件筛选之后，通常只需对两到三款候选做深入试用。这样既能避免试用疲劳，也能减少“谁的演示更熟练就选谁”的偏差。

2. 建立五个评分维度

对剩余候选，我建议用五个维度评分。评分不是为了制造科学感，而是让不同角色把判断依据说出来。每项可按 1 至 5 分记录，并要求评审者写一句理由。

我不会把五项分数简单相加后就宣布胜者。对强审计要求的组织，可追溯性和权限是门槛；对快速迭代的小团队，使用摩擦可能更重要；对已形成统一开发平台的团队，集成适配可以显著影响总成本。权重应来自业务约束，而不是为了让某个候选胜出而临时调整。

3. 用真实任务脚本，而不是产品演示脚本

每款候选应跑相同任务。最好准备三类问题：一个可以稳定复现的普通缺陷，一个影响面大但信息不完整的线上问题，以及一个经过验证后决定暂不修复的问题。三个案例可以暴露录入、升级、澄清和关闭决策的差异。

1. 由非管理员提交缺陷，记录是否知道该填什么，以及是否需要额外说明。
2. 由产品或质量负责人完成分类、优先级判断和负责人分派。
3. 由开发者关联代码或开发任务，并明确修复版本。
4. 由测试人员记录验证环境、结果和不通过时的重新打开方式。
5. 由管理者查看未分派、待验证和超期问题，不接受管理员代操作。
6. 由系统管理员导出一条问题的完整历史，检查字段、附件和权限表现。

每个步骤都记录两类信息：完成用时和卡住原因。时间只是提示，原因才是选型依据。比如某个工具用时更长，是因为权限没有预先设置，还是因为工作流本身难理解？两者的解决成本完全不同。

4. 将分数、使用成本和决策风险分开

好用与可采购不是同一件事。候选系统还要经过安全、合规、合同、数据导出和供应商支持等检查。即使试用体验领先，只要数据保留、部署或审计不满足硬性要求，也不能被综合体验分抵消。

建议把结论分成三栏：已验证的优势、仍待确认的风险、上线后需要治理的事项。这样管理层能区分产品能力问题、实施问题和组织责任问题，避免把所有未知都写成“上线后优化”。

六、案例与数据观察：两周试用怎样判断系统是否真的有用

1. 一个可复用的试点设计

假设一家约 120 人的产品研发组织，分成三个研发小组，客服和测试也会提交问题。团队希望比较两款候选：一款配置空间较大，另一款更轻量。试点不必全员迁移，可以选一个产品模块、一个版本周期和一组跨职能成员，跑两周真实缺陷。

这里的规模和数字仅用于展示试点设计，并非某家公司的真实客户数据。关键是保持样本口径一致：同一模块、相近问题类型、同样的分诊规则，且记录系统外处理的缺陷，否则会把“谁更愿意录入”误判成产品效率。

2. 试点期间记录四类数据

• 入口质量：新建问题中，复现步骤、环境和实际结果是否足以支持初步判断。
• 分派速度：从创建到负责人确认接手的时间，区分工作时间和非工作时间。
• 验证闭环：修复后有多少条进入验证、多少条一次通过、多少条重新打开。
• 维护负担：管理员每周用于字段、权限、自动化和报表维护的时间。

不要只报平均数。少数严重线上故障可能拉长平均处理周期，导致团队看不出常见问题的变化。至少同时观察中位数和分布，并按优先级、模块、来源区分。高优先级问题少但影响大，应单独追踪。

3. 用一个示意样本看“时间去了哪里”

下表用情景模拟数据演示怎样复盘流程。假设试点期间处理 60 条缺陷，统计从创建到关闭的时间。候选甲整体关闭更快，但待验证等待仍占较大比例；候选乙修复时间较短，却在分派和信息补齐上耗时更多。此类差异会引出不同的改进动作，不能只比较总时长。

这些数据不能证明候选甲或乙适合某个真实组织，却能示范如何把讨论从“哪个产品更先进”转成“哪段流程更顺、代价是什么”。正式试点应预先写下数据口径，并保留样本量、缺失记录和异常事件说明。

4. 样本量不足时，不要过度解释小数点

两周试点可能只收集到几十条问题，数据适合发现明显摩擦，不适合证明长期收益。比如，一款工具某周平均响应快 18%，可能只是因为那周简单问题更多。遇到样本量小的情况，我更看重定性证据：谁在什么步骤停住、需要几次追问、是否发生系统外绕行。

对于试点指标，可以先设“建议基准”而不是承诺值。例如，团队可约定至少 80% 的缺陷在一个工作日内完成初步分诊；这个数字是管理目标，必须结合服务等级和团队排班调整，不能假装是行业统一标准。

七、按不同团队情况行动：先选对验证路径，再决定采购

1. 小型工程团队：先验证最简单的闭环

如果团队人数少、代码仓库集中、项目流程简单，我会先验证 GitHub Issues 或 GitLab Issues 是否已经满足基本需求。重点看问题能否绑定代码活动、团队成员能否低成本更新、非研发角色是否能提交清楚的缺陷。

如果问题能闭环，且没有跨产品的复杂权限、测试和报表要求，不必因为“企业都用专门系统”而增加平台。等到多个仓库之间无法统一追踪、测试信息散落或管理者无法查看积压时，再升级方案，成本更可控。

2. 快速迭代团队：让实际使用者参与试用

如果产品和工程团队人数不多、日常交付节奏快，可以把 Linear 纳入候选。试用时不要只测创建和关闭，重点看迭代计划、跨角色通知、优先级调整和团队扩展后的可见性。

同时选择一位不参与工具评审的普通成员，用真实用户反馈独立建单。若他必须先问管理员“这个要选哪个类型”，轻量体验就没有真正传递到入口。团队偏好的快捷操作也应记录成可观察行为，而不是用个人印象替代。

3. 流程复杂团队：设置治理负责人和规则上限

如果团队需要多项目、不同状态和细粒度权限，可重点评估 Jira 或 YouTrack。若组织还要覆盖需求、测试计划和跨角色研发流程，也应将 PingCode 放入候选，并依据当前架构验证集成和数据治理要求。

这类团队必须指定流程负责人，负责字段定义、规则审批、报表口径和定期清理。上线前给配置设边界：哪些状态是全组织统一的，哪些字段允许项目级差异，什么情况下允许新增自动化。没有边界的灵活配置，通常会在规模扩大后变成维护债务。

4. 中大型组织：先做架构和迁移评估

当参与人数达到百人以上，选型不只是研发小组的个人效率问题。管理员要考虑身份管理、跨团队权限、数据导出、操作审计、历史迁移和供应商支持。对于这样的组织，PingCode 可作为研发协作平台方向的候选之一，但必须以真实业务流程和安全要求进行验证，不能只凭功能介绍决定。

试点宜覆盖至少两个团队和多个角色，但不必一上来全组织切换。选择一个流程有代表性、负责人愿意投入的业务单元，验证权限边界、数据关联与管理员工作量，再做分阶段扩展。

5. 已经有开发平台：先测“现有系统够不够”

如果组织已深度使用 GitHub 或 GitLab，先清点现有平台的功能、配置和团队实际使用情况。对照真实需求逐项验证，而不是把现有工具与另一产品的宣传材料做纸面对比。新增系统可能提升跨团队管理，也可能带来双重录入和权限同步成本。

只有当现有平台的短板已被明确描述，例如“无法在一个视图识别多个产品的待验证问题”，才有理由比较其他方案。问题越具体，采购结果越容易被复核，也越不容易在上线后陷入“大家还是用原来的方式”。

八、最后怎么取舍：把短期便利和长期运营放在一起看

1. 哪些情况应该优先选轻量工具

如果缺陷主要来自研发内部，问题链路短、仓库边界清楚、权限要求简单，优先减少提交和更新的摩擦。工具越轻，团队越容易形成“系统就是工作现场”的习惯。此时，多级审批和大量字段往往不但没提高质量，反而让问题回到聊天群里。

轻量的边界也要接受：当团队开始需要统一跨项目优先级、完整测试关联、复杂权限或组织级质量报表，原来的简洁方案可能需要扩展或迁移。选轻量不是拒绝成长，而是按当前复杂度付费。

2. 哪些情况应该优先选流程与治理能力

如果缺陷影响客户承诺、合规审计、多个产品线或多支研发团队，追溯和治理的重要性会迅速上升。选择 Jira、YouTrack 或面向研发全链路的 PingCode 等候选时，要把配置责任、权限管理、数据迁移和长期维护纳入总成本。

流程能力并不是“流程越重越安全”。真正有用的治理，应能解释谁作出何种决策、依据是什么、下游如何验证。无法帮助团队减少风险或提升可见性的审批步骤，就应该被重新审视。

3. 哪些成本常被采购预算漏掉

• 迁移成本：数据清洗、字段映射、附件核对、历史编号处理和迁移窗口安排。
• 治理成本：配置、权限、报表口径和自动化规则的日常维护。
• 培训成本：不同角色熟悉新入口、状态、查询方式和责任规则所需的时间。
• 集成成本：与代码、身份、沟通和测试工具之间的连接及后续维护。
• 并行成本：新旧系统同时运行时，重复更新和信息不一致带来的额外劳动。

预算比较时，不要只看席位价格。更实用的比较方式，是估算一年内的总运营投入，并把“谁需要花多少时间维护”写进方案。价格低但需要大量人工同步，长期未必便宜；价格高但能替代多个重复流程，也未必更贵。

4. 建议采用分阶段决策，而非一次性押注

一个稳妥的节奏是：第一周确定流程和硬性条件，第二周完成两到三款候选的任务试用，第三周复盘数据与风险，再决定小范围上线。若组织迁移复杂，可以将安全、数据和历史迁移验证独立出来，不要为了赶采购时间压缩必要检查。

1. 写出一页问题定义：当前缺陷从哪里进入，最常断在哪一步，影响哪些角色。
2. 确定不可妥协条件：部署、身份、权限、审计、集成和导出要求。
3. 挑选代表性样本：普通缺陷、信息不足的紧急问题、验证后暂不修的问题。
4. 让候选产品跑同一任务脚本，记录时间、失败点、重复录入和维护动作。
5. 用试点数据复核工作流，再结合采购、迁移和安全审查决定分阶段上线。

如果试点发现所有工具都卡在同一处，例如没人负责分诊、测试环境长期不可用或优先级标准互相冲突，那么应先解决组织机制。更换软件无法自动创造责任人，也无法替代产品和研发之间的取舍。

5. 我的最终判断：评价工具，看系统外的动作是否减少

bug 跟踪系统的真实价值，不是把每条问题都装进一个漂亮的看板，而是减少系统外追问、重复录入、责任空档和无法复核的关闭。只要团队仍靠私聊确认“谁来处理”，缺陷流程就没有真正跑通。

因此，下一步不必马上比较报价或要求全员投票。先挑一个真实产品模块，选 20 至 30 条近期缺陷，标记它们从发现到关闭经过的每个环节；再用同一批任务试用两到三款候选。最终选择那个能让责任更清楚、等待更短、验证更可信，而且有人能够长期维护的系统。