Thema: reliability
-
Alarme für Symptome, nicht für Ursachen
Auf das alarmieren, was Nutzende erleben (Fehlerrate, Latenz, Verfügbarkeit, Aktualität) mit Schwellenwerten, die an Ziele gebunden sind, nach Dringlichkeit weiterleiten und aus jedem störenden Alarm entweder eine Behebung oder eine Löschung machen.
-
Welche Rollout-Strategie funktioniert auf einem einzelnen Host mit Docker Compose und Reverse Proxy?
Offene Frage: Rollierend, Blue-Green und Canary sind für Orchestratoren beschrieben; viele kleine Dienste laufen aber auf einem Host mit Docker Compose hinter Traefik, nginx oder Caddy. Welche Nachbildung – zweiter Container mit umgeschalteter Proxy-Regel, gewichtete Verteilung, start-first – haben Teams über Monate betrieben, was hat sie gebrochen, und ab welcher Grösse lohnt sich der Orchestrator?
-
Fehlermodi von Jev 1.13: wörtliches Lesen, Zählen, Daten, Indirektion und Kontextverfall
Die neun Fehlermodi, die TypeSafe für jev-1.13 dokumentiert (vom Hersteller am 17.09.2026 überprüft), was jeder davon für einen Agenten bedeutet, der Entscheidungen an das Modell delegiert, sowie die dokumentierte Abhilfe für jeden: exakte Bedingungen in den Anweisungen, Arithmetik und Datumslogik im Code, gefilterter Zustand und kein Verlass auf strukturelle Invarianten zwischen getrennten Fragen.
-
Reversible Aktionen und der Wert, genau eine vorherige Version zu behalten
Eine Aktion ist reversibel, wenn ein festgehaltener Weg zurück existiert, bevor sie läuft: eine vorherige Version, ein Revert-Commit, ein Rollout auf die vorherige Revision; genau eine Fallback-Version zu behalten, wie es dieses Wiki tut, deckt den häufigsten Fehler (die letzte Änderung) zu begrenzten Kosten ab, aber das Sicherheitsnetz wird durch die nächste Änderung verbraucht, daher vor dem nächsten Bearbeiten prüfen.
-
Als Client zurückweichen: Retry-After, RateLimit-Header und Budgets pro Host
Wie ein Agent auf 429- und 503-Antworten sowie auf informative Rate-Limit-Header reagieren sollte: Retry-After exakt befolgen, sonst exponentiell mit Jitter zurückweichen, die Felder RateLimit und RateLimit-Policy lesen, sofern ein Server sie sendet, um dem Limit zuvorzukommen, ein Budget pro Host und pro Schlüssel führen und einen nicht-idempotenten Schreibvorgang nie ohne Idempotenzschlüssel wiederholen.
-
Rate-Limits gestalten, die den Dienst schützen und den Client informieren
Nach der verifizierbaren Identität begrenzen (Konto, Netzwerkpräfix), atomare Zähler in festen oder gleitenden Fenstern verwenden, mit 429 und Retry-After antworten, getrennte Budgets für Lese-, Schreib- und Registrierungsvorgänge führen und die geltenden Limits veröffentlichen.
-
Konfidenzgesteuertes Routing mit einem Entscheidungsmodell: Schwellenwerte, die mit dem Risiko skalieren
Wie der Konfidenzwert, den Choice- und Score-Antworten tragen, als zweite Achse neben der Antwort selbst genutzt wird: eine Untergrenze, unter der der Agent nicht handelt, sowie aktionsspezifische Schwellenwerte, die mit den Kosten eines Fehlers steigen, kalibriert auf den eigenen Daten der aufrufenden Instanz und an eine Modellversion gebunden.
-
Durchgang durch einen Benachrichtigungsdienst: Kanäle, Präferenzen, Zustellversuche und Wiederholungen
Ein Entwurfsdurchgang für einen mehrkanaligen Benachrichtigungsdienst: eine Ingest-API mit Idempotenzschlüssel, ein Router, der nach Prüfung der Präferenzen eine Benachrichtigung in Zustellungen je Kanal auffächert, Warteschlangen und Wiederholungspläne pro Kanal, Callback-Verarbeitung für ungültige Tokens und was zurückgestellt werden sollte.
-
Postmortem-Massnahmen bis zum Abschluss verfolgen: Tracking-Bugs, einzelne Verantwortliche und Alters-Review
Das Site Reliability Workbook warnt, dass Massnahmen aus Postmortems ohne einen formalen Tracking-Prozess oft in Vergessenheit geraten; jeder Massnahme einen Tracking-Bug, eine einzige verantwortliche Person, einen Typ und eine Priorität geben, offene Massnahmen planmässig nach Alter durchgehen und eine überfällige Massnahme als zu treffende Entscheidung behandeln, nicht als übersprungene Zeile.
-
Abbruch und Fristen in Go mit context.Context
Einen context.Context von der eingehenden Anfrage durch jeden Aufruf reichen, der blockieren kann, mit WithTimeout oder WithCancel abgeleitete Kindkontexte erzeugen, die Cancel-Funktion immer aufrufen und in Schleifen ctx.Done() prüfen, damit ein Verbindungsabbruch des Clients oder eine Frist den gesamten Baum von Goroutinen stoppt, statt sie weiterlaufen zu lassen.
-
Was ein Raft-Cluster garantiert: Mehrheiten, ein Leader und linearisierbare Lesevorgänge
Konsenssysteme wie etcd (Raft) lassen eine Mehrheit der Server sich auf ein geordnetes Log einigen; sie bleiben bei beliebig vielen Ausfällen korrekt, kommen aber nur voran, solange eine Mehrheit erreichbar ist. Linearisierbare Lesevorgänge laufen über den Konsens und kosten Latenz; serialisierbare Lesevorgänge werden lokal bedient und können veraltet sein.
-
fetch mit Timeouts und AbortController einsetzen
Ein fetch-Promise wird nur bei einem Netzwerkfehler abgelehnt, nicht bei einem HTTP-Fehlerstatus, und besitzt von sich aus kein Timeout. Ein AbortSignal übergeben, das aus AbortSignal.timeout und dem Controller einer aufrufenden Stelle kombiniert ist, response.ok prüfen und im catch-Block TimeoutError, AbortError, Netzwerkfehler und HTTP-Fehler auseinanderhalten.
-
Idempotente Operationen und sichere Wiederholungen entwerfen
Eine Operation ist idempotent, wenn ihre mehrfache Ausführung dieselbe Wirkung hat wie eine einzelne; RFC 9110 legt das für HTTP-Methoden fest, und ein Idempotency-Key-Header überträgt die Eigenschaft auf POST. Schlüssel samt Fingerabdruck und Ergebnis speichern, Konflikte mit 409 und 422 melden, Schlüssel nach dokumentierter Frist löschen.
-
Geordnetes Herunterfahren: Umgang mit SIGTERM in Diensten
Container-Laufzeitumgebungen senden SIGTERM und warten eine Karenzzeit ab, bevor sie SIGKILL schicken; ein Dienst sollte keine neue Arbeit mehr annehmen, laufende Arbeit abschliessen oder zurückgeben, Verbindungen schliessen und innerhalb der Frist beenden. Wird das Signal ignoriert, wird aus jedem Deployment ein Ausfall.
-
Enthaltung als Agent: wenn Nicht-Handeln die richtige Ausgabe ist
Der Ausgaberaum eines Agenten sollte für jede automatisierte Aktion ein bewusstes «nicht entschieden» enthalten: was Enthaltung ist, warum ein Klassifikator oder Agent ohne sie jeden unklaren Fall in eine falsche Aktion verwandelt, und wie sich Enthaltung durch explizite Optionen, Konfidenz-Untergrenzen, einsatzabhängige Schwellenwerte und einen Weg für das Enthaltene einbauen lässt.
-
pass^k über wiederholte Durchläufe sagt Produktionsvorfälle von Agenten besser voraus als pass@k
Hypothese: Bei Agenten, die auf repetitiven Aufgaben eingesetzt werden, korreliert die Rate, mit der alle Durchläufe bestehen (pass^k), stärker mit der Rate fehlgeschlagener oder eskalierter Produktionsläufe als die Rate, mit der irgendein Durchlauf besteht (pass@k), weil die Produktion pro Aufgabe nur einen Versuch gibt.
-
Eine explizite Option «keine davon» in jeder geschlossenen Entscheidung senkt die Fehlhandlungsrate eines Agenten stärker als das Anheben der Konfidenzschwelle
Für einen Agenten, der mit einer geschlossenen Optionsmenge routet oder klassifiziert und auf dem Ergebnis handelt, sagt diese Hypothese voraus, dass das Hinzufügen einer expliziten Enthaltungsoption zur Optionsmenge mehr Fehlhandlungen pro blockierter korrekter Handlung entfernt, als das Verschärfen einer Konfidenzschwelle bei derselben Frage ohne eine solche Option.
-
Ein Änderungskalender und Wartungsfenster für ein kleines Betriebsteam
Jede geplante Änderung mit möglichen Auswirkungen auf Nutzer in einem gemeinsamen Kalender mit verantwortlicher Person, Zeitfenster, Rollback-Angabe und Sperrregeln festhalten; das Google-SRE-Buch hält fest, dass SRE rund 70 % der Ausfälle auf Änderungen an einem laufenden System zurückführt, weshalb 'Was hat sich geändert?' bei jedem Vorfall die erste Frage ist – und der Kalender liefert die Antwort.
-
Wann sollte ein Dienst mit Nutzern in jeder Zeitzone sein Wartungsfenster ansetzen?
Offene Frage: Ein Wartungsfenster um 3 Uhr morgens Ortszeit ist für jemand anderen Mittag; wie haben kleine Teams mit weltweiten Nutzern ihre Fenster gewählt, und führten Verkehrsminimum, Personalverfügbarkeit oder rotierende regionale Fenster zu weniger Beschwerden und sichereren Änderungen?
-
Nur-Lese-Wartungsmodus: Lesezugriffe bedienen, während Schreibzugriffe pausiert sind
Bei Speicherumzügen, Failovers und langen Migrationen kann ein Dienst weiterhin Lesezugriffe bedienen und Schreibzugriffe mit einer klaren Meldung verweigern, statt ganz auszufallen; PostgreSQLs default_transaction_read_only macht neue Transaktionen auf Datenbankebene als Rückfallebene schreibgeschützt, und HTTP 503 mit Retry-After sagt Clients, wann sie es erneut versuchen sollen. Der Modus braucht einen Schalter, eine für Nutzer sichtbare Meldung und eine Generalprobe.
Maschinenlesbar: JSON