Projekte und Erfahrung

Neue Server wurden bei Bedarf von Hand aufgesetzt — Betriebssystem, Pakete, Konfiguration, Benutzer, Dienste, jedes Mal einzeln. Das funktioniert, solange es wenige sind. Aber es kostet jedes Mal dieselbe Zeit, und kein Server gleicht dem anderen exakt: hier eine andere Version, dort eine Einstellung, die jemand später von Hand nachgezogen hat. Bei jedem neuen System begann die gleiche Handarbeit von vorn, und wenn etwas klemmte, war schwer zu sagen, ob es am System lag oder an einer vergessenen manuellen Anpassung. Wer den Server ursprünglich eingerichtet hatte, war oft die einzige Person, die ihn wirklich kannte.

Die Bereitstellung neuer Server so aufsetzen, dass sie schnell geht, wiederholbar ist und jedes Mal dasselbe Ergebnis liefert — dokumentiert, nicht im Kopf einer einzelnen Person.

Ich habe die immer gleichen Schritte in Ansible abgebildet: Grundkonfiguration, Pakete, Dienste, Benutzer und Rechte. Aus einmaliger Handarbeit wurde versionierter Code, den ich wiederverwenden kann. Ein neuer Server entsteht seitdem nicht mehr durch Zusammenklicken, sondern durch einen Lauf, der auf jeder Maschine dasselbe tut — nachvollziehbar, weil jeder Schritt im Code steht.

Server werden seither reproduzierbar und in einem Bruchteil der früheren Zeit bereitgestellt. Was vorher wiederholte Handarbeit pro Maschine war, ist ein Lauf, der überall dasselbe Ergebnis liefert; die gesparte Zeit summiert sich mit jedem weiteren Server. Und weil die Konfiguration in Code liegt statt in Erinnerungen, ist nachvollziehbar, warum ein Server so aussieht, wie er aussieht — auch für jemanden, der ihn nicht selbst aufgesetzt hat.

Von Anfang an in kleinen Rollen denken statt in einem großen Playbook. Der Zwischenschritt über die monolithische Variante war vermeidbar — die Aufteilung, die am Ende stand, hätte gleich der Startpunkt sein können.

Ein Betrieb brauchte gesicherten Zugriff auf interne Systeme für Mitarbeiter, die außerhalb des Büros arbeiten. Eine Lösung dafür gab es bereits — über die Jahre gewachsen, Stück für Stück erweitert, von wechselnden Händen angefasst. Das Ergebnis war ein Zustand, den niemand im Haus mehr vollständig überblickte: Es lief irgendwie, aber warum es lief und was passieren würde, wenn ein Teil ausfällt, konnte niemand sicher sagen. Genau das ist die Situation, in der ich am häufigsten gerufen werde — nicht weil nichts funktioniert, sondern weil niemand mehr erklären kann, wie es funktioniert.

Den Fernzugriff neu aufsetzen. Drei Bedingungen waren dem Kunden und mir wichtig: nachvollziehbar, sauber dokumentiert und ohne dauerhafte Abhängigkeit von mir. Am Ende sollte keine Lösung stehen, die nur ich bedienen kann.

Ich habe zuerst eine eigene Lösung auf Basis von WireGuard gebaut. WireGuard ist schlank, gut verstanden und lässt sich vollständig in Code beschreiben — auf dem Papier genau das, was zu meinem Anspruch passt: alles selbst in der Hand, alles dokumentiert. Ich habe die Konfiguration aufgesetzt, die Zugänge eingerichtet und das Ganze in einer Testphase unter realen Bedingungen laufen lassen.

Am Ende stand ein funktionierender, dokumentierter Fernzugriff, den der Kunde ohne mich betreiben kann. Wer Zugriff hat und wie man jemanden hinzufügt oder entfernt, steht schriftlich fest. Meine Rolle war damit erledigt — so, wie es sein soll.

Den Vergleich der beiden Ansätze würde ich früher ziehen und in einer kleineren Testumgebung, bevor eine Eigenentwicklung so weit gedeiht. Die Entscheidung gegen die selbstgebaute Variante war richtig — aber ich hätte sie günstiger haben können, wenn ich beide Wege von Anfang an klein gegeneinander getestet hätte, statt einen davon erst voll auszubauen.