Get best of the week

Betrieb eines großen verteilten Systems: Was ich gelernt habe



Beim Lesen verschiedener Kanäle und Newsletter stoße ich häufig auf Artikel über bestimmte „Schmerzen“ und Probleme, die auftreten, wenn ein Unternehmen wächst, wenn Zuverlässigkeit und Skalierbarkeit im Vordergrund stehen. Dieser Artikel ist anders. Es gibt keine detaillierte Analyse spezifischer Architekturlösungen oder eine schrittweise Anleitung zur Änderung der Ingenieurkultur. Es ist vielmehr eine Draufsicht auf die Herausforderungen, die sich beim Betrieb verteilter Systeme ergeben, und ein Ausgangspunkt, der Ihnen hilft, den Fluss von Begriffen, Abkürzungen und Technologien zu steuern.

Ich mache Sie auf eine Übersetzung eines Artikels aufmerksam, der von einem Ingenieur aus Uber geschrieben wurde.

* * *

In den letzten Jahren habe ich in Uber ein großes verteiltes Zahlungssystem erstellt und gepflegt . In dieser Zeit habe ich viel über die Konzepte verteilter Architekturen gelernt .und aus eigener Erfahrung habe ich herausgefunden, wie schwierig es ist, hoch ausgelastete Systeme mit hoher Verfügbarkeit zu erstellen und zu warten. Der Aufbau eines solchen Systems ist eine interessante Aufgabe. Ich möchte planen, wie das System mit einem 10-100-fachen Verkehrswachstum umgehen soll, um die Zuverlässigkeit der Daten unabhängig von Hardwarefehlern zu gewährleisten. Der Betrieb eines großen verteilten Systems gab mir jedoch unerwartete Erfahrungen .

Je größer das System, desto wahrscheinlicher ist es, dass Sie auf eine Manifestation von Murphys Gesetz stoßen: " Alles, was schief gehen kann, wird schief gehen ." Die Wahrscheinlichkeit ist besonders hoch bei häufigen Releases, wenn viele Entwickler Code einführen, wenn mehrere Rechenzentren verwendet werden und wenn ein großes Publikum von Benutzern auf der ganzen Welt anwesend ist. In den letzten Jahren bin ich auf eine Vielzahl von Systemabstürzen gestoßen, von denen mich viele überrascht haben: von vorhersehbaren Problemen wie Hardwareabstürzen oder unschuldigen Fehlern bis hin zu Kabelbrüchen, die Rechenzentren verbinden, bis hin zu zahlreichen gleichzeitig auftretenden kaskadierenden Abstürzen. Ich habe Dutzende von Fehlern durchlaufen, bei denen Teile des Systems nicht richtig funktionierten, was das Geschäft stark beeinträchtigte.

Dieser Artikel fasst die Techniken zusammen, die vom Betrieb eines großen Systems in Uber profitiert haben . Meine Erfahrung ist nicht einzigartig: Andere arbeiten mit Systemen gleicher Größe und erleben dieselben Abenteuer. Ich habe mit Ingenieuren von Google, Facebook und Netflix gesprochen, die mit ähnlichen Situationen konfrontiert waren und ähnliche Lösungen gefunden haben. Viele der hier beschriebenen Ideen und Prozesse können auf Systeme derselben Größenordnung angewendet werden, unabhängig davon, ob sie in firmeneigenen Rechenzentren (wie dies bei Uber am häufigsten der Fall ist) oder in der Cloud (wo Uber manchmal skaliert ) funktionieren . Diese Tipps können jedoch für nicht so große oder wichtige Systeme für das Unternehmen redundant sein.

Wir werden über solche Themen sprechen:

  • Überwachung
  • Dienst (Bereitschaftsdienst), Erkennung von Anomalien und Benachrichtigung.
  • Fehler- und Vorfallmanagement.
  • Post Mortems, Incident-Analyse und eine Kultur der kontinuierlichen Verbesserung.
  • Failover, Ressourcenplanung und Blackbox-Tests.
  • SLO, SLA und Berichterstattung darüber.
  • SRE als unabhängiges Team.
  • Zuverlässigkeit als dauerhafte Investition.
  • Nützliche Materialien.

Überwachung


Um zu verstehen, ob das System fehlerfrei ist, müssen wir die Frage beantworten: „Funktioniert es richtig? ". Dazu ist es wichtig, Informationen über kritische Teile des Systems zu sammeln. Und wenn Sie Systeme verteilt haben, die aus verschiedenen Diensten auf zahlreichen Servern und in verschiedenen Rechenzentren bestehen, kann es schwierig sein, zu entscheiden, welche wichtigen Punkte Sie wirklich verfolgen müssen.

Überwachung des Status der Infrastruktur.Wenn eine oder mehrere Maschinen / virtuelle Maschinen überlastet sind, kann die Leistung einiger Teile des verteilten Systems beeinträchtigt werden. Die Statusmetriken der Computer, auf denen der Dienst ausgeführt wird - der Verbrauch von Prozessorressourcen und Speicher - sind die grundlegenden Parameter, die überwacht werden müssen. Es gibt Plattformen, die diese Metriken zunächst verfolgen und Instanzen automatisch skalieren. Uber verfügt über ein großartiges Kerninfrastruktur-Team , das standardmäßig Überwachung und Alarmierung bietet. Unabhängig von der Implementierungsmethode müssen Sie über Informationen verfügen, dass Instanzen, Infrastruktur oder einzelne Dienste Probleme haben.

Überwachung des Servicestatus: Verkehr, Fehler, Verzögerung . Oft muss man die Antwort auf die Frage haben "Funktioniert das Backend einwandfrei? ". Die Überwachung von Metriken wie der Menge des eingehenden Datenverkehrs, dem Anteil der Fehler und der Verzögerung der Antwort liefert wertvolle Informationen über den Status des Dienstes. Ich ziehe es vor, Dashboards für all diese Metriken zu erstellen. Wenn Sie einen neuen Dienst erstellen, kann die Verwendung der richtigen HTTP-Antworten und die Überwachung der entsprechenden Codes viel über den Status des Systems aussagen. Wenn Sie sicher sind, dass 4xx-Codes für Clientfehler und 5xx-Codes für Serverfehler zurückgegeben werden, können Sie diese Überwachung leicht erstellen und interpretieren.

Es gibt noch etwas zu sagen über die Überwachung von Reaktionsverzögerungen. Das Ziel von Produktionsservices ist, dass die meisten Endbenutzer sie gerne nutzen. Die Messung der durchschnittlichen Verzögerung ist nicht die beste Lösung, da der Durchschnittswert eine kleine Anzahl von Anforderungen mit einer großen Verzögerung verbergen kann. Es ist viel besser, p95, p99 oder p999 zu messen - die Verzögerung für das 95., 99. oder 99,9-Perzentil der Anforderungen. Diese Zahlen helfen bei der Beantwortung von Fragen wie: " Wie schnell wird die Anfrage für 99% der Besucher sein?" "(P99) oder" Wie langsam wird die Anfrage für einen von 1000 Besuchern sein? (P999). Wenn Sie an den Details interessiert sind, können Sie diesen Artikel lesen .


Grafik für p95 und p99. Beachten Sie, dass die durchschnittliche Verzögerung für diesen Endpunkt weniger als 1 Sekunde beträgt und 1% der Anforderungen 2 Sekunden dauert. und mehr - dies wird bei der Messung des Durchschnittswerts nicht gesehen.

Das Thema Überwachung und Beobachtbarkeit ist viel tiefer. Ich empfehle, das Google SRE-Buch und den Abschnitt Vier goldene Signale zur Überwachung verteilter Systeme zu lesen . Wenn Sie für ein System, mit dem Benutzer interagieren, nur vier Metriken erhalten, konzentrieren Sie sich auf Datenverkehr, Fehler, Verzögerung und Sättigung. Es gibt weniger Material - das E-Book " Distributed Systems Observability " , in dem nützliche Tools wie Protokolle sowie Best Practices für die Verwendung von Metriken und die Ablaufverfolgung beschrieben werden.

Überwachung von Geschäftsmetriken. Überwachungsdienste informieren uns über ihren Gesamtzustand. Laut Überwachungsdaten allein können wir jedoch nicht sagen, ob die Services ordnungsgemäß funktionieren und ob aus geschäftlicher Sicht alles korrekt verarbeitet wird. Im Fall des Zahlungssystems lautet die Hauptfrage: „ Können Personen Reisen mit einer bestimmten Zahlungsmethode unternehmen? ". Einer der wichtigsten Schritte bei der Überwachung ist die Identifizierung und Verfolgung von Geschäftsereignissen, die von diesem Service erstellt und verarbeitet werden.

Mein Team erstellte eine Überwachung der Geschäftsmetriken nach einem Fehler, den wir auf andere Weise nicht erkennen konnten. Alles sah so aus, als ob die Dienste normal funktionieren würden, aber tatsächlich funktionierte die Schlüsselfunktionalität nicht. Diese Art der Überwachung war für unser Unternehmen und unseren Tätigkeitsbereich sehr ungewöhnlich. Daher mussten wir viele Anstrengungen unternehmen, um diese Überwachung für uns selbst zu konfigurieren und unser eigenes System zu erstellen .

Pflicht, Anomalieerkennung und Alarm


Die Überwachung ist ein großartiges Werkzeug, um den aktuellen Status des Systems zu überprüfen. Dies ist jedoch nur ein Schritt auf dem Weg, Fehler automatisch zu erkennen und diejenigen zu warnen, die in diesem Fall etwas tun sollten.

Beobachten ist ein umfangreiches Thema. Das Increment Magazine hat hervorragende Arbeit geleistet und viele der Themen in der On-Call- Ausgabe hervorgehoben . Pflicht ist meiner Meinung nach eine logische Fortsetzung des Ansatzes „Sie haben geschaffen - Sie besitzen“. Die Dienste gehören den Teams, die sie hergestellt haben, und sie besitzen auch ein Alarm- und Vorfallreaktionssystem. Mein Team besaß ein solches System für den von uns erstellten Zahlungsdienst. Und wenn der Alarm eintrifft, muss der diensthabende Ingenieur reagieren und herausfinden, was passiert. Aber wie wechseln wir von der Überwachung zu Warnungen?

Das Ermitteln von Anomalien anhand von Überwachungsdaten ist eine schwierige Aufgabe , und maschinelles Lernen sollte sich hier vollständig manifestieren. Es gibt viele Dienste von Drittanbietern zum Erkennen von Anomalien. Zum Glück für mein Team hat unser Unternehmen eine eigene Gruppe für maschinelles Lernen, um die Probleme zu lösen, mit denen Uber konfrontiert ist. Das New Yorker Team schrieb einen nützlichen Artikel darüber, wie die Erkennung von Anomalien durch Uber funktioniert . Aus Sicht meines Teams senden wir nur Überwachungsdaten an diese Pipeline und erhalten Warnungen mit unterschiedlichem Vertrauen. Und dann entscheiden wir, ob wir den Ingenieur darüber informieren wollen.

Wann muss ich eine Benachrichtigung senden? Die Frage ist interessant. Wenn es zu wenige Warnungen gibt, verpassen wir möglicherweise einen wichtigen Fehler. Wenn zu viel, dann werden die Menschen nachts nicht schlafen.Das Verfolgen und Kategorisieren von Warnungen sowie das Messen des Signal-Rausch-Verhältnisses spielt eine große Rolle bei der Einrichtung eines Warnsystems . Ein guter Schritt in Richtung einer stetigen Rotation der diensthabenden Ingenieure besteht darin, Warnungen zu analysieren, Ereignisse als „Maßnahmen erforderlich“ und „nicht erforderlich“ zu kategorisieren und dann die Anzahl der Warnungen zu verringern, für die keine Maßnahmen erforderlich sind.


Ein Beispiel für ein Call Duty-Panel, das vom Uber Developer Experience-Team in Vilnius erstellt wurde.

Das Uber-Team für die Erstellung von Entwicklungstools aus Vilnius hat ein kleines Tool erstellt , mit dem wir Warnungen kommentieren und Dienstverschiebungen visualisieren können. Unser Team erstellt wöchentlich einen Bericht über die Arbeit der letzten Schicht im Dienst, analysiert Schwachstellen und verbessert die Dienstmethode.

Fehler- und Vorfallmanagement


Stellen Sie sich vor: Sie sind eine Woche lang Dienstingenieur. Mitten in der Nacht wecken Sie eine Nachricht auf dem Pager. Sie prüfen, ob ein Produktionsfehler aufgetreten ist. Verdammt, es scheint, als wäre ein Teil des Systems abgestürzt. Was jetzt? Überwachung und Alarmierung haben gerade funktioniert.

Ausfälle sind für kleine Systeme möglicherweise nicht besonders problematisch, wenn der diensthabende Ingenieur verstehen kann, was passiert ist und warum. Normalerweise können Sie in solchen Systemen die Ursachen schnell identifizieren und beseitigen. Bei komplexen Systemen mit vielen (Mikro-) Diensten ist der Grund für den Fehler jedoch ziemlich schwierig, wenn viele Ingenieure den Code in Betrieb nehmen. Die Einhaltung mehrerer Standardverfahren kann eine große Hilfe sein.

Die erste Verteidigungslinie sind Runbooks mit Standardreaktionsverfahrendie einfache Schritte zur Fehlerbehebung beschreiben. Wenn das Unternehmen über solche Listen verfügt und aktiv unterstützt wird, ist es unwahrscheinlich, dass eine oberflächliche Vorstellung des diensthabenden Ingenieurs über das System ein Problem darstellt. Die Listen müssen auf dem neuesten Stand gehalten, aktualisiert und auf neue Weise zur Lösung von Problemen verarbeitet werden.

Informieren über Ausfälle anderer MitarbeiterEs wird sehr wichtig, wenn mehrere Teams an der Einführung eines Dienstes beteiligt sind. In der Umgebung, in der ich arbeite, werden Services nach Bedarf von Tausenden von Ingenieuren mit einer Häufigkeit von Hunderten von Releases pro Stunde bereitgestellt. Und die scheinbar harmlose Einführung eines Dienstes kann sich auf einen anderen auswirken. In einer solchen Situation spielt die Standardisierung der Fehlerberichterstattung und der Kommunikationskanäle eine wichtige Rolle. Ich hatte viele Fälle, in denen die Warnung nichts anderes war, und mir wurde klar, dass dies für andere Teams ebenfalls seltsam aussieht. In einem allgemeinen Chat über Fehler identifizieren wir den für den Fehler verantwortlichen Dienst und beseitigen schnell die Konsequenzen. Gemeinsam schaffen wir das viel schneller als jeder von uns einzeln.

Beseitigen Sie jetzt die Konsequenzen und finden Sie es morgen heraus. Während eines Unfalls wurde ich oft von einer Adrenalinwelle überwältigt, weil ich Fehler korrigieren wollte. Oft war die Ursache des Problems die Einführung von fehlerhaftem Code mit einem offensichtlichen Fehler. Zuvor hatte ich alles beendet und begonnen, Fehler zu korrigieren, einen Fix zu senden und den fehlgeschlagenen Code zurückzusetzen. Aber die Ursache mitten in einem Unfall zu beheben, ist eine schreckliche Idee . Mit einer schnellen Lösung können Sie wenig erreichen und viel verlieren . Da das Update schnell durchgeführt werden muss, muss es im Kampf getestet werden. Und dies ist der Weg zu einem neuen Fehler - oder einem neuen Fehler - zusätzlich zu dem vorhandenen. Ich habe gesehen, wie dies eine Reihe von Fehlern verursacht hat. Konzentrieren Sie sich nur darauf, die Konsequenzen zu beheben, und versuchen Sie nicht, den Code zu beheben oder die Ursache zu finden. Die Untersuchung wird bis morgen warten.

Post Mortems, Incident-Analyse und eine Kultur der kontinuierlichen Verbesserung


Ein Vorfallbericht ist ein wichtiges Merkmal dafür, wie ein Team mit den Folgen eines Ausfalls umgeht. Macht die Situation den Menschen Sorgen? Machen sie ein wenig Nachforschungen oder geben sie erstaunlich viel Mühe für die Beobachtung, stoppen Sie das Produkt und nehmen Sie Korrekturen vor?

Richtig geschriebenes Post-Mortem ist eines der Hauptelemente beim Aufbau nachhaltiger Systeme. Es verurteilt niemanden und sucht nicht nach den Tätern, dies ist eine nachdenkliche Untersuchung und Analyse des Vorfalls. Im Laufe der Zeit haben sich unsere Vorlagen für solche Berichte weiterentwickelt, Abschnitte mit endgültigen Schlussfolgerungen, Folgenabschätzung, Chronologie der Ereignisse, Analyse des Hauptgrunds, gewonnene Erkenntnisse und eine detaillierte Liste von Elementen zur weiteren Beobachtung erschienen.


Ich habe dieses Fehlerbehandlungsmuster in Uber verwendet.

In einem guten Post-Mortem-Bereich wird die Fehlerursache gründlich untersucht und Maßnahmen vorgeschlagen, um die Folgen ähnlicher Fehler zu verhindern, zu erkennen oder schnell zu beseitigen. Und wenn ich "tief" sage, meine ich, dass die Autoren nicht bei der Tatsache stehen bleiben, dass der Grund das Rollen von Code mit einem Fehler war, den der Rezensent nicht bemerkt hat. Autoren sollten die Five Why- Methode anwenden , um zu einer nützlicheren Schlussfolgerung zu gelangen. Zum Beispiel:

  • Warum gibt es ein Problem? -> Der Fehler wurde als Teil des Codes hochgeladen.
  • Warum hat niemand einen Fehler entdeckt? -> Derjenige, der die Überprüfung durchgeführt hat, hat nicht bemerkt, dass das Ändern des Codes zu einem solchen Problem führen kann.
  • , ? --> .
  • ? --> .
  • ? --> .
  • : . , .

Die Ereignisanalyse ist ein wichtiges Begleitwerkzeug für die Bearbeitung von Fehlern. Während einige Teams sorgfältig an Fehlern arbeiten, können andere von zusätzlichen Daten profitieren und vorbeugende Verbesserungen vornehmen. Es ist auch wichtig, dass sich die Teams als verantwortlich und in der Lage fühlen, die von ihnen vorgeschlagenen Verbesserungen auf Systemebene vorzunehmen.

In Organisationen, die die Zuverlässigkeit ernst nehmen, werden die schwerwiegendsten Vorfälle von erfahrenen Ingenieuren analysiert und beseitigt. Es ist auch erforderlich, das Engineering auf Unternehmensebene zu verwalten, um sicherzustellen, dass Korrekturen vorgenommen werden können - insbesondere, wenn diese zeitaufwändig sind oder andere Arbeiten beeinträchtigen. Ein zuverlässiges System kann nicht in einer Nacht erstellt werden: Es sind ständige Iterationen erforderlich. Iterationen, die sich aus einer Unternehmenskultur der kontinuierlichen Verbesserung ergeben, basierend auf Lehren aus Vorfällen.

Failover, Ressourcenplanung und Blackbox-Tests


Es gibt mehrere reguläre Verfahren, die erhebliche Investitionen erfordern, jedoch für die Aufrechterhaltung eines großen verteilten Systems von entscheidender Bedeutung sind. Ich bin bei Uber zum ersten Mal auf diese Ideen gekommen und musste sie aufgrund des geringeren Umfangs und der Nichtverfügbarkeit der Infrastruktur nicht auf andere Unternehmen anwenden. Ich habe dummes

Failover im Rechenzentrum (Failover) in Betracht gezogen, bis ich selbst darauf gestoßen bin. Anfangs glaubte ich, dass das Design eines stabilen verteilten Systems die Stabilität von Rechenzentren ist. Warum sollte es regelmäßig getestet werden, wenn theoretisch alles funktionieren sollte? Die Antwort hängt von der Skalierung und dem Testen der Fähigkeit von Diensten ab, den unerwarteten Anstieg des Datenverkehrs im neuen Rechenzentrum effizient zu bewältigen.

Das häufigste Fehlerszenario, auf das ich gestoßen bin, ist, dass der Dienst im neuen Rechenzentrum nicht über genügend Ressourcen verfügt, um den globalen Datenverkehr im Falle eines Failovers zu verarbeiten. Angenommen, Service A funktioniert in einem Rechenzentrum und Service B in einem anderen. Der Ressourcenverbrauch beträgt 60% - zehn oder Hunderte virtueller Maschinen drehen sich in jedem Rechenzentrum, und Warnungen werden ausgelöst, wenn ein Schwellenwert von 70% erreicht wird. Der gesamte Datenverkehr vom Rechenzentrum A zum Rechenzentrum B ist fehlgeschlagen. Das zweite Rechenzentrum kann einen solchen Lastanstieg nicht bewältigen, ohne neue Maschinen bereitzustellen. Dies kann jedoch viel Zeit in Anspruch nehmen, sodass sich Anfragen häufen und fallen lassen. Das Blockieren wirkt sich auf andere Dienste aus und führt zu einem Kaskadenfehler anderer Systeme, die nicht mit dem primären Failover zusammenhängen.


Eine mögliche Situation, in der ein Failover zu Problemen führt.

Ein weiteres beliebtes Fehlerszenario betrifft Probleme auf Routing-Ebene, Probleme mit der Netzwerkbandbreite oder den Gegendruck . Das Failover von Rechenzentren ist eine Entwicklung, die jedes zuverlässige verteilte System ohne Auswirkungen auf die Benutzer ausführen muss. Ich betone - es sollte , diese Entwicklung ist eine der nützlichsten Übungen zur Überprüfung der Zuverlässigkeit verteilter Websysteme.

Geplante Übungen für AusfallzeitenEine großartige Möglichkeit, die Stabilität eines gesamten Systems zu testen. Es ist auch ein großartiges Tool zum Erkennen versteckter Abhängigkeiten oder unangemessener / unerwarteter Verwendungen eines bestimmten Systems. Geplante Ausfallzeiten können mit Diensten, mit denen Clients interagieren und von denen nur geringe Abhängigkeiten bekannt sind, relativ einfach durchgeführt werden. Wenn es sich jedoch um kritische Systeme handelt, für die eine sehr kurze Ausfallzeit zulässig ist oder von denen viele andere Systeme abhängen, ist es schwierig, solche Übungen durchzuführen. Aber was passiert, wenn ein solches System eines Tages nicht mehr verfügbar ist? Es ist besser, diese Frage in einem kontrollierten Experiment zu beantworten, damit alle Teams gewarnt und bereit sind.

Blackbox-Tests(die "Black-Box" -Methode) ist eine Methode, um die Richtigkeit des Systems in einer Situation zu beurteilen, die der Interaktion mit dem Endbenutzer so nahe wie möglich kommt. Dies ähnelt einem End-to-End-Test, mit der Ausnahme, dass für die meisten Produkte für den richtigen Blackbox-Test eigene Investitionen erforderlich sind. Gute Kandidaten für solche Tests sind wichtige Benutzerprozesse und -szenarien, die Benutzerinteraktion beinhalten: Um das System zu testen, stellen Sie sicher, dass sie jederzeit gestartet werden können.

Am Beispiel von Uber überprüft ein offensichtlicher Blackbox-Test die Fahrer-Beifahrer-Interaktion auf Stadtebene: Kann ein Beifahrer einen Fahrer finden und auf eine bestimmte Anfrage hin eine Reise unternehmen? Nach der Automatisierung dieses Szenarios kann der Test regelmäßig ausgeführt werden und verschiedene Städte emulieren. Ein zuverlässiges Blackbox-Testsystem erleichtert die Überprüfung des korrekten Betriebs des Systems oder seiner Teile. Es hilft auch sehr beim Failover-Testen: Der schnellste Weg, um Feedback zu erhalten, ist das Ausführen von Blackbox-Tests.


Ein Beispiel für Blackbox-Tests während eines Failover-Failovers und eines manuellen Rollbacks.

Ressourcenplanungspielt eine besonders wichtige Rolle für große verteilte Systeme. Im Großen und Ganzen meine ich diejenigen, bei denen die Kosten für Computer und Speicherung in Zehntausenden oder Hunderttausenden von Dollar pro Monat berechnet werden. In dieser Größenordnung kann es billiger sein, eine feste Anzahl von Bereitstellungen zu haben, als selbstskalierbare Cloud-Lösungen zu verwenden. In extremen Fällen sollten feste Bereitstellungen den für „normales Geschäft“ charakteristischen Datenverkehr verarbeiten, wobei die automatische Skalierung nur bei Spitzenlasten erfolgt. Aber wie viele Instanzen müssen mindestens im nächsten Monat beantragt werden? In den nächsten drei Monaten? Nächstes Jahr?

Es ist nicht schwierig, zukünftige Verkehrsmuster für ausgereifte Systeme mit großen statistischen Volumina vorherzusagen. Dies ist wichtig für das Budget, die Auswahl der Anbieter oder für die Festsetzung von Rabatten von Cloud-Anbietern. Wenn Ihr Service große Konten generiert und Sie nicht über Ressourcenplanung nachgedacht haben, fehlt Ihnen eine einfache Möglichkeit, Kosten zu senken und zu verwalten.

SLO, SLA und Berichterstattung darüber


SLO steht für Service Level Objective , eine Metrik für die Systemverfügbarkeit. Es wird empfohlen , SLOs auf Service-Ebene für Leistung, Reaktionszeit, Korrektheit und Verfügbarkeit festzulegen . Diese SLOs können dann als Alarmschwellen verwendet werden. Beispiel:

SLO-MetrikUnterkategorieServicewert
PerformanceMinimale Bandbreite500 Anfragen pro Sekunde
2 500
50-90
p99500-800
0,5 %
99,9 %

SLO auf Unternehmensebene . oder funktionale SLOs, dies ist eine Abstraktion über Dienste. Sie decken benutzerdefinierte oder geschäftliche Metriken ab. Ein SLO auf Unternehmensebene könnte beispielsweise folgendermaßen aussehen: 99,99% der Belege werden voraussichtlich innerhalb von 1 Minute nach Abschluss einer Reise verschickt. Dieses SLO kann mit dem SLO auf Serviceebene verglichen werden (z. B. mit der Verzögerung des Zahlungssystems oder des Systems zum Senden von Postschecks) und kann separat gemessen werden.

SLA - Service Level Agreement . Dies ist eine allgemeinere Vereinbarung zwischen einem Dienstleister und seinem Verbraucher. Normalerweise bilden mehrere SLOs eine SLA. Beispielsweise kann die Verfügbarkeit eines Zahlungssystems auf der Ebene von 99,99% SLA sein, das für jedes entsprechende System in spezifische SLOs unterteilt ist.

Nachdem Sie den SLO ermittelt haben, müssen Sie ihn messen und einen Bericht erstellen.Die automatische Überwachung und Berichterstellung von SLAs und SLOs ist häufig ein komplexes Projekt , das weder Ingenieure noch Unternehmen priorisieren möchten. Ingenieure sind nicht interessiert, da sie bereits unterschiedliche Überwachungsebenen haben, um Fehler in Echtzeit zu identifizieren. Ein Unternehmen priorisiert die Bereitstellung von Funktionen besser, als in ein komplexes Projekt zu investieren, das keine unmittelbaren Vorteile bietet.

Dies führt uns zu einem anderen Thema: Unternehmen, die große verteilte Systeme betreiben, müssen früher oder später Mitarbeiter zuweisen, um die Zuverlässigkeit dieser Systeme sicherzustellen. Lassen Sie uns über das SRE-Team - Site Reliability Engineering - sprechen.

SRE als unabhängiges Team


Der Begriff Site Reliability Engineering wurde um 2003 von Google geprägt. Heute gibt es mehr als 1.500 SRE-Ingenieure. Da der Betrieb der Produktionsumgebung zu einer immer komplexer werdenden Aufgabe wird, die mehr Automatisierung erfordert, wird sie bald zu einer vollwertigen Arbeit. Dies geschieht, wenn Unternehmen feststellen, dass Ingenieure fast den ganzen Tag an der Automatisierung der Produktionsumgebung arbeiten: Je wichtiger das System und je mehr Fehler auftreten, desto eher wird die SRE zu einer separaten Position.

Schnell wachsende Technologieunternehmen bilden häufig frühzeitig ein SRE-Team, das sie selbst planen. In Uber wurde 2015 ein solches Team gegründet.Ziel war es, die Komplexität des Systems zu steuern. In anderen Unternehmen kann die Zuweisung von SRE-Teams mit der Schaffung eines separaten Infrastrukturteams verbunden sein. Wenn das Unternehmen so weit wächst, dass die Gewährleistung der Zuverlässigkeit des Service die Aufmerksamkeit einer erheblichen Anzahl von Ingenieuren erfordert, ist es an der Zeit, ein separates Team zu bilden.

Das SRE-Team vereinfacht die Wartung großer verteilter Systeme für alle Ingenieure erheblich. Das SRE-Team besitzt wahrscheinlich Standard-Überwachungs- und Warnungstools. Sie kaufen oder erstellen wahrscheinlich Bereitschaftstools und sind bereit, ihre Erfahrungen zu teilen. Sie können die Analyse von Vorfällen erleichtern und Systeme erstellen, die es einfacher machen, Fehler zu erkennen, ihre Folgen zu verringern und sie in Zukunft zu verhindern. Der SRE-Befehl erleichtert sicherlich Failover-Operationen. Es wird häufig verwendet, um Black Boxes zu testen und die Leistung zu planen. Die SRE-Ingenieure verwalten die Auswahl, Anpassung oder Erstellung von Standardwerkzeugen zur Ermittlung und Messung von SLOs und zur Berichterstellung.

Da alle Unternehmen ihre eigenen Probleme haben, für deren Lösung sie SRE einstellen, haben solche Teams in verschiedenen Unternehmen unterschiedliche Strukturen. Sogar die Namen können variieren: Es kann sich um einen Betriebsdienst, ein Plattform-Engineering oder einen Infrastrukturdienst handeln. Google hat zwei obligatorische Lesebücher zur Gewährleistung der Zuverlässigkeit von Diensten veröffentlicht . Sie sind frei verfügbar und eine hervorragende Informationsquelle für eine eingehendere Untersuchung des Themas SRE.

Zuverlässigkeit als dauerhafte Investition


Beim Erstellen eines Produkts ist das Zusammenstellen der ersten Version nur der Anfang. Danach wird es neue Iterationen mit neuen Funktionen geben. Wenn das Produkt erfolgreich und rentabel ist, wird die Arbeit fortgesetzt.

Verteilte Systeme haben den gleichen Lebenszyklus, außer dass sie nicht nur mehr in neue Funktionen investieren müssen, sondern auch mit der Skalierung Schritt halten müssen. Wenn die Belastung des Systems zunimmt, müssen Sie mehr Daten speichern, mehr Ingenieure arbeiten am System und Sie müssen sich ständig um dessen normale Funktionsweise kümmern. Viele derjenigen, die zum ersten Mal verteilte Systeme erstellen, betrachten sie als eine Art Maschine: Wenn Sie dies einmal getan haben, reicht es aus, alle paar Monate bestimmte Wartungsarbeiten durchzuführen. Es ist schwer, einen Vergleich zu finden, der weiter von der Realität entfernt ist.

, , . Damit das Krankenhaus gut funktioniert, sind ständige Überprüfungen erforderlich (Überwachung, Warnmeldungen, Black-Box-Tests). Sie müssen ständig neue Mitarbeiter und Geräte einstellen: Für Krankenhäuser sind dies Krankenschwestern, Ärzte und medizinische Geräte sowie für verteilte Systeme neue Ingenieure und Dienstleistungen. Mit zunehmender Anzahl von Mitarbeitern und Dienstleistungen werden die alten Arbeitsmethoden unwirksam: Eine kleine Klinik auf dem Land arbeitet anders als ein großes Krankenhaus in einer Metropole. Das Erreichen effektiverer Funktionsweisen wird zu einer vollwertigen Arbeit, und Messungen und Warnungen werden immer wichtiger. Da ein großes Krankenhaus mehr Personal benötigt, wie z. B. Buchhaltung, Personal und Sicherheit,Der Betrieb großer verteilter Systeme hängt von Serviceteams wie Infrastruktur und SRE ab.

Damit das Team ein zuverlässiges verteiltes System aufrechterhalten kann, muss die Organisation ständig in seine Funktionsweise sowie in die Arbeit der Plattformen investieren, auf denen das System aufgebaut ist.

Nützliche Materialien


Obwohl sich der Artikel als lang herausstellte, zeigt er nur die oberflächlichsten Momente. Um mehr über die Funktionen des Betriebs verteilter Systeme zu erfahren, empfehle ich folgende Quellen:

Bücher


Websites

  • On-Call Edition des Increment Magazine : Eine Reihe von Artikeln zu Vorfällen bei Amazon, Dropbox, Facebook, Google und Netflix.
  • Lernen, verteilte Systeme zu erstellen - AWS Engineer-Artikel, in dem die Frage „Wie lerne ich , große verteilte Systeme zu erstellen?“ Beantwortet wird.

Siehe Kommentare zu diesem Artikel in den Hacker News .

More articles:


All Articles