Schriftliche DevOps-Schulung

Was ist DevOps?

DevOps ist ein Prozess zur Entwicklung, Bereitstellung und zum Betrieb von Software. So einfach das klingt, unterschätzen Sie nicht, wie wichtig es ist, DevOps wirklich zu verstehen. In Buchhandlungen und im Internet finden Sie viele Definitionen, die eigenen Interessen dienen oder bestenfalls lückenhaft und verwirrend sind.

Manche kommerziell motivierten Definitionen knüpfen DevOps an bestimmte Build- und Bereitstellungswerkzeuge oder Cloud-Infrastrukturplattformen. Diese können Ihnen zwar helfen, mit DevOps Ihre IT- und Unternehmensziele zu erreichen. Doch die Einführung eines weiteren Werkzeugs, über das Sie meist wenig Kontrolle haben, weil Sie es nicht selbst entwickelt haben, oder die Migration Ihrer Anwendungen in die Cloud reichen nicht aus, um zu verkünden, dass Ihre Organisation nun mit DevOps liefert. Darüber würden, wie ein alter, wenig bekannter Spruch sagt, selbst die Raben lachen.

Eine weitere irreführende, aber etwas bessere Definition sieht DevOps als Schnittmenge von Tätigkeiten und Personen in der IT, die Softwareentwicklung, Softwaretests und Produktionsbetrieb zusammenbringt. Wenn Sie das Buch bis zum Ende gelesen haben, werden Sie merken, wie trocken diese Definition ist.

DevOps lässt sich am besten anhand iterativer agiler Entwicklungs- und Prozessverbesserungsmethoden beschreiben, etwa Scrum, Lean, ITIL, IDEAL (Initiate, Define, Establish, Act and Learn) und Six Sigma DMAIC (Define, Measure, Analyze, Improve and Control).

Agiles Scrum, Lean, ITIL, IDEAL und Six Sigma DMAIC können DevOps wirksam unterstützen. DevOps ist jedoch keine verbesserte Kombination dieser Methoden und Techniken. Der Grund ist einfach: Abgesehen von agilem Scrum wurde keine dieser Methoden speziell für die Anforderungen und Probleme der Softwarebranche eingeführt.

Viele DevOps-Praktiken und -Grundsätze stammen aus der Lean-Bewegung. Sie wurden für Entwicklung, Bereitstellung und Betrieb von Software angepasst, erprobt, validiert und verfeinert. DevOps hat auch viele Techniken und Denkweisen aus der Continuous-Delivery-Bewegung, der Toyota-Verbesserungskata, der Theory of Constraints, dem Agilen Manifest und der agilen Infrastruktur übernommen und angepasst.

Lean-Bewegung:

Die Lean-Bewegung lässt sich in sieben Grundsätzen zusammenfassen:

1. Sie betrachten das Ganze und schaffen mit systemischem Denken Kundennutzen.
2. Sie bauen Qualität von Anfang an ein, schaffen einen Fluss und arbeiten nach dem Pull-Prinzip statt nach dem Push-Prinzip.
3. Sie liefern so schnell wie möglich. Mit kurzen Durchlaufzeiten werden Rohstoffe zu fertigen Produkten oder, auf Software bezogen, Ideen zu nutzbaren Funktionen in Produktionssystemen.
4. Sie fördern das Lernen und setzen auf wissenschaftliches Denken.
5. Sie geben Ihrem Team Handlungsspielraum, führen mit Bescheidenheit und respektieren jeden Einzelnen.
6. Sie beseitigen Verschwendung bei Werkzeugen, Systemen und vor allem bei der Zeit, die Sie möglicherweise mit unproduktiven Tätigkeiten verbringen.
7. Sie entscheiden so spät wie möglich, also genau dann, wenn die Entscheidung nötig ist.

Continuous-Delivery-Bewegung:

Sie ermöglichen Continuous Delivery über die Deployment-Pipeline. Diese erfüllt drei wichtige Aufgaben: Transparenz, Feedback und Continuous Deployment.

• Transparenz – Sie machen alle Aspekte des Bereitstellungssystems, einschließlich Build, Deployment, Tests und Release, für alle Mitglieder Ihres Teams und anderer Teams sichtbar. Dadurch fördern Sie die Zusammenarbeit und schaffen Transparenz für Ihre Kunden und Stakeholder.
• Feedback – Sie und Ihr Team erfahren von Problemen, sobald sie auftreten. So können Sie sie schnell beheben, bevor Sie auf einem bereits eingestürzten Fundament weiterbauen.
• Continuous Deployment – Sie stellen jede Softwareversion in jeder Umgebung bereit und geben sie dort frei, einschließlich Test und Produktion. Der Prozess läuft vollständig automatisiert ab.

Toyota-Verbesserungskata:

Mit der Toyota-Verbesserungskata arbeiten Sie routinemäßig, kreativ und zielgerichtet auf einen neuen Zustand hin. Das Modell besteht aus vier Schritten:

1. Sie orientieren sich an einer übergeordneten Vision oder an einer besseren Richtung …
2. Sie erfassen den aktuellen Zustand.
3. Dann legen Sie den nächsten Zielzustand fest.
4. Schließlich arbeiten Sie kontinuierlich und schrittweise auf den Zielzustand hin. Auf dem Weg entdecken Sie Hindernisse und beseitigen sie.

Andere Verbesserungsmethoden versuchen, den Weg vorherzusagen, und konzentrieren sich auf die Umsetzung. Mit der Toyota-Verbesserungskata lernen Sie aus Erkenntnissen, die sich unterwegs ergeben, und bauen darauf auf. Sie und Ihre Teams lernen beim Streben nach einem Zielzustand und passen Ihr Vorgehen an das Gelernte an.

Theory of Constraints (Engpasstheorie):

In jeder Organisation, die Software bereitstellt, gibt es einen anhaltenden Konflikt zwischen IT und Geschäftsbereichen. Schnell auf geschäftliche Anforderungen zu reagieren und zugleich stabile, vorhersehbare Produktionsumgebungen zu gewährleisten, erfordert ständiges Abwägen. Wie Sie wissen, ist kein Produktionsrelease risikofrei. In einem komplexen System wie Ihrem können Sie kaum schnell genug sein, wenn das Risiko gering bleiben soll. Und wenn Sie Code schnell in Produktion bringen wollen, können Sie kein geringes Risiko gewährleisten.

Sie begegnen diesem Konflikt, indem Sie

• Ihre IT-Organisation in viele kleine, autonome, unabhängige und eigenständig arbeitsfähige Teams unterteilen, die eng zusammenarbeiten. Betrachten Sie Teams als „intelligente Einheiten“ mit einem Auftrag.
• die Größe der Arbeitspakete und damit den Umfang der laufenden Arbeit je Team verringern.
• die Durchlaufzeit verringern, also die Zeit, die aus Ideen und Anforderungen nutzbare Funktionen in Produktionssystemen macht.
• schnellere, verlässliche und kontinuierliche Feedbackschleifen aufbauen, um die Deployment-Bereitschaft sicherzustellen.

Agiles Manifest:

Mit DevOps orientieren Sie sich an den Grundwerten des Agilen Manifests:

• Individuen und Interaktionen sind Ihnen wichtiger als Prozesse und Werkzeuge.
• Funktionierende Software ist Ihnen wichtiger als umfassende Dokumentation.
• Zusammenarbeit mit Kunden ist Ihnen wichtiger als Vertragsbedingungen und Vertragsverhandlungen.
• Reagieren auf Veränderung ist Ihnen wichtiger als das Befolgen eines Plans.

Agile Infrastruktur:

Große und kleine Organisationen, vermutlich auch Ihre, nutzen hybride Cloud-Infrastrukturen mit öffentlichen und privaten Clouds und dedizierten Servern. So profitieren Sie von der Sicherheit der Colocation und zugleich von der Flexibilität und Skalierbarkeit der Public Cloud.

Eine agile Infrastruktur ist aus mehreren Gründen für DevOps von Vorteil:

• Sie zahlen bei transparenter und einfacher Preisgestaltung für das, was Sie nutzen.
• Sie können Test- und Produktionsumgebungen schnell aus Ihrer Codebasis bereitstellen und wieder abbauen (IaC – Infrastructure as Code).
• Sie bleiben bei der Architektur flexibel.
• Sie können leicht in weitere geografische Regionen expandieren.
• Sie erreichen wahrscheinlich ein höheres Sicherheitsniveau.
• Sie erfüllen die Vorgaben ohne Audits und zusätzliche Kosten.

FAZIT

In diesem Abschnitt haben wir erläutert, was DevOps ausmacht und wo die Grenzen des Begriffs liegen. Wir haben auch die wichtigsten Bewegungen und Grundsätze vorgestellt, aus denen DevOps entstanden ist.

Ein Hinweis: Viele agile Fachkräfte halten sich in der Praxis seit Jahren leider an starre Definitionen. Machen Sie es bei DevOps anders. Keine Definition sollte Ihnen vorschreiben, wie Ihre Organisation, Ihr Produkt, Ihr Dienst und vor allem Ihr Team DevOps einsetzen. Es gibt weder bei agilen Methoden noch bei DevOps eine Lösung, die für alle passt.

Im Mittelpunkt stehen Lernen, Experimentieren und Anpassung. DevOps kann uns viel Arbeit abnehmen. Die wichtigste Aufgabe für uns Menschen ist es, die passende Form und Ausprägung von DevOps zu finden. Genau das tun erfolgreiche DevOps-Organisationen wie Google, Amazon, Facebook, Netflix und Apple.