Legt Schwellenwerte, Routing, Dashboards, Diagnose-Schritte, Eskalation, Behebung und Überprüfung für Gesundheitsprüfungen fest. Diese Referenz definiert die Annahmegrenze, das Ausfallverhalten und beobachtbare Nachweise, während umgebungsspezifische Grenzwerte konfigurierbar bleiben.
Paketstatus: Referenzkontext bereit für menschliche Überprüfung. Der Vertrag und die Testszenarien sind abgeschlossen, es wird jedoch nicht behauptet, dass eine übernehmende Implementierung diese bestanden hat.
Entscheidung
Für Gesundheitsprüfungen wird ein versionierter Telemetrievertrag angenommen, der an Serviceziele und Runbooks gebunden ist. Die Fähigkeit wird mit benannten Signalen, begrenzter Kapazität, zugeordneten Alarmen, einem diagnostischen Runbook und getesteten Wiederherstellungsnachweisen betrieben. Dieses Paket ist ein Referenzvertrag: Das übernehmende Team muss numerische Grenzwerte, Anbieter, Zuständigkeitsbereiche und operative Verantwortliche anhand von Nachweisen aus der eigenen Umgebung auswählen.
Umfang
- Die Akteure, Eingaben, Ausgaben, Zustände, Richtlinien- oder Schemaversionen und extern sichtbaren Ergebnisse der Gesundheitsprüfungen, die durch diesen Betriebsblock beschrieben werden.
- Primäre und alternative Schnittstellen, Hintergrundarbeiten, Caches, Integrationen, Supportwege und Nachweise, die dieselbe Grenze ausüben können.
- Übernahmespezifische Konfiguration, Rollout, Wiederherstellung und Verifikationsverantwortlichkeiten, die für eine sichere Anwendung der Referenz erforderlich sind.
Außerhalb dieses Blocks
- Die Auswahl eines universellen Anbieters, Frameworks, Zuständigkeitsbereichs, numerischen Schwellenwerts, Aufbewahrungszeitraums oder Service-Level-Objektivs für jeden Übernehmer.
- Die Behauptung, dass verpackte Szenarien gegen eine nachgelagerte Implementierung ausgeführt wurden oder dass diese Referenz eine rechtliche, sicherheitsrelevante oder barrierefreie Zertifizierung gewährt.
Vertrag
- Definieren Sie jedes Signal, Einheit, Aggregation, Attribute, Eigentümer, erwartete Kardinalität, Aufbewahrung und die unterstützte Entscheidung.
- Korrelation über Anfragen-, Warteschlangen-, Job- und Abhängigkeitsgrenzen hinweg propagieren, ohne Geheimnisse oder uneingeschränkte personenbezogene Daten in Attributen zu platzieren.
- Alarmieren bei benutzerbeeinträchtigenden Symptomen oder erschöpften Sicherheitsmargen, mit einem Diagnosepfad und einem benannten Reaktionsverantwortlichen.
- Behandeln Sie gesampelte Traces und Client-Berichte als Nachweise; lassen Sie nicht zu, dass nicht authentifizierte Telemetrie allein Produktionsänderungen oder Rollbacks autorisiert.
- Definieren Sie normale, degradierte, erschöpfte und nicht verfügbare Zustände mit Entscheidungsmetriken und expliziten Operatoraktionen.
- Bewahren Sie die Identität der akzeptierten Arbeit während Failover, Replay, Rollback und Reparatur, sodass die Wiederherstellung keine Effekte duplizieren oder stillschweigend verlieren kann.
- Trennen Sie Start-, Liveness-, Readiness- und tiefere Diagnoseprüfungen und definieren Sie für jede die genaue lokale Invariante, Timeout, Frequenz, Ausfallgrenze und Orchestrator-Aktion.
- Halten Sie Routineprüfungen günstig und frei von Geheimnissen, vermeiden Sie die Kopplung der Liveness an jede nachgelagerte Abhängigkeit und testen Sie Kaltstart, Drain, teilweisen Abhängigkeitsverlust, Überlast, Wiederherstellung und Versionsinkompatibilität.
Implementierungsleitfaden
- Üben Sie das Runbook in einer repräsentativen Umgebung und zeichnen Sie Wiederherstellungszeit, Datenverlustgrenze und ungelöste Annahmen auf.
- Modellieren Sie Eingaben, Ausgaben, Akteure, Zustände, Invarianten, Nebeneffekte und Nachweise der Gesundheitsprüfungen, bevor Sie Framework- oder Anbieterdetails auswählen.
- Speichern Sie die anwendbare Version des Gesundheitsprüfungsvertrags oder der Richtlinie mit materiellem Zustand, damit Migrationen, Replay und Supportentscheidungen nachvollziehbar bleiben.
- Führen Sie den Pfad hinter kontrolliertem Rollout ein, vergleichen Sie erwartete und beobachtete Ergebnisse und behalten Sie eine getestete Wiederherstellungsroute, bis Übernahme-Nachweise vollständig sind.
Fehlerbehandlung und Schutzmaßnahmen
- Fehlende Telemetrie ist selbst erkennbar, während der überwachte Dienst begrenzt bleibt und nicht vom Erfolg des Observability-Exports abhängt.
- Ungültiger oder widersprüchlicher Gesundheitsprüfungszustand wird abgelehnt oder isoliert; die Implementierung schätzt niemals einen Wert, der Autorität erweitert oder einen Effekt dupliziert.
- Wiederholungen sind begrenzt und verwenden dauerhafte Identität; nach Erschöpfung erreicht die Arbeit einen überprüfbaren Endzustand mit verantwortlichem Eigentümer.
Verifikation und Betrieb
- Injizieren Sie Sättigung, Abhängigkeitsausfall, veraltete Konfiguration und Telemetrieverlust und bestätigen Sie das deklarierte degradierte Verhalten.
- Überwachen Sie Erfolg, Ablehnung, Validierungsfehler, Abhängigkeitsfehler, Erschöpfung von Wiederholungen und Wiederherstellung der Gesundheitsprüfungen nach Vertragsversion ohne sensible Nutzlastdimensionen.
- Führen Sie gepaarte positive und negative Fixtures nach Richtlinien-, Schema-, Abhängigkeits-, Migrations- oder Grenzänderungen erneut aus und bewahren Sie die resultierenden Nachweise.
Übernahmeannahmen
- Namen und Werte im Beispiel sind ein konkretes Fixture, keine universellen Standardwerte; Übernehmer ersetzen sie durch dokumentierte Nachweise und Eigentümerschaft.
- Das übernehmende System kann authentifizierte Identität, dauerhafte Operationen oder Versionsaufzeichnungen, begrenzte Telemetrie und einen kontrollierten Änderungsweg bereitstellen.
Die ausführbar aussehenden Beispiele in diesem Paket sind Fixtures und Akzeptanzverträge. Führen Sie den Sammlungsvalidator aus, um Struktur und Metadaten zu prüfen, übersetzen und führen Sie dann die Szenarien im Ziel-Repository aus, bevor Sie Implementierungsnachweise aufzeichnen.