1. 项目概述与部署思路1.1 为什么要搭一套Test环境的JiraJira这个名字做研发管理的同学应该都不陌生。它号称是“软件开发团队的瑞士军刀”从需求收集、任务拆解、迭代规划到缺陷跟踪几乎所有研发协作环节都能管起来。很多公司把它用作核心的研发管理平台日常的工单流转、Sprint安排、版本发布记录全都跑在上面。但问题也恰恰出在这里——因为它太核心了所以不能随便动。你不可能在正式环境上试升级、测插件、验证工作流脚本。一旦出了问题影响的可是全团队每天的协作节奏甚至可能导致项目进度失控。而Test环境的Jira就是用来干这些“脏活累活”的。我自己在搭这套环境的时候核心目的有三个第一验证版本升级路径。在正式环境升级前先在Test环境完整走一遍升级流程确认数据迁移没问题、插件兼容性正常心里才有底。第二测试插件和二次开发逻辑。Jira的价值很大一部分靠生态插件撑起来很多插件在正式环境里不敢轻易启用必须先在Test环境跑通了确认没有性能抖动、没有数据异常才敢上正式环境。第三给新人练手和做流程测试。新来的测试同学或项目经理需要有个环境去熟悉Jira的配置逻辑总不能在正式环境里随便改工作流和权限方案。所以这套环境虽然挂了个Test的名字但它的配置思路、性能要求、数据安全性一点都不能糊弄。1.2 这次部署的整体技术选型Jira的部署方式常见的有三种Server版自托管单机、Data Center版集群部署、Cloud版供应商托管。对于Test环境来说Cloud版虽然省事但很多企业因为数据合规或者网络隔离的原因根本不让把数据放到外部Data Center版功能很强悍但那是给大规模团队准备的Test环境用纯属浪费授权和服务器资源。所以最合理的选择是Server版自托管。这次我采用的具体方案是操作系统LinuxCentOS 7.x环境数据库MySQL 8.0Java运行环境OpenJDK 11Atlassian Jira版本8.x系列8.20以上版本为什么这么选后面我在每一节里结合具体操作详细说。这里先强调一个核心理念Test环境的部署逻辑和正式环境应当保持一致唯一的差别是规模和数据量。如果你在Test环境里随便装个最简单的方式那测出来的结论跟正式环境根本没有可比性这套环境的价值就大打折扣了。2. 安装包选择与版本决策2.1 版本选择的两条经验法则选哪个版本的Jira是我觉得这次配置里第一个值得认真思考的问题。很多人习惯直接装最新版但在企业环境里最新版不一定是最优解。我总结了两条经验法则第一条看生态兼容性。Jira本身功能是固定的但它真正用起来顺不顺手很大程度上取决于你装了什么插件。装最新版Jira容易但你常用的那些插件很可能还没适配最新版或者只能在对应的某些版本上稳定运行。所以选版本前先去查一下核心插件的兼容矩阵这比看Jira自己的帮助文档更重要。第二条考虑迁移路径。企业里不会有哪个环境是永远不升级的。Test环境最好选择当前正式环境同一大版本的最新小版本这样既能验证升级路径又不会因为版本跨度过大导致数据迁移时出现意料之外的兼容问题。如果正式环境是7.x你直接装个9.x回来测迁移测试的结果参考意义就有限了。这次模拟项目里我选择的是8.20版本这个版本在稳定性、功能完整度和插件兼容性之间取得了比较平衡的状态。2.2 安装包格式的选择逻辑Jira官方提供的安装包主要有两种格式.binLinux installer和.tar.gz手动解压版。.bin安装包是一个图形化的引导程序它会自动检测系统环境、创建服务、配置启动脚本整个流程比较傻瓜化。这种方式的优点是省心缺点是它会在系统里安放很多你不可控的配置文件一旦想自定义位置或者深度调优反而有些碍事。.tar.gz解压版则是“everything is a file”的思路——所有内容都集中在一个目录下启动方式是自己控制脚本配置文件、日志、程序文件都可以随意安放。对于做Test环境我个人更推荐这种方式。原因有三点方便多实例共存。同一台测试服务器上可能同时需要跑Jira 8.5和Jira 8.20两个实例来做对比测试.tar.gz解压版天然支持这种场景。方便整体备份和迁移。整个目录打包拷走就能在另一台机器上恢复这对Test环境的快速重建非常有价值。方便排查问题。出问题时可以直接查看脚本、修改启动参数不用去和各种安装生成的系统配置纠缠。不过如果你对Linux运维不太熟悉第一次部署建议还是用.bin安装器省去手动配置环境变量的麻烦。两种方式最终的产物是一样的只是管理方式有差别。2.3 配套环境的版本匹配Jira对运行环境有一定要求这里给出我实测可行的搭配组合组件推荐配置说明操作系统CentOS 7.x / Ubuntu 18.04内核参数差异影响不大但要保证磁盘空间充足JavaOpenJDK 11 x648.20版本的Jira绑定的Java版本不要用Java 8也不要贸然上Java 17MySQL5.7或8.0需要配置InnoDB引擎和utf8mb4字符集内存最低4GB建议8GBJira本身是Java应用JVM堆内存直接决定响应速度磁盘建议50GB以上安装目录、数据目录、数据库要分开存放这里有一个很关键的细节Jira的版本和Java版本是绑定的关系。装错Java版本会导致启动直接失败而且报错信息有时候很隐晦让人摸不着头脑。我见过很多人在这一步卡壳其实只要严格对照官方兼容矩阵就不会出问题。3. 安装前的环境准备3.1 系统环境初始化安装Jira之前建议先把操作系统层面的准备工作做扎实。很多时候Jira后面出现的诡异问题根源不在Jira本身而是操作系统的基础配置没做好。第一件事确认服务器的时区和时间同步。Jira对时间非常敏感工单的创建时间、更新日志、Sprint的时间窗口全都依赖准确的时间。如果服务器的时区设置错误所有的时间显示都会偏离排查起来极其痛苦。统一使用东八区并配置好NTP自动同步这一步看似简单却能省掉后面无数麻烦。第二件事调整系统文件描述符限制。Jira运行时会打开大量文件句柄尤其是附件上传、日志写入频繁的时候。默认的1024限制根本不够用会在高负载时报出“Too many open files”的错误。这属于典型的“测试环境不会出错但正式迁移后立刻暴露”的问题。这次配置时把/etc/security/limits.conf里的nofile限制调整到了65535。第三件事关闭防火墙或明确放行端口。Jira默认使用8080端口HTTP和8443端口HTTPS如果开启了系统防火墙记得放行对应端口。我知道有同学在本地测试时为了避免麻烦直接把防火墙关了这在小范围测试环境里可以接受但如果要长期运行还是建议按最小权限原则放行端口。3.2 创建专用的运行用户这是一个非常重要的安全习惯不要用root用户直接运行Jira。Jira是一个Web服务如果以root身份运行一旦应用出现远程代码执行之类的漏洞攻击者直接获得的就是服务器最高权限。这个问题在Test环境里容易被忽略因为内网测试环境暴露面小很多人图省事就用root了。但规范的习惯应该是创建专用的低权限用户只给它需要的最小目录访问权。# 创建名为jira的系统用户指定家目录为/opt/jira useradd -m -d /opt/jira -s /bin/bash jira后续Jira的程序文件、数据文件都放在这个用户的家目录下所有需要写入的目录归属这个用户。这样即使应用被攻破攻击者拿到的权限也被限制在一个普通用户级别不至于瞬间拿下整个服务器。3.3 部署目录规划目录规划这件事看起来是个小事但决定了后续维护的顺手程度。我第一次部署Jira的时候就吃了目录混乱的亏程序文件、数据文件、日志散落在各处排查问题时要来回切换目录效率很低。这次我采用的目录规划如下/opt/jira/ ├── app # Jira程序主目录解压后的安装文件 ├── data # Jira的Home数据目录 ├── archives # 备份文件存放目录 └── logs # 汇总日志目录这里的核心逻辑是把“程序”和“数据”分离。程序目录可以随时删除重建数据目录则必须稳定保留。Jira的Home目录也就是上面的data目录承载着所有项目配置、工单数据、插件状态是这套系统的“大脑”迁移备份时它是绝对的核心。另外Jira的启动脚本里有个参数叫JIRA_HOME它指向的就是数据目录。安装完成后第一件事就是确认这个参数指向正确位置否则Jira会把数据目录默认创建在程序目录内部一旦程序升级或者目录被替换数据就跟着没了。4. 完整安装实操过程4.1 安装JDK环境与配置Java是Jira的运行基础这一步虽然基础但很关键。我直接使用OpenJDK 11因为它完全满足了8.20版本的运行需求同时又比Oracle JDK省去了繁琐的授权管理。# 使用包管理器安装OpenJDK 11 yum install -y java-11-openjdk-devel # 验证安装版本 java -version安装完成后还需要配置一个容易被忽视的环境变量JAVA_HOME。虽然有些版本的Jira启动脚本能自动探测Java路径但手动指定是最稳妥的。# 编辑/etc/profile在末尾追加 export JAVA_HOME/usr/lib/jvm/java-11-openjdk export PATH$PATH:$JAVA_HOME/bin # 使环境变量立即生效 source /etc/profile这里分享一个小细节Jira的启动脚本start-jira.sh里会去找Java命令如果找不到或者找到的版本不对会直接报错启动失败。所以在执行启动前一定要确认当前用户在执行which java时能正确找到路径。4.2 解压安装与目录授权拿到.tar.gz安装包后解压和授权是连着的两步缺一不可。# 切换到jira用户 su - jira # 解压安装包到app目录 mkdir -p /opt/jira/app tar -zxvf atlassian-jira-software-8.20.0.tar.gz -C /opt/jira/app # 创建数据目录 mkdir -p /opt/jira/data # 确保目录归属jira用户 chown -R jira:jira /opt/jira授权这一步很容易被忽略。如果用root解压的文件目录jira用户启动时根本没有写入权限会直接报权限不足的错误。我习惯的做法是解压和授权一气呵成做完避免后面启动时再手忙脚乱。4.3 数据库初始化与连接配置Jira支持内置的H2数据库但那个只适合安装后立即体验一下功能不适合作为正式的运行数据库。H2是嵌入式数据库功能有限并发能力差数据备份也不方便所以这次配置我直接选择了MySQL 8.0。在MySQL中创建Jira所需的数据库和账号-- 使用root账号登录MySQL后执行 CREATE DATABASE jiradb CHARACTER SET utf8mb4 COLLATE utf8mb4_bin; CREATE USER jirauser% IDENTIFIED BY 你的强密码; GRANT ALL PRIVILEGES ON jiradb.* TO jirauser%; FLUSH PRIVILEGES;这里有两个细节需要注意字符集问题。Jira的工单内容常常包含中文、日文等多语言字符如果数据库默认字符集不是utf8mb4会出现乱码问题。更严重的是有些情况下数据写进去了但排序、索引行为异常排查起来比乱码更让人头疼。所以建库时统一指定utf8mb4是最保险的做法。数据库连接驱动问题。Jira 8.20连接MySQL 8.0时需要在JIRA_HOME目录中放置对应的JDBC驱动。Jira本身自带了一些旧版驱动但不一定兼容MySQL 8.0的认证方式。把mysql-connector-java-8.x.jar放到/opt/jira/data/lib目录下Jira启动时会自动加载这个外部驱动替换掉自带的旧驱动。Jira首次启动后会在浏览器里弹出配置向导其中数据库连接的页面会要求填写Host、端口、数据库名、用户名和密码。这里填写的就是我们刚才创建的jiradb数据库和jirauser账号。4.4 启动与首次访问验证配置完成数据库连接后Jira会自动开始初始化表结构。这个过程是自动的一般会持续几分钟期间会有进度条显示。如果在这一步卡住或者报错大多数情况都和数据库连接配置有关常见的原因有数据库权限不足、连接驱动版本不对、数据库字符集不匹配。初始化完成后系统会要求设置管理员账号并输入许可证密钥。Test环境没有采购正式许可证的话可以申请一个试用许可证有效期通常为30天。这个时间足够验证功能和流程了。这里我强烈建议在Test环境里设置一个独立的管理员账号不要复制正式环境的用户名。原因很简单Test环境会频繁做各种破坏性测试导入导出、恢复备份、删除项目等独立的账号可以随时重置不影响正式环境的账号体系。5. 初始化配置与核心功能设置5.1 系统全局配置项清单Jira安装完成后进入系统管理界面第一眼看到的就是各种配置项。这里我按重要程度排一个优先级方便大家上手时有个清晰的落点。系统设置里最优先处理的是“系统通知邮箱”。Jira会发送大量邮件通知——工单分配、评论回复、状态变更提醒全都依赖邮箱系统。如果邮件没有配置好整个团队的协作效率会大打折扣。SMTP服务可以用企业已有的邮箱服务关键是配置账号、加密方式、端口这三个参数要对应正确。其次是“附件存储配置”。Jira默认把附件存储在Home目录下的data/attachments里如果磁盘空间不充裕最好调整到单独的磁盘分区。附件目录的增长速度往往超出预期尤其是团队习惯在工单里贴截图的话几个月就能积累好几个GB。还有“许可信息”和“插件管理”。确认试用许可的到期时间规划插件安装策略。插件建议遵循“必需的才装”原则每多一个插件升级和数据迁移时就会多一分变数。Test环境更应该克制只装那些你真正需要验证的插件。5.2 项目数据导入与结构配置安装好Jira的壳子之后最重要的事情是往里面导入真实结构。如果是全新的Test环境还要创建项目、配置工作流、设置权限方案。一个比较省力的方式是使用Jira官方提供的数据迁移工具直接从正式环境生成一个备份包然后在Test环境恢复。这种方式效率最高几分钟内就能把正式环境的所有项目、工作流、字段配置、用户权限结构完整复制过来。Test环境的目的本来就是做迁移演练这个过程本身就很有价值。如果是从零开始配置则需要按以下顺序操作第一创建项目。Jira的项目类型主要分为三种Scrum软件开发项目、看板项目管理项目和业务流程管理项目。Test环境里通常需要分别创建一个验证。第二配置工作流。工作流是Jira的灵魂定义了工单从创建到关闭的所有状态流转。比如一个标准的“缺陷修复”流程包含“待确认-进行中-已修复-待验证-已关闭”这几个状态。新建工作流时重点检查“转换规则”里的条件设置和“后处理功能”很多权限问题都出在这一层。第三设置权限方案。Jira的权限体系非常细分为项目权限和全局权限两层。项目权限包括“创建工单”、“编辑工单”、“关闭工单”、“移动工单”、“处理工单”等一个常见的坑是项目管理员发现用户无法操作排查半天发现是权限方案关联错误。5.3 管理账户与安全策略Test环境的账户管理可以比正式环境放松但最小权限的原则不能丢。建议创建两类测试账号一类是模拟普通开发人员的账号只赋予“处理工单”的基本权限另一类是模拟项目经理的账号拥有项目管理和配置的权限。这样做的目的很直接后期做权限模型验证时可以用这两个账号完整模拟实际工作场景。如果你在Test环境里直接用管理员账号做所有操作那永远不会发现正式环境中普通用户遇到的权限问题。安全策略方面密码复杂度策略在Test环境可以适当放宽但管理员账号的密码必须单独设置并妥善保管。考虑到这套环境可能会承载迁移数据的备份其中可能包含正式环境的敏感信息所以安全这根弦不能松。6. 常见问题排查与避坑实录6.1 启动失败与端口占用问题安装配置过程中我遇到的第一类问题集中在启动阶段。这里把高频问题和解决方案整理成了一张速查表问题现象可能原因解决方案启动脚本找不到JavaJAVA_HOME未配置手动export JAVA_HOME并确认指向JDK11启动后立即退出无提示数据目录权限不足chown -R jira:jira 数据目录访问8080端口无响应防火墙拦截放行8080端口或关闭firewalld启动时报端口被占用已有一个Jira实例在运行检查进程占用netstat -tlnp数据库连接页面报错JDBC驱动不匹配将mysql-connector-java-8.x.jar放入Home/lib目录值得一提的是Jira的启动日志位置比较隐蔽默认在Home目录下的log/atlassian-jira.log。这个日志文件的信息量非常大几乎所有的启动问题都能在这里找到根因。很多人启动失败后到处百度其实最应该做的第一件事就是打开这个日志文件看最后几十行的错误信息。6.2 内存配置与性能优化心得Jira的内存配置是Test环境里容易被忽略但影响极大的环节。Jira作为Java写的应用它的JVM堆内存设置直接决定了系统的响应速度和稳定性。默认配置比较保守通常只有1GB左右这个容量在正式环境下明显不够。修改方式是在JIRA_HOME目录下的setenv.sh或bin/setenv.sh文件中调整JVM_MINIMUM_MEMORY和JVM_MAXIMUM_MEMORY参数。JVM_MINIMUM_MEMORY2048m JVM_MAXIMUM_MEMORY4096m内存设置有一个经验法则生产环境和Test环境的物理内存如果相同JVM堆内存可以设置成相同的数量级如果Test环境的物理内存只有正式环境的一半那么堆内存就设置为正式环境的一半即可。还有一点很多人不知道Jira需要的是JVM堆内存但操作系统还需要给缓存留出空间。如果服务器物理内存8GB把堆内存直接顶到6GB很容易触发操作系统的OOM机制导致整个服务被强制杀死。我建议堆内存最大值不超过物理内存的60%-70%剩余空间留给操作系统缓存和Jira自身的元空间。6.3 备份与恢复的完整流程备份这个问题是Test环境搭建中我认为最不能偷懒的环节。很多人觉得测试环境丢了就重装没必要备份。这个思路在纯功能测试场景下勉强能接受但如果Test环境里备份了正式数据或运行了升级演练丢了重装就意味着整个测试周期要重新来一遍代价完全不同。Jira备份有三个层次数据库备份、Home目录备份、附件目录备份。数据库是结构化数据的核心Home目录包含配置文件、插件附件目录则是所有上传的文件实体。# 数据库备份使用mysqldump mysqldump -uroot -p jiradb /opt/jira/archives/jiradb_$(date %F).sql # Home目录备份 tar -czf /opt/jira/archives/jira_home_$(date %F).tar.gz -C /opt/jira data # 附件目录备份 tar -czf /opt/jira/archives/attachments_$(date %F).tar.gz -C /opt/jira/data attachments恢复的时候就反过来先恢复数据库再解压Home目录最后恢复附件。顺序不能乱如果先恢复了附件再恢复数据库会导致附件记录和数据库索引不同步工单里的附件链接会出现404。我的实操习惯是Test环境每周做一次全量备份在关键操作比如升级插件、变更工作流前后额外手动备份一次。这样一旦操作失误可以做到10分钟内回滚到之前的状态。6.4 反向代理访问配置前面我们一直直接用IP访问8080端口这在Intranet环境下已经没有问题。但如果整个团队习惯通过域名访问就需要配置反向代理。Jira官方推荐用Apache或Nginx作为反向代理把请求转发到本机的8080端口。用Nginx的配置比较简单server { listen 80; server_name jira.test.internal; client_max_body_size 1024M; location / { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } }配置完反代后还要在Jira的“系统管理-常规配置”里把“基础URL”改成对应的域名地址。如果没有改这一步Jira生成的邮件通知和Webhook链接都会带着IP和8080端口用户点开链接会直接访问到未经过反代的原始地址。这一点看似是个小配置却是我踩过的最大坑之一。曾经因为在反代后没有同步修改基础URL导致所有用户收到的邮件通知里的链接都打不开花了大半天才定位到问题根源。6.5 插件兼容性风险清单Test环境里验证插件的兼容性可以说是搭建这套环境的核心任务之一。下面列几个我实际遇到过的兼容性问题供大家参照第一某些工单报表类插件在Jira大版本升级后会失效因为底层数据存储结构变了插件没有及时适配就会报“找不到数据源”的错误。第二部分免费的插件更新不及时在试用期内的功能看起来很正常但授权到期或版本变更有可能会引发数据定义的异常。第三工作流自带的脚本插件比如ScriptRunner在不同版本间的语法有些微差异升级后可能遇到脚本执行失败的情况。所以Test环境里一旦决定用某个插件就要固定版本不要轻易跟随Jira自动升级。我自己在Test环境验证插件时遵循的顺序是备份数据、记录当前插件清单、在Test环境升级插件、完整跑一遍关键流程创建工单、编辑工单、关闭工单、生成报表、确认没有异常后再在正式环境执行同样操作。7. 环境验收与日常维护建议7.1 功能验收清单一台Jira服务器装完到底算不算“配好了”我习惯用一张清单来验收能够使用管理员账号和普通用户账号正常登录能够创建Scrum项目和看板项目能够创建、编辑、分配、关闭工单并正确触发工作流转换邮件通知能够在工单状态变更时自动发出附件上传和下载功能正常中英文文件名都无乱码权限配置有效普通用户无法越权操作每周备份流程能够正常执行且数据可恢复发版时可以在10分钟内回滚到备份点每一项都用真实流程过一遍不走过场。尤其是恢复演练不能只看备份命令跑成功了就默认恢复没问题必须实际恢复一次确认数据完整、附件可用这才是整套环境真正可用的证明。7.2 日常巡检的建议节奏Test环境装好后不是放着不管它也承载着重要任务。我个人的巡检节奏是每天看一次系统日志中有没有ERROR级别的记录每周检查一次磁盘空间和数据库大小每月做一次完整的备份恢复演练确认备份链路通畅。磁盘空间是我在Jira运维中最常遇到的隐形杀手。日志文件、附件目录、数据库binlog三个大头任何一个爆了都会导致服务不可用。Test环境的服务器往往磁盘空间预留不足所以这个巡检点不能省略。7.3 从Test到生产的迁移要点最后聊一下这套环境产出的成果怎么用到正式环境。Test环境验证通过的配置要形成一份《配置变更记录》把改了哪些参数、装了哪些插件、验证过哪些场景都记清楚。这份记录的价值绝不低于环境本身。因为以后任何时候需要回溯“某个配置为什么这么改”答案都在记录里。正式环境做同样变更时严格对照这份记录执行然后再在Test环境重新恢复一次正式环境的最新备份把两套环境的配置拉齐避免漂移。我在实际项目里体会最深的是Test环境最大的价值不是“装了Jira”而是“通过这个Jira你能放心地把正式环境也管理好”。配置同步到正式环境后长期积累下来的操作习惯、备份机制、问题排查经验才是真正降低团队风险护城河的部分。这套环境跑得越久它的成本就越摊越薄而它的价值却越叠越厚。