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

SRE - Reaktion auf Vorfälle (Incident Response)

 

Während die Einführung des Monitorings hauptsächlich eine technische Übung ist, besteht die Reaktion auf Vorfälle fast ausschließlich aus Prozessen und Menschen. Die Reaktion auf Vorfälle baut auf der Datenwelt auf, die wir mit der Überwachung aufgebaut haben, und setzt eine Feefback-Schleife in Gang, die uns hilft, die Überwchung unserer Dienste zu finden und zu verbessern. Das zeigt uns, worauf es ankommt, denn wenn wir keine Warnung erhalten und uns jemand mitteilt, dass unser Dienst nicht funktioniert , dann haben wir nicht die richtigen Dinge überwacht.

Was ist ein Vorfall?

Ein Zwischenfall liegt vor, wenn etwas Bedeutendes passiert, das Sie dazu zwingt, Ihren Weg und ihre normalen Handlungen zu ändern.

In der Softwarebranche können Zwischenfälle ähnlich verlaufen. In der Regel handelt es sich um einen Fehler, der auf eine Änderung im System (entweder im System selbst oder in den Eingaben, die das System erhält) oder auf eine Änderung in der Umgebung, in der das System läuft, zurückzuführen ist. Das System selbst ändert sich in der Regel durch die Bereitstellung von Code oder durch eine Änderung des Umgangs, in dem das System arbeitet.

Die Tatsache dass die Welt aus ständigem Chaos besteht, bedeutet, dass der Wandel aus jeder Richtung kommen kann. Zwischenfälle sind oft der Beweis dafür, dass wir Menschen nicht allmächtig sind. Wir schreiben die Software und wissen nicht alles, so dass Ereignisse eintreten, die wir nicht eingeplant haben, was oft dazu führen kann, dass die Software auf eine Art und Weise agiert, die uns nicht zusagt.

Was ist die Reaktion auf Vorfälle?

Die Reaktion auf einen Vorfall besteht in der Regel aus einer Reihe von Maßnahmen:

=> Bemerken, dass etwas nicht in Ordnung ist.

=> Kommunizieren, dass etwas nicht in Ordnung ist

=> Etwas tun, um die Dinge in Ordnung zu bringen

Alarmierung

Die Alarmierung ist ein umstrittene Thema. Es ist umstritten, weil niemand gewarnt werden möchte. Eine Warnung ist eine Warteschlange , die sie zur Arbeit zwingt. 

Wann sollten Sie sich melden?

Dies alles führt zu der Frage, wann man Alarm schlagen sollte. Was ist die Abfrage, die jemanden dazu zwingt, benachrichtigt zu werden, dass etwas nicht in Ordnung ist? Wir beginnen mit dieser Frage und nicht mit der Frage, wen wir benachrichtigen oder wie wir benachrichtigen, weil die Frage bei Monitoring  gestellt worden ist ob der Dienst funktioniert.

Wenn die Antwort auf diese Frage oft nein lautet, dann sollte dies die ernsthafteste aller Warnungen hervorrufen. Sie wollen, dass jemand Bescheid weiß und reagiert. Oft bedeutet dies, dass ein Kunde betroffen ist. Unter einem schwerwiegenden Vorfall verstehe ich in der Regel etwas, das ein Kunde sieht und das ihn dazu veranlasst , sich mit uns in Verbindung zu setzen, weil unser Produkt defekt ist. 

Wie das Monitoring ist auch die Alarmierung eine Sache , die sich ständig ändert. Hüten Sie sich davor, zu oft zu alarmieren, da Sie damit die Wirksamkeit für die Empfänger der Warnung verringern. Es ist eine ständige Bewertung erforderlich , um sicherzustellen, dass die Warnmeldungen nützlich sind und dass richtig darauf reagiert wird.

Wie schlagen Sie Alarm?

Sobald Sie festgelegt haben, wann Sie eine Warnung ausgeben wollen , müssen Sie entscheiden , wohin die Warnungen gehen und wie sie die Personen erreichen sollen.

Sie können sie auf viele Arten versenden. Einige gängige Möglichkeiten zur Benachrichtigung von Personen sind:

=> Ein Anruf

=> Eine SMS

=> Eine spezielle App , die laute Geräusche macht

=> Eine Gruppenchat-Nachricht

=> Eine E-Mail

=> Eine laute Sirene in einem Büro

Einige Übermittlungsmethoden sind besser als andere. Die Wahl der Übermittlungsmethode hängt von der Häufigkeit und Lautstärkke Ihrer Warnungen ab und auch davon, wie die Menschen auf eine Warnung reagieren sollen. Bei einem kleinen Software-Startup würde eine laute Sirene wahrscheinlich dazu führen, dass alle kündigen, aber bei einer Software, die einen Atomreaktor betreibt, ist eine laute Sirene vielleicht keine schlechte Idee.

Es gibt unterschiedliche Systeme für die Alarmierung. Der Schlüssel zu all diesen Systemen ist, ein System zu finden, das erschwinglich und zuverlässig ist und das von den Empfängern der Warnmeldungen auch gelesen wird. Wenn niemand auf Ihrer Arbeit seine E-Mails liest, dann schicken Sie ihm auch keine Warnmeldungen.

Wie schon bei den Monitoringsystemen erwähnt, handelt es sich auch bei den Warnsystemen um Software, die nicht immer zuverlässig ist. Wie zuverlässig sie sind, hängt von Ihnen und Ihrem Team ab. Wie gefährlich ist es, wenn eine Meldung Sie nicht erreicht? Sie können Ihre Alarmierungstools diversifizieren, um die Wahrscheinlichkeit zu erhöhen, dass ein Alarm zugestellt wird. Das Nachrichtensystem könnte so eingerichtet werden, dass bei einem Ausfall einer Nachricht eine andere für den Ausfall einspringen kann. Es kommt ganz darauf an, was man wählt , aber oft arbeiten Warnsysteme mit „Master Election“ oder „Leader Election“. Dabei handelt es sich um einen Prozess, der in der Regel auf den Paxos- oder Raft-Algorithmen aufbaut und bei dem eine Reihe identischer Server darüber entscheidet , wer die Führungsrolle übernimmt und die eigentliche Arbeit erledigt.

Was gehört in eine Warnmeldung?

Das erste, woran man denken sollte , ist der Anfangstext. Dies ist oft der Betreff der E-Mail, die erste Nachricht in einem Chat oder die Kopfzeile der Warnmeldung. Er sollte kurz und beschreibend sein.

Tim Pope, ein Software-Entwickler in der Vim Open-Source-Gemeinschaft, hat einige Formatierungsvorschläge für Commit-Nachrichten in Git, einem Versionskontrollsystem, die auch für Alerts sinnvoll sind. Die meisten seiner Ratschläge sind sehr spezifisch für Git, aber es gibt einige Dinge, die wir mitnehmen können und die sehr nützlich sind:

=> Die Betreffe sollten weniger als 50 Zeichen umfassen. So lässt sich schnell erkennen, warum die Person ausgeschrieben wird.

=> Verwenden Sie den Imperativ. Dies ist vor allem deshalb wichtig, weil Sie oft Anweisungen geben wollen, was zu tun ist, wenn dieser Fehler auftritt. Zum Beispiel: „ Gehen Sie zur AWS-Konsole und beenden Sie die Instanz i-1234567890“.

=> Geben Sie eine zusätzliche Erklärung nach dem Betreff. Wenn Ihr Alarmierungsdienst dies zulässt, fügen Sie Live-Details wie Diagramme oder Auswertungen von Metriken hinzu. Fügen sie auch Links zu Dokumentationen ein, die für die Person, die auf die Warnmeldung reagiert , nützlich sein könnten.

Wen alarmieren Sie?

Jetzt , da wir leicht verständliche Warnmeldungen versenden, müssen wir entscheiden, wer unsere Warnmeldungen erhalten soll. Erinnern Sie sich, dass Warnmeldungen ein umstrittenes Thema sind?

Der Grund dafür ist, dass viele Menschen zwar eine Benachrichtigung wünschen, aber nicht die Person sein wollen, die die Benachrichtigung erhält.

Eine Warnung ist per Definition ein Störfaktor. Die Notwendigkeit, auf einen Zwischenfall zu reagieren, ist nur selten etwas, von dem man weiß, dass es kommt, so dass man gezwungen ist, alles sofort zu unterbrechen. Oft ist die Reaktion auf einen Zwischenfall auch kein Hauptbestandteil der Arbeit einer Person, so dass diese auch Fristen verschieben und ihre Arbeit unterbrechen muss.

Voriges Thema:

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

Auskopplung vom Post:

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

SRE - Monitoring

 

Monitoring wird im Wörterbuch definiert als „den Fortschritt oder die Qualität (von etwas) über einen bestimmten Zeitraum beobachten und überprüfen; systematisch überprüfen“. 

Diese Definition weist auf zwei auf zwei entscheidende Details hin: 

Erstens müssen Sie definieren, was Qualität ist, und sicherstellen, dass Ihr System Fortschritte in Richtung einer Qualitätsgrenze macht oder innerhalb dieser Grenze bleibt. 

Zweitens müssen Sie bei dieser Arbeit systematisch vorgehen - sie sollten Ihr System nicht wahllos überprüfen.  Stattdessen sollte ihr Ansatz konsequent sein. Die Notwendigkeit systematischer Messungen ist ein Grund dafür, dass Ihr Zahnarzt sie bittet , alle sechs Monate in die Sprechstunde zu kommen.

Hier befassen wir uns mit den Werkzeugen oder der Methodik zur Überwachung moderner Webdienste. Wir werden Überlegungen besprechen , welche Daten zu sammeln sind, wie man diese Daten sammelt, wie man sie speichert und wie man diese Daten für Entwickler und andere nützliche Personen anzeigt.

Warum Monitoring?

Jeder sagt, man solle regelmäßig zum Arzt gehen, aber warum sollte man das tun?

Was sind die Vorteile? Auf der einen Seite soll der Arzt Anzeichen für Dinge zu erkennen, auf die man selbst nicht unbedingt achtet oder die man selbst nicht bemerkt.. Das zweite ist mit den Arzt zu besprechen was einem selbst aufgefallen ist. Zum Beispiel , wenn ich häufig Magenbeschwerden habe.

Diese Beispiele sind ein guter Vergleich für die zwei verschiedenen Arten der Überwachung, die Software häufig benötigt. Die erste Art sind Metriken und die zweite sind Protokolle. Bei Metriken handelt es sich in diesem Fall um Zahlenmessungen. Traditionell konzentrierten sich Metriken auf Leistungszahlen, wie den Prozentsatz des belegten Speicherplatzes , die Anzahl der empfangenen Pakete oder die CPU-Auslastung. 

Sammeln und Speichern von Überwachungsdaten

Überwachungstools kann man in zwei Kategorien einzuteilen. Das ist oft eine Vereinfachung dieser Systeme , aber es hilft mir, ihre Funktionsweise zu verstehen. Diese beiden Kategorien sind Polling-Anwendungen und Push-Anwendungen.

Polling-Anwednungen

Polling-Anwendungen (auch Pull-Anwendungen genannt) holen Daten von einem Dienst ab und speichern und zeigen sie dann an. Einige Beschwerden gegen Polling-Anwendungen lauten, dass man alle Dienste, die man abruft, aufzeichnen muss. Gegen Polling. Anwendungen ist nicht einzuwenden, aber man sollte darüber nachdenken: 

Folgende Tool‘s sollen hier aufgezählt werden:

Nagios

Prometheus

Cacti

Sensu

Push-Anwendungen:

Push-Anwendungen sind die Umkehrung von Pull-Anwendungen. Anstatt dass die Überwachungsanwednung Metriken von den Diensten erhält, schreiben die Diensten an die Überwachungsanwendung Metriken von den Diensten erhält, schreiben die Dienste an die Überwachungsanwendung. Oft gibt es einen zwischengeschalteten Dienst, der die Metriken übersetzt oder aggregiert, bevor er sie an die zentrale Pberwachungsanwendung sendet. Einer der Kritikpunkte an Push-Anwendungen ist, dass es zu Problemen kommen kann, wenn viele Dienste gleichzeitig an sie schreiben. An Push-Anwendungen ist jedoch nichts auszusetzen - sie haben nur eine andere Architektur. Wei die Polling Anwendungen verwenden viele sehr große und auch sehr kleine Unternehmen Push-Anwendungen, und sie sind genauso effektiv.

Folgende Tools werden hier aufgezählt:

StatsD

Telegraf

ELK

Anzeige von Überwachungsinformationen

Nachdem Sie nun Ihre Daten gesammelt und gespeichert haben, können Sie damit beginnen, sie den Benutzern anzuzeigen. Viele der zuvor erwähnten Überwachungsprogramme bieten eigene Visualisierungssysteme an. Ein beliebtes Open-Source-Tool für diesen Zweck ist Grafana.

Unabhängig davon, was Sie für die Visualisierung und den Zugriff auf ihre Metriken verwenden, gibt es vier Kategorien von Tools, die häufig genutzt werden.

Beliebe Abfragen

Diagramme

Dashboards

Chatbots

Beliebige Abfragen

Jeder braucht die Möglichkeit , eine Abfrage der von Ihnen erstellten Metriken und Protokolle zu erstellen. Der Grund dafür ist ziemlich einfach: Metriken sind nutzlos, wenn Menschen keinen Zugang zu ihnen haben.

Diagramme

Diagramme werden meist zu visuellen Darstellung von Daten im Zeitverlauf verwendet. 

Die klassischen Regel für ein Diagramm lauten wie folgt:

=> Die x-Achse (der untere Edge des Diagramms) enthält die Zeit

=> Es muss einen Schlüssel geben für das, was grafisch dargestellt wird.

=> Alle Achsen müssen beschriftet sein

=> Alle Zahlen müssen Einheiten haben

Dashboards

Dashboards sind eine Sammlung von Diagrammen, die in der Regel alle um einen bestimmten Zeitraum herum synchronisiert werden. Es gibt eine Menge Philosophien und Meinungen darüber, was ein gutes Dashboard ausmacht. Sollte ein Dashboard auf einem Fernseher angezeigt werden? 

Wenn Sie Dashboards für sich selbst oder für Ihr Team entwerfen, finden Sie hier einige Vorschläge und Dinge, die Sie beachten sollten:

=> Wen Sie ein Armaturenbrett auf einem Fernseher anbringen wollen, achten Sie darauf, dass es nur wenige Grafiken enthält und aus großer Entfernung ablesbar ist. Wenn Sie quer durch den Raum laufen müssen, um zu sehen, was vor sich geht, erfüllt es wahrscheinlich nicht seine Aufgabe.

=> Wenn Sie können, erstellen Sie eine mobilfreundliche Version Ihres Dashboards. Immer mehr Techniker prüfen Ausfälle und Diagramme zuerst auf ihrem Handy, bevor sie einen Laptop herausholen.

=> Einige Leute schlagen vor, dass Sie Ihre Dashboards auf jeweils fünf Diagramme beschränken sollten. Ich habe oft Dashboards, die viel mehr als das enthalten. Ich schlage daher vor, die ersten drei Diagramme auf die wichtigsten Informationen über einen Dienst zu beschränken. Auf diese Weise können Sie sich beim ersten Laden der Seite auf die wichtigsten Informationen konzentrieren. Ein guter Trick ist es, Links zu anderen Dashboards einzurichten. Wenn Sie ein Diagramm über den Netzwerkverkehr haben, sollten Sie darunter Links zu Dashboards mit weiteren Details über das Netzwerk einfügen, falls das Diagramm zeigt, dass etwas nicht stimmt.

Chatbots

Chatbots , die Diagramme bereitstellen, sind kein obligatorischer Bestandteil der Überwachungsinfrastruktur , aber im Laufe der Jahre haben sie sich zu einer meiner Lieblingsmethoden entwickelt, um eine Untersuchung zu beginnen oder ein Problem zu untersuchen. Sie bieten eine schnelle Momentaufnahme und sind oft sehr nützlich in Gesprächen mit Mitarbeitern über Ausfälle, insbesondere wenn nicht alle im selben Raum sind oder man eine Aufzeichnung des Gesprächs haben möchte.

Verwaltung und Pflege von Überwachungsdaten

Die Speicherung ist in der Regel der Knackpunkt bei den Monitoring-Werkzeugen.

Das liegt daran, dass man sich oft nicht bewusst ist, wie viele Daten man sammelt und wie schnell der Speicherplatz aufgebraucht sein kann. Wenn Sie nur über eine begrenzte Menge an Speicherplatz verfügen und viele Dinge überwachen, werden Sie irgendwann anfangen müssen, Daten zu löschen. Die beiden gängigsten Methoden dafür sind Stickproben und Archivierung . In der Regel sieht das so aus , dass sich die Granularität der Daten ändert, je weiter man in die Vergangenheit zurückgeht, oder dass das Überwachungssystem Daten von einer langsameren Datenquelle abrufen muss, wenn sie eine bestimmte Zeit in der Vergangenheit liegen. 

Auskopplung vom Post:

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

SRE - die nächste Stufe von DevOps Teil III

 Ist SRE (Site Reliability Engineering)  die nächste Stufe von DevOps?

Die Antwort auf diese Frage lautet: SRE bildet eine Brücke zwischen DEV und OPs. 

Eine logische nächste Frage wäre in diesem Fall: Ist eine Brücke notwendig? 

Wir werden feststellen das es nicht ausreich, Entwickler und Betrieb in ein Team zu stecken. Es gibt einen natürlichen Interessenskonflikt. Ein Unternehmen muss also mehr tun, um die Vorteile der Arbeit im DevOps-Modus wirklich zu nutzen. Genau das tut SRE.

Die Schlüsselthemen von SRE sind Zuverlässigkeit, Skalierbarkeit, Verfügbarkeit, Leistung, Effizienz und Reaktion. 

Diese sind in sieben architekturrelevant Grundsätze integriert , die dem SRE Workbook entnommen sind:

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

=> Der Betrieb ist ein Softwareproblem: Dies ist der Ausgagnspunkt von SRE.

Software wird sich ändern, aber der Betreib muss stabil bleiben, damit die Dienste nicht unterbrochen werden. Das bedeutet, dass die Software belastbar sein und intensiv getestet werden muss.

=> Arbeiten Sie nach Service-Level Objectives (SLOs): Setzen Sie klare Ziele für den Dienst. Wie hoch sollte die Verfügbarkeit einer Anwendung wirklich sein? Dies sind nicht nur IT-bezogene Ziele . In erster Linie geben die Geschäftsanforderungen die Parameter vor. Das bedeutet , dass die Projekte eng mit den Geschäftsinteressenten zusammenarbeiten müssen, um die Ziele zu definieren.

=> Arbeiten, um die Arbeitsbelastung zu minimieren: Wir werden noch weiter über Arbeit sprechen, aber im Prinzip bedeutet Arbeit nur Arbeit. Außerdem ist Arbeit manuelle Arbeit, die durch Automatisierung vermieden werden kann. Im Grunde besteht das Ziel von SRE darin, Computer die Arbeit so weit wie möglich für Sie erledigen zu lassen.

=> Automatisieren: Nach Grundsatz drei ist dieser logisch. Wenn Sie es automatisieren können , tun Sie es.

=> Schnell scheitern: Fehlschläge sind in Ordnung, solange sie in einem sehr frühen Stadium entdeckt werden. Die Behebung des Problems in diesem frühen Stadium entdeckt werden. Die Behebung des Problems in diesem frühen Stadium hat weitaus geringere Auswirkungen, als wenn es zu einem späteren Zeitpunkt im Entwicklungs- und Bereitstellungszyklus entdeckt und behoben wird. Außerdem führt das frühzeitige Erkennen und Beheben von Problemen zu geringeren Kosten.

=> Jedes Teammitglied ist ein Eigentümer: Dieser Punkt erfordert etwas mehr Erklärung, insbesondere in großen Unternehmen, in denen wir in der Regel eine Matrixorganisation haben. Denken Sie daran, dass viele Unternehmen mit Sourcing-Modellen arbeiten, bei denen bestimmte Lieferanten für die Infrastruktur (die Plattform) und andere Lieferanten und das Unternehmen selbst für die Anwendung (die Produkte) verantwortlich sind. Bei SRE gibt es diese Grenzen nicht. Sowohl die Produkt- als auch die Plattformteams teilen sich die Verantwortung für das Endprodukt. Daher müssen die Produkt- und Plattformteams die gleiche Sicht auf jede Komponente haben:

Anwendungsmöglichkeit, Frontend-Systeme, Backend-Infrastruktur und Sicherheitsregeln. Sie sind alle gleichberechtigte Eigentümer des Projekts. 

=> Verwenden Sie einen Werkzeugsatz: Alle Teams verwenden die gleichen Tools. Sie können mehrere SRE-Teams haben, aber sie arbeiten alle mit denselben Tools. Der Grund dafür ist, dass ein Unternehmen zu viel Zeit mit der Verwaltung der verschiedenen Toolsets verbringen muss, anstatt sich auf die Projektergebnisse zu konzentrieren. Und bei SRE geht es vor allem um Konzentration.

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

SRE-Architektur mit KPI‘s

Bevor wir uns mit der Definition von KPIs befassen, müssen wir auf die Grundprinzipien von SRE zurückkommen. SRE-Teams konzentrieren sich auf Zuverlässigkeit, Skalierbarkeit,Verfügbarkeit, Leistung, Effizienz und Reaktion. Dies alles sind messbare Größen, die wir in KPIs umwandeln können.

Die wichtigsten KPIs , die wir in SRE verwenden, sind die folgenden:

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

=> SLOs: In SRE wird damit definiert, wie gut ein System sein sollte. Ein SLO ist viel präziser als ein SLA, das eine Vielzahl verschiedener KPI umfasst. Man könnte auch sagen, dass das SLA eine Reihe von SLOs umfasst. Ein SLO ist jedoch eine Vereinbarung zwischen den Entwicklern im SRE-Team und dem Product Owner des Dienstes, während ein SLA eine Vereinbarung zwischen dem Dienstanbieter und dem Endbenutzer ist. Die SLO ist ein Zielwert. Zum Beispiel sollte das Eb-Frontend in der Lage sein, Hunderte von Anfragen pro Minute zu verarbeiten. Machen Sie es am Anfang nicht zu komplex. Durch die Festlegung dieses SLO hat das Team bereits eine Reihe von Herausforderungen, um dieses Ziel zu erreichen, da es nicht nur das Frontend betrifft , sondern auch den Durchsatz z.B. im Netzwerk und in den beteiligten Datenbanken. Mit anderen Worten: Durch die Festlegung dieses einen Ziels haben die Architekten und Entwickler eine Menge zu tun, um dieses Ziel zu erreichen.

=> SLIs: SLOs werden durch SLIs gemessen. Bei SRE gibt es einige Indikatoren, die wirklich wichtig sind: Anfragelatenz, Systemdurchsatz, Verfügbarkeit und die Fehlerquote. Dies sind die wichtigsten SLIs, die messen, wie gut ein System wirklich ist. Die Anfragelatenz misst die Zeit , bis ein System eine Antwort zurückgibt. Der Systemdurchsatz ist die Anzahl der Anfragen pro Sekunde oder MInute. Die Verfügbarkeit ist der Zeitraum, in dem ein System für den Endbenutzer nutzbar ist. Die Fehlerquote ist der prozentuale Anteil an der Gesamtzahl der Anfragen und der Anzahl der Anfragen, die erfolgreich zurückgegeben werden.

=> Fehlerbudget: Dies ist wahrscheinlich der wichtigste Begriff in SRE. Die SLO definiert auch das Fehlerbudget. Das Budget beginnt bei 100 und wird durch Abzug der SLO berechnet. Wenn wir zum Beispiel ein SLO haben, das besagt, dass die Verfügbarkeit eines Systems 99,9% beträgt, dann ist das Fehlerbudget 100-99,9 = -0,1. Dies ist der Spielraum, den die SRE-Teams haben, um Änderungen vorzunehmen, ohne die SLO zu beeinträchtigen. Dies zwingt die Entwickler im SRE-Team, entweder die Anzahl der Änderungen und Freigaben zu begrenzen oder so viel wie möglich zu testen und zu automatisieren, um eine Unterbrechung des Systems und eine Überschreitung des Fehlerbudgets zu vermeiden.

Um das Konzept des Fehlerbudgets in SRE zu verstehen, ist es wichtig zu wissen, wie SRE die Verfügbarkeit von Systemen behandelt . Es geht nicht einfach darum, die Ausfallzeit abzuziehen, um die Verfügbarkeit von Systemen zu erreichen. SRE berücksichtigt auch fehlgeschlagene Anfragen.  Eine fehlgeschlagene Anfrage kann darauf zurückzuführen sein, dass ein System nicht oder nur langsam antwortet. Die Erkennung fehlgeschlagener Anfragen bestimmt die Verfügbarkeit und damit, ob das Fehlerbudget überschritten wird oder nicht. Wichtige Parameter sind folgende:

=> TTD: Die Zeit bis zur Erkennung eines Problems in einer Software oder einem System.

=> TTR: Die Zahl zur Lösung oder Reparatur des Problems

=> Häufigkeit/Jahr: Die Fehlerhäufigkeit pro Jahr.

=> Benutzer: Die Anzahl der Benutzer, die von dem Fehler betroffen sind.

=> Schlecht/Jahr: Die Anzahl der Munuten pro Jahr, in denen ein System nicht nutzbar ist, oder die schlechten Minuten pro Jahr.

Implementierung von SRE

Bislang haben wir und angesehen , was SRE ist und was die wichtigsten Elemente sind. Wie bei DevOps lautet der Rat, klein anzufangen. Es gibt zwei wichtige Schritte , die helfen SRE auf kontrollierte Weise zu implementieren

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

=> Einigen Sie sich auf Standards und Praktiken: Dies kann nur für ein SRE-Team oder für das gesamte Unternehmen gelten, wenn der Ehrgeiz so groß ist. 

Dies kann ein praktikabler Ansatz für Unternehmen mit einer begrenzten Anzahl von Anwendungen sein, aber für Unternehmen ist es vielleicht sinnvoller, mit einer SRE-Team-Charta zu arbeiten. Lassen Sie uns mit einem sehr gängigen Beipiel arbeiten. Unternehmen haben in der Regel Produktteams, die an Anwendungen arbeiten, und ein Plattformteams, das für die Infrastruktur zuständig ist. Es ist eine gute Praxis , ein SRE-Team zu haben, das eine Brücke zwischen einem Produktteam und dem Plattformteams schlägt und Standards und Praktiken für diesen speziellen Bereich festlegt. 

Das Produktteam konzentriert sich auf die Bereitstellung der Anwendung und arbeitet natürlich eng mit dem Plattformteams zusammen. Das SRE-Team kann dies lenken und Standards für die Zuverlässigkeit des Endprodukts festlegen. Das bedeutet , dass SRE-Teams mehrere Bereiche abdecken müssen.

Google nennt drei Einstiegskriterien, um mit SRE zu beginnen:

=> Die SLOs wurden definiert und mit den Geschäftsinhabern vereinbart.

=> Es können tadellose Obduktionen durchgeführt werden.

=> Das Unternehmen verfügt über einen Prozess zur Verwaltung von Produktionsproblemen. Dabei kann es sich um den Standardprozess für das Incident Management handeln, wie er in IT Service Management Frameworks wie ITIL definiert ist.

Wo setzt SRE an und wie beginnen die Teams ihre Arbeit?

=> SRE-Spezialisten werden im UNternehmen eingestellt oder geschult.

=> Freigabeprozesse werden dokumentiert und von SRE-Spezialisten bewertet.

=> Betriebliche Prozesse werden dokumentiert, einschließlich Runbooks für Freigaben und Übergabe an den Betrieb. Diese Prozesse werden von SRE-Spezialisten evaluiert.

=> Es wurden SLOs definiert und vereinbart.

=> SRE-Teams sind beauftragt, Prozesse anzupassen und zu implementieren , die den Arbeitsaufwand verringern. Die Zusammenarbeit mit den Entwicklern und dem Betrieb , die zu einem Buy-in führt , ist eine Voraussetzung.

SRE-Teams können dies für alle neuen und bestehenden Prozesse tun:

=> SLO und Überprüfung des Fehlerhaushalts

=> Bewertungen von Vorfällen

=> Test- und R-unhook-Überprüfungen

=> Sicherheitsprüfungen

Bevor das Team jedoch wirklich loslegen kann, muss die Organisation klare Prioritäten setzen. Wie wir gelernt haben, wird SRE einen Kulturwandel auslösen, und die gesamte Organisation muss die Einführung von SRE unterstützen. 

Die Idee der Pyramide ist, dass die Elemente am unteren Ende die Grunlagen sind, die zuerst implementiert werden müssen; sie bilden das Fundament. Von dort aus schreitet die Umwandlung zu fortgeschritteneren Elementen voran, wie z.B. Die Freigabekette bei der Entwicklung und Bereitstellung neuer Produkte an der Spitze der Pyramide.

Die Unternehmen von heute befinden sich in einem ständigen Wandel. Das setzt den Betrieb stark unter Druck, der einerseits mit den Entwicklungen Schritt halten muss und andererseits die Systeme stabil und zuverlässig halten muss. Ohne echte Zusammenarbeit zwischen Entwicklern und Betrieb ist das praktisch unmöglich. SRE geht die Herausforderung an. SRE hat erkannt, dass es das Problem nicht löst, wenn Entwickler und Betrieb in einem Raum zusammensitzen. SRE schafft eine Lösung, die betriebliche Probleme reduziert, indem sie Entwicklern hilft, zuverlässige Systeme zu erstellen. 

Die wichtigsten Komponenten sind folgende:

=> Standardisierung: Standardisierung von Prozessen und Werkzeugen.

=> Automatisierung: Automatisierung führt zu Konsistenz, aber Automatisierung ermöglicht auch Skalierung. Dies erfordert eine sehr gut durchdachte Architektur. Bei der Automatisierung geht es darum, etwas einmal zu tun und dann den Rest der Automatisierung zu überlassen. Ohne Automatisierung würde der Betrieb einfach in manuellen Aufgaben ertrinken.

=> Beseitigen Sie mühsame Arbeit: Arbeit ist manuelle , sich wiederholende Arbeit, die automatisiert werden kann. Aber Arbeit ist auch Arbeit, die keinen Mehrwert für das Produkt schafft: Sie unterbricht und verlangsamt die Entwicklung von Dienstleistungen, die einen Mehrwert schaffen.

=> Einfachheit: Als Voraussetzung für ein stabiles , zuverlässiges System muss die Software einfach sein. Der Code muss einfach und sauber und die APIs so minimal wie möglich sein. SRE lebt nach der goldenen Regel „weniger ist mehr“.

Die hier in der Grafik aufgeführten Themen dienen zur Vertiefenden Beschäftigung mit SRE.

Post‘s  werden folgen

Von unten nach oben  dargestellt in der Grafik

Monitoring 

Reaktion auf Vorfälle (Incident Response)

Postmortems 

Testen und Freigeben

Kapazitätsplanung

Dev

UX

Zugehörige Post‘s:

Erster Teil: 

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

Zweiter Teil: DevOps:

https://einsiedlerkreps.blogspot.com/2023/05/devops-nahere-erlauterung-teil-ii.html

In-Memory Data Management Teil I

 Die Zukunft von Enterprise Computing

Es stellt sich die Frage ob ein neues Datenbank-Management-System wirklich notwendig ist. Die Antwort lautet: Ja! Moderne Unternehmen haben sich dramatisch verändert. Unternehmen basieren auf Informationen mehr als je zuvor. 

Es gibt zwei dominierende Anforderungen an ein modernes Datenbank-Management-System:

=> Daten aus verschiedenen Quellen müssen in einem einzigen Datenbank-Management-System kombiniert werden.

=> Diese Daten müssen in Near- Echtzeit analysiert werden , um eine interaktive Entscheidungsfindung zu unterstützen.

Die folgenden Anforderungen an ein neues Enterprise-Datenbank-Management-System  leiten sich von den Anforderungen für moderne Unternehmen ab.

Verarbeitung von Ereignisdaten

Ereignisdaten beeinflussen Unternehmen heute mehr und mehr. Sie zeichnen sich durch folgende Eigenschaften aus:

=> Jeder Ereignisdatensatz ist im Vergleich zur Größe traditioneller Unternehmensdaten, wie beispielsweise allen Daten, die in einem einzigen Kundenauftrag enthalten sind , klein (einige Bytes oder Kilobytes).

=> Verglichen mit der Menge an Entitäten ist die Anzahl der erzeugten Ereignisse pro Enität hoch, z.B. werden hunderte oder tausende Ereignisse für ein einzelne Produkt erzeugt.

Im Folgenden werden einige Anwendungsfälle von Ereignisdaten in modernen Unternehmen kurz vorgestellt.

Sensordaten

Heutzutage werden Sensoren eingesetzt, um die Funktion einer zunehmenden Anzahl von Systemen zu überwachen. Ein Beispiel ist das Tracking und Tracing von sensiblen Gütern wie Arzneimitteln, Kleidung oder Ersatzteilen. Dabei werden Pakete mit Radio-Frequency Identification (RFID)-Tags oder zweidimensionalen Barcodes, sogenannten QR-Codes, ausgestattet.

Tracking von Arzneimitteln

In Europa werden jährlich ca. 15 Milliarden verschreibungspflichtige Arzneimittel produziert. Diese werden an wichtigen Stellen in der Lieferkette getrackt. Das Tracking der Arzneimittelpackungen führt zu ca. 8.000 Leserereignismeldungen pro Sekunde.  Die In-Memory - Technologie ermöglicht Rückverfolgung von 10 Milliarden Ereignissen in weniger als 100 ms.

Formel-1-Rennwagen

Auch Formel-1-Rennwagen produzieren ein Übermaß an Sensordaten. Diese Sportwagen sind mit bis zu 600 Sensoren ausgestattet, die jeweils hunderte von Ereignissen pro Sekunden aufzeichnen. Abhängig von der Granularität der Datenaufzeichnung werden bei einem zweistündigen Rennen Sensordaten im Giga-oder Terabyte-Bereich erzeugt und erfasst. Die Herausforderung besteht darin, die gewonnenen Daten während des Rennens zu erfassen, zu verarbeiten und zu analysieren, um die Fahrzeugparameter sofort zu optimieren, um beispielsweise Bauteilfehler zu erkennen, den Kraftstoffverbrauch oder die Höchstgeschwindigkeit zu optimieren.

Analyse von Spiel-Ereignissen

personalisierte Inhalte in Online-Spielen sind ein Erfolgsfaktor für die Spiele-Industrie . Die deutsche Firma Bigpoint ist ein Anbieter von Browser-Spielen mit mehr als 200 Millionen aktiven Nutzern.

Ihrer Browser Spiele erzeigen einen stetigen Strom von mehr als 10 000 Ereignissen pro Sekunde, wie aktuelle Level, virtuelle Güter , Spielzeit usw. Bigpoint verfolgt mehr als 800 Millionen Ereignisse pro Tag. Traditionelle Datenbanken unterstützen  keine Verarbeitung solch großer Datenmengen in einer interaktiven Art und Weise. Beispielsweise erfordern Joins oder vollständige Tabellenscans komplexe Indexstrukturen oder optimierte Data-Warehouse-Systeme, um einige ausgewählte Informationen schnell zurückzuliefern. Allerdings können individuelle und flexible Anfragen von Entwicklern oder Marketing-Experten hierbei nicht interaktiv beantwortet werden.

In Memory-Technologie verbessert die Erkennung von Zielgruppen und das Testen von Beta-Funktionen, Echtzeit-Vorhersagen und die Auswertung von Anzeigen-Platzierungen.

Merkmale von Unternehmensanwendungen

Ein Enterprise-Datenbank-Management-System sollte in der Lage sein, Daten zu bearbeiten, die aus mehreren unterschiedlichen Quellen stammen.

=> Transaktionale Daten stammen aus verschiedenen Anwendungen, wie z.B. Enterprise Resource Planning (ERP)-Systemen.

=> Den Ursprung von Event-Processing - und Stream-Daten bilden Maschinen und Sensoren, in der Regel stark ausgelastete Systeme.

=> Echtzeitanalysen stützen sich in der Regel auf strukturierte Daten für Transaktions-Reporting , klassische Vorhersagen, Planung und Simulation.

=> Textanalyse schließlich basiert in der Regel auf unstrukturierten Daten aus dem Web, sozialen Netzwerken, Log-Dateien, Hilfesystemen etc.

OLTP versus OLAP

Ein Enterprise-Datenbank-Management-System sollte in der Lage sein, transaktionale und analytische Abfragetypen, die sich in mehreren Dimensionen unterscheiden , zu verarbeiten.

Die Erstellung von Kundenaufträgen , von Rechnungen, von Abbrechnungsdaten, die Anzeige eines Kundenauftrags für einen einzelnen Kunden oder die Anzeige von Kundenstammdaten stellen typische Abfragen im Online Transaction Processing (OLTP) dar. Das Online Analytical Processing (OLAP) besteht hingegen aus analytischen Abfragen. Typische OLAP-Produkte oder Dienstleistungen an einen Kunden), operatives Reporting oder die Analyse von Trends , die auf früheren Absatzdaten basieren. 

Nachteile der Trennung von OLAP und OLTP

Obwohl die Trennung der Datenbank in zwei Systeme Workload-spezifische Optimierungen in beiden Systemen ermöglicht, hat sie auch eine Reihe von Nachteilen:

=> Das OLAP-System verfügt nicht über die aktuellsten Daten, weil die Latenz zwischen den Systemen von Minuten bis zu Stunden oder sogar Tagen reichen kann. Folglich werden viele Entscheidungen auf veraltenden Daten getroffen, weil die aktuellsten Informationen zum Abfragezeitpunkt zur Verfügung stehen.

=> Im eine akzeptable Leistung zu erreichen , arbeiten OLAP-Systeme mit vordefinierten materialisierten Aggregaten, die jedoch die Flexibilität der Abfragen des Anwenders verringern.

=> Die Redundanz der Daten ist hoch. In beiden Systemen werden gleiche , nur unterschiedlich optimierte Informationen gespeichert.

=>Die Schemata der OLTP- und OLAP-Systeme sind unterschiedlich. Das führt einerseits zu einer erhöhten Komplexität von Anwendungen, die beide Systemtypen nutzen, und anderseits zu einer hohen Komplexität des ETL-Prozess , der die daten zwischen den Systemen synchronisiert.

Kombinieren von OLTP- und OLAP-Daten

Der Hauptvorteil dieser Kombination besteht darin , das sowohl transaktionale als auch analytische Abfragen auf denselben Server mit demselben Satz von Daten ausgeführt werden können. Diese kombinierte Datenquelle stellt eine sog. „Single Source of Truth“ dar, jegliche ETL-Verarbeitung wird damit überflüssig.

Durch den Einsatz moderner Hardware können zusätzlich vorberechnete Aggregate und materialisierte Sichten eliminiert werden, weil Daten-Aggregationen nach Bedarf vorgenommen und virtuelle Sichten auf Daten  (sogenannte Views) zur Verfügung gestellt werden können. Mit einer erwarteten Antwortzeit bei Analyseabfragen von unter einer Sekunden ist es möglich , den analytischen Abfrageprozess der transaktionalen Daten jederzeit und überall direkt durchzuführen. Durch Verzicht auf die Vorausberechnung von Aggregaten und die Materialisierung von Sichten können außerdem Anwendungen  und Datenstrukturen vereinfacht werden, da die Verwaltung von Aggregaten und materialisierten Views (d.h. Deren Aufbau, Pflege und Speicherung ) nicht länger notwendig ist.

Der entstehende gemischte Workload kombiniert die Eigenschaften von OLAP- und OLTP-Workloads . Die Abfragen können sowohl volle Zeilenoperationen aufweisen als auch nur eine kleine Anzahl von Spalten erfassen. Abfragen können einfach oder komplex sein, vorgegeben oder ad hoc. Dies umfasst analytische Abfragen , die mit den aktuellsten Transaktionsdaten laufen und in der Lage sind, Änderungen in Echtzeit zu verwerten.

Folgende Teile werden folgen:

Teil II: in-Memory Datenbank Theorie und Algorithmen

Teil III: SAP HANA Datenbank

Teil IV: SQL Script für SAP HANA

SAP Data Intelligence .- Connection Management

 Eine der grundlegendsten Funktionen einer IT-Unternehmensarchitektur ist die Fähigkeit, die Daten aller relevanten Systeme und die Informationen aus den verschiedensten Bereichen des Unternehmens zusammen zu bringen. Im Idealfall können diese Systeme direkt miteinander kommunizieren. Man spricht hier von einer unternehmensweiten Datenintegration. Über entsprechende Schnittstellen ließe sich das bekannte und in der Vergangenheit viel zu oft praktizierte Verfahren des Exports und Imports von Daten aus den und in die verschiedenen Systeme vermeiden. Die Einführung einer übergreifender Integrationsplattform ist lange überfällig, da die Export- und Importverfahren nur allzu oft mit Problement zu kämpfen haben, wie beispielsweise abweichenden Formatierungen, zeitlichem Verzug oder einfach auch nur beschädigten oder unvollständigen Datenbeständen bzw. Nichtverfügbarkeit eines Speichermediums. 

SAP Data Intelligence bietet die geforderte Möglichkeit, die Systeme direkt anzubinden und miteinander kommunizieren zu lassen. Um zu verstehen, welchen Funktionsumfang SAP Data Intelligence bietet und welche Szenarien damit möglich sind, ist es essenziell, zu wissen welche Arten von Quellsystemen innerhalb des Systems verarbeitet werden können und vor allem auch, wie diese Datan in das System gelangen. Um Daten grundsätzlich strukturiert und ohne Umwege in das System zu integrieren, sind Schnittstellen mit standardisierter Funktionalität nötig. Diese sollen es auf einfachste Weise ermöglichen, Datenquellsysteme anzubinden, deren Informationen auszulesen, zu verstehen und so letztendlich auch zu verarbeiten. 

Funktionen auf Basis der Verbindungstypen

Bevor ich auf die einzelnen Verbindungstypen eingehe , will ich in diesem Abschnitt einen grundsätzlichen Blick auf die über die Verbindungen bereitgestellten Funktionen werfen. Diese können in den weiteren Applikationen von SAP Data Intelligence, wie beispielsweise dem Metadata Explorer oder dem Modeler, genutzt werden.

Eine der einfachsten Funktionen im Connection Management ist die Anzeige der Verbindungsstatus , um einen Überblick über die noch aktiven und laufenden Verbindungen zu erhalten. Im Zweifelsfall können Sie so korrigierend eingreifen, damit die laufenden Prozesse ungefährdet ausgeführt werden können. 

Über die Verbindungen besteht im Modeler und im Metadata Explorer die Möglichkeit , Ordner , Dateien, Bereiche, Objekte, Schemas und Datensätze auf den jeweiligen Zielsystemen zu durchsuchen oder Daten in Dateien, Tabellen und Views zu lesen und zu schreiben.  Darüber hinaus können Inhalte wie Dateien kopiert , aber auch gelöscht werden.

Durch die im Connection Management angelegten Verbindungen können vordefinierte und standardisierte Integrationsflüsse, sogenannte iFlows, ausgeführt werden. Solche iFlows können etwa aus über SAP Cloud Platform Integration angebundenen Systemen über eine obligatorische , gesicherte HTTPS-Verbindung ausgeführt werden, um beispielsweise eine Serviceanfrageformular im Zielsystem SAP Service Cloud oder SAP SAles Cloud (vormals SAP Cloud for Customer) anzulegen.

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

SAP Cloud Platform Integration

SAP Cloud Platform Integration ist eine Entwicklungs- und Integrationsplattform, die auf der SAP Cloud Platform angeboten wird. Sie ermöglicht den Austausch von Daten zwischen Cloud- und On-Premise-Systemen, wozu iFlows modelliert werden. Daneben bietet SAP Cloud Platform Integration vorgefertigte Adapter und Integrationsszenarien an.

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

Verbindungen bilden darüber hinaus die Grundlage für die Ausführung von Ablaufdiagrammen oder Ablaufdiagrammaufgaben, ABAP-Operatoren, Jobs, Prozessketten oder SQL-Anweisungen, um damit die Prozesse der angeschlossenen Systeme zentral steuern und orchestrieren zu können. Neben den Ablaufdiagrammen können auch Jobs aus SAP Data Services, einer Software zur Datenbewirtschaftung von Data-Warehouse-Lösungen durchsucht und in der SAP-Data-Intelligence-Umgebung dargestellt werden.

In Machine-Learning-Szenarien können die im Connection Management definierten Verbindungen im Rahmen des Trainings von maschinell lernenden Modellen verwendet werden. Sie ermöglichen so das Experimentieren mit Daten unter Verwendung von Jupyter-Lab. JupyterLab ist eine interaktive Entwicklungsumgebung , die Coding , die grafische Darstellung sowie die Dokumentation der Programmierung mithilfe von sogenannten Notebooks unterstützt. Die Bezeichnung Jupyter leitet sich von den drei im Wesentlichen verwendeten Programmiersprachen Julia, Python und R ab. 

Verbindungen zu SAP-Systemen

Als SAP-Tool ermöglicht SAP Data Intelligence die typischen Systemverbindungen zu SAP-Lösungen. Für diese Verbindungstypen sind unterschiedliche Funktionalitäten in SAP Data Intelligence verfügbar. 

Der Verbindungstyp ABAP ermöglicht den Zugriff auf die klassischen ABAP-basierten SAP-Systeme wie beispielsweise SAP R/3, SAP ERP oder SAP S/4HANA. Verbindungen dieses Typs werden über die Protokolle Remote Function Call (RFC), HTTPS oder WebSocket RFC hergestellt. Es kann auf Tabellen, ABAP-Dictionary-Objekte und CDS-Views zugegriffen werden.

Änderungen an Verbindungen dieses Typs werden nicht immer gleich erkannt, da die Verbindungsdetails im Cache des Browsers abgelegt werden und daher immer leicht verzögert greifen. Bei der Nutzung eines HTTPS- oder WebSocket-RFC-Verbindung ist darauf zu achten, dass ein entsprechendes Zertifikat zur Verfügung steht.

Der Verbindungstyp BW ermöglicht den Aufbau von Verbindungen zu SAP-BW-Systemen, SAP BW-Systemen auf SAP HANA oder SAP BW/4HANA-Systemen. Es werden allerdings nur Systeme ab Version 7.4 unterstützt.

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

Cloud Connector

Der Cloud Connector von SAP verbindet Cloudanwendungen mit On-Premise-Systemen. Er wird über die SAP Cloud Platform bereitgestellt. Mit dem Cloud Connector können Sie beliebig viele Backend-Systeme mit der SAP Cloud Platform verbinden.

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

Über den Verbindungstyp CLOUD_DATA_INTEGRATION können diverse SAP-Cloudlösungen mithilfe von OData-basierten APIs angebunden werden. Zu nennen wären hier etwa die Lösungen SAP Fieldglass, SAP Sales Cloud, SAP Service Cloud oder SAP S/4HANA Cloud.

Der Verbindungstyp CPI nutzt HTTPS als obligatorisches Verbindungsprotokollen und stellt eine Verbindung zur Middleware SAP Cloud Platform Integration her. Diese Middleware unterstützt Daten- und Prozessintegrationsszenarien und stellt hierzu verschiedene vorgefertigte Integrationspakete zur Verfügung. Darüber hinaus verfügt SAP Cloud Platform Integration über eine Entwicklungsplattform, eine Laufzeitumgebung sowie vorgefertigte Funktionsbausteine . Aus SAP Data Intelligence heraus können Sie die Integrationsflüsse (iFlows), die in SAP Cloud Platform Integration modelliert werden, auf der SAP Cloud Platform steuern. Deren Rückmeldungen können Sie wiederum innerhalb von SAP Data Intelligence verarbeiten.

Über den Verbindungstyp HANA_DB kann der Zugriff auf eine klassische SAP-HANA-Datenbank erfolgen, sodass die SAP-HANA-Objekte durchsucht. Metadaten ausgelesen , ein Data Profiling erstellt und eine Datenvorschau innerhalb von SAP Data Intelligence angezeigt werden können. Zur Einschränkung auf nur notwendige Schemas stellt dieser Verbindungstyp eine Blacklistfunktion zur Verfügung, die nicht benötigte Schemas der Datenbank ausblendet. Diese Einschränkung stellt aber keine direkte Berechtigungseinschränkung dar, da sie mit dem Zugriff auf die Verbindungen aufgehoben werden kann.

Weitere Verbindungen sind:

Verbindungen zu Datenbanken

Verbindungen zu cloudbasierten Systemen

Erster Artikel zur SAP Data Intelligence:

https://einsiedlerkreps.blogspot.com/2023/04/sap-data-intelligence-ein-moglicher.html

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