run_0920687ff7ab030e

input

{
  "request": "Triage Jira ticket MZCLD-3816: Set up PagerDuty teams, escalation policies and a provisioning route for onboarded teams",
  "references": [
    "https://mozilla-hub.atlassian.net/browse/MZCLD-3816"
  ],
  "sourceContext": {
    "issue": "MZCLD-3816"
  }
}

summary

MZCLD-3816 is a Backlog ticket proposing to set up PagerDuty teams, escalation policies, and a repeatable provisioning route so teams can be onboarded without filing a bespoke ticket each time. The description is well-scoped and cites concrete pain points (manual SREIN tickets, an SSO/invite failure) but the work depends on cross-team ownership decisions and on another in-flight automation ticket that should not be duplicated. Access to the referenced tickets (SREIN-1707, SREIN-1695, SVCSE-3687, MZCLD-245) was blocked by policy in this run, so triage below relies solely on the MZCLD-3816 description text.

findings

• Current PagerDuty provisioning is manual and ticket-driven, which doesn't scale for onboarding multiple teams.
• There is a known, unresolved SSO/invite failure (SREIN-1695) that could undermine any new self-service or open-invitation provisioning route if not fixed first.
• Ownership of PagerDuty instance administration is explicitly called out as belonging to IT/Service Engineering, not this team, and requires an agreed division of responsibility before proceeding.
• There is overlap risk with MZCLD-245 (automating on-call schedules from workgroups); the new provisioning route should consume that work rather than duplicate it.
• The ticket currently has no comments and no acceptance criteria/design doc linked, and is still in Backlog, suggesting it needs scoping/refinement before implementation can start.
• This triage run could not pull SREIN-1707, SREIN-1695, SVCSE-3687, or MZCLD-245 directly (access blocked by policy), so dependency status (e.g., whether the SSO/invite bug is fixed, or whether SVCSE-3687 has resolved the ownership split) is unverified and should be confirmed manually before starting work.

proposed actions

Triage notes:

1) Blocking dependency — ownership: Instance administration is owned by IT/Service Engineering (Brandon Wells, per SVCSE-3687). Before design work starts here, we should confirm with SVCSE-3687 what split of responsibilities (who owns team/escalation-policy creation vs. who owns the account-provisioning route) has been agreed, so this ticket doesn't duplicate or conflict with their admin process.

2) Blocking risk — SREIN-1695 (SSO/invite failure): This ticket explicitly flags that the invite/SSO path needs to be understood or fixed before we move to an open-invitation provisioning phase. Recommend confirming current status of SREIN-1695 and, if unresolved, either scoping a fix as a prerequisite or explicitly carving the open-invitation phase out of this ticket's initial scope.

3) Overlap to avoid — MZCLD-245: Schedule automation from workgroups is covered there; this ticket's provisioning route should be designed to consume that output once it lands rather than reimplementing schedule logic. Suggest linking MZCLD-3816 and MZCLD-245 (e.g., 'is blocked by' or 'relates to') so sequencing is visible in Jira.

4) Readiness: Ticket is still in Backlog with no acceptance criteria/design doc attached. Recommend moving to 'Refinement' and adding a short design note (proposed PagerDuty team/escalation-policy structure, provisioning mechanism — e.g., Terraform vs. API script vs. IdP group sync) before pulling into a sprint.

Suggested next step: schedule a short sync with IT/Service Engineering (SVCSE-3687 owner) to agree the ownership split, then re-scope this ticket's acceptance criteria accordingly.

tool calls

[
  {
    "capability": "jira.issue.read",
    "args": {
      "key": "MZCLD-3816"
    },
    "result": {
      "key": "MZCLD-3816",
      "summary": "Set up PagerDuty teams, escalation policies and a provisioning route for onboarded teams",
      "status": "Backlog",
      "description_text": "Background Adding a user to PagerDuty today means someone files a SREIN ticket and an admin does it by hand \u2014 see SREIN-1707 (\"Add Chris Gemoules to PagerDuty\") and SREIN-1695, where a new user could not complete the invite at all. That does not scale to a multi-team rollout, and the SSO/invite failure in SREIN-1695 suggests the provisioning path itself needs checking before we point more people at it. Goal Have the instance-side structure ready so a team can be onboarded without a bespoke ticket: their PagerDuty team, their escalation policy, and a repeatable route to get their people accounts. Notes Instance administration belongs to IT / Service Engineering \u2014 Brandon Wells, SVCSE-3687. Agree the split of who does what rather than working around them. MZCLD-245 covers automating schedules from workgroups. Do not rebuild that here; if it lands, this route should consume it. SREIN-1695 (invite/SSO failure) is worth resolving or at least understanding before the open-invitation phase.",
      "comment_count": 0,
      "comments": []
    }
  },
  {
    "capability": "jira.issue.read",
    "args": {
      "key": "SREIN-1707"
    },
    "result": {
      "error": "read blocked by policy: resource not in run subject",
      "args": {
        "key": "SREIN-1707"
      }
    },
    "blocked": true
  },
  {
    "capability": "jira.issue.read",
    "args": {
      "key": "SREIN-1695"
    },
    "result": {
      "error": "read blocked by policy: resource not in run subject",
      "args": {
        "key": "SREIN-1695"
      }
    },
    "blocked": true
  },
  {
    "capability": "jira.issue.read",
    "args": {
      "key": "SVCSE-3687"
    },
    "result": {
      "error": "read blocked by policy: resource not in run subject",
      "args": {
        "key": "SVCSE-3687"
      }
    },
    "blocked": true
  },
  {
    "capability": "jira.issue.read",
    "args": {
      "key": "MZCLD-245"
    },
    "result": {
      "error": "read blocked by policy: resource not in run subject",
      "args": {
        "key": "MZCLD-245"
      }
    },
    "blocked": true
  }
]

log