Der unaufhaltsame technische Fortschritt und die allgemeinen Prozessverbesserungen der letzten zehn Jahre haben es IT-Organisationen ermöglicht, ihre Leistung und Schnelligkeit um ein Vielfaches zu steigern. [...]
Dennoch schränken aufgeblähte Prozesse, in Silos arbeitende Teams und zusammenhangslose Tools diese verbesserte Leistung ein und verhindern damit, dass das Unternehmen von der verbesserten Leistung profitiert. In Zeiten von immer komplexer und essentieller werdender IT bei gleichzeitiger Steigerung und Veränderung der KundInnen- und Businessanforderungen ist die kontinuierliche Lieferung und Bereitstellung von qualitativ hochwertigen und verlässlichen IT-Services unerlässlich.
Dabei trifft das Lager der Entwicklerinnen und Entwickler (Dev), die fortwährend Änderungen vorantreiben, auf das Lager der IT-Betreiberinnen und IT-Betreiber (Ops), deren Ziel es ist, die IT stabil zu gestalten; also Reaktionsfähigkeit versus Stabilität. Eine schöne Beschreibung, wie IT wahrgenommen wird, findet man in dem Buch „The Phoenix Project“: „Ich will, dass bei der IT alles läuft. Es ist wie mit der Toilette. Ich nutze sie und will mir keine Sorgen darum machen müssen, ob sie funktioniert. Ich will nicht, dass irgendetwas verstopft und die Toiletten die ganze Etage unter Wasser setzen.“ Natürlich hat IT-Operations auch ein bestimmtes Bild von „den Entwicklerinnen und Entwicklern“.
Diese in Silos arbeitenden Teams sollen näher zusammenrücken und nicht gegeneinander, sondern miteinander arbeiten. Hier liefert DevOps einen kulturellen und fachlichen Ansatz, um bei sich verkürzenden Entwicklungszeiten stabile IT-Services zu liefern. Der daraus resultierende bessere Workflow ermöglicht es dem Business, flexibel und schnell auf Änderungen zu reagieren, ohne dabei den Verlust von Qualität und Verlässlichkeit der IT-gestützten Business Services in Kauf nehmen zu müssen. Trotz des Namens erstreckt sich DevOps auch noch weit über Softwareentwicklung sowie IT-Operations hinaus. Im Allgemeinen schließt „Dev“ all diejenigen mit ein, die an der Entwicklung von Software-Produkten und -Services beteiligt sind (einschließlich GeschäftsvertreterInnen und LieferantInnen) und „Ops“ umfasst alle Personen, die an der Bereitstellung und dem Management dieser Produkte und Services beteiligt sind (einschließlich LieferantInnen).
Der Begriff „DevOps“ gelangte während einer Reihe von DevOps-Tagen, die 2009 in Belgien begannen, zur Bekanntheit. Seit damals hat sich diese erfahrungsbezogene Bewegung durch weltweite DevOps-Events und einer aktiven Online-Community immer weiter verbreitet.
Die Community widmet sich dem Studium von Praktiken und Technologien und dem Erfahrungsaustausch, um qualitativ hochwertige Software-Produkte und Services schnellstmöglich zu entwickeln und zu liefern.
DevOps-Wegbereiter sind:
* Agile und Lean Softwareentwicklungs-Methoden
* Agile und Lean Service-Management-Praktiken
* Virtualisierte und Cloud Infrastruktur von internen und externen AnbieterInnen
* Die Betrachtung von Infrastruktur als Code
* Data Center Automatisierung und Configuration Management Tools
* Überwachende und selbstheilende Technologien
In den letzten Jahren haben sowohl Dev als auch Ops Schritte unternommen, um diese Wegbereiter zur Leistungssteigerung zu verwenden. Leider wurde dabei nicht immer zusammengearbeitet. Das Ergebnis sind aufkommende Einschränkungen und der Rhythmus bzw. der Workflow ist beeinträchtigt. Konkurrierende Ziele verstärken das Problem noch. Dev wird angehalten, Changes und vor allem immer schnellere und mehr Changes zu generieren. Ops soll die Stabilität aufrecht halten und tut dies, indem sie unbeabsichtigt die Geschwindigkeit von Changes reduzieren. Dieses Patt führt zu einer dysfunktionalen Kultur und verfehlten Business-Zielen. DevOps erkennt die Notwendigkeit für kulturelle Verbesserung und gemeinsame Ziele, die auf die Business-Ziele abgestimmt sind.
DevOps ermöglicht Unternehmen einen Wettbewerbsvorteil durch schnellere Lieferung von besserer Software und damit nachhaltiger Innovation. Hierzu werden bei DevOps drei Wege beschrieben. Der erste Weg betont die Leistung des gesamten Systems im Gegensatz zu bestimmten Arbeits-Silos oder Abteilungen – diese kann dabei so groß wie ein ganzer Bereich (Entwicklung oder IT-Operations) oder so klein wie ein einzelne/r MitarbeiterIn (EntwicklerIn, SystemadministratorIn) sein. Im zweiten Weg geht es um das Schaffen von Feedbackschleifen. Das Ziel von fast jeder Prozessverbesserung ist es, Feedbackschleifen zu verkürzen und gleichzeitig zu verstärken, sodass nötige Korrekturen kontinuierlich erbracht werden können.
Der dritte Weg
Beim dritten Weg geht es darum, eine Kultur zu schaffen, die zwei Dinge unterstützt und fördert:
* Kontinuierliches Experimentieren, welches die Inkaufnahme von Risiken und das Lernen aus Erfolg und Scheitern erfordert.
* Ein Verständnis dafür, dass Wiederholung und Übung die Voraussetzung für Beherrschung sind.
* Tobias Beckmann ist Senior Consultant der Trusted Quality GmbH/ITSM Group
Be the first to comment