Der Betrieb einer skalierbaren verteilten Plattform erfordert ein Engagement für Zuverlässigkeit, um sicherzustellen, dass Kunden das haben, was sie brauchen, wenn sie es brauchen. Abhängigkeiten können ziemlich komplex sein, insbesondere bei einer so großen Plattform wie Roblox. Das Erstellen zuverlässiger Dienste bedeutet, dass ein bestimmter Dienst ungeachtet der Komplexität und des Zustands der Abhängigkeiten ununterbrochen (d. h. hochgradig disponible), wird ohne Fehler funktionieren (d.h. hochwertige Qualität) und ohne Fehler (d.h. Fehlertoleranz).
Warum Zuverlässigkeit wichtig ist
Unser Account Identity-Team ist bestrebt, eine größere Zuverlässigkeit zu erreichen, da die von uns erstellten Compliance-Services Kernkomponenten der Plattform sind. Eine Nichteinhaltung kann schwerwiegende Folgen haben. Die Kosten für die Blockierung der natürlichen Funktionsweise von Roblox sind sehr hoch, da zusätzliche Ressourcen erforderlich sind, um sich von einem Ausfall und einer beeinträchtigten Benutzererfahrung zu erholen.
Der typische Ansatz zur Zuverlässigkeit konzentriert sich hauptsächlich auf die Verfügbarkeit, aber in einigen Fällen werden die Begriffe verwechselt und falsch verwendet. Die meisten Verfügbarkeitsmetriken bewerten einfach, ob Dienste betriebsbereit sind, während Aspekte wie Partitionstoleranz und -konsistenz manchmal übersehen oder missverstanden werden.
Nach dem CAP-Theorem kann jedes verteilte System nur zwei dieser drei Aspekte garantieren. Unsere Compliance-Services opfern daher etwas Konsistenz, um hochverfügbar und partitionstolerant zu sein. Dennoch haben unsere Dienste wenig geopfert und Mechanismen gefunden, um mit angemessenen architektonischen Änderungen, die unten erläutert werden, eine gute Konsistenz zu erreichen.
Der Prozess zur Erreichung einer höheren Zuverlässigkeit ist iterativ, wobei präzise Maßnahmen einer kontinuierlichen Arbeit entsprechen, um Fehler zu verhindern, zu finden, zu erkennen und zu beheben, bevor es zu Zwischenfällen kommt. Unser Team hat einen starken Wert in den folgenden Praktiken identifiziert:
- Genaue Messung – Erstellen Sie eine vollständige Beobachtbarkeit darüber, wie Qualität an Kunden geliefert wird und wie Abhängigkeiten uns Qualität liefern.
- Proaktive Antizipation – Aktivitäten wie Architekturüberprüfungen und Abhängigkeitsrisikobewertungen durchführen.
- Priorisieren Sie die Behebung – Achten Sie mehr auf die Lösung von Vorfallberichten für den Service und Abhängigkeiten im Zusammenhang mit unserem Service.
Der Aufbau größerer Zuverlässigkeit erfordert eine Kultur der Qualität. Unser Team hat bereits in leistungsorientierte Entwicklung investiert und weiß, dass der Erfolg eines Prozesses von seiner Einführung abhängt. Das Team nahm diesen Prozess in seiner Gesamtheit an und wandte die Praktiken als Standard an. Das folgende Diagramm hebt die Komponenten des Prozesses hervor:
Die Macht des guten Maßes
Bevor wir uns eingehender mit Metriken befassen, gibt es eine kurze Erläuterung zu Service-Level-Metriken.
- Das SLO (Service Level Objective) ist das Zuverlässigkeitsziel, das unser Team anstrebt (99,999 %).
- Der SLI (Service Level Indicator) ist die über einen bestimmten Zeitraum erreichte Zuverlässigkeit (d. h. 99,975 % im vergangenen Februar).
- Das SLA (Service Level Agreement) ist die Zuverlässigkeit, zu der wir uns verpflichten und die unsere Verbraucher innerhalb eines bestimmten Zeitrahmens erwarten (d. h. 99,99 % pro Woche).
Der SLI sollte die Verfügbarkeit (keine nicht verwalteten oder fehlenden Antworten), die Fehlertoleranz (keine Dienstfehler) und die erreichte Qualität (keine unerwarteten Fehler) widerspiegeln. Daher haben wir unseren SLI als die „Trefferquote“ erfolgreicher Antworten im Verhältnis zur Gesamtzahl der an einen Dienst gesendeten Anfragen definiert. Erfolgreiche Antworten sind Anfragen, die rechtzeitig und in der Form gesendet wurden, was bedeutet, dass keine
Verbindungs-, Dienst- oder unerwartete Fehler aufgetreten.
Dieser SLI oder Success Ratio wird aus Sicht der Verbraucher (d. h. Kunden) erhoben. Die Absicht besteht darin, die tatsächliche End-to-End-Erfahrung zu messen, die unseren Verbrauchern bereitgestellt wird, damit wir sicher sein können, dass SLAs eingehalten werden. Andernfalls würde ein falsches Gefühl der Zuverlässigkeit entstehen, das alle Infrastrukturprobleme für die Verbindung mit unseren Kunden ignoriert. Ähnlich wie beim Verbraucher-SLI erfassen wir Abhängigkeits-SLI, um potenzielle Risiken zu verfolgen. In der Praxis müssen alle Abhängigkeits-SLAs mit den Dienst-SLAs übereinstimmen, und es besteht eine direkte Abhängigkeit mit ihnen. Das Scheitern eines Menschen impliziert das Scheitern aller. Wir verfolgen und melden auch Metriken des Dienstes selbst (d. h. des Servers), aber das ist nicht die praktische Quelle für hohe Zuverlässigkeit.
Zusätzlich zu SLIs sammelt jeder Build Qualitätsmetriken, die von unserem CI-Workflow gemeldet werden. Diese Praxis kann Qualitätsbarrieren (z. B. Codeabdeckung) stark durchsetzen und andere aussagekräftige Metriken wie die Einhaltung von Codierungsstandards und statische Codeanalyse melden. Dieses Thema wurde bereits in einem anderen Artikel behandelt, Erstellen Sie leistungsorientierte Microservices. Sorgfältige Einhaltung der Qualität trägt zur Zuverlässigkeit bei, denn je mehr wir investieren, um hervorragende Ergebnisse zu erzielen, desto sicherer sind wir, dass das System auch unter widrigen Bedingungen nicht versagt.
Unser Team hat zwei Dashboards. One bietet vollständigen Einblick in Verbraucher-SLI und Abhängigkeits-SLI. Die zweite zeigt alle Qualitätsmetriken. Wir arbeiten daran, alles in einem einzigen Dashboard zusammenzuführen, damit alle Aspekte, die uns wichtig sind, konsolidiert und jederzeit berichtsbereit sind.
Rechnen Sie mit einem Scheitern
Action Architekturbewertungen ist ein grundlegendes Element, um zuverlässig zu sein. Zuerst stellen wir fest, ob Redundanz vorhanden ist und ob der Dienst über die Mittel verfügt, um zu überleben, wenn die Abhängigkeiten fallen. Über typische Replikationskonzepte hinaus haben die meisten unserer Dienste verbesserte Double-Cache-Hydration-Techniken, Double-Recovery-Strategien (z. B. lokale Failover-Warteschlangen) oder Datenverluststrategien (z. B. Transaktionsunterstützung) angewendet. Diese Themen sind umfangreich genug, um einen weiteren Blogeintrag zu rechtfertigen, aber letztendlich ist die beste Empfehlung, Ideen zu implementieren, die Katastrophenszenarien berücksichtigen und Leistungseinbußen minimieren.
Ein weiterer wichtiger Aspekt ist alles, was die Konnektivität verbessern könnte. Das bedeutet, für Clients aggressiv auf niedrige Latenz zu setzen und sie auf sehr hohen Datenverkehr vorzubereiten, indem Cache-Steuerungstechniken, Sidecars und Leistungsrichtlinien für Zeitüberschreitungen, Trennschalter und Wiederholungen verwendet werden. Diese Praktiken gelten für alle Clients, einschließlich Caches, Stores, Warteschlangen und voneinander abhängige Clients in HTTP und gRPC. Es bedeutet auch, gesunde Servicesignale zu verbessern und zu verstehen, dass Zustandsprüfungen eine wichtige Rolle bei der gesamten Container-Orchestrierung spielen. Die meisten unserer Dienste geben im Rahmen des Health-Check-Feedbacks bessere degradierte Signale und überprüfen, ob alle kritischen Komponenten funktionsfähig sind, bevor sie fehlerfreie Signale senden.
Die Unterteilung von Services in kritische und nicht kritische Elemente hat sich als hilfreich erwiesen, um sich auf die Funktionalität zu konzentrieren, die am wichtigsten ist. Früher hatten wir nur für Administratoren bestimmte Endpunkte im selben Dienst, und obwohl sie nicht oft verwendet wurden, wirkten sie sich auf die gesamten Latenzmetriken aus. Die Umstellung auf einen eigenen Dienst hatte einen positiven Einfluss auf alle Messwerte.
Suchtrisikobewertung ist ein wichtiges Instrument zur Identifizierung potenzieller Abhängigkeitsprobleme. Das bedeutet, dass wir Abhängigkeiten mit niedrigem SLI identifizieren und eine SLA-Anpassung anfordern. Diese Abhängigkeiten erfordern bei den Integrationsschritten besondere Aufmerksamkeit. Wir verbringen also mehr Zeit damit, zu evaluieren und zu testen, ob neue Abhängigkeiten für unsere Pläne ausgereift genug sind. Ein gutes Beispiel ist die frühe Einführung von Roblox Storage-as-a-Service. Die Integration mit diesem Dienst erforderte das Einreichen von Fehlertickets und regelmäßige Synchronisierungsmeetings, um Ergebnisse und Feedback zu kommunizieren. Bei all dieser Arbeit wird das Tag „Zuverlässigkeit“ verwendet, damit wir ihre Quelle und Prioritäten schnell identifizieren können. Die Charakterisierung geschah oft, bis wir sicher waren, dass die neue Sucht für uns bereit war. Diese zusätzliche Arbeit hat dazu beigetragen, die Abhängigkeit auf das erforderliche Maß an Zuverlässigkeit zu bringen, das wir durch gemeinsames Handeln für ein gemeinsames Ziel erwarten.
Strukturiere das Chaos
Es ist nie wünschenswert, Zwischenfälle zu haben. Aber wenn sie passieren, müssen aussagekräftige Informationen gesammelt und genutzt werden, um zuverlässiger zu sein. Unser Team verfügt über einen Teamvorfallbericht, der über den typischen unternehmensweiten Bericht hinaus erstellt wird, sodass wir uns auf alle Vorfälle konzentrieren, unabhängig vom Ausmaß ihrer Auswirkungen. Wir nennen die Grundursache und priorisieren alle Arbeiten, um sie in Zukunft zu mindern. Als Teil dieses Berichts beauftragen wir andere Teams damit, Abhängigkeitsvorfälle mit hoher Priorität zu lösen, eine angemessene Lösung vorzunehmen, eine Retrospektive durchzuführen und nach Mustern zu suchen, die auf uns zutreffen könnten.
Das Team produziert a Monatlicher Zuverlässigkeitsbericht nach Service Dazu gehören alle hier erläuterten SLIs, alle Tickets, die wir aufgrund der Zuverlässigkeit geöffnet haben, und alle möglichen Vorfälle im Zusammenhang mit dem Dienst. Wir sind so daran gewöhnt, diese Berichte zu erstellen, dass der natürliche nächste Schritt darin besteht, ihre Extraktion zu automatisieren. Es ist wichtig, diese Aktivität regelmäßig durchzuführen, und es ist eine Erinnerung daran, dass die Zuverlässigkeit ständig überwacht und in unsere Entwicklung einbezogen wird.
Unsere Instrumentierung umfasst benutzerdefinierte Metriken und erweiterte Warnungen, damit wir so schnell wie möglich benachrichtigt werden, wenn bekannte und erwartete Probleme auftreten. Alle Warnungen, einschließlich Fehlalarme, werden wöchentlich überprüft. An diesem Punkt ist es wichtig, die gesamte Dokumentation aufzupolieren, damit unsere Verbraucher wissen, was sie erwartet, wenn Warnungen ausgegeben werden und wenn Fehler auftreten, und dann weiß jeder, was zu tun ist (z. B. Playbooks und die Integration von Richtlinien werden häufig angepasst und aktualisiert).
finale~~POS=TRUNC, Die Einbeziehung von Qualität in unsere Kultur ist der kritischste und entscheidende Faktor, um eine größere Zuverlässigkeit zu erreichen. Wir können beobachten, wie diese Praktiken in unserer täglichen Arbeit bereits Früchte tragen. Unser Team ist von Zuverlässigkeit besessen und das ist unsere wichtigste Errungenschaft. Wir haben unser Bewusstsein dafür geschärft, welche Auswirkungen potenzielle Schwachstellen haben könnten und wann sie eingeführt werden könnten. Dienste, die diese Praktiken implementiert haben, haben ihre SLOs und SLAs konsequent erfüllt. Zuverlässigkeitsberichte, die uns dabei helfen, die von uns geleistete Arbeit nachzuverfolgen, sind ein Beweis für die Arbeit unseres Teams und wertvolle Lektionen, um andere Teams zu informieren und zu beeinflussen. So berührt die Kultur der Zuverlässigkeit alle Komponenten unserer Plattform.
Der Weg zu mehr Vertrauen ist nicht einfach, aber er ist notwendig, wenn Sie eine Plattform des Vertrauens schaffen wollen, die die Art und Weise, wie Menschen zusammenkommen, neu erfindet.
Alberto ist Senior Software Engineer im Account Identity-Team bei Roblox. Er blickt auf eine lange Geschichte in der Gaming-Branche zurück, mit Credits für zahlreiche AAA-Spieletitel und Social-Media-Plattformen mit einem starken Fokus auf hochskalierbare Architekturen. Jetzt hilft er Roblox, Wachstum und Reife zu erreichen, indem er Best Practices für die Entwicklung anwendet.
