Tvärsystemdrift, incidenter och SLO

Ett grönt system kan ge ett felaktigt beslut.

Det påståendet låter motsägelsefullt bara om “systemet” betyder en process och “grönt” betyder att processen svarar. För en handläggare kan tjänsten vara oanvändbar trots att alla pods är Ready: informationen kan vara gammal, en källa kan saknas, sambandet mellan två identiteter kan vara fel eller Matrix egen sammanställning kan ha stannat. Omvänt kan en redundant komponent vara röd utan att användarens resa bryts.

Kapitlets utgångspunkt är därför:

Driftens objekt är ett löfte till en användare eller en annan tjänst, inte färgen på en komponent.

Det betyder inte att komponenthälsa är oviktig. Den är nödvändig diagnostik. Men komponenthälsa, tjänstenivå, SLO-uppfyllelse och incidentstatus är fyra olika påståenden [CLAIM-OPS-001]. De har olika populationer, tider, källor och konsekvenser.

1. Sex begrepp som inte får kollapsas

En observation är en tidsatt avläsning: en pod var Ready, en endpoint gav HTTP 200, en kö hade sex READY-poster eller ett event anlände.

En hälsobedömning tolkar observationer mot en teknisk definition. Matrix Platform använder healthy, degraded, down och unknown. unknown är inte en mild variant av grönt; det betyder att underlaget inte räcker.

En SLI, service level indicator, är ett kvantitativt mått på en egenskap som en användare bryr sig om. “Andel beslut där samtliga deklarerade källor var färska och täckta” kan vara ett SLI. CPU-procent är vanligen diagnostik.

Ett SLO, service level objective, sätter ett mål eller intervall för ett SLI under ett bestämt fönster. Ett SLO är inte ett kontrakt bara för att det har en procentsats. En SLA innehåller dessutom uttalade konsekvenser mellan parter.

Ett larm är en begäran om tidsrelevant mänsklig eller automatiserad handling. Telemetry som ingen behöver agera på nu är logg eller analysdata, inte ett larm.

En incident är en hanterad händelse där faktisk eller möjlig påverkan måste samordnas. Den behöver en egen identitet, starttid, klass, roller, tidslinje, påverkan och avslut. Ett larm kan öppna en incident; hundra korrelerade larm kan fortfarande vara en incident. Ett fynd kan bli en förbättring utan att någonsin vara en incident [CLAIM-OPS-006].

2. Vad Matrix redan gör väl

Matrix monitoring-definition skiljer definition från observation. Per system kan den beskriva health-endpoints, nyckelmetriker, signaler, evidensgrad, källreferens och täckning. Saknad dokumentation blir partial eller missing, inte en uppfunnen endpoint.

Hälsoproben har ytterligare en viktig asymmetri. En försämrande signal, som många felrader i Loki, får göra läget rött. Men noll felrader får inte ensam göra läget grönt: ett avstängt namespace kan också producera noll fel. healthy kräver minst en auktoritativ positiv signal. Det är ett exempel på att positiv och negativ evidens inte behöver ha samma bevisstyrka.

Den schemalagda kedjan skriver status på varje försök. Vid fel flyttas inte lastSuccessAt fram. Läsaren fäller en bild vars senaste lyckade körning är äldre än två intervall — normalt 60 minuter. En gammal fil kan alltså inte fortsätta se grön ut bara för att ingen längre uppdaterar den.

Matrix självobservation deklarerar dessutom egna komponenter: bryggan, Coordinator-kön, Matrix-Qdrant, MCP-servern, grafaggregatet och Foundry- embeddingberoendet. Varje deklarerad komponent måste få en observation eller ett uttalat unknown. Det förverkligar kärninsikten från kapitel 11:

Matrix kan inte trovärdigt förklara andra system om det inte lika tydligt kan förklara sitt eget tillstånd.

JAKE:s hälsovy lägger till lokala services, timers, HTTP-prober, aktiviteter, modellkö, restore proof, auditkedjeverifiering och secret rotation. Dess larmkontrakt kräver kind, begriplig etikett, konsekvens och ägarroll. Om ett datum nämns i konsekvensen måste samma datum vara maskinläsbart. Ett trasigt larm får inte slå ut alla giltiga larm; kontraktsbrottet visas separat.

Detta är bra kontrollsystemsdesign. Men det är ännu inte ett komplett driftsystem.

3. Hälsa är en lokal teknisk bedömning

Anta att Nordic har följande kedja:

ärendeportal → identitet → AppWorks → xECM → Matrix beslutssammanställning

Varje komponent kan ha en egen health-definition. Ingen enskild definition svarar på om handläggaren kan:

1. öppna rätt ärende,
2. se alla relevanta dokument,
3. få en aktuell regelbedömning,
4. förstå osäkerheten,
5. slutföra beslutet inom verksamhetens tidsgräns.

En statisk /health som svarar 200 bevisar processnåbarhet. Kubernetes readiness bevisar att plattformen anser poden redo enligt dess probe. SELECT 1 bevisar databaskontakt. Inget av detta bevisar att rätt data hämtats eller att hela resan fungerar.

Matrix bör därför visa hälsa i två riktningar:

• inåt: komponenter, dependencies, kontrollplan, telemetry och prober,
• utåt: användarresor, beslut, populationscoverage och löften.

Den inre bilden hjälper oss förklara varför. Den yttre bilden avgör om det spelar roll just nu.

4. Besluts-SLI:er för Matrix

Googles SRE-litteratur rekommenderar att börja med vad användaren bryr sig om, inte med vad som råkar vara lätt att mäta. För Matrix innebär det att vanlig availability och latency behöver kompletteras med egenskaper hos själva beslutsunderlaget [CLAIM-OPS-002].

4.1 Svarbarhet

Kan en giltig fråga få ett maskinellt användbart svar? Populationen måste definieras. Nekade anrop som korrekt bryter mot behörighet är inte tjänstefel; interna 500-fel är det. unknown får inte kodas som success.

4.2 Beslutstid

Hur lång tid går från accepterad fråga till beslutbart svar? Mätpunkten bör ligga så nära konsumenten som möjligt. Serverlatens missar klient-, nät- och beroendefel. Percentiler visar lång svans bättre än medelvärde.

4.3 Färskhet

Varje källa har egen freshnessbudget. Ett svar är “good” bara om de källor som krävs för frågan ligger inom sina budgetar. Ett globalt generatedAt får inte dölja att en delkälla är äldre.

4.4 Populationstäckning

Hur stor andel av den förväntade populationen kunde bedömas? Täljaren är bedömda objekt; nämnaren måste härledas från en namngiven definition. En oläsbar källa får inte minska nämnaren och därigenom förbättra procenten.

4.5 Korrekthet och verifierbarhet

För vissa svar kan korrekthet verifieras direkt mot en postcondition. För andra kan Matrix bara mäta evidenstäckning, konflikter, mänskliga overrides eller senare facit. Det är bättre att ha ett smalare, ärligt mått än en generisk “confidence score”.

4.6 Kontrollplansförmåga

För Coordinatorn behövs separata SLI:er: andel claims med giltig lease, heartbeat inom budget, lyckad reap, kötid, stagegenomströmning, korrelations- coverage och andel fleet ticks som kan återskapas. Dessa visar om Matrix kan utföra och förklara sitt eget arbete, inte om domänresultatet är korrekt.

5. SLO-kontraktet

Ett fullständigt SLO behöver minst följande [CLAIM-OPS-003]:

Ett första illustrativt Nordic-SLO kan lyda:

Under rullande 30 dagar ska minst 99 procent av behöriga ärendefrågor få ett beslutbart svar inom 10 sekunder. Ett good-event kräver att alla för frågan obligatoriska källor är inom sina freshnessbudgetar, att populationstäckningen är 100 procent för ärendet och att inga olösta blockerande konflikter finns. Mätcoverage under 99,5 procent gör SLO-status unknown, inte uppfylld.

Värdena är exempel, inte rekommenderade produktmål. Mål ska väljas med verksamhet, produkt, drift, säkerhet och kostnad — aldrig bara kopieras från dagens prestation.

SLI-matematik

För requestbaserade flöden:

SLI = good events / valid events

För ett mål SLO är felbudgeten:

error budget = 1 - SLO
burn rate = observerad bad-event-andel / tillåten bad-event-andel

Burn rate 1 förbrukar budgeten exakt i takt med fönstret. Högre burn rate hotar målet snabbare. Multi-window-larm kan kombinera ett långt fönster för precision med ett kort för att bekräfta att felet fortfarande pågår.

Glesa Matrixflöden kräver försiktighet. Om tio högriskactions sker per månad kan ett fel ge en enorm burn rate men också vara just det fel som aldrig får budgeteras bort. Då kan syntetiska journeys, batch-SLO, absoluta felgränser eller “zero tolerance”-säkerhetsinvarianter vara bättre än requestprocent.

6. Error budget är styrning, inte rabatt på säkerhet

Ett error budget gör avvägningen mellan förändringstakt och tillförlitlighet explicit. När budgeten är frisk kan teamet ta normal förändringsrisk. När den brinner snabbt kan man skärpa granskning, stoppa riskhöjande releaser eller prioritera återställande arbete.

Men budgeten gäller det definierade tjänstelöftet. Den ger aldrig lov att:

• korsa tenant- eller datagräns,
• läcka en hemlighet,
• acceptera en oåterkallelig action utan mandat,
• visa gammal data som färsk,
• dölja okänd mätcoverage,
• radera audit- eller incidentbevis.

Sådana egenskaper är constraints och riskgränser, inte statistiskt förbrukbar opålitlighet [CLAIM-OPS-004]. Ett system kan ligga inom availability-SLO och ändå ha en säkerhetsincident.

7. Från signal till larm

Ett bra larm svarar på fem frågor:

1. vilket löfte eller vilken kontroll hotas?
2. vilken population påverkas eller kan påverkas?
3. vad händer om ingen agerar, och när?
4. vem äger första handlingen?
5. vilken runbook eller säkra nästa handling finns?

JAKE:s kontrakt täcker redan kind, label, consequence och owner och kan bära deadline. Det är starkare än en rå “service down”. Men dagens larm är läs-härledda. Incidentrutinen konstaterar uttryckligen att de saknar beständig skrivväg, acknowledgement, timupplöst deadline och garanterad realtidsväckning.

Det ger en tydlig hierarki:

telemetry → bedömning → larm → acknowledgement → incident → åtgärd → verifiering

En dashboard är inte en notifieringskanal. Ett larm som endast syns nästa gång någon öppnar sidan har inte väckt någon. För varje allvarlighetsklass måste Matrix kunna säga kanal, mottagare, leveranskvitto, eskaleringsregel och vad som händer när mottagaren inte svarar [CLAIM-OPS-005].

Alert deduplication måste ske på orsak och påverkan, inte bara text. Ett identitetsfel kan skapa hundra följdlarm i AppWorks, xECM och Coordinatorn. Operatören behöver en incident med hundra relaterade signaler, inte hundra konkurrerande sanningsanspråk.

8. Incidenten som eget objekt

Matrix säkerhetsincidentrutin är ovanligt konkret. Den skiljer incident från larm och fynd, klassar K1–K3, kräver bevissäkring före sanering, namnger ägare, hanterar extern parts mandat och definierar rapporteringsklockor. Den har också torrövats och bevarar sina tidigare underkännanden.

Begränsningen är lika viktig: rutinen är säkerhetscentrerad och lagras som Markdown. Den utgör ännu inte ett generellt operativt incidentlager. En tvärsystemdriftincident kan vara allvarlig utan hemlighetsläckage: exempelvis att alla Nordic-beslut bygger på en ofullständig population i sex timmar.

Ett generellt incidentobjekt bör bära:

• incident_id, status, klass och deklarationstid,
• upptäckts-, påverkan-, mitigation-, recovery- och stängningstid,
• berörda tjänstelöften, tenants och användarresor,
• incident commander, operations lead och communications lead,
• relaterade alerts, changes, work items, agents och externa ärenden,
• observerade fakta med källor,
• arbetshypoteser och deras status,
• beslut, approvals och exakta actions,
• kommunikationsmottagare och kvitton,
• verifieringsplan och recovery evidence,
• kvarvarande risk och postmortem/action items.

Incidenten får inte bli en enda fritext. Fakta kan ha hög evidensgrad; hypoteser kan vara falsifierade; beslut kan vara giltiga trots att hypotesen senare faller. Om allt lagras som “tidslinje” går dessa semantiska skillnader förlorade [CLAIM-OPS-007].

9. Roller under tryck

När tre eller fler arbetar parallellt bör incident command skilja minst:

• Incident Commander: håller mål, prioritet, roller och lägesbild.
• Operations Lead: leder de som förändrar systemet.
• Communications Lead: ger tidsatta, målgruppsanpassade uppdateringar.
• Scribe/evidence lead: bevarar fakta, tider, hypoteser och beslut.

Små incidenter kan börja med en person, men rollerna ska fortfarande vara explicita. När fler ansluter delegeras de. Endast operationsspåret bör ändra systemet. Annars kan två välmenande aktörer samtidigt starta om, rollbacka och ändra routing och därmed förstöra både system och bevis.

Agentroller passar in, men mandatet förändras inte för att läget är akut. Coordinatorn kan samla observationer, föreslå hypoteser, simulera åtgärder, hålla tidslinjen och följa deadlines. Den får inte uppfinna credentials, korsa kundgränser eller själv godkänna en action som normalt kräver människa.

10. En evidensseparerad tidslinje

En incidentrad bör typas. Exempel:

Korrelation med OpenTelemetry kan hjälpa: trace och span kan knyta ihop ett anrop över services, metrics och logs. Men trace-ID ersätter inte incident_id, tenant_id, work_item_id, agent_run_id eller action_intent_id. Tekniskt exekveringssammanhang och domänidentitet är olika dimensioner.

11. Mitigation före förklaring

Under påverkan är första målet att begränsa skada och återställa tjänsten, inte att vinna rotorsaksdebatten. Det kan innebära att:

• markera berörda beslut som unknown eller stale,
• stoppa nya writes men behålla read-only observation,
• isolera en tenant eller connector,
• återgå till senaste verifierade konfiguration,
• köra en säker reservväg,
• be extern ägare vidta en åtgärd som Matrix saknar mandat för.

Varje handling ska fortfarande följa kapitel 10: plan, approval när det krävs, receipt och read-back. “Incident” är inte ett bypassord.

Coordinatorn ger särskilda risker. En död worker kan lämna en lease som senare reapas och redispatchas. Om det första försöket hann påverka ett externt system innan kontakten förlorades är utfallet unknown, inte “failed”. Recovery måste då reconcila receipt eller verkligt tillstånd innan retry.

12. Recovery är en hypotes tills användarresan är verifierad

Att en pod åter blir Ready visar att en teknisk förutsättning återställts. Det visar inte att:

• tappade events har spelats ikapp,
• köepisoder har rätt ägare och utfall,
• grafaggregatet täcker hela populationen,
• cache och index läser samma revision,
• externa writes har reconcilerats,
• användaren kan slutföra sitt arbete.

Recovery behöver därför en plan med flera nivåer:

1. komponent: process, dependency och storage svarar,
2. data: backlog, eventsekvens, index och auditkedja är konsistenta,
3. kontrollplan: claims, leases, fleet och agents är förklarliga,
4. användarresa: syntetiska och verkliga representativa journeys lyckas,
5. SLO: burn rate har upphört och budgetprognosen stabiliserats.

Först därefter kan incidenten gå från mitigated till recovered. Stängning kan ske senare, efter kommunikation, kvarvarande risk och uppföljning [CLAIM-OPS-008].

13. När observatören själv går sönder

Matrix scheduled health chain har ett gott fail-closed-mönster: varje försök stämplas och gammal success blir stale. Men självobservation är inte komplett bara för att sex komponenter finns i ett register.

Följande frågor måste besvaras:

• kör proben över huvud taget?
• når dess resultat användaren?
• är definitionerna kompletta och färska?
• kan samma fel slå ut både tjänst och observatör?
• finns en extern eller oberoende dead-man-signal?
• kan Coordinatorns controllers förklara sina senaste beslut?
• är telemetrydrop mätbar utan att antas vara noll?

En kontrollpanel som läser sin egen lokala fil kan korrekt fälla filens färskhet när sidan öppnas. Den kan inte själv väcka en användare om hela maskinen, webbservern eller nätet är nere. Minst en kritisk väg behöver därför en annan fel-domän: extern synthetic probe, separat notifieringskanal eller annan observerande nod. Detta är defense in depth, inte en ny global sanningskälla [CLAIM-OPS-009].

14. Gränssnittshierarki på hög nivå

En operativ Matrix-yta bör inte börja med hundratals komponenter. Den bör börja med löften och pågående påverkan:

Drift
├── Tjänstelöften
│   ├── SLO-status, burn rate och coverage
│   ├── användarresor och tenants
│   └── historik och budgetpolicy
├── Aktiva incidenter
│   ├── påverkan, klass, roller och nästa checkpoint
│   ├── evidensseparerad tidslinje
│   ├── hypoteser, beslut, actions och kommunikation
│   └── recovery-verifiering
├── Larm
│   ├── handlingsbara, kvitterade och eskalerade
│   └── kontraktsfel och unrouted
├── Systemlandskap
│   ├── användarresor och beroendegraf
│   ├── komponenthälsa och signaler
│   └── definitions-/observationstäckning
├── Coordinator
│   ├── work, leases, agents och fleet
│   ├── controller health och performance
│   └── inference, eval och outcome coverage
└── Lärande
    ├── postmortems
    ├── återkommande mekanismer
    └── åtgärder, ägare och verifiering

“Coordinator” är en förstaklassvy, inte gömd under teknisk hälsa. Den ska visa levande, pausade, contact-lost och avslutade agent-runs; kötid; heartbeatålder; stale budget; fleetbeslut; reap; eval; kostnad; incidentrelation och mätcoverage. Den tillfälliga 8181-vyns releaseorienterade “väg till DONE” ska inte bli produktens permanenta informationsarkitektur.

15. Användningsfall

UC13.1 — Bedöm ett tjänstelöfte

En tjänsteägare väljer en användarresa och ser SLI, mål, fönster, budget, coverage och källor. Om mätcoverage är otillräcklig visas unknown med orsak.

UC13.2 — Öppna från SLO till population

Operatören öppnar en försämrad SLI och ser exakt vilka requests, ärenden, tenants eller batches som räknades som good, bad, excluded och unknown.

UC13.3 — Förklara burn rate

Matrix visar vilket felmått, fönster och mål som gav burn rate, hur länge budgeten räcker i nuvarande takt och vilka förändringsregler som aktiveras.

UC13.4 — Granska en användarresa

En produktägare följer portal→identitet→AppWorks→xECM→Matrix och ser både end-to-end-utfall och tekniska beroenden utan att blanda ihop dem.

UC13.5 — Se ärligt okänd hälsa

En probe saknar behörighet eller är onåbar. Matrix visar unknown, tid sedan senaste success, berörd coverage och vad som krävs för att återfå evidens.

UC13.6 — Ta emot ett handlingsbart larm

On-call får löfte, konsekvens, population, ägare, deadline, runbook, leveranskvitto och dedupliceringsnyckel — inte bara “service red”.

UC13.7 — Kvittera och eskalera

Mottagaren kvitterar larmet. Utebliven kvittens inom policyn eskalerar via en annan definierad väg och sparar leverans- och eskaleringskvitton.

UC13.8 — Deklarera en incident

Ett larm eller en människa skapar incident_id, klass, initial påverkan, berörda löften och roller. Relaterade larm länkas, inte kopieras bort.

UC13.9 — Leda incidenten

Incident Commander ser mål, roller, nästa checkpoint, öppna beslut, blockeringar, kommunikationsdeadline och vilka actors som får göra writes.

UC13.10 — Arbeta med hypoteser

Operations Lead registrerar en hypotes, stöd, motbevisande test och utfall. Falsifierade hypoteser ligger kvar så att samma spår inte återupprepas.

UC13.11 — Verkställa mitigation säkert

En föreslagen åtgärd går via intent, risk, mandat, approval, receipt och read-back. Incidentläget höjer synlighet och tempo men kringgår inte grinden.

UC13.12 — Hantera extern part

När kunden eller leverantören äger åtgärden visar Matrix vår initierade begäran, partens kvittens, separata klockor och att status ännu inte är “stoppad”.

UC13.13 — Kommunicera läget

Communications Lead skapar målgruppsanpassad status från verifierade fakta. Osäkra hypoteser märks; mottagare, tid och leveranskvitto sparas.

UC13.14 — Verifiera recovery

Verifieraren kör komponent-, data-, kontrollplans- och användarresetest. Incidenten kan inte markeras recovered om obligatorisk coverage saknas.

UC13.15 — Förklara Coordinatorns roll

Operatören ser om agentsystemet orsakade, förstärkte, upptäckte eller endast observerade incidenten, inklusive leases, attempts, fleet ticks och actions.

UC13.16 — Förklara observatörens hälsa

Matrix visar senaste lyckade och senaste misslyckade probe, registrerad komponentpopulation, coverage, freshness och oberoende dead-man-signal.

UC13.17 — Skriva och följa upp postmortem

Ägaren länkar påverkan, tidslinje, trigger, bidragande villkor, recovery och åtgärder. Varje åtgärd har owner, deadline och verifierbart slutvillkor.

UC13.18 — Upptäcka återfall

Matrix grupperar incidenter efter mekanism, inte bara symptomtext, och visar om samma fel återkommer trots stängd åtgärd.

16. Postmortem som ändring av systemet

En blameless postmortem frågar vilka villkor som gjorde handlingarna rimliga och felet möjligt. Den ska innehålla mätbar påverkan, trigger, bidragande faktorer, vad som fungerade, vad som försvårade, var man hade tur och hur recovery verifierades.

Men texten är inte slutprodukten. Minst en systemisk åtgärd bör ha:

• en namngiven ägare,
• prioritet och deadline,
• ett verifierbart slutvillkor,
• koppling till mekanismen,
• test som skulle ha fångat återfallet,
• uppföljning efter stängning.

Åtgärden “var försiktigare” flyttar ansvar till framtida människor. Åtgärden “gör missing source till unknown och mutationstesta att den aldrig blir zero” ändrar systemets beteende. Först då har incidenten blivit institutionellt lärande [CLAIM-OPS-010].

17. Vad som saknas i Matrix

Implementationsgranskningen ger fyra tydliga utvecklingsspår.

17.1 Användarcentrerad SLO-modell

Monitoring-definitionerna beskriver vad teknisk hälsa betyder men saknar tjänst, population, good-event, fönster, error budget och budgetpolicy. Lägg till en separat SLO-modell; överbelasta inte health-schemat.

17.2 Beständigt larm- och incidentlager

Larmkontraktet är bra, men larmen skapas i läsvägen. Det behövs beständiga identiteter, state machine, ack, routing, escalation, incidentrelation och timupplösta klockor. Säkerhetsrutinen bör bli en profil ovanpå en generell incidentkärna, inte ersättas.

17.3 Korrelerad operativ telemetry

Queue, agent-run, fleet, inference, health och actions behöver korrelations- coverage och gemensamma tidsfält. OpenTelemetry kan vara transport-/exportlager, men Matrix domän-ID:n och privacyregler ska vara styrande.

17.4 Oberoende självövervakning

Den lokala freshnessgrinden skyddar mot gammalt grönt när någon öppnar ytan. Den garanterar inte notifiering när hela värden är nere. En syntetisk extern probe och separat notifieringsväg bör pilottestas för de mest kritiska löftena.

18. Slutprinciper

1. Börja med användarresan, inte servern.
2. Gör population och good-event explicit.
3. Låt unknown försämra coverage, aldrig förbättra SLI.
4. Separera constraints från förbrukbar felbudget.
5. Larma bara för handling och ge handlingen en ägare.
6. Ge incidenten egen identitet och semantiskt typad tidslinje.
7. Mitigera först, men kringgå aldrig mandat och bevis.
8. Verifiera recovery i användarresan och kontrollplanet.
9. Övervaka observatören från en annan fel-domän där konsekvensen kräver det.
10. Stäng lärandeloopen med ägda, testbara mekanismer.

Matrix stora möjlighet är inte ännu en dashboard. Den är att binda löftet, observationen, konsekvensen, handlingen och beviset till samma levande modell. När det lyckas kan systemet inte bara säga att något är rött. Det kan förklara vem som påverkas, vad vi vet, vad vi inte vet, vilket löfte som hotas, vem som äger nästa steg och vilket bevis som krävs för att kalla världen återställd.

FIG-13-01 — Från användarlöfte till incidentlärande kontrollslinga

Visa diagramdefinition

flowchart LR
    J[Användarresa<br/>och beslutskonsekvens] --> L[Löfte<br/>SLI + SLO + fönster]
    L --> O[Observationer<br/>events metrics logs traces]
    O --> A{Bedömning<br/>freshness + coverage}
    A -->|inom mål| B[Error budget<br/>och ändringsbeslut]
    A -->|hotat mål| R[Larm<br/>handling + ägare + tid]
    R --> I[Incident<br/>command + tidslinje]
    I --> M[Mitigation<br/>och recovery]
    M --> V[Verifiering<br/>användarresa + beroenden]
    V --> P[Postmortem<br/>mekanism + action owner]
    P --> J
    O --> S[Matrix självobservation]
    S --> A