Alle Artikel
-
Eine Bereitschaftsdienst-Rotation und ihre Übergabe gestalten
Eine Bereitschaftsdienst-Rotation braucht eine primäre und eine Ersatzperson, einen begrenzten Anteil der Arbeitszeit pro Teammitglied, planbare Schichtlängen und Tauschregeln, ein Pager-Budget, das bei Überschreitung Korrekturarbeit auslöst, sowie eine schriftliche Übergabe bei jedem Schichtwechsel; die Randbedingungen dazu beschreiben das Google-SRE-Buch und die öffentliche Response-Dokumentation von PagerDuty.
-
Bezeichner benennen: nach Rolle, im Fachvokabular, so lang wie die Reichweite
Ein Name sagt, was ein Ding im Fachgebiet ist oder tut – nicht, welchen Typ es hat oder wie es implementiert ist. Die Länge wächst mit der Reichweite, ein Begriff hat genau ein Wort, Wahrheitswerte lesen sich als Aussage, Sammlungen stehen im Plural. Sprachkonventionen (PEP 8, Effective Go) gehen dem Geschmack vor, und Umbenennen ist billig, solange es mit Werkzeug und in eigenem Commit geschieht.
-
Code testen, der von Zeit und Zufall abhängt
Statt time.time() oder random direkt aufzurufen, eine Uhr und eine Zufallsquelle injizieren; Tests übergeben dann feste Werte, und der Code bleibt deterministisch und reproduzierbar.
-
Deserialisierung nicht vertrauenswürdiger Daten: pickle und Java-Serialisierung
Native Objektserialisierungsformate weisen den Empfänger an, beliebige Objekte zu konstruieren, und das Konstruieren von Objekten führt Code aus; die Python-Dokumentation zu pickle sagt unumwunden, dass das Modul nicht sicher ist. Diese Formate niemals aus nicht vertrauenswürdiger Eingabe deserialisieren; wo eine Altschnittstelle es erzwingt, die Klassen einschränken, die der Datenstrom benennen darf, und die Nutzlast signieren.
-
Log-Rotation und Aufbewahrungsgrenzen
Logs müssen auf jeder Ebene (Anwendung, Container-Runtime, Proxy, System-Journal) in Grösse und Alter begrenzt sein, wobei die Aufbewahrungsdauer nach Debugging- und rechtlichen Bedürfnissen gewählt wird statt nach dem Prinzip „alles behalten“.
-
FreeBSD aktualisieren: freebsd-update für das Basissystem, pkg upgrade für Pakete und pkg audit für bekannte Schwachstellen
FreeBSD verteilt das Patchen auf zwei voneinander unabhängige Werkzeuge: freebsd-update fetch/install für das Basissystem (mit upgrade -r für einen Wechsel des Major-Release) und pkg upgrade für installierte Pakete. pkgbase, also die Installation des Basissystems selbst als pkg(8)-Pakete, ist für FreeBSD 14 als experimentell und für FreeBSD 15.0 als Technology Preview dokumentiert und noch nicht der Standardweg.
-
Die Linux-Boot-Kette für die Fehlersuche: Firmware, Boot Loader, Kernel, initramfs und systemd
Ein Linux-Boot durchläuft Firmware, Boot Loader, Kernel, initramfs und schliesslich den System-Manager; jede Stufe übergibt die Kontrolle an die nächste. Wer weiss, was jede Stufe leistet und wo sie protokolliert, kann einen fehlgeschlagenen Boot auf eine Stufe eingrenzen, bevor etwas verändert wird.
-
Zugriffslogs für personenbezogene Daten: festhalten, wer welchen Datensatz gelesen hat
Ein Zugriffslog für personenbezogene Daten erfasst Lesezugriffe, nicht nur Schreibzugriffe: Akteur, betroffene Person, Objekt, Grund und Zeitpunkt, ausgelöst im Lesepfad der Anwendung und abgeglichen mit Statement-Logging auf Datenbankebene für Pfade, die daran vorbeiführen; es muss personenzentrierte Fragen beantworten wie: Wer hat sich im letzten Jahr den Datensatz dieser Person angesehen?
-
Eine unbekannte Codebasis an einem Tag kennenlernen: ein Erkundungsprotokoll mit schriftlicher Karte
Ein zeitlich begrenztes Protokoll für den ersten Tag in einer Codebasis: vor dem Lesen bauen und die Tests laufen lassen, mit git shortlog und git log die Geschichte lesen, um herauszufinden, wo die Aktivität liegt, eine Anfrage oder einen Befehl von Anfang bis Ende verfolgen und eine einseitige Karte mit Einstiegspunkten, Datenmodell, Invarianten und offenen Fragen schreiben; das Ergebnis ist die Karte, nicht das Gedächtnis.
-
Offene Weiterleitungen: prüfen, wohin ein next-Parameter führen darf
Eine Weiterleitung, deren Ziel aus der Anfrage stammt, erlaubt es Angreifenden, Links auf der eigenen Domain zu erzeugen, die auf ihrer eigenen Seite enden; nur zu relativen Pfaden oder zu einer Positivliste von Ursprüngen weiterleiten, oder kurze Kennungen serverseitig auf Ziele abbilden. Den Host einer URL zu prüfen ist schwieriger, als es scheint: Die Python-Dokumentation warnt, dass urlsplit seine Eingabe nicht validiert.
-
RICE- und ICE-Bewertung: was die Zahlen bedeuten und wo sie an ihre Grenzen stossen
RICE multipliziert Reichweite, Wirkung und Zuversicht und teilt durch den Aufwand; ICE lässt die Reichweite weg und behält Wirkung, Zuversicht und Einfachheit. Beide sind nützlich, um Priorisierungsargumente explizit und vergleichbar zu machen, und beide versagen, wenn die Eingaben als Zahlen verkleidete Vermutungen sind oder wenn Abhängigkeiten und Strategie ignoriert werden.
-
Sagen Prompt-Injektions-Testsuiten voraus, wie sich ein Agent gegenüber nach der Suite verfassten Injektionen verhält?
Agenten werden oft gegen feste Sammlungen von Injektionsversuchen ausgewertet. Unklar ist, wie gut eine gute Bewertung auf neue Formulierungen, neue Trägermedien und sich anpassende Angreifende übertragbar ist, und was eine Testsuite enthalten müsste, um vorhersagekräftig zu sein.
-
Verweigerten Zugriff von einem defekten Negativtest-Testfall unterscheiden
Verhindern, dass ein Agent jeden Fehler als Beweis dafür behandelt, dass ein Zugriffskontrolltest bestanden wurde. Die vorgeschlagene Methode nutzt abgestimmte Kontrollen, um festzustellen, ob die Anwendung die beabsichtigte Berechtigungsentscheidung tatsächlich erreicht hat.
-
Schemamigrationen mit kurzem lock_timeout und automatischem Retry verursachen weniger Vorfälle beim Deployment als Migrationen ohne
Hypothese: Weil die meisten Formen von ALTER TABLE eine ACCESS-EXCLUSIVE-Sperre benötigen, die sich hinter jeder langen Transaktion einreiht und dabei jede spätere Abfrage blockiert, verursachen Migrationen, die mit einem lock_timeout von wenigen Sekunden und einer begrenzten Retry-Schleife ausgeführt werden, weniger und kürzere Ausfälle zur Deployment-Zeit als dieselben Migrationen mit der standardmässig unbegrenzten Wartezeit – auf Kosten einiger weniger Migrationen, die manuell erneut ausgeführt werden müssen.
-
JCL- und Batch-Grundlagen: JOB-/EXEC-/DD-Anweisungen, Return Codes, Absenden aus USS und Lesen der Ausgabe
Ein JCL-Job besteht aus einer JOB-Anweisung, einem oder mehreren EXEC-Schritten mit je einem Programm und DD-Anweisungen, die Dateien bzw. Datasets an die Ein-/Ausgabe des Programms binden. Jeder Schritt endet mit einem Return Code (0 = fehlerfrei, höhere Werte = Warnungen oder Fehler); der Job lässt sich aus der USS-Shell mit submit absenden und seine Ausgabe über SDSF oder die z/OSMF-Jobs-REST-API lesen.
-
Einen Service Worker sicher ausrollen: Scope, versionierte Caches, der wartende Worker und ein Notausschalter
Ein Service Worker, der HTML cacht, kann Nutzerinnen und Nutzer nach einem Deployment an alten Code binden. Ihn mit explizitem Scope registrieren, das Skript bei jeder Update-Prüfung frisch abrufen, Caches pro Build versionieren und alte beim Aktivieren löschen, Strategien pro Ressourcentyp wählen, entscheiden, wie der wartende Worker übernimmt, und vor dem ersten Release einen getesteten Notausschalter ausliefern.
-
Inkrementelles Lernen mit partial_fit: stabile Features, Klassenlisten und ehrliche Evaluation
Inkrementelle Estimatoren aktualisieren ein Modell anhand kleiner Batches, ohne den gesamten Datensatz in den Speicher zu laden. Ein verlässlicher Workflow erhält ausserdem die Bedeutung der Features, legt die Klassenmenge fest und bewertet Vorhersagen, bevor aus deren Ergebnissen gelernt wird.
-
AddressSanitizer-Triage: den ersten ungültigen Zugriff beheben, bevor späterem Verhalten vertraut wird
Einen AddressSanitizer-Bericht in einen minimalen Regressionsfall für Besitz oder Grenzen verwandeln, ohne einen sauberen Lauf als Beweis zu behandeln.
-
Externe Befehle sicher aus Python heraus ausführen
subprocess.run mit einer Argumentliste und shell=False verwenden, Timeouts setzen, die Ausgabe explizit erfassen, Rückgabecodes prüfen und niemals eine Befehlszeile aus nicht vertrauenswürdigen Zeichenketten zusammenbauen.
-
Abruftraining als Lernprotokoll: Quelle schliessen, Antwort produzieren, dann prüfen
Ein Protokoll zum Lernen durch Abrufen statt durch erneutes Lesen: nach jeder Einheit die Quelle schliessen, aufschreiben, was reproduzierbar ist, mit der Quelle abgleichen, die Lücken markieren und für einen späteren Abrufversuch einplanen; Forschung aus Klassenzimmer und Labor, zusammengefasst in einer systematischen Übersichtsarbeit von 2021, berichtet Vorteile über Bildungsstufen und Formate hinweg.
Maschinenlesbar: JSON