Jira实战 | 用户访问策略
Jira有不同类型的用户、成员和维护他们的场景，本文我们会探讨不同用户类型、权限等级、职责、角色和用户组，我们还会讨论如何管理新入职员工和离职员工、设置期望和创建用户访问权限管理的策略。
用户类型
用户一般都属于以下几个类型
-
内部用户–在可预见的将来仍将留在公司的全职和兼职雇员
-
外部用户–一段时间后将停止工作的承包商、顾问和临时雇员
-
活跃用户–定期登录并在问题上进行数据交互的用户
-
不活跃用户 -在X日内未登录和/或已离职的用户
-
JIRA Core 用户 -具有简易浏览的“业务（Business）”项目类型的用户，该用户具有简易的项目浏览权限，而无需软件开发相关特性
-
JIRA Software 用户 -带有浏览软件开发概念的“软件（Software）”项目类型的用户，该用户能看到开发相关的特性。（例如：发布选项、版本、开发工具集成面板等等）
-
JIRA Service Desk用户 -包含浏览支持概念的“支（Support）”项目类型的用户，如服务级别协议（SLA）、首页功能等。
-
项目级管理员 –具备管理单一JIRA项目设置权限的用户。(例如：组件、项目用户等)
-
系统级管理员 –具备执行JIRA每一个管理功能的用户
-
应用级管理员 – 具备执行JIRA最多管理功能的用户
测试用户
为每一个用户场景创建一个测试用户账户，例如：如果你是一位具备应用管理员访问权限的内部用户，请创建一个通用账号来测试你的更改对一个具备常规访问权限的内部用户的影响。
不要这么做
创建测试管理员用户，因为这可能引入安全问题或是违反公司的政策。
管理员
咨询委员会应该定义管理员的数量(最少和最多)来妥善地支撑应用程序，这个范围取决于用户数、项目数、用户请求的频率和日常运维计划的活跃性，太少的管理员会导致你的应用没有人可以支持，特别是在节假日休息、紧急事件或是公司其他高优先级事件发生时；太多的管理员导致在整体应用策略上变更冲突或修改不一致的情况发生。
案例分析
在某一家公司里头，没有任何流程来决定谁可以获得应用级管理权。不管你是技术开发团队经理还是非技术项目经理，不管你有多年的支持经验或是一点经验都没有，每一个去要求管理权限的人都能够得到这个权限。在一个将近1000用户的公司里有将近50位管理员的人数，确切的数字是45位，这实在是太多了！用户能做所有他想做的变更，而且是没有计划性、记录和沟通的变更，有些变更常常对其他项目或是应用造成无法预期的影响，方案复制很多次、自定义字段拼写错误、已安装插件从未被使用或是被莫名卸载，应用程序的稳定性和可用性每天都在下降，一个复杂的查询和一次重新索引就会导致整个应用崩溃！
不要这么做
随意授予管理权限。
就像咨询委员会的成员一样，你的JIRA管理员需要被仔细地挑选、定期审核并被应用负责人认可，一个管理员需要考虑应用程序的健康状况、对应用程序的影响，以及每个决策和更改带来的维护成本。
管理团队成员中，最糟糕的类型就是对于应用的结构不了解、不与利益干系人沟通或是忙于其他应用程序而没有时间投入到正确支持JIRA上的人。
无论你是否雇用专职的管理员或是使用有经验的员工来担任兼职管理员团队，角色、职责和期望都需要明确被定义。
应该这样做
管理员应该一直记录所有的变更，JIRA会记录谁何时进行变更，但是不会记录为何要用这个特定的方式来进行变更。理想情况下，如同前面章节所提到的这些信息应该记录在JIRA支持项目上，管理员应该记录所有执行细节上的说明，好让其他有需要的人能够参考。这些记录对于多管理员团队一同处理复杂的用户请求或是将管理职责转移到新用户时尤为重要。
项目负责人
每一个JIRA项目都有其项目负责人(有时候也是问题默认的经办人)，因此，就有机会让更多其他用户参与项目级的维护和管理。
不要这么做
让应用程序级别的管理员同时也担任项目级管理员，这两个是独立的角色。
应该这样做
在新建项目请求时确认项目负责人(请参阅"新项目申请"工作表来创建你专属的调查问卷。) 可以根据具体情况来选择项目负责人，也可以按照项目类型(project type)和类别(category)来安排项目负责人，例如，由保罗担任所有软件类型项目的项目负责人。 项目负责人也可以是之前"委派大使"章节中提到的JIRA大使团最好的候选人。
职责
项目负责人通常有以下职责:
-
按照制定的标准设定和维护模块组件、版本以及其他项目特定设置
-
在“用户和角色”区域中管理用户和用户组
-
定期分配（或指定一个负责分配的人员)在创建问题时分配和审查问题
-
维护项目空间的数据和数据正确性
-
将项目问题或是定制化请求呈报给JIRA支持团队
-
响应问题或JIRA支持团队批准通过的需求
外部用户
不管现在或将来，你都会需要让外部用户访问你的应用，可能是协助项目临时雇用的外聘人员，或是Atlassian技术人员来进行JIRA问题的故障排除，也可能是进行审计的外部顾问，无论什么场景，你都应该提前做好准备。
不要这么做
忽略考虑外部人员，他们的访问权限应该被特别的处理。
设定外部用户时不要使用外部邮箱地址，公司的重要数据绝不能通过外部邮箱服务器发送。
应该这样做
应该为所有的外部用户设置公司的邮箱地址(不一定是和内部员工使用相同的域，但是应该是被公司管理的域)，外部邮箱会将敏感信息和专有信息通过外部邮箱服务器被不安全地获取。记住，邮件通知在JIRA中是被广泛使用的，任何的@提及和分享操作都会触发邮件通知，邮件通知在任何时点发送，并且内容会呈现变更的记录。过滤器的结果会被发给所有的订阅者。你希望你的公司JIRA数据被发送到@gmail.com的邮箱地址去么？当然不！
思考以下案例
-
2 个外部人员来自于同一家公司，他们需要访问JIRA的X项目
-
3个来自于不同公司，他们需要访问JIRA的X项目和Y项目
-
4个临时的承包商需要访问JIRA的Z项目
案例分析
上述的使用案例是个真实案例，该公司没有为外部人员做好准备，例如，具备访问一个JIRA项目的权限，同时也能访问其他的项目，更糟的是，任何一个新的JIRA用户居然同时也是Confluence 用户！这就表示每一个临时员工都能通过这两个应用访问到内部的公司信息、专有文档和未来的计划！
虚拟用户
确保用户阅读来自JIRA管理消息和通知的一种方法，就是使用特殊创建的虚拟角色来发送，来自个别用户的消息可能看起来非常的无聊并且容易被遗忘在邮箱的大海里，但是通过虚拟的角色来发的话会显得比较幽默且更容易会被阅读和分享!
关于本书
本文节选自《JIRA策略管理实战手册》，为应用程序管理员提供配置、清理和维护Jira的模板。
此实战手册包含：
-
152条建议- 帮助您设置、清理和维护Jira
-
50个工作表，以及其他相关模板、代码片段和示例- 帮助您建立和简化主要工作
-
33个需避免的反面真实案例
-
每个管理区域的最佳实践和注意事项
-
我作为管理员犯下的十大错误
此实战手册向您展现：
-
精心策划并得以实施的行动项
-
工作流管理的简单方法
-
如何审计及清理应用程序
-
维护和扩展Jira的方法
-
如何创建可重复的流程
-
如何远离“Jira沼泽”
推荐阅读
Jira实战 | 关于IssueType
Jira实战 | 关于解决结果