Das Netzwerk ist die Schicht, die ich zuletzt dokumentiert habe
Mein Homelab verfügt über ein IPAM, Metriken von jedem Access Point und eine Netzwerk-Konfigurationsdatei, die komplett aus Platzhaltern besteht – mit einer Warnung ganz oben, die das offen zugibt.
Mein Homelab ist bis ins Unvernünftige dokumentiert. Jeder Host hat eine eigene Seite. Jeder zustandsbehaftete Dienst hat ein getestetes Wiederherstellungsverfahren. Es gibt einen Beziehungsgraphen, einen Fakten-Store und eine automatisierte Prüfung, die meckert, wenn die Dokumentation von der Realität abweicht.
Das Netzwerk – das Fundament, auf dem das alles läuft – hat eine Konfigurationsdatei, deren Inhalt Platzhalter sind, und ganz oben eine Warnung, die genau das sagt.
Was tatsächlich existiert
Die Instrumentierung ist in Ordnung. Es läuft ein IPAM-System mit eigener Datenbank, Workern und Backups. Ein Poller zieht Metriken vom Router und den Access Points in Prometheus, Dashboards in Grafana, Blackbox-Probes, Uptime-Monitoring und Alert-Routing. Ein Paar DNS-Server mit automatischem Failover. Ein Reverse Proxy, dessen Routen von einem Collector inventarisiert werden.
Das Netzwerk wird also beobachtet. Es wird nicht beschrieben. Das sind zwei verschiedene Dinge, die ich lange Zeit vermischt habe.
Warum diese Schicht und nicht eine andere
Weil ich dokumentiere, was kaputtgeht, und das Netzwerk fast nie kaputtgeht.
Applikationsschichten brechen wöchentlich, in kleinen, wiederherstellbaren Fällen, jeder einzelne erzeugt einen Fix und eine Notiz. Das ist ein Dokumentations-Schwungrad: häufige, risikoarme Fehler erzeugen Schreiben. Das Netzwerk bricht ungefähr nie – und wenn doch, nimmt es alles mit, genau in dem Moment, in dem du keine Kapazität hast, irgendwas aufzuschreiben.
Das Ergebnis ist eine inverse Beziehung zwischen der Bedeutung einer Schicht und wie gut ich sie beschrieben habe. Die kritischste Schicht erzeugt am wenigsten Dokumentation, weil sie am zuverlässigsten ist. Das ist kein persönliches Versagen, sondern eine strukturelle Eigenschaft von Lernen durch Vorfälle, und es ist gut zu wissen, dass deine Dokumentation dort am dichtesten ist, wo deine Probleme am kleinsten waren.
Das Nützlichste in dieser Datei ist die Warnung
Die Netzwerkdatei besteht aus Platzhaltern. Was sie außerdem ganz oben hat, ist ein explizites Banner, das sagt, dass jeder Wert ein Platzhalter ist und vor dem Vertrauen gegen den Router und den Hypervisor geprüft werden muss.
Dieses Banner leistet mehr Arbeit als der Großteil meiner echten Dokumentation.
Eine Datei voller plausibel aussehender Werte ohne Herkunft ist aktiv gefährlich – jemand liest sie, glaubt einem Subnetz und plant eine Änderung basierend auf einer Zahl, die niemand je verifiziert hat. Dieselbe Datei, die ihre eigene Unzuverlässigkeit ankündigt, ist sicher, weil sie nicht mit Beweisen verwechselt werden kann. Sie ist eine bekannte Lücke statt einer unbekannten Lüge.
Ich habe ein ganzes System aufgebaut nach dem Prinzip, dass eine Behauptung, die ihre Quelle nicht nennen kann, blockiert werden sollte, statt sie zu beschönigen. Dieses Banner ist dieselbe Regel, von Hand angewandt, bevor ich die Mechanismen gebaut habe. Das billigste ehrliche, was ein Dokument tun kann, ist dir zu sagen, dass du ihm noch nicht vertrauen sollst.
Der Ausfall, der den Punkt beweist
Das eine Mal, als das Netzwerk wirklich ausgefallen ist, hat es das ganze Homelab um Viertel vor zwei nachts lahmgelegt. Ich habe zuerst den Reverse Proxy verdächtigt, dann die Intrusion Prevention Layer, dann den Single Sign-On Service. Die eigentliche Ursache war ein Port am Switch, und alles, was ich verdächtigt habe, war ein Symptom davon.
Ich habe nie eine Netzwerkseite geschrieben. Aber ich habe ein Postmortem für diese Nacht verfasst, und das ist das meistgelesene Dokument, das ich über mein eigenes Netzwerk habe – was dir genau sagt, was das Schwungrad belohnt.
Geschrieben von
Adrian Romo
Senior Backend Engineer für skalierbare Python-APIs, AWS-Lambda-Architekturen, Voice-Systeme und Enterprise-Integrationen.
Verwandt
Weiterlesen
Zusammengesetzte Primitives vs. eine Plattform
Ich habe einen Voice-Agenten aus Cloud-Primitiven gebaut, und er hat funktioniert. Inzwischen wurde er durch eine speziell entwickelte Voice-Plattform ersetzt, und ich denke, das war die richtige Entscheidung.
Sechs Beiträge am Tag und der Scheduler, der lernte, wann er sagen soll
Eine Social-Pipeline, die jeden Tag genau einen Reel veröffentlicht hat und sonst nichts, weil die Quoten pro Format als Obergrenzen galten und niemand die anderen Formate nachgefragt hat.
Sekunden der Arbeit, Stunden des Aufenthalts
Mein Morgenbriefing begann zu scheitern. Ollama war zwar erreichbar, lieferte aber HTTP 500 zurück, weil ein 21 Sekunden langer Bild-Render auch Stunden später noch 6,6 GB VRAM belegte.
Weiter geht's
Wohin als Nächstes?
Stöbere durch weitere technische Texte, sieh dir die Engineering Case Studies an oder melde dich direkt.