Klein beginnen

Wichtig bei der Einführung einer agilen Zusammenarbeit sind realistische Ziele und die passenden Services. Es macht keinen Sinn, mit dem totkonfigurierten Unternehmens-ERP oder der überalterten Gehaltsabrechnung zu beginnen. Wichtig ist die Wahl eines Service, der Spass macht und dessen Reformation im Sinne von Devops kurzfristigen Erfolg verspricht. Webanwendungen sind dafür in Regel gut geeignet, da sie meist klassische Komponenten wie Datenbank, Web- und Applikationsserver sowie die ein oder andere Infrastrukturkomponente benötigen. Darüber hinaus ist der Erfolg einfach und klar für Tools, aber eben auch für die beteiligten Personen messbar. Die Bereitstellung einer Java-Applikation macht im Team mit Sicherheit mehr Spass und stärkt das gegenseitige Verständnis für Fehler und Problemstellungen auf beiden Seiten. Hinzu kommt das sowohl Entwickler als auch Administrator die Arbeitsumgebung des anderen kennenlernen.

Der Einstieg in ein entsprechendes Pilotprojekt kann durchaus in einem kleinen, gleichmässig verteiltem Team aus zwei oder vier Personen erfolgen. Dabei ist es anfangs sinnvoll, in einer offenen Runde die Probleme der Vergangenheit offen auf den Tisch zu legen. Fragen wie "Warum dauert das bei Euch immer so lange" bergen zwar durchaus Konfliktpotenzial, richten aber auch schnell den Blick auf die andere Seite. Es ist wichtig, nicht um den heißen Brei herumzureden, sondern direkt und durchaus subjektiv auf die erfahrenen Missstände einzugehen. Wenn die offene Diskussion in Streit und nicht konstruktive Betrachtung der bekannten Probleme mündet, sind oft nicht die richtigen Personen am Start.

Die gemeinsame Optimierung der bisherigen Schwachstellen verbindet Development und Operations meist schnell und zeigt auch die Schnittstellen zwischen den Bereichen klarer auf. Darauf aufbauend lassen sich dann die notwendigen Schritte zur Verbesserung entwickeln und umsetzen.

Kommt zu diesem Zeitpunkt bereits ein Tool zum Einsatz, das dabei hilft, ein gemeinsames Ziel zu erreichen, können Development und Operations stark voneinander profitieren und die iterative Ausführung zeigt schnell, ob man tatsächlich den richtigen Pfad eingeschlagen hat.

Gerade wenn es nicht gleich beim ersten Mal klappt, ist etwas Geduld, Respekt und Einfühlungsvermögen notwendig, um die beteiligten Personen für einen erneuten Versuch zu motivieren. Der Erfolg wird sich mit der Zeit einstellen und mehr und mehr Mitarbeiter mit dem Devops-Virus infizieren. Bei aller Agilität ist es trotzdem wichtig, die Arbeit gemeinsam zu besprechen und die Methoden zu optimieren, um die Bildung eines neuen Silos für Service X zu verhindern.

Der Einsatz von Tools

Der Erfolg oder Misserfolg von Devops hängt nicht an einem Tool, jedoch gibt es durchaus Parallelen zwischen agilen Arbeitsmethoden und damit verbundenen Werkzeugen. Lösungen wie Puppet [4] , Chef [5] und CFEngine [6] als Urväter der Konfigurations-Management-Welle haben das Thema in den letzten Jahren stark beschleunigt. Systeme und Applikationen automatisiert bereitzustellen, erfordert automatische Provisionierung eines IT-Services, erfordert die Zusammenarbeit zwischen Development und Operations in hohem Maß und kann nur bei absoluter Transparenz gelingen.

Hinzukommt, dass die gängigen Werkzeuge auch Entwicklungs-Know-how erfordern, das über Bash- und Perl-Skripte hinausgeht. Werden Änderungen im Puppet-Modul oder Manifest dann noch in Git festgehalten, um die Nachvollziehbarkeit sicherzustellen oder den Rollback zu ermöglichen, so ist der Admin dem Developer schon einen großen Schritt nähergekommen.

Analog zur fachlichen und organisatorischen Umsetzung sind auch bei der Einführung eines Konfigurationsmanagements kleine Schritte zu empfehlen.

Wer von individuell installierten und administrierten Servern kommt, sollte nicht sofort das ganze Rechenzentrum in Puppet beschreiben wollen. Ist man über die wichtigen Systemparameter hinweg, kann man einzelne Services beschreiben und automatisiert ausrollen. Die Verwendung vieler spezialisierter Module gelingt deutlich einfacher als die Implementierung des allmächtigen Firmenmoduls, das alles automatisiert erledigt und am Abend noch das Licht ausschaltet. Hier ist weniger oft mehr.

Der Einsatz eines Versionsmanagements ist in der Administration meist unüblich, sorgt aber gerade im Zusammenspiel mit einem Konfigurationsmanagement für hohe Transparenz und ermöglicht die schnelle Fehlerbeseitigung. Bei Fehlern muss nicht lange in Konfigurationsfiles gesucht werden, sondern ein Blick in die Änderungshistorie offenbart den Fehler schnell. Gleichzeitig ist es von großem Vorteil, den Schuldigen auszumachen und offen damit umzugehen. Die Unmöglichkeit, Fehlern zu verschleiern, führt mittelfristig zu einer höheren Motivation und Bindung an das Produkt.