Remote-Work-Infrastruktur — Bereit zum Arbeiten von überall

Ende 2019 begannen wir, mit vollständiger Remote-Arbeit für einen Teil unseres Teams zu experimentieren. Wir ahnten nicht, wie sehr sich diese Investition auszahlen würde. Hier sind unsere Erfahrungen mit dem Aufbau einer Remote-First-Infrastruktur.

Warum Remote Work vor der Pandemie?¶

Der Grund war prosaisch — wir wollten Talente außerhalb Prags gewinnen. Ein Senior-Java-Entwickler in Brünn wollte nicht pendeln, war aber genau die Person, die wir brauchten. Also begannen wir, Infrastruktur aufzubauen, die vollwertiges Arbeiten von überall ermöglicht.

Unsere Ausgangssituation war nicht ideal. Die meisten internen Systeme liefen On-Premise, die VPN war für 10 gleichzeitige Verbindungen dimensioniert, und die Unternehmenskultur ging davon aus, dass alle im Büro sitzen. Die Veränderung musste sowohl technisch als auch kulturell sein.

VPN — notwendiges Minimum, nicht die Lösung¶

Von OpenVPN auf einem Server wechselten wir zu WireGuard mit Redundanz. WireGuard ist schneller, einfacher zu konfigurieren und hat deutlich niedrigere Latenz. Für Entwickler, die auf interne Git-Repositories und CI/CD-Pipelines zugreifen müssen, war es ein Game Changer.

Aber VPN ist nur ein Tunnel. Er stellt nicht sicher, dass der Benutzer auf der anderen Seite der ist, der er vorgibt zu sein. Er stellt nicht sicher, dass sein Gerät sicher ist. Deshalb begannen wir, Alternativen zu erkunden — über den Zero-Trust-Ansatz werden wir im nächsten Artikel schreiben.

Virtual Desktop Infrastructure¶

Für den Zugang zu sensiblen Kundendaten deployten wir Apache Guacamole als clientloses Remote-Desktop-Gateway. Entwickler verbinden sich über den Browser mit einem virtuellen Desktop, auf dem sie alles Nötige haben. Daten verlassen nie das Rechenzentrum.

VDI hat Nachteile — Latenz beim Coden, IDE verhält sich anders als lokal, man braucht reichlich Server-Leistung. Aber für compliance-intensive Projekte (Banken, Versicherungen) ist es oft die einzig akzeptable Variante.

Cloud-Tools statt On-Premise¶

Parallel migrierten wir Tools in die Cloud:

• GitLab — von Self-Hosted zu GitLab.com (SaaS)
• Jira + Confluence — Migration zu Atlassian Cloud
• Slack — ersetzte den internen XMPP-Server
• Google Workspace — Dokumente, Kalender, Meet

Ergebnis: Kein Tool erfordert VPN, alles läuft im Browser, und die Verwaltung ist einfacher.

Sicherheit und kultureller Wandel¶

Remote Work bringt neue Herausforderungen. Wir führten MFA überall ein, Device Management, Netzwerksegmentierung und Audit-Logs. Überraschenderweise war der schwierigste Teil nicht die Technologie, sondern die Menschen. Manager mussten auf Outcome-basiertes Management umstellen — keine Entscheidungen an der Kaffeemaschine, alles in schriftlicher Form.

Zentrale Regel: Was nicht schriftlich festgehalten ist, existiert nicht. Jedes Meeting hat ein Protokoll in Confluence. Jede Aufgabe ist in Jira. Es ist mehr Arbeit, stellt aber sicher, dass Remote-Kollegen dieselben Informationen haben.

Investition, die sich ausgezahlt hat¶

Remote-Work-Infrastruktur ist nicht nur VPN und ein Laptop. Es ist ein ganzes Ökosystem aus Tools, Prozessen und Kultur. Wir investierten Monate Arbeit hinein — und es sollte sich bald zeigen, wie weitsichtig diese Investition war.