Durch eine zunehmend durchgängigere Unterstützung der Business-Prozesse bestimmt die IT heute den Herzschlag der meisten Unternehmen. Doch wie gestalten diese den IT-Betrieb, vor welchen Problemen stehen sie dabei und welche Lösungsmöglichkeiten gibt es?
IT-Betrieb ist in den meisten Unternehmen eine von der Entwicklung strikt getrennte Angelegenheit. Er wird meist ab einer gewissen Unternehmensgröße (ab ca. 150 Mitarbeiter) weiter unterteilt. Es steht dann auf der einen Seite der Anwendungsbetrieb, der sich um das Bereitstellen, Warten und Testen von Systemen rund um den Betrieb von Anwendungen kümmert. Gleichzeitig leistet er oftmals den 2nd- beziehungsweise 3rd-Level-Support und überarbeitet das Betriebshandbuch. Auf der anderen Seite steht das Infrastruktur-Team, das sich um Themen rund um Hardware, Netzwerke, Betriebssysteme, Zertifikate und mittlerweile auch um die Virtualisierungsschicht kümmert.
Schließlich übernehmen, nicht generell, aber gerade in größeren Firmen weitere Teams die Quality Assurance (QA) und IT-Sicherheit. Aus Betriebssicht sind, mit jeweils unterschiedlichem Fokus, die QA genauso wie die IT-Sicherheit für das Überwachen der Hardware und Systeme zuständig und informieren bei Problemen die jeweiligen Teams. Diese Strukturen kommen oft von der Ausrichtung der Unternehmen an ITIL und der darin definierten Ableitungen her. Die Abbildung 1 zeigt, wie die Service-Operationen nach ITIL strukturiert sind: “Service Operation beinhaltet die Erfüllung von Anwender-Anfragen und Erarbeitung von Problemlösungen ebenso wie die Erbringung von Betriebsaufgaben im laufenden Tagesgeschäft”.
Wird das Ganze weiter aufgebrochen, finden sich meist folgende Arbeitsfelder in den Unternehmen:
- Service Desk
- Incident Management
- Change Management
- Release Management
- Configuration Management
- Compliance
- Access Management
T-Betrieb in Unternehmen: Das Problem
Schon 1968 hat Melvin E. Conway formuliert: “Organisationen, die Systeme modellieren, […] sind auf Modelle festgelegt, welche die Kommunikationsstrukturen dieser Organisationen abbilden.” Längst ist bekannt, dass bei solch einer Struktur Probleme auch aufgrund komplexer Kommunikationsstrukturen vorgezeichnet sind. Die Abbildung 2 zeigt, dass die agile Bewegung geholfen hat, Feedback-Zyklen zwischen Business und Entwicklung einzurichten und zu stärken. Sie zeigt aber auch, dass das über den Lebenszyklus einer Anwendung nur eine kurze Teilstrecke ausmacht.
Für den IT-Betrieb bedeutet das, dass Feedback-Zyklen eingerichtet und gelebt werden müssen genauso wie zwischen der Entwicklung und dem Business. Zur Verdeutlichung sei ein gängiges Beispiel herangezogen: Werden über das Business neue Anforderungen an die Entwicklung herangetragen, leiten die Programmierer die Systemanforderungen an den Anwendungsbetrieb weiter. Derzeit findet in den meisten Unternehmen an dieser Stelle eine eindimensionale Kommunikation statt: von den Entwicklern in Richtung des IT-Betriebs. Dass der Anwendungsbetrieb bereits in den ersten Meetings, in denen die Systemanforderungen definiert werden, mitsprechen darf, passiert selten. Aber schon an diesem Punkt kann der IT-Betrieb seine Stärken ausspielen, da er das Fachwissen mitbringt, welche Vor- beziehungsweise Nachteile gegebenenfalls bei bestimmten Systemen und Techniken zu erwarten sind und wie diese am besten in eine Systemarchitektur passen.
Auch in der späteren Phase, der Entwicklung, schreiben die Programmierer oft ohne Absprache mit der QA die Texte für Log-Nachrichten. Manch ein QA-Mitarbeiter hat sich beim Lesen der Nachricht dann gefragt: “Was sagt denn diese Log-Nachricht aus?”. Auch aufgrund der fehlenden Feedback-Zyklen bekommt der Anwendungsbetrieb von den Entwicklern immer wieder zu hören, dass die für ein neues Projekt benötigten Systeme besser gestern als heute bereitstehen sollen. Der Anwendungsbetrieb wartet dabei möglicherweise selbst auf die Hardware beziehungsweise die VM, die das Infrastruktur-Team nicht liefern kann, da die Bestellung zu spät unterschrieben wurde. Aus Sicht des Managements stellt sich das Ganze dann so dar, dass mittlerweile Features in kurzen Zyklen ausreichend schnell entwickelt werden, diese aber als totes Kapital bis zum nächsten Deployment brachliegen.
Die soeben beschriebenen Mängel zeigen, dass in Zukunft Barrieren eingerissen, Arbeitsabläufe visualisiert und Aufgaben gemeinschaftlich angegangen werden müssen. Nur so ist es möglich, der Geschwindigkeit des Business folgen zu können und gegebenenfalls sogar den lang gehegten Wunsch zu erfüllen, als IT der Treiber des Unternehmens zu werden und nicht wie bisher der Getriebene.
Die Abbildung zeigt ein weiteres Problem an den aus Sicht des Managements klar strukturierten Prozessen: Aufgrund der sich oft ändernden und unbekannten Anforderungen und durch den Einsatz neuer weniger bekannter Techniken wird die Arbeit, die in den IT-Bereichen anfällt, eher zum Chaos, als vorhersagbar und zuverlässig zu sein. Das Ziel eines modern aufgestellten Unternehmens muss es also sein, die wenig vorhersagbare Arbeit wieder in geordnete Bahnen zu lenken.
IT-Betrieb in Unternehmen: morgen
Um ausgehend von den beschriebenen Problemen einen modernen IT-Betrieb aufzubauen, stellt sich zunächst die Frage: Hilft es an dieser Stelle, Continuous Delivery und einige neue Tools zum Bereitstellen von Infrastruktur und Systemen einzuführen? Wohl eher nicht, wenn die Feedback-Zyklen vollständig über den gesamten Anwendungslebenszyklus laufen sollen (s. Abb. 2). Es gilt jetzt, zunächst die vorhandenen Prozesse und anfallenden Arbeiten zu visualisieren und im Folgenden besser zu strukturieren.
Ein gutes Mittel bieten hier Kanban-Boards. Sie ermöglichen es, die Arbeitsschritte sowie offene (WIP, work in progress) und erledigte Arbeiten aufzuzeigen. Die Fokussierung auf die Teams und die Umkehr der Arbeitsweise weg vom Push- hin zum Pull-Prinzip entlasten die Mitarbeiter, und Selbstorganisation und Mitabeitermotivation steigen. Diese ersten Erfolge helfen dabei, die bis dahin unterschiedlichen Teams für weitere gemeinsame Arbeit zu begeistern. Das gilt auch für das Management, wenn sich von Beginn an beispielsweise die Dauer der Arbeitsschritte (Durchlaufzeit) festhalten und so die Verbesserungen aufzeigen lassen. Wichtig ist dabei, dass die Verbesserungen nicht zulasten der Mitarbeiter erfolgen. Das kann durch dass Einhalten der Kanban-Prinzipien erreicht werden. Diese sind Visualisierung, Limitierung des WIP, Pull- statt Push-Prinzip und kontinuierliche Verbesserung. Wichtig ist weiterhin, dass die Arbeit fokussiert vonstatten geht. Denn den IT-Mitarbeiter kostet es viel Zeit, sich ständig in neue Arbeit zu hineinzudenken.
Nachdem sich hoffentlich erste Erfolge eingestellt haben, wird es Zeit, sich dem nächsten Problemfeld zu widmen. Teilweise neidisch schauen die Kollegen aus dem Betrieb zu den Entwicklern, die durch beispielsweise Scrum eine deutlich bessere und effizientere Kommunikation mit den Fachbereichen erreicht haben. Damit einher gehen kürzere Releasezyklen mit neuen Features. Selbst hier ist nicht alles Gold, was glänzt, und auch durch fehlerhaftes Umsetzen von Scrum bekommen Entwickler oft zu viele Features aufgedrängt und zu wenig Zeit für technische Schulden. Helfen kann hier beispielsweise eine gemeinsam erstellte “Definition of Done”, eine Liste der Dinge, die abgearbeitet sein müssen, bevor eine User Story geschlossen werden kann.
Soll nun die Kommunikation zwischen Anwendungsentwicklern und Betrieb verbessert werden, kann man Scrum-Teams bilden, in denen funktionsübergreifend Mitglieder aus Betrieb, Entwicklung, Business und QA zusammenarbeiten und für den gesamten Lebenszyklus bestimmter Services oder Features verantwortlich sind. Amazons CTO Werner Vogels hat dazu bereits im Mai 2006 im Magazin “Association for Computing Machinery’s Queue” geschrieben:
“The traditional model is that you take your software to the wall that separates development and operations, and throw it over and then forget about it. Not at Amazon. You build it, you run it. This brings developers into contact with the day-to-day operation of their software. It also brings them into day-to-day contact with the customer. This customer feedback loop is essential for improving the quality of the service.”
Es hat sich jedoch gezeigt, dass solche funktionsübergreifenden Scrum-Teams gerade am Anfang einer Transformation der täglichen Arbeit des IT-Betriebs wenig gerecht werden. Das liegt vor allem daran, dass der Anteil von ungeplanter Arbeit im IT-Betrieb deutlich höher ist als der von geplanter. Nun gibt es verschiedene Wege zum Erfolg, aber wieder hilft es, zunächst den Prozentsatz von geplanter und ungeplanter Arbeit im IT-Betrieb überhaupt sichtbar zu machen (etwa über Kanban-Boards). Wie im Folgenden auf das neu erworbene Wissen reagiert wird, ist noch einmal ein ganz anderes Thema.
Die Menge der ungeplanten Arbeit im IT-Betrieb hat dazu geführt, dass neue Ausprägungen des Scrum-Frameworks entwickelt wurden, die es ermöglichen, die Arbeit des IT-Betriebs besser abzudecken. Scrum-ban mischt beispielsweise Ideen von Scrum und Kanban, um der Arbeit des IT-Betriebs gerechter zu werden. Die generellen Ziele von Scrum-ban sind:
- mit Iterationen wie in Scrum starten
- eine Spalte für wichtige/dringende Arbeiten einführen
- Arbeit nicht frühzeitig Teammitgliedern zuweisen
- den WIP limitieren
- mit bedachten Schritten zum Pull-Prinzip
- immer den Arbeitsfluss beachten
- Vorbereitung- und Durchlaufzeit sind wichtiger als Burndown Charts
- Die durchschnittliche Durchlaufzeit zu kennen ist wichtiger als die genaue Schätzung jeder einzelnen Aufgabe
Um mit den Scrum-Teams der Entwickler effektiv zusammenarbeiten zu können, lässt sich einer weiteren Methode bedienen: des “scrum of scrum”-Meetings. Hier wird aus jedem Team ein sogenannter Team-Botschafter entsendet. Diese Botschafter treffen sich regelmäßig und berichten aus ihren Teilprojekten. Im günstigsten Fall stellt sich relativ schnell ein gemeinsames Verantwortungsgefühl für die Anwendung ein, und die Mitarbeiter fangen an, sich über ihre Grenzen hinweg mit den nun gemeinsamen Problemen zu beschäftigen.
Die entstehende Kommunikation sollte dazu genutzt werden, die über den Softwarelebenszyklus entstandenen technische Schulden nach und nach abzubauen. Gegebenenfalls wird nun das erste Mal gemeinsam darüber gesprochen, dass ein bestimmtes Modul beim Deployment immer wieder Ärger macht, woraufhin die Entwickler anfangen, ihre Tests auszuweiten. Im Folgenden lässt sich jetzt vereinbaren, dass die Teams zusammen das Überwachen und den Support für die Anwendung gewährleisten. Das führt im Umkehrschluss schnell zu bereinigten Log-Nachrichten genau so wie zu generell stabilerer Software.
Für ein erfolgreiches Umsetzen der oben angerissenen Ideen ist es wichtig, dass das Management Verantwortung abgibt und den Teams Vertrauen entgegenbringt. Gerade am Anfang, beim Aufbau der neuen Team-Strukturen, lassen sich durch zu wenig Vertrauen und Freiraum viele gute Vorsätze zerstören. Auch innerhalb der Teams ist es wichtig, dass ein reges Mit- und kein Gegeneinander gelebt wird. Letzten Endes soll damit auch der in vielen Firmen existierende “Hidden Champion” in regulierte Bahnen gebracht werden. Er ist ein Mitarbeiter, der häufig zum Beispiel bei einem fehlerhaften Deployment gerufen wird, dann mit Root-Rechten quer durch die Systeme marschiert und am Ende auf wundersame Weise alles wieder zum Laufen bekommt. Was erst einmal nach großer Kunst aussieht, entpuppt sich bei genauerer Betrachtung als hausgemacht. Der Hidden Champion wird oft so viel in Anspruch genommen, dass seine Lösungen oft die späteren Probleme erst verursachen, die wiederum nur er selbst lösen kann. Wird er mit den neuen Team-Strukturen gebändigt und agiert in klaren Strukturen, wird er es sein, der neue Trends und Techniken vorantreibt, für die er bis dahin keine Zeit gefunden hat.
Ausblick
Auch die neu strukturierten Teams werden die klassischen Phasen (Forming, Storming, Norming und Performing) durchlaufen. Stellt sich nach einer gewissen Zeit die Performing-Phase ein, lässt sich die folgende gegensätzliche Ansicht von Entwicklung und Betrieb angehen. Aus Sicht des Betriebs erscheinen kurze Sprints und somit kurze Releasezyklen gegenläufig zu langlaufenden stabilen Systemen. Die Angst vor Nachtschichten und Systemausfällen bei regelmäßigen Releases muss genommen werden. An dieser Stelle können nun Tools tatsächlich weiterhelfen. Zunächst sollte damit gestartet werden, seine Infrastruktur nicht nur händisch aufzusetzen, sondern als Code zu beschreiben und genau wie Anwendungscode zu behandeln. Das Nutzen von Versionsverwaltung gehört dann ebenso zum Standard wie das Schreiben von Tests für den Infrastruktur-Code.
Wenn sowohl die Anwendung als auch die Infrastruktur als ausführbarer Code vorliegen, herrscht eine vollkommene Transparenz der Änderungen. Diese sind durch die Versionierung nun reversibel, was die Angst vor ihnen nimmt. Zudem lässt sich somit schneller und häufiger Anwendung mit Infrastruktur vermählen, sodass es nicht erst im letzten Schritt des Deployments zu unerwarteten Problemen kommt. In einem weiteren Schritt ist dafür zu sorgen, dass etwa die Anwendungskonfiguration an einem zentralen Ort für die verschiedenen Stages liegt. Wurden auch hier die technischen Schulden reduziert, lässt sich damit beginnen, eine Deployment-Pipeline aufzubauen. Dabei können durch Qualitätsmetriken weitere Mängel zutage treten (Testabdeckung etc.), die nach und nach abzubauen sind. Jedoch wird am Ende das Ziel erreicht, Änderungen am Code sowohl der Infrastruktur als auch des Anwendungscodes führen zu einem Deployment in die Produktion.
Fazit
Der Anwendungslebenszyklus hört nicht beim Bauen der Software durch die Entwickler auf, sondern erst beim Betrieb der Anwendung auf geeigneter Infrastruktur. Deshalb sollte der IT-Betrieb
frühzeitig in Projekte involviert werden und seine Expertise genau auf diesem Gebiet einbringen. Der Artikel möchte anregen, über mögliche Veränderungen nachzudenken und neue Wege zu beschreiten, um den IT-Betrieb zu entlasten und neue Feedback-Schleifen so einzurichten, dass eine durchgängige Feedback-Kultur vom Kunden bis zum IT-Betrieb hergestellt wird.
Quelle: http://www.heise.de/developer/artikel/Operations-heute-und-morgen-Teil-1-Das-moderne-IT-Unternehmen-2624295.html