aiMOOC

Server Cloud und zuverlässiger IT-Betrieb – Kapazität und Betriebskosten beurteilen

QR-Code

Einleitung

Server Cloud und zuverlässiger IT-Betrieb – Kapazität und Betriebskosten beurteilen

Wie viel Serverleistung benötigt ein Dienst? Wie wächst sein Speicherbedarf? Und wie lassen sich Betriebskosten senken, ohne die Zuverlässigkeit zu gefährden?

In diesem aiMOOC übernimmst Du die Rolle einer angehenden Fachinformatikerin oder eines angehenden Fachinformatikers. Du planst die IT-Infrastruktur eines fiktiven Ausbildungsbetriebs, berechnest Kapazitäten und vergleichst Betriebsszenarien.

Dein Lernauftrag: Entwickle eine nachvollziehbare Entscheidung zu Cloud Computing, Serverkapazität, Monitoring, Datensicherung und IT-Kostenmanagement.

Zielgruppe: Ausbildung in der Fachinformatik, insbesondere Systemintegration und Digitale Vernetzung.

Vorkenntnisse: Grundbegriffe zu Servern, Betriebssystemen und Netzwerken.

Lernzeit: Sechs kurze Lerneinheiten von jeweils etwa 10 bis 15 Minuten sowie vertiefende Aufgaben.

Wichtig: Alle Betriebsdaten, Preise, Leistungswerte und Unternehmensangaben im Ausbildungsfall sind fiktiv. Die Beispiele sind keine realen Angebote oder gemessenen Leistungszusagen.

Sicheres Lernen

Alle praktischen Übungen erfolgen ausschließlich mit erfundenen Daten.

Die Python-Beispiele benötigen keine Cloudkonten, Zugangsdaten, externen Schnittstellen oder Netzwerkverbindungen.

Verwende für die Übungen einen eigenen Rechner oder eine ausdrücklich autorisierte, möglichst netzwerkfreie Lern-VM. Die lokale Simulation erzeugt keine echte Serverlast.

Nicht Bestandteil des Kurses: Tests gegen fremde Netzwerke, produktive Systeme, Kundenumgebungen oder nicht ausdrücklich freigegebene Dienste.

Der Ausbildungsfall: Terminservice Nord

Der fiktive Ausbildungsbetrieb Terminservice Nord betreibt eine Webanwendung zur Organisation interner Schulungstermine.

Der Dienst soll zuverlässig erreichbar sein. Gleichzeitig darf die monatliche Rechnung nicht unnötig hoch ausfallen.

Dein Auftrag: Berechne die benötigte Kapazität, beurteile zwei Betriebsvarianten und begründe Deine Empfehlung.

Kennzahl	Fiktive Annahme
Normale Last	20 Anfragen pro Sekunde
Spitzenlast	75 Anfragen pro Sekunde
Dauer der Spitzenlast	6 Stunden täglich
Kapazität einer Anwendungsinstanz	30 Anfragen pro Sekunde bei angenommener sicherer Zielauslastung
Ausstattung einer Instanz	2 vCPU und 4 GB RAM
Aktiver Datenbestand	600 GB
Monatliches Datenwachstum	5 %
Planungsgrenze für Speicherbelegung	80 %
Betrachtungszeitraum	30 Tage beziehungsweise 720 Stunden
Vergleich	Feste Kapazität gegen bedarfsgerechte Skalierung

Die angenommene Leistung von 30 Anfragen pro Sekunde ist ein fiktiver Benchmarkwert für den Ausbildungsfall. In der Praxis muss sie für die konkrete Anwendung gemessen werden.

Lerneinheit 1: Server, Cloud und Betriebsverantwortung

Lernziel: Du unterscheidest Betriebsmodelle und erkennst, wer welche Aufgaben übernimmt.

Cloud oder eigener Server?

Ein eigener Server benötigt unter anderem Strom, Kühlung, Wartung, Hardwareersatz und Administration.

Bei Cloud Computing können Rechenleistung, Speicher und andere Ressourcen bedarfsgerecht bereitgestellt werden. Cloud bedeutet allerdings nicht, dass alle Betriebsaufgaben automatisch entfallen.

Modell	Typische Verantwortung des Nutzers
IaaS	Betriebssystem, Anwendungen, Konfigurationen und Daten
PaaS	Anwendung, Daten und anwendungsspezifische Einstellungen
SaaS	Nutzung, Zugriffsrechte, Daten und vereinbarte Konfigurationen

Die genaue Verteilung der Verantwortung hängt vom gewählten Dienst und Vertrag ab.

Merksatz: Cloudbetrieb ersetzt nicht das IT-Service-Management.

Videoauftrag: Halte nach dem Video zwei Vorteile der Cloud und zwei verbleibende Aufgaben des IT-Betriebs fest.

Lerneinheit 2: Last und Rechenkapazität

Lernziel: Du leitest aus einer erwarteten Last den rechnerischen Instanzbedarf ab.

Warum ist die Spitzenlast entscheidend?

Ein Load Balancer kann Anfragen auf mehrere geeignete Instanzen verteilen. Dadurch kann die verfügbare Verarbeitungskapazität steigen.

Im Ausbildungsfall kann eine Instanz höchstens 30 Anfragen pro Sekunde innerhalb des angenommenen Leistungsziels bearbeiten.

Berechnung:

Benötigte Instanzen = Aufrunden von Spitzenlast / Kapazität pro Instanz.

75 / 30 = 2,5

Ergebnis: 3 Instanzen für die angenommene Spitzenlast.

Diese Rechnung ist eine Planungsvereinfachung. Sie berücksichtigt beispielsweise keine Datenbankengpässe, Startzeiten, Lastverteilungskosten oder Fehler beim automatischen Skalieren.

Lastprofil visualisieren

Lastsituation	Anfragen/s	Visualisierung	Rechnerisch benötigte Instanzen
Normalbetrieb	20	██	1
Mittlere Beispiellast	45	█████	2
Spitzenbetrieb	75	████████	3

Die mittlere Beispiellast ist ein zusätzliches Rechenszenario und geht nicht in die spätere Monatskostenberechnung ein.

Denkfrage: Warum ist eine niedrige durchschnittliche CPU-Auslastung noch kein Nachweis für ausreichende Kapazität?

Hilfestufe 1: Betrachte den Zeitpunkt der stärksten Nachfrage.

Hilfestufe 2: Überlege, was bei gleichzeitig eintreffenden Anfragen geschieht.

Hilfestufe 3: Prüfe neben der CPU auch RAM, Datenträgerzugriffe, Datenbankantwortzeiten und Netzwerklast.

Begründetes Feedback: Ein Durchschnitt kann kurze Überlastungen verdecken. Deshalb müssen Spitzenwerte, Antwortzeiten und Engpässe gemeinsam betrachtet werden.

Lerneinheit 3: Speicherbedarf und Datenwachstum

Lernziel: Du berechnest den künftigen Speicherbedarf und unterscheidest Kapazitätsplanung von Datensicherung.

Daten wachsen nicht immer linear

Der fiktive Datenbestand beträgt 600 GB und wächst monatlich um 5 %.

Modell:

Datenbestand nach n Monaten = 600 × 1,05 hoch n.

Zeitpunkt	Datenbestand gerundet	Visualisierung
Heute	600 GB	██████
Nach 6 Monaten	804 GB	████████
Nach 12 Monaten	1.078 GB	███████████

Wenn ein provisioniertes Speichersystem höchstens zu 80 % belegt sein soll, ergeben sich folgende Planungswerte:

Zeitpunkt	Benötigte Kapazität
Heute	600 / 0,80 = 750 GB
Nach 12 Monaten	ungefähr 1.347 GB

Wichtig: Eine Kapazitätsreserve ist nicht zwangsläufig abrechnungsrelevant. Ob genutzter oder bereitgestellter Speicher berechnet wird, hängt vom Speicherdienst und seinem Tarifmodell ab.

Backup ist nicht gleich Redundanz

Ein Backup schützt vor Datenverlust, wenn eine brauchbare Sicherung vorhanden ist und eine Wiederherstellung funktioniert.

RAID kann je nach Konfiguration Ausfälle einzelner Datenträger tolerieren. Es ersetzt aber keine unabhängige Datensicherung.

Für die Planung sind zwei Kennzahlen wichtig:

RPO (Recovery Point Objective): Maximal tolerierter Zeitraum, aus dem Daten verloren gehen können.

RTO (Recovery Time Objective): Angestrebte maximale Wiederherstellungsdauer nach einer Störung.

Mini-Aufgabe: Ein Dienst hat ein RPO von vier Stunden. Begründe, weshalb eine tägliche Sicherung allein im Allgemeinen nicht ausreicht, um dieses Ziel zu erfüllen.

Feedback: Zwischen zwei täglichen Sicherungen können deutlich mehr als vier Stunden Datenänderungen liegen. Sicherungsfrequenz, Replikation und Wiederherstellbarkeit müssen zum festgelegten RPO passen.

Lerneinheit 4: Betriebskosten transparent berechnen

Lernziel: Du erstellst ein einfaches, nachvollziehbares Kostenmodell.

Kostenannahmen

Alle folgenden Eurobeträge sind frei gewählte Lernpreise, keine Anbieterpreise.

Kostenart	Angenommener Preis
Anwendungsinstanz	0,12 € pro Instanzstunde
Aktiv genutzter Objektspeicher	0,08 € pro GB und Monat
Eine vereinfachte Backup-Kopie	0,04 € pro GB und Monat
Ausgehender Datentransfer	0,05 € pro GB
Monitoring-Grundbetrag	12 € pro Monat

Weitere Annahmen: 200 GB ausgehender Datentransfer im Monat, 600 GB aktive Daten, eine vollständige Backup-Kopie ohne zusätzliche Versionen.

Nicht enthalten sind beispielsweise Steuern, Support, Lizenzen, Lastverteiler, Netzwerkinfrastruktur, zusätzliche Sicherungsversionen oder einmalige Einrichtungskosten.

Szenario A: Drei Instanzen dauerhaft

3 Instanzen × 720 Stunden × 0,12 € = 259,20 € Rechenkosten.

Szenario B: Bedarfsgerechte Skalierung

An 18 Stunden täglich genügt rechnerisch eine Instanz. Während der übrigen 6 Stunden werden drei benötigt.

Instanzstunden pro Monat:

1 × 720 + 2 × 6 × 30 = 1.080 Instanzstunden.

1.080 × 0,12 € = 129,60 € Rechenkosten.

Dieses idealisierte Modell setzt voraus, dass Instanzen rechtzeitig gestartet und gestoppt werden können und keine weiteren Skalierungskosten anfallen.

Kostenvergleich

Kostenart	Dauerhaft 3 Instanzen	Elastisch 1 bis 3 Instanzen
Rechenleistung	259,20 €	129,60 €
Aktiver Speicher	48,00 €	48,00 €
Backup	24,00 €	24,00 €
Datentransfer	10,00 €	10,00 €
Monitoring	12,00 €	12,00 €
Monatliche Gesamtkosten	353,20 €	223,60 €

Rechnerische Differenz: 129,60 € monatlich.

Die elastische Variante ist in diesem vereinfachten Modell rund 36,7 % günstiger.

Aber: Die günstigere Variante ist nicht automatisch betriebssicherer. Wenn bei geringer Last nur eine Instanz läuft, kann deren Ausfall den gesamten Dienst unterbrechen.

Videoauftrag: Notiere eine Maßnahme zur Kostenkontrolle und eine zur Anpassung überdimensionierter Ressourcen.

FinOps: Kosten sind eine Betriebsaufgabe

FinOps verbindet technische Nutzung, Kostenkontrolle und wirtschaftliche Entscheidungen.

Der FinOps-Ansatz unterscheidet drei wiederkehrende Phasen:

Inform: Nutzung, Kosten und Annahmen sichtbar machen.
Optimize: Technische und wirtschaftliche Verbesserungen prüfen.
Operate: Maßnahmen kontrolliert umsetzen und Ergebnisse messen.

Merksatz: Eine Kostensenkung ist nur sinnvoll, wenn vereinbarte Anforderungen an Leistung, Sicherheit und Zuverlässigkeit weiterhin eingehalten werden.

Lerneinheit 5: Zuverlässigkeit überwachen

Lernziel: Du verwendest passende Betriebskennzahlen und erkennst Zielkonflikte.

Ein zuverlässig betriebener Dienst benötigt Monitoring, Alarmierung, Wartung, angemessene Redundanz und überprüfbare Wiederherstellungsverfahren.

Google beschreibt im Site Reliability Engineering vier zentrale Monitoring-Signale: Latenz, Traffic, Fehler und Sättigung.

Signal	Beispielkennzahl	Fiktiver Messwert	Angenommenes Ziel
Latenz	95. Perzentil der Antwortzeit	450 ms zur Spitze	höchstens 300 ms
Traffic	Anfragen pro Sekunde	75	Planungswert
Fehler	Fehlgeschlagene Anfragen	0,2 %	unter 1 %
Sättigung	CPU-Auslastung	85 % vor Skalierung	möglichst höchstens 70 %

Betriebsbewertung: Die Fehlerrate liegt innerhalb des angenommenen Ziels. Latenz und CPU-Sättigung zeigen dagegen Handlungsbedarf. Zusätzliche Instanzen könnten helfen, aber auch eine langsame Datenbank oder ein anderer Engpass ist möglich.

Wichtig: Diese Schwellen sind Übungsziele, keine allgemeingültigen Normwerte.

Videoauftrag: Erkläre, warum auch bei einem verwalteten Cloud-Dienst Überwachung und klare Betriebszuständigkeiten wichtig bleiben.

Ausfallsicherheit kostet Kapazität

Soll der Dienst auch bei geringer Last mindestens zwei laufende Instanzen besitzen, ändert sich die Kalkulation.

2 × 720 + 1 × 180 = 1.620 Instanzstunden.

1.620 × 0,12 € = 194,40 € Rechenkosten.

Mit den unveränderten Nebenkosten ergibt sich ein Monatsbetrag von 288,40 €.

Die Differenz zur besonders sparsamen elastischen Variante beträgt 64,80 €.

Zwei Instanzen allein garantieren noch keine Ausfallsicherheit: Fehlerdomänen, gemeinsamer Speicher, Datenbank, Load Balancer und Wiederanlauf müssen ebenfalls betrachtet werden.

Denkfrage: Wann würdest Du diese zusätzlichen Kosten empfehlen?

Begründetes Feedback: Wenn die geforderte Verfügbarkeit einen Ausfall einzelner Anwendungsinstanzen überstehen muss, ist mehr Redundanz sinnvoll. Für eine belastbare Empfehlung brauchst Du jedoch ein konkretes Betriebsziel und einen überprüften Architekturentwurf.

Lerneinheit 6: Lokales Kapazitätslabor

Lernziel: Du veränderst Annahmen, visualisierst Ergebnisse und überprüfst Berechnungen mit automatisierten Tests.

Testumgebung 1: Interaktive Offline-Simulation

Voraussetzung: Lokal installiertes Python 3.

Erstelle in einem eigenen Übungsverzeichnis die Datei kapazitaet.py mit folgendem Inhalt.

Führe sie auf einem eigenen Rechner oder in einer ausdrücklich autorisierten, netzwerkfrei konfigurierten Lern-VM aus.

Das Programm verwendet ausschließlich die Python-Standardbibliothek. Es erzeugt weder Netzwerkverkehr noch echte Serverlast und benötigt keine Zugangsdaten.

#!/usr/bin/env python3
"""Offline-Kapazitätslabor mit ausschließlich fiktiven Daten."""
from math import ceil

def berechne(spitze=75, daten=600, wachstum=0.05):
    if not (20 <= spitze <= 1000 and
            0 <= daten <= 100000 and
            0 <= wachstum <= 1):
        raise ValueError("Werte außerhalb des Übungsbereichs")

    stunden = 30 * 24
    spitzenstunden = 30 * 6

    basis_vms = ceil(20 / 30)
    spitzen_vms = ceil(spitze / 30)

    stunden_elastisch = (
        basis_vms * stunden
        + (spitzen_vms - basis_vms) * spitzenstunden
    )

    kosten_neben = (
        daten * 0.08
        + daten * 0.04
        + 200 * 0.05
        + 12
    )

    elastisch = stunden_elastisch * 0.12 + kosten_neben
    fest = spitzen_vms * stunden * 0.12 + kosten_neben
    jahr = daten * (1 + wachstum) ** 12

    return {
        "vms": spitzen_vms,
        "vm_stunden": stunden_elastisch,
        "elastisch": elastisch,
        "fest": fest,
        "ersparnis": fest - elastisch,
        "daten_jahr": jahr,
        "bedarf_heute": daten / 0.8,
        "bedarf_jahr": jahr / 0.8
    }

def balken(euro):
    return "█" * round(euro / 10)

def start():
    print("LOKALES LABOR: keine Cloud-API und keine Netzwerktests.")
    print("Enter = Standardwerte; q = beenden")

    while True:
        eingabe = input("Spitzenlast in Anfragen/s [75]: ").strip()
        if eingabe.lower() == "q":
            break

        try:
            spitze = (
                float(eingabe.replace(",", "."))
                if eingabe else 75
            )

            eingabe = input("Datenbestand in GB [600]: ").strip()
            daten = (
                float(eingabe.replace(",", "."))
                if eingabe else 600
            )

            r = berechne(spitze, daten)

        except ValueError as fehler:
            print("Ungültige Eingabe:", fehler)
            continue

        print("Instanzen zur Spitze:", r["vms"])
        print("Instanzstunden:", int(r["vm_stunden"]))

        print(
            f"Elastisch: {r['elastisch']:.2f} EUR "
            f"|{balken(r['elastisch'])}"
        )

        print(
            f"Fest:      {r['fest']:.2f} EUR "
            f"|{balken(r['fest'])}"
        )

        print(f"Monatliche Differenz: {r['ersparnis']:.2f} EUR")
        print(f"Daten nach 12 Monaten: {r['daten_jahr']:.1f} GB")

        print(
            "Speicherplanung bei 80 % Belegung: "
            f"{r['bedarf_heute']:.1f} bis "
            f"{r['bedarf_jahr']:.1f} GB"
        )

        print(
            "Modellgrenze: Skalierungszeiten, Ausfälle "
            "und Zusatzkosten nicht berücksichtigt.\n"
        )

if __name__ == "__main__":
    start()

Lokaler Start:

python3 -I kapazitaet.py

Die Option -I aktiviert den isolierten Python-Modus. Sie verhindert jedoch nicht selbstständig Netzwerkzugriffe. Die Trennung vom Netzwerk muss über die Testumgebung erfolgen.

Drei Szenarien zum Ausprobieren

Szenario	Spitzenlast	Datenbestand	Erwartete Beobachtung
Basis	75 Anfragen/s	600 GB	3 Spitzeninstanzen; 223,60 € elastisch
Mehr Anfragen	100 Anfragen/s	600 GB	4 Spitzeninstanzen; höhere Kosten
Mehr Daten	75 Anfragen/s	900 GB	Gleiche Instanzzahl; höhere Speicherkosten

Basisaufgabe: Starte den Standardfall und dokumentiere die Ausgabe.

Anwendungsaufgabe: Erhöhe die Spitzenlast auf 100 Anfragen pro Sekunde. Begründe die neue Instanzzahl.

Transferaufgabe: Welche zusätzlichen Kosten und technischen Anforderungen fehlen, wenn Du das Modell für einen tatsächlich ausfallsicheren Dienst verwenden möchtest?

Testumgebung 2: Automatische lokale Selbsttests

Erstelle im selben Verzeichnis die Datei test_kapazitaet.py.

import unittest
from kapazitaet import berechne

class KapazitaetsTests(unittest.TestCase):

    def test_basis(self):
        r = berechne()
        self.assertEqual(r["vms"], 3)
        self.assertEqual(r["vm_stunden"], 1080)
        self.assertAlmostEqual(r["elastisch"], 223.60)
        self.assertAlmostEqual(r["fest"], 353.20)

    def test_mehr_last(self):
        r = berechne(spitze=100)
        self.assertEqual(r["vms"], 4)

    def test_mehr_daten(self):
        a = berechne(daten=600)
        b = berechne(daten=900)
        self.assertGreater(b["elastisch"], a["elastisch"])

    def test_ungueltige_last(self):
        with self.assertRaises(ValueError):
            berechne(spitze=10)

if __name__ == "__main__":
    unittest.main()

Lokaler Start:

python3 test_kapazitaet.py

Erwartetes Ergebnis: Vier erfolgreich abgeschlossene Tests.

Die Tests prüfen das vereinfachte Rechenmodell, nicht die Leistungsfähigkeit eines realen Cloudsystems.

Gestufte Hilfen und begründetes Feedback

Stufe	Hilfe	Feedback
Basis	Prüfe die Rundung von 75 / 30.	2,5 Instanzen sind nicht möglich. Deshalb werden 3 benötigt.
Anwendung	Berechne 100 / 30.	Der Wert 3,33 muss auf 4 Instanzen aufgerundet werden, damit die angenommene Kapazität nicht unterschritten wird.
Transfer	Vergleiche günstigen Betrieb mit Anforderungen an Verfügbarkeit und Wiederherstellung.	Zusätzliche Instanzen, Redundanz, Monitoring und Sicherungen können Kosten verursachen, reduzieren jedoch unter geeigneten Bedingungen das Ausfallrisiko.

Grenze der Simulation: Das Programm bildet ein deterministisches Kosten- und Kapazitätsmodell ab. Es ist kein realer Lasttest, keine Cloudbereitstellung und keine Garantie für Skalierungsverhalten oder Verfügbarkeit.

Interaktive Aufgaben

Quiz: Teste Dein Wissen

Was zeichnet ein elastisches Cloudsystem aus? (Ressourcen können dem Bedarf angepasst werden) (!Alle Server müssen immer vollständig ausgelastet sein) (!Der Speicherbedarf bleibt dauerhaft konstant) (!Es entstehen grundsätzlich keine Betriebskosten)

Wie viele Instanzen benötigt der Ausbildungsfall bei 75 Anfragen pro Sekunde und 30 Anfragen pro Instanz? (3 Instanzen) (!1 Instanz) (!2 Instanzen) (!5 Instanzen)

Wie viele Stunden besitzt der angenommene Abrechnungsmonat mit 30 Tagen? (720 Stunden) (!600 Stunden) (!744 Stunden) (!900 Stunden)

Wie hoch sind die berechneten monatlichen Gesamtkosten der elastischen Basisvariante? (223,60 Euro) (!129,60 Euro) (!259,20 Euro) (!353,20 Euro)

Welche provisionierte Kapazität ergibt sich für 600 GB Daten bei maximal 80 Prozent Belegung? (750 GB) (!480 GB) (!600 GB) (!800 GB)

Wie groß ist der Datenbestand nach zwölf Monaten bei fünf Prozent monatlichem Wachstum ungefähr? (1078 GB) (!630 GB) (!900 GB) (!1500 GB)

Welche Kennzahl beschreibt die Dauer der Bearbeitung einer Anfrage? (Latenz) (!Backupgröße) (!Lizenzkosten) (!Speicherpreis)

Was beschreibt das Recovery Point Objective? (Den maximal tolerierten zeitlichen Datenverlust) (!Die Anzahl der Serverkerne) (!Die monatlichen Cloudkosten) (!Die maximale CPU-Auslastung)

Warum sind Wiederherstellungstests wichtig? (Sie überprüfen die tatsächliche Nutzbarkeit einer Sicherung) (!Sie ersetzen automatisch sämtliche Backups) (!Sie garantieren unbegrenzten Speicherplatz) (!Sie verhindern jede mögliche Betriebsstörung)

Welche Aussage über die Preise des Ausbildungsfalls ist richtig? (Es handelt sich um transparente fiktive Übungspreise) (!Die Beträge sind verbindliche Marktpreise) (!Die Preise gelten für alle Cloudanbieter) (!Die Rechnung enthält sämtliche möglichen Betriebskosten)

Memory

Latenz	Antwortzeit einer Anfrage
Traffic	Anfragenaufkommen eines Dienstes
Sättigung	Annäherung an die Belastungsgrenze
Backup	Gesicherte wiederherstellbare Datenkopie
Skalierung	Anpassung bereitgestellter Ressourcen
RPO	Maximal tolerierter zeitlicher Datenverlust
RTO	Angestrebte Wiederherstellungsdauer
FinOps	Zusammenarbeit für transparente Technologiekosten

Drag and Drop

Ordne die richtigen Begriffe zu.	Thema
Spitzenlast	Zeitweise besonders hohe Nachfrage
Autoskalierung	Automatische Anpassung der Ressourcen
Monitoring	Laufende Beobachtung wichtiger Betriebskennzahlen
Wiederherstellung	Rückführung gesicherter Daten in einen nutzbaren Zustand
Kostenmodell	Nachvollziehbare Zuordnung von Mengen und Preisen

Kreuzworträtsel

Latenz	Wie heißt die Antwortzeit eines Systems?
Backup	Wie nennt man eine gesicherte Datenkopie?
Skalierung	Wie heißt die Anpassung der bereitgestellten Serverkapazität?
Monitoring	Wie nennt man die laufende Überwachung eines IT-Dienstes?
Finops	Welcher Ansatz verbindet Technik und finanzielle Verantwortung für Cloudkosten?
Speicher	Welche Ressource wird für die dauerhafte Aufbewahrung von Daten benötigt?

LearningApps

Lückentext

Die fiktive Basislast beträgt

Anfragen pro Sekunde.

Während der angenommenen Spitzenlast treffen

Anfragen pro Sekunde ein.

Eine Instanz kann im Modell

Anfragen pro Sekunde verarbeiten.

Für die Spitzenlast werden daher

Instanzen benötigt.

Der aktuelle Datenbestand beträgt

GB.

Das monatliche Datenwachstum liegt bei

Prozent.

Die maximale geplante Speicherbelegung beträgt

Prozent.

Die elastische Basisvariante kostet monatlich

Euro.

Die laufende Beobachtung der Betriebskennzahlen heißt

.

Der zeitlich tolerierte Datenverlust wird durch das

beschrieben.

Offene Aufgaben

Bearbeite die folgenden zwölf Aufgaben in aufsteigender Schwierigkeit. Verwende ausschließlich die fiktiven Fallwerte oder eigene ausdrücklich erfundene Daten.

Leicht – Basisaufgaben

Cloud-Skizze: Zeichne eine einfache Architektur mit Webanwendung, Anwendungsinstanzen, Speicher und Backup. Kennzeichne, welche Komponenten überwacht werden müssen.
Instanzrechnung: Berechne den Bedarf für 20, 45 und 75 Anfragen pro Sekunde. Ergänze zu jeder Rechnung eine kurze Begründung.
Speicherdiagramm: Erstelle aus den gegebenen Monatswerten ein kleines Balkendiagramm und beschreibe die Bedeutung einer Kapazitätsreserve.
Betriebskarte: Gestalte eine übersichtliche Karte mit den vier Monitoring-Signalen und jeweils einer passenden Beispielkennzahl.

Standard – Anwendungsaufgaben

Kostenvergleich: Übertrage das Rechenmodell in eine Tabelle, berechne beide Betriebsvarianten und erläutere die Kostendifferenz.
Szenariolabor: Führe die lokale Python-Simulation mit mindestens drei verschiedenen Eingaben aus. Dokumentiere Ergebnisse und Modellgrenzen.
Backupplan: Entwirf für den fiktiven Terminservice einen Sicherungsplan mit RPO, RTO, Sicherungsintervallen und lokal simuliertem Wiederherstellungstest.
Betriebsdashboard: Entwerfe ein Dashboard auf Papier oder mit einem lokalen Grafikprogramm. Erkläre, welche Kennzahlen einen Alarm auslösen sollen.

Schwer – Transferaufgaben

Verfügbarkeitskonzept: Entwickle eine Betriebsvariante, die einen Ausfall einer einzelnen Anwendungsinstanz verkraften soll. Zeichne Fehlerdomänen und dokumentiere verbleibende Risiken.
Dreijahresrechnung: Vergleiche ein fiktives lokales Serversystem mit einem Cloudmodell. Berücksichtige Anschaffung, Energie, Wartung, Personalaufwand, Speicherwachstum und Unsicherheiten.
Entscheidungsvorlage: Verfasse eine begründete Empfehlung für die Ausbildungsleitung. Bewerte mindestens Kosten, Zuverlässigkeit, Datenschutz und Skalierbarkeit.
Modellerweiterung: Erweitere das lokale Python-Modell um mindestens eine zusätzliche Kostenart oder einen Mindestwert von zwei Instanzen. Schreibe dazu eigene automatisierte Tests.

Feedback zu Basis, Anwendung und Transfer

Basis – erfolgreich, wenn: Du verwendest die angegebenen Einheiten, rundest benötigte Instanzen auf und machst die genutzten Annahmen sichtbar. Eine rechnerisch genaue Dezimalzahl ist noch keine technisch bereitstellbare Instanzzahl.

Anwendung – erfolgreich, wenn: Deine Teilkosten zur Gesamtsumme passen und Du fehlende Kostenpositionen benennst. Der Betrag von 223,60 € beschreibt nur das definierte Übungsszenario.

Transfer – erfolgreich, wenn: Du nicht allein die billigste Variante wählst, sondern technische Grenzen, Ausfallfolgen und Zielkonflikte bewertest. Eine teurere Variante kann begründet sein, wenn sie nachweisbar bessere Anforderungen erfüllt.

Lernkontrolle

Bearbeite die folgenden Aufgaben ohne Zugriff auf fremde oder produktive Systeme. Im Mittelpunkt stehen Begründungen, Entscheidungen und die Übertragung des Gelernten.

Veränderte Nachfrage: Die Spitzenlast steigt dauerhaft um 40 Prozent. Erläutere, welche Messungen, technischen Prüfungen und Kostenanpassungen Du vor einer Kapazitätserhöhung vornehmen würdest.
Betriebsentscheidung: Vergleiche die elastische Variante mit einer redundant ausgelegten Variante. Entwickle Kriterien, nach denen sich ein Ausbildungsbetrieb entscheiden sollte.
Engpassanalyse: Die CPU-Auslastung ist gering, aber die Antwortzeiten sind hoch. Erkläre mindestens drei mögliche Ursachen und geeignete Wege zur Eingrenzung.
Wiederherstellbarkeit: Eine Sicherung wurde erfolgreich erstellt, aber noch nie zurückgespielt. Bewerte das Risiko und entwickle einen Testplan mit fiktiven Daten.
Kostentransparenz: Eine angenommene Rechnung überschreitet das Budget. Untersuche, welche Mengen, Tarifannahmen oder Auslastungsänderungen dafür verantwortlich sein könnten.
Verantwortlichkeiten: Ein Cloudanbieter verwaltet die physische Infrastruktur. Erkläre, warum der Ausbildungsbetrieb dennoch eigene Sicherheits-, Daten- und Betriebsaufgaben besitzt.

Lernnachweis

Dein Lernnachweis besteht aus einer kurzen technischen Entscheidungsvorlage mit einem lokal nachvollziehbaren Rechenmodell.

Er sollte folgende Bestandteile enthalten:

Annahmenverzeichnis: Alle fiktiven Last-, Wachstums-, Leistungs- und Preisannahmen mit eindeutigen Einheiten.
Kapazitätsberechnung: Instanzbedarf bei Normal- und Spitzenlast sowie Speicherbedarf heute und in zwölf Monaten.
Kostenvergleich: Zwei nachvollziehbar berechnete Betriebsszenarien inklusive erkennbarer Grenzen und fehlender Kostenarten.
Visualisierung: Mindestens ein Last- oder Speicherdiagramm und eine Kostenübersicht.
Zuverlässigkeitskonzept: Monitoring, mögliche Engpässe, Backup, RPO, RTO und verbleibende Ausfallrisiken.
Lokaler Testnachweis: Eingaben, Ausgaben und Ergebnisse der automatisierten Tests einschließlich einer selbst entwickelten Testvariation.
Begründete Entscheidung: Empfehlung mit Bewertung von Wirtschaftlichkeit, Zuverlässigkeit und Unsicherheit.

Bewertungsvorschlag:

Kriterium	Gewichtung
Fachlich und rechnerisch korrekte Kapazitätsplanung	25 %
Transparente Kostenannahmen	20 %
Bewertung der Zuverlässigkeit	20 %
Funktionierende lokale Simulation und Tests	20 %
Verständliche Visualisierung und reflektierte Empfehlung	15 %

OERs zum Thema

Wikipedia

Weitere Grundlagen: Cloud Computing, Server, Virtualisierung, Load Balancing, Datensicherung, Monitoring, Kapazitätsplanung, Total Cost of Ownership, Service Level Agreement und IT-Grundschutz.

Fachquellen

Die fachlichen Grundlagen wurden anhand folgender Quellen geprüft. Anbieterübergreifende Modelle und Übungen sind von konkreten Produktpreisen zu unterscheiden.

NIST SP 800-145 – The NIST Definition of Cloud Computing: Grundbegriffe und Eigenschaften von Cloud Computing.
Google SRE – Monitoring Distributed Systems: Latenz, Traffic, Fehler und Sättigung als Monitoring-Signale.
FinOps Foundation – Phases: Inform, Optimize und Operate.
Microsoft Azure Well-Architected – Kostenoptimierung: Kostenmodelle, Überwachung und Optimierung von Ressourcennutzung.
AWS – Gemeinsame Verantwortlichkeit: Aufgabenteilung beim Cloudbetrieb.
BSI – CON.3 Datensicherungskonzept: Planung und regelmäßige Überprüfung von Datensicherungen.
Google Cloud – Testing Recovery from Data Loss: Wiederherstellungstests und die Beachtung von RTO und RPO.

Bildnachweise und Medienrechte

Die eingebundenen Bilder stammen aus Wikimedia Commons. Die folgenden Dateiseiten dokumentieren Autorenschaft und Lizenz:

Bilddatei	Urheber	Lizenz
Cloud computing.svg	Sam Johnston	CC BY-SA 3.0
PDC server room.jpg	Johan Fredriksson	CC BY-SA 3.0
Cloud Computing Stack.svg	Sam Johnston	CC0 1.0
Load Balancing divisible tasks.png	M Briand	CC BY-SA 4.0
Backup diagram.svg	Inowen	CC BY-SA 4.0
RAID 10.svg	Wheart, basierend auf Cburnett	CC BY-SA 3.0
Cloud computing layers.svg	Wylve, nach Bikeborg	CC0 1.0

Bei Bearbeitungen von CC-BY-SA-Bildern sind die jeweiligen Lizenzbedingungen, Namensnennung und Hinweise auf Änderungen zu beachten.

Die drei eingebetteten Videos stammen vom verifizierten YouTube-Kanal Google Cloud Tech. Ihre URLs und Inhalte wurden thematisch geprüft. Sie werden ausschließlich über die bereitgestellte Einbettungsmöglichkeit genutzt und nicht als offen lizenzierte OER-Videos bezeichnet. Es gelten die Plattform- und Rechtebedingungen des jeweiligen Angebots.

Hinweis zur Barrierefreiheit: Die Zahlen der selbst erstellten Balkenvisualisierungen sind zusätzlich als Text und Tabellenwerte enthalten. Die Diagramme lassen sich deshalb auch ohne Farbwahrnehmung interpretieren.