Alarm-Stufe aus dem Verhaeltnis ableiten, nicht aus der Absolutzahl
`checkHealth.ts:205` lautete `severity: unavailable > 1 ? 'critical' : 'warning'`.
Die Stufe hing damit an der ABSOLUTZAHL nicht verfuegbarer Instanzen statt am
Verhaeltnis zur Sollzahl - in beide Richtungen falsch, beides an echten Alarmen
gemessen (Fenster 2026-08-15..22, Sammlung `alerts`):
- Falsches critical: 636 von 688 kritischen `deployment_failed` trugen
`availableReplicas > 0`, liefen also weiter. Spitzenreiter sind drei
Ein-Instanz-Laeufer, bei denen "0 verfuegbar" der Normalzustand jedes
Neustarts ist (368 + 149 + 54 Alarme).
- Verpasster Totalausfall: ein Ein-Instanz-Dienst, der ganz ausfaellt, zeigt
`unavailable = 1` und war damit nur `warning` - niedriger eingestuft als das
harmlose Neuausrollen des Nachbarn.
Neu: `helpers/deploymentOutage.ts` haelt das Urteil EINMAL (rein, AY-frei) -
`outageScope` (full/partial/none) plus der aus `syncCluster` hierher gezogene
`deploymentHealthStatus`. Beide Regeln standen an getrennten Stellen und sind
genau deshalb auseinandergelaufen.
Karenz gegen Ausroll-Rauschen ueber den BESTEHENDEN Aufschlag des geteilten
Schreibers (`upsertAlert.escalateAfterMs`), kein neuer Mechanismus: ein
Totalausfall startet als `warning` und wird `critical`, sobald er die Karenz
(Vorgabe 10 min, `DEPLOYMENT_OUTAGE_CRITICAL_MINUTES`) ununterbrochen steht.
Gemessen trennt das sauber: von 1.960 Alarmen mit `availableReplicas = 0`
standen 1.934 (98,7 %) genau EINEN Takt, 25 laenger als drei Stunden, genau
einer dazwischen.
Zwei Praemissen des Auftrags korrigiert:
- `syncCluster.ts:81` (readyReplicas === 0) und `availableReplicas === 0` sind
NICHT dieselbe Regel - 430 Alarme ueber 33 Dienste tragen ready=1 bei
available=0. Fuer die Stufe gilt `availableReplicas`, weil
`escalationGate.decideEscalation` genau dieses Feld fuer sein FULL OUTAGE liest.
- Die vorgeschlagene Regel ALLEIN haette die Lage verschlimmert: sie macht aus
1.908 heutigen Warnungen kritische Alarme (Ein-Instanz-Neustart). Erst die
Karenz dreht das um. `status.updatedReplicas` geprueft und nicht gebaut -
ohne Zusatznutzen neben der Karenz.
Proben: `test/deploymentOutage.test.ts`, die vier Faelle des Verify-Gates plus
Karenz, Zahl-Lesung und Verhaltensgleichheit des Gesundheitszustands. Die
abgeloeste Regel steht als `legacySeverity` daneben, damit der rote Gegenpart im
selben Lauf entsteht. Flip-Probe gefahren: mit der alten Regel an derselben
Stelle fallen 11 Proben, die uebrigen 355 bleiben gruen. `npm test` 366/366.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Die Stufe hing damit an der ABSOLUTZAHL nicht verfuegbarer Instanzen statt am
Verhaeltnis zur Sollzahl - in beide Richtungen falsch, beides an echten Alarmen
gemessen (Fenster 2026-08-15..22, Sammlung `alerts`):
- Falsches critical: 636 von 688 kritischen `deployment_failed` trugen
`availableReplicas > 0`, liefen also weiter. Spitzenreiter sind drei
Ein-Instanz-Laeufer, bei denen "0 verfuegbar" der Normalzustand jedes
Neustarts ist (368 + 149 + 54 Alarme).
- Verpasster Totalausfall: ein Ein-Instanz-Dienst, der ganz ausfaellt, zeigt
`unavailable = 1` und war damit nur `warning` - niedriger eingestuft als das
harmlose Neuausrollen des Nachbarn.
Neu: `helpers/deploymentOutage.ts` haelt das Urteil EINMAL (rein, AY-frei) -
`outageScope` (full/partial/none) plus der aus `syncCluster` hierher gezogene
`deploymentHealthStatus`. Beide Regeln standen an getrennten Stellen und sind
genau deshalb auseinandergelaufen.
Karenz gegen Ausroll-Rauschen ueber den BESTEHENDEN Aufschlag des geteilten
Schreibers (`upsertAlert.escalateAfterMs`), kein neuer Mechanismus: ein
Totalausfall startet als `warning` und wird `critical`, sobald er die Karenz
(Vorgabe 10 min, `DEPLOYMENT_OUTAGE_CRITICAL_MINUTES`) ununterbrochen steht.
Gemessen trennt das sauber: von 1.960 Alarmen mit `availableReplicas = 0`
standen 1.934 (98,7 %) genau EINEN Takt, 25 laenger als drei Stunden, genau
einer dazwischen.
Zwei Praemissen des Auftrags korrigiert:
- `syncCluster.ts:81` (readyReplicas === 0) und `availableReplicas === 0` sind
NICHT dieselbe Regel - 430 Alarme ueber 33 Dienste tragen ready=1 bei
available=0. Fuer die Stufe gilt `availableReplicas`, weil
`escalationGate.decideEscalation` genau dieses Feld fuer sein FULL OUTAGE liest.
- Die vorgeschlagene Regel ALLEIN haette die Lage verschlimmert: sie macht aus
1.908 heutigen Warnungen kritische Alarme (Ein-Instanz-Neustart). Erst die
Karenz dreht das um. `status.updatedReplicas` geprueft und nicht gebaut -
ohne Zusatznutzen neben der Karenz.
Proben: `test/deploymentOutage.test.ts`, die vier Faelle des Verify-Gates plus
Karenz, Zahl-Lesung und Verhaltensgleichheit des Gesundheitszustands. Die
abgeloeste Regel steht als `legacySeverity` daneben, damit der rote Gegenpart im
selben Lauf entsteht. Flip-Probe gefahren: mit der alten Regel an derselben
Stelle fallen 11 Proben, die uebrigen 355 bleiben gruen. `npm test` 366/366.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>