Vom Projekt in den Betrieb: Verfügbarkeit messen

Worum es geht

Montag, 7.40 Uhr bei der Brunnwerk IT AG in Frauenfeld. Das Telefon klingelt. Am Apparat ist die Verkaufsleiterin des Möbelherstellers, den Fabio und sein Teamleiter seit letzter Woche betreuen: «Unser Webshop zeigt seit dem Wochenende nur noch eine Fehlermeldung. Ein Kunde hat uns per Mail darauf hingewiesen.» Fabio öffnet das Azure-Portal. Die VM läuft, die CPU liegt bei 3 %, alles ist grün. Und trotzdem verliert der Kunde seit Samstag Bestellungen.

Diese Szene zeigt, worum es in Modul 109 geht. Einen Dienst in der Cloud anzulegen, dauert ein paar Minuten. Ihn so zu betreiben, dass Ausfälle auffallen, bevor die Kundin anruft, dass Daten wiederherstellbar sind, dass niemand mehr Rechte hat als nötig und dass die Rechnung keine Überraschung bringt: Das ist die eigentliche Arbeit. IT-Dienstleister verkaufen genau das als Managed Service und verrechnen dafür eine monatliche Pauschale.

In dieser ersten Lektion verschaffst du dir den Überblick: Welche Aufgaben gehören zum Cloud-Betrieb? Wie liest du die ersten Metriken richtig, ohne dich täuschen zu lassen? Und wie misst du, ob ein Dienst sein Verfügbarkeitsziel erreicht hat? Am Ende rechnest du die Monatsverfügbarkeit des Webshops selbst aus, zuerst von Hand und dann im Code-Labor.

Was Betrieb in der Cloud bedeutet

Stell dir eine Wohnung vor. Der Einzug ist ein einmaliges Ereignis. Danach musst du lüften, putzen, Rechnungen zahlen, den Rauchmelder testen und den Schlüssel nicht jedem geben. In der IT spricht man vom Tag 2: Tag 0 ist die Planung, Tag 1 der Aufbau, Tag 2 ist alles, was danach jeden Tag anfällt. Tag 2 dauert Jahre und macht den grössten Teil der Kosten und der Arbeit aus.

Im Cloud-Betrieb fallen sechs Daueraufgaben an. Jede hat in diesem Kurs eine eigene Lektion:

Wie viel davon bei dir liegt, hängt vom Servicemodell ab (das kennst du aus Modul 346). Bei einer VM (IaaS) betreibt der Anbieter Hardware und Virtualisierung. Alles ab dem Betriebssystem ist deine Sache: Updates, Backup-Konfiguration, Überwachung des Gastsystems, Zugriffe. Ein abgestürzter Webserver-Dienst auf der VM taucht in keiner Statusmeldung von Microsoft auf. Das musst du selbst bemerken.

Erste Blicke: Metriken im Portal lesen

Der einfachste Einstieg ins Monitoring braucht keine Einrichtung. Jede Azure-VM liefert automatisch Plattformmetriken, die der Hypervisor von aussen misst: Percentage CPU, Netzwerk ein und aus, Lese- und Schreibvorgänge der Disks und den verfügbaren Arbeitsspeicher (Available Memory Bytes). Du findest sie auf der Übersichtsseite der VM unter «Überwachung» oder ausführlicher im Metrik-Explorer. Bei AWS zeigt CloudWatch für EC2-Instanzen ebenfalls CPU, Netzwerk und Disk-Werte an, den Arbeitsspeicher aber erst, wenn der CloudWatch-Agent auf der Instanz läuft.

Im Metrik-Explorer stellst du drei Dinge ein:

1. Metrik, z.B. Percentage CPU.
2. Aggregation: Wie werden die vielen Messpunkte eines Zeitabschnitts zu einem Wert zusammengefasst? Möglich sind Durchschnitt (Avg), Minimum, Maximum, Summe und Anzahl.
3. Zeitbereich und Granularität: Über welchen Zeitraum schaust du, und wie gross ist ein Abschnitt (1 Minute, 5 Minuten, 1 Stunde)?

Hier lauert die häufigste Fehlinterpretation. Angenommen, die CPU liegt jeden Morgen um 7 Uhr während 10 Minuten bei 100 % und sonst bei 20 %. Zeigt dir das Diagramm den Durchschnitt pro Stunde, siehst du für die Stunde von 7 bis 8 Uhr nur rund 33 %: (10 × 100 + 50 × 20) / 60 = 33,3. Die Spitze ist verschwunden. Mit Maximum und einer Granularität von 1 Minute wird sie sofort sichtbar.

Eine grüne VM-Übersicht heisst übrigens noch lange nicht, dass der Dienst funktioniert. Beim Webshop aus der Einleitung lief die VM tadellos, nur der Webserver-Prozess war abgestürzt. Die CPU war deshalb sogar besonders tief. Das wichtigste Signal ist darum, ob der Dienst von aussen funktioniert, also so, wie ihn die Kundschaft erlebt. Genau das misst die Verfügbarkeit.

SLA, SLO und SLI: Verfügbarkeit als Zahl

Drei Abkürzungen begegnen dir im Betrieb ständig:

Das SLO liegt bewusst strenger als das SLA. So merkt das Team, dass es eng wird, bevor der Vertrag verletzt ist. In Modul 346 hast du gelernt, wie man aus SLAs der Anbieter die theoretische Verfügbarkeit einer Architektur abschätzt. Im Betrieb geht es um die andere Seite: Wie verfügbar war der Dienst tatsächlich?

Die gemessene Verfügbarkeit berechnest du aus den Ausfallzeiten:

Verfügbarkeit = (Servicezeit - ungeplante Ausfallzeit) / Servicezeit × 100 %

Die Servicezeit ist der Zeitraum, für den die Zusage gilt. Bei 24/7-Betrieb ist das der ganze Kalendermonat: Ein 30-Tage-Monat hat 30 × 24 × 60 = 43 200 Minuten, ein 31-Tage-Monat 44 640. Viele Verträge nehmen angekündigte Wartungsfenster aus. Diese Minuten zählen dann weder als Servicezeit noch als Ausfall. Was genau zählt, steht im Vertrag. Lies ihn, bevor du rechnest.

Aus dem SLO folgt das Fehlerbudget: die Ausfallzeit, die du dir pro Monat leisten kannst. Bei 99,9 % in einem 30-Tage-Monat sind das 0,001 × 43 200 = 43,2 Minuten. Ist das Budget Mitte Monat schon verbraucht, verschiebt das Team riskante Änderungen und kümmert sich zuerst um die Stabilität. So wird aus einer abstrakten Prozentzahl eine konkrete Entscheidungshilfe.

Schritt für Schritt: Die Monatsverfügbarkeit des Webshops

Fabio soll für den September (30 Tage) den ersten Monatsbericht schreiben. Vertraglich gelten 24/7-Betrieb und ein SLO von 99,9 %, angekündigte Wartungsfenster sind ausgenommen. Das Störungsprotokoll zeigt drei Einträge:

Schritt 1: Gesamtzeit bestimmen. 30 × 24 × 60 = 43 200 Minuten.

Schritt 2: Wartung ausnehmen. Die angekündigte Wartung zählt laut Vertrag nicht zur Servicezeit: 43 200 − 25 = 43 175 Minuten.

Schritt 3: Ungeplante Ausfälle summieren. 12 + 48 = 60 Minuten.

Schritt 4: Verfügbarkeit berechnen. (43 175 − 60) / 43 175 = 43 115 / 43 175 = 0,998610, also 99,86 %.

Schritt 5: Mit dem SLO vergleichen. Das Fehlerbudget beträgt 0,001 × 43 175 = 43,2 Minuten. Verbraucht wurden 60 Minuten, das Budget ist also um 16,8 Minuten überzogen. Das SLA von 99,5 % (Budget rund 216 Minuten) ist eingehalten, eine Gutschrift wird nicht fällig.

Schritt 6: Folgerung für den Bericht. Der grösste Posten ist das abgelaufene Zertifikat. Dieser Fehler lässt sich mit einer einfachen Überwachung des Ablaufdatums vermeiden. Fabio schlägt einen Alarm 21 Tage vor Ablauf vor und notiert für den Preisimport eine genauere Analyse (das machst du in Lektion 4).

Dieselbe Rechnung als Python-Funktion. Im Labor erweiterst du sie gleich um das Fehlerbudget:

def verfuegbarkeit(tage, ungeplant_min, wartung_min=0):
    """Gemessene Verfügbarkeit in Prozent, angekündigte Wartung ausgenommen."""
    servicezeit = tage * 24 * 60 - wartung_min        # Schritt 1 und 2
    ausfall = sum(ungeplant_min)                       # Schritt 3
    return round((servicezeit - ausfall) / servicezeit * 100, 3)  # Schritt 4


print(verfuegbarkeit(30, [12, 48], wartung_min=25))   # 99.861

Typische Fehler

• «Die VM läuft, also läuft der Dienst.» Ein abgestürzter Prozess, ein abgelaufenes Zertifikat oder ein voller Datenträger lassen die VM grün aussehen. Miss den Dienst von aussen, so wie ihn die Kundschaft nutzt.
• Durchschnitt über eine Stunde für kurze Probleme verwenden. Spitzen von wenigen Minuten verschwinden im Mittelwert. Für Störungen nimmst du das Maximum bei feiner Granularität.
• Wartung immer abziehen. Ob geplante Arbeiten von der Servicezeit ausgenommen sind, entscheidet der Vertrag, nicht du. Eine spontane, nicht angekündigte «Wartung» ist ein Ausfall.
• SLA und SLO gleichsetzen. Wer intern genau auf das SLA zielt, verletzt den Vertrag beim ersten Ausreisser. Das SLO liegt strenger, damit Zeit zum Reagieren bleibt.
• Mit 730 Stunden rechnen, wenn der Vertrag Kalendermonate meint. 730 Stunden sind ein Durchschnittsmonat für Preisrechner. Für den Monatsbericht zählst du die echten Tage des Monats.

Zusammenfassung

• Cloud-Betrieb umfasst sechs Daueraufgaben: Infrastruktur verwalten, beobachten, alarmieren und reagieren, sichern, absichern und aktualisieren, Kosten kontrollieren.
• Bei IaaS bist du ab dem Betriebssystem selbst verantwortlich, auch für Backup und die Überwachung des Gastsystems.
• Im Metrik-Explorer wählst du Metrik, Aggregation und Granularität. Kurze Spitzen findest du mit Maximum bei feiner Granularität.
• SLI ist die Messung, SLO das interne Ziel, SLA der Vertrag mit Folgen.
• Verfügbarkeit = (Servicezeit − ungeplante Ausfälle) / Servicezeit. Angekündigte Wartung zählt nur dann nicht, wenn der Vertrag das so festlegt.
• Das Fehlerbudget sagt dir, wie viel Ausfall pro Monat noch drinliegt, und hilft bei der Entscheidung, ob riskante Änderungen warten müssen.