Wie definierst du ein SLI, ein SLO und ein SLA, und wie hängen die drei zusammen?

Ein SLI ist ein gemessener Indikator für das Verhalten eines Service, etwa der Anteil der Requests, die unter 300ms ausgeliefert werden. Ein SLO ist das interne Ziel für diesen Indikator, zum Beispiel 99,9% der Requests unter 300ms über 28 Tage. Ein SLA ist der externe Vertrag mit Kunden, meist mit finanziellen Konsequenzen, und es sollte lockerer sein als dein SLO, damit du Luft hast, bevor du jemandem Geld schuldest.

Ein SLI ist die Messung, ein SLO das Ziel, und ein SLA das Versprechen, das du verkaufst. In meinem letzten Team war das SLI für unsere Checkout-API der Anteil der Requests, die in unter 400ms einen Status ohne 5xx zurückgaben, gemessen am Load Balancer statt in der App, weil das näher an dem ist, was der User sieht. Das SLO waren 99,9% dieser Requests über ein rollierendes 28-Tage-Fenster. Unser SLA mit Enterprise-Kunden lag bei 99,5% pro Monat mit Service Credits, bewusst lockerer, damit wir ein ganzes Band an Degradation abfangen konnten, bevor es kommerziell wurde. Was Leute übersehen: Das SLI muss eine User Journey sein. Wir hatten ein wunderschönes CPU-Dashboard, und es hat nicht ein einziges Mal einen Ausfall vorhergesagt. Sobald wir auf request-basierte Indikatoren umgestellt haben, konnten wir mit Product tatsächlich über Prioritäten streiten, und zwar anhand derselben Zahlen.