Skip to main content

Jira Service Management Guide: Our Central Nervous System for IT

1. Introduction: More Than Just a Ticketing System​

Jira Service Management (JSM) is the central hub for all IT and operational service requests, incident records, and change management processes at XOPS. While Jira Software tracks development work, JSM tracks the health, stability, and support of our platform as a service. It is the primary interface for both internal users and external customers to request help and report issues.

This guide explains how JSM is configured, how its automation rules work, and how it serves as a critical event source and action target for our AI agent, Sparky.

Core Mission: To provide a single, structured, and auditable pane of glass for all service operations, from a customer reporting a bug to an SRE requesting a production change.

2. Usage in Handbook Sections​

JSM is the system of record for many of our most important workflows:

  • Change and Incident Management: JSM is the only approved tool for requesting and tracking production changes. All incidents, whether detected automatically or reported manually, result in a JSM ticket.
  • Proactive Problem Resolution: When Sparky's L3 triage determines an issue requires human intervention, its final action is to create a detailed, context-rich ticket in JSM and assign it to the appropriate team.
  • Customer Interaction and Routing: When a customer has an issue that cannot be self-served via Control Center or Sidekick, the final escalation path is to create a ticket in our customer-facing JSM portal.
  • Customer Success and QBRs: The history of JSM tickets for a given customer is a key input into our Quarterly Business Reviews, helping us identify recurring pain points and areas for improvement.
  • Platform Operations and Maintenance: All periodic checks and maintenance tasks are tracked as scheduled issues within JSM.

3. Key Configurations and Best Practices​

  • Request Types: We have meticulously defined request types to structure all incoming work. Examples include:
    • Incidents: "Report a Production Outage", "Report a Performance Issue"
    • Service Requests: "Request Database Access", "Onboard a New Teammate"
    • Change Requests: "Request Standard Production Change", "Request Emergency Production Change"
  • Automation Rules: JSM's automation engine is used extensively to reduce manual work.
    • Auto-Assignment: Tickets are automatically routed to the correct team based on the component or service field.
    • Auto-State Changes: When a developer links a GitHub PR that fixes an issue, the JSM ticket is automatically transitioned from In Progress to In Review.
    • SLA Timers: We have strict SLAs for response and resolution times, which are tracked by JSM. Breaches automatically escalate the ticket's priority and notify team leads.
  • Customer Portal: The customer-facing portal is designed to be simple and intuitive, with a prominent link to our Knowledge Base to encourage self-service.
  • Integration with Confluence: Every JSM project is linked to a Confluence space which serves as its Knowledge Base. This allows customers and internal users to find answers before they even create a ticket.

4. Verbose Workflow: The Life of a JSM Ticket (Sparky-Assisted)​

This workflow shows how a customer-reported issue is handled with maximum automation.

  1. Customer Creates Ticket: A customer is having trouble with their ServiceNow integration and creates a ticket via the JSM portal, selecting the "Report an Integration Issue" request type.
  2. JSM Automation: JSM's internal automation rules fire:
    • It sets the Component field to Ecosystem-Integrations.
    • It assigns the ticket to the Tier 2 Support queue.
    • It fires a webhook to Sparky.
  3. Sparky Triage (L1): Sparky receives the ticket details. It queries the Knowledge Graph: "Are there any known issues with the ServiceNow integration? Is the customer's configuration valid?" It discovers the customer is using a deprecated authentication method. This matches Playbook-007: Deprecated Integration Auth.
  4. Sparky Resolves & Updates:
    • Sparky executes the playbook, which involves calling the Platform API to update the customer's integration configuration to use the new auth method.
    • Sparky adds a public comment to the JSM ticket: "Hello [Customer Name], I've identified that your ServiceNow integration was using a deprecated authentication method. I have automatically updated it for you. Please try again and let me know if the issue is resolved. Thank you!"
    • Sparky transitions the ticket status to Resolved.
  5. Customer Notified: The customer receives an email notification with Sparky's comment and can re-open the ticket if the issue persists. In this case, the fix works, and no human ever had to touch the ticket.

5. Template: RFC (Request for Change) Issue​

All production changes must be documented with a "Request for Change" ticket in JSM. Use this template.

### Request for Change: [Brief, Descriptive Title]

**1. Change Summary:**
> A clear, concise summary of the proposed change. What are you changing and why?

**2. Business Justification:**
> Why is this change necessary? Link to relevant business goals or incident tickets.

**3. Impact Assessment:**
> What is the potential impact of this change? What services will be affected? What is the expected customer impact (if any)?

**4. Risk Assessment:**
> What is the risk of making this change? What is the risk of *not* making this change? Rate the risk as Low, Medium, or High.

**5. Implementation Plan:**
> A step-by-step plan for implementing the change. Include links to the GitHub PRs.
> 1.
> 2.
> 3.

**6. Verification Plan:**
> How will you verify that the change was successful and did not cause any unintended side effects?
> - [ ] Check New Relic dashboard for service X.
> - [ ] Run synthetic test Y.

**7. Rollback Plan:**
> If the change fails, what is the exact, step-by-step plan to revert it?
> 1. Revert GitHub PR.
> 2. Manually execute rollback script Z.