SRE - Entwicklung

 

Projekte finden

Hier geht es in der Regel darum, neue Projekte zu starten, aber es ist nicht zu unterschätzen, wie wertvoll es ist, bei der Arbeit eines anderen mitzuhelfen. Eine großartige Möglichkeit zu lernen und zu wachsen ist es , mit anderen zusammen Software zu schreiben. Wenn man Teil einer Gruppe ist, die versucht, ein Stück Software zu implementieren, lernt man oft etwas über ihre Prozesse und Bedürfnisse. 

Abgesehen davon müssen Sie, wenn Sie ein neues Projekt beginnen wollen, anstatt sich einem bestehenden Projekt anzuschließen, ein Problem finden, das Ihrer Meinung nach behoben werden muss. Diese Inspiration kann von allen möglichen Orten kommen. Meine Porjektinspirationen kommen in der Regel von verschiedenen Seiten:

=> Etwas in Ordnung bringen, das mich stört

Das ist mehr eine Form der Selbstfürsorge als alles andere. Wenn ich mich über etwas beschwere , sollte ich es in Ordnung bringen. Ein Beispiel ist, dass es mir nicht gefällt , dass einige unserer Dienste bei First Look Media nicht Ende-zu-Ende-verschlüsselt sind, also plane ich, einen generischen SSL (Secure Sockets Layer)-Kürzungsproxy für unsere Anwendungen auf jedem Server zu implementieren. Wahrscheinlich gibt es auch Dinge , die Sie nicht stören und die aufgeräumt werden müssen, worauf wir später in dieser Liste eingehen.

=> Verhindern, das Menschen sich selbst verletzen

Hier geht es darum zukünftige Ausfälle oder unbeabsichtigte Folgen zu verhindern. Ein Beispiel wäre das hinzufügen von Werkzeugen, die Konfiguraitonsänderungen testen, bevor sie bereitgestellt werden, oder das Verhindern, dass ein Benutzer Befehle ausführt, die die Produktion beeinträchtigen.

=> Dinge aufräumen

Oft geht es nur darum, technische Schulden zu beseitigen. Bei der ersten Implementierung einer Software wird der kürzestmögliche Weg gewählt, wobei der Schwerpunkt auf der Auslieferung und nicht auf der langfristigen Wartbarkeit liegt. Sich die Zeit nehmen, um einen Hack in etwas Stabileres und Langlebigeres zu verwandeln, ist eine wichtige Arbeit. Dazu kann das Refactoring von Codeabschnitten gehören, um sie an moderne Standards anzupassen, Abhängigkeiten zu aktualisieren , etwas umzuschreiben, um es leistungsfähiger zu machen, oder ungenutzten Code zu entfernen.

=> Automatisieren von Aufgaben , die jemand von Hand erledigt hat

Dies ist eine der klassischsten SRE-Aufgaben. Indem Sie etwas automatisieren, gewinnen Sie Zeit für sich und andere, um an anderen Dingen zu arbeiten. Dies ist eine große Kategorie, aber sie könnte jeden menschlichen Prozess oder jede Checkliste umfassen, die in Code automatisiert wird.

=> Verbesserung einer Abhängigkeit , um sie widerstandsfähiger zu machen

Die Analyse von Abhängigkeiten und Teilen Ihrer Infrastruktur auf mögliche Ausfälle ist wertvoll, denn oft ist man mit dem Zustand eines Dienstes zufrieden, bis er ausfällt. Das Analysieren und Reparieren einer solchen Lösung kann undankbar sein, erspart Ihnen aber in Zukunft viel Ärger. Dies könnte dadurch geschehen, dass man mehrere Kopien des Dienstes laufen lässt, Backups anlegt oder den Failover- oder Bereitstellungsprozess verbessert.

Definition von Projekten

Sobald Sie Ihre Aufgabe oder Ihr Problem haben, müssen Sie sich überlegen, wie Sie es angehen wollen. Ich persönlich beginne damit, das Problem in ein Notitzbuch zu schreiben und mir Notizen darüber zu machen, was ich nicht weiß, was ich weiß und wie ich versuchen könnte, es zu lösen. In dieser Recherephase suche ich oft im Internet , um herauszufinden , wie andere Leute das Problem gelöst haben, ob es Open-Source-Tools gibt, die bereits veröffentlicht wurden und das Problem betreffen, oder wenn niemand sonst dieses Problem hat, warum das so ist.

Durch die Bewertung der Lösungen anderer lernen Sie, wie das Problem in verschiedenen Umgebungen auftritt. Es ist auch nützlich, um herauszufinden, ob ein Stück Open-Source-Software Ihr Problem lösen oder fast lösen könnte. Jede Situation ist anders, aber oft können Sie ein Softwareprojekt finden, das 90% dessen erfüllt, was Sie wollen, und Sie können es entweder erweitern oder mit dem Betreuer zusammenarbeiten, um zu sehen, ob die Software für Ihre Situation geeignet ist. All diese Nachforschungen ersparen Ihnen Arbeit und stellen sicher, dass Sie wissen, worauf Sie sich einlassen. Lassen Sie sich durch Ihre Nachforschungne jedoch nicht entmutigen! Wenn Sie auf ein Problem stoßen, das noch niemand gelöst hat, bedeutet das nicht, dass es zu schwierig ist: Es bedeutet nur , dass es mehr Unbekannte gibt , die das Projekt betreffen.

Sie müssen ständig überprüfen, ob das Projekt , an dem Sie arbeiten, das Problem löst, das Sie zu lösen versuchen (und ob das Problem immer noch dasselbe ist). 

Planung von Projekten

Sobald Sie eine ungefähre Vorstellung davon haben, was Sie bauen wollen, und dies in gewissem Umfang dokumentiert haben, müssen Sie mit der Arbeit am Projekt beginnen: die Arbeit planen und vorankommen.

Es gibt viele Definitionen von Agile und viele ähnliche Philosophien (einschließlich Scrum und Extreme Programming), aber die grobe Idee ist ein Periode oder Iteration, in der sich das Team nach jeder Periode neu gruppiert, die Prioritäten und Pläne auf der Grundlage von Feedback anpasst und sich dann wieder an die Arbeit macht. Wie bei allem in der Technik gibt es Eiferer , die Ihnen sagen, was richtig und was falsch an Agile ist. Denken Sie einfach daran: Wenn es für Sie und Ihr Team funktioniert, dann ignorieren Sie die Eiferer, denn Sie können Ihnen nicht sagen, was Sie tun sollen. Einige Teams arbeiten beispielsweise ausschließlich mit Pair Programming, während ander Teams dies nicht tun können , weil sich nicht alle in derselben Zeitzone befinden oder weil es MItarbeiter gibt, die aufgrund familiärer Verpflichtungen unterschiedliche Arbeitszeiten haben. Es geht nicht darum, die Leute zu ignorieren , sondern zu bewerten, was sie sagen, und herauszufinden, ob das für Ihr Team funktionieren würde.

Viele moderne Teams nutzen Agile als Mittel, um das Team zu organisieren und sicherzustellen, dass ein einzelnes Teammitglied nicht zu sehr im Unkraut versinkt. Indem Sie sich in regelmäßigen Abständen melden (einmal pro Tag, Woche oder zwei Wochen), können Sie den Fortschritt im Auge behalten und Ihren Kollegen helfen zu verstehen, woran Sie arbeiten und was Sie behindert.

Wenn Sie entscheiden müssen, woran Sie arbeiten und wie Sie ein großes Projekt angehen wollen, ist es am besten, das Projekt in kleine Teile zu zerlegen. Anstatt darüber nachzudenken, wie Sie alles implementieren können, überlegen Sie, welche Funktionen Sie haben wollen. Wählen Sie dann eine Funktion aus und erstellen Sie eine Liste der Funktionen oder Teile, die Sie implementieren müssen, damit die Funktion funktioniert.

Retrospektiven und Standups

Zwei Aspekte von Agile , über die wir noch nicht gesprochen haben und die ich sehr schätze , sind Retrospektiven und Standups. Ein Standup ist ein tägliches Treffen, bei dem alle Teammitglieder darüber sprechen, woran sie gestern gearbeitet haben, was sie heute tun und wo sie blockiert sind. Dies ist die Möglichkeit, die Mitarbeiter über ein Projekt auf dem Laufenden zu halten und über alle Änderungen zu informieren. Selbst wenn jeder an etwas anderem arbeitet, können die Teilnehmer auf diese Weise auf dem Laufenden bleiben. 

Retrospektiven sind eine Möglichkeit, die Pläne der vergangenen Woche, des vergangenen Monats , der vergangenen zwei Wochen oder was auch immer Revue passieren zu lassen. Dabei handelt es sich um regelmäßige Treffen, bei denen sich die Teilnehmer darüber austauschen, was gut , was schlecht und was ganz okay gelaufen ist. 

Ein Instrument für Retospektiven sind die 4Ls. Wie bei der obigen Idee erstellen Sie eine Tafel mit vier Kategorien: Gefallen, Gelernt, Vermisst und Ersehnt. Die Teammitglieder kleben dann Post-it-Zettel in jede Kategorie. Anschließend werden die Post-it-Zettel nach Topics gruppiert und diskutiert.

Versuchen Sie herauszufinden , wie viel Arbeit eine Person pro Zeiteinheit bewältigen kann, und stellen Sie sicher, dass sie das Gefühl hat, die zugewiesene Arbeit bewältigen zu können. Hinzu kommt, dass sich die Menschen überfordert fühlen können. Es besteht die Gefahr , dass sich die Mitarbeiter in ihrer Arbeit ineffektiv fühlen, weil sie nicht in der Lage sind, die ihnen zugewiesene Arbeit zu erledigen. Dieses Gefühl der Ineffizienz sowie körperliche und emotionale Erschöpfung sind Anzeichen für chronischen Stress und Burnout , die sich negativ auf das Wohlbefinden des Arbeitnehmers auswirken und ihn dazu bringen können, zu kündigen.

Builds

Sobald die Arbeit geplant und zugewiesen ist, können Sie sich hinsetzen und mit der Codierung beginnen. Als Entwickler müssen Sie sich bei der Einführung von neuem Code in ihre Infrastruktur an alle vorherigen Hierarchieebenen erinnern. Als SRE wird Ihre Arbeit oft als Vorbild dafür angesehen, was die übrigen Entwicklerteams tun sollten.

Eine einfache Checkliste für neue Software , die Sie auf der Grundlage unseres Hierarchieframeworks schreiben, lautet wie folgt:

=> Überwachung

Verfügen Sie über grundlegende Metriken, die von dem Code stammen, den Sie schreiben? Werden Sie gesammelt und gespeichert?

=> Reaktion auf Vorfälle

Erstellen Sie eine Dokumentaiton über den Betrieb Ihres Dienstes? Gibt es Warnmeldungen, so dass jeder , der sie erhält , weiß, was zu tun ist, wenn er entlassen wird?

=> Postmortem

Wenn Ihr Code ausfällt, behandeln Sie ihn dann wie anderen Code, der ausfällt, und schreiben Sie einen Postmortem?

=> Testen und Freigeben

Schreiben sie Unit-und Integrationsstests für Ihren Code? Dokumentieren Sie sowohl den Freigabeprozess als auch den Rollback-Prozess?

=> Kapazitätsplanung

Dokumentieren Sie, wie sich dies auf die Leistung Ihres Systems auswirken wird?

Ratschläge zum Schreiben von Code

=> Verwenden Sie die Versionskontrolle

Dies ist der Sonnenschutz der Computerprogrammierung. Es gibt kein Projekt , das zu klein ist, als dass man nicht die Versionskontrolle verwenden könnte. Menschen machen Fehler , und mit der Versionskontrolle können Sie Fehler leicht rückgängig machen oder sehen, wann ein Fehler eingeführt wurde.

=> Führen Sie immer Code-Reviews durch

Als Entwickler wissen Sie nur so viel, dass es Ihnen hilft, Ihre Arbeit mit anderen Augen zu lesen, um Fehler zu finden und Annahmen zu beseitigen, die Sie möglicherweise gemacht haben. Ihr Code verdient mindestens einen Redakteur, der Ihnen hilft, die Zahl der Fehler zu begrenzen.

=> Alle Projekte sollten einen Verantwortlichen haben: 

Irgendwann werden alle Projekte Fragen von externen Parteien aufwerfen. Für alle Projekte sollte ein Verantwortlicher benannt werden, damit es jemanden gibt, der diese Fragen beantworten kann. Dies ist auch wichtig, wenn Sie über Prioritäten entscheiden. Ein Verantwortlicher bedeutet, dass es eine Person gibt, die die endgültige Entscheidung darüber treffen kann, was am wichtigsten ist.

=> Das Problem sind immer die Menschen

Wie Sie vielleicht aus den drei vorangegangenen Vorschlägen entnommen haben, ist der Mensch oft das Problem. Es ist sehr wichtig, mit Code zu arbeiten und zu wissen, dass er von Menschen genutzt werden wird. Dies könnte dadurch geschehen, dass Sie sicherstellen, dass Prozesse vorhanden sind, um mit der Tatsache umzugehen, dass Menschen an dem Code arbeiten müssen, oder indem Sie Ihre Programmierung dahingehend ändern, dass Sie davon ausgehen, dass alle Eingaben in Ihre Software von Menschen stammen (entweder direkt oder indirekt) und daher widerstandsfähig sein müssen. Menschen werden oft Anforderungen ändern, Bedürfnisse falsch kommunizieren oder einfach nur Chaos verursachen. Seien Sie immer bereit, sich in andere hineinzuversetzen und Ihre eigenen Fehler zu korrigieren. Die Bereitschaft, anderen gegenüber freundlich zu sein und ihre Gefühle zu verstehen, wird die Stimmung der Menschen verbessern und wahrscheinlich die Wahrscheinlichkeit erhöhen, dass sie Ihnen helfen werden, wenn Sie scheitern. Denken Sie daran, dass Misserfolge passieren werden, also lächeln Sie  und machen Sie weiter.

Trennung von Belangen

Ein Aspekt von Software, der in der Entwurfs- und Entwicklungsphase berücksichtigt werden sollte , ist die Trennung von Belangen. Der Gedanke dahinter ist, dass der gesamte Code für den Umgang mit bestimmten Datentypen an einem Ort angesiedelt ist, und seine API bereitgestellt sein sollte; jede andere Software , die mit diesen Daten arbeiten möchte , tut dies dann über die API. Das bedeutet , dass Ihre Daten von anderem Code oder anderen Diensten nicht berührt werden. In einigen Fällen ist dies einfach, aber in den meisten Fällen kann eine stärkere Trennung der Daten durch eine API zu Datenduplizierung oder schlechter Leistung führen. Das liegt daran, dass eine verteilte Zustandsverwaltung schwierig ist.

Wenn beispielsweise vier Softwareprogramme wissen müssen, wie viel Geld ein Benutzer auf seinem Bankkonto hat, mag es einfacher erscheinen, die Datenbank abzufragen, aber auf lange Sicht macht der Aufruf einer klar definierten API das Leben leichter. 

Wenn Sie diese Trennung gut hinbekommen, können Sie theoretisch bei Bedarf einen Teil herausreißen und durch einen Dienst ersetzen. Ein gängiges Beispiel hierfür ist die Authentifizierung.  Oft beginnen Teams mit der Authentifizierung innerhalb ihrer Anwendung , aber wenn andere Dienste die Authentifizierung benötigen, ersetzen sie den Code in der Anwendung durch den Aufruf eines externen Dienstes, der eine ähnliche API bietet.

Eine etwas ähnliche Idee ist die Unix-Philosophie. Diese Philosophie hat einige Grundsätze , aber die beiden, auf die ich mich gerne konzentriere, sind das Schreiben von Software, die nur eine Sache tut, und das Schreiben von Software , die zusammenarbeitet. Sie können dies in den meisten gängigen Linux-Befehlszeilenprogrammen sehen. 

Beachten Sie, dass die Trennung von Belangen und die Unix-Philosophie oft als Begründung für den Wechsel zu einer serviceorientierten Architektur oder zu Microservices herangezogen werden. Beide Begriffe stehen für die Idee, den Code in viele kleinere Dienste oder Teile aufzuteilen. Es gibt Probleme mit einer solchen Infrastruktur (mehr zu überwachende Teile, möglicherweise teuer udn eine höhere Wahrscheinlichkeit eines Netzwerkausfalls), aber in der Regel ist die Trennung von Belangen kein gutes Argument, wenn es das einzige Argument für einen Wechsel ist. Sie können Bedenken innerhalb Ihres Codes trennen, wenn Sie wollen, indem Sie einfach separate Klassen oder ander Organisationstechniken verwenden.

Langfristige Arbeit

ein weiterer Faktor, über den wir in Bezug auf die Entwicklung sprechen sollten, ist das langfristige Planen und Denken. Die moderne Entwicklung ist so sehr auf schnelle Iterationen ausgerichtet, dass die Leute oft nicht mehr daran denken, sich anzuschauen, wo sie stehen sind und wohin sie gehen. Ich mache gerne eine vierteljährliche Retrospektive und plane für mich selbst, um dieses Problem zu lösen.  Bei einigen Unternehmen ist dies bereits in den Planungsprozess integriert, aber sie können es auch selbst tun.

Ein allgemeiner Rahmen , den einige Unternehmen verwenden , kann man auch für die persönliche Plannung nutzen. Er nennt sich Ziele und Schlüsselergebnisse (OKRs). Die Idee hinter den OKRs ist, dass Sie eine Liste von Dingen aufstellen, die Sie erreichen wollen, also Ziele, udn dann messbare Kontrollpunkte als Ihre Schlüsselergebnisse erstellen. Am Ende des Quartals schauen Sie sich dann Ihre OKRs an und prüfen , was Sie vorhatten zu tun, bevor Sie es mit dem vergleichen, was Sie erreicht haben.

Projekte dokumentieren und pflegen

Ein letztes , aber sehr wichtiges Detail ist die Dokumentation und Wartung des von Ihnen erstellten Codes. Hoffentlich hält Ihr Code so lange, wie er gebraucht wird. Die frühzeitige Festlegung guter Standards für die Dokumentation fördert die Bereitschaft anderer , in Zukunft Dokumente zu schreiben.

Beim schreiben von Dokumentation ist es wie beim Schreiben von Code: Ihr Team wird einen eigenen Stil haben und das Ziel sollte Genauigkeit und Konsistenz sein, nicht Perfektion, den Perfektion ist unmöglich.

Vorige Themen:

https://einsiedlerkreps.blogspot.com/2023/05/sre-monitoring.html

https://einsiedlerkreps.blogspot.com/2023/05/sre-reaktion-auf-vorfalle-incident.html

https://einsiedlerkreps.blogspot.com/2023/05/sre-postmortems.html

https://einsiedlerkreps.blogspot.com/2023/05/sre-testen-und-freigeben.html

https://einsiedlerkreps.blogspot.com/2023/05/sre-kapazitatsplanung.html

Auskopplung vom Post:

https://einsiedlerkreps.blogspot.com/2023/05/sre-die-nachste-stufe-von-devops-teil.html

System Landscape Directory (SLD)

 Eine SAP-Systemlandschaft ist meistens heterogen. Das heißt , in einer Unternehmenslandschaft gibt es unterschiedliche Anwendungssysteme verschiedener Hersteller, die miteinander agieren. Um die Komplexität zu optimieren, hat SAP das System Landscape Directory entwickelt. Diese Landkarte stellt die Topologie der Entwicklungen in der eigenen Systemlandschaft strukturiert und zentral dar.

Das SLD dient als zentrales Systeminformationsverzeichnis der gesamten Landschaft. Es enthält die technischen Beschreibungen der in der Landschaft installierten und installierbaren Systeme, Produkte und Softwarekomponenten.

Das SLD trägt unter anderem dazu bei, wichtige Informaitonen, z.B. die für die Konfiguration benötigten Softwarekomponenten, an den SAP Solution Manager weiterzuleiten. Diese Informaitonen werden als Grundlage für das Landschaftsmanagement des Unternehmenssoftware-Lifecycles benötigt. Das SLD kann somit als Standalone-System, das zentral Landschaftsinformationen für alle beteiligten Systeme zur Verfügung stellt, betrachtet werden.

Common Interface Model

Das Common Interface Model (CIM) sit ein Standard der DMTF (Distributed Management Force) und basiert auf dem objektorientierten Modelierungsansatz. Die DMTF ist ein Konsortium aus verschiedenen Unternehmen zur Organisation einheitlicher Open-Source-Standards, die sich über verschiedene aufkommende und traditionelle IT-Infrastrukturen wie Cloud, Virtualisierung, Netzwerk , Server und Storage erstrecken.

https://www.dmtf.org/about

Der Vorteil dieser Standards ist die einfache Erweiterbarkeit der Beschreibungsschemata zu den einzelnen Elementen in einer Systemlandschaft im Rahmen von Kernklassen. SAP verwendet diese Norm in SAP-spezifischen Klassen. So werden z.B. für unterschiedliche Systeme unterschiedliche Objekte , basierend auf Klassen, erzeugt. Klassen können eine Ansammlung von anderen Objekten als Attribute umfassen. Damit diese Klassen Erweiterungen wie neue Attribute umfassen. Damit diese Klassen Erweiterungen wie neue Attribute erhalten können, lassen sich diese mittels Beschreibungs-schemata einfach vorgeben und auf die jeweilige Klasse übertragen.

Eine Besonderheit des CIM ist die Beschreibung der Verbindung zwischen den Klassen. Über Referenzschlüssel können z.B. zwei Klassen verbunden werden. Eine Assoziation ist eine Klasse , die zwei Referenzschlüssel beinhaltet und eindeutig einer CIM-Instanz zuzuordnen sein soll.

—————————————————————————————————————————-

Definition CIM-Instanz

Eine Instanz ist eine Ausprägung einer Klasse oder ein Objekt der Klasse. Alle in der Klasse definierten Eigenschaften besitzen bei einer Instanz feste Werte.

Beispiel: Die CIM-Klasse SAP_Product kann Instanzen besitzen, wie z.B. mySAP und R/3 Enterprise.

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

Verständnis von Landschaftsbeschreibung - Produkt , Produktinstanzen und Softwarekomponenten

Die Beschreibung - oder "Modellierung" - von Systemlandschaften basiert auf einigen Entitäten, die Produkte genannt werden.

Produktinstanzen und Softwarekomponenten. Diese Begriffe und die Modell-Entitäten, die sie beschreiben, tauchen in den Management- und Entwicklungssystemen von SAP auf. Was für Sie vielleicht noch wichtiger ist, ist, dass sie die Grundlage für die Beschreibung von Landschaften im SAP Solution Manager sind, die Sie z.B. für die Systemüberwachung oder die Wartung benötigen.

Das Verständnis dieser Instanzen ist also notwendig für ein erfolgreiches Management dieser Landschaften. 

Hier sehen Sie, wie Sie die SAP-Begriffe auf ein Auto übertragen können (natürlich hat ein Auto - wie die Produkte von SAP - viel mehr Teile):

Produkt: Ein Produkt ist das Modell eines Autos in verschiedenen Ausführungen und einschließlich des Fahrzeugbriefs (Ihr Vertrag zur Nutzung des Produkts) und der Garantiebescheinigung (des Wartungsvertrags). Ein Produkt ist also das, was Sie kaufen

Softwarekomponenten (SCs): Softwarekomponenten sind die Elemente, die in einem Stück entwickelt werden und die Sie normalerweise als ein Teil sehen würden - die Karosserie, die Fenster und die Räder. Es gibt optionale Komponenten, wie Add-Ons, wie z.B. Transportkoffer, Antenne, Ersatzrad....

Produktinstanzen: Softwarekomponenten können einzeln betrachtet und gehandhabt werden, aber wenn es darum geht, ein Produkt einzurichten, gehören einige Teile einfach zusammen: Ein Satz Fenster gehört nur zu einem Wagentyp, Vorder- und Hinterrad sind ein passender Satz. Solche Sätze von Softwarekomponenten, die zusammengehören, sind die Produktinstanzen.

Hier sind einige Punkte, die Sie wissen sollten. Über Produktinstanzen Bescheid wissen: Sie

- können in mehreren Produkten wiederverwendet werden - siehe z.B. das Rad-Set

- können eine oder mehrere SCs enthalten

- können optional sein - siehe auch das Add-On

Verwendung: Was Sie am Ende verwenden, ist eine bestimmte Konfiguration eines bestimmten Produkts.

Die Elemente des Produkts - ihr Zweck

Was ist nun der Zweck der oben beschriebenen Elemente?

Produkte definieren einen Gesamtumfang, eine Reihe von Funktionen zur Lösung eines Geschäftsbedarfs. Es wäre nicht hilfreich, in Softwarekomponenten zu denken, wenn es um Geschäftsprozesse insgesamt geht. Das ist auch wichtig, wenn es um die Wartung einer IT-Landschaft geht: Geschäftsprozesse und damit die Produkte sind die Einheiten eines Upgrades, die Sie sehen müssen.

Softwarekomponenten sind die Einheiten, die entwickelt werden, aber wie besprochen, machen aus der Perspektive einer Installation oder eines Updates nur bestimmte Sätze von SCs Sinn - bei der Installation und noch mehr bei der Systemwartung werden Sie also mit diesen Sätzen, den so genannten Produktinstanzen, umgehen.

Produkte und Produktinstanzen werden verwendet, um Software zu beschreiben, die SAP ausliefert. 

Es sind auch diese Entitäten, die Sie verstehen müssen, um Ihre Systeme zu warten.

Diese beiden Dinge sind wichtig, weil sie definieren, was Sie bei der Verwaltung Ihrer Systeme manuell tun müssen.

Produkte, ihre Elemente und die Komplexität, mit der Sie umgehen müssen

Auch wenn sich auch hier mehr Ähnlichkeiten mit Autos finden lassen, werden wir von nun an abstrakter vorgehen.

Während die Grundlagen von Produkten, Softwarekomponenten und Produktinstanzen mit einer einfachen Analogie erklärt werden können, muss die Zuordnung zu Produktsystemen sorgfältig erfolgen - der Grund dafür ist, dass wir es mit Produkten in verschiedenen Versionen zu tun haben und ihre Teile durch Wiederverwendung Abhängigkeiten aufweisen, was große Vorteile hat (offensichtlich weniger Versionen von Objekten insgesamt), aber durch Verschachtelung und Versionierung zu einer gewissen Komplexität führt, die sowohl in den Produktdefinitionen als auch in den Produktsystemen auftaucht, mit denen die Produkte in der Landschaft betrieben werden

Produkte

Produkte sind Anwendungen, die Sie kaufen und betreiben, um Ihre Geschäftsanforderungen zu erfüllen.

=> Produkte werden oft über mehrere technische Systeme hinweg installiert, zum Beispiel um Dual-Stack-Installationen zu vermeiden

=> Produktinstanzen bestehen aus Softwarekomponenten, die - wiederum - in verschiedenen Produktinstanzen wiederverwendet werden können.

=> Produktinstanzen enthalten andere Produktinstanzen auf zwei Arten, die unterschiedlich gehandhabt werden müssen, als explizite Includes oder implizite Includes

Produktsysteme

Ein Produktsystem ist eine Gruppe von einem bis mehreren technischen Systemen, die zur Installation einer Produktversion verwendet werden

=> Technische Systeme können in mehr als einem Produktsystem wiederverwendet werden

=> Die Zuordnung von technischen Systemen zu Produktsystemen erfolgt auf der Ebene der Produktinstanzen.

In einem technischen System finden Sie also Produktinstanzen mehrerer Produktversionen, aber Sie können nur die Produktinstanzen einem Produktsystem zuordnen, die zu diesem einen Produkt gehören:

Abbildung : Die Produktversionen A und J sind mit einigen Überschneidungen auf zwei technischen Systemen ABP und JAP installiert und werden in zwei Produktsystemen ABP und JVP verarbeitet.

Hier ist die Situation in der Abbildung erklärt

=> Ein hypothetisches Produkt A ist in der aktuellen Version AS ABAP und AS Java basiert. Produkt A

=> Hat die Produktinstanzen A1.A2 (als ABAP-basiert) und A3 (als Java-basiert).

=> Es enthält außerdem eine Produktinstanz PI J1

=> Produktinstanzen von Produkt A sind auf dem AS ABAP-basierten technischen System ABP und dem AS Java-basierten technischen System JAP installiert.

Produkt J in der aktuellen Version ist AS Java-basiert und hat

=> Produktinstanz J1 und J2.

Die => PIs J1 und J2 sind auf dem AS Java-basierten technischen System JAP neben der PI A3 installiert.

Die Einbeziehung von Produktinstanzen kann explizit oder implizit erfolgen. Details werden später erklärt.

Wie man mit Produktsystemen umgeht

Auch wenn Produktinstanzen mehrerer Produktversionen auf demselben technischen System installiert sind, sprechen Sie in der Wartung eine Produktversion an, die Sie pflegen wollen.

Versionierung

Produkte bestehen, wie wir gelernt haben, aus Produktinstanzen. Ein Produkt ist etwas abstrakt, zum Beispiel . Im wirklichen Leben werden Sie immer mit einer Produktversion zu tun haben. Daher ist es notwendig und ausreichend, die richtige Produktversion zu wählen. Auch wenn in einem Produktsystem mehr als ein Produkt gehandhabt werden kann, kann in einem Produktsystem nur eine Version jedes Produkts existieren.

Umgang mit Produkten und ihren Bestandteilen

Der Gesamtprozess umfasst die folgenden Instrumente und Schritte:

Abbildung: Prozesse, Landschaftsdaten und Werkzeuge der Landschaftsdatenverwaltung im Anwendungslebenszyklus.

Datenfluss von Landschaftsdaten - Datenquelle und beteiligte Werkzeuge

=> Installationswerkzeuge fügen technische Systeme zu Ihrer Landschaft hinzu.

=> Die Daten der technischen Systeme werden im System Landscape Directory (SLD) gesammelt und an die verschiedenen "Client-Applikationen" weitergegeben:

=> Das SLD erlaubt die Registrierung von technischen Systemen über deren Datenlieferanten.

=> Für neuere Releases enthalten diese Daten bereits das Produkt, die Produktversion und die installierten Produktinstanzen.

=> Bei älteren Releases müssen die Daten zu Product. Produktversion und Produktinstanzen müssen dem technischen System in der LMDB hinzugefügt werden.

=> Das SLD liefert Systemdaten an Anwendungen in der Landschaft, die Systemdaten benötigen, wie z.B. Process Integration, und NWDI benötigen Systeminformationen und lesen diese direkt aus dem SLD. Um diese Informationen in anderen SLD (z.B. im Entwicklungsbereich) verfügbar zu machen, werden die Systemdaten aus dem zentralen SLD durch Weiterleitung in andere SLD-Systeme repliziert.

=> Das SLD liefert Systemdaten für den SAP Solution Manager, der Systemdaten aus dem (zentralen) SLD liest und im SAP Solution Manager zu Landschaftsdaten (z.B. Produktsysteme, Technische Szenarien) anreichert oder aggregiert.

=> Die Landscape Management Database (LMDB) ist mit einer SLD (vorzugsweise nur eine SLD, und in diesem Fall in der Regel die zentrale SLD im produktiven Bereich Ihrer Landschaft) in Ihrer Landschaft verbunden, die als einzige Quelle der Wahrheit für Systemdaten im SAP Solution Manager dient:

- Einlesen des SLD durch vollautomatische Synchronisation

- Anreicherung der Daten der technischen Systeme, wo dies erforderlich ist (einschließlich der manuellen Erstellung neuer technischer Systeme, wo derzeit kein Datenlieferant verfügbar ist)

- Versorgung von Client-Anwendungen im SAP Solution Manager (z.B. SMSY und Monitoring) mit Systemdaten.

=> Basierend auf dem Technischen System wird im SAP Solution Manager folgendes gemacht:

- Produktsysteme für den Maintenance Optimizer (MOpz) und logische Komponenten in der Transaktion SMSY definieren - benötigte technische Systemdaten werden automatisch aus der LMDB synchronisiert (ersetzt diesen Teil des Landscape-Fetch-Jobs, der die Daten aus der LMDB holte)

- Definieren Sie technische Szenarien für die Überwachung von Anwendungen in der LMDB.

=> Verwenden Sie Produktsysteme und technische Szenarien in der Wartung und Überwachung. Änderungen in den technischen Systemen werden automatisch von ihren Datenlieferanten aktualisiert (wo dies nicht möglich ist, muss es manuell erfolgen).

SLD_Objekte in der SAP-Systemlandschaft

Das SLD stellt die Schlüsselrolle in jeder SAP-Process-Orchestration-Landschaft dar. Es beinhaltet alle Informationen über die Softwarekomponenten, Produkte und Systeme, die ebenfalls in unterschiedlichen Phasen des Designs und der Integration benötigt werden. Im SLD lassen sich Entwicklungen bzw. Implementierungen in der Systemlandschaft einer Topologie gleich festhalten und katalogisierung.

Im SLD können Sie zwischen den drei Kategorien Landschaft, Softwarekatalog und Entwicklung unterscheiden. Diese Kategorien erläutern wir näher in den folgenden Abschnitten. 

In der Kategorie Landschaft , auch Systemkatalog genannt, werden alle Informationen der installierten und installierbaren Systeme festgehalten. In dieser Kategorie werden explizit die technischen und die Business-Systeme beschrieben, die ebenfalls in einer „Art“ Landschaft konfiguriert und gruppiert werden.

Technische Systeme sind Anwendungssysteme , die in der Landschaft installiert sind (z.B. SAP Customer Relationship Management [CRM], SAP Solution Manager, SAP Process Orchestration, SAP Hybris E-Commerce etc). Die technischen Systeme im SLD lassen sich in die folgenden fünf Typen unterscheiden:

=> Systeme, die auf dem SAP NetWeaver Application Server (AS) ABAP basieren

=> Systeme, die auf dem SAP NetWeaver Application Server(AS) Java basieren

=> Standalone-Systeme (eigenständige Systeme)

=> Drittanbietersysteme

=> SAP Process Orchestration (PO)

Technisches System, da auf SAP NetWeaver AS ABAP basiert

Ein SAP NetWeaver AS ABAP ist ein Applikationsserver , entwickelt von SAP, der aus mehreren Applikationsserver-Instanzen sowie einer oder mehreren Datenbanken besteht. SAP-Systeme wie SAP ERP, SAP CRM oder SAP Solution Manager basieren auf AS ABAP.

Das Anlegen bzw die Registierung eines technischen System vom Typ ABAP erfolgt in den meisten Fällen komplett automatisch. Dafür müssen das zugehörige SLD und der jeweiligen ABAP-Stack verbunden sein. Dazu werden aufsteigen von SAP NetWeaver AS ABAP Systeminformationen über ein Datenerfassungsprogramm gesammelt und an das SLD weitergeleitet (Transaktion RZ70). Dieser Vorgang wird meistens von der SAP-Basis Abteilung eines Unternehmens durchgeführt.

Es ist nicht zu empfehlen, das technische System vom Typ ABAP manuell anzulegen. Nur wenn eine automatische Registrierung eines technischen ABAP-Systems nicht möglich ist, sollte das manuelle Anlegen angewandt werden.

Technisches System, das auf SAP NetWeaver AS Java basiert

Ein SAP NetWeaver AS Java ist ein Applikationsserver , entwickelt von SAP, der aus mehreren Applikationsserver-Instanzen sowie einer oder mehereren Datenbanken besteht.

Technisches System von Typ Standalone

Wie andere Systeme aus der eigenen Systemlandschaft (ABAP und Java) kann ein technisches SAP-System vom Typ Standalone manuell angelegt werden. Andere technische Systeme vom Typ Standalone, die nicht von SAP zur Verfügung gestellt werden, müssen hingegen generell manuell angelegt werden. Als Standalone-Systeme werden Systeme ohne einen eigenen ABAP-Stack bezeichnet.

Technisches System vom Typ Third-Party

Technische Systeme vom Typ Third-Party (Drittanbietersysteme) sind Systeme , die Drittanbieterprodukte bzw. Drittanbieter-Softwarekomponenten beinhalten.

SLD-Konzept

Jedes Unternehmen kann ein SLD installieren und es in den eigenen Betrieb integrieren. Allerdings muss vorher zur Reduzierung inner-betrieblicher Konflikte ein für die unternehmenseigene IT-Infrastruktur  optimales Konzept erstellt werden.

Mehrere SLD in einer Architektur stellen in einer heterogenen Landschaft keine Seltenheit mehr dar. Basierend auf der Systemverteilung (geografisch oder administrativ) werden Systemgruppen definiert (z.B. wird jede Gruppe einem SLD zugeordnet). Das Konzept , mehrere SLDs einzurichten (Poly.SLD) ist dann sinnvoll, wenn ein Unternehmen seine produktive Umgebung isolieren möchte.

Dann haben nur die Administratoren den Zugriff auf das produktive SLD, wohingegen die Entwickler an einem Designtime SLD arbeiten können.

Ein Vorteil dieser Isolierung und Trennung von SLDs ist die Ausführung von Tests, CIM-Data-Model-Updates und Patches. Mit verschiedenen SLDs lassen sich operative Releases in der Systemlandschaft organisierter umsetzen.

Der richtige Prozess

Sie können das SLD in Ihrer SAP-Landschaft auf unterschiedlichen Wegen implementieren udn ausführen. Jede Option hat Vor- und Nachteile. Deshalb müssen Sie die Installation des SLD gemäß Ihren Landschaftsanforderungen planen.

Das richtige SLD-Konzept zu definieren ist nach wie vor das Grundgerüst der Erstellung einer IT-Strategie. Aus diesem Grund sollten Sie sich mit dem SLD, den SAP-Systemen und deren fundamentalen Konzepten vertraut machen. Stellen Sie daher grundlegende Konzeptfragen , wie z.B.:

=> Benötigen Sie mehrere SLDs? Wenn ja, warum?

=> Wie soll das SLD eingerichtet und ausgeführt werden (als Standalone , auf dem SAP-Solution-Manager-System, auf dem SAP-Process-Orchestration-System etc)?

=> Sollen Daten ausgetauscht werden (nur CIM-Daten oder auch die System- und Softwarekataloge etc.)?

=> Welche Synchronisierungsoptionen wollen Sie planen (unidirectional, volle Synchronisierung etc.)?

=> Wie ist es mit der Releasehomogenität und Kompatibilität (sollen hier für das SLD Systeme gepatscht werden etc.)?

=> Welche Anwendungen können im Fall einer Nichterreichbarkeit betroffen sein?

=> Wie sieht es mit den technischen Einschränkungen aus (Netzwerk, Firewall, Nachrichtenzahl, Hardware, Hochverfügbarkeit etc.)?

SLD und die Systemlandschaft

Nachdem Sie die Anzahl und Typen der SLDs bestimmt haben, sollen Sie jetzt entscheiden, wo die einzelnen SLDs laufen sollen. Es gibt verschiedene Möglichkeiten, und jede Option hat Vor- und Nachteile. In einer normalen Landschaft haben Sie vielleicht eine Mischung aus einem zentralen Laufzeit-SLD, einen zentralen Designzeit-SLD, und einen lokalen SLD .

Nachfolgende zeigt die Vor- und Nachteile eines dedizierten Standalone-SLD-Systems. 

Flexibilität: Es ist einfach, Änderungen in ihrer Systemlandschaft zu planen und durchzuführen , z.B. ist es einfacher, die Ausfallzeiten eines eigenständigen Applikationssystems zu planen, da es keine SLD-Verfügbarkeitsanforderungen für andere Anwendungen mehr gibt, die man berücksichtigen muss.

Darüber hinaus können das SLD-System und die Systeme, die dieses SLD nutzen, verschiedene Releasestände haben. Anwendungen, die dieses SLD verwenden , werden nicht durch das Upgrade des entsprechenden SLD-Systems beeinträchtigt, da das SLD rückwärtskompatibel ist.

Verfügbarkeit: Abhängig von den Verfügbarkeitsanforderungen, die Sie an ein dediziertes SLD stellen würden, könnte ein Hochverfügbarkeits-Setup erforderlich sein.

Kosten: Sie müssen ein zusätzliches System betreiben und warten.

Voriger Post:

https://einsiedlerkreps.blogspot.com/2023/05/der-landschaft-management-prozess-das.html

Der Landschaft Management Prozess - das Big Picture

 Ihre IT-Landschaft besteht aus allen Einheiten, die für den Betrieb Ihres Unternehmens erforderlich sind. Je nach Bereitstellungsmodell handelt es sich dabei um Systeme oder Tenants, Server, Softwareprodukte usw.

Um Ihr Unternehmen am Laufen zu halten und Ihre Prozesse kontinuierlich zu verbessern, ändern sich sowohl Server/Mieter als auch Software ständig.

Wir können von drei Zuständen von IT-Landschaften sprechen:

=> Aktuell verwendete Version - hier läuft idealerweise ein Projekt, in dem die Landschaft analysiert wird, um Input für die Änderungsplanung zu liefern

=> Die nächste Version der Landschaft, die sich in der Phase der detaillierten Planung befindet, gefolgt von der Implementierung auf Systemebene. Oft werden "natürliche" Änderungen eingeführt, wie z. B. das nächste Support Package oder Enhancement Package.

=> Zukunftsvision der Landschaft zur Umsetzung Ihrer Strategie für die langfristige Planung oft mit grundlegenderen Veränderungen, wie z. B. den verwendeten Bereitstellungsmodellen.

Gerade hier ist es wichtig, grundlegend neue Optionen zu erkunden und Empfehlungen für die Umsetzung auf Landschaftsebene zu erhalten.

Der Landschaftsmanagementprozess hilft Ihnen, Ihre IT-Landschaft zu betreiben und weiterzuentwickeln:

=> Informationen über den Status Quo der IT-Landschaft als Grundlage für den Betrieb der Landschaft und die Planung von Änderungen an SAP-zentrischen Lösungen

=> Wege zur Veränderung Ihrer Landschaft umfassen Installationen, Updates, Upgrades und die Umstellung auf SAP S/4HANA und SAP BW/4HANA

=> Informationen, die für die Integration der von Ihnen abonnierten Software erforderlich sind

Die folgende Abbildung zeigt die Entwicklung der Landschaft und ihre Phasen:

Auf dem Bild sehen Sie eine Landschaft, die sich von einer reinen On-Premise-Landschaft zu einer hybriden Landschaft mit Cloud-Systemen entwickelt. Die Frage, wo die Schichten der Landschaft verlaufen und wer für welche Schichten verantwortlich ist, wird in Bereitstellungsmodelle und SAP-Angebote - On-Premise, Cloud und Hybrid beschrieben.

Die Schritte, um von einem Zustand der Landschaft zum nächsten zu gelangen, basieren auf dem Status quo, um die erforderlichen Änderungen zu finden, um die nächste Ebene zu erreichen. Ist diese erreicht, beginnt der Zyklus von neuem. Diese Iterationen sind natürlich nicht klar voneinander getrennt: Im nächsten Schritt wird die "neue Landschaft", die geplant wird, zu derjenigen, die Sie verwenden, und die nächste Stufe geht in die Phase der Detailplanung über.

Die für einen Zyklus der Planung und Umsetzung von Änderungen dargestellten Schritte werden von verschiedenen Personen in einem Unternehmen in unterschiedlichen Rollen ausgeführt. In diesem Dokument finden Sie die beteiligten Rollen und eine Liste der wichtigsten Komponenten und Werkzeuge, die sie für ihre Aufgaben benötigen.

Rollen, ihre Aufgaben, Werkzeuge und Einrichtungen im Landschaftspflegeprozess

An der Bewältigung der erforderlichen Veränderungen sind Menschen in unterschiedlichen Rollen beteiligt. Die wichtigsten Rollen in der Landschaftspflege sind aus den Bereichen:

Business

IT Architektur

Basis Administration

Entwicklung

Daher müssen Business, IT-Architektur und Basisadministration bei der Planung von Änderungen an der Unternehmenslandschaft eng zusammenarbeiten, um erforderliche Änderungen zu identifizieren, sie auf der Grundlage der aktuellen Landschaftsbeschreibung zu planen und zu bewerten und die Implementierung neuer oder zusätzlicher Softwareproduktversionen vorzubereiten.

Abbildung 2: Hauptrollen und ihre Aufgaben im Prozess der Landschaftspflege - das große Bild.

Das Bild beschreibt die am Landschaftsmanagementprozess beteiligten Rollen und ihre Aufgaben auf der Ebene der Funktionsbereiche: Geschäft, IT-Architektur, Basisverwaltung und Entwicklung.

Der innere Kreis beschreibt die Aufgaben in der bestehenden Landschaft, der äußere Kreis beschreibt die Phasen der Planung und Umsetzung von Änderungen.

Entitäten, Schritte und Werkzeuge im Detail

In diesem Abschnitt finden Sie Details zu den in den Abbildungen 3 und 4 gezeigten Elementen: Bereitstellungsmodelle, Landschaftsentitäten, Werkzeuge für beteiligte Rollen und Dienste in oder im Zusammenhang mit SAP Solution Manager werden erläutert.

Die Abschnitte sind als Aufgaben beschrieben und folgen einer "natürlichen" Abfolge, die vom Verstehen und Beschreiben hybrider Landschaften über die Suche nach neuen Optionen, deren Abbildung auf Ihre Bedürfnisse bis hin zur Definition einer neuen Landschaftsversion, dem Erhalt von Empfehlungen und der detaillierten Planung und Implementierung der Ergebnisse führt.

Projekt-Setup & Vorwissen

Die SAP Activate-Methodik wurde entwickelt, um Projektteams bei der Neuimplementierung oder Konvertierung etc. von SAP-Lösungen vor Ort oder in der Cloud-Umgebung zu unterstützen.

Über SAP Activate werde ich in einem weiteren Post berichten

Die Beschreibung Ihrer IT-Landschaft ist eine Voraussetzung für die Planung von Änderungen, deren Wartung und Überwachung.

Folgende Post’s soll Ihnen helfen, Ihre Landschaftsdaten besser zu handhaben, die eine Voraussetzung für den Betrieb von Geschäftsanwendungen, Systemen und Application Lifecycle Management-Prozessen gleichermaßen sind.

Analyse des Status Quo

Abrufen des Status Ihrer IT-Landschaft - Daten in SLD, LMDB, deren Verifizierung

Daten, die den aktuellen Status Ihrer Landschaft beschreiben, sind für die Verwaltung laufender Prozesse und die Planung von Landschaftsänderungen erforderlich.

Die Tools, die Daten, die Sie erhalten, und der Zweck, für den Sie sie verwenden müssen, hängen von den Bereitstellungsmodellen ab, die Sie in Ihrer Landschaft verwenden.

 Abrufen des Status Ihrer IT-Landschaft - Daten in SLD, LMDB, deren Verifizierung

h

Eine IT-Landschaft, die Systeme verschiedener Bereitstellungsmodelle mit Werkzeugen und Schritten des Landschaftsmanagementprozesses umfasst.

Ich werde versuchen , aufzuzeigen wie die verschiedenen Methoden, Tools und Werkzeugen helfen die Landschaftstransformation vorzunehmen.

Zukünftige Posts:

System Landscape Directory 

Solution Manager 

SAP Activate 

SRE - Kapazitätsplanung

 

Kapazitätsplanung ist die Kunst, die Zukunft vorauszusagen. Dabei geht es darum, herauszufinden, wie Sie ihre Sicht der Vergangenheit als Metrik auf die zukünftige Planung anwenden können. 

Die Kapazitätsplanung ist unglaublich wertvoll, denn die Kapazitätserweiterung kann ein langsamer und teurer Prozess sein, selbst angesichts der modernen Technologie. Da wir in der Hierarchie der Zuverlässigkeit immer weiter nach oben rücken, sprechen wir jetzt über die Zukunft. Wie planen wir sie, wie sieht sie aus, und wie bewerten wir die Risiken und Probleme, die auftreten können? 

Warum planen?

Der Grund für diese Planung und Vorbereitung liegt darin, dass es keinen Spaß macht, blindlings auf eine dunkle Straße zu rennen. Es mag die wahre Definition von Chaos sein, aber es ist vermeidbar .

Planung ist mühsam. Sie erfordert , dass Ihre Überwachungssysteme zuverlässig und umfassend sind. Sie erfordert ein gewisses Maß an Belastungstests. Sie erfordert Gespräche mit allen relevanten Personen im Unternehmen, von den Entwicklern, die den Code schreiben, über die Produktmanager und Führungskräfte , die die Ausrichtung des Unternehmens planen, bis hin zu den Vertriebsmitarbeitern (um den Strom der eingehenden Kunden zu verstehen und zu wissen,wie sich der Umfang des Produkts ändern wird) und den Finanzverantwortlichen, um zu verstehen, wie viel Geld wir haben und wie viel wir ausgeben können. 

Festlegen eines Plans

Die Ausarbeitung eines Plans besteht aus einer Reihe von Schritten. Jeder Schritt erfordert die Bewertung einer Frage, um die Antwort zu finden:

1. Wie hoch ist unsere derzeitige Kapazität?

Es gibt viele Möglichkeiten, die Kapazität Ihrer Infrastruktur zu bestimmen. Sie können aggregierte Metriken wie CPU-Nutzung , Festplattenspeicherverfügbarkeit, Anfragen pro Minute, Pakete pro Sekunde oder beliebige Anwendungsmetriken verwenden. Normalerweise sollten Sie sich auf die Ressourcen konzentrieren, die Sie am meisten nutzen oder die für Sie am wichtigsten sind. Was am wichtigsten ist, ergibt sich oft aus Ihren SLOs und den dahinter stehenden SLIs (Service Level Indicators). Beachten Sie, dass es sich bei den Kennzahlen nicht unbedingt um serverseitige Kennzahlen handeln muss. 

2. Wann wird unsere Kapazität erschöpft sein?

Sobald Sie über Metriken verfügen, die die aktuelle Kapazität definieren, besteht der nächste Schritt darin, herauszufinden, wann die Kapazität erschöpft sein wird. 

Sie fragen sich vielleicht , warum wir uns die Mühe machen, diese Vorhersage zu treffen, wenn wir wissen, dass user System nicht statisch ist und sich mit der Zeit verändern wird. Die Antwort auf diese Frage lautet, die Zukunft zu ignorieren. Wir können nur wissen , wie unser Dienst jetzt funktioniert. Wir sagen nicht voraus, wie wir unseren Dienst verändern oder wie wir mehr oder weniger effizient werden, sondern vielmehr, wo unser Dienst angesichts des derzeitigen Wachstums im Laufe der Zeit stehen wird.

Angesichts dieser Daten wird unser Ziel hoffentlich nicht darin bestehen, die Leistung zu verbessern, sondern eher darin, für das Wachstum zu planen. Das heißt nicht, dass wir keine Daten verwenden sollten, um zu entscheiden, ob wir die Leistung unseres Systems verbessern sollten, aber es ist eine schlechte Idee, die Hoffnung auf Leistungsverbesserungen an unsere Kapazitätspläne zu knüpfen. 

Einige hypothetische Beispiele dafür, warum dies eine schlechte Idee ist, sind:

=> Ihre neue Systemarchitektur verschlechtert die Leistung

=> Neue Funktionen verändern die Leistung drastisch

=> Niemand kann herausfinden, wie man die Leistung schnell verbessern kann

3. Wie sollten wir unsere Kapazität verändern?

Da wir nun einen groben Zeitplan haben, wann unsere Kapazität erschöpft sein wird, sollten wir einen Plan ausarbeiten, um dies zu verhindern. Es ist schwierig, darüber zu sprechen, weil sich die einzelnen Dienste in so vielen Punkten unterscheiden , aber wir können ein paar Dinge ansprechen, die Ihnen bei der Entscheidungsfindung helfen könnten.

Zunächst einmal geht es darum, wie man skaliert. 

4. Führen Sie den Plan aus

Wenn Ihr Plan solide ist und Sie die Genehmigung für das Geld erhalten haben, können Sie beginnen, ihn umzusetzen. Ich lege alle Schritte des Plans gerne als separate Tickets in einem Ticket Tracker ab und füge dann für jedes Ticket Ereignisse in meinen Kalender 

Architektur - woher die Leistungsänderungen kommen

Einer der häufigsten Gründe für drastische Leistungsänderungen sind Änderungen an der Infrastruktur. Man kann in den code eintauchen und Bugs finden oder tiefgreifende Untersuchungen zur Optimierung durchführen, aber in den meisten Fällen reicht es aus,  einen Cache an der richtigen Stelle zu platzieren oder eine Abhängigkeit zu entfernen, um die Leistung um Größenordnungne zu verbessern. Ein schnelles Beispiel wäre eine einfache Webanwendung, der ein Content Distribution Network (CDN) vorangestellt wird. Dies ermöglicht eine globale Zwischenspeicherung von Inhalten, wodurch die Belastung Ihrer eigentlichen Anwendungen verringert wird, vorausgesetzt, die Inhalte können tatsächlich zwischengespeichert werden.

Aufgrund dieser erheblichen Leistungsveränderung können Architekturentscheidungen auch dramatische Auswirkungen auf die Kapazitätsplanung haben. Es wird dringend empfohlen, dass Sie versuchen, in die Planungsphasen für Architekturänderungen einbezogen zu werden. Hierfür gibt es zwei Gründe:

1. Sie wissen genau, wie die Infrastruktur funktioniert und wie der Code darauf läuft. Aufgrund dieser Kenntnisse können Sie die Dinge im Planungsprozess oft aus einer neuen Perspektive betrachten.

2. Die getroffenen Entscheidungen können und werden sich wahrscheinlich darauf auswirken, wie viele Ressourcen für andere Systeme zur Verfügung stehen. Einige Architekturentscheidungen könnten sich dramatisch auf andere Systeme auswirken oder die kosten Ihrer Infrastruktur in einem Maße erhöhen, das Sie sich nicht leisten können.

Technik als Profitcenter und Beschaffung

Die Technik kan je nach Unternehmen als Profitcenter oder als Kostenstelle betrachtet werden. Wenn die Technologie das Produkt ist , das Sie verkaufen , ist Ihr Team in der Regel ein Profitcenter, und wenn die Technologie Ihrem Unternehmen zum Erfolg verhilft, sind Sie stattdessen eine Kostenstelle. Wenn dies Ihrem Team zu sehr unter die Nase gerieben wird, kann es sich wie eine Beleidugung anfühlen. Ingenieure sind Konstrukteure und kreative Typen, und manche fühlen sich vielleicht unmotiviert oder deprimiert, wenn sie als nicht integraler Bestandteil des Unternehmenserfolgs angesehen werden. Das ist völliger Unsinn, aber es kommt vor. Eine Möglichkeit, dies aus den Köpfen Ihres Teams zu verbannen, besteht darin, härter für ein größeres Budget zu kämpfen. Oft bemerken Ingenieure den Unterschied erst, wenn sie feststellen, dass sie Dinge, die sie gerne tun würden, nicht tun können, weil sie nicht im Budget enthalten sind. 

Fazit:

All dies ist für SRE wichtig, denn ein Mangel an Kapazität führt zu Serviceausfällen. Indem Sie mit Ihren Mitarbeitern zusammenarbeiten, können Sie Ihre langfristige Zuverlässigkeit verbessern, indem Sie einen Plan für künftige Ausfälle erstellen. Denken Sie daran, zunächst Ihre aktuelle Kapazität zu bestimmen, zu sehen, wie sie sich im Laufe der Zeit verändert, und sich dann Zugang zum Budget zu verschaffen, um sicherzustellen, dass Sie das prognostizierte Wachstum bewältigen können.

Vorige Themen:

https://einsiedlerkreps.blogspot.com/2023/05/sre-monitoring.html

https://einsiedlerkreps.blogspot.com/2023/05/sre-reaktion-auf-vorfalle-incident.html

https://einsiedlerkreps.blogspot.com/2023/05/sre-postmortems.html

https://einsiedlerkreps.blogspot.com/2023/05/sre-testen-und-freigeben.html

Auskopplung vom Post:

https://einsiedlerkreps.blogspot.com/2023/05/sre-die-nachste-stufe-von-devops-teil.html

SRE - Testen und Freigeben

 

Wenn es in den vorigen Posts um den Blick zurück ging geht es in diesem Kapitel um den Blick in die Zukunft.

Testen und Freigeben sind Prozesse, die oft früh in einem Projekt eingerichtet und dann vergessen werden. Bei Projekten, die lange dauern (z.B. Jahre), wird die Verbesserung des Freigabe- und Testprozesses oft ignoriert, bis eine Organisation viel größer ist und die Skalierung zu Problemen mit den bestehenden Prozessen führt. Die Verbesserung der Entwicklerwerkzeuge eines Teams kann die Produktivität und die Zufriedenheit der Entwickler steigern und die Veröffentlichung von Korrekturen für Probleme, die bei Zwischenfällen gefunden wurden, erleichtern.

Abgesehen davon sind sowohl das Testen als auch das Freigeben ein sehr umfangreiches Thema. Wir werden uns ihnen hauptsächlich unter dem Aspekt der Zuverlässigkeit nähern. Sie werden lernen, wie Sie in sie investieren können und wie Sie mit Ihren Teamkollegen zusammenarbeiten können, um sie zu wertvollen Werkzeugen zu machen.

Prüfung

Etwas zu testen bedeutet, zu überprüfen, ob es wie erwartet funktioniert. Man kann so gut wie alles testen, und in gewisser Weise ähnelt das Testen der in den Postmortems, erwähnten Analyse.Anstatt jedoch eine Hypothese aufzustellen, nehmen Sie etwas , von dem sie wollen, dass es existiert , schaffen es und überprüfen dann, ob das von Ihnen geschaffene Ding das tut, was Sie wollen.

Beachten Sie das berühmte Dijstra-Zitat: „Testen zeigt das Vorhandensein, nicht das Fehlen von Fehlern.“ Dies ist eine andere Art zu sagen, dass Sie , egal welche Hypothese Sie testen, nicht unbedingt andere Hypothesen entkräften.

Zu der fast garantierten Notwendigkeit, Software zu ändern, wenn sich ihre Definition und Anforderungen ändern, kommt die Tatsache hinzu, dass Softwaretests anfälliger sein können als die Software selbst. Eines der bekanntesten Probleme in der Informatik ist das „Halteproblem“. Es besagt, dass wir nicht wissen können, ob ein Programm bei einem zufälligen Programm und zufälligen Eingaben beendet wird oder für immer läuft. Es handelt sich dabei um ein halbwegs kompliziertes Stück mathematischer Theorie , aber im Grunde genommen gibt es keinen einzigen Test oder eine Funktion, mit der man beweisen kann, ob ein Programm beendet werden kann. Man kann einen Test für ein einzelnes Programm schreiben, aber man kann nicht einen Test für jedes Programm schreiben. Alan Turing bewies dies 1936 in seiner Arbeit On Computable Numbers

Als einzelner Entwickler hat man häufig das Gefühl , dass man niemanden braucht, der seinen Code versteht. Sie können den gesamten Code, den Sie geschrieben haben, in Ihrem Kopf behalten. Sie haben den Großteil des Codes geschrieben, mit dem Sie eine Schnittstelle bilden, und Sie wissen, wie der Code verwendet wird, so dass der wahrscheinlich nicht kaputtgehen wird. Diese Annahme ist nicht falsch. Kleinere Projekte oder Funktionen werden oft von Einzelpersonen bearbeitet, aber dieser Glaube setzt zwei Dinge versus - dass Sie der Einzige sind , der an diesem Stück Code arbeitet, und dass Sie im Laufe der Zeit nicht vergessen werden, was Sie getan haben. 

Software wird zu 20% erstellt und zu 80% gewartet wird. Wahrscheinlicher ist, dass sie von der Idee des Pareto-Prinzips herrührt, das besagt, dass 20% der Ursachen 80% der Wirkungen hervorrufen. 

Freigabe von

Die Freigabe ode Bereitstellung ist der Vorgang, bei dem ein Haufen Code genommen, gebündelt und an die Benutzer verteilt wird. Es kann viele Formen annehmen, vom Kopieren vieler einzelner Dateien auf einen laufenden Server über die Erstellung eines Pakets und dessen Veröffentlichung in einem Repository, das die Benutzer herunterladen können, bis hin zur Erstellung eines physischen Mediums, das per Post verschickt wird. Die Art und Weise , wie Software in diesen Zustand gebracht wird, hat sich im Laufe der Jahre dramatisch verändert. Als Software noch auf physischen Datenträgern ausgeliefert wurde, bezeichnete man die Software als „Gold“, und das war die Version die an den Kunden verschickt wurde. Heutzutage ist es üblich, Software auf einem Server freizugeben oder verschiedene Möglichkeiten zu nutzen, um Iterationen des Codes aus der Ferne an die Benutzer zu übermitteln. Dadurch wird die Häufigkeit der Freigabe erhöht und die Zeit, die wir für jede einzelne Version aufwenden, verringert. Das Zeil ist nicht mehr die perfekte Version , sondern eine gute Version, damit wir weiter iterieren und das Produkt weiterentwickeln können.

Rollbacks

Ich habe Rollbacks bisher ein paar Mal erwähnt, ohne sie wirklich zu beschreiben. Ein Rollback ist die Rückgängigmachung einer Version. Je schneller und einfacher ein Rollback ist , desto mehr Risiko können Sie mit Ihren Veröffentlichungen eingehen. Denn wenn es einen einzigen Kopf gibt, den jemand drücken kann, um zu einer bekannten, funktionierenden Version zurückzukehren, kann jemand, der in Bereitschaft ist, einfach diesen Knopf drücken , wenn er etwas Schlechtes sieht und später Fragen stellen. Dies ist nicht immer möglich. Wenn Ihr Bereitstellungsprozess nur darin besteht, einige Dateien per sync auf einen Server zu übertragen, ist es oft schwieriger, diese Dateien auf eine korrekte Version zurücksetzen. Wenn Sie sich mit dem Hochladen von Dateien begnügen müssen, empfehle ich Ihnen , Ihre  Versionskontrollsoftware auf dem Server zu installieren und bei der Freigabe einen Tag auszuhecken. Auf diese Weise werden alle Dateien auf die korrekte Version geändert.

Achten Sie nicht nur darauf , dass Ihre Rollbacks schnell sind, sondern auch darauf , dass Sie Ihre Rollbacks testen. Dies ist dem Testen von Datenbanksicherungen sehr ähnlich, wenn Sie ihren Prozess nicht testen, ist es gut möglich , dass er genau dann abbricht , wenn Sie ihn am meisten brauchen. Sie brauchen jedoch nicht nur zu testen, um sicherzustellen, dass Ihre Rollbacks funktionieren. Wenn Sie ein Rollback durchführen, müssen Sie eine Validierung durchführen, als ob Sie gerade freigegeben hätten, denn das haben Sie im Grunde getan.

Welche Fragen müssen wir uns stellen?

Was macht eine gute Version aus?

Wie können wir uns auf das verlassen, was wir liefern?

Wie können wir sicherstellen, dass wir bei der Bereitstellung nichts kaputt machen?

Woher wissen wir , ob die Version funktioniert hat?

Um sicherzustellen, dass der Build und die Verteilung konsistent und stabil sind, muss die Veröffentlichung in der Regel drei Eigenschaften aufweisen:

=> Wiederholbar

Wiederholbar ist eigentlich die umstrittenste dieser drei Möglichkeiten. Wiederholbare Builds bedeuten, dass derselbe Code, wenn er zweimal erstellt wird, genau die gleiche Ausgabe liefert. Traditionell waren nur sehr wenige Builds auf diese Weise, was bedeutete , dass zwei Personen, die den gleichen Code erstellten, nicht beide den den Hash der Ausgabe nehmen und vergleichen konnten. Dies war vor allem aus Sicherheitsgründen problematisch. Man kann nicht garantieren, dass man die richtige Binärdatei hat und dass sie nicht manipuliert wurde, wenn man nicht sagen kann, dass sie den richtigen Hash hat. Dies ist einfacher , wenn man nur Code kompiliert , da die meisten Compiler durchgängig die gleiche Binärdatei ausgeben. Es ist viel schwieriger, wenn Sie etwas wie ein Debian-Paket, ein Docker-Image oder ein Amazon Machine Image erstellen. Das liegt daran, dass oft Schritte erforderlich sind, um aktuelle Abhängigkeiten zu erhalten oder  Dateien zu schreiben, die sich mit der Zeit ändern. Es ist nicht unmöglich und das Debian-Team hat große Anstrengungen unternommen, um jeden Debian-Build deterministisch und reproduzierbar zu machen. Sie können überprüfen, ob ihr Build  reproduzierbar ist, indem Sie ihn auf zwei verschiedenen Systemen erstellen und eine Prüfsumme (z.B. SHA256) der Ausgabe vergleichen. Sie sollten gleichwertig sein, wenn sie auf ähnliche Weise erstellt wurden (zum Beispiel auf zwei verschiedenen Linux-Maschinen).

=> Getestet

Getestet ist ziemlich einfach. Sie wollen sicherstellen, dass Ihre Tests erfolgreich sind und dass sie tatsächlich etwas testen. Eine der Gefahren dabei ist die Ehrfurcht vor „grün“. Grün bedeutet, dass Ihre Tests alle bestanden haben. Wenn Ihre Tests nicht viel testen, dann bedeutet ein grüner Build gar nichts. Das ist ein guter Ausgangspunkt, aber es bedeutet auch, dass Sie wahrscheinlich nicht deployed sollten, wenn Ihr Build grün ist, wenn grün keine große Bedeutung hat. Wir werden bald über die Verifizierung einer Veröffentlichung sprechen, aber weniger Tests im Vorfeld bedeuten in der Regel mehr Validierung nach der Veröffentluchung.

=> Idempotisch

Idempotent ist dem Wiederholbar sehr ähnlich, konzentriert sich aber mehr auf die Bereitstellungs- und Verteilungsphase einer Version und weniger auf den Build-Aspekt. Idempotent ist ein Begriff aus der Mathematik, der besagt, dass die Operation bei mehrfacher Ausführung dasselbe Ergebnis liefert.  Dies ist Wege der Skalierung wichtig. Sie benötigen ein  Einsatzsystem, das unabhängig vom Zustand des eingegebenen Systems immer dasselbe System ergibt. Wenn Sie beispielsweise mit drei Servern beginnen, auf denen die Version 1.0.0 Ihres Codes läuft, und Sie 1.1.0 bereitstellen, erwarten Sie, dass sie alle 1.1.0 erhalten. Wenn Sie dann das System erweitern müssen, sollte derselbe Prozess in der Lage sein, einen leeren Server in den Zustand von 1.1.0 zu versetzen. 

Der Sinn von idempotent ist jedoch, dass Sie , wenn Sie das Deployment-Skript jede Stunde über einen Server laufen lassen, den Server immer in denselben Zustand versetzen würden, egal was passiert. Idempotenz ist die Grundlage für die meisten Konfigurationsmanagement-Tools wie Chef und Ansible, da ihr Ziel darin besteht, ein System in einem beliebigen Zustand in einen identischen Endzustand zu versetzen.

Wann soll freigegeben werden?

Wir haben bereits früher die Idee eines SLO erwähnt - wir müssen nicht einmal einen Dienst haben, der immer in Ordnung ist. 

Freigabe für die Produktion

Der nächste und letzte Schritt ist die Produktionsumgebung. Die Produiktionsumgebung ist die Umgebung, in der die Dienste laufen, mit denen die Benutzer tatsächlich kommunizieren. Während jede andere Umgebung jederzeit freigegeben werden kann, müssen Sie bei der Produktionsumgebung die Risiken berücksichtigen. 

Automatisierung

Die Automatisierung von Freigaben und Tests ist eine häufige Aufgabe. Beide umfassen in der Regel viele Schritte, so dass die Schaffung eines konsistenten Ortes und einer konsistenten Methode für die Durchführung von von Tests und Freigaben die allgemeine Zuverlässigkeit verbessern kann. Andernfalls könnte ein Build oder Test jedes Mal auf einem anders konfigurierten Rechner stattfinden und unbekannte Variable einbringen. Eine unvollständige Konfiguration , nicht in der richtigen Reihenfolge ausgeführte Schritte oder falsch eingegebene Befehle haben schon so manchen Ausfall verursacht, so dass die Automatisierung dieses Prozesses von großem Wert ist.

Die Automatisierung von Tests und Freigaben erfordert in der Regel die Automatisierung von drei Dingen:

=> Bauen: Die eigentliche Erstellung eines Artefakts aus dem Quellcode

=> Testen: Validierung des erstellten Artefakts

=> Verteilen: Versenden des Artefakts an den Benutzer

Automatisierung gibt es, weil die Menschen vergesslich sind. Alle drei Dinge können mit ähnlichen Tools automatisiert werden. Fast alle diese Tools sind im Wesentlichen Job-Runner, die auf einer Ereigniswarteschlange laufen. Diese Warteschlange kann durch Aktionen gefüllt werden, z.B. durch Code , der in ein Versionskontroll-Repository übertragen wird, oder durch das Klicken auf eine Schaltflächen. Die Warteschlange kann auch mit zeitabhängige Ereignissen gefüllt werden, z.B. mit einem stündlichen Ereignis zur Ausführung von Integrationstests. 

Das Wichtigste ist, dass sie ihre Tests und Veröffentlichungen automatisieren. Es wird ein Notfall eintreten, und Sie müssen eine schnelle Korrektur durchführen, oder jemand Neues muss eine Bereitstellung durchführen und weiß nicht, was er tun soll.

Durch die Automatisierung dieser Schritte können Sie dafür sorgen, dass die betreffende Person lediglich ein Ereignis auslösen muss sich dann zurücklehnen kann, um zu sehen, was passiert.

Kontinuierlich 

Es gibt viele Wörter , die man gerne hinter „kontinuierlich“ setzt, und oft führen sie zu Diskussionen. In der Regel sind damit nur die drei Schritte gemeint , die oben im Abschnitt Automatisierung beschreiben wurden. Manche nennen das Ganze Continuous Integration, so nennen sich die meisten dieser Job-Runner-Dienstleister. Begriffe, die alle sehr ähnlich zu sein scheinen sind:

=> Kontinuierliche Integration

=> Kontinuierliche Freigabe

=> Koninuierliche Bereitstellung

=> Einsatz bei Grün

Der übergreifende Punkt ist, das die Dinge getestet, erstellt und geliefert werden, und das alles mit Automatisierung. Einige Systeme fügen menschliche Kontrollen in die Pipelines ein. Einige ermöglichen automatische Rollbacks, wenn Probleme auftreten. Bei einigen müssen Schaltflächen angeklickt oder Testbedingungen erfüllt werden. Es ist wichtig sich nicht in Diskussionen verstricken zu lassen sondern sich darauf zu konzentrieren , den Arbeitsablauf zu finden, der für Ihr Unternehmen am besten geeignet ist, und das Risiko zu minimieren, mit dem Ihre Mitarbeiter einverstanden sind.

Nichtsdestotrotz kann jede dieser Ideen und ihre feinen Unterschiede nützlich sein. 

Kontinuierliche Integration bedeutet, dass bei jedem Commit eine Reihe von Tests durchgeführt werden sollte, um festzustellen, ob der Code Fehler enthält oder nicht.

Continuous Deployment ist die Idee , dass jeder Commit automatisch in die Produktion überführt wird. 

Die kontinuierliche Bereitstellung ist ähnlich, konzentriert sich aber auf die Idee , dass die gesamte Bereitstsellung automatisch erfolgt, sobald Sie sich für die Bereitstellung von Code entscheiden.

Deploy on green ist die Idee , dass die kontinuierliche Bereitstellung immer dann erfolgen sollte , wenn die Tests erfolgreich sind.

Vorige Themen:

https://einsiedlerkreps.blogspot.com/2023/05/sre-monitoring.html

https://einsiedlerkreps.blogspot.com/2023/05/sre-reaktion-auf-vorfalle-incident.html

https://einsiedlerkreps.blogspot.com/2023/05/sre-postmortems.html

Auskopplung vom Post:

https://einsiedlerkreps.blogspot.com/2023/05/sre-die-nachste-stufe-von-devops-teil.html

SRE - Postmortems

 

Was ist ein ein Postmortem?

Ein Postmortem ist die Durchführung einer Retrospektive nach einem Servicevorfall.

Je nach Organisation hat eine Postmortem-Analyse viele Bezheichnungen:

Retrospektive , Ursachenanalyse (RCA), Vorfallbesprechung und andere. Es geht darum , ein Dokument zu erstellen, in dem festgehalten wird, warum ein Vorfall passiert ist, und mit den Beteiligten zu besprechen, was passiert ist.

Der Begriff „Postmortem“ wird in der Regel mit medizinischen oder juristischen Berufen in Verbindung gebracht. Das Oxford English Dictionary definiert ihn als „Untersuchung eines toten Leichnahms zur Feststellung der Todesursache“. Diese Definition ist der Grund dafür, dass viele Menschen in der Softwarebranche den Begriff „postmortem“ verwenden. Manche betrachten Softwareprozesse als Lebewesen, und wenn ein Prozess anhält, wird er als tot bezeichnet. Diejenigen, die die Idee, einer Maschine Leben zuzuschreiben, problematisch finden,  verwenden oft die Begriffe Incident Review oder RCA. Unabhängig von der verwendeten Bezeichnung besteht das Ziel darin, ein historisches Artefakt zu erstellen und den Vorfall, der sich ereignet hat, zu diskutieren.

Warum ein Postmortem schreiben ?

Die Erstellung eines Postmortem-Dokuments ist der richtige Zeitpunkt , um herauszufinden, was passiert ist. Wie ist der Prozess abgestürzt? Welcher Teil des Systems verursachte die Instabilität? Wie lange nach Beginn des Vorfalls haben wir dies bemerkt?

Warum sind andere Systeme ausgefallen?

Wir führen eine Postmortem-Untersuchung getrennt vom ursprünglichen Vorfall durch, um gründlich und sorgfältig vorgehen zu können. Wir müssen sicherstellen , dass uns alle Daten vorliegen und wir das Problem vollständig beheben können. Bei einem Zwischenfall fließt of das Adrenalin und es werden schnelle Bauchentscheidungen getroffen. Das liegt daran, dass nur sehr wenig Zeit zum Nachdenken und Abwägen von Entscheidungen bleibt. Wenn wir die Analyse und die Nachforschungen erst im Nachhinein durchführen, können wir mit mehr Leuten sprechen, stehen nicht unter dem Stress des Ausfalls und haben mehr Zeit, eine kalkulierte Entscheidung zu treffen. Auf der Grundlage dieser Analyse können wir beschließen, ein Dokument zu erstellen, in dem wir unsere Erkenntnisse zusmmenfassen und den Vorfall mit unseren Teamkollegen teilen. Um einen Postmortem zu verfassen ist auf jeden Fall eine Analyse erforderlich . Sie müssen wissen , warum etwas fehlgeschlagen ist. 

Die Entscheidung ein Dokument zu erstellen, ist optional , aber ein Bericht ist nutzlos , wenn Sie den Vorfall nicht analysieren und herausfinden , was passiert ist.

Ein Postmortem ist auch ein historisches Dokument. Es ist sehr wahrscheinlich , dass Sie nicht ewig für eine Organisation arbeiten werden und dass es in Ihrer Organisation Mitarbeiter geben wird, die nicht an dem Vorfall oder dem ausgefallenen Dienst beteiligt waren. In einem Postmortem-Dokument können Sie festhalten, was passiert ist, wie Sie das Problem gelöst haben und was Ihr Team daraus gelernt hat.

Wann ist ein Postmortem-Dokument zu erstellen?

Eine Frage, die oft gestellt wird, wenn mit Dokumentationen von Postmortem in einer Organisation begonnen wird, lautet: „Soll ich einen Postmortem schreiben?“ Es gibt viele verschiedene Möglichkeiten, wie Organisationen entscheiden, wann ein Postmortem geschrieben werden soll, aber ich habe eine einfache Regel, die ich gerne befolge: Wenn jemand nach einem Postmortem fragt, sollte man eines schreiben. In einer großen Organisation funktioniert das hervorragend , denn oft wird jemand fragen:“Was hatte es mit dem Vorfall von gestern Abend auf sich?“ oder „Wird es einen Postmortem für den Ausfall von gestern Abend auf sich?“ oder „Wird es einen Postmortem für den Ausfall von letzter Woche geben?“ Dies sind Anzeichen dafür , dass ein Dokument erstellt werden sollte.

In einer kleineren Organisation ist das schwieriger , weil Sie oft selbst entscheiden, ob Sie den Vorfall dokumentieren sollten. Um festzustellen, ob dies der Fall ist, könnten Sie eine interne Kennzahl entwickeln. Zum Beispiel: „Wenn wir mehr als 10 Minuten für die Wiederherstellung gebraucht haben, sollten wir einen Postmortem schreiben. 

Man sollte sich eine genaue Metrik ausdenken, um eine Postmortem zu schreiben. Die Metrik hat zwei Aspekte:

1, Wenn der Vorfall zweimal innerhalb weniger Tage auftritt, solle ich einen Postmortem schreiben.

2. Wenn es einen Ausfall länger als 30 Minuten gibt , sollte ein Postmortem geschrieben werden.

Ich verwende diese Metrtiken , weil sie dem Schweregrad entsprechen.

Es gibt kleinere Vorfälle aufgrund von Fehlern , Nachlässigkeit oder anderen Dingen. Bei der Geschwindigkeit , mit der wir arbeiten, können wir nicht alles aufhalten und dokumentieren, aber die Vorfälle, die diese Messwerte erreichen, scheinen die gleiche Art von Vorfällen zu sein, die eine größere Anzahl von Personen betreffen. 

Durchführung von Ereignisanalysen

Die Analyse von Vorfällen ist kompliziert. Sie sollten das System wie ein paranoider Sherlock Holmes angehen. Beginnen Sie am Tatort und gehen Sie dann jedem Aspekt auf den Grund. Seien Sie vorsichtig mit Ihren vorgefassten Meinungen, achten Sie auf  Ablenkungsmanöver und überprüfen Sie stets Ihre Hypothesen.

Der Tatort eines Ausfalls ist oft das , was Sie zurückgesetzt haben. Das kann eine fehlerhafte Konfiguration oder ein fehlerhafter Code sein. Wurde der Ausfall durch die Änderung verursacht, die ihr Team zu implementieren versuchte, oder durch ein System, das mit diesem Code interagiert? Dann können Sie damit beginnen , den geänderten Code oder den Code, der mit dem von Ihnen bereitgestellten Code interagiert, durchzulesen. Wenn es keinen Rollback gab, haben Sie das Problem wahrscheinlich schon herausgefunden, da Sie es während des Vorfalls herausfinden mussten, um das Problem zu lösen, sofern es sich nicht von selbst gelöst hat. Wir haben noch nicht über das Reverse Engineering von Systemen gesprochen, das oft ein wichtiges Werkzeug ist, also lassen Sie uns das genauer betrachten.

Beim Reverse Engineering geht man von einem System aus und findet heraus , wie es funktioniert, indem man mit ihm interagiert und sieht, wie es auf Eingaben reagiert. Wenn ich ein System habe, über das ich nichts weiß und niemanden dazu befragen kann (weil er schläft, nicht mehr arbeitet oder aus einem anderen Grund), beginne ich damit, mir anzusehen , wie die Dinge mit ihm interagieren. 

Versuchen sie ein Flow-Diagramm zu erstellen. Denken Sie daran , dass das Ziel nicht darin besteht, die Software vollständig zu verstehen, sondern herauszufinden, wie sie das tut, womit Sie Probleme haben. Ruft sie andere externe oder interne unterstützende Dienste auf? Speichert sie Daten? Kann sie diese beiden Dinge tun? Gibt es Kommentare, und stimmen Sie mit dem überein , was der Code tatsächlich tut? Wenn Sie dies herausgefunden haben, können Sie ein Systemdiagramm erstellen, in dem entweder die Funktionen doer die Dienste zusammenwirken.

Wie man ein Postmortem-Dokument verfasst

Der Vorfall ist passiert, und Sie haben beschlossen, ein Postmortem-Dokument zu verfassen. Sie haben Ihre Analyse gemacht. Was schreiben Sie hinein? Meine grobe Vorlage sieht in der Regel wie folgt aus: Zusammenfassung, Auswirkungen, Zeitleiste, Grundursache,Aktionspunkte und Anhang. 

Fügen Sie am Anfang des Dokuments die Namen der beteiligten Personen, das Datum des Vorfalls und das Datum der letzten Änderung des Dokuments ein. Wenn Sie ihre Postmortems in einem Online-System speichern, können Sie Schlüsselwörter oder Tags hinzufügen, um das Dokument zu Organisierung.

=> Zusammenfassung

Der erste Abschnitt sollte eine Zusammenfassung sein. Das bedeutet, dass jeder der dieses Dokument öffnet, eine ungefähre Vorstellung davon. Haben sollte, was passiert ist, wann es passiert ist und wer betroffen war. In der Regel handelt es sich um eine kurze Erklärung,

=>Auswirkungen

Ich nehme diesen Abschnitt nicht immer auf, aber er ist hilfreich, wenn es darum geht, wie der Kundendienst reagieren soll oder ob es irgendwelche externen Auswirkungen des Ausfalls geben wird. Der Abschnitt über die Auswirkungen ist ein guter Platz, im die Kunden zu beschreiben, die von dem Ausfall betroffen waren, alle öffentlichen Nachrichten über den Ausfall, eine Diskussion darüber, wie sich der Ausfall auf die SLA Ihres Dienstes ausgewirkt hat, und vielleicht ein oder zwei Grafiken. Sie können auch Statistiken über die Zeit bis zur Wiederherstellung oder die Reaktionsgeschwindigkeit des  Bereitschaftsdienstes einfügen, wenn Ihr Unternehmen daran interessiert ist, diese Daten zu messen.

Es ist wichtig, dass die Leser des Postmortem die Auswirkungen des Vorfalls verstehen, die nicht nur aus fehlgeschlagenen Anfragen, fehlgeschlagenen Aufträgen oder anderen technischen Fehlern resultieren. 

=> Zeitleiste

Dieser Abschnitt gefällt mir sehr gut, da er eine minutengenaue Erklärung des Geschehens liefert. Jede Zeile besteht aus einem Zeitstempel und einer Beschreibung. In der Beschreibung bieten Links zu Codeänderungen, Zeitleisten für Ereignisse und die Bereitstellung von Diensten zusätzliche Einblicke und Details zu dem Dokument. 

=> Grundlegende Ursache

Die Ursachenforschung ist wahrscheinlich der wichtigste Abschnitt eines Postmortem. Er beschreibt , was den Ausfall verursacht hat. Die vorherigen Abschnitte beschreiben, was passiert ist oder wie es passiert ist, aber nicht warum. Wenn wir zukünftige Ausfälle verhindern wollen, müssen wir wissen , warum sie passiert sind. 

=> Aktionspunkte 

Aktionspunkte sind eine liste von Maßnahmen, die nach dem Vorfall zu ergreifen sind, in der Regel mit angehängten Tickets oder einem Tracking. Tickets sind gut , weil sie die Verantwortlichkeit und die Prioritäten für die Behebung des Problems festlegen. Aktionspunkte stellen sicher, dass eine Gruppe von Personen daran arbeitet, einen erneuten Ausfall zu verhindern, und es ist wichtig, dass die Verantwortlichkeit gegeben ist. Unabhängig davon, wie das Problem aufgetreten ist, sollte das Team zusammenarbeiten, um sicherzustellen, dass es nicht noch einmal auftritt.

=> Anhang

Der Anhang ist der Abschnitt, in dem Sie alle mit diesem Vorfall zusammenhängenden Dinge hinzufügen. Das Hinzufügen von Chatprotokollen, relevanten Dienstprotokollen, Screenshots, Grafik, externen URLs ist.

Der Anhang ist genauso nützlich wie die Zeitleiste - er gibt Aufschluss darüber , wie Sie zu den Ursachen gelangt sind, und bietet visuelle Darstellungen, die den Text ergänzen. Der Anhang ist auch deshalb wichtig , weil die heute verwendeten Instrumente in Zukunft  vielleicht nicht mehr zur Verfügung stehen werden und die Daten selten für immer in der gleichen Qualität überwacht werden können. 

Durchführung einer Postmortem-Sitzung

Eine Postmortem-Sitzung ist die Folgemaßnahme zum Dokument. Dabei werden häufig die Maßnahmen abgeschlossen, die Ergebnisse der Ursachenforschung erörtert und ein sicherer Rahmen für die Diskussion geschaffen. Zu einer Postmortem-Besprechung werden in der Regel am besten diejenigen eingeladen, die an dem Vorfall beteiligt waren - der technische Leiter der betroffenen Dienste, der Produktmanager für die betroffenen Dienste und alle interessierten Techniker. Es ist schwierig, das richtige Gleichgewicht zu finden, denn wenn die Besprechung zu groß ist, wird nicht viel erreicht, aber wenn die Besprechung zu klein ist, wird das Wissen nicht gut weitergegeben.

Es ist ein gute Idee, dass die am Vorfall Beteiligten anwesend sind, da sie wissen, was passiert ist, falls Daten in dem Dokument fehlen. Die technischen Leiter der betroffenen Dienste sollten anwesend sein, falls Annahmen über ihre Dienste gemacht werden, die nicht der Wahrheit entsprechen, und die Verantwortung übernehmen, um sicherzustellen, dass die Maßnahmen umgesetzt werden. Die Produktmanager der betroffenen Dienste sind wichtig, da sie helfen können, die geschäftlichen Anforderungen in Bezug auf den Dienst zu beschreiben und mit den technischen Leitern zusammenzuarbeiten, um sicherzustellen, dass die Korrekturen nach Priorität geordnet werden. Um den Wissentransfer zu fördern,ist es wichtig , interessierten Personen die Teilnahem zu ermöglichen.

Der Incident Commander des Vorfalls sollte die Besprechung leiten. Er schreibt zwar nicht immer den gesamten Postmortem, kennt sich aber oft am besten mit dem Ereignis und den Beteiligten aus und kann die Konversation leiten. Eröffnen Sie die Sitzung mit einer Erklärung, in der Sie diejenigen, die das Dokument nicht gelesen haben, auffordern, sich von der Sitzung zu entschuldigen oder sich bereit erklären, nicht teilzunehmen. Der Gedanke dahinter ist, dass diejenigen , die das Dokument nicht gelesen haben, Fragen stellen oder Erklärungen abgeben werden, die möglicherweise bereits in dem Dokument beantwortet werden. Die Sitzung sollte sich nicht an diejenigen richten, die sich nicht die Zeit nehmen konnten, sich über den Vorfall zu informieren, um einen größeren Lerneffekt zu erzielen. Versuchen Sie anschließend, sich an die folgende Tagesordnung zu halten:

=> Ein kurzer Zeitplan und eine Zusammenfassung des Vorfalls:

Dies sollte nicht länger als fünf Minuten dauern. Denken Sie daran, dass jeder das Dokument bereits gelesen hat und dies eher dazu dient, die Informationen aufzufrischen udn auf besonders bemerkenswerte Fakten hinzuweisen. Sie müssen nicht jede Minuten aufzählen, sondern nur grobe Züge nennen.

=>Erörterung der Grundursache: 

Dies ist in der Regel der variabelste Abschnitt, da die Menschen manchmal nicht verstehen, wie die Ursache überhaupt möglich gewesen sein könnte. Dies ist auch ein Bereich, in dem Menschen defensiv werden können, wenn sie sich angegriffen oder beschuldigt fühlen. 

Versuchen Sie, die Diskussionen zivilisiert zu führen und alle Schuldzuweisungen auf die Zsammenarbeit zu lenken, da wir alle für den Erfolg des anderen verantwortlich sind. Achten Sie auch darauf, dass Sie sich nicht zu sehr in Diskussionen darüber verlieren , wie eine Lösung für die Grundursache gefunden werden kann. Wenn es keine offensichtliche Lösung gibt, sollte eine Folgesitzung für die Entwicklung einer Lösung anberaumt werden, die ein Aktionspunkte sein sollte.

=> Fragen: 

Dieser Abschnitt wird oft in den vorherigen Abschnitt übergehen, aber Sie können die Teilnehmer dazu auffordern, Fragen vorab einzureichen, wenn es sich um eine große Gruppe handelt, oder alle Bedenken, die die Teilnehmer haben könnten, durchgehen.

Diskussion der Aktionspunkte: 

Die vorangegangenen Diskussionen haben möglicherweise zusätzliche Aktionspunkte hervorgebracht; stellen Sie also sicher, dass alle Aufgaben ordnungsgemäß dokumentiert sind. Wenn Sie einen Fehlerverfolgungsdienst haben, stellen Sie sicher, dass die Fehler protokolliert und mit dem Dokument verknüpft werden. Stellen Sie außerdem sicher, dass jemand für die Fehelr verantwortlich ist. Wir wollen niemanden beschuldigen, aber wir wollen sicherstellen, dass Fehelrbehebungen auch umgesetzt werden. Eines der ärgerlichsten Gefühle ist die Teilnahme an mehreren Postmortems, die alle die gleichen Aktionspunkte haben, aber niemand sorgt dafür, dass die Korrekturen durchgeführt werden.

Dieser Zeitplan eignet sich hervorragend für größere Organisationen. 

In kleineren Organisationen ist es oft sinnvoll, weniger formell zu sein und schneller vorzugehen. In diesen Fällen gefällt mir eine schnelle Diskussion über einen Postmortem oder einen Vorfall:

=> Was hat funktioniert? 

Gehen sie durch den Raum und bitten Sie jede Person, bis zu drei Dinge aufzulisten, die während des Vorfalls funktioniert haben.

=> Was hat nicht funktioniert?

Lassen Sie jede Person sagen, was ihrer Meinung nach nicht gut funktioniert hat.

=> Was sollten wir anfangen zu tun? 

Bitten Sie diesmal die Teilnehmer , eine Sache aufzulisten, mit der das Team ihrer Meinung nach beginnen sollte. Dies ist oft ein guter Weg , um die Prioritäten von Maßnahmen festzulegen oder neue Maßnahmen zu entwickeln.

=> Was sollten wir nicht mehr tun?

Konzentrieren Sie sich stattdessen darauf , was das Team nicht mehr tun sollte.

=> Was sollten wir verbessern?

Gehen Sie schließlich herum und konzentrieren Sie sich auf die Dinge , die Sie verbessern wollen.

Analyse frühere Postmortems

Wenn alles gesagt und getan ist , ist es gut , zurück zu gehen und die vergangenen Postmortems zu überprüfen. Sammeln Sie einmal im Quartal oder einmal im Jahr alle Postmortems und versuchen Sie , einige Metriken zusammenzustellen. Diese Metriken können Ihnen Aufschluss darüber geben, wie Ihr Team auf Vorfälle reagiert:

=> Zeit bis zur Wiederherstellung

=> Zeit zwischen Ausfällen

=> Anzahl der ausgelösten Warnmeldungen im Vergleich zu den erstellten Postmortems

=> Anzahl der Ausschreibungen pro Bereitschaftsdienst-Rotation

MTTR und MTBF

Außerhalb von Zwischenfällen sind zwei Kennzahlen, über die oft gesprochen wird, die mittlere Zeit bis zur Wiederherstellung (MTTR) und die mittlere Zeit zwischen Ausfällen (MTBF). Ein Blick auf diese Zahlen über ein Jahr hinweg kann zeigen, wie sich Ihre Fähigkeit, auf Zwischenfälle zu reagieren, verbessert oder verändert.

Beachten Sie, dass das Ziel darin besteht, die Zeit bis zur Widerherstellung zu minimieren, nicht unbedingt die Zeit, bis die Ursache des Ausfalls behoben ist. Wenn die MTBF niedrig ist, kann das bedeuten, dass Ihr Team nicht genug in Tests investiert, und das belastet wahrscheinlich, dass Ihr Team nicht weiß, wie es auf  Vorfälle reagieren soll, oder dass die Werkzeuge für Rollbacks und andere Wiederherstellungsmaßnahmen schlecht oder langsam sind.

Meldungsmüdigkeit

Es ist wichtig für die Gesundheit der Mitarbeiter, herauszufinden, wie viel Prozent der Warnmeldungen umsetzbar waren. Anhand einer historischen Aufzeichnung von Alarmen, die zu Postmortems wurden, von Alarmen pro Rotation und von umsetzbaren Alarmen können Sie feststellen, ob die Responder überfordert sind und ob sie von wichtigen Dingen unterbrochen werden. Wenn Sie Techniker haben, die wissen, dass sie jedes Mal um drei Uhr morgens geweckt werden, wenn sie auf Abruf bereitstehen, bleiben sie vielleicht nicht lange dabei oder hören einfach auf zu reagieren.

Vergangene Ausfälle besprechen

Sobald Sie Daten über Ihre vergangenen Postmortems und Ausfälle gesammelt haben, sollten Sie sie mit dem Team teilen. Nach der Weitergabe der Daten kann es sinnvoll sein, Einzelgespräche zu führen oder eine Teamsitzung abzuhalten, in der die Mitarbeiter ihre Bedenken über den aktuellen Zustand der Störungsreaktion mitteilen. Manchmal hat das Team ein gutes Gefühl , während es in anderen Fällen das Gefühl hat, dass etwas fehlt - vielleicht zu viele Warnungen, schlechte Überwachung oder das Gefühl, dass die Behebung von Ausfällen nicht mir der nötigen Priorität behandelt wird.

Voriges Thema:

https://einsiedlerkreps.blogspot.com/2023/05/sre-monitoring.html

https://einsiedlerkreps.blogspot.com/2023/05/sre-reaktion-auf-vorfalle-incident.html

Auskopplung vom Post:

https://einsiedlerkreps.blogspot.com/2023/05/sre-die-nachste-stufe-von-devops-teil.html