När kontrollsystemet självt går sönder

Matrix kärnlöfte är förklaring under förändring. Därför är ett fel i Matrix inte bara ett vanligt driftfel. Det kan göra organisationen blind, låta en gammal bild se aktuell ut eller utföra åtgärder på ett felaktigt underlag.

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

Resiliens betyder enligt NISTs användbara verb att kunna förutse, motstå, återhämta och anpassa. För Matrix måste alla fyra omfatta data, kontrollplan, mänsklig operabilitet och evidens [CLAIM-RESILIENCE-001].

1. Kontrollplan och dataplan

Källsystemens dataplan fortsätter normalt att bära verksamhetens transaktioner. Matrix kontrollplan observerar, korrelerar, bedömer, föreslår och ibland verkställer. Separationen begränsar skadan: ett Matrixavbrott ska inte automatiskt stoppa xECM eller AppWorks. Men styrande actions, stale beslut och saknade larm kan ändå påverka dataplanet.

Analysera därför fyra riktningar:

2. Fail-silent är huvudfienden

Ett synligt rött fel är ofta enklare än ett kontrollplan som slutat mäta men fortsätter visa gårdagens gröna JSON. Varje härledd status behöver därför:

• observedAt och validAt,
• förväntad kadens och stalegräns,
• coverage över deklarerad population,
• status för själva mätkedjan,
• ägare och konsekvens när kedjan tystnar.

Matrix scheduled health gör mycket av detta rätt: en misslyckad körning flyttar inte fram lastSuccessAt och läsvägen fäller gammal success. Men om värd, webbserver, probe och lokalt UI delar fel-domän kan ingen lokal komponent väcka användaren. Kritiska löften behöver en separat dead-man eller synthetic path [CLAIM-RESILIENCE-002].

3. Korrelerade fel-domäner

“Två kontroller” betyder inte defense in depth om de delar process, databas, credential, region, DNS, kod, schema eller operatör. En dependency map bör märka sådana gemensamma domäner.

Exempel: queue och fleet supervisor kan ligga i olika processer men dela Coordinator-databasen. Lokal probe och UI kan dela filsystem. Primärdatabas och automatisk replica kan replikera samma felaktiga delete. En extern synthetic kan ändå dela identitetsleverantören med tjänsten.

Kravet är inte maximal fysisk separation. Det är att uttala vilket fel varje kontroll ska överleva och testa just det [CLAIM-RESILIENCE-003].

4. Feedbackloopar och kaskader

Coordinatorn är en controller: den observerar kö, reapar leases, bedömer kapacitet och startar arbete. Controllers kan förstärka fel:

latens → timeout → retry → mer kö/last → fler timeouts → fler workers → mer last

Skydd omfattar begränsad concurrency, retry budget, exponentiell backoff med jitter, circuit breaker, load shedding, tenantkvoter och monotona state transitions. En fleet supervisor måste särskilt skilja efterfrågan från ett beroende som redan är överlastat. Fler agents är inte alltid mer kapacitet [CLAIM-RESILIENCE-004].

Actions med outcome_unknown får inte blindretryas. Efter contact loss måste read-back, extern receipt eller idempotency key avgöra om effekten redan skett.

5. Integrity är inte freshness

Matrix verifierar hashkedjor för handovers och decision ledger. Det kan visa att lagrade poster inte brutit den lokala länkningsregeln. Det bevisar inte:

• att alla händelser skrevs,
• att payloaden var sann,
• att aktören var behörig,
• att kedjan är färsk,
• att extern effekt motsvarar posten.

jake_chain_verify håller därför integritetsstatus skild från ledger freshness och gör missing, unreadable och stale larmbara. Det är exakt rätt semantiska separation [CLAIM-RESILIENCE-005].

6. Backup är inte återställning

En backupfil bevisar bara att bytes skrevs någonstans. Replikering ger tillgänglighet men replikerar ofta korruption. Restore proof kräver:

1. välj en verklig backup enligt definierad policy,
2. återställ till isolerad miljö,
3. starta kompatibel schema-/applikationsversion,
4. verifiera strukturell och semantisk data,
5. kör representativa användarresor,
6. mät tid och dataförlust,
7. skriv kvitto och gör gammalt kvitto stale.

Matrix veckovisa Coordinator-prov återläser senaste dump till scratchdatabas, jämför tabellräkningar, skriver status och larmar när resultatet är rött, saknat, oläsbart eller äldre än åtta dagar. Detta är väsentligt bättre än “backup finns”. Begränsningen är att tabellantal inte bevisar relations-, tenant-, queue- eller domäninvariants och att provet inte automatiskt täcker varje store i katalogen [CLAIM-RESILIENCE-006].

RPO anger tolererad dataförlust i tid eller händelser. RTO anger tolererad tid till återställd tjänst. Båda måste definieras per förmåga. Ett gemensamt RTO för “Matrix” döljer att read-only landscape kan prioriteras före modeljobs och write actions.

7. Degraded mode och safe mode

Degraded mode är en fördefinierad, begränsad tjänst – inte improvisation.

Safe mode ska vara fail-closed för irreversibla eller känsliga handlingar men kan tillåta evidensinsamling, export av incidentpaket och manuellt verifierade read-only vägar. Break glass kräver namngiven principal, scope, tid, motiv, tvåpersonskontroll där risken kräver det och eftergranskning. Det får inte öppna en generell bypass [CLAIM-RESILIENCE-007].

8. Återuppbyggnad från kanoniska källor

Matrix innehåller både kanonisk definition och återskapbara projektioner. Recoveryplanen måste klassificera varje lager:

• authoritative: måste återställas med historia och integritet,
• reconstructable: byggs om från låst source revision,
• ephemeral: kan förloras utan affärskonsekvens,
• externally authoritative: återläses från ägt källsystem,
• irreplaceable evidence: kräver särskilt skydd och kedjeverifiering.

Återbyggnad ska pinna versionskombinationer, stoppa writers, verifiera källor, bygga i topologisk ordning, jämföra counts/digests/invariants och först därefter öppna läsning och writes. Queue recovery måste dessutom reconcila work item, episode, attempt, lease, agent-run och extern action receipt. Annars kan “återställd” Coordinator skapa dubbelarbete.

Den aktuella backupkatalogen deklarerar elicitationens elva tabeller som täckta av Coordinator-dumpen, men markerar restore_proven=false: tabellerna skapades efter det senaste restorebeviset. “Ingår i backupmetoden” och “har återställts och verifierats” är därför två skilda påståenden. Tills en ny drill omfattar deras relationer, retention och rättighetsväg ska elicitation visas som backup-covered men restore-unproven (MATRIX-BACKUP-COVERAGE).

9. Game days

En game day är ett kontrollerat experiment, inte ett dramatiskt avbrott. Hypotes, blast radius, abortvillkor, observatörer, startläge och expected evidence skrivs före injektionen. Bra Matrix-scenarier är:

• stoppa scheduled probe men lämna senaste gröna fil,
• gör restore-status stale,
• kapa worker efter extern effekt men före receipt,
• korrumpera en scratch-hashkedja,
• återläs backup före en raderingstombstone,
• gör identity/policy source unavailable,
• ge fleet felaktig efterfrågesignal,
• tappa en hel telemetrypartition.

Mät detection time, decision time, safe-mode time, RTO, RPO, coverage, mänskliga handoffs och om användarresan verkligen verifierades. En lyckad övning kan avslöja fel; att inget upptäcktes är inte automatiskt ett bra resultat.

10. Gränssnittshierarki

Resiliens
├── Förmågor och återställningsmål
│   ├── RTO/RPO, prioritet och dependencies
│   └── senaste restore-/journeybevis
├── Kontrollplan
│   ├── observers, controllers, leases och fleet
│   ├── freshness, coverage och fel-domäner
│   └── paus/safe mode/reconcile
├── Data och integritet
│   ├── storeklass, backupcoverage och restore
│   └── chain integrity, ledger freshness och gaps
├── Recovery
│   ├── deklarerad runbook och faktiskt steg
│   └── postconditions och återstående risk
└── Övningar
    ├── scenario, blast radius och abort
    └── mätresultat, fynd och ägda åtgärder

11. Användningsfall

UC15.1 — Se kontrollplanets liveness

Operatören ser varje controller/probe, senaste start/success, stale budget, källa och om presentationsvägen själv är nåbar.

UC15.2 — Upptäck stale green

En gammal success fälls till stale även om filen fortfarande säger ok.

UC15.3 — Visa fel-domäner

Arkitekten ser vilka prober, stores, identities och notifieringar som delar värd, kod, credential, region eller operatör.

UC15.4 — Pausa dispatch säkert

Incident commander stoppar nya claims men bevarar queue, leases och evidence.

UC15.5 — Reconcila contact-lost work

Operatören kopplar attempt till receipt/read-back och väljer success, retry, compensation eller manuell utredning.

UC15.6 — Begränsa en kaskad

Fleet sänker concurrency, respekterar retry budget och visar varför kapacitet inte skalas upp mot ett överlastat beroende.

UC15.7 — Gå till degraded mode

Systemet väljer en versionsbunden profil och visar exakt vilka frågor/actions som är tillåtna, unknown eller blockerade.

UC15.8 — Aktivera break glass

Två behöriga principals godkänner avgränsad tid/target/action; receipt och automatisk expiry bevaras.

UC15.9 — Granska backupcoverage

Dataarkitekten ser varje store, backupmetod, senaste backup, restore proof, RPO/RTO och oregistrerade lager.

UC15.10 — Kör restore proof

En isolerad återställning mäter tid, schema, invariants och journeys och publicerar ett tidsbegränsat bevis. Coverage redovisas per store; elicitation förblir restore-unproven tills dess elva tabeller faktiskt ingått i drillen.

UC15.11 — Skilj kedjeintegritet från freshness

CISO ser intakt men stale kedja som två separata statusar och kan följa senaste förväntade/observerade append.

UC15.12 — Återbygg en projektion

Operatören väljer kanonisk revision, stoppar writers, rebuildar index/graf och jämför populationscoverage före cutover.

UC15.13 — Återställ Coordinatorn

Work, episodes, attempts, leases, agent-runs och externa outcomes reconcileras innan dispatch återöppnas.

UC15.14 — Kör game day

Övningsledaren injicerar ett avgränsat fel, följer abortvillkor och mäter detection, safe mode, recovery och användarverifiering.

UC15.15 — Förklara en recovery

En granskare kan se definition, utförda steg, aktörer, tider, bevis, avvikelser och kvarvarande risk utan att lita på berättande statusord.

UC15.16 — Lär av kontrollplansfelet

Fynd kopplas till systemisk mekanism, ägare, verifierbart slutvillkor och ny mutation/game-day så att samma failure mode prövas igen.

12. Sammanfattning

Resiliens är ett verifierat systembeteende. Matrix har lovande byggblock: stale-gates, coverage, restore proof, chain verification och queue/fleet- kontroller. Nästa mognadssteg är sammanhängande recovery per förmåga och oberoende bevis för de löften vars lokala observatör kan falla samtidigt.

FIG-15-01 — Självobservation, safe mode och verifierad återställning

Visa diagramdefinition

flowchart TB
  P[Användarlöfte] --> O[Observer]
  O --> C[Controller]
  C --> A[Action mot dataplan]
  A --> U[Dataplan och användarutfall]
  U --> NO[Nästa observation]
  D[Oberoende dead-man] -. övervakar .-> O
  D -. övervakar .-> C
  B[Backup och kanoniska källor] --> R[Isolerad restore/rebuild]
  R --> V[Invariants och användarjourney]
  V -->|bevisad| RA[Kontrollerad återaktivering]
  V -->|fel| S[Safe/degraded mode]