Discover Performance

Der Autor und DevOps-Experte Gene Kim spricht über die Entwicklung von DevOps und sein neues Buch "The DevOps Cookbook".

Gene Kim, der Gründer und ehemalige CTO von Tripwire, hat mit führenden Internetunternehmen zusammengearbeitet, um die Implementierung und die Effizienz ihrer IT-Prozesse zu verbessern. Von seinem Buch "Visible Ops Handbook" wurden bisher mehr als 200.000 Exemplare verkauft. Als einer der Autoren des Buchs "The DevOps Cookbook", das im Juli 2012 von ITRevolution herausgegeben wurde, hat Kim mit uns über seine Sicht der DevOps-Bewegung gesprochen.

Frage: Welche Herausforderung löst DevOps und wie können IT-Verantwortliche dies unterstützen?
Sehr treffend hat das Christian Verstraete, HP Chief Technologist for Cloud Strategy ausgedrückt: „Früher sind Probleme aufgetreten, wenn Ingenieure Produkte entwickelt haben, ohne die Belange der Montage und Fertigung zu berücksichtigen. Heute ist die Fertigung bereits beim Design ein zentraler Aspekt und das Fertigungsteam wird am gesamten Designprozess beteiligt, um sicherzustellen, dass das Produkt schnell und effizient hergestellt und montiert werden kann. Im Bereich der Softwareentwicklung sind wir in exakt derselben Situation.“

Jetzt ist es wichtiger denn je, dass Entwickler die IT-Betriebsumgebung kennen und die Mitarbeiter des IT-Betriebs über die Entwicklungsprozesse Bescheid wissen. Die Teams sollten sich bei der Lösung ihrer Probleme unterstützen. Noch wichtiger ist jedoch, dass beide Teams als ein Team zusammenarbeiten, damit die globalen Ziele des Unternehmens erreicht werden können.

Kurzum, wir müssen das Know-how und die Ressourcen des IT-Betriebs in die Entwicklung integrieren und umgekehrt.

Frage: Über DevOps wird viel diskutiert, aber das Konzept ist schwer zu greifen. Gibt es eine genaue, akzeptierte Definition von DevOps-Verfahren?
Was alle DevOps-Praktiker vereint, ist ihr unverrückbarer und gemeinsamer Glaube daran, dass die Entwicklung und der IT-Betrieb sowie alle anderen an der IT-Wertschöpfungskette Beteiligten auf andere Weise zusammenarbeiten müssen, damit neue Funktionen schnell integriert und gleichzeitig stabile, zuverlässige und sichere IT-Services bereitgestellt werden können.

DevOps ist jedoch heute mehr eine kulturelle und philosophische Bewegung und noch keine standardisierte Definition von Verfahren und Prozessen wie beispielsweise CMM-I, ITIL etc.

Der Idealfall wäre ein Standard an DevOps-Prozessen, -Verfahren, -Prozeduren und -Vorlagen, der genau beschreibt, inwiefern die Entwicklung und der IT-Betrieb anders vorgehen müssten, um ihre tägliche Arbeit zu verbessern. Das Ziel des Projekts "DevOps Cookbook" ist die Katalogisierung der Merkmale, die „leistungsfähigen DevOps-Organisationen“ gemeinsam sind.

Wir möchten auf diese Weise Anleitungen bereitstellen, mit deren Hilfe andere Organisationen in der Lage sind, ebenso gute Ergebnisse zu erzielen und DevOps-Initiativen erfolgreicher durchzuführen.

Frage: Warum geht es bei DevOps hauptsächlich um die Entwicklung und den IT-Betrieb?
Ich denke, der Hauptgrund ist, dass zwischen der Entwicklung und dem IT-Betrieb die meisten Konflikte auftreten.

Zunächst werden die Anforderungen von den Geschäftsbereichen definiert. Anschließend werden die Produkte entwickelt und dann in den IT-Betrieb überführt. Dort stellen sie dem Kunden einen Mehrwert in Form eines Service bereit.

Oftmals sind die Ziele der Entwicklung und des IT-Betriebs konträr. Die Entwicklung implementiert Änderungen, um auf geänderte Geschäftsanforderungen reagieren zu können, während der IT-Betrieb Änderungen weitgehend vermeiden möchte, um die Stabilität der Produktionsumgebung nicht zu gefährden.

DevOps löst diesen Konflikt durch ein übergeordnetes Team auf, das neben Entwicklung und IT-Betrieb auch Produktmanagement, Projektmanagement, QA, Packaging, Release-Management und Sicherheit umfasst.

In Zusammenarbeit erreicht dieses übergeordnete Team sowohl eine schnelle Integration neuer Funktionen als auch Stabilität.

Frage: Inwiefern kann der IT-Betrieb die Entwicklung unterstützen?
Bei jeder Methodologie zur Prozessverbesserung ist „Qualität an der Quelle“ eine zentrale Anforderung. Folglich ist es sehr wichtig, dass erfahrene Mitarbeiter des IT-Betriebs bei der Definition der nicht funktionalen Anforderungen sowohl für den Code als auch für die Ausführungsumgebung mitwirken. Vereinfacht ausgedrückt sind die nicht funktionalen Anforderungen alle Anforderungen, die keine Funktionen für Endbenutzer darstellen, z. B. Anforderungen in Bezug auf Skalierbarkeit, Management, Widerstandsfähigkeit, Portierbarkeit usw. Auf diese Weise können Anwendungen entwickelt werden, die sich leicht in der Produktionsumgebung implementieren und managen lassen – im Gegensatz zu „Throw over the wall“-Anwendungen.

Die sich ergebenden Verbesserungen können sehr umfangreich sein, z. B. wenn der IT-Betrieb bei der Definition der Anforderungen und Architektur für Kapazitäts- und Produktionsunterstützung hilft. Oder auch weniger umfangreich, wenn z. B. der IT-Betrieb die Speicherposition für die Konfigurationseinstellungen spezifiziert, die Anforderungen für Implementierung und Paketierung entwickelt usw. Doch sie alle machen einen Unterschied.

Der IT-Betrieb kann auch auf ein anderes Problem einwirken, das bei vielen Projekten auftritt: Die gesamte im Projektplan zur Verfügung stehende Zeit wird häufig für die Entwicklung verwendet und es bleibt keine Zeit für Performancetests, die Definition der passenden Bereitstellungsumgebung etc.

Wir versuchen, dem durch andere Vorgaben für Agile Sprints entgegenzuwirken. Am Ende jedes Sprint-Intervalls muss das Team nicht nur lieferbaren Code bereitstellen, sondern auch eine Arbeitsumgebung, in der der Code ausgeführt wird. Diese wird im Idealfall durch einen automatisierten Prozess erstellt.

Auf diese Weise verfügen alle Entwickler über konsistente Umgebungen und es gibt einen automatisierten Prozess für die Erstellung der Produktionsumgebungen und der Vorproduktionsumgebungen.

Die Vorteile sind enorm, da in den frühen Stadien des Projekts standardisierte Umgebungen und prognostizierbare Implementierungen zur Verfügung stehen, sodass über die gesamte Lebensdauer des Projekts und der Anwendung hinweg viel weniger Nacharbeit erforderlich ist.

Frage: Inwiefern kann die Entwicklung den IT-Betrieb unterstützen?
Ein weiteres Ziel bei fast jeder Initiative zur Prozessverbesserung ist die Beschleunigung und Ausweitung von Feedbackschleifen, sodass notwendige Korrekturen kontinuierlich vorgenommen werden können. Eines meiner Lieblingsbeispiele aus dem Bereich der IT-Servicebereitstellung stammt von Patrick Lightbody, dem Gründer von browsermob.com. Er sagte: „Wir haben herausgefunden, dass Defects am schnellsten behoben werden, wenn wir die Entwickler mitten in der Nacht alarmieren.“

Wenn wir die Entwicklung näher an den IT-Service und den Kunden heranbringen (z. B. als Level 3-Eskalation), erstellen wir eine gesunde Feedbackschleife zwischen IT-Betrieb und Entwicklung. Als Folge werden Probleme schneller und durch ein funktionsübergreifendes Team behoben. Dies führt zu wesentlich besseren Ergebnissen als die isolierte Arbeit beider Teams, bei der Tickets und Probleme so lange hin- und hergeschoben werden, dass das Management eingreifen muss.

Frage: Wann wird DevOps sich zum Standard entwickelt haben?
Da Unternehmen und deren Geschäftserfolg mehr und mehr von der IT und damit von der Entwicklung und dem IT-Betrieb abhängen, ist es essenziell, dass diese Teams effektiv zusammenarbeiten.

Ich bin der Meinung, dass die meisten "leistungsfähigen DevOps-Organisationen" Eigenschaften aufweisen, die sich ergeben, wenn Verfahren wie Lean, Theory of Constraints usw. auf die IT angewendet werden.

In den 1980er Jahren waren Unternehmen, die keine Verbesserungsverfahren in ihre Fertigung integriert haben, am Markt weniger erfolgreich. Ich glaube, dass Unternehmen, die keine DevOps-Verfahren übernehmen, in fünf Jahren auffallen werden, weil sie weniger wettbewerbsfähig sein werden - insbesondere im Zusammenhang mit der weiteren Verbreitung von Cloud Computing und PaaS.

Weitere Informationen zu DevOps finden Sie im Buch "DevOps Cookbook".