DevOps bei onOffice und seine Entwicklung

Auf der Suche nach neuen Verbesserungsideen für unsere wachsenden IT-Abteilungen habe ich mich im letzten Jahr zum ersten Mal genauer mit dem Thema DevOps beschäftigt. Ein sehr guter Einstieg für mich war das Buch “Das DevOps-Handbuch” von Gene Kim, Jez Humble, Patrick Debois und John Willis.

• Die für mich größte Erkenntnis nach dem ersten Lesen: Es geht nicht nur um CI/CD-Pipelines, die Philosophie dahinter ist viel spannender.
• Die nächste Erkenntnis: Wir sind in der IT-Welt (mal wieder) sehr eigenwillig unterwegs und trennen die Fachexperten für Server und Software sehr klar in verschiedene Teams oder gar Abteilungen auf, statt sie zusammenzubringen, um eine bestmögliche Software zu entwickeln.

Auch wir bei onOffice haben zwei getrennte Bereiche für Softwareentwicklung und Administration. Es gibt zwar Schnittstellen, aber zum Beispiel nahezu keine gemeinsamen Termine.

Die drei DevOps-Wege: Fluss, Feedback und Lernen

Im Bereich “Fluss” sind wir organisatorisch dank unserer Kanban-Philosophie schon sehr gut aufgestellt. Wir haben kleine Arbeitspakete, verfolgen den Kanban-Ansatz sowohl in der Softwareentwicklung als auch in der Administration und haben in beiden Bereichen Systeme zur Flusssteuerung installiert.

Das “Lernen” ist ebenfalls durch Kanban weit verbreitet, interne Schulungen werden beispielsweise schon lange firmenweit angekündigt. Hält ein Entwickler eine Schulung, werden auch immer alle Administratoren eingeladen und umgekehrt.

Für ein gutes Feedback (und “Feed-Forward”) zwischen den Mitarbeitern, die Software programmieren und betreiben, haben wir aber über die Jahre klare Hürden aufgebaut. Es gibt zwei getrennte Abteilungen, mit getrennten Projektboards und getrennten Standup-Terminen zur Flusssteuerung. Wir haben getrennte Quartalsmeetings und sogar getrennte Team-Events.

Allerdings sind schon erste Ansätze vorhanden, um beide Bereiche wieder enger zusammenzubringen.

Zusammenführen der Abteilungen

Da wir firmenweit unsere eigene CRM-Software zur Organisation der Arbeit einsetzen, werden keine unterschiedlichen Tools zur Steuerung eingesetzt – man spricht eine Sprache. Innerhalb der Entwicklung haben wir das “Operation”-Team, das die Software ausliefert und den Betrieb überwacht. Das Team hat, genau wie das Administrations-Team, Zugriff auf die Produktivsysteme und das Monitoring. Dieses Team ist schon sehr häufig in direktem Austausch mit den Administratoren, da bei vielen Problemen erst einmal nicht klar ist, ob ein Server- oder Softwareproblem vorliegt. 

Ein gemeinsamer Chatraum dient quasi als “Andon Chord”. Wenn sich im Monitoring ein Problem andeutet, kann hier sehr schnell abteilungsübergreifend Alarm geschlagen werden, damit Entwickler und Administratoren sich den Fall anschauen.

Andererseits beweist Conways Law, dass es nie gut ist, ein Team zu gründen, um Schnittstellen in Softwaresystemen zu optimieren. Es besteht die Gefahr, dass man dadurch den Schnitt zwischen Softwareentwicklung und Softwarebetrieb sogar noch größer macht.

DevOps im Alltag bei onOffice

Nach dieser ersten Bestandsaufnahme und einem internen DevOps-Vortrag haben wir Ideen gesammelt, wie wir beide Bereiche besser verzahnen und so eine bessere Zusammenarbeit ermöglichen können.

In der Runde kamen sehr schnell viele gute Ideen zusammen. Eine gemeinsame Übersicht über Projekte wurde als sehr wichtig angesehen. Der Wissensaustausch sollte noch weiter gefördert werden – zum Beispiel durch gegenseitige Wissensschulungen am Projektende.

Die beiden Kanban-Boards für Administration und Softwareentwicklung unterscheiden sich im Aufbau. In der Entwicklung gibt es Phasen, in denen das Produktmanagement beteiligt ist und mehrere Phasen für den Test des entsprechenden Features. Das Board in der Administration ist da hingegen einfacher aufgebaut. Und trotzdem gibt es in beiden Boards einzelne Projekte, die jeweils für Administratoren und Entwickler spannend sind. Dazu gehören zum Beispiel:

• Softwareanpassungen, die neue Server-Infrastruktur nötig machen,
• Softwareanpassungen, die größere Auswirkungen auf die Last der Infrastruktur haben,
• und Serverprojekte, auf die bestimmte Entwickler warten.

Erster Lösungsansatz

Wir haben ein eigenes Projektboard erstellt, in dem genau diese Themen dargestellt werden. Alle zwei bis drei Wochen treffen wir uns in der Runde aller Administratoren und Entwickler und gehen diese Themen kurz durch. Dieses DevOps-Standup hat sehr schnell das Verständnis für die andere Seite erhöht. Durch das kurze gegenseitige Update wurde schon das ein oder andere Projekt wieder in die richtige Richtung gestoßen.

Dank des DevOps-Projektboards wurde auch direkt ersichtlich, dass wir zu viele Themen parallel bearbeiten, für die zeitgleich Entwickler und Administratoren benötigt werden. Durch die Kanban-Ausrichtung haben wir sowohl auf Entwicklungs- als auch auf Administrationsseite wip-Limits, damit nie zu viel parallel bearbeitet wird. Trotzdem konnte es bisher dazu kommen, dass mehrere Entwicklungsprojekte gestartet wurden, für die ein Administrator benötigt wurde – der dann nicht zeitnah zur Verfügung stand. Lange Wartezeiten in diesen Projekten entstanden, was immer zu Unzufriedenheit führt. 

Die ersten Schritte in Richtung einer Steuerung der beiden Teams durch das DevOps-Projektboard sind getan, den Weg wollen wir jetzt weiter verfolgen und ausbauen. Kanban Flight-Level 2 im Prinzip.

Zweiter Lösungsansatz

Ein weiteres positives Beispiel des DevOps-Gedanken ist eine bereichsübergreifende Gruppe zur Verbesserung der Skalierbarkeit unserer Systeme. Innerhalb der Entwicklung hatten wir schon mehrere solcher teamübergreifenden Gruppen (Reviewer, Architekten). Mit dem DevOps-Gedanken im Kopf haben wir das Thema Skalierbarkeit in die gleiche Richtung gebracht.

Es gibt jetzt eine Gruppe von zwei Administratoren, drei Entwicklern und mir, die die Skalierbarkeit bewerten und Ideen in beide Richtungen (Server / Software) geben, um unsere Systeme zu verbessern. Auch hier waren wir vorher eher in Silos unterwegs. Durch die gemeinsame Arbeit entstehen immer wieder neue Ideen. Skalierbarkeit kann immer durch Änderungen an der Software oder Änderung an der Serverinfrastruktur verbessert werden.

Fazit

Wir haben erste Schritte getan und bringen die Fachexperten für Software und Server besser zusammen als früher. Es sind noch einige Ideen nicht umgesetzt und wir wollen uns auch bezogen auf die DevOps-Ausrichtung in der nächsten Zeit kontinuierlich weiter verbessern.