企业官网建设流程全解析

做 CI 的人大概都遇到过这种尴尬：任务明明在同一个 Jenkins 上跑，A 团队能点构建，B 团队点进去就是"你无权访问"；或者反过来，所有人都能看见所有人的任务，构建记录里的参数、日志里的地址全暴露着。我在上一家公司接手 Jenkins 时，第一件事就是把默认的"登录用户全权限"改成基于角色的授权，用的就是 Role-based Authorization Strategy 这个插件。它解决的核心问题很直白：让"视图"和"任务"这对组合，从"全开放"变成"按团队、按项目前缀、按人"精确到按钮级的控制。

如果你现在的 Jenkins 是十几个人共用、几十上百个任务堆在仪表盘上，这个插件基本是绕不开的。它适合三类人：一是刚开始搭 Jenkins、还没定权限模型的运维或 DevOps；二是已经被矩阵授权折磨得不想再挨个任务勾权限的人；三是需要给外包、测试、审计这类角色开只读权限的团队。下面我把从安装、切换策略、设计角色、正则匹配任务，到批量维护和排错的整套流程摊开讲，中间踩过的坑会重点标出来。

1. 先想清楚：视图从来都不是权限边界

1.1 矩阵授权在人多之后必然失控

Jenkins 自带的"项目矩阵授权策略"是很多人的第一选择，因为它直观：一张大表格，纵轴是人，横轴是权限，勾勾点点就完事。人少的时候确实够用，三五个人的小团队，谁要看什么勾一下就行。但只要团队超过十个人、任务超过五十个，这张表就会膨胀成一个没法维护的怪物。新来一个同事，你得在几十行里找到他，然后从几十列里挑出他该有的那几项，还得保证跟他同组的人勾的完全一致——只要有一次手抖多勾了Job/Configure，就等于把整个任务的配置权限给出去了，连带着可以改构建脚本、改凭据引用、改触发器。

更麻烦的是人走人留。有人离职时你忘记清权限，他的账号只要还在，就依然能读所有任务的日志。而矩阵授权里没有任何"按项目分组"的概念，你要么逐个任务改，要么推倒重来。这套模型的设计前提是"任务数量少、人员流动小"，跟现在动辄几百流水线的场景完全不匹配。

Role-based Authorization Strategy 换了个思路：不再关心"某个人对某个任务有没有权限"，而是先定义"一类角色的权限集合"，再让"人"和"任务前缀"分别去匹配角色。人是变量，角色是模板，任务名是索引。这样一来，加人只需要在 Assign Roles 里加一行用户 ID，加任务只要命名遵守规范就自动被角色覆盖，维护成本从 O(人 × 任务) 降到 O(角色)。

1.2 插件里的四种角色，各管一段

装上插件后，Manage and Assign Roles 页面里会分三块：Manage Roles、Assign Roles，以及角色类型的选择。很多人第一眼会懵，因为"角色"在这里不是一个概念，而是四条互不干扰的线：

• Global roles（全局角色）：管的是整个实例层面的权限，比如Overall/Read、Overall/Administer、Overall/SystemRead，以及所有跟视图相关的权限View/Read、View/Create、View/Configure、View/Delete。注意，视图权限只在这里出现，这是后面所有"视图怎么授权"问题的答案。
• Item roles（项目角色）：管的是任务和文件夹，靠一个正则表达式（Pattern）去匹配任务的全名，权限包括Job/Read、Job/Build、Job/Configure、Job/Create、Job/Delete、Job/Cancel、Job/Workspace，以及构建记录相关的Run/Replay、Run/Delete、Run/Update。
• Node roles（节点角色）：匹配 Agent 的节点名，控制谁能连节点、谁能在节点上跑构建，权限是Agent/Build、Agent/Connect、Agent/Disconnect、Agent/Configure。
• Credentials roles（凭据角色）：控制谁能看凭据列表、谁能管理凭据域，权限是Credentials/View和Credentials/ManageDomains。

搞清楚这四条线之后，"我要让 A 团队只能构建自己的任务"这句话就能翻译成可执行的动作：建一个 Global 角色给Overall/Read和View/Read，再建一个 Item 角色，Pattern 写^team-a-.*，权限勾Job/Read、Job/Build、Job/Cancel，最后把 A 团队的人分到这个 Item 角色上。

1.3 视图可见性和任务可见性是两套逻辑

这是我见过最多人绕不过去的弯。标题里说"管理视图任务权限"，很多人第一反应是"能不能给某个视图单独授权，让 A 团队只能看 A 视图"。答案是：这个插件做不到"按视图授权"，视图的权限是全局粒度的。

那视图到底怎么起作用？分两层看。第一层，视图本身可不可见，取决于用户有没有全局的View/Read。没有这个权限，连视图标签页都看不到；有了，就能看到所有视图的标签（但视图里的任务仍受任务权限过滤）。第二层，进入视图之后能看到哪些任务，完全取决于 Item 角色的正则有没有匹配上这个任务名。换句话说，视图只是个"展示容器"，真正卡权限的是任务名的正则匹配。

所以正确的做法是：用任务命名前缀建立权限边界，用视图建立使用体验。比如所有 A 团队的任务都叫team-a-xxx，正则^team-a-.*天然就是权限边界；同时建一个名为"团队A视图"的列表视图，正则也用^team-a-.*，让 A 团队登录后第一眼看到的就是自己的任务。两套正则保持一致，视图和权限就不会错位。如果你反过来，先建了一堆视图再想按视图授权，一定会掉进坑里。

顺便提醒一个常见误解：有人觉得"不给View/Create用户就看不到任何视图了"，其实不是。View/Create控制的是"能不能新建视图"，跟"能否查看已有视图"是两回事，后者由View/Read决定。

2. 插件安装与授权策略切换，顺序错了会把自己锁在门外

2.1 安装：在线和离线两条路

在线环境下最省事，系统管理 → 插件管理 → 可选插件，搜Role-based Authorization Strategy直接装，装完重启。插件 ID 是role-strategy，如果要用命令行方式：

# 前提是已配置好 update center（内网可用 Nexus 或本地镜像代理） java -jar jenkins-cli.jar -s http://localhost:8080/ -auth admin:token install-plugin role-strategy -deploy

内网离线环境就得手动来。下载role-strategy.hpi，放到$JENKINS_HOME/plugins/目录下，然后重启。这里有个必须注意的点：只放 .hpi 文件是不够的，重启后 Jenkins 可能会因为依赖缺失而把插件标记为失败。role-strategy 依赖matrix-auth之类的插件，离线装之前先看一眼插件页面上的 Dependencies 列表，把这些依赖一起下下来放进去。我踩过一次，只丢了主插件，重启后插件管理页面显示一片红，最后只能删掉目录重新来。

版本选择上，3.x 版本和老版本最大的差异是 Java 包名变了：老版本是com.michelin.cio.hudson.plugins.rolestrategy，新版是org.jenkinsci.plugins.rolestrategy。这个差异平时用界面没感觉，但等你写 Groovy 脚本批量建角色的时候，import写错了就会直接报 ClassNotFoundException。升级插件之前，先把你手上所有脚本里的包名对一遍，这是升级前必做的一件事。

2.2 切换策略的正确顺序

很多人装完插件就直接去全局安全配置里把授权策略改成 Role-Based Strategy，然后发现自己进不去任何页面了。原因很简单：策略切过去的那一刻，当前的授权规则全被清空，而新策略里还没有任何角色和用户绑定，包括你自己的管理员角色。

正确的顺序是"先建后切"：

1. 进入系统管理 → Manage and Assign Roles → Manage Roles，此时页面还是按旧的授权策略运行的，但角色数据可以先写好。
2. 在 Global roles 里加一个jenkins-admin，勾全Overall/Administer，保存。
3. 在Assign Roles里把这个全局角色分配给当前的管理员账号（以及至少一个备用管理员账号）。
4. 回到全局安全配置，授权策略选Role-Based Strategy，保存。
5. 刷新页面，确认自己还能进系统管理。

如果你已经切换了怎么办？两条路：一是如果还能登录只是权限不足，用另一个Overall/Administer的账号去补；二是彻底锁死，就得改文件——这部分下面单独说。

2.3 锁死之后的救援方案

Jenkins 的授权策略持久化在$JENKINS_HOME/config.xml里，找到这一段：

<authorizationStrategy class="org.jenkinsci.plugins.rolestrategy.RoleBasedAuthorizationStrategy"> <roleMap type="globalRoles">...</roleMap> <roleMap type="projectRoles">...</roleMap> </authorizationStrategy>

救援步骤：先停掉 Jenkins 服务，备份config.xml，然后把整个authorizationStrategy节点替换成"登录即全权"的策略：

<authorizationStrategy class="hudson.security.FullControlOnceLoggedInAuthorizationStrategy"> <denyAnonymousReadAccess>true</denyAnonymousReadAccess> </authorizationStrategy>

保存后启动，用管理员账号登进去，重新按正常顺序配置角色，再切回 Role-Based Strategy。这个操作我建议只在维护窗口做，因为改 config.xml 属于"绕开所有权限"的操作，期间任何能访问到实例的人都可能拿到管理权限，做完立刻切回来。

提示：改 config.xml 之前一定要先备份，尤其是文件里有中文注释或自定义节点时，手工编辑很容易破坏 XML 结构，导致 Jenkins 启动失败。

顺带说一句，如果你用的是容器化部署，$JENKINS_HOME通常是挂载出来的卷，直接在宿主机上编辑文件、docker restart即可，不需要进容器。但要注意容器的文件属主，编辑后可能因为权限问题让 Jenkins 读不到，chown一下更稳。

3. 角色和 Pattern 的设计，决定了这套权限能不能长期活下去

3.1 Pattern 是正则，不是通配符

这是新手最容易翻车的地方。Manage Roles 里的 Pattern 字段用的是 Java 正则表达式，不是*这种通配符。你写team-a*，它不会匹配team-a-build，因为a*在正则里表示"零个或多个 a"。想匹配前缀，必须写^team-a-.*。

拆开看：^表示从字符串开头匹配，team-a-是字面量，.*表示任意字符重复零到多次。三个部分合起来才是"以 team-a- 开头的所有任务"。如果你只写team-a.*，虽然大多数情况下也能匹配上，但严格来说它允许前面有任何字符吗？不是，team-a.*要求字符串开头就是team-a，因为没有^时 Java 的matches语义仍是从头匹配，但为了可读性和后续维护（比如复制到其他地方用），我建议一律带上^。

匹配的对象是任务的全名，包含文件夹路径。比如任务在team-a/dev/build这个文件夹下，它的全名就是team-a/dev/build，正则需要写成^team-a/.*才能覆盖整个文件夹下的所有任务。这一点在做文件夹隔离时特别有用——用文件夹插件把每个团队的任务装进各自的文件夹，Pattern 直接匹配文件夹名，比匹配任务名前缀更干净。

还有两个细节：正则是区分大小写的，Team-A和team-a是两回事；任务名里如果含有正则特殊字符（比如.、+、(、[），必须转义。我见过一个团队的流水线叫service.a-backend，Pattern 写成^service.a-.*，结果那个.匹配了任意字符，把serviceXa-开头的任务也放进去了。虽然概率低，但属于隐性风险，写^service\.a-.*才是对的。

3.2 命名规范比任何权限配置都重要

讲真，这套插件能不能用好，八成取决于任务命名。如果团队的任务名是"随手起"的——今天叫test1、明天叫build-new、后天叫张三的环境——那任何正则都救不了你。我在推这套方案之前，先花了两周把历史任务改名，定了三条硬规则：

• 所有任务以团队标识开头，用短横线或斜杠分隔，例如team-a-、team-b/。
• 团队标识只用小写字母和数字，避免大小写和特殊字符带来的匹配歧义。
• 共享任务（比如公共的工具链流水线）统一放在shared-前缀下，单独建一个角色，权限给Job/Read，不给Job/Configure。

命名统一之后，角色的 Pattern 就变成了一个稳定的、不怎么需要维护的东西。新团队加入时，建一个角色、写一条正则、加几个用户，五分钟搞定。反过来，如果命名是乱的，你就只能不停地堆特例，堆到最后又回到了矩阵授权那种状态。

3.3 一套可以直接照抄的角色配置

下面这套配置是我在某次实际迁移里用的，覆盖了运维、开发、测试、审计四类人。可以当作起点，按自己团队情况增减。

几个解释。Job/Workspace给开发是有必要的，否则他们没法在构建前清理或查看工作区，遇到"上次的产物没清干净导致构建失败"这种问题会束手无策。Run/Replay允许重新跑一次并临时改参数，调试流水线时很省时间。Run/Update是改构建描述，测试同学用它标注验证结论，比在群里吼一声靠谱得多。

反过来，Job/Configure我只给了负责人。理由很实在：能改任务配置就等于能改流水线脚本、能改构建参数、能改引用的凭据 ID。给出去容易，收回来难，这个权限一定要往上报。

至于Job/Create和Job/Delete，我给得更谨慎。Job/Create给出去之后，用户能建的还是自己 Pattern 范围内的任务吗？不一定——Item 角色的 Create 权限是加在匹配范围内的，正常情况下新建的任务如果命名不在他的正则里，他自己反而会看不到。这种"建完就丢"的迷惑行为会带来不少支持工单，所以我一般建议让负责人建、或者直接用流水线里的 Job DSL 自动生成，不给人手工建的权限。

3.4 视图这里到底该怎么配

回到标题的核心。视图相关的四个权限——View/Read、View/Create、View/Configure、View/Delete——全部位于 Global roles 里，配置方式很直接：

• 想让所有人看见已有的视图标签，全局角色必须给View/Read。这个权限我放在global-read角色里，和Overall/Read一起给。
• 想让用户自己建视图（比如自己拼一个"我最近关注的任务"），给View/Create。但要有心理准备：用户建视图时如果正则写得宽，会看到很多自己没权限的任务名（只是名字可见，点进去还是 403），反而制造困惑。
• View/Configure是改视图定义的权限，包括改视图的正则和列配置。这个权限给团队负责人比较合适，让他们自己维护视图的过滤规则，不用每次都找运维。
• View/Delete只给管理员。删视图看起来无害，但如果删的是公共视图，其他人的使用习惯会被打断。

我的实际做法是：视图由运维统一建，命名和团队标识一一对应，正则和对应的 Item 角色完全一致。比如 A 团队建一个团队A-主线视图，正则^team-a-.*；再建一个团队A-发布视图，正则^team-a-.*release.*。用户默认没有View/Create，只能看这些预设视图加自己的"My Views"。这样视图和权限永远是一一对应、不会错位的。

有个细节值得说：Jenkins 默认的 "All" 视图会展示用户有读权限的所有任务。给每个人保留这个视图是有好处的——万一某个任务的正则没覆盖到，用户至少能在 All 里找到它，不至于以为任务被删了。但如果你的实例里任务数量很大，All 视图会让页面加载变慢，这时候可以考虑建一个"仅展示最近活跃任务"的视图作为默认入口。

4. 用脚本批量维护角色，比在页面点鼠标靠谱

4.1 Script Console 是这套插件的后门

角色多了之后，页面操作会变得很痛苦：十几个角色、几十个用户，点一次保存刷一次页面，改一轮下来半小时没了。Jenkins 自带脚本控制台（系统管理 → 脚本命令行），可以直接调插件的 API 批量操作。

进控制台第一件事，先探一下当前环境暴露出来的类和包名，不要凭记忆写import：

import jenkins.model.Jenkins def strategy = Jenkins.get().getAuthorizationStrategy() println strategy.getClass().getName() println strategy.getRoleMap(com.synopsys.arc.jenkins.plugins.rolestrategy.RoleType.GLOBAL) println strategy.getRoleMap(com.synopsys.arc.jenkins.plugins.rolestrategy.RoleType.PROJECT)

先把类名打出来，确认是org.jenkinsci.plugins.rolestrategy.RoleBasedAuthorizationStrategy还是老版的com.michelin.cio...，再继续往下写。这一步能省掉大半的报错排查时间。getRoleMap返回的是角色名到角色对象的结构，打印出来可以顺便核对现有角色的正则写得对不对。

注意：脚本控制台是"以 Jenkins 进程身份执行任意代码"，权限极大的同时风险也极大。生产环境里建议先临时禁用匿名访问，操作完关闭控制台入口（或者只让管理员访问），别把它当成日常工具暴露在那里。

4.2 批量建角色的脚本

下面的脚本按"角色名 + 正则 + 权限列表"的格式批量创建 Item 角色。写之前先用上一步打印出来的实际类名替换import：

import jenkins.model.Jenkins import hudson.security.Permission import org.jenkinsci.plugins.rolestrategy.Role import org.jenkinsci.plugins.rolestrategy.RoleBasedAuthorizationStrategy import com.synopsys.arc.jenkins.plugins.rolestrategy.RoleType def jenkins = Jenkins.get() def strategy = jenkins.getAuthorizationStrategy() as RoleBasedAuthorizationStrategy // 权限用 fromId 拿，大小写不敏感，写全名更直观 def p = { String id -> Permission.fromId(id) } // 角色定义表：角色名 -> [pattern, 权限列表] def roleDefs = [ 'team-a-dev' : ['^team-a-.*', ['hudson.model.Item.Read', 'hudson.model.Item.Build', 'hudson.model.Item.Cancel', 'hudson.model.Item.Workspace', 'hudson.model.Run.Replay']], 'team-a-owner': ['^team-a-.*', ['hudson.model.Item.Read', 'hudson.model.Item.Build', 'hudson.model.Item.Configure', 'hudson.model.Item.Create', 'hudson.model.Item.Delete', 'hudson.model.Run.Delete']], 'team-b-dev' : ['^team-b-.*', ['hudson.model.Item.Read', 'hudson.model.Item.Build']] ] roleDefs.each { name, def -> def perms = def[1].collect { p(it) } as Set def role = new Role(name, def[0], perms) strategy.addRole(RoleType.PROJECT, role) println "已创建/更新角色: ${name} -> ${def[0]}" } jenkins.save() println '完成'

几点说明。addRole对已存在的同名角色是覆盖行为，所以这个脚本可以反复执行，相当于幂等的"声明式"配置。权限列表里的 ID 要用标准写法，虽然fromId不区分大小写，但写成规范形式以后维护起来不容易出错。执行完必须调jenkins.save()，否则改动只在内存里，重启就没了——我见过有人调试了半天说"脚本执行成功但界面没变化"，就是忘了保存或者没刷新页面。

脚本执行完刷新 Manage Roles 页面，新角色应该都在。如果界面没变，先确认save()有没有抛异常，再确认是不是连接到了另一个 Jenkins 实例（多实例环境下经常搞错端口）。

4.3 批量分配用户，以及怎么核对

角色建完后要绑定用户，用的是assignRole：

import jenkins.model.Jenkins import org.jenkinsci.plugins.rolestrategy.RoleBasedAuthorizationStrategy import com.synopsys.arc.jenkins.plugins.rolestrategy.RoleType def jenkins = Jenkins.get() def strategy = jenkins.getAuthorizationStrategy() as RoleBasedAuthorizationStrategy def assignMap = [ 'zhangsan' : 'team-a-dev', 'lisi' : 'team-a-dev', 'wangwu' : 'team-a-owner', 'zhaoliu' : 'team-b-dev' ] assignMap.each { sid, roleName -> strategy.assignRole(RoleType.PROJECT, sid, roleName) println "已分配: ${sid} -> ${roleName}" } jenkins.save()

这里的 SID 就是用户 ID，通常等于登录名。有几个坑要说清楚。

第一，用户必须先存在。Jenkins 的权限分配绑定的是用户 ID 字符串，理论上给一个不存在的 ID 分配也不报错，但这个人在用户列表里是黑的。严格的做法是让所有人先登录一次，或者在"管理用户"里确认用户已创建，再跑批量脚本。

第二，SID 区分大小写，而且不能有首尾空格。手工在 Assign Roles 页面输入时特别容易多打一个空格，页面看着一切正常，但该用户登录后就是没权限。脚本方式能避免这个，所以我更推荐脚本，或者手工输入后重新核对一遍。

第三，分配是累加的。同一个人可以同时拥有多个角色，最终权限是所有角色的并集。这个特性可以用来做"基础角色 + 增强角色"的组合：给所有人一个global-read，再给具体的人加团队角色。

核对的时候，除了在 Assign Roles 页面肉眼检查，还有个更靠谱的办法：用 Configuration as Code 插件的"View Configuration"功能，把当前的授权策略导出成 YAML，肉眼扫一遍全局/项目角色的正则和分配关系。导出的内容和界面上的数据是一致的，而且能直接 diff，改之前改之后对比一下就知道哪里动了。

4.4 想上声明式配置的话

如果你们的 Jenkins 已经在用 Configuration as Code（JCasC）做整体管理，那角色体系最好也纳入进去，避免"界面改一次、配置文件覆盖一次"的来回拉扯。大概的结构是这样：

jenkins: authorizationStrategy: roleBased: roles: global: - name: "jenkins-admin" permissions: - "Overall/Administer" assignments: - "admin" - name: "global-read" permissions: - "Overall/Read" - "View/Read" assignments: - "authenticated" items: - name: "team-a-dev" pattern: "^team-a-.*" permissions: - "Job/Read" - "Job/Build" assignments: - "zhangsan"

不同插件版本里这个结构字段名有过调整，别照抄别人的博客。稳妥的做法是用前面说的 View Configuration 导出一份当前实例的 YAML，照着导出的结构改，改完再导入验证。JCasC 的好处是整套权限可以进 Git、走评审、能回滚；坏处是它接管之后，你在界面上手工改的东西会在下次加载配置时被覆盖，所以要提前跟团队说清楚"以后权限改动走 Git，不要在界面上点"。

5. 常见问题和排查，这些坑我都踩过

5.1 登录后一片空白，什么都看不到

最常见的三种原因，按概率排序。

第一种，没有给Overall/Read。这个权限是所有页面的基础，哪怕是只读用户也必须有。如果只给Job/Read不给Overall/Read，用户登录后页面直接 403，或者是一个空白的仪表盘。检查方法是看该用户绑定的全局角色里有没有Overall/Read，或者有没有通过匿名角色/authenticated这种特殊主体间接拿到。

第二种，用户名对不上。Jenkins 支持多种认证方式，如果接了单点登录，SID 可能是邮箱、可能是工号，跟你在 Assign Roles 页面里填的不一致。排查办法是让用户登录后进"个人设置"，看页面右上角显示的用户名，那个才是真正的 SID。

第三种，角色分配生效了但会话没刷新。角色的增删一般在下一个请求就生效，但个别认证插件会缓存会话里的权限信息。遇到"明明加上了还是没权限"，先让用户退出重新登录一次，这是成本最低的验证手段。

5.2 任务看得见，按钮却不见了

这类问题几乎都是"缺一条细粒度权限"。用户能在列表里看到任务名，点进去也有页面，但"立即构建"按钮是灰的或者根本没有，说明Job/Read有了但Job/Build没给。同理，参数化构建的输入框能看不能用，通常缺的是Job/Build；构建历史里想删记录删不掉，缺的是Run/Delete；想改构建的描述，缺Run/Update。

排查的时候，直接在 Manage Roles 页面找到对应的 Item 角色，对照权限列表一项项看。给你一张对照表，遇到问题按症状查：

5.3 视图报错和权限报错不是一回事

有人看到"加载 web 视图时出错"这类提示，第一反应是权限配错了，其实多半是浏览器端的缓存或者某个插件的前端资源加载问题，跟授权策略没关系。真正的权限问题报错是清清楚楚的 403 页面，或者"你无权访问"的文字提示。区分方法很简单：换个浏览器或者无痕窗口再开一次，如果还报同样错，再去查插件和日志；如果无痕正常，那就是本地的缓存或者扩展程序在捣乱。

还有一类容易混淆的是"视图里任务数量对不上"。这个不是 bug，就是权限过滤的结果——视图的正则匹配了 20 个任务，但你只有其中 8 个的Job/Read，那页面上就只显示 8 个。排查的时候别只看视图的正则，一定要同时看对应用户的 Item 角色正则，两者是否一致。

5.4 权限模型的两条硬边界

用这套插件，有两件事必须接受，因为它们不是配置问题，而是插件的设计逻辑。

第一，权限只能加不能减。插件里没有 deny 规则，所有授予都是并集。这意味着你无法用一条"排除规则"来禁止某个人看某个任务，只能靠命名隔离——把敏感任务放到完全不同的前缀下，确保任何宽泛的正则都覆盖不到它。我一般的做法是给生产环境的任务单独用prod-前缀，并且明确规定：任何角色的正则都不允许出现^.*这种全匹配，除非是管理员和只读审计角色。

第二，Overall/Administer是万能的。任何拿到这个权限的人都能改授权策略本身，等于拿到了整个 Jenkins 的控制权。所以这个权限只给一到两个人，并且建议配合强密码和登录审计使用。给"方便"多开几个管理员，是权限体系崩塌的开始。

5.5 我在实际项目里的几点心得

最后说几条真金白银换来的经验。

上线前先做一次权限快照。把你打算授予的所有角色、正则、权限列表写进一个文档或者一份 YAML 里，作为基线。之后任何改动都基于这个基线改，而不是在页面上随手勾。我吃过这个亏：某次临时给一个同事加了Job/Configure帮他排障，事后忘了收，三个月后审计才发现。

正则写得越具体越好。与其写^team-.*覆盖所有团队，不如一个团队一条角色。角色数量多一点不痛苦，因为它是可复制、可脚本化的；权限范围模糊才痛苦，因为你永远不知道到底谁有权。

给只读角色做一次实测。建完auditor之后，找个真实账号登录，逐项验证：能看到视图吗？能看到任务列表吗？点开任务能看到日志吗？点构建按钮会发生什么？这些走一遍，比在配置页面盯着看靠谱十倍。实测下来最容易被忽略的是构建日志里可能带出的环境变量和地址信息，如果审计角色不该看这些，那就连Job/Read都别给，只给Overall/Read和View/Read。

定期清理。每季度导出一次角色分配，对照当前的人员名单，把离职和转岗的人清掉。这件事手动做很烦，所以我一般写个简单的脚本，把 Assign Roles 里的分配关系和 HR 系统导出的名单做个比对，输出一份差异清单，人工确认后批量删。权限体系不是配好就完事的东西，它更像一份需要持续维护的资产清单，配置只是起点。