Wie wahrscheinlich die meisten Unternehmen hat uns das Ausmaß und die Geschwindigkeit, mit der die Ausbreitung des Coronavirus sich auf die alle Bereiche des öffentlichen Lebens auswirkt, sehr überrascht. Anders als viele andere Unternehmen waren wir aber in der Lage, schnell auf diese unvorhergesehene Situation zu reagieren. So konnten wir schon relativ früh die Entscheidung treffen, das Arbeiten im Homeoffice zum Regelfall zu machen. Die erfolgreiche Umstellung auf diesen Arbeitsmodus hat sich fast geräuschlos vollzogen. Einen ganz wesentlichen Anteil daran hat unser Team, das den aktuellen Herausforderungen sehr optimistisch und professionell begegnet und dafür sorgt, dass die Zusammenarbeit sowohl intern als auch gegenüber unseren Kunden auch unter erschwerten Bedingungen sehr gut funktioniert.
Bereit für Remote Work durch die richtige Infrastruktur
Auch mit einer positiven Hands-on-Mentalität und einem agilen Mindset kommt man aber nicht weit, wenn es an der nötigen Infrastruktur fehlt. Neben den verschiedenen Kommunikations- und Coworking-Tools die wir nutzen, kommt es für basecom als Softwaredienstleister darauf an, dass unseren Softwareentwickler*innen auch zu Hause die technischen Ressourcen zur Verfügung stehen, die sie brauchen, um problemlos an ihren Projekten zu arbeiten. Welche Lösungen basecom dafür gefunden hat und welche technische Infrastruktur dafür nötig ist, erklärt Justus Klein, der sich als Tech Head in unserem Bereich Symfony die Zeit genommen hat, unsere Fragen zu beantworten:
Mit unserem ‘Entwicklungscluster’ halten wir bei basecom eine Infrastruktur bereit, die unseren Entwickler*innen ermöglicht remote, also auch aus dem Homeoffice, die gleiche Rechenleistung abzurufen, die ihnen auch vor Ort zur Verfügung steht. Wie funktioniert das?
Wir benutzen für unsere Projekte Docker, eine Lösung zur ‘Containerisierung’. Dadurch lässt sich Software isoliert bauen, übertragen und betreiben. Unsere Projekte haben unterschiedliche und sich stetig weiterentwickelnde Anforderungen an die Laufzeitumgebung und zusätzliche Services, die zum Betrieb und/oder zur Entwicklung notwendig sind (Datenbanken, Webserver, Cache-Services, etc.). Über Docker können wir diese Anforderungen abbilden und über unsere üblichen Tools zur Code-Verwaltung versionieren, verwalten und ausliefern. Gleichzeitig können wir so unkompliziert zwischen Projekten mit gänzlich unterschiedlichen Umgebungen, Anforderungen und Diensten wechseln, ohne etwas konfigurieren oder installieren zu müssen.
Docker gibt es im Grunde nur für GNU/Linux-Distributionen, sowie für Windows (dort über ein Linux-Subsystem, oder Windows-Container nativ). Wir benutzen allerdings MacOS. Hierfür gibt es seit geraumer Zeit eine Lösung ‘Docker for Mac’, welche über einen nativen MacOS-Hypervisor-Docker in einer entsprechenden Linux-Umgebung zur Verfügung stellt. Darüber können wir Docker auch direkt auf unseren Geräten nutzen. Diese Lösung führt allerdings zu einem Performance-Verlust, da der Netzwerk- und auch Dateizugriff über eine zusätzliche ‘Schicht’ laufen muss. Der Verlust ist zwar beispielsweise im Vergleich zu einer Virtualisierung nicht so groß, aber dennoch merklich. Hinzu kommt noch, dass wir zum Entwickeln weitere Tools auf unseren Geräten benötigen. Bei umfangreicheren Projekten, oder auch dem parallelen Arbeiten an mehreren Projekten kommen unsere Geräte schnell an ihre Grenzen und die längeren Ladezeiten mindern die Produktivität.
Um diesen Problemen entgegenzuwirken haben wir den ‘Entwicklungscluster’ eingeführt. Bestehend aus drei Hypervisor- und zwei Storage-Servern steht uns direkt im Büro eine große Menge an Rechenpower zur Verfügung. Auf diesem zentralen System erhält jede Entwickler*in eine eigene virtuelle Maschine (als Lösung zur Virtualisierung setzen wir auf Proxmox) auf Basis von Ubuntu (GNU/Linux). Auf diesen Maschinen ist Docker vorinstalliert und der Zugriff erfolgt per SSH. Alle Projekte liegen weiterhin auf unseren MacOS-Geräten, werden aber ebenfalls auf den VMs hinterlegt. Sobald wir eine Änderung, z.B. am Quellcode, auf unserem Endgerät vornehmen, wird diese automatisch sofort an unsere VM übertragen. Dort läuft dann die eigentliche Applikation, auf welche wir über HTTP zugreifen können bzw. diese über eine SSH-Verbindung steuern können. An der eigentlichen Arbeitsweise ändert sich dadurch nicht viel. Im Browser muss eine andere URL aufgerufen werden und Befehle (über SSH) auf der VM getätigt werden.
Auch wenn das etwas Umgewöhnung erfordert, sind die Vorteile enorm. Die bessere Performance ist nur ein Aspekt. Die virtuellen Maschinen werden von unserer Technik zentral verwaltet und stets aktuell gehalten, sie lassen sich bei Bedarf vergrößern & verkleinern (CPU, RAM, Festplatte etc.) und bieten mit ihrer GNU/Linux-basierten Distribution ein System, das nahezu identisch mit den Produktiv-Servern ist. Weiterhin steht den Entwickler*innen so ein Betriebssystem zur Verfügung, das im Gegensatz zu MacOS, mit seinem Open-Source-Ansatz explizit für Softwareentwicklern*innen entwickelt wurde und neben umfangreichen Möglichkeiten zur Individualisierung auch ein breites Feld an Tools zur Entwicklung zur Verfügung stellt.
Der ‘Entwicklungscluster‘ steht in einem kleinen Serverraum, direkt bei uns im Büro. Das vermindert die Latenz beim Arbeiten zusätzlich etwas, sorgt aber dafür, dass für den externen Zugriff z.B. aus dem Homeoffice eine VPN-Verbindung notwendig ist.
Um sicherzustellen, dass das VPN auch bei erhöhtem Traffic durch externe Zugriffe stabil ist, wurde es vor Inkrafttreten der Homeofficeregelung einem Stresstest unterzogen. Gab es Probleme mit dem Netzwerk, seit die meisten Entwickler*innen von zu Hause arbeiten?
Wir haben eine 200 Mbit/s Leitung. Im Unterschied zu den meisten privaten Anschlüssen wird diese Bandbreite bei Business-Anschlüssen jedoch jederzeit zu nahezu 100% garantiert. Außerdem sind diese Leitungen meist ’synchron‘. Das bedeutet, dass uns die volle Bandbreite in beiden Richtungen (Upstream & Downstream) zur Verfügung steht. In Zeiten wo viele Privatleute in der Stadt problemlos 1000 Mbit/s bekommen können, klingt das nicht nach viel. Eine gut konfigurierte Firewall sorgt jedoch dafür, dass die zur Verfügung stehenden Ressourcen zu jeder Zeit sinnvoll zwischen den Nutzer*innen aufgeteilt werden. So können einzelne Datenübertragungen die Leitung nur soweit ausreizen, dass alle anderen aktuell aktiven Nutzer immer noch eine ausreichende Bandbreite zur Verfügung haben. Sicherlich sorgen die externen Verbindungen per VPN, sowie der Aspekt, dass zuvor interner Traffic nun ebenfalls über die Internetverbindung laufen muss, für eine zusätzliche Belastung. Um sicherzustellen, dass diese unsere Kapazitäten nicht übersteigt wurde der Stresstest gemacht. Dabei wurde festgestellt, dass unsere Systeme wie erwartet funktionieren und wir allen Mitarbeiter*innen eine Mindest-Bandbreite gewährleisten können, die für die tägliche Arbeit ausreicht.
Weiterhin ist ein wichtiger Aspekt, dass wir nicht zwangsläufig den gesamten Datenverkehr der Mitarbeiter*innen über unser VPN leiten, sondern nur die Verbindungen bei denen ein Weg über das Firmennetzwerk technisch nötig ist. Dazu gehören Verbindungen zu den Systemen vor Ort, sowie zu geschützten Kundensystemen. Da wir die meisten unserer Tools der täglichen Arbeit auf sogenannten ‚Public-Clouds‘ betreiben (z.B. AWS) sind diese ohnehin bereits von extern erreichbar und wir ersparen uns eine große Menge zusätzlicher Last, und unseren Kollegen*innen zusätzliche Ladezeit bei der Nutzung dieser Tools.
Natürlich ist das nur die eine Seite. Diese haben wir als Unternehmen gut im Griff und die Systeme wurden laufend aufgebaut, überwacht, durch den Arbeitsalltag getestet und an unsere Bedürfnisse angepasst. Der Internetanschluss der jeweiligen Mitarbeiter*innen im Homeoffice bildet die andere Seite. Hier gibt es natürlich weitreichende Unterschiede. Manche wohnen in derselben Stadt und haben sehr gute Anbindungen, andere auf dem Land, wo sie noch immer auf den Internetausbau warten. Zusätzlich kommt noch hinzu, dass viele Leute aktuell von zu Hause arbeiten und einzelne Verteiler (insbesondere bei Kabelanschlüssen) dafür nicht ausreichend dimensioniert sind und somit zu Stoßzeiten die Bandbreite einbricht.
Glücklicherweise können aktuell alle unsere Mitarbeiter*innen verhältnismäßig problemlos von zu Hause arbeiten. Sollte es in Einzelfällen doch zu Problemen können, so können Kollegen*innen jederzeit auch auf unsere (ansonsten leeren) Büroräume ausweichen.
In der Softwareentwicklung arbeitet ihr agil. Hat diese Arbeitsweise aus deiner Sicht in der momentanen Situation Vorteile? Wie hat sich die Zusammenarbeit in den Teams im Homeoffice-Modus verändert?
Wir arbeiten nach dem agilen Vorgehensmodell ‘Scrum’. Dieses definiert feste Rollen und auch Termine mit festem Rhythmus und klaren Zielen. Auch in der Vergangenheit haben Mitarbeiter*innen, Kund*innen und externe Dienstleister*innen an diesen Terminen vereinzelt remote teilgenommen. Die grundlegenden Strukturen bestanden also bereits und waren auch ausreichend erprobt. Im Grunde hat also lediglich eine Verlagerung der Termine von physischen in virtuelle Besprechungsräume stattgefunden. Da dabei allerdings ein großer Teil der nonverbalen Kommunikation verloren geht, ist es jetzt wichtiger denn je, auf Gesprächsgepflogenheiten zu setzen. So wird verstärkt darauf geachtet, andere ausreden zu lassen, sie nicht zu unterbrechen und auch stilleren Gesprächsteilnehmern Beachtung zu schenken und ihnen die Möglichkeit zu geben sich einzubringen. In der täglichen Arbeit kommt uns hier das Konzept der asynchronen Kommunikation entgegen, welche wir auch zuvor schon angewandt haben. Hierbei geht es darum, dass Mitarbeiter*innen z.B. bei einer technischen Frage nicht direkt den entsprechenden Kollegen oder die Kollegin anrufen, oder persönlich vorbeikommen, sondern zuerst immer den Weg über den Chat (in unserem Fall Slack) sucht. Dadurch wird den Mitarbeiter*innen die Möglichkeit gegeben, die aktuelle Arbeit erst konzentriert abzuschließen.
Meiner Ansicht nach sind wir also strukturell und technisch gut auf die aktuelle Situation vorbereitet. Zusätzlich können wir unsere Systeme, Konzepte und Strukturen auf die Probe stellen und an einigen Stellen sicher noch Optimierungsbedarf ausfindig machen, um für die Zukunft und kommende Herausforderungen noch besser aufgestellt zu sein.
Vielen Dank, Justus, für die ausführliche Erklärung und diesen spannenden Blick in den Maschinenraum! Ihnen allen weiterhin alles Gute und bleiben Sie gesund!
