DevOps nähere Erläuterung Teil II

 DevOps

Die Prinzipien hinter DevOps sind die gleichen die die Herstellung revolutioniert haben. Statt in einer Fabrikhalle die Verwandlung von Rohmaterialien in fertige Produkte zu optimieren, zeigt DevOps, wie wir die Wertschöpfungskette in IT verbessern und Kundenanforderungen in Features und Services umwandeln, die den Anwendern etwas bringen.

DevOps beginnt mit dem Unternehmen. Durch die Zusammenführung von Teams in einer Entwicklungs- und Betriebsumgebung, die traditionell in Silos arbeiten, kann ein Unternehmen die Entwicklung beschleunigen und neue Produkte und Dienstleistungne veröffentlichen. Dahinter steht die Überlegung, dass weniger Zeit für die Übergabe zwischen Entwicklung und Betrieb verbessert sich auch die Qualität der Produkte , da DevOps auch Qualitätssicherung Tests und Sicherheit umfasst. Das Kundenfeedback wird kontinuierlich ausgewertet und in neue Iterationen des Produkts einbezogen.

Die Vorteile von DevOps sind wie folgt:

- Es bringt Geschäft, Entwicklung und Betrieb zusammen, ohne Silos.

- Unternehmen können schneller auf die Anforderungen des Marktes reagieren , da sie kontinuierlich Feedback erhalten.

- Die Produkte werden laufend verbessert und mit neuem Funktionen ausgestattet , anstatt die nächsten großen Versionen zu planen.

- Durch die Automatisierung in DevOps-Pipelines können Unternehmen die Kosten für Entwicklung und Betrieb senken und gleichzeitig die Qualität ihrer Produkte verbessern.

Die wichtigsten Prozesse der IT-Bereitstellung sind:

- Geschäftsanforderungen: Ein Unternehmen muss wissen, welche Anforderungen es an ein von ihm geliefertes Produkt stellt. Diese Anforderungen werden von den Personen gestellt, die das Produkt verwenden werden. Die Kunden verlangen ein Produkt, das eine bestimmte Funktionalität und Qualität erfüllt. Die Architektur muss sich darauf konzentrieren, eine Endprodukt zu liefern, das die Anforderungen der Kunden eines Unternehemens erfüllt. Die IT-Bereitstellung ist ein wesentlicher Bestandteil der Bereitstellung eines Endprodukts. Bei DevOps sorgt ein zugewiesener Product Owner dafür, dass das Produkt den Anforderungen entspricht. Der Product Owner muss eng mit dem Enterprise Architekt zusammenarbeiten. Im Abschnitt „Erstellen einer ReferenzArchitektur“ erfahren wir, dass die Unternehmensarchitektur und DevOps sich gegenseitig ergänzen.

- Geschäftsplanung: Sobald der Bedarf klar ist, muss das Produkt geplant werden. Bei DevOps beginnen die Produktteams in der Regel mit einem Minimum Viable Produkt (MVP), einer ersten Iteration des Produkts, das die Anforderungen des Kunden erfüllt. Beim Entwurf des MVP müssen die Prozesse die Entwicklung und den Betrieb dieses Produkts unterstützen können. Daher umfasst die Geschäftsplanung auch Qualitätsmanagement und Testen, zwei wichtige Komponenten der IT-Bereitstellung. Dies muss sich auch in der Architektur widerspiegeln.

- Entwicklung: Bei DevOps arbeitet das Produktteam mit UserStories. Ein Team muss das Produkt in Komponenten zerlegen, die als Deliverables definiert werden können. Dazu brauchen wir eine klare Definition der User Story. Eine Benutzergeschichte hat immer das gleiche Format: Als [Funktion des Benutzers] möchte ich [Wunsch des Benutzers], damit ich [Beschreibung des Nutzens, den ein Benutzer erhält, wenn die Funktion erfüllt und das Ziel erreicht ist]. Der Schlüssel zu jeder UserStory sind die Akzeptanzkriterien , oder die Definition of Done (DoD). 

Wir können den gesamten DevOps-Zyklus wie folgt in zwei Hauptphasen unterteilen:

Bereitstellung und Betrieb:

- Bereitstellung: In dieser Phase wird der Code getestet und validiert, so dass er mit der User Story übereinstimmt. Es wird nun in den Produktionszustand überführt. Das Testen und Freigeben für die Produktion ist ein Prozess, der idealerweise in der Pipeline automatisiert ist, ebenso wie die Integration. Bevor der Code in die Produktion geht, muss er auch mit der Konfiguration zusammengeführt werden. Denken Sie an Sicherheitspakete, die auf Komponenten angewendet werden müssen, die in der Produktion laufen. Im Test- und Qualitätsprozess muss das gesamte Paket- Anwendungscode und Infrastrukturkomponenten - als „produktionsreif“ validiert werden. Das Ergebnis sollte ein „lebendes“ Produkt sein. Werden bei den Tests und der Validierung Fehler, Schwachstellen oder Verstöße gegen die Sicherheitsvorschriften entdeckt, wird das Produkt in eine frühere Phase des Entwicklungsprozesses zurückgeschickt.

- Betrieb: Nach der Bereitstellung muss das Live-Produkt in Betrieb genommen werden. Zu diesem Zweck arbeiten Unternehmen nach den Grundsätzen des IT-Service-Managements (ITSM). Die Tatsache, dass die Betreiber im selben Team wie die Entwickler arbeiten, bedeutet nicht, dass die ITSM-Prozesse nicht mehr gültig sind. Ein Beispiel ist das Auftreten von Vorfällen, bei denen der Vorfallsmanagementprozess ausgelöst werden muss. Im Betrieb unterscheiden wir zwischen den folgenden Hauptprozessen: a) Anfrageerfüllung b)Störungsmanagement c) Problemmanagement (postmortem) d) Konfigurationsmanagemente) Änderungsmanagement

DevOps fügt dem noch etwas hinzu, nämlich kontinuierliche Integration und kontinuierliche Bereitstellung (CI/CD)

- Kontinuierliche Integration (CI): CI basiert auf dem Prinzip eines gemeinsam genutzten Repository’s, in dem der Code häufig aktualisiert und von Teams, die in Cloud-Umgebungen arbeiten, gemeinsam genutzt wird. CI ermöglicht es den Entwicklern , gemeinsam und gleichzeitig an demselben Code zu arbeiten.

Die Änderungen am Code werden direkt integriert und können in verschiedenen Testumgebungen vollständig getestet werden.

- Kontinuierliche Bereitstellung (CD): Dies ist die automatisierte Übertragung von Software in Testumgebungen. Das ultimative Ziel von CD ist es , Software vollautomatisch in die Produktion zu bringen. Verschiedene Tests werden automatisch durchgeführt. Nach der Bereitstellung erhalten die Entwickler sofort eine Rückmeldung über die Funktionalität ihres Codes.

CI/CD erfordert eine Feedback-Schleife , um es kontinuierlich zu gestalten. Sie benötigt Rückmeldungen über die gelieferten Produkte und Dienstleistungen. Dieses wird dann an die Entwickler zurückgespielt, und von dort aus werden neue Iterationen geplant, um das Produkt oder die Dienstleistung zu verbessern.

Folgende Architekturaussagen, bilden den Kern von DevOps

- Automatisierung: Nach dem Prinzip „alles ist Code“ lautet der nächste Schritt „alles automatisieren“. Durch die Automatisierung wird die Zeitspanne zwischen Tests und Bereitstellung erheblich verkürzt, was einen schnelleren Freigabeprozess ermöglicht. Die Automatisierung führt aber auch zu weniger manuellen Eingriffen und damit zu weniger Fehlern.

- Zusammenarbeit: Zwei der sechs Grundsätze sind funktionsübergreifende, autonome Teams und End-to-End-Verantwortung. Dies kann nur durch Zusammenarbeit erreicht werden. Entwicklung und Betrieb werden sehr eng zusammenarbeiten müssen, um die Bereitstellung von Releases zu beschleunigen. Obwohl es sich hierbei auch um einen kulturellen Wandel handelt, erfordert die Zusammenarbeit ein gemeinsames Toolset, das die Zusammenarbeit unterstützt.

- Integration: Entwicklung und Betrieb kommen zusammen, aber auch Unternehmen und IT. Bei DevOps integrieren wir die Geschäftsanforderungen mit der IT-Bereitstellung mithilfe von User Stories. Der Code wird mit neuen Funktionen integriert, die sich aus den Geschäftsanforderungen ergeben. Dieser Bedarf ändert sich heutzutage schneller, so dass die Entwicklung mit Hilfe von CI schritt halten muss. Dies wird auch zu Veränderungen im Betrieb führen - sie müssen diese neuen Entwicklungen mit der gleichen Geschwindigkeit übernehmen. Damit ist die Integration der Kern von DevOps.

- Portfolio- und Konfigurationsmanagement: Automatisierung und Integration erfordern ein klares Portfolio, das die Bausteien enthält, die leicht automatisiert werden können. Diese Bausteine sind Artefakte im ADM-Zyklus und stellen Funktionspakete dar, die zur Erfüllung einer Anforderung verwendet werden können. Ein Baustein ist wiederverwendbar und austauschbar; daher muss er klar und spezifisch definiert sein. Besser gesagt, die Konfiguration der Bausteine muss gut dokumentiert werden und unter die Kontrolle des Konfiguraitonsmanagements gestellt werden. Wenn dies gut gemacht ist, werden diese Bausteine auch klare Schnittstellen haben, so dass sie vollständig automatisiert werden können.

Jede DevOps-Architektur muss Planung, Entwicklung , Integration, Bereitstellung und Betrieb abdecken. Wir müssen uns jedoch vor Augen halten, warum wir DevOps einsetzen, nämlich um Geschäftsziele schneller und flexibler zu erreichen und Produkte kontinuierlich zu verbessern. Die DevOps-Architektur steht nicht für sich allein; sie muss mit der Unternehmensarchitektur verknüpft werden.

Ein Unternehmensarchitekt wird höchstwahrscheinlich mit dem The Open Group Architecture Framework (TOGAF) beginnen. TOGAF ist weltweit als Standard für die Unternehmens- und Geschäftsarchitektur anerkannt. Es verwendet die Architekturentwicklungsmethode (ADM), um die Architektur zu entwerfen. 

Die goldene Regel bei DevOps lautet: „You build it, you run it“, oft gefolgt von der Aussage „You break it, you fix it“.  Oder es könnte auch heißen: Du zerstörst es, du baust es besser wieder auf. Wenn etwas kaputt geht, muss das Team herausfinden, was genau passiert ist. In diesem Abschnitt werden wir über die Ursachenanalyse (RCA) als eines der wichtigsten Instrumente zur Ermittlung der Ursache eines Problems sprechen.

Jetzt soll hier noch aufgeführt werden wie DevOps für unternehmenskritische Umgebungen und warum es für die Verwaltung von Kernanwendung geeignet ist.  Hier muss definiert sein was geschäftskritischer ist.

Eine sehr einfache Definition wäre: jede Software , die ein Unternehmen benötigt, um im Geschäft zu bleiben . Wenn ein geschäftskritischer System ausfällt , würde das Unternehmen möglicherweise viel Geld verlieren, entweder durch direkte entgangene Transaktionen oder durch weniger greifbare Dinge , wie z.B. einen Rufschaden. Diese Systeme werden durch den Prozess der Business Impact Analysis (BIA) identifiziert.

Wen wir mit DevOps-Projekten beginnen, sammelt ein Architekt als erstes die geschäftlichen und technischen Anforderungen. Dazu gehören auch Ergebnisse des BIA-Prozesses, der in der Regel in Zusammenarbeit mit internen Prüfern und Unternehmensbeteiligten durgeführt wird. Anhand der BIA werden kritische Systeme oder Systemkomponenten ermittelt, die im Falle eines Ausfalls sehr schnell wiederhergestellt werden müssen. Dies ist ein sehr mühsamer Prozess.

Der Unternehmensarchitekt muss sich darüber im Klaren sein, dass die Beteiligten unterschiedliche Ansichten darüber haben , was kritische Systeme sind.  Finanzsysteme in Banken sind geschäftskritischer, aber eine Autofabrik verliert nicht sofort ihr Geschäft , wenn der Cief Financial Officer (CFO) für - sagen wir mal - eine Stunde keinen Zugriff auf die Finanzberichte hat. Die Produktion in dieser Fabrik wird jedoch sofort eingestellt, wenn die Montageroboter ausfallen.

Wo kommt DevOps ins Spiel? Bei der Erstellung des Geschäftskontinuitätsplans (BCP), in den die BIA einfließt. Es gibt keinen wirklichen technischen Grund, warum unternehmenskritische Systeme nicht in der Cloud gehostet und mit DevOps entwickelt und verwaltet werden können, aber angesichts der Tatsache, dass diese Systeme hochgradig widerstandsfähig sein müssen, gibt es einige Dinge zu beachten - zum Beispiel bei der Planung und Anwendung von Änderungen.

—————————————————————————————————————————

Hinweis:

Die Aussage, dass es keinen wirklichen technischen Grund gibt, warum unternehmenskritische Systeme nicht in der Cloud gehostet werden können, ist nicht ganz richtig. Die Latenzzeit kann ein Problem sein: die Zeit , die Informationen zwischen den Systemen benötigen. Ein weiterer Grund kann die Einhaltung von Gesetzen und Vorschriften sein. Manche Organisationen dürfen einfach keine Systeme in einem Cloud-Rechenzentrum hosten, das nicht in dem Land oder der Region liegt, in dem/der die Organisation selbst ansässig ist. Dies sind Aspekte , die ebenfalls im Rahmen der BIA berücksichtigt werden müssen.

—————————————————————————————————————————

Hier die Erklärung der drei Wege :

Der erste Weg beschäftigt sich mit dem Arbeitsfluss von der Entwicklung über IT-Operations hin zum Kunden. Um diesen Fluss zu maximieren, brauchen wir kleine Losgrössen und Arbeitsintervalle, wir dürfen keine fehlerhafte Produkte weiterreichen und müssen uns fortlaufend auf die globalen Ziele hin optimieren (im Gegensatz zu lokalen Zielen wie zum Beispiel der Fertigungsstellungsrate von Entwicklungsfeatures, dem Verhältnis von gefundenen zu behobenen Fehlern oder der Verfügbarkeit im OPs-Bereich.

Zu den notwendigen Praktiken gehören ein kontinuierlichen Build , Integration und Deployment, das Erstellen von Umgebungen auf Anforderung, das Beschränken der Work in Process und den Aufbau von sicheren Systemen sowie Organisationen, die sich sicher ändern lassen.

Beim zweiten Weg geht es um ein konstantes, schnelles Feedback zurück zu den Quellen der Wertschöpfungskette. Dadurch wird sichergestellt, dass Probleme schneller erkannt und behoben werden und nicht wieder vorkommen. So entstehen schon an der Quelle Qualität und Wissen - dort , wo wir es brauchen.

Zu den notwendigen Praktiken gehören:

- Das Stoppen des Fließbands, wenn die Builds oder Tests in der Deployment-Pipeline fehlgeschlagen,

- das Hervorheben der Verbesserung täglicher Arbeit gegenüber der eigentlichen täglichen Arbeit.

- das erstellen schneller , automatisierter Test-Suites , um sicherzustellen , dass sich der Code immer in einem potenziell auslieferbaren Zustand befindet,

- das erstellen gemeinsamer Ziele und das vereinte Durchleben von Schmerzen und Entwicklung und IT Operations

- sowie das erstellen allgegenwärtiger Messpunkte in der Produktivumgebung, damit jeder sehen kann, ob Code und Umgebung wie gewünscht funktionieren und Kundenziele erfüllt werden.

Der dritte Weg dreht sich um das Aufbauen einer Kultur , die zwei Dinge fördert:

Andauerndes Experimentieren, bei dem man Risiken ermöglichen es uns, unser Arbeitssystem immer weiter zu verbessern. Dabei müssen wir häufig Dinge ganz anders tun, als wir es schon immer getan haben. Und wenn etwas schiefgeht, ermöglichen uns unsere fortlaufende Wiederholungen und Übungen, mit den dadurch gewonnenen Fähigkeiten schnell wieder einen sicheren und normalen Zustand zu erreichen.

Zu den notwendigen Praktiken gehört das Aufbauen einer Kultur der Innovationen und des Eingehens von Risiken (im - Gegensatz zum ängstlichen Agieren oder gedankenlosen Empfangen von Befehlen), das Freihalten von wenigsten 20 Prozent der Entwicklung und IT Operations-Zeit für nicht funktionale Anforderungen und die ständige Versicherung, dass Verbesserung unterstützt und gefördert werden.

Auf diesen drei Wegen baut das Theoretische Fundament von DevOps auf , gut nachzulesen im Buch Projekt Phoenix.

Erster Teil:

https://einsiedlerkreps.blogspot.com/2023/05/devops-noops-devsecops-sre-aus-der.html