ServiceOps

ServiceOps is a vendor label for running IT service management (ITSM: requests, incidents, changes, service levels) and IT operations management (ITOM: monitoring, events, discovery, automation) on shared data, so that people who handle tickets and people who run systems see the same services, owners and dependencies.^[1] Its promises (one incident per group of correlated alerts, routing to the right team, change impact, business-level health) rest on a service model: services that each have one owner team, a tier, dependencies, service levels and one identifier used by every tool. This page teaches how to build and run that model.

Where to start. Beginners: the glossary, then Lab 1. Practitioners: the service record, reference implementation and labs. Leaders: the decision framework and judgement call. Last verified 2026-10-18.

Most organisations already have ITSM and monitoring tools. The trouble is between them:

• One fault, many tickets. A database failure raises alerts in four tools and tickets from three teams. BMC Helix’s answer is one incident per correlated “situation” carrying “the causal configuration item (CI)”,^[1] which helps only if that CI belongs to a known service with a known owner.
• Pages that reach nobody. AWS lists “an ITSM queue without an email mapping” among its ownership anti-patterns and rates missing resource owners a high risk.^[7]
• Services defined by technology. EMA’s 2024 panel (415 IT leaders) split 68% by technology area and 32% by business function;^[4] its 2025 survey (204 IT leaders) found more than half defining services by business function, while “the rest still organize around technology silos”.^[8][5] The samples differ, but in many firms the database team is still “green” while customers cannot pay.
• Promises the dependency chain cannot keep. “A service cannot be more available than the intersection of all its critical dependencies.”^[9] A tier-1 checkout that needs an unowned tier-3 tax service has a target nobody can meet.
• Regulators ask for the map. EU DORA (the Digital Operational Resilience Act, Regulation (EU) 2022/2554)^[10] and the UK Financial Conduct Authority (FCA)^[11] require in-scope financial firms to identify their business functions or important business services and map what they depend on.

• Not ITSM practice detail. How incidents, problems and changes are recorded, prioritised and approved is on ITOps.
• Not SLO engineering (SRE), incident command (IncidentOps) or alert correlation (AIOps). Here SLOs are fields of a service record, and incidents and alerts are consumers of the model.
• Not one product, though products carry the name. ServiceNow sells the same ITSM–ITOM convergence as “Service Operations Workspace”, one agent interface for incidents, alerts and tasks that integrates with its ITOM edition,^[12] which shows several vendors chasing the idea. Motadata sells an ITSM platform called “Motadata ServiceOps”.^[13]
• Not ITIL V3 “Service Operation”, though that was its precursor. That lifecycle stage of ITIL V3 and 2011 already put event management (monitoring) and incident management together, with request, access and problem management.^[14]
• Not a CMDB project. A CMDB is one store of the model; a complete one with no owners or tiers answers no operational question.

The label is recent; the ideas under it are not.

• 2006, ownership. Werner Vogels on Amazon: “Each service has a team associated with it, and that team is completely responsible for the service”; “You build it, you run it.”^[15]
• 2007, ITIL V3 made “Service Operation” a lifecycle stage, kept in its 2011 edition.^[14][16]
• 2020, software catalogues. Spotify open-sourced Backstage (over 280 teams, 2,000+ backend services);^[17] it is now a CNCF incubating project.^[18]
• About 2021, the label. BMC says it named the integration of its BMC Helix service and operations products “ServiceOps” then, calling it “a new paradigm in enterprise technology: the convergence of service management and operations management”.^[19][2]
• 2022, an analyst category. BMC reported that Gartner’s Hype Cycle for ITSM, 2022 placed “Service Operations” (defined around “the ITSM incident management practice”) at the innovation trigger, cautioning that “Accurate service mapping and comprehensive CMDBs are necessary to support the end-to-end incident process”; we could not read the Gartner report.^[2]
• 2024–2025, surveys. EMA’s third annual study (February 2024, 415 IT leaders) called “ServiceOps (by any name)” “a technology-enabled approach to frictionless collaboration between IT service and operations”;^[4] its 2025 study widened it to “a unified operational approach combining IT service, ITOps, and ESM”.^[5]

Mental model: one service, one identity, many records, one graph. Each tool keeps its own record of a service; ServiceOps works when all carry the same key, so a trace, alert, ticket and change join to one owner and one tier. And services depend on each other, so a tier means little until you see what sits beneath it (figure).

Neighbours either consume the model (AIOps ranks alerts by tier, IncidentOps pages the owner) or feed it (ObservabilityOps). Two approaches lack an Atlas page: full-service ownership (teams run what they build^[26]) gives accountability and fast routing but no business-level view; enterprise service management applies ITSM principles “to the services delivered by other departments”^[27] and needs the same model (non-IT records).

This charter is the Atlas’s proposal; no official ServiceOps manifesto exists.

Mission. Anyone holding a signal (an alert, ticket, change, trace or bill) can find within a minute which service it belongs to, who owns it, how critical it is and what depends on it.

1. One service, one identity, everywhere. Catalogue ID, CMDB record, on-call service, telemetry service.name and cost tag resolve to one key. OpenTelemetry falls back to unknown_service when service.name is unset,^[28] so naming is a contract.
2. One accountable owner team, reachable now. For PagerDuty a service is “wholly owned by one team”;^[29] Backstage’s owner is “the singular entity (commonly a team) that bears ultimate responsibility”.^[30]
3. Name services as consumers see them. Business services should be “Recognizable to non-technical stakeholders”;^[31] technology-area services belong one layer down.
4. Tier by business impact; make dependencies match the tier.^[9]
5. Trust neither declarations nor discovery alone. Teams forget dependencies; tools miss uninstrumented and rare paths.
6. Records decay; review by tier. A record without a review date is a guess.
7. Model what decisions need. Start with services that page people, carry money or are regulated (ITOps judgement call).

Non-goals. Centralising ownership in a service-management office; modelling every configuration item; replacing the ITSM practices on ITOps.

The service record is the unit of ServiceOps. Each field exists because some decision or tool depends on it.

Records for non-IT services (ESM). An HR onboarding or facilities service keeps the same record (one owner team, a tier, a review date), but three fields change, by the Atlas’s proposal. The on-call reference becomes a staffed queue with business hours. Dependencies are steps owned by other departments, suppliers and IT services (onboarding needs an account and a laptop); no telemetry checks them, so drift shows up in reviews and misrouted requests. Service levels become request lead-time targets rather than SLOs. The record also gains a catalogue entry, which is what consumers order: in CSDM, consumers request business services through request catalogues.^[32]

The service owner is accountable for levels, tier and investment; the owner team runs the service and keeps its record; the service model owner (similar to ITIL V3’s service catalogue manager^[23]) owns the schema, checks and exceptions; the service desk, SRE and risk teams consume the model and report its errors.

R = responsible, A = accountable, C = consulted, I = informed. Keep one A per row; the AWS anti-pattern list shows why overlapping ownership of critical infrastructure is a risk.^[7]

stateDiagram-v2
  direction TB
  [*] --> Proposed
  Proposed --> Onboarding: owner team and tier accepted
  Onboarding --> Production: readiness review passed
  Production --> Production: quarterly or annual review
  Production --> Deprecated: replacement named, consumers told
  Deprecated --> Retired: no traffic, no dependants
  Retired --> [*]

The readiness gate borrows Google’s production readiness review (PRR: dependencies, monitoring, emergency response, capacity, change management, performance).^[33] Backstage’s lifecycle uses experimental, production and deprecated.^[30] Retirement is where catalogues fail: a “deprecated” service with callers is a dependency nobody staffs.

Escalation rule (proposal). A service without a valid owner goes to the parent organisation’s engineering lead, who names an interim owner within one working day and a permanent owner within 30 days. Ownership transfers need both managers’ acceptance, never an administrator’s bulk edit.

Declared data (owner, tier, intended dependencies, service levels) comes from people; directory data (teams, schedules) from the identity provider and paging tool; observed data (running components, calls, cloud resources) from discovery, traces and tags. A reconciler joins them on the service ID and publishes one model plus a list of exceptions.

%%{init: {"flowchart": {"wrappingWidth": 140, "nodeSpacing": 16, "rankSpacing": 30}}}%%
flowchart TB
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029
  classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
  subgraph IN["Inputs"]
    direction LR
    DEC["Declared: service records in Git or ITSM"]:::neutral
    DIR["Directory: teams, people, on-call schedules"]:::neutral
    OBS["Observed: discovery, trace service graph, cloud tags"]:::neutral
  end
  REC["Reconciler: join on service ID, validate, diff"]:::core
  EXC["Exceptions: no owner, no on-call, drift, unnamed telemetry"]:::risk
  MOD["Published service model and API"]:::core
  subgraph OUT["Consumers"]
    direction LR
    ITSM["ITSM: incident, change, request"]:::neutral
    EVT["Event management and AIOps"]:::neutral
    STAT["Status pages and stakeholders"]:::neutral
    FIN["Cost allocation and risk registers"]:::neutral
  end
  DEC --> REC
  DIR --> REC
  OBS --> REC
  REC --> EXC
  REC --> MOD
  EXC ~~~ MOD
  MOD --> ITSM
  MOD --> EVT
  MOD --> STAT
  MOD --> FIN

Where the master record lives is the main architectural choice; the judgement call works through it.

Trust boundaries. Owner teams edit their own records (reviewed pull requests or ITSM forms); only the model owner changes the schema; tier changes need the service owner; nobody bulk-edits ownership. The sync job and reconciler are privileged, since editing services or escalation policies in the paging tool can reroute or silence pages: give them read-only access to the directory and traces, write access only to the fields they sync (never escalation policies), and log every write. In a portal-centred design, changing spec.owner changes who is paged: require code-owner review of catalog-info.yaml by the model owner’s group (every edit to the file then waits for it), on a branch rule that binds administrators too (GitHub; private repositories need a paid plan).^[34][35] Any one code owner’s approval satisfies GitHub’s rule, so record the receiving manager’s acceptance separately. Never grant access from catalogue ownership (security).

%%{init: {"flowchart": {"wrappingWidth": 150, "nodeSpacing": 16, "rankSpacing": 28}}}%%
flowchart TB
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  A["Alerts from monitoring carry service.name"]:::core
  B["Event management groups them into one situation"]:::core
  Q{"Service known, owner valid, on-call set?"}:::decision
  C["Incident on the service; tier sets priority"]:::core
  D["Owner team paged; recent changes attached"]:::core
  E["Business services impacted, found via critical dependencies"]:::core
  F["Status page and stakeholders notified"]:::core
  X["Fallback queue: incident manager routes by hand"]:::risk
  Y["Interim owner within 1 working day; counted as attribution failure"]:::risk
  A --> B --> Q
  Q -->|"yes"| C --> D --> E --> F
  Q -->|"no"| X --> Y
  X --> C

Products implement pieces of this flow. PagerDuty marks a business service impacted when a supporting service has an incident (which must have a priority), at any priority by default or above a threshold.^[31] BMC Helix creates blackout policies “based on a scheduled change request”.^[1] The priority matrix is on ITOps.

A tier decides which agreements a service needs, how its health is judged and how carefully it is changed. These rules are the Atlas’s proposal; clock design is in ITOps’ service levels section, SLO design on SRE.

Which sense of SLA. Google’s SRE book treats an SLA as a contract “that includes consequences”, a business and product decision.^[25] FitSM-1, which is certifiable, requires SLAs “For all services delivered to customers” (a customer can be part of your own organisation) and OLAs “as needed”;^[36] if you certify, every customer-facing service needs an SLA, whatever its tier.

An OLA is the organisational side of a tier inversion. When tier-1 checkout-api critically depends on team-pricing’s tier-2 pricing-svc, an OLA on that edge records team-pricing’s target, page response and change notice. It does not make the dependency stronger; it makes the gap owned, so the tier playbook’s engineering options get funded.

Health roll-up. Each option has a cost:

• Worst of the critical components: simple and explainable; pessimistic where redundancy absorbs a failure, blind to a missing edge.
• Rules and thresholds: PagerDuty, for example, can count only incidents at or above a chosen priority;^[31] fewer false alarms, but only as good as the priorities.
• A business-level SLI (orders completed per minute against the expected rate): closest to customers, but needs instrumentation and does not name the faulty component.

Use the third for tier-1 business services, the first to diagnose.

Change risk. The model feeds ITOps’ risk score with the changed service’s tier and its dependants (Lab 2 finds them). Route a change at the highest tier among the service and its critical dependants: changing tier-2 pricing-svc is a tier-1 change because checkout fails with it. Attach the dependants to the change, notify their owners and honour the freeze windows of the business services above.

PagerDuty’s guide gives the sequence:^[29]

1. Start from the team that will be paged. “A service should be wholly owned by the team that will be supporting it via an on-call rotation”; if several teams share one, split it (“service mitosis”).
2. Size it to the team’s knowledge; merge two microservices that “effectively behave as one”.
3. Monoliths: split logical functionality into services for routing, runbooks and on-call, even though the code is shared.
4. Add dependencies after ownership is clear.

Our addition: name the consumer-facing service separately when the business sees something other than the component (online ordering versus checkout-api).

Acceptance: one owner team, one schedule with people on it, a tier, a lifecycle state, and the identifiers other tools use.

Use one question set for every service (the Atlas’s rubric; Jira Service Management’s four tiers run from failure that “will result in a significant impact to customers” to “no significant effect on the customer experience”^[24]):

Then check each critical dependency of a tier-1 service. Google’s rule of thumb gives critical dependencies “one additional 9”, counting each unique dependency once however deep it sits.^[9] For a lower-tier critical dependency, raise its tier and staffing (with an OLA on the edge), make it non-critical (cache, fail open, degrade gracefully^[9]), or lower the promise. Lab 2 automates the check on the estate below.

%%{init: {"flowchart": {"wrappingWidth": 150, "nodeSpacing": 16, "rankSpacing": 34}}}%%
flowchart TB
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029
  classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
  OO["online-ordering: business service, tier 1"]:::core
  CA["checkout-api: tier 1, SLO 99.95%"]:::core
  PG["payments-gw: tier 1"]:::core
  PR["pricing-svc: tier 2"]:::risk
  LT["legacy-tax: tier 3, owner team dissolved"]:::risk
  RS["recs-svc: tier 3"]:::neutral
  FS["fraud-scoring: tier 2"]:::risk
  DB["orders-db: shared resource, tier 1"]:::core
  OO --> CA
  CA --> PG
  CA -->|"inversion"| PR
  CA -->|"inversion"| LT
  CA -.->|"non-critical"| RS
  PG -->|"inversion"| FS
  PG --> DB
  PR --> DB
  CA --> DB

Separate what is binding from what is advice.

• Binding where it applies (check jurisdiction and scope). EU DORA Article 8 requires in-scope financial entities to “identify, classify and adequately document all ICT supported business functions, roles and responsibilities, the information assets and ICT assets supporting those functions, and their roles and dependencies in relation to ICT risk”, map “the links and interdependencies”, identify processes that rely on ICT third-party providers, and review at least yearly.^[10] The UK FCA required firms in scope to identify important business services, set impact tolerances and map and test them by 31 March 2022, and to be able to remain within tolerances by 31 March 2025.^[11]
• Certifiable standards. FitSM-1 (open, CC BY 4.0) requires that “A service portfolio shall be maintained. All services shall be specified as part of the service portfolio”, that “A service catalogue shall be maintained”, and that CIs and their relationships are kept in a CMDB verified at planned intervals.^[36] ISO/IEC 20000-1 is the international standard; see ITOps.
• Frameworks. ITIL (Version 5), as quoted by ITSM.tools, defines service catalog management as “The practice of providing a single source of consistent information on all services and service offerings, and ensuring that it is available to the relevant audience”.^[37]
• Data models. ServiceNow CSDM (business services, service instances, technology management services; CSDM v5 renamed “application service” to service instance)^[21]; Backstage (components, APIs, resources, systems, domains)^[22]; OpenTelemetry’s service.* attributes.^[28]
• Methods. Google’s production readiness review^[33]; the calculus of critical dependencies^[9]; Team Topologies’ stream-aligned teams, described as “‘You Built It, You Run It’ teams”.^[38]

As of October 2026. Re-check after major releases and ownership changes. Three are recent or ongoing: Compass moving into DX, Helix’s completed carve-out from BMC and the CSDM v5 renames.

Selection criteria: your service ID as a first-class key; read/write API; a critical flag on dependencies; owners can edit in their normal workflow; a known exit cost.

Automate the checks that decay fastest (owner exists, schedule staffed, telemetry names match, declared and observed edges agree, deprecated services have no callers) and maintenance windows from change records. Keep humans on tier, ownership and retirement.

BMC Helix offers AI agents and ML change-risk prediction from similar past changes;^[1] the Gartner text quoted by BMC warns that “AI-based monitoring systems can take a long time to understand the context of the environment”.^[2] A language model can draft a service record from a repository; the owner team must accept it, because a wrong owner pages the wrong people. Topology-based correlation inherits every error in the map.

Assumptions (illustrative). About 60 production services; records beside the code in a software catalogue; an ITSM tool; a paging tool; OpenTelemetry. ITSM as master works too if every system stores the same ID.

1. The declared record. A Backstage component requires type, lifecycle and owner.^[30] Tier and external IDs are not built-in, so this example uses a label and annotations under a placeholder prefix (example.com/).

Example status: YAML syntax-checked by the Atlas validator; not loaded into a Backstage instance.

apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: checkout-api
  description: Takes a basket to a paid order
  labels:
    tier: "1"
  annotations:
    example.com/oncall-service-id: PXXXXXX
    example.com/cmdb-id: CMDB-0000000
    example.com/cost-tag: svc-checkout-api
spec:
  type: service
  lifecycle: production
  owner: group:default/team-checkout
  system: online-ordering
  dependsOn:
    - component:default/payments-gw
    - component:default/pricing-svc
    - component:default/legacy-tax
    - component:default/recs-svc
    - resource:default/orders-db
---
apiVersion: backstage.io/v1alpha1
kind: System
metadata:
  name: online-ordering
  description: Customers browse, pay and track orders
spec:
  owner: group:default/team-checkout
  domain: commerce
---
apiVersion: backstage.io/v1alpha1
kind: Group
metadata:
  name: team-checkout
spec:
  type: team
  children: []

dependsOn has no “critical” flag; keep criticality in your register (as in the lab data) or an annotation.

2. The same name in telemetry. OTEL_SERVICE_NAME sets service.name and wins over a service.name inside OTEL_RESOURCE_ATTRIBUTES, which takes key1=value1,key2=value2 pairs.^[44][45]

Example status: bash syntax-checked; not executed against an SDK.

# Set in the deployment manifest or start-up script of every instance
export OTEL_SERVICE_NAME="checkout-api"
export OTEL_RESOURCE_ATTRIBUTES="service.namespace=shop,service.version=2026.10.3"

3. One identity, four tools. The join only works if this table is complete for every tier-1 and tier-2 service.

Sources: Backstage^[22], CSDM^[21], PagerDuty^[31][46], OpenTelemetry^[28][43]. PagerDuty’s supporting services are the technical (or business) services a business service requires.^[31] Field names vary by version, so treat the table as a starting map.

The labs need Python 3.8+, no network, cost or risk, and share one data file. They were executed on 2026-10-18 (Python 3.8.10, Linux); expected output is actual output. Work in a new empty directory.

Example status: JSON and Python syntax-checked and executed.

{
  "as_of": "2026-10-18",
  "teams": {
    "team-checkout": {"oncall": "sched-checkout"},
    "team-payments": {"oncall": "sched-payments"},
    "team-pricing": {"oncall": "sched-pricing"},
    "team-data-platform": {"oncall": "sched-data"},
    "team-discovery": {"oncall": null}
  },
  "services": [
    {"id": "online-ordering", "kind": "business", "tier": 1,
     "owner": "team-checkout", "slo": null, "reviewed": "2026-09-30",
     "deps": [{"id": "checkout-api", "critical": true}]},
    {"id": "checkout-api", "kind": "technical", "tier": 1,
     "owner": "team-checkout", "slo": 99.95, "reviewed": "2026-09-30",
     "deps": [{"id": "payments-gw", "critical": true},
              {"id": "pricing-svc", "critical": true},
              {"id": "orders-db", "critical": true},
              {"id": "legacy-tax", "critical": true},
              {"id": "recs-svc", "critical": false}]},
    {"id": "payments-gw", "kind": "technical", "tier": 1,
     "owner": "team-payments", "slo": 99.99, "reviewed": "2026-08-14",
     "deps": [{"id": "orders-db", "critical": true},
              {"id": "fraud-scoring", "critical": true}]},
    {"id": "pricing-svc", "kind": "technical", "tier": 2,
     "owner": "team-pricing", "slo": 99.9, "reviewed": "2026-03-02",
     "deps": [{"id": "orders-db", "critical": true}]},
    {"id": "fraud-scoring", "kind": "technical", "tier": 2,
     "owner": "team-payments", "slo": 99.95, "reviewed": "2026-07-01",
     "deps": []},
    {"id": "orders-db", "kind": "resource", "tier": 1,
     "owner": "team-data-platform", "slo": 99.99, "reviewed": "2026-10-01",
     "deps": []},
    {"id": "legacy-tax", "kind": "technical", "tier": 3,
     "owner": "team-finance-it", "slo": 99.5, "reviewed": "2025-11-20",
     "deps": []},
    {"id": "recs-svc", "kind": "technical", "tier": 3,
     "owner": "team-discovery", "slo": 99.0, "reviewed": "2026-06-11",
     "deps": []}
  ]
}

Objective: measure ownership, on-call, SLO and review coverage, and list the records to fix. Prerequisites: Python 3.8+; about 30 minutes. Steps: (1) save the data above as services.json and the script below as catalog_check.py; (2) run python3 -I catalog_check.py services.json; (3) fix the four problems in a copy, services-fixed.json (set online-ordering’s slo to 99.9, a target for completed orders; move legacy-tax to team-payments; give team-discovery a schedule; set pricing-svc’s reviewed to 2026-10-15) and run the script on it.

"""Check service records: owner, on-call, SLO and review freshness."""
import json
import sys
from datetime import date

MAX_REVIEW_AGE_DAYS = {1: 90, 2: 180, 3: 365, 4: 365}


def needs_slo(s):
    """Tiers 1-2 need an SLO; a business service needs one at tier 1."""
    return s["tier"] == 1 or (s["tier"] == 2 and s["kind"] != "business")


def check(path):
    data = json.load(open(path, encoding="utf-8"))
    today = date.fromisoformat(data["as_of"])
    teams = data["teams"]
    services = data["services"]
    problems = []
    owned = paged = slo_needed = slo_set = fresh = 0
    for s in services:
        team = teams.get(s["owner"])
        if team is None:
            problems.append(f"{s['id']}: owner {s['owner']} is not an active team")
        else:
            owned += 1
            if team["oncall"]:
                paged += 1
            else:
                problems.append(f"{s['id']}: owner {s['owner']} has no on-call")
        if needs_slo(s):
            slo_needed += 1
            if s["slo"] is None:
                problems.append(
                    f"{s['id']}: tier {s['tier']} {s['kind']} service has no SLO")
            else:
                slo_set += 1
        age = (today - date.fromisoformat(s["reviewed"])).days
        if age <= MAX_REVIEW_AGE_DAYS[s["tier"]]:
            fresh += 1
        else:
            problems.append(f"{s['id']}: tier {s['tier']} review is {age} days old")
    n = len(services)
    print(f"services: {n}")
    print(f"ownership coverage: {owned}/{n} = {owned / n:.1%}")
    print(f"on-call coverage:   {paged}/{n} = {paged / n:.1%}")
    print(f"SLO coverage (tiers 1-2):  {slo_set}/{slo_needed}")
    print(f"reviews within policy: {fresh}/{n} = {fresh / n:.1%}")
    for p in problems:
        print("PROBLEM", p)
    return 1 if problems else 0


if __name__ == "__main__":
    sys.exit(check(sys.argv[1]))

Expected output (step 2; exit code 1):

services: 8
ownership coverage: 7/8 = 87.5%
on-call coverage:   6/8 = 75.0%
SLO coverage (tiers 1-2):  5/6
reviews within policy: 7/8 = 87.5%
PROBLEM online-ordering: tier 1 business service has no SLO
PROBLEM pricing-svc: tier 2 review is 230 days old
PROBLEM legacy-tax: owner team-finance-it is not an active team
PROBLEM recs-svc: owner team-discovery has no on-call

Validation: on the fixed copy every coverage line is complete (SLO 6/6) and the exit code is 0. Troubleshooting: JSONDecodeError usually means a trailing comma; a KeyError on a tier means a value outside 1–4. Teardown: delete the directory. Next: feed teams from your directory and paging tool; that check catches reorganisations.

Objective: list a service’s unique critical dependencies, the availability its dependencies allow, tier inversions, and what a failing component takes down. Prerequisites: Lab 1’s unfixed services.json. Steps: save blast_radius.py, then run python3 -I blast_radius.py services.json checkout-api orders-db.

"""Critical dependencies, availability ceiling, tier inversions, blast radius."""
import json
import sys


def load(path):
    data = json.load(open(path, encoding="utf-8"))
    return {s["id"]: s for s in data["services"]}


def critical_deps(svc, services, seen=None):
    """Unique transitive critical dependencies, each counted once."""
    seen = set() if seen is None else seen
    for d in services[svc]["deps"]:
        if d["critical"] and d["id"] not in seen:
            seen.add(d["id"])
            critical_deps(d["id"], services, seen)
    return seen


def dependants(target, services):
    """Services that fail when target fails (reverse critical closure)."""
    return sorted(s for s in services if target in critical_deps(s, services))


def main(path, svc, failing):
    services = load(path)
    deps = sorted(critical_deps(svc, services))
    ceiling = 1.0
    for d in deps:
        ceiling *= services[d]["slo"] / 100
    print(f"{svc}: SLO {services[svc]['slo']}%, {len(deps)} unique critical deps")
    print("  " + ", ".join(deps))
    print(f"  ceiling if failures are independent: {ceiling:.4%}")
    for d in deps:
        if services[d]["tier"] > services[svc]["tier"]:
            print(f"  TIER INVERSION: tier {services[svc]['tier']} {svc} "
                  f"needs tier {services[d]['tier']} {d}")
    print(f"if {failing} fails, affected: {', '.join(dependants(failing, services))}")


if __name__ == "__main__":
    main(sys.argv[1], sys.argv[2], sys.argv[3])

Expected output (exit code 0):

checkout-api: SLO 99.95%, 5 unique critical deps
  fraud-scoring, legacy-tax, orders-db, payments-gw, pricing-svc
  ceiling if failures are independent: 99.3309%
  TIER INVERSION: tier 1 checkout-api needs tier 2 fraud-scoring
  TIER INVERSION: tier 1 checkout-api needs tier 3 legacy-tax
  TIER INVERSION: tier 1 checkout-api needs tier 2 pricing-svc
if orders-db fails, affected: checkout-api, online-ordering, payments-gw, pricing-svc

Reading it. orders-db sits on three paths but counts once, as the calculus paper prescribes.^[9] The ceiling multiplies SLO targets, not measured availability (0.9995 × 0.995 × 0.9999 × 0.9999 × 0.999 ≈ 0.9933), assumes independent failures and double-counts (payments-gw’s target already absorbs some orders-db failures); fully correlated failures would lift it only to the weakest target, 99.5%. Either way a 99.95% SLO is not credible while legacy-tax is critical. The arithmetic is on SRE; who acts is mastery question 2. Validation: mark legacy-tax non-critical (as if checkout fell back to a cached tax table) and rerun: four dependencies, ceiling 99.8301%, two inversions (checked by execution). Troubleshooting: a KeyError names an unregistered dependency, itself a finding. Teardown: none beyond Lab 1.

Objective: compare declared dependencies with calls seen in traces, and find unnamed telemetry. Prerequisites: Labs 1–2; for real data, a trace backend that produces service-graph metrics (not needed for the sample). Status: the Python part was executed; the PromQL export was not executed (no Tempo instance in this environment).

Tempo pairs client and server spans into edges, exposed as traces_service_graph_request_total with client and server labels; uninstrumented peers become virtual nodes named from attributes such as peer.service or db.system.^[43] Export a week:

sum by (client, server) (increase(traces_service_graph_request_total[7d])) > 0

Save the sample export as observed.csv:

client,server,requests_7d
checkout-api,payments-gw,412870
checkout-api,pricing-svc,398112
checkout-api,orders-db,820455
checkout-api,recs-svc,95230
checkout-api,promo-engine,61002
payments-gw,orders-db,407991
payments-gw,fraud-scoring,405116
unknown_service:java,orders-db,1290

"""Compare declared dependencies with edges observed in traces."""
import csv
import json
import sys


def main(catalog_path, observed_path):
    services = json.load(open(catalog_path, encoding="utf-8"))["services"]
    kind = {s["id"]: s["kind"] for s in services}
    known = set(kind)
    declared = {(s["id"], d["id"]) for s in services for d in s["deps"]}
    observed = set()
    unnamed = []
    with open(observed_path, newline="", encoding="utf-8") as f:
        for row in csv.DictReader(f):
            edge = (row["client"], row["server"])
            if row["client"].startswith("unknown_service"):
                unnamed.append(edge)
            elif int(row["requests_7d"]) > 0:
                observed.add(edge)
    # Business services emit no spans: compare only edges whose client
    # is a technical service or a resource.
    in_scope = {e for e in declared if kind[e[0]] != "business"}
    undeclared = sorted(observed - declared)
    silent = sorted(in_scope - observed)
    print(f"declared {len(in_scope)}, observed {len(observed)}")
    for c, s in undeclared:
        tag = "" if s in known else " (server not in catalog)"
        print(f"UNDECLARED {c} -> {s}{tag}")
    for c, s in silent:
        print(f"NOT OBSERVED {c} -> {s} (stale, uninstrumented or rare path)")
    for c, s in unnamed:
        print(f"UNNAMED CALLER {c} -> {s}: set service.name")
    drift = (len(undeclared) + len(silent)) / len(in_scope)
    print(f"drift ratio: {drift:.0%}")
    return 1 if undeclared or unnamed else 0


if __name__ == "__main__":
    sys.exit(main(sys.argv[1], sys.argv[2]))

Run python3 -I drift.py services.json observed.csv. Expected output (exit code 1):

declared 8, observed 7
UNDECLARED checkout-api -> promo-engine (server not in catalog)
NOT OBSERVED checkout-api -> legacy-tax (stale, uninstrumented or rare path)
NOT OBSERVED pricing-svc -> orders-db (stale, uninstrumented or rare path)
UNNAMED CALLER unknown_service:java -> orders-db: set service.name
drift ratio: 38%

Interpreting. promo-engine is an unregistered dependency: find its owner. legacy-tax may be called uninstrumented or by a nightly batch; ask before deleting the edge. unknown_service:java is a process with no service.name.^[28] Validation: register promo-engine and declare its edge; set service.name on the Java process (say batch-reconciler), re-export, and register it with its orders-db dependency. Only the two “not observed” lines remain, drift falls to 20% and the exit code is 0 (checked by execution). Troubleshooting: missing edges can mean spans of one trace reached different instances, which Tempo cannot pair reliably; check traces_service_graph_unpaired_spans_total.^[43] Teardown: delete the directory.

The requirements cited below are real; the organisations and numbers are illustrative scenarios.

Notes. Regulated firm: model the business function first, as DORA^[10] and the FCA^[11] frame it. Microservice estate: at Spotify’s 2020 scale^[17] checks must be automated. Service desk meets operations: BMC Helix’s single incident and change-driven blackouts^[1] need alerts and changes to name the same service. ESM: reuse the model; do not build a second catalogue.

Measure the model, then the outcomes it should improve. Service-level metrics themselves (SLOs, MTTR) belong to SRE and IncidentOps; the formulas below measure whether the model can be trusted.

Ownership, reachability and freshness lead; attribution and change impact recall lag, showing whether the model helps in incidents. Vanity traps: CI counts, catalogue percentages without a fixed scope, averages that hide tier-1 failures.

An illustrative quarter: 120 services in scope; 114 have an active owner team, and 109 of those have a staffed schedule.

• Ownership coverage = 114 ÷ 120 = 95.0%; reachability = 109 ÷ 120 = 90.8%. Target 100% for tiers 1–2, 98% or better for the rest.
• 240 incidents; 198 kept the service they were opened on → first-time-right attribution = 198 ÷ 240 = 82.5%; study the 42 misses.
• 30 change-caused incidents; 21 had the failing service listed on the change → change impact recall = 21 ÷ 30 = 70%.
• 412 declared edges; 37 undeclared and 52 not observed → drift = (37 + 52) ÷ 412 = 21.6%.

Set targets after the baseline: from 82.5% attribution, 90% in two quarters is a fair aim.

• The model is a target map of your critical services and weak points: limit bulk export, log access, keep it out of public repositories.
• Ownership is not authorisation. Backstage’s owner field “is not to be used by automated processes to for example assign authorization in runtime systems”.^[30] Grant production access through the identity provider.
• Personal data. Point records at schedules and team aliases, not personal phone numbers. AWS advises company-owned contacts so they still work after people leave;^[7] aliases also keep personal numbers out of the register.
• Audit trail. Log who changed an owner, tier or critical flag, and why; keep dated register snapshots. DORA expects inventories updated periodically and after major changes.^[10]
• Jurisdiction. DORA covers EU financial entities, the FCA rules UK firms in scope; other sectors may have neither. This page is not legal advice.

The main cost is people’s time: owners’ reviews (our estimate: 30–60 minutes per tier-1 service a quarter; measure yours), a part-time model owner and integration work. Licences matter less than whether owners edit the records. A service tag on cloud resources makes the model the allocation key for cost per service (FinOps); AWS counts financial accountability as one meaning of ownership.^[7] The “no traffic, no dependants” retirement test also finds idle resources to switch off (GreenOps).

Checks can pass while the model is wrong. Monthly, test ten random records: page the schedule in a test window, have the owner confirm dependencies, compare the tier with the sponsor’s view. Track exception age, and send every attribution failure to the model owner; one misrouted page matters more than a 1% change in coverage.

Illustrative scenario. At 02:10 checkout error rates rise. The alert names legacy-tax; the paging tool shows “no on-call schedule” because team-finance-it was dissolved in a reorganisation two months earlier. Nobody acknowledges for 25 minutes.

1. Contain (incident manager, minutes 0–10). Page the parent organisation’s fallback and the dependant tier-1 owner (team-checkout), who can degrade gracefully (cached tax table).
2. Find a human (minutes 10–20). Check deployment history for whoever last changed legacy-tax; ask the former team’s manager. Record the time spent: it is the cost of the gap.
3. Restore as the incident process directs (IncidentOps).
4. Repair the record under the escalation rule: interim owner, then an accepted transfer.
5. Find siblings. Run Lab 1 across the estate for every service owned by the dissolved team.
6. Fix the inversion found by Lab 2: raise the tier and staff it, make the dependency non-critical, or lower checkout’s promise.
7. Prevent. Transfers on the reorganisation checklist; weekly directory check; alert when a team with services is deleted.

Verification: a test page to the new schedule is acknowledged; Lab 1 shows no services owned by deleted teams; the incident review lists the record failure as a contributing factor.

• “Buy the platform, get ServiceOps.” Suites share data but do not decide who owns what; BMC’s own approach rests on “dynamic service models”.^[2] Instead: fix ownership and naming first.
• CMDB first, owners later. Thousands of CIs, nobody accountable. Instead: model critical services with owners, then extend discovery beneath them.
• Ownership by committee. “Shared by three teams” means nobody is paged. Instead: split the service or choose one owner.^[29]
• Everything is tier 1. Tiers then stop ranking anything. Instead: use the rubric; cap tier 1 by requiring a business sponsor.
• The developer portal as business catalogue. Business users do not read component lists. Instead: publish business services linked to components.
• Myth: “AI will discover our services.” Tools observe calls and hosts; they cannot infer accountability or business meaning.

Invest in a service model when several teams share on-call or a service desk; when incidents start with “who owns this?”; when changes break services nobody listed; when regulators or customers ask for mapping; or when ITSM and monitoring cannot be joined.

Do not run a ServiceOps programme when one team builds and runs one product: owners in the repository and a paging tool suffice. Do not buy a platform while ownership is contested; it will store the dispute. Do not model configuration items nobody will consult. Hidden responsibilities: someone owns the schema and checks indefinitely, and every reorganisation gains a modelling task.

%%{init: {"flowchart": {"wrappingWidth": 150, "nodeSpacing": 14, "rankSpacing": 26}}}%%
flowchart TB
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029
  Q1{"More than one team on call, or a shared service desk?"}:::decision
  N1["Keep a short owner list in the repo; stop here"]:::neutral
  Q2{"Can each critical service name one owner team today?"}:::decision
  N2["Settle ownership first; no tool purchase yet"]:::neutral
  Q3{"Do engineers already maintain records beside the code?"}:::decision
  I["ITSM-centred master; portal reads it"]:::core
  Q4{"Regulated, or many business and non-software services to record?"}:::decision
  P["Portal-centred master; sync to ITSM"]:::core
  F["Federated: portal masters component fields, ITSM the business layer; one ID registry"]:::core
  Q1 -->|"no"| N1
  Q1 -->|"yes"| Q2
  Q2 -->|"no"| N2
  Q2 -->|"yes"| Q3
  Q3 -->|"no"| I
  Q3 -->|"yes"| Q4
  Q4 -->|"no"| P
  Q4 -->|"yes"| F

The tree assumes portal adoption predicts whether engineers keep records current, and that auditors and the service desk read ITSM records; test both locally. The judgement call lands on the federated leaf.

This model is the Atlas’s proposal, not an industry standard.

Quick wins: fix pages to dissolved teams; name the unknown_service processes; publish business services on the status page. Dependencies: a directory export of teams, the paging tool’s API, and a model owner with time.

• Scope written down: which services count as “production” for the register
• Record schema and tier rubric agreed
• Every tier-1 and tier-2 service has one owner team and a staffed schedule
• service.name equals the register ID in every deployment
• Fallback queue and escalation rule for unknown or unowned services

• Owner team accepted by its manager; service owner named
• Tier set with a business sponsor’s agreement
• Critical dependencies declared; no tier inversion, or a recorded decision
• SLO defined for tier 1–2 (SRE); OLAs on tier-1 critical edges; runbook and dashboard linked
• Readiness review passed^[33]

• List every service owned by affected teams before announcing changes
• Receiving managers accept each transfer; test page acknowledged
• Old groups deleted only after their services have moved

• Coverage, drift, attribution and inversion trends reviewed
• Ten records sampled and tested
• Exceptions older than 30 days escalated
• Write access to the register and the sync identities reviewed; owner and tier changes traced in the audit log

Service ID:            checkout-api          Kind: technical
Name and purpose:      Takes a basket to a paid order
Business service(s):   online-ordering
Owner team:            team-checkout         Service owner: <name, role>
On-call reference:     <schedule ID>         Escalation: <policy ID>
Tier:                  1   Rationale: customers cannot pay when it fails
Lifecycle state:       production            Last reviewed: 2026-09-30
Critical dependencies: payments-gw, pricing-svc, orders-db, legacy-tax
Other dependencies:    recs-svc
SLOs:                  <link>                SLAs that rely on it: <link>
OLAs (critical edges): one per edge owned by another team: <link>
Runbook / dashboard:   <link> / <link>
Identifiers:           service.name=checkout-api; CMDB=<id>; cost tag=<tag>
Data / regulation:     payment data; DORA Art. 8 inventory: yes; Art. 28 register: <ref>

1. Requesting manager lists services, open incidents, open changes, open risks.
2. Receiving manager reviews runbooks, SLOs, dependencies; may refuse with reasons.
3. Both managers approve the transfer in the register (owner team, service owner);
   in Git, the model owner's code-owner review merges it.
4. Paging: receiving schedule added; test page acknowledged; old schedule removed.
5. Access: production access granted through the identity provider, not the record.
6. Record "reviewed" date set; model owner informed; transfer closed.

1. Service levels: SLO, SLA and OLA results; customer feedback; breaches and causes.
2. Incidents: count, attribution misses, repeat causes, actions overdue.
3. Dependencies: drift report, tier inversions, supplier issues.
4. Changes ahead: launches, migrations, retirements, reorganisations.
5. Decisions: tier, levels, investment; owners and dates for each action.

Title:     Master record for services
Context:   Tools in use; who edits today; audit and regulatory needs
Options:   ITSM-centred | portal-centred | federated with ID registry
Decision:  <option>, with field-level masters: owner=<system>, tier=<system>...
Sync:      direction, frequency, conflict rule (master wins; diff raised)
Review:    in 6 months, against attribution and freshness metrics

Is ServiceOps a job title? We found no standard role of that name. The work is done under titles such as service owner, service catalogue manager (an ITIL V3 role^[23]), ITSM platform owner or platform engineer.

Do we need ServiceNow or BMC Helix? No. The model can live in Jira Service Management, Backstage, a paging tool or a file in Git, if every system stores the same ID. Suites help most when they already run your incidents and changes.

Who should own a shared database or Kubernetes cluster? One platform team, as its own service with its own SLO and tier. If it is a critical dependency of tier-1 services, it is tier 1.

How is an SLA different from an SLO? An SLA is the agreement with consequences; SLOs are internal targets beneath it.^[25] Which tier needs which is under service levels by tier.

How do we stop the register going stale? Give every field a consumer (paging, change approval, cost allocation), check it automatically, and tie reviews to tier. Data nobody uses decays fastest.

• Established: joining tickets, alerts and changes on service IDs; scheduled discovery of application services^[39]; service graphs from traces^[43]; business services above technical ones.^[31]
• Maturing: AI agents proposing root causes and change risk^[1]; test them on your own incidents, as the map bounds them.
• Moving: portals. Compass scorecards and catalogue “will transition into the DX app”;^[41] check exit paths first.
• Regulatory pull: DORA pushes maps out to the suppliers behind critical functions.^[10]
• Open question: how much can be inferred safely. Observed edges are facts about calls, not criticality or accountability.

• Prerequisites: as at a glance, plus what traces are (ObservabilityOps).
• One day: read the service record and run Lab 1 on ten of your own services.
• One week: tier those services with the rubric; run Lab 2; list inversions and owners for each.
• 30 days: follow the 30-day roadmap block; measure attribution on real incidents.
• Specialise: CSDM or ITSM data modelling; Backstage catalogue engineering; resilience mapping for regulated firms.
• Portfolio project: a reconciler joining register, directory, paging tool and trace export into an exception list.

• What it is: a vendor label for joining ITSM and IT operations; in practice, a shared service model.
• Decide first: the master for each field, the schema owner, the scope.
• Practices: one reachable owner team per service; tiers by impact that set levels, health rules and change rigour; critical dependencies declared and reconciled; transfers in every reorganisation.
• Metrics: ownership, reachability, freshness, drift, attribution, change impact recall, tier inversions.
• Watch-outs: platforms before ownership; tier 1 everywhere; maps nobody consumes.
• Next action: run Lab 1 on your 20 most critical services this week.

Situation (illustrative). A 900-person software company uses ServiceNow for incidents and changes, a Backstage portal and PagerDuty; owner data disagrees across them for about a fifth of services. The CIO wants the CMDB as master because auditors read it; the platform lead wants catalog-info.yaml in each repository.

Option 1: ITSM master. Owners edit service records in ServiceNow; the portal reads them. Option 2: portal master. Owners edit YAML beside the code in reviewed pull requests; a sync job writes to ServiceNow and PagerDuty.

Assumptions. Engineers already edit portal metadata; auditors need ITSM records but not ITSM editing; business services and non-software services (payroll, the office network) also need records.

Evidence. Backstage requires owner on every component,^[30] so the portal already collects ownership where engineers work. CSDM ties service records to impact in incident, problem and change,^[32] which auditors and the service desk consume. AWS accepts a central register or resource metadata for owners;^[7] what matters is one answer.

Why the attractive choice can be wrong. Option 1 satisfies audit but asks engineers to maintain records in a tool they rarely open, so owners go stale: the original problem. Option 2 keeps owners current but leaves business services, suppliers and non-software services homeless, and a broken sync silently splits the truth again.

Decision process. Decide per field, not per system. The table is the Atlas’s proposal for this company; a narrowly scoped identity writes the changes (trust boundaries).

Measure attribution and the weekly owner-mismatch count before and after.

Expected result, with uncertainty. Software owner mismatches should approach zero within a quarter if the sync is monitored (a sync failure longer than a day raises an exception). The business layer depends on business owners attending reviews, the least predictable part.

You should now be able to explain the label and its status; design a service record; tier services, find inversions and attach the levels each tier needs; reconcile dependencies; measure the model; and decide where the master record lives.

1. A vendor says its platform “delivers ServiceOps”. What do you check before believing that it will help you?

2. Lab 2 shows tier-1 checkout-api critically depending on legacy-tax, tier 3, whose owner team was dissolved. Who must act, and through which records?

3. Two teams “share” ownership of the payments gateway. Why is that a problem, and what are the fixes?

4. The drift report shows checkout-api -> legacy-tax declared but not observed. Should you delete the edge?

5. Which of these is ServiceOps on this page, and which belongs to a neighbour: (a) the SLA clock pause rule, (b) choosing the owner team of a new service, (c) the error-budget policy, (d) grouping 40 alerts into one situation?

6. An EU bank’s supervisor asks how it identifies the dependencies of its critical functions. Which records answer that?

“ServiceOps” is a young vendor label for an old ambition: make service management and operations work from one picture. The label will probably change; the picture will not. It is a list of services that consumers recognise, each with one team that answers the pager, a tier that means something, dependencies that match what actually runs, and service levels someone agreed to.

Tools can share that picture, correlate against it and increasingly reason over it. They cannot decide who is accountable, which failure the business can tolerate, or whether a dependency matters. Organisations that settle those questions find most ServiceOps promises follow; those that skip them buy a faster way to page the wrong team.

All sources were opened on 2026-10-18; dates are the sources’ own. Claim-level support and caveats: research/serviceops-ledger.md.

Changelog. 2026-10-18, r0: first draft by the managing author (term status confirmed as vendor-specific; three labs executed); awaiting independent review. 2026-10-18, r1: after the independent fact check, decision tree aligned with the judgement call; new section on levels, health and change risk by tier; EMA 2025 result, Helix carve-out and tier-inversion figure added; labs fixed. 2026-10-18, post-score polish: Figure 2 re-routed so no edge passes the exceptions node; ITIL V3’s 2007 date sourced; field-level sync table and non-IT (ESM) record paragraph added; re-check triggers, register-access check and nested-quote typography added; “fifty alerts” example and two restatements of the escalation clock removed. 2026-10-18, polish check: ESM paragraph now lists three field changes plus the added catalogue entry; tooling re-check note distinguishes completed from ongoing changes; mastery answer 2 names the engineering lead again.