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系统，这里有几个建议，也是我们的日常做法。

多使用webhooks功能，实现主动推送变更数据到业务系统，这样能实现实施的功能，也能满足业务需求。多多提交问题和想法让龙智或官方解决，我们提交的问题比较多，包括Jira的一些功能优化，也经常和官方沟通。一定要有研发能力，实现top级问题用户自助解决。一定要配备专门人员或龙智驻场，因为如果不太懂Jira的人员进行操作，一不小心就会影响全局。项目版本和模块数量一定不能过百，不然在项目中新建问题会很慢。一定要针对数量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上得到了解决，未来我们也会持续投入。

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