"With great access comes great administrative overhead" - A wise JIRA Administrator
Administrating a JIRA instance can get very cumbersome with every customization that is made. This can lead to a number of larger issues within the system like roadblocks to upgrading server instances, long re-index times, and failures in backing up data. Here are some tried and true practices to keeping your instance clean and running smoothly....and to keep you from pulling your hair out!
No Duplicates
Duplicate names are a big source of overhead and trouble for administrators. These can occur in but not limited to:
- statuses
- issue types
- resolutions
- custom fields
- project roles
The term "duplicates" also refers to similarly named entities. You would want to avoid creating a status called "Finished" or "Complete" when you already have a status called "Done"; or single line text field with a name like "External Issue ID" when you have single line text field with a name "External Issue".
Spring Cleaning
Get in a good practice of checking your system periodically for things that have become inactive. Depending on the size and level of activity in your system, do these audits every 6 months. Deactivate old users, archive projects that have reached their EOL, remove schemes that are not associated with any project in the system. There is a good article on this topic here.
Projects and Spaces for Administrator
Administrators should have a standard Jira or Service Desk project as a means for your user base to ask questions and request changes to the system. This can allow you to have some standardized approval process for changes and track:
- Who requested changes
- Why are changes being requested
- Which administrator made the changes
- When the change was made
- Where the change was made
All the right questions admins seem to have when a user reports "On <insert day of week/date>, I started having problems with..." This can also function as a means of discovering bugs and issues in your system. End users always find more things wrong than testing ever will.
If you have a Confluence instance, create a Knowledge Base. This can help cut down on the volume of requests/questions you receive from users by providing
- General best practices
- Training material and How-To articles
- Guidance for requesting new users, projects, add-on evaluations, and more
- FAQs
If you have a Service Desk, you can connect it to the Knowledge Base and help drive self-help!
System Monitoring
There are a number of add-ons and third party tools to keep a watchful eye on your system and its performance. There are a couple of ways built into Jira that can help you monitor for problem areas and trends. Set up a dashboard for your administrators that looks for problems (e.g. Closed issues where resolution is EMPTY). Periodically run the Integrity Checker (Administration -> System - Integrity Checker).
Set up a "Development" Instance
One way you can keep your production instance of Jira safe and sound is to set up a development/staging/testing/pre-prod instance. This should be as up to date with your production instance as possible for consistency. A development environment gives you a sandbox to test out changes without adversely affecting your production instance. They are good place to test add-on trails, new custom fields, new project configurations, etc.
Join the Community!
"The Whole is Greater than the Sum of its Parts" - Aristotle
You are not alone! Join the Atlassian Community and collaborate with other system administrators who deal with similar issues/struggles....
After all, you ended up here because you were looking for some guidance and help!
2 comments