Alle Artikel
-
Logs, Metriken und Traces: das richtige Signal wählen
Logs erfassen einzelne Ereignisse, Metriken aggregieren numerische Messwerte über die Zeit, und Traces verfolgen eine Anfrage über Dienste hinweg; OpenTelemetry standardisiert alle drei, damit sie sich korrelieren lassen.
-
Benutzer, Rollen und RBAC unter Solaris: warum root standardmässig eine Rolle ist und wie pfexec sudo ersetzt
Oracle Solaris setzt privilegierte Administration über RBAC-Rechteprofile um, die Benutzern oder Rollen zugewiesen werden, und richtet root standardmässig als Rolle statt als direkt anmeldbaren Benutzer ein. Das native Werkzeug, um einen einzelnen privilegierten Befehl unter einem zugewiesenen Profil auszuführen, ist pfexec, nicht sudo.
-
Die JavaScript-Ereignisschleife: Tasks, Microtasks und Rendering
JavaScript führt jeweils einen Job aus; die HTML-Ereignisschleife nimmt einen Task und leert dann die gesamte Microtask-Warteschlange (Promise-Reaktionen, queueMicrotask), bevor der nächste Task oder eine Rendering-Gelegenheit an die Reihe kommt. Lange synchrone Arbeit und endlose Microtask-Ketten blockieren Eingaben und das Zeichnen.
-
Datensicherungen wirklich prüfen: die Rücksicherungsprobe
Eine Sicherung ist erst dann eine Sicherung, wenn eine Rücksicherung in eine leere Umgebung gelungen und geprüft worden ist. Das Vorgehen: Erwartung festlegen, allein aus der Sicherung wiederherstellen, Vollständigkeit und Funktion messen, Dauer notieren, Befund ablegen und den Termin für die nächste Probe setzen.
-
Serielle und Out-of-Band-Konsolen: Serverzugriff auch bei ausgefallenem Netzwerk
Eine serielle Konsole (console=ttyS0,115200 samt getty auf der Leitung), die Serial-Console-Funktion eines Cloud-Anbieters oder IPMI/BMC Serial-over-LAN eröffnen Administratoren einen Zugang zu einem Server ohne funktionierenden Netzwerkstack – eine Situation, die ein rein auf SSH beruhendes Zugriffskonzept nicht übersteht.
-
CIS Benchmarks und DISA STIGs als Härtungsbasis: Was sie sind und wie sie selektiv angewendet werden
CIS Benchmarks und DISA STIGs sind zwei unabhängig gepflegte Sammlungen von Konfigurationsempfehlungen; beide bieten wählbare Profilstufen statt eines festen Ziels. Wer ein Profil pauschal und ohne dokumentierte Ausnahmen umsetzt, legt bei der Härtung häufig einen produktiven Dienst lahm.
-
Alle Unterbrechungen an eine rotierende Person zu leiten erhöht die ununterbrochene Arbeitszeit des restlichen Teams
Hypothese: Ein Team, das Tickets, Fragen und operative Anfragen einer einzigen rotierenden Person zur Bearbeitung von Unterbrechungen zuweist und aufhört, sie auf alle zu verteilen, erhöht die mediane Länge der ununterbrochenen Arbeitsblöcke der übrigen Mitglieder, ohne die Reaktionszeiten auf Unterbrechungen über das vereinbarte Ziel hinaus zu verlängern; eine vorgeschlagene Messung.
-
Server-Side Request Forgery: URLs abrufen, die von Nutzenden angegeben werden
Wenn ein Server eine von Nutzenden angegebene URL abruft, kann sie auf interne Dienste und Metadaten-Endpunkte gelenkt werden; Schemata und Hosts per Positivliste zulassen, Adressen auflösen und prüfen, Weiterleitungen in private Adressbereiche unterbinden und wenn möglich ganz auf den Abruf verzichten.
-
Profiling vor der Optimierung
Mit einem Profiler messen, wo die Zeit tatsächlich verbraucht wird, bevor Code aus Geschwindigkeitsgründen geändert wird; die meisten Vermutungen über Hotspots sind falsch, und ungemessene Optimierung fügt Komplexität ohne Nutzen hinzu.
-
Überlauf bei vorzeichenbehafteter Arithmetik: den Compiler-Vertrag dokumentieren, bevor die Optimierung geändert wird
Arithmetische Anforderungen von den GCC-Überlauf-Flags trennen, wenn sich ein Release-Build anders verhält als ein Debug-Build.
-
Token Bucket, Leaky Bucket und Sliding Window: wie sich Rate-Limiter-Algorithmen unterscheiden
Fixed Windows sind günstig, lassen an einer Grenze aber die doppelte Rate durch; Sliding Logs sind exakt, speichern aber jeden Zeitstempel; Sliding-Window-Zähler nähern sich mit konstantem Speicherbedarf an; Token Buckets erlauben Bursts bis zur Bucket-Grösse bei fester Auffüllrate; Leaky Buckets glätten die Ausgabe durch Verzögerung. nginx und Envoy dokumentieren die letzten beiden.
-
Was ein Agent von einer API-Beschreibung braucht
Agenten lesen maschinenlesbare Beschreibungen statt Fliesstext: stabile Links aus einem einzigen Discovery-Dokument, typisierte Antworten, dokumentierte Fehler und Retry-Signale, Idempotenz sowie explizite Aussagen darüber, was nicht verfügbar ist.
-
Eine Request-ID durchgängig mitführen: Edge, Logs, nachgelagerte Aufrufe und die Antwort
Am Edge eine Request-Kennung erzeugen (nginx bietet $request_id, 16 zufällige Bytes in Hexadezimalform), sie der Anwendung per Header übergeben, sie im anfragebezogenen Kontext halten, sodass jede Logzeile und jeder ausgehende Aufruf sie mitführt, und sie in der Antwort zurückgeben, damit sich die Meldung einer nutzenden Person den Logs jedes berührten Dienstes zuordnen lässt; wo Tracing vorhanden ist, ist die W3C-Trace-ID diese Kennung.
-
Testdaten-Builder mit Standardwerten verringern Testausfälle, wenn sich ein Domänenobjekt ändert
Hypothese: Testsuiten, die Objekte über Builder erzeugen, bei denen jedes Feld einen gültigen Standardwert hat und ein Test nur die Felder setzt, auf die er sich in der Prüfung bezieht, benötigen bei einer Schema- oder Konstruktoränderung weniger Testanpassungen als Suiten, die auf geteilten Fixtures oder Object Mothers mit vorgefertigten Instanzen beruhen.
-
E-Mail-Adressen validieren: was eine Syntaxprüfung zeigen kann und was nicht
RFC 5321 begrenzt den Local-Part auf 64 Oktette und einen Pfad auf 256; der HTML-Standard verwendet für input type=email bewusst eine einfachere Grammatik als RFC 5322; internationalisierte Adressen benötigen SMTPUTF8 durchgängig. Syntax und Längen prüfen, bei der Registrierung den MX-Eintrag nachschlagen, den Besitz per Nachricht bestätigen und eine Adresse nie automatisch "korrigieren".
-
Ein zusammengesetztes Urteil in atomare Fragen zu zerlegen erhöht bei einem Entscheidungsmodell die Übereinstimmung mit menschlichen Labels im Vergleich zu einer einzelnen mehrfaktoriellen Frage
Herstellerhinweise zu Entscheidungsmodellen empfehlen, pro Frage genau eine bestimmte Sache abzufragen und im Code zu kombinieren; diese Hypothese formuliert diese Vorhersage als messbare Behauptung: Bei Urteilen, die mehrere unabhängige Faktoren abwägen, stimmt die zerlegte Form häufiger mit menschlichen Labels überein als eine einzelne Frage, deren Kriterien die Kombination beschreiben.
-
Das Ausführungsziel festhalten, bevor ein Diagnoseergebnis interpretiert wird
Feststellen, welchen Prozess, welchen Checkout, welche Dienstinstanz oder welche Datenbank ein Diagnosebefehl tatsächlich erreicht hat, bevor sein Ergebnis auf das von der nutzenden Person gemeldete Problem angewendet wird.
-
Gebackene Lightmaps mit Light Probes für bewegte Objekte kombinieren
UV-Layouts für Oberflächen und räumliche Beleuchtungs-Samples gemeinsam planen, damit statische Szenerie und dynamische Objekte ein stimmiges gebackenes Beleuchtungssetup teilen.
-
Barrierefreiheit: die vier WCAG-Grundsätze praktisch angewendet
Die WCAG 2.2 ordnen alle Erfolgskriterien vier Grundsätzen zu: wahrnehmbar, bedienbar, verständlich, robust. Wer pro Grundsatz die häufigsten Verstösse kennt (fehlende Textalternativen, Tastaturfallen, zu wenig Kontrast, unbeschriftete Felder, zu kleine Ziele), findet viele Barrieren ohne Spezialwerkzeug; Stufe AA ist das übliche Ziel.
-
Ren'Py-Dialogverzweigungen: Entscheidungen, Story-Variablen und Rücksprungpfade verbinden
Menüs wählen lokale Story-Blöcke aus, Labels gliedern die Ziele, und eindeutig gewählte call- oder jump-Semantik sorgt dafür, dass Verzweigungen ihre Folgen behalten und gezielt wieder zusammenlaufen.
Maschinenlesbar: JSON