Wie Atlassian bei der Betriebsbereitschaft hilft

Stufe 0: Kritische Backbone-Infrastruktur

Ein Service der Stufe 0 bietet unterstützende Infrastruktur- und Shared-Service-Komponenten, ohne die Services der Stufe 1 nicht funktionieren. Komponenten gelten als kritisch, wenn einer der folgenden Punkte auf sie zutrifft:

• Sie sind erforderlich, um einen Service der Stufe 1 auszuführen und damit Benutzer auf ihn zugreifen können
• Sie sind erforderlich, damit sich Kunden bei einem Service der Stufe 1 anmelden können
• Sie werden von Mitarbeitern benötigt, um wichtige Betriebsfunktionen eines Services der Stufe 1 zu unterstützen oder auszuführen, wie zum Beispiel:

— Den Service starten/stoppen/neu starten
— Eine Bereitstellung, ein Upgrade, ein Rollback oder einen Hotfix durchführen
— Den aktuellen Status ermitteln (online/offline/beeinträchtigt)

Stufe 1: Grundlegende Services

Ein Service der Stufe 1 bietet eine wichtige Geschäfts-, Kunden- oder Produktfunktion. Das sind kundenorientierte Services oder geschäftskritische interne Services. Wenn der Service heruntergestuft oder nicht verfügbar ist, verliert das Unternehmen Geld oder ist nicht in der Lage, wichtige Geschäftsfunktionen auszuführen und/oder Funktionen, die aus Kundensicht wichtig sind, gehen verloren. Services der Stufe 1 erfordern rund um die Uhr Support, haben anspruchsvolle SLAs für wichtige Metriken und strenge Startanforderungen.

Stufe 2: Services ohne Kernfunktionen

Ein Service der Stufe 2 bietet einen kundenorientierten Service, der nicht Teil der Kernfunktionalität ist. Services der Stufe 2 bieten zusätzlichen Wert oder eine zusätzliche Benutzererfahrung, die als optional oder "nice to have" angesehen werden.

Ein Service der Stufe 2 umfasst öffentliche Services, die hauptsächlich Marketingzwecken dienen, wie z. B. öffentliche Unternehmens-Websites. Sie bieten Kunden keine direkten Services auf Unternehmensebene und keine internen Services, die von Teams zur Erfüllung ihrer Aufgaben genutzt werden, wie Tools für die Zusammenarbeit, Arbeitsverfolgung und mehr.

Services der Stufe 2 erfordern ggf. nicht rund um die Uhr Support, haben niedrigere SLAs und weniger Startanforderungen.

Stufe 3: Interne oder nicht kritische Funktionen

Ein Service der Stufe 3 bietet einem Unternehmen interne Funktionen oder experimentelle Beta-Services. Diese Stufe kann auch Services beinhalten, bei denen es sich derzeit um experimentelle Funktionen für Early Adopter handelt, bei denen eine Verschlechterung der Servicequalität während der Beta hingenommen wird. Diese Stufe bietet einen SLA-Bucket mit niedriger Priorität für Services, die nur in einem gewissen Rahmen unterstützt werden.

Datenverlust (RPO)

Diese Zahl steht für die maximale Datenmenge, die im Falle eines Serviceausfalls verloren geht. Ein Service der Stufe 0 verliert bei einem Serviceausfall weniger als eine Stunde an Daten.

Servicewiederherstellung (RTO)

Diese Zahl steht für die maximal verstrichene Zeit, bis der Service wieder einsatzbereit ist. Ein Service der Stufe 0 ist in weniger als vier Stunden vollständig wiederhergestellt.

Backups

Wenn ein Service unterbrochen wird, müssen Teams ggf. Backups verwenden, um Daten ab einem bestimmten Zeitpunkt wiederherzustellen. Es ist wichtig, regelmäßig Backups von Daten zu erstellen, einen Wiederherstellungsprozess zu implementieren und die Backup- und Wiederherstellungsprozesse regelmäßig zu testen. Die Backup- und Wiederherstellungsprozesse sollten zuverlässig und effektiv sein. Dokumentation und Tests sind hier essenziell.

Definition von "Erledigt"

• Die Backup- und Wiederherstellungsprozesse sind implementiert
• Die Backup- und Wiederherstellungsprozesse sind dokumentiert und getestet
• Die Sicherungs- und Wiederherstellungsprozesse werden regelmäßig getestet
  

Kapazitätsmanagement

Beschreibe klar, welchen Nutzen der Service den Verbrauchern bietet. Identifiziere insbesondere alle Einschränkungen des Services, die für die Verbraucher gelten. Implementiere Leistungstests, um sicherzustellen, dass der Service erwartungsgemäß funktioniert.

Hier sind einige Beispiele für Informationen, die du testen und den Verbrauchern zur Verfügung stellen kannst.

• Der Service ist auf X Anforderungen pro Sekunde beschränkt
• Der Service garantiert eine Reaktionszeit von X
• Die Funktion X des Services wird regionsübergreifend repliziert oder nicht
• Der Verbraucher sollte nicht X
  — den Service überlasten
  — Dateien hochladen, die größer als X sind

Definition von "Erledigt"

• Servicegrenzen sind bekannt und dokumentiert
• Leistungstests werden durchgeführt, um zu überprüfen, ob die Grenzwerte eingehalten werden
  

Kundenbewusstsein

Unterstützbarkeit ist neben Zuverlässigkeit und Benutzerfreundlichkeit ein wichtiger Aspekt der Servicequalität. Teams müssen Supportprozesse oder eine neue Funktion für einen Service erstellen, bevor er an den Start geht. Unterstützbarkeit kann einen Prozess für den Kundensupport, einen Prozess für die Änderungskontrolle, Unterstützung für Runbooks und andere auf den Support ausgerichtete Elemente umfassen.

Prozess für den Kundensupport

Entwickler müssen verstehen, was passiert, wenn Kunden das Support-Team kontaktieren und sich ihrer Verantwortung in Bezug auf den Support-Prozess bewusst sein. Das kann heißen, Teil eines Bereitschaftsservices zu sein oder Produktionsprobleme zu lösen, sobald sie auftreten.

Prozess für die Änderungskontrolle

Nicht alle Änderungen haben dieselben Auswirkungen auf Kunden. Manche Änderungen sind für Kunden nicht wahrnehmbar. Zum Beispiel ein kleiner Bugfix. Manche verursachen bei der Einführung großen Aufwand beim Kunden, zum Beispiel eine komplette Neufassung einer API. Die Änderungskontrolle hilft dabei, das Ausmaß der möglichen Auswirkungen von Änderungen auf die Kunden einzuschätzen.

Support-Runbooks

Runbooks bieten einen allgemeinen Überblick über die Funktionsweise eines Services sowie detaillierte Erklärungen zu möglichen Problemen und deren Lösung. Runbooks sollten regelmäßig aktualisiert und überprüft werden, ob die dokumentierten Support-Verfahren an Serviceänderungen angepasst sind.

Definition von "Erledigt"

• Eine Dokumentation, welche die meisten relevanten Fragen zur Untersuchung eines Problems durch das Support-Team beantwortet
• Ein funktionierender Prozess für die Änderungskontrolle
  
  

Disaster Recovery

Ein Teil eines Notfalls ist der Verlust einer Availability Zone. Services müssen stabil genug sein, um bei einem Ausfall einer Availability Zone weiterhin normal zu funktionieren. Die Notfallwiederherstellung besteht aus zwei Komponenten: Zum einen, einen Prozess für die Notfallwiederherstellung zu entwickeln und zu dokumentieren, und zum anderen, den dokumentierten Prozess fortlaufend zu testen. Die Notfallwiederherstellung sollte regelmäßig getestet werden. Teste die Fähigkeit, einen Ausfall einer Availability Zone zu bewältigen mithilfe des dokumentierten Plans für die Notfallwiederherstellung.

Definition von "Erledigt"

• Der Plan für die Notfallwiederherstellung wurde dokumentiert
• Der Plan für die Notfallwiederherstellung wurde getestet
• Es sind regelmäßige Tests für den Plan für die Notfallwiederherstellung geplant
  

Protokollierung

Protokolle sind aus einer Vielzahl von Gründen nützlich, z. B. zur Erkennung von Anomalien, zur Untersuchung während oder nach einem Serviceausfall und zur Verfolgung böswilliger Aktivitäten durch das Verknüpfen verwandter Ereignisse in Services mithilfe eindeutiger Identifikatoren. Es gibt viele Arten von Protokollen. Ein paar sehr nützliche Protokolle, welche die meisten Services enthalten sollten, sind:

• Zugriffsprotokolle
• FEHLERPROTOKOLLE

Definition von "Erledigt"

• Passende Protokolle werden generiert
• Protokolle werden einfach auffindbar und durchsuchbar gespeichert
  

Logische Zugriffsprüfungen

Logische Zugriffsprüfungen konzentrieren sich auf die Verwaltung des Zugriffs interner Benutzer, des Zugriffs externer Benutzer, des Zugriffs von Service zu Service und der Datenverschlüsselung. Wie verhindert der Service den unbefugten Zugriff auf Funktionen und Daten? Wie werden Benutzerberechtigungen definiert, verifiziert, aktualisiert und als veraltet gekennzeichnet? Bieten diese Prüfungen ausreichenden Schutz für vertrauliche Daten?

Interne Benutzer

Es gilt, einige wichtige Fragen zu beantworten: Wie werden interne Benutzer authentifiziert? Wie wird der Zugriff gewährt/bereitgestellt? Wie wird er entzogen? Wie funktioniert eine Eskalation von Rechten? Wie sieht der Prozess für regelmäßige Zugriffsprüfungen und Audits aus?

Externe Benutzer

Wie wird die Authentifizierung von Kunden abgewickelt? Wie wird der Zugriff gewährt/bereitgestellt? Wie wird er entzogen? Wie funktioniert eine Eskalation von Rechten? Wie sieht der Prozess für regelmäßige Zugriffsprüfungen und Audits aus?

Von Service zu Service

Ähnlich wie bei internen und externen Benutzern. Teams müssen festlegen, wie sich die Services gegenseitig authentifizieren. Beispielsweise durch die Einrichtung von OAuth 2.0.

Verschlüsselung

Teams möchten Daten bei der Speicherung und Übertragung verschlüsseln. Erkläre, wie Daten vom Service verschlüsselt werden. Wie verwaltet das Team Schlüssel? Was ist die Schlüsselrotationsrichtlinie?

Definition von "Erledigt"

• Logische Zugriffsprüfungen werden für interne Benutzer, externe Benutzer und von Service zu Service dokumentiert, implementiert und getestet
• Ruhende Daten werden verschlüsselt
• In der Übertragung begriffene Daten werden verschlüsselt
• Verschlüsselung ist implementiert und getestet
  

Releases

Die Bereitstellung einer neuen Version des Services sollte den Kunden-Traffic nicht über das im SLA des Services definierte Maß hinaus stören. Alle Änderungen müssen von Experten geprüft, getestet und über CI/CD-Pipelines bereitgestellt werden. Vergewissere dich nach jeder Bereitstellung, dass die Bereitstellung erfolgreich war und keine Funktion beeinträchtigt hat. Eine automatische Überprüfung nach der Bereitstellung wird empfohlen. Mehrere Umgebungen wie Test, Staging, Vorproduktion und Produktion sind von Vorteil, damit Bereitstellungen getestet werden können.

Definition von "Erledigt"

• Der Service wird ohne Ausfallzeit bereitgestellt
• Es gibt Umgebungen, in denen der Service bereitgestellt und getestet werden muss, bevor er in die Produktion geht
  

Sicherheitscheckliste

Die Sicherheitscheckliste besteht aus einer Reihe von Praktiken und Standards für die Entwicklung und Wartung einer sicheren Infrastruktur und Software. Diese Standards reduzieren die Wahrscheinlichkeit von Datenschutzverletzungen und Datenpannen, was wiederum das Kundenvertrauen stärkt. Teams sollten eine Sicherheitscheckliste erstellen, die zur Art des Services passt, den sie entwickeln. Ein paar Beispielanforderungen sind aufgelistet:

Definition von "Erledigt"

• Der Service hat nachweislich keine offenen kritischen oder hohen Sicherheitslücken
• Gespeicherte Daten werden in allen Datenspeichern verschlüsselt
• Der Service lässt nachweislich keine unsicheren HTTP-Verbindungen zu
  

Servicemetriken

Servicemetriken liefern wichtige Status- und Diagnoseinformationen zu einem Service und ermöglichen es Teams, Vorfälle zu überwachen und darauf zu reagieren. Beginne mit dem Definieren einer Reihe von Metriken, die bei jedem Service überwacht werden. Erstelle dann ein Dashboard mit diesen Metriken in einem Tool wie Datadog oder New Relic. Löse Warnmeldungen aus, wenn eine Metrik eine Grenze überschreitet und erstelle im Falle einer Warnmeldung Problemtickets.

Definition von "Erledigt"
Hier sind einige Beispiele für Dinge, die gemessen werden sollten:

• Latenz: Die für die Bearbeitung einer Anfrage benötigte Zeit
• Traffic: Die von externen Benutzern im Service generierten Datenmengen
• Fehler: Die Anzahl der Benutzer beeinflussenden Fehler oder Ausfälle
• Sättigung: Die Auslastung des Services und wie viel dieser noch bewältigt
• Zugrundeliegende Ressourcennutzung: CPU, Arbeitsspeicher, Datenträger
• Interne Anwendungsfunktionen wie Warteschlangen, Anzeigedauern und Fluss
• Nutzung und Kernfunktionen deines Services: aktive Nutzer, Aktionen pro Minute
  

Servicestabilität

Die Anforderungen an die Servicestabilität bestimmen, ob ein Service Lastschwankungen und/oder Ausfälle verschiedener Komponenten verkraftet. Ein stabiler Service skaliert meistens automatisch und ist resistent gegenüber Ausfällen einzelner Knoten.

Automatische Skalierung

Wenn der Service automatisch skalieren kann, stelle sicher, dass die automatische Skalierung richtig konfiguriert und getestet ist. Bestimme, welche Metrik die automatische Skalierung auslöst und teste, ob sie funktioniert. Wenn der Service zum Beispiel das Speichern von Daten auf einem Datenträger erfordert, kann er den Prozentsatz an freiem Speicher auf den Datenträgern überwachen und automatisch skalieren, indem Speicherplatz hinzugefügt wird, wenn der freie Speicher unter einen bestimmten Schwellenwert fällt.

Ausfalltests für einzelne Knoten

Services sollten Ausfälle einzelner Knoten verkraften. Wenn ein einzelner Serviceknoten ausfällt, sollte der Service weiterhin funktionieren, auch wenn nur mit reduzierter Kapazität. Führe Tests durch, indem du mindestens einen Knoten im Service kappst, und beobachte das Systemverhalten. Dein Service sollte den Ausfall eines einzelnen Knotens verkraften. Die Umgebung, in der du den Ausfall eines einzelnen Knotens simulierst, sollte überwacht werden.

Definition von "Erledigt"

• Die automatische Skalierung wurde nachweislich implementiert und getestet
• Die Produktions- und/oder Staging-Umgebungen führen nachweislich mehrere Knoten aus
• Der Service ist nachweislich resistent gegenüber Ausfällen einzelner Knoten
  

Support

Support ist der Prozess zur Unterstützung eines Services nach der Veröffentlichung. Teams müssen über Runbooks, Ops-Tools und Bereitschaftsservices verfügen, bevor das Produkt an den Start geht, damit Services, bei denen Probleme auftreten, über einen Prozess zur Behebung verfügen.

Runbooks

Runbooks bieten Bereitschaftsmitarbeitern den Kontext und die Anweisungen, die sie benötigen, um schnell auf Vorfälle zu reagieren und Behebungsmaßnahmen zu ergreifen.

Ops-Tools

Einen Service einem ausreichenden Standard nach zu betreiben, erfordert einen Bereitschaftsservice und ein Ops-Tool wie Opsgenie, um den Bereitschaftsservice zu benachrichtigen, wenn Probleme

Bereitschaftsdienst

Für einen Service der Stufe 2 bzw. 3 ist ein Bereitschaftsservice erforderlich

Für einen Service d Stufe 1 bzw. 0 ist ein rund um die Uhr erreichbarer Bereitschaftsservice erforderlich

Definition von "Erledigt"

• Runbooks sind vom Support verfasst und abrufbar
• Das Ops-Tool ist konfiguriert und getestet
• Es gibt einen Bereitschaftsservice, der bei Problemen erreichbar ist
  

Für Stufe 3 empfohlene Betriebsbereitschaftsprüfungen

• Backups
• Protokollierung
• Releases
• Sicherheitscheckliste
• Servicemetriken
• Support
  

Services der Stufe 3 beginnen mit den grundlegendsten Anforderungen an die Betriebsbereitschaft.

Für Stufe 2 und Stufe 1 empfohlene Betriebsbereitschaftsprüfungen

• Backups
• Disaster Recovery
• Protokollierung
• Releases
• Sicherheitscheckliste
• Servicemetriken
• Servicestabilität
• Support

Services der Stufe 2 und 1 haben zusätzlich Betriebsbereitschaftsanforderungen an die Notfallwiederherstellung und Servicestabilität. Man sollte beachten, dass Services der Stufe 2 und Stufe 1 unterschiedliche Anforderungen an die Betriebsbereitschaft haben können. Es ist jedoch nicht erforderlich, dass die Stufen unterschiedliche Anforderungen haben. Wenn eine zusätzliche Betriebsbereitschaftsanforderung für eine bestimmte Servicestufe als notwendig erachtet wird, füge sie hinzu. Stufe 2 und Stufe 1 können je nach den Anforderungen des Teams voneinander abweichen.

Für Stufe 0 empfohlene Betriebsbereitschaftsprüfungen

• Backups
• Kapazitätsmanagement
• Kundenbewusstsein
• Disaster Recovery
• Protokollierung
• Logische Zugriffsprüfungen
• Releases
• Sicherheitscheckliste
• Servicemetriken
• Servicestabilität
• Support

Services der Stufe 0 verfügen zusätzlich über Kapazitätsmanagement, Kundenbewusstsein und logische Zugriffsprüfungen.