共计 4866 个字符，预计需要花费 13 分钟才能阅读完成。
2023 年 4 月 14 日，Atlassian 中国合作伙伴企业日·上海站圆满闭幕。作为 Atlassian 寰球白金合作伙伴、云业余搭档，龙智参加了此次流动，并邀请小米团体信息技术部 SRE 薛世英作为演讲嘉宾，分享了小米公司的 Jira 实战经验。
以“小米团体 Jira 实战：如何在高负载状态下放弃 Jira 性能与运行稳固”为主题，薛世英深刻介绍了小米成功实践万人规模 Jira 迁徙的教训，并分享了如何优化 Jira，如何依据用户需要实现性能的扩大，如何实现不间断提供服务，以及一些 Jira 日常应用技巧，为大家提供实际参考。
▽ 点击此处观看回放视频
https://www.bilibili.com/video/BV1PM4y1a7dH/?aid=910269250&ci…
以下是局部文字实录（有删改润色）：
各位下午好，我是来自小米公司的薛世英，明天受龙智邀请来解说小米 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 上失去了解决，将来咱们也会继续投入。
以上是我分享的内容，谢谢大家。
