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

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

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