小米集团 Jira 实战：如何在高负载状态下保持 Jira 性能与运行稳定

2023 年 4 月 14 日，Atlassian 中国合作伙伴企业日·上海站圆满落幕。作为Atlassian全球白金合作伙伴、云专业伙伴，龙智参与了此次活动，并邀请小米集团信息技术部 SRE 薛世英作为演讲嘉宾，分享了小米公司的 Jira 实战经验。

以“小米集团 Jira 实战：如何在高负载状态下保持 Jira 性能与运行稳定”为主题，薛世英深入介绍了小米成功实践万人规模 Jira 迁移的经验，并分享了如何优化 Jira，如何根据用户需求实现功能的扩展，如何实现不间断提供服务，以及一些 Jira 日常使用技巧，为大家提供实践参考。

▽ 点击此处观看回放视频

以下是部分文字实录（有删改润色）：

各位下午好，我是来自小米公司的薛世英，今天受龙智邀请来讲解小米 Jira 系统的使用经验，我会分享我们是如何让 Jira 系统保持运行稳定性的。

小米从早期就开始使用 Jira，2013 年我接手了 Jira 系统的运维与管理。当时使用的是 Server 版本，现在已迁移至数据中心版。

小米 Jira 项目概况

2013 年的时候，小米公司的 Jira 用户不足百人，主要用于安卓的研发。当时使用 Jira 的原因是用户数（员工数）增长过快，大家不可能认识所有同事，也不可能了解到每个人具体负责的工作内容，修 bug 很难找到正确的人或部门，加上 bug 统计管理的需求，以及 UI 界面易用性的考虑，我们开始使用 Jira。

到现在，小米已经使用 Jira 10 年了。目前我们的数据量特别大，大概有千万级的 Issue，而且这些 Issue 都是不能归档的。我们大约有 2,000 多个项目，界面、阶段的数量也比较多。

我们遇到最多的问题是接口机器人对接导致 Jira 系统运行慢。小米自动化的程度很高，每天大概有上百个接口机器人不停地对接 Jira 系统。

我们日活用户大约有 14000 人，有专人维护系统和需求，每周大概有 50 多个需求到我们这里进行各种需求变更。

Jira 优点

Jira 优点在于接口丰富、开放。用了 Jira 系统后，所有用户都可以随时随地拿到他想要的数据，不存在需要二次研发后才能有接口，或需要额外增加成本投入的情况。其他还有一些常见优点，比如可以自定义工作流、界面和字段，还有它本身的敏捷理念，丰富的插件市场等。

对于小米来说，除了接口，标准的 webhooks 服务用得也比较多，我们推送变更数据到用户方，Issue 的状态可以实时变更。

Server 版迁移到数据中心版

说一下我们为什么要把 Server 版迁移到数据中心版，以及在迁移过程中遇到了什么问题。当用户数增加、数据量庞大，再加上机器人的频繁对接，单机版的 Server 一天可能停止服务七、八次。

我们当时分析了原因，也找官方做了大量优化工作，找出的原因：

第一是因为 JVM 内存调整，会导致长时间 Full GC 回收频繁失败，导致 Jira 没有响应。

第二是因为数据量较大，Issue 也多，随时需要查看和搜索。还有一点是我们购买的 Server 产品不限制用户数，导致用户较多，机器人随时在对接。

第三是因为 Server 版本产品无法使用限流功能。

我们想到的临时应对方法是通过人为重启中止 Full GC 操作。但是人为重启需要五分钟时间，如果人不在旁边时间会更长。

还有一个方法是使用脚本实现 HA 功能，加速自动化处理，但是再怎么加速还是需要恢复时间。

另外，我们从用户端解决问题，建立使用规范和机器人登记规范，降低获取数据的频率，缓解不可用次数。

但这些方法都治标不治本。

迁移至数据中心版

我们选择迁移到数据中心版来解决以上问题。迁移的时候，我们内部遇到最大的问题是部门成本与分摊核定。处理好成本问题后，我们又面临筛选供应商的问题。公司的采购部门已经提前将优质供应商进行了筛选，再根据相应的标准综合评判，最终选择龙智作为我们的 Jira 代理商。

采购前，我们做了一些技术上的方案测试，包括后来的正式迁移。在正式迁移之后，我们来到龙智公司的上海办公室待了一周的时间，与龙智专家和官方技术支持一起，把积攒的 108 个问题集中解决，其中包括需求、建议、接入、SSO 等。

现在小米的 Jira 系统可用性已经在 99.95%以上，正常情况可达到 99.98%。

Jira 优化

目前，我们的用户处理流程是用户提出需求，内部沟通确认，一部分需求在确认好之后我们就直接解决。如果解决不了，比如新的功能需求，我们会让龙智帮忙评估，包括评估是否能够通过开发实现、开发的周期和成本、是否需要购买某个插件等。

如果可以通过龙智开发实现，我们会与用户沟通成本和周期，用户再内部评估，成本申请下来后，就开始进行开发、脚本实现等工作。

还有一部分可以通过我们自己研发实现。我们会直接修改 DB 或脚本插件来实现，也可以找龙智编写脚本，例如将用户的操作及流程通过自动化脚本进行约束，以符合规范要求。

定制开发

我们买的插件比较多，使用的核心是龙智自研的组织架构插件，其次是龙智自研的 Jira 飞书插件，因为小米使用飞书，需要把 Jira 和飞书打通。但飞书自带的 Jira 大师不好用，会有卡顿和新版本支持等问题，所以我们找到了龙智做二次开发，还有 ScriptRunner 等脚本插件的支持。

问题排查

我们平时用的关键分析工具是 JFR 和 HAR。JFR（Java Flight Recorder）是一个 Java 的数据收集框架，通过 Jira 的参数实时运行 JFR，把 dump 包保存到各个节点上，遇到 CPU 增高时，可以根据监控时间来分析当时 Jira 系统在做什么，一清二楚。HAR 就是大家平时使用浏览器的 F12 开发工具。如果使用这两个方法还是无法解决，我们就会寻求官方支持，解决速度还是很快的。

1、用户仪表板异常问题

我们的 Issue 数量较多，总体千万级，单个项目就有超过百万的 Issue。所以当用户使用 filter 进行全局排序时，稍微操作不当，JAVA 内存就会 Full，负载增高，所以从 CPU 监控图上就能看到 CPU 突然会飙高。

我们通过 JFR 文件根据时间去查，能清晰地看到用户是谁，做了什么，然后我们会去搜索该用户的仪表盘，看到该用户的仪表盘是空的，基本上都是刷不出来，而且该用户每次登录 Jira，或者是打开 Jira 主页的时候都会卡一次。

解决方法：访问用户仪表盘后，发现第一个图表一直在刷新，并且是白色状态，不出数据，基本可定位该图表异常，可以联系用户本人删除 filter 或缩小 filter 搜索范围。

2、访问速度越来越慢问题

访问速度越来越慢的问题让我们和用户都觉得头疼。在大家打开 Jira 主页时，加载时间超过 10 秒以上，而且每一项都加载得很慢。从运维的角度看，监控指标和各项性能又没有太大的异常，PV 值也很低。

解决方法是：我们和龙智、官方技术支持多次会议后，达成一致意见，从 nginx 代理上做前后端分离，也就是用户端和接口端分开，分开之后感觉速度有质的飞跃。额外的收获是官方帮助我们多次优化了脚本插件，让每个网页的加载从 10M 多减少至 5M，提升了公司 wifi 线路的用户体验。

3、RMI 连接超时问题

我们经常查日志分析问题，发现日志里经常有 RMI 连接超时，每次报超时就会一连串报很多条，并且 Jira 前端无反应或反应慢。

我们会首先查看时间点对应的 CPU 波峰状态，然后去进行分析。JFR 分析能看到是哪个用户用了 API 接口进行操作，占用了多大内存。比如一个接口占用了 10G，这肯定是不正常的。然后联系用户，去查看具体情况。

以我们的经验来看，大部分都是因为一个 Issue 的评论数过千，甚至有的过万。这种就是机器人自动对接（一般为 Issue 中包括手机操作系统和 BUG 的提交、分析等自动化匹配操作）导致的，有些 Issue 中关键 Bug 原因不明确，机器人会自动添加评论，提供更多信息，所以会出现一次一个 Issue 占用 10G 的情况。

4、Jira 系统 Full GC 问题

无论是 Server 版还是数据中心版，Full GC 都是困扰我们的问题，相信大家也会遇到。虽然数据中心版保证了用户端的高可用性，但从后台运维角度来看，有时候某个节点还是会有问题，Jira 某个节点会不定时的出现 Full GC，大概的无响应的时间是几秒到几分钟。我们做了一系列的排查，最终的目标是降低成本、提高质量，不能无限制扩容服务器数量，所以我们抓取了占用 jvm 内存最多的人和进程。

可以看到，某用户做了 2620 的看板操作，并使用了大量内存。联系用户进行优化 2620 看板对应的 JQL，缩小范围，其中包括增加经办人、日期、Issue 状态的条件，避免对整个项目进行排序。因为一个项目有百万 Issue 时，再排序直接就停止响应。最后是系统管理员自行删除。

如何实现不间断提供服务

对于超大 Jira 系统，这里有几个建议，也是我们的日常做法。

1. 多使用 webhooks 功能，实现主动推送变更数据到业务系统，这样能实现实施的功能，也能满足业务需求。

2. 多多提交问题和想法让龙智或官方解决，我们提交的问题比较多，包括 Jira 的一些功能优化，也经常和官方沟通。

3. 一定要有研发能力，实现 top 级问题用户自助解决。

4. 一定要配备专门人员或龙智驻场，因为如果不太懂 Jira 的人员进行操作，一不小心就会影响全局。

5. 项目版本和模块数量一定不能过百，不然在项目中新建问题会很慢。

6. 一定要针对数量 top 级项目约定好使用规范。

给大家分享一下我们的 Jira 系统中 JFR 相关的设置、集群互斥锁和 GC 参数。

我们内部比较关心成本、效率和质量。我们使用 Jira，但 Jira 很庞大，对于 SRE 来说肯定需要研发一些自助系统来辅助 Jira。

成本方面，我们会自动禁用账号，在职用户 60 天不登录系统，我们就会清理掉他账号的系统权限，自动收回授权。还有部门人员分布统计，用来解决成本分摊问题。还有 license 授权告警，假如我们一共买了 10 个 license，假如用户数超过了 8 个，我们就会有收到报警，不会等到超额才发现。

效率方面，因为入职员工比较多，好多用户让我们查询问题，我们一个人是无法面对将近 2 万的用户的。怎么办？开发一个系统让用户自己去查，角色权限增删和项目 ID 等等也交给用户自助解决。

质量方面，举个例子，我们内部称之为“地雷”看板，它是一个计划任务，大约每 30 秒检测一次，自动去数据库检查危险的 filter，如果检测到会进行自动删除，确保系统稳定。

Jira 监控

我们内部都是使用 Falcon 监控，并增加了 jmx 监控。对于某个节点出现无响应这种 P0 报警，会通过电话和飞书通知。日常报警例如 CPU 增高等由飞书直接推送普通消息。

有几个核心指标，他们会影响到整体服务。其中，最重要的是 RMI 错误数和 GC 情况。

日常使用技巧

这里讲到的使用技巧，技术层面的偏多。

首先是建议写好日常问题知识库和用户指南。

其次是多利用系统公告栏和用户群公告。

第三，也是最关键的一点，因为现在小品牌插件较多，这些插件可能经过了 Jira 官方的高性能测试，但在日常使用过程中，你不能过于信任这些插件，试用插件前一定做好性能测试。因为我们发现 Jira 本身性能非常强，但用了某些插件后会逐步很慢，所以要减少对插件的依赖。

第四，是为了避免系统过于庞大，多利用归档功能。

第五，建议大家使用 ScriptRunner 等脚本插件，可以实现批量增加字段和字段值更改等便捷功能。

第六，这里强调一点，我们内部也会针对一些日常反复出现的问题进行集中讲解培训。除了把自研系统做好以外，我们也会不定期开展培训。我们主要找到龙智为我们提供培训服务，培训内容包括 Jira 服务方法和最佳实践。我们会在内网上发起报名，可以观看直播、录屏，也可以现场学习。我们的录屏也是放在 Jira 中让用户自行观看。集中培训为我们解决了难题，提升了工作效率。

未来，我们要做的事情很多，针对可用性挑战、业务侧连续性要求，我们都会和官方、龙智共同商讨解决方案，也会及时升级到新的长期版本，我们新的优化问题已经在官方版本 9 上得到了解决，未来我们也会持续投入。

以上是我分享的内容，谢谢大家。