Thema: operations
-
Einen DNS-Eintrag mit Rückwegabsicherung ändern: TTL absenken, Umschaltung und Prüfung
Eine DNS-Änderung erreicht Nutzer nur so schnell, wie die alte TTL in den Caches abläuft; deshalb die TTL eine volle alte TTL-Periode vor der Änderung absenken, das alte Ziel weiterlaufen lassen, bis das neue überall bestätigt ist, und berücksichtigen, dass Resolver veraltete Daten ausliefern dürfen, wenn die autoritativen Server nicht erreichbar sind, wie es RFC 8767 zulässt.
-
Ablauf von TLS-Zertifikaten auf jedem Endpunkt überwachen, nicht nur auf der Hauptwebsite
Ein abgelaufenes Zertifikat ist ein Ausfall mit exakt vorhersagbarem Zeitpunkt; das notAfter-Datum jedes tatsächlich ausgelieferten Zertifikats (Web, API, Mail, interne Panels, Load Balancer) von aussen abfragen, mit ausreichendem Vorlauf für eine manuelle Erneuerung alarmieren und sowohl die Zwischenzertifikate als auch das Endzertifikat prüfen.
-
Continuous Profiling in Produktion: dauerhaft aktive Sampling-Profile und was sie beantworten
Continuous Profiling erstellt systematisch über die Zeit CPU- und Speicherprofile und speichert sie als beschriftete Serien, sodass ein Team fragen kann, welche Funktion gestern flottenweit am meisten CPU verbraucht hat oder was sich zwischen zwei Versionen geändert hat; Sampling-Profiler machen das günstig genug, um es dauerhaft laufen zu lassen, und Laufzeit-Endpunkte wie Gos /debug/pprof/ oder eBPF-Agenten liefern die Profile.
-
Audit-Logs: was aufzuzeichnen ist, wie man sie unverändert hält und wer sie lesen darf
Ein Audit-Log beantwortet, wer was an welchem Objekt getan hat, wann und mit welchem Ergebnis; es wird von der Anwendung für jede sicherheitsrelevante Aktion geschrieben, getrennt von Debug-Logs gehalten, durch zügiges Verschieben in einen Append-only- oder Write-once-Speicher vor Veränderung geschützt und nur unter protokolliertem, eingeschränktem Zugriff gelesen.
-
Welche Trace-Sampling-Strategie hält seltene Fehlschläge in einem Dienst mit wenig Datenverkehr sichtbar?
Offene Frage: Leitlinien zum Sampling sind für Dienste mit Tausenden Traces pro Sekunde geschrieben, bei denen ein Prozent noch eine repräsentative Stichprobe ist; welche Kombination aus Head Sampling, Tail Sampling, Raten pro Route und Aufbewahrung hat bei einem Dienst mit wenigen Anfragen pro Sekunde den einen fehlschlagenden Trace pro Woche zu Kosten verfügbar gehalten, die das Team akzeptiert hat?
-
Welche Regeln zur Image-Aufbewahrung halten eine Container-Registry klein, ohne noch eingesetzte Images zu löschen?
Offene Frage: Registrys sammeln per Garbage Collection nur Blobs ein, auf die kein Manifest mehr verweist, und Lifecycle-Regeln lassen Images nach Alter, Anzahl oder Tag-Muster ablaufen; welche Kombination von Regeln haben Teams über Jahre gefahren, ohne dass entweder unbegrenztes Wachstum entstand oder ein Rollback scheiterte, weil sein Image weg war?
-
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?
-
Unix-Dateiberechtigungen und die umask
Jede Datei besitzt Berechtigungsbits für Eigentümer, Gruppe und Andere zum Lesen, Schreiben und Ausführen, dazu setuid-, setgid- und Sticky-Bit; neue Dateien erhalten ihre Berechtigungen von der umask des Prozesses. Geheimnisse gehören in Dateien mit 0600, Verzeichnisse benötigen Ausführen, um durchquert zu werden, und Dienste sollten unter einem dedizierten Benutzer laufen.
-
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.
-
Die USE-Methode zum Aufspüren von Performance-Engpässen
Für jede Ressource (CPU, Speicher, Festplatten, Netzwerk, Sperren) Auslastung, Sättigung und Fehler prüfen; die USE-Methode ist eine Checkliste, die Engpässe schnell findet, ohne zuerst auf der Anwendungsebene zu raten.
-
Antwortkomprimierung: wo sie erfolgen sollte und was auszunehmen ist
Textantworten (HTML, JSON, Markdown) am Proxy oder in der Anwendung komprimieren, bereits komprimierte und gestreamte Inhalte auslassen, ETags über Kodierungen hinweg ehrlich halten und Vary: Accept-Encoding setzen.
-
Welche Observability-Signale sollte ein JVM- oder .NET-Dienst standardmässig ausgeben, und mit welchem Overhead?
Offene Frage: Beide Laufzeitumgebungen bringen eingebaute Telemetrie mit (Flight Recorder und GC-Logging auf der JVM; EventPipe-Counter und dotnet-trace bei .NET), und beide bieten OpenTelemetry-Auto-Instrumentierung – doch es gibt kaum geteilte Belege dazu, welche davon in Produktion dauerhaft aktiv sein sollten, was sie kosten und welche tatsächlich Vorfälle verkürzt haben.
-
PostgreSQL-Erweiterungen verwalten: installieren, versionieren, aktualisieren und dumpen
Eine Erweiterung bündelt SQL-Objekte und oft eine Shared Library unter einem Namen mit einer Control-Datei und versionierten Skripten; CREATE EXTENSION installiert sie je Datenbank, ALTER EXTENSION UPDATE wendet die Update-Skripte des Autors an, und pg_dump gibt nur die Zeile CREATE EXTENSION aus. Installierte Dateien, Katalogversion und geladene Bibliothek im Gleichschritt halten, besonders bei Paket-Upgrades und pg_upgrade.
-
Log-Sampling bei Ereignissen mit hohem Volumen: jeden Fehler behalten, die repetitiven Zeilen sampeln
Sampling verwirft absichtlich einen Teil ähnlicher Log-Ereignisse; die nützlichen Formen sind Eins-von-N, Burst-dann-Rate je Zeitraum, Regeln je Level, die Warnungen und Fehler unangetastet lassen, sowie Pipeline-Sampling anhand einer Request-ID, sodass eine ganze Anfrage gemeinsam behalten oder verworfen wird, wobei die angewandte Rate in die überlebenden Ereignisse geschrieben wird.
-
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.
-
Eine Append-only-Zeitreihentabelle in PostgreSQL entwerfen
Messwerte in einer nach Zeitbereich partitionierten Tabelle mit timestamptz speichern, einem zusammengesetzten Schlüssel aus Serie und Zeit, Indizes passend zum Abfragemuster (B-Tree je Serie, BRIN für zeitliche Scans über die gesamte Tabelle) sowie Aufbewahrung durch Abtrennen und Löschen von Partitionen statt DELETE; die Entscheidungen ergeben sich daraus, dass Zeilen in zeitlicher Reihenfolge ankommen und in ganzen Zeitscheiben wieder verschwinden.
-
«No space left on device» diagnostizieren, obwohl df freien Platz zeigt
ENOSPC hat neben einer vollen Festplatte drei häufige Ursachen: erschöpfte Inodes, Platz, den gelöschte, aber von einem Prozess noch geöffnete Dateien belegen, sowie den reservierten Blockanteil bei ext-Dateisystemen. Vor jedem Löschen df -i, lsof +L1 und die Reservierung des Mounts prüfen.
-
Individuelle 404-Seiten und Soft 404s: die Fehlerseite mit dem Fehlerstatus ausliefern
Eine individuelle 404-Seite hilft Nutzenden nur, wenn sie mit Status 404 ausgeliefert wird; eine Nicht-gefunden-Seite mit Status 200 ist ein Soft 404, den Crawler weiter abrufen und den Suchmaschinen ausschliessen. nginx' error_page kann den Status umschreiben (error_page 404 =200 ...), und genau so entstehen Soft 404s versehentlich; den Status beibehalten, die Seite nützlich gestalten und mit curl -I prüfen.
-
Nach wie vielen Soft Bounces, über welchen Zeitraum, sollte ein Versender eine Adresse nicht mehr anschreiben?
Offene Frage: Erweiterte Statuscodes trennen dauerhafte Fehlschläge (5.X.X) von anhaltend vorübergehenden (4.X.X), doch der Standard überlässt den vorübergehenden Fall der Richtlinie des Versenders; welche Schwellenwerte haben Versender verwendet, und was geschah mit Erholungsraten und Reputation?
Maschinenlesbar: JSON