Artefaktgedanke: Beobachtbarkeit und Gegendruck für ein wachsendes OZMAI Brain

Mit wachsender Komplexität entsteht die Gefahr, dass Fehler nicht mehr als offensichtliche Fehlfunktion erscheinen.

Ein System kann weiterhin laufen und trotzdem Eigenschaften entwickeln, die erst später problematisch werden:

• einzelne Bereiche wachsen unverhältnismäßig stark,
• Traversierungen werden immer teurer,
• wenige Knoten entwickeln extremen Fan-out,
• bestimmte Inhalte werden ständig gemeinsam geladen,
• andere vorhandene Inhalte werden praktisch nie erreicht,
• zyklische Strukturen erzeugen unnötige Arbeit,
• Verdichtungen verdrängen im tatsächlichen Zugriff ihre Quellen,
• ein kleiner Teil des Bestands bestimmt zunehmend den verarbeiteten Kontext,
• Beobachtung und Protokollierung erzeugen selbst relevanten Speicher- oder Rechenaufwand.

Daraus entsteht die Idee kleiner messender Artefakte.

Sie sollen nicht entscheiden, was richtig, wichtig oder löschbar ist.

Sie sollen konkrete Eigenschaften eines laufenden Systems sichtbar und später vergleichbar machen.

Ihre Grundbewegung wäre:

messen → feststellen → belegbar machen

und zunächst ausdrücklich nicht:

messen → bewerten → verändern

Mögliche Beobachtungen

Ein späteres Artefakt könnte beispielsweise feststellen:

Bereich Y bestand zum Zeitpunkt X aus N Objekten und M Relationen.

Traversierung Z benötigte T Zeit und B gelesene Bytes.

Knoten A besaß zum Messzeitpunkt einen Fan-out von F.

Artefakt B wurde innerhalb des beobachteten Zeitraums nicht aktiviert.

Anfrageklasse Q aktivierte durchschnittlich K Objekte.

Verdichtung V wurde in 98 % der beobachteten Zugriffe verwendet, ihre Quellen dagegen in 2 %.

Solche Aussagen beschreiben einen beobachteten Zustand.

Sie begründen für sich genommen keine Löschung, keine Umstrukturierung und keine Aussage über Bedeutung.

Die Auswahl der Messung ist nicht neutral

Auch ein rein beobachtendes Werkzeug trifft bereits eine Vorentscheidung dadurch, was es überhaupt messbar macht.

Wer Fan-out pro Knoten misst, macht Fan-out sichtbar und andere Eigenschaften zunächst unsichtbar.

Wer Aktivierungshäufigkeit misst, macht häufige Aktivierung zu einer auffälligen Eigenschaft und seltene Aktivierung zu einer weniger sichtbaren.

Wer nur Latenz misst, kann semantische Verluste vollständig übersehen.

Das bedeutet nicht, dass eine Metrik bereits eine Bewertung enthält. Aber ihre Auswahl beeinflusst, welche Phänomene später überhaupt als untersuchenswert erscheinen können.

Deshalb muss zu einer Messung nicht nur dokumentiert werden, was sie zeigt, sondern auch, was sie nicht beobachtet.

Beobachtbarkeit hat eine Grenze

Bestimmte besonders wichtige Fehler lassen sich durch reine Messung nicht erkennen.

Wenn eine relevante Feststellung für einen Vorgang hätte aktiviert werden sollen, aber nicht aktiviert wurde, kann ein Messartefakt zunächst nur feststellen:

Y wurde nicht aktiviert.

Es kann daraus nicht ableiten:

Y hätte aktiviert werden müssen.

Diese zweite Aussage benötigt eine zusätzliche Grundlage: beispielsweise spätere Erkenntnis, externe Prüfung, einen Vergleichsvorgang oder eine andere noch zu bestimmende Form von Bewertung.

Damit darf ein zukünftiges Beobachtungsartefakt nicht so beschrieben werden, als könne es automatisch alle Aktivierungsfehler finden.

Gerade falsche Negative können unsichtbar bleiben.

Ein Messartefakt ist selbst Architektur

Sobald ein Beobachtungswerkzeug dauerhaft oder regelmäßig in einem System wirkt, ist es nicht nur ein externes Hilfsmittel.

Es wird selbst zu einer Architekturkomponente mit eigener Wirkung und eigenem Failure Scope.

Sein Ausfall kann Beobachtbarkeit verlieren lassen.

Seine Fehlmessung kann ein falsches Bild des Systems erzeugen.

Seine Ressourcenaufnahme kann andere Komponenten beeinflussen.

Seine Auswahl von Metriken kann bestimmen, welche Probleme später überhaupt sichtbar werden.

Deshalb darf ein solches Werkzeug nicht allein deshalb von Architekturprüfung ausgenommen werden, weil es „nur misst“.

Für eine konkrete Implementierung müsste von Beginn an festgehalten werden, welche anderen Komponenten von seinem Ausfall, seiner Verzögerung, seiner Fehlkonfiguration oder seiner eigenen Ressourcenaufnahme betroffen sein können.

Das Messartefakt darf seine eigene Wirkung nicht vergessen

Ein Beobachtungssystem ist selbst Teil der physischen Realität, die es beobachtet.

Es benötigt Speicher.

Es erzeugt Lesezugriffe.

Es benötigt Rechenzeit.

Es produziert möglicherweise eigene Feststellungen.

Damit verändert seine Existenz das gemessene System.

Wenn seine Messergebnisse wiederum in denselben Bestand geschrieben werden, den es beobachtet, entsteht zusätzlich eine Rückkopplung:

Das Artefakt misst das System.

Seine Messung wird Teil des Systems.

Beim nächsten Durchlauf misst es möglicherweise auch seine eigene frühere Messung.

Das ist nicht automatisch falsch.

Aber es darf nicht stillschweigend entschieden werden.

Vor einer tatsächlichen Implementierung müsste deshalb geklärt werden, ob und wie Beobachtungsdaten:

• Teil desselben Bestands werden,
• logisch getrennt bleiben,
• bei Messungen ein- oder ausgeschlossen werden,
• auf die beobachteten Zustände referenzieren.

Auch diese Frage bleibt zunächst offen.

Kein automatisches Aufräumen

Aus technischen Symptomen dürfen keine unmittelbaren semantischen Entscheidungen folgen.

Aus

seit zwei Jahren nicht aktiviert

folgt nicht:

kann gelöscht werden.

Aus

hoher Fan-out

folgt nicht:

Architekturfehler.

Aus

hohe Zugriffshäufigkeit

folgt nicht:

hohe Bedeutung.

Aus

teure Traversierung

folgt nicht:

Beziehung ist überflüssig.

Messungen können Hinweise auf Stellen liefern, die untersucht werden sollten.

Mehr zunächst nicht.

Verhältnis zu #c4m

Sollte daraus später tatsächlich Software entstehen, könnte #c4m kleine, klar begrenzte Mess- oder Prüfartefakte erzeugen, prüfen oder ausführen.

Das ist jedoch eine mögliche spätere Verwendung und noch keine Anforderung an #c4m.

Vor einer Implementierung müsste für jedes solche Artefakt konkret bestimmt werden:

• was genau es beobachtet,
• warum gerade diese Metriken ausgewählt wurden,
• welche relevanten Phänomene dadurch nicht beobachtet werden,
• welche Ressourcen es selbst benötigt,
• welche Aussagen seine Messung tatsächlich erlaubt,
• welche Fehler es nicht erkennen kann,
• welche anderen Komponenten von seinem Ausfall betroffen wären,
• ob sein eigener Output wiederum Gegenstand seiner Messung wird.

Zweck dieses Gedankens

Dieser Text spezifiziert kein fertiges Observatory und verlangt nicht, dass eines gebaut wird.

Er hält lediglich einen möglichen späteren Werkzeugtyp fest:

Software, die nicht versucht, die Bedeutung des OZMAI Brain zu bestimmen, sondern sichtbar macht, wie sich seine Architektur unter realer Nutzung tatsächlich verhält.

Ob daraus ein Artefakt entsteht, welche Form es besitzt und ob es überhaupt nötig ist, sollte erst aus realen Problemen folgen.