Chaos Engineering Platform  ·  View 03 of 21  ·  People and journeys

Actors and Their Core Journeys

Six actors, their goals in their own words, and the eleven journeys the platform has to serve.

Editable source SVG draw.io All views
They run the experiments Service owner ~180 teams Goal — Find out whether my service really survives the dependency I claim is optional — before a Friday night tells me Core journeys Prove a dependency timeout journey 04 Promote to scheduled 3 passing runs Close a finding fix, then re-run Reliability engineer central, 9 people Goal — Know which failure classes the fleet has actually been tested against, and which are still guesses Core journeys Facilitate a game day journey 05 Read coverage gaps untested set Suspend a fault class after a stuck revert They are affected by them On-call responder rotation per service Goal — Never be paged by an experiment I did not know was running, and always be able to stop one Core journeys See the annotation on their dashboard Press stop ≤ 10 s to clear Tier-1 approver named per service Goal — Say yes to a bounded, reversible test and no to an outage with paperwork Core journeys Review a radius escalation time-boxed They consume the output Engineering lead per domain Goal — Show that resilience work happened and that the weaknesses found were actually fixed Core journeys Read the coverage report quarterly Deployment pipeline automated Goal — Refuse to promote a canary that a resilience suite just refuted Core journeys Gate on a verdict pre-promotion Actors and Their Core Journeys The customer never appears here by design: a run the customer notices has already failed its guardrails. v 1.0 · owner Reliability Architecture · date 2026-09

Decisions

  • Service owners run their own experiments. A central team that runs chaos on other people's services produces findings nobody feels responsible for.
  • The on-call responder is a first-class actor with two journeys of their own: seeing the annotation, and pressing stop. Neither is a feature request.
  • The deployment pipeline is an actor, not an integration. It has a goal — refuse to promote a refuted canary — and the platform owes it a verdict it can gate on.

Assumptions

  • About 180 owning teams and a central reliability group of nine, which is what makes self-service mandatory rather than nice.
  • Tier-1 services have a named approver in the service catalogue.

What this changes

  • Because the reliability engineer's goal is coverage rather than execution, the untested-dependency report is a first-class output and not a dashboard afterthought.
  • Because the approver's goal is bounded reversibility, the approval card has to show the computed radius, not the requested one.
◀  High-Level Architecture All views Journey — Proving a Dependency Is Really Optional  ▶
Solution Architecture v1.0 · Google Cloud · Reliability Architecture · 2026-09 · 21 views · 16 architecture decision records03-actors-and-journeys