#FlattenTheCurve – Vorstellung unserer Remote-Infrastruktur

Die Corona-Krise hat uns alle, sowohl als Privatpersonen als auch als Firmen, plötzlich ziemlich hart getroffen und stellt unsere gesamte Gesellschaft vor neue Herausforderungen. Wir als Pengutronix möchten uns bei denjenigen bedanken, die in systemkritischen Berufen arbeiten und unsere alltägliche Versorgung sicherstellen.

Aber es wird auch eine Zeit nach der Krise geben, und unsere Gesellschaft wie auch die Wirtschaft werden sich erholen – somit ist es für uns keine Option, einfach unsere Arbeit niederzulegen. Selbstverständlich möchten wir dabei verantwortungsbewusst handeln und den größtmöglichen Schutz für unsere Kollegen und Angehörigen gewährleisten.

Daher haben wir vor zwei Wochen kurzerhand fast alle Mitarbeiter ins Homeoffice geschickt, um die Ansteckungsgefahr innerhalb der Firmenräume so gering wie nur möglich zu halten.

Obwohl wir einige wenige Kollegen haben, die auch in Nicht-Krisenzeiten vollzeit remote arbeiten, befindet sich der Großteil der Kollegen normalerweise in unserem Büro in Hildesheim. Dort trifft man sich gerne an der zentralen Kaffeetheke, um über technische Probleme zu diskutieren, Ideen auszutauschen oder auch mal, um einfach locker zu quatschen. Daher ist es für die meisten von uns ebenfalls eine ungewohnt neue Situation, isoliert und von zu Hause aus zu arbeiten.

Wegen der grundlegend vorhandenen Strukturen war es uns möglich, unsere Infrastruktur in kurzer Zeit so zu erweitern, dass alle Kollegen innerhalb eines Tages (inklusive Bildschirme tragen) wieder arbeitsfähig waren und mit ihren eigentlichen Aufgaben fortfahren konnten.

Aus Gründen, die irgendwo zwischen Bequemlichkeit von Entwicklern und der überlegenen Effizienz eines vollautomatisierten Setups liegen, haben wir über die Jahre viele Aufgaben im Bereich der Embedded-Entwicklung automatisiert oder schon mit einem softwareseitigen Zugriff ausgestattet. Aber auch bei uns gibt es einige Tätigkeiten, die vor Ort erledigt werden müssen (wie Pakete annehmen oder Kabel an einigen Boards umstecken), sodass täglich ein Kollege in unserem Büro die Stellung hält.

Obwohl die meisten unserer Arbeitsabläufe bereits an die Remote-Arbeit angepasst waren, mussten wir sie doch hier und da erweitern, um den zusätzlichen Herausforderungen zu begegnen, die sich ergeben, wenn plötzlich alle Kollegen aus der Ferne arbeiten.

Wir möchten an dieser Stelle gerne unsere Erfahrungen teilen, die uns helfen den Mitarbeitern trotz physikalischer Distanz ein produtkives und sozial kommunikatives Arbeiten zu bieten.

Remote-Arbeit auf Softwareebene

Um unsere tägliche Arbeit zu ermöglichen, haben wir eine größere Serverfarm, auf der wir unsere Infrastruktur aufsetzen und via SSH zugreifen können. Sämtliche unserer Projekte (Quellcode wie auch das dazugehörige Projektmanagement) verwalten wir in Git-Repositories, was uns nebenbei eine hervorragende Nachverfolgbarkeit von Änderungen ermöglicht.

Das Kompilieren von Code und das Bauen der Board Support Packages ist natürlich ziemlich ressourcenhungrig und braucht eine Menge Rechenleistung, die wir über einen ICECC Compiling-Cluster und den besagten SSH-Zugriff bereitstellen können.

Gerade weil wir diese Infrastruktur schon seit Jahren nutzen, pflegen und weiterentwickeln, konnten unsere Kollegen schnell zu Hause ihre Rechner starten und einfach (fast) wie gewohnt weiterarbeiten.

Remote Conversation

Internet Relay Chat (IRC) und E-Mail

Nach wie vor sind IRC und E-Mail unsere beliebtesten und wichtigsten asynchronen Kommunikationswerkszeuge.

In Zeiten, in denen (gefühlt) jede Woche eine neue Messaging-App erscheint, die noch bessere Kommunikationsmöglichkeiten verspricht, mag IRC ein wenig angestaubt erscheinen. Für unsere Entwickler gehört der IRC aber allein deswegen schon zum Tagesgeschäft, weil er in vielen Open-Source-Projekten oft die bevorzugte Variante ist, um miteinander im Chat zu diskutieren.

Außerdem lässt sich der Dienst einfach auf eigener Infrastruktur betreiben und mit diversen simplen Clients nutzen, sodass unsere Mitarbeiter nicht gezwungen sind, (private) Smartphones für wichtige Kommunikation zu nutzen. Außerdem hat IRC den großen Vorteil, dass man nicht durch eine Flut von Bildern und Videos, die einen nicht wirklich interessieren, aus der Arbeit gerissen wird. ;-)

Unsere übliche projektbezogene Kommunikation läuft nach wie vor über Mailinglisten.

Voice-Chat dank Mumble

Wir nutzen bereits seit längerem Mumble, einen Open-Source VoIP-Chat-Server, um uns mit unseren remote arbeitenden Kollegen zu unterhalten. Diese bei gemeinsamen Onlinespielen gebräuchliche Konferenzsoftware ist nun unsere virtuelle Kaffeetheke geworden. Über Mumble können wir sowohl unsere regelmäßigen Stand-Up-Meetings in großer Runde fortsetzen als auch in kleineren Gruppen themenbezogene Diskussionen starten.

Empfehlung: bei einer dauerhaften Konferenzschaltung – unabhängig von der Softwarelösung – die persönlichen Einstellungen auf Push To Talk setzen. Eure Gesprächspartner werden es Euch danken.

Zeigen und Erklären – Jitsi

Trotz aller bisher gut funktionierender Kommunikation reicht es manchmal nicht aus, nur miteinander zu reden. Bei der gemeinsamen Arbeit ist es zwischendurch hilfreich und wichtig, gemeinsam auf einen Bildschirm oder ein Stück Hardware zu schauen – oder doch in das Gesicht, um die Person gegenüber besser zu verstehen.

Für diese Fälle haben unsere Admins einen Jitsi-Server aufgesetzt. Die ersten vorsichtigen Erfahrungen mit der im Browser laufenden Videokonferenz sind selbst bei längeren Konferenzschaltungen mit einigen wenigen Teilnehmern auch bei geringer Bandbreite recht vielversprechend. Wir planen, in den nächsten Tagen noch einige Performance-Tests durchzuführen.

Remote-Arbeit an Hardware

Einer der großen Unterschiede zwischen Pengutronix und vielen anderen Software-Entwicklungsdienstleistern ist, dass wir sehr viel direkt auf und mit Hardware arbeiten (zum Beispiel, um Linux-Kernel-Treiber weiterzuentwickeln oder zu testen). Das bedeutet aber auch, dass unsere Kollegen Zugang zu den Entwicklungsboards brauchen.

Im Moment profitieren wir davon, dass sich die Remote-Arbeit im Homeoffice technisch nicht sonderlich von unserem bisherigen alltäglichen Arbeiten unterscheidet.

Sobald ein Kundenboard bei uns initial in Betrieb genommen ist, hängen wir es in eines unserer Remote-Labs. Über die dazugehörige SSH-Infrastruktur können die Entwickler direkt von ihrem Arbeitsplatz aus die Stromversorgung schalten, auf die serielle Konsole zugreifen oder sich per Netzwerkzugang mit dem Board verbinden. Aber vor allem ermöglichen unsere Remote-Labs uns die Testautomatisierung.

Unser Remote-Setup

Wir haben in den letzten Jahren sowohl softwareseitig als auch mit spezialisierter Hardware viel Aufwand in Technik investiert, die das Remote-Arbeiten an unseren Kunden-Boards ermöglicht. Mit dem nun folgenden Einblick in unsere Arbeitsumgebung hoffen wir, auch andere zu inspirieren:

Jedes Remote-Lab besteht aus den folgenden Komponenten:

  • einem über das Netzwerk kontrollierbaren Power Switch (Gude oder netio),
  • einem über Ethernet kontrollierbaren Seriellen Server (siehe RFC 2217),
  • einem Netzwerkswitch und
  • einem kleinen Server.

Einige Remote-Labs haben außerdem

  • eine CAN-Infrastruktur, für erweriterte Schaltaufgaben (IO)
  • USB-Hubs, um USB-Geräte zu kontrollieren.

Unser Open-Source-Hardware-Automatisierungstool labgrid ist dann die Komponente, die Hard- und Software verbindet, indem sie die physikalischen Ressourcen abstrahiert und auf den Monitor der Entwickler bringt.

Dafür läuft auf dem kleinen Server in jedem Remote-Lab ein 'labgrid exporter', der automatisch eine virtuelle "Ressource" für jede verfügbare Fernsteuer-Hardware im Lab anlegt. Das kann dann zum Beispiel ein Powerswitch, eine serielle Konsole, ein USB-Gerät, oder ein CAN-IO sein.

Diese Ressourcen lassen sich zu sog. Plätzen gruppieren, wodurch sich Ressourcen unter einem einfachen, abstrakten Namen, wie bspw. "mein_entwicklungsboard", zusammenfassen lassen.

Jeder Entwickler kann nun eine lokale Instanz des labgrid-Clients benutzen, um zum Beispiel Plätze zu sperren, ein Board neu zu starten oder per serieller Konsole auf dieses zuzugreifen.

Auf einer zentralen VM läuft ein 'labgrid coordinator'. Dieser koordiniert die Zugriffe von den labgrid-Clients auf die Ressourcen der 'labgrid exporter'.

Der Unterschied, ob die Hardware nun von den Schreibtischen im Büro oder per SSH aus dem Homeoffice gesteuert wird, ist dabei so minimal, dass sich nun der Aufwand, den wir in den Aufbau dieser Infrastruktur gesteckt haben, bezahlt macht.

Hilfreiche Tools

Trotzdem gibt es immer noch Tätigkeiten, die sich in der Embedded-Entwicklung nicht so einfach automatisieren lassen. Ein Beispiel wäre, eine SD-Karte mit einem neuen Softwarestand zu bespielen und diese wieder in das Board zu stecken. Zumindest für diesen Fall hat unser Partner Linux Automation GmbH den USB-SD-Mux entwickelt.

Der USB-SD-Mux ist eine kleine Platine, die an einem Ende wie eine µSD-Karte geformt ist und am anderen Ende einen µSD-Karten-Slot enthält. Der USB-SD-Mux wird nun anstelle einer µSD-Karte in das Board geschoben, und die eigentliche µSD-Karte wird in den USB-SD-Mux gesteckt. Der USB-SD-Mux wird mittels USB-Kabel mit einem Host-PC verbunden und kann so die Karte zwischen dem Host-PC und unserem Board („Device under Test“) umschalten. Im Host-PC erscheint die SD-Karte als ein ganz normaler USB-Massenspeicher und kann dort einfach neu beschrieben werden.

Da uns selbst noch zahlreiche weitere Automatisierungen fehlen, sind bereits die nächsten Werkzeuge in der Entwicklungs- und Testphase. Darunter sind der ETH-Mux, der Ethernet schalten wird (um die Kabel nicht mehr abziehen und neu stecken zu müssen), und ein USB-OTG-Mux, der das Stecken eines USB-Sticks simuliert. Dazu bald mehr… :-)

Obwohl wir das Gefühl haben, dass unsere Remote-Infrastruktur gut aufgestellt ist und wir keine Probleme haben, weiter zu arbeiten, hoffen wir doch darauf, dass wir uns bald wieder an der Kaffeetheke treffen können und wir die Krise gut überstehen.

Bleibt gesund!