Was DevOps heute wissen müssen

Der erste Teil unserer zweiteiligen Serie hat die 6 DASA-DevOps-Prinzipien dargestellt. Der zweite Teil geht nun auf das DASA-DevOps-Kompetenz-Framework ein, welches 12 Bereiche definiert, in denen die Mitarbeiter Qualifikationen haben müssen. Die Bereiche reichen von Soft-Skills wie Mut und Leadership über eher technische Aspekte wie Infrastruktur-Engineering und Continuous-Delivery zu eher klassischen Themen wie Business-Analyse und Testspezifikation.

DASA ist eine unabhängige und offene, von Mitgliedern getragene Vereinigung, die weltweit die Entwicklung von DevOps-Schulungen und -Zertifizierungen unterstützt. Mit den 6 DASA-DevOps-Prinzipien, die im ersten Teil unserer Serie dargestellt wurden, wird eine Basis für die organisationsweite Betrachtung gelegt. Es wird die Grundlage für die Ausrichtung und Entwicklung einer IT-Organisation in Richtung DevOps als Inbegriff einer hoch performanten IT gelegt. Der zweite Teil geht nun auf das DASA-DevOps Kompetenz-Framework ein, welches 12 Bereiche definiert, in denen die Mitarbeiter Qualifikationen haben müssen. Diese 12 Bereiche unterteilen sich in 4 Verhaltensbereiche und 8 Wissensbereiche. Analog zu der Tatsache, dass DevOps in einer IT-Organisation nicht allein durch Automation zu erreichen ist, muss ein moderner DevOps-Engineer neben Tool-Kompetenzen weitergehende Skills besitzen.

Das DASA-DevOps-Kompetenz-Framework sieht in den einzelnen Bereichen jeweils verschiedene Stufen vor. Damit kann ein persönlicher Entwicklungspfad für die Mitglieder in einem DevOps-Team aufgezeigt werden.

DASA-DevOps-Kompetenz-Framework[1]. (Abb. 1)

Das Ziel der Eingangsschulung DevOps-Fundamentals ist es, alle Teilnehmer auf den gleichen Wissensstand (Stufe 2) zu heben. Die Bereiche reichen von Soft-Skills wie Mut und Leadership über eher technische Aspekte wie Infrastruktur-Engineering und Continuous-Delivery zu eher klassischen Themen wie Business-Analyse und Testspezifikation.

Mut

Mut beschreibt im Zusammenhang von DevOps einerseits die Fähigkeit, im beruflichen Umfeld zu agieren, Dinge auszuprobieren und einfach voranzugehen sowie andererseits die Risiken zu kennen, sie in die Betrachtung einzubeziehen und zu minimieren. Innovative Unternehmen und Mitarbeiter sind auf dem Gebiet schon aktiv und haben ihre Erfahrungen gesammelt bzw. sammeln sie noch. Für die Early-Adaptors ist das jedoch an vielen Stellen noch unerforschtes Gebiet, so dass es mutige Mitarbeiter und Führungskräfte braucht, den Schritt in Richtung DevOps und damit einer radikalen Veränderung zu gehen. Konkret zeigt sich der Mut darin, die innere Überzeugung aktiv und überzeugend nach außen zu vertreten (Evangelisten). Es gilt, zu den vielen Themen im Rahmen von DevOps offene Diskussionen zu führen, den Mut zur Veränderung in das Unternehmen und die Köpfe der IT-Professionals zu bringen, proaktiv Inhalte von DevOps aufzunehmen, u.a. durch eine moderne Experimentierkultur, sowie viel Gruppen- und Individualreflexion und Coaching.

Team-Building

Die Teamentwicklung ist ein kritischer Erfolgsfaktor für den Erfolg von DevOps. In den Teams arbeiten die Experten mit den unterschiedlichen Hintergründen, Zielsetzungen und Ausbildungen. Diese müssen bei der Gestaltung ihrer gemeinsamen Arbeit unterstützt werden, um eine effektive und effiziente Zusammenarbeit gestalten zu können.

In vielen deutschen IT-Organisationen arbeiten die Experten seit langer Zeit ohne eine wirkliche Notwendigkeit, Teams zu bilden und mit diesen Teams dauerhaft Erfolge zu gestalten. (Die Arbeit in Projektteams ist sicher eine Ausnahme, wobei aus Sicht von DevOps Projektteams differenziert betrachtet werden. DevOps hat das Ziel, nachhaltig wirkende Teams zu formen, die neben der Entwicklung in Projektform auch langfristig für Kunden und die eigenen Projekte zusammenarbeiten).

Experten und Spezialisten waren das Ziel und diese werden häufig ungeachtet einer menschlichen Kompatibilität zur Zusammenarbeit gebracht. Das Ziel bei DevOps ist der Aufbau einer hochperformanten IT-Organisation. Dazu werden Teams benötigt, die die Vielfältigkeit und Unterschiedlichkeit der beteiligten Experten zu einer gemeinsamen Art der Zusammenarbeit vereint. Konkret heißt das bspw. ein gemeinsames Ziel zu schaffen, gegenseitige Rechenschaftspflichten zu definieren und Verständnis für unterschiedliche Standpunkte zu entwickeln.

DevOps-Leadership

In einer DevOps-orientierten Organisation bedeutet Führung nicht die Festlegung von Regeln und detaillierten Anweisungen, sondern die Vermittlung einer Vision. Damit werden Ziele und Nutzen einer Aufgabe beschrieben. Führung zu übernehmen ist dabei nicht nur Aufgabe von Führungskräften oder des Managements, sondern auch bzw. vielmehr von Mitgliedern der DevOps-Teams. Führung mit formeller und informeller Macht muss in einem passenden Gleichgewicht erfolgen. Dabei ist zu beachten, dass die Zusammenarbeit im Team ausgeglichen ist und das Team sich weiterentwickelt. Das übergeordnete Ziel, Erfüllung der Kundenanforderungen und Unterstützung der Geschäftsprozesse, darf nicht aus den Augen verloren werden. Deshalb wird das Thema Führung mit einer weiteren Kompetenz ergänzt: Feedback. Feedback sorgt für Transparenz, Fokussierung der Teams auf hochperformantes Agieren, Stakeholder-Management und Bewusstsein des Service-Lebenszyklus.

Kontinuierliche Verbesserung

Die heutige Geschäftswelt ist geprägt von kurzfristigen Veränderungszyklen. Damit wächst auch der Druck auf die IT, sich kontinuierlich anzupassen bzw. zu verbessern. Für DevOps-Mitarbeiter bedeutet dies, eine permanente Sensibilität für Verbesserungen zu entwickeln. Einerseits in der Fähigkeit, Probleme zu sehen, andererseits diese auch anzugehen und zu beseitigen. Insbesondere für den zweiten Anspruch wird spezielles Wissen zur strukturierten Problemlösung benötigt. DevOps greift dabei auf bekannte und im Markt etablierte Methoden zurück, wie z.B. Kaizen-Mindset (Root-Cause-Analysis), den DMAIC-Zyklus (Lean-Six-Sigma) etc.

Business-Value-Optimization

Geschäftswertoptimierung bedeutet die Verbesserung der Geschäftsprozesse durch Einsatz von IT unter Berücksichtigung betriebswirtschaftlicher Anforderungen. Für eine IT-Organisation setzt dies sehr gute Kenntnisse über das Geschäftsmodell, dessen Ziele und Kennzahlen voraus, um so innovative und preiswerte IT-Lösungen zur bestmöglichen Unterstützung anzubieten. Die Steuerung dieser Lösungen erfolgt über vereinbarte Abnahmekriterien, abgestimmte Business-Cases, regelmäßige Feedback-Loops, sowie die Anwendung von Service-Level-Management-Praktiken.

Business-Analysis

Business-Analysis bedeutet, dass das DevOps-Team ein klares Verständnis über die Geschäftsprozesse und die dazu gehörenden IT-Systeme erlangt. Nur so können Verbesserungsmaßnahmen vollständig im Hinblick auf Nutzen und Risiken bewertet werden. Das Team muss in der Lage sein, eine detaillierte Geschäftsanalyse durchzuführen, so dass die zu entwickelnde IT-Lösung hinsichtlich Funktionalität, Kosten und Vorlaufzeit optimal gestaltet werden kann. Dazu gehört die Bewertung von funktionalen und qualitativen Anforderungen, die Beobachtung der langfristigen Entwicklung der Geschäftsprozesse, Veränderungen am Markt, eine detaillierte Datenanalyse und die Flexibilität regelmäßige Anpassungen zu berücksichtigen.

Architektur und Design

Architektur und Design sorgen für die Übersetzung der Anforderungen aus geschäftlicher Sicht in eine optimale technische IT-Lösung. Kenntnisse sowie Erfahrungen sind von entscheidender Bedeutung für alle DevOps-Teams. Dabei gilt es, das IT-System ganzheitlich im Kontext mit der kompletten IT-Umgebung zu betrachten, um so den eigenen Verantwortungsbereich (Technologie-Stack) mit seinen Schnittstellen zu anderen IT-Systemen zu bestimmen und zu gestalten. Letztlich geht es um die Sicherstellung, dass neue Entwicklungen zu den aktuellen Systemen passen und dass die Vorgaben zum Service-Design in vollen Maße Anwendung finden.

Testspezifikation

Bei der Testspezifikation geht es darum, sicherzustellen, dass die Anforderungen der Benutzer des IT-Service vollständig erfüllt werden. Dazu zählen die Konzeption der Testphasen und das Design der einzelnen Testfälle. Methoden wie Test-Driven-Development (TDD) sollen dazu beitragen, vor der eigentlichen Softwareentwicklung die Test-Sequenzen und Inhalte zu definieren. Solche Methoden werden zunehmend angewendet, um sicherzustellen, dass die geforderte Funktionalität auch geliefert wird. Ein weiteres Ziel ist die Automatisierung dieser Aktivitäten, um schneller, preiswerter und wirkungsvoller testen zu können.

Programmierung

Programmieren ist die Kernkompetenz des DevOps-Teams, unabhängig davon ob es ein DevOps-Team ist, das eine Anwendung, eine Plattform oder ein vollständiges IT-System unterstützt. Künftig werden alle IT-Techniker lernen müssen, Softwarekomponenten zu pflegen, zu erstellen und zu modifizieren. Dies bedeutet eine wesentliche Änderung für den IT-Betrieb, insbesondere den Infrastrukturbetrieb, bei dem es bisher kaum notwendig war, im Tagesgeschäft Code-Änderungen durchzuführen. Viele Unternehmen, die mit der DevOps-Transformation beginnen, kämpfen mit dem Mangel an Software-Engineering-Fähigkeiten in ihren neu gegründeten Teams. Firmen, denen es nicht gelingt, diese Fähigkeiten auch im Betrieb aufzubauen, werden in einer zunehmend digitalen Zeit kaum überleben können.

Continuous-Delivery

Eine wichtige Aufgabe für DevOps-Teams ist Continuous-Delivery. Dies beschreibt eine automatisierte Vorgehensweise zur kontinuierlichen Softwareauslieferung. Dazu zählt eine gut konstruierte Pipeline, die den Weg von der Entwicklung bis zur Produktion erleichtert, aber was vielleicht noch wichtiger ist: das konzeptuelle Verständnis des gesamten Prozesses und wie dies technisch unterstützt wird. Continuous-Delivery erfordert eine genaue Kenntnis des Softwarelieferprozesses von der Entwicklung bis zur Produktion. Wichtige Teilaufgaben in diesem Zusammenhang sind z.B. automatisiertes Testen, Release- und Deployment-Management, Konfigurationsmanagement, Versionskontrolle, Cloud-Dienste, Container-Lösungen, Feature-Driven-Delivery etc.

Infrastructure-Engineering

Infrastrukturaufbau ist eine weitere Disziplin, die ein DevOps-Teams übernehmen muss. Dies umfasst standardisierte IT-Umgebungen, so dass diese automatisiert, konsistent und schnell gepflegt werden können. Besonders die DevOps-Teams, die Infrastrukturdienste bereitstellen, müssen diese Fähigkeiten haben und anwenden. Für anwendungsorientierte DevOps-Teams ist es wichtig, die zugrundeliegende Infrastrukturtechnologie gut zu verstehen, um sicherzustellen, dass ihre Anwendungen durch die Standard-Infrastrukturmodelle optimal unterstützt werden. Infrastructure-Engineering wir durch eine Vielzahl von technischen Aufgaben ermöglicht, wie z.B. technische Überwachung, Performance-Management (z.B. Load-Balancing etc.), das Management von Kapazitäten, Verfügbarkeit, Zuverlässigkeit, die Nutzung von Cloud- und Container-Services.

Security, Risk and Compliance

Die Themen Sicherheit, Risiken und Compliance treiben IT-Vorhaben von Beginn an. Besondere Aufmerksamkeit gilt der Verwaltung sicheren Software-Codes, dem Verständnis der Risiken bei der Infrastruktur und der Entwicklung neuer oder geänderter Funktionen unter Berücksichtigung regulativer und gesetzeskonformer Anforderungen zur bestmöglichen Unterstützung der Geschäftsprozesse. Sicherheits- und Risiko-Management sind auch bei der Planung der Servicekontinuität ausreichend zu untersuchen.

Fazit: 

Nachdem es im ersten Teil unserer zweiteiligen Serie um die 6 DASA-DevOps-Prinzipien ging, befasst sich der zweite Teil mit dem DASA-DevOps-Kompetenz-Framework, das 12 Bereiche beschreibt, in denen DevOps Qualifikationen haben müssen. DevOps müssen in der Lage sein, die wesentlichen Konzepte und Prinzipien von DevOps zu beschreiben, die betriebswirtschaftlichen Vorteile von DevOps und Continuous-Delivery zu erklären und die Konzepte der Test-, Infrastruktur-, Build- sowie Deployment-Automatisierung verstanden haben. Zudem müssen DevOps die Beziehung von DevOps zum Lean-Management und agilen Methoden beschreiben sowie die kritischen Erfolgsfaktoren in Bezug auf die Einführung von DevOps bewerten können.