SLICK: Adopting SLOs for improved reliability

Um die Menschen und Communities zu unterstützen, die unsere Apps und Produkte verwenden, müssen wir ständig mit ihnen in Kontakt bleiben. Die von uns angebotenen Erfahrungen wollen wir zuverlässig zur Verfügung stellen. Wir müssen auch Vertrauen zu der größeren Gemeinschaft aufbauen, die wir unterstützen. Dies kann in einer großen, sich schnell entwickelnden Umgebung wie Meta eine besondere Herausforderung darstellen, in der Tausende von Ingenieuren häufig Code bereitstellen, Prototyping-Funktionen erstellen und Änderungen durchlaufen. Wir müssen klare Erwartungen für jedes Produkt, jede Funktion und jeden Service haben. Damit können wir das gewünschte Erlebnis für die Nutzer unserer Dienste besser visualisieren und eventuelle Engpässe oder komplexe Interaktionen zwischen unseren Systemen analysieren.

Wir begannen, Service-Level-Indikatoren (SLIs) und Service-Level-Ziele (SLOs) zu untersuchen, um Erwartungen zu setzen und die Leistung von Services an diesen Erwartungen zu messen. Um hierfür Tooling-Unterstützung zu bieten, haben wir SLICK entwickelt – einen dedizierten SLO-Store. Mit SLICK sind wir in der Lage, SLI- und SLO-Definitionen zu zentralisieren, um die Zuverlässigkeit eines anderen Dienstes leicht zu finden und zu verstehen; Bereitstellung von Einblicken für Service-Inhaber mithilfe von Daten mit hoher Retention und vollständiger Granularität für wichtige Service-Metriken, die in anderen Tools nicht zu finden sind; und integrieren Sie SLOs in verschiedene andere Workflows im Unternehmen, um sicherzustellen, dass SLOs ein Teil der täglichen Arbeit werden.

Vor SLICK wurden SLOs und andere Leistungskennzahlen in benutzerdefinierten Dashboards, Dokumenten oder anderen Tools gespeichert. Wenn Sie die SLOs eines Teams finden wollten, konnte es eine Stunde dauern, zu suchen oder Leute zu bitten, etwas zu finden. Darüber hinaus haben unsere vorherigen Systeme diese Messwerte nicht länger als ein paar Wochen in voller Granularität beibehalten. Dies machte es nahezu unmöglich, ein SLO über längere Zeiträume zu analysieren. Mit SLICK sind wir jetzt in der Lage:

  1. Definieren Sie SLOs auf einheitliche Weise für unsere Dienstleistungen
  2. Bis zu minutengenaue metrische Daten mit Granularität und einer Aufbewahrungsdauer von bis zu zwei Jahren
  3. Verfügen Sie über Standardvisualisierungen und Einblicke für SLI/SLO-Metriken
  4. Senden Sie regelmäßige Zuverlässigkeitsberichte an interne Gruppen, damit Teams diese für Zuverlässigkeitsüberprüfungen verwenden können

Auffindbarkeit

SLICK definiert ein Standardmodell, das es allen im Unternehmen ermöglicht, in Sachen Zuverlässigkeit die gleiche Sprache zu sprechen. Dies macht es für neue Service-Inhaber nahtlos, unternehmensweiten Standards zu folgen. Es ermöglicht ihnen auch, in den frühen Phasen der Einführung und Gestaltung des Dienstes über die Serviceerwartungen nachzudenken.

SLICK kann uns helfen, Metrik- und Leistungsdaten bezüglich der Zuverlässigkeit eines bestimmten Dienstes zu finden, indem er nur seinen Namen kennt. Dazu wird ein Index der integrierten Dienste erstellt, der mit Dashboards mit Standardvisualisierungen verknüpft ist, um die Dienstzuverlässigkeit zu analysieren und zu bewerten. So kann mit einem einzigen Klick festgestellt werden, ob ein Service derzeit die Erwartungen der Benutzer erfüllt oder nicht. Dann können wir anfangen zu fragen warum.

Eine Beispielsuche im SLO-Index von SLICK.

Langzeiteinblicke

Fragen zur Servicezuverlässigkeit können äußerst komplex sein. In einigen Fällen kann eine einzelne fehlerhafte Bereitstellung oder ein fehlerhafter Code dazu führen, dass ein Dienst plötzlich zurückfällt. Während sich in anderen Fällen kleine, inkrementelle Änderungen einschleichen können, während sich der Dienst weiterentwickelt.

SLICK ermöglicht es Service-Eigentümern, Metrik- und Leistungsdaten mit vollständiger Granularität mit einer Aufbewahrungsdauer von bis zu zwei Jahren zu nutzen. Der Speicherprozess in SLICK erfolgt periodisch über eine stündlich ausgeführte Datenpipeline, die alle Daten der SLI-Zeitreihen erfasst und in einer geshardten MySQL-Datenbank speichert. Das System analysiert diese dann, um Erkenntnisse über Verbrauchsmaterialien zu gewinnen. Dies ermöglicht es jedem – von Ingenieuren über TPMs bis hin zu Führungskräften –, Trends im Laufe der Zeit zu verstehen, die einen Rückgang der Servicezuverlässigkeit aufdecken könnten, der andernfalls unbemerkt bleiben könnte.

Arbeitsabläufe

Um den Wert zu steigern und uns zu helfen, neue langfristige Erkenntnisse für die Entscheidungsfindung zu nutzen, müssen SLIs und SLOs in einer Sprache verfasst sein, die jeder versteht und bei der Planung und Bewertung der Auswirkungen verwendet. Um dies zu ermöglichen, haben wir SLOs in gängige Workflows integriert.

Wenn ein groß angelegter Vorfall auftritt, können Servicebesitzer parallel bewerten, wie sich dies auf die gesamte Benutzererfahrung auswirkt. Sie können dies tun, indem sie sich SLOs in unserem Bereitschaftstool ansehen. Auf der anderen Seite können wir SLOs auch verwenden, um den Prozess der Meldung eines großen Vorfalls voranzutreiben. Wir initiieren dies, indem wir SLOs als Kriterien für Vorfälle im Unternehmen verwenden. Viele unserer Systeme verwenden diese Kriterien, um über Probleme informiert zu werden, die ihre Benutzer sehen.

Im Wesentlichen schafft die Integration von SLIs und SLOs in andere Tools einfache Wege zum Onboarding in SLICK (für einen noch nicht Onboarding-Dienst) oder um effektive Einblicke auf zugängliche und einfach zu nutzende Weise zu erhalten.

SLICK-Onboarding

Unsere Service-Owner an Bord von SLICK, indem sie eine Bearbeitungsoberfläche verwenden oder eine einfache Konfigurationsdatei schreiben, die einer DSL mit Informationen wie dem Namen des Service und Abfragen für die SLI-Zeitreihen zusammen mit den jeweiligen SLOs folgt.

Beispielcode Nachdem der Benutzer die Konfiguration getestet und festgeschrieben hat, fügt SLICK den Dienst automatisch seinem Index hinzu. Anschließend generiert es ein servicespezifisches Dashboard und beginnt mit dem Sammeln von Daten für langfristige Erkenntnisse. Ab diesem Zeitpunkt werden alle Integrationen sofort einsatzbereit sein.

Verwendung von SLICK

1) Dashboards

SLICK-Dashboards bieten Service-Eigentümern die Möglichkeit, Echtzeit-SLI-Daten sowie historische Trends auf der Grundlage von Langzeitdaten mit hoher Speicherkapazität zu überwachen.

Beispielansicht von SLICK UIDie linke Seite zeigt die SLI-Zeitreihen in voller Granularität. Die rechte Seite zeigt die wöchentliche zeitbasierte Aggregation der SLI-Werte gegen den SLO.

2) Periodische Berichte

SLICK bietet Ingenieuren die Möglichkeit, Berichte mit Zusammenfassungen ihrer SLO-Leistung zu erhalten. Diese Berichte werden regelmäßig an interne Gruppen gepostet. Die Berichte dienen Service-Eigentümern als einfache Möglichkeit, Regressionen im Auge zu behalten und Retrospektiven durchzuführen. Wir haben oft gesehen, wie Service-Inhaber in den Kommentaren zu diesen Posts über die Zuverlässigkeit nachgedacht haben.

Ein SLICK-Bericht, der die SLO-Leistung in der letzten Woche zeigt.Ein SLICK-Beispielbericht, der die SLO-Leistung über eine Woche zeigt.

3) CLI

SLICK bietet eine Befehlszeilenschnittstelle, die es Dienstinhabern ermöglicht, einige Operationen durchzuführen, wie beispielsweise das Auffüllen von Daten, das Erstellen eines Berichts bei Bedarf oder das Testen der Auswirkungen von Änderungen auf SLICK-Konfigurationen.

SLICK-Architektur

Gesamtarchitektur

SLICK: Einführung von SLOs für verbesserte Zuverlässigkeit

  • SLICK-Konfigurationen: Eine mit SLICKs DSL geschriebene Konfigurationsdatei, die vom Benutzer an den SLICK-Konfigurationsspeicher übergeben wird.
  • SLICK Syncer: Ein Dienst, der an SLICK-Konfigurationen vorgenommene Änderungen mit dem Konfigurationsmetadatenspeicher von SLICK synchronisiert.
  • SLICK UI: Dies sind die generierten SLICK-Dashboards für jeden Dienst. Die SLICK UI stellt auch den oben erwähnten Index bereit.
  • SLICK-Dienst: Ein Server, der eine API bereitstellt, die Abfragen wie „Wie berechnet man das SLO für eine bestimmte Visualisierung?“ beantworten kann. Der Server ermöglicht es uns, alle Details rund um die Datenplatzierung und das Sharding zu abstrahieren, und ermöglicht dem Anrufer, die benötigten Daten leicht zu finden.
  • SLICK Data Pipelines: Pipelines, die regelmäßig laufen, um SLI-Daten langfristig zu erfassen.

Vergrößern der Datenaufnahme

Diagramm zur Funktionsweise von SLICK

SLICK verfügt über Datenpipelines, die stündlich ausgeführt werden. Diese Pipelines finden die Abfragen für alle SLIs, indem sie den Konfigurationsmetadatenspeicher von SLICK konsultieren. Die Pipelines führen alle erforderlichen Abfragen für unsere Überwachungsdatensätze aus, um die rohen Zeitreihendaten für jede dieser SLIs für die Stunde mit einer Granularität von einer Minute zu erhalten.

Die Pipelines konsultieren dann die SLICK-Shard-Map, um zu ermitteln, wo die Daten jedes SLI platziert werden sollten, und fahren mit dem Masseneinfügen der Daten in den entsprechenden Shard fort.

Darüber hinaus führen wir Datenqualitätsprüfungen durch, um uns Vertrauen in die Funktionsweise unserer Datenpipelines zu geben und Fehler bei der Richtigkeit schnell zu erkennen. Die Datenqualitätsprüfungen werden gegen eine Reihe deterministischer Testzeitreihen durchgeführt. Wir behandeln diese deterministischen Zeitreihen wie echte SLIs, dh wir lassen die Pipelines gegen sie laufen und sie werden in die Shard-DB eingefügt. Anschließend vergleichen wir die Zeilen in der DB mit den erwarteten Zeitreihen, um das Verhalten des Systems zu überprüfen.

Aktueller Stand der SLOs bei Meta mit SLICK

Nach dem Aufbau von SLICK im Jahr 2019 konnten wir bis 2021 eine unternehmensweite Einführung feststellen, wobei mehr als 1.000 Dienste in SLICK integriert wurden. Wir haben auch viele Erfolgsgeschichten über Zuverlässigkeit im Unternehmen beobachtet und einige davon im Folgenden geteilt. Bitte beachten Sie, dass die folgenden Diagramme aus Vertraulichkeitsgründen simulierte Daten verwenden, dh wir haben die Daten entfernt und die Werte geringfügig geändert, die Gesamtform der Diagramme bleibt jedoch unverändert.

LogDevice: Regressionen erkennen und beheben (Beispiel)

LogDevice ist unser verteiltes Log-Speichersystem. Mithilfe von SLICK konnten die Dienstbesitzer eine Regression in der Leseverfügbarkeit feststellen. Das Team behob dann die Probleme, die die Regression verursachten, und bestätigte über SLICK, dass die Fehlerbehebungen die Service-Levels für die Leseverfügbarkeit wiederhergestellt haben.

Zuverlässigkeit von LogDevice (Leseverfügbarkeit).  Nicht maßstabsgetreuZuverlässigkeit von LogDevice (Leseverfügbarkeit). Die Grafik ist nicht maßstabsgetreu und dient nur zu Diskussionszwecken.

Beispiel für die Zuverlässigkeit von Back-End-ML-Diensten

Eines der kritischen Back-End-ML-Systeme bei Meta erlebte im Jahr 2020 einen erheblichen Rückgang der Zuverlässigkeit. Dies betraf einen der ML-Dienste, der unsere Endbenutzer in allen unseren Apps betrifft.

Die SLICK-Daten zeigten, dass sie ihr SLO konsequent nicht einhielten, sodass das Serviceteam diese Regression erkennen konnte. Diese Daten halfen dabei, eine Zuverlässigkeitsüberprüfung anzustoßen, die ihnen wiederum half, die Ursache der Zuverlässigkeitsprobleme zu untersuchen, zu finden und zu beheben. Das Team befasste sich mit der Grundursache, und der Dienst nahm wieder sein SLO auf.

Mitbringsel von unserer Reise

Wir haben auf unserer Reise mit SLOs einen langen Weg zurückgelegt und dabei einige Lektionen gelernt:

  • Die Fähigkeit zur langfristigen Verfolgung ist äußerst wertvoll, da sie uns hilft, Trends zu verstehen. So können wir Zuverlässigkeitsarbeiten über einen längeren Zeitraum planen.
  • SLOs müssen im Zentrum der Ingenieurskultur leben, sowohl in der strategischen Zuverlässigkeitsplanung als auch im täglichen Gespräch.
  • Die Einführung von SLOs trug dazu bei, die allgemeine Zuverlässigkeit unserer Dienste zu stärken.

Das SLICK-Team wird weiterhin daran arbeiten, die Plattform weiterzuentwickeln, um mehr Wert zu bieten. Insbesondere hoffen wir, in folgende Bereiche zu investieren:

  1. Ausrichten der SLOs der Dienste mit den SLOs ihrer Abhängigkeiten. Auf diese Weise können Teams verstehen, wie sich ihre Abhängigkeiten auf ihre Leistung auswirken. Es wird uns auch dabei helfen, nicht übereinstimmende Erwartungen zwischen den Diensten im gesamten Stack aufzudecken, die kaskadierende Fehler auslösen könnten.
  2. Geben Sie Service-Inhabern Feedback und Vorschläge zur Verbesserung der Zuverlässigkeit ihrer Services. Wir möchten unsere Erfahrungen aus der Vergangenheit mit der Verbesserung der Zuverlässigkeit nutzen, um Service-Eigentümern umsetzbare Erkenntnisse zu liefern, damit sie ihre Zuverlässigkeit steigern und ihre SLOs einhalten können.
  3. Erhebliche Skalierung von SLICK. Wir hoffen, mehr Teams und Dienste in SLICK integrieren zu können. Um dies zu erreichen, muss SLICK zuverlässig und skalierbar bleiben (wir müssen unsere eigenen SLOs erfüllen!).

Comments are closed.