Ressourcenzuweisung

1) Aufgabe und Grundsätze

Die Ressourcenzuweisung ist ein systematischer Weg, um die Nachfrage (Auslastung, Projekte, Vorfälle) mit dem Angebot (CPU/RAM/IO/Netzwerk, Lizenzen, Personen, Budgets) für gezielte SLOs und FinOps-Einschränkungen abzugleichen.

• SLO-first: die Ressource hat ein Qualitätsziel; Auswahl - ein Werkzeug, um es zu ertragen.
• Fairness + Priorität: ein fairer Anteil für alle, aber Garantien haben Priorität.
• Isolation: Wir begrenzen den Blast-Radius von „gefräßigen“ Lasten.
• Elasticity: automatische Erweiterung/Komprimierung für den tatsächlichen Bedarf.
• Cost-aware: Jede zusätzliche Ressource muss einen nachvollziehbaren Effekt auf den SLO/Umsatz haben.
• Evidence-based: Entscheidungen werden durch Telemetrie und Experimente bestätigt.

2) Taxonomie der Ressourcen

Berechnungen: CPU/Memory/GPU, Container-Pools, serverlose Kontingente.
Speicher: IOPS/Durchsatz, heiße/warme/kalte Schichten, Cache.
Netzwerk: egress/ingress, CDN, private Kanäle, IP-Pools.
Daten: Slots/Fensterressourcen in DWH/Streaming, Backfill-Fenster.
Personen: On-Call-Slots, IC/Release, SRE/Dev-Zeit (Stunden/Sprint).
Anbieter: Anbieter-Limits (PSP/KYC/CDN), Rate-Limits und Connects.

3) Priorisierungsmodell (Portfolio)

Tier-0: Vital Flow (Login, Zahlungen). Garantierte Ressourcen, separate Pools.
Tier-1: geschäftskritisch (Cor-Produkt, D-1-Berichte). Bevorzugte Quoten.
Tier-2/3: Unterstützung/Forschung. Burstable, Budgetlimits.
Die Projekte: die Einschätzung Impact × Urgency × Confidence × Cost → der Rang; Abstimmung im CAV/Portfolio.

4) Zuteilungspolitik (Garantien, Quoten, Grenzen)

Garantiert (dedicated): Fix-Anteil/Reserve; für Tier-0/1.
Burstable: Grundquote + das Recht, frei bis zur Grenze zu leihen.
Best-effort: ohne Garantien, kann verdrängt werden.
Quote/Limit-as-Code: Alle Kontingente und Limits werden deklarativ beschrieben (Policy Repository).
Präemption/Pod Disruption Budget: Wer kann verdrängt werden und mit welcher Geschwindigkeit.
Netzwerkkontingente: egress/tenant, Grenzen für Verbindungen zu Anbietern.

5) Multi-Tenant und Isolierung

Namespace/Account per tenant: individuelle Limits, Budget, Audit.
Laute Nachbarn: cgroups/requests/limits/IO-throttling; separate Knoten für „schwere“ Aufgaben.
P95-Isolierung: SLO wird nach Perzentilen berechnet, nicht nach Durchschnitt; burst sollte nicht brechen p95 Nachbarn.
Daten tenancy: getrennte Pools Speicherebenen und Caches für VIP/Regionen.

6) Auto-Skalierung und Elastizität

HPA/VPA/Cluster-Autoscaler: Skalierung durch SLI/SLI-Proxy (Latenz p95, Queue-Tiefe), nicht nur CPU.
Geplante Skalierung: im Voraus für Spitzenfenster/Veranstaltungen.
Warmpools: Erwärmte Knoten/Anschlüsse für schnelle Skalops.
Netzwerk/CDN: Automatische Rebalance nach RUM/Anycast/POP Last.

7) Warteschlangen, Serviceklassen und SLAs

Klassen: 'gold/silber/bronze' mit Zielwartezeit und Fehlerbudget.
Warteschlangen/Busse: Priorisierung, separate Parteien für Tier-0, DLQ.
Backpressure: Drop/Shape/Slow-Disziplinen zum Schutz des Kernels.
Adaptive Timeouts/Retrays: unter Serviceklasse und aktuellem Status.

8) Humanressourcen

Schichten und Abdeckung: Verkehrskonformität (Follow-the-Sun), P1 + P2 Takes auf dem Höhepunkt.
SRE/Dev Fokus: Prozentsatz der Zeit pro Reagenz/Proaktiv (z.B. 50/50) mit KPI.
Ressourcenanfrage: RFC-Vorlagen für Stunden/Sprint, transparente Prioritätswarteschlange.

9) Finanzmodell (FinOps)

Unit-Economy: $/1k Anfragen, $/erfolgreiche Zahlung, $/GiB Logs.
Budgets und Alerts: Quoten nach Konten/Tenanten, Warnungen vor Überausgaben.
Optimierung: Hot/Warm/Cold Storage, Log-Sampling, Spot-Pools für Non-Critical.
Showback/Chargeback: Kostenberichte über Teams/Tenanten motivieren zur Effizienz.

10) Anbieterverwaltung

Limits und Fenster: vertragliche TPS und Warteschlangen bei PSP/KYC/CDN; geplante Fenster im Kalender.
Failover-Profile: Gewichte und Routing zwischen mehreren Anbietern.
Pulsmetriken: Reaktionszeit, Fehlertoleranz, Kosten/erfolgreicher Betrieb.

11) Verteilungsreifemetriken

SLO Adherence nach Klassen:% Compliance in Gold/Silber/Bronze.
Ressourceneffizienz: CPU/RAM/IO Recycling (Median/p95), Anteil idle.
Kosten pro SLO-Punkt: Änderung der Kosten für die Beibehaltung des SLO-Ziels.
Throttling/Präemptionsrate: wie oft und wen wir verdrängen.
Hotspot MTTA: Reaktionszeit bei Pool-/Tenant-Überhitzung.
Fairness Index: Streuung der Verzögerungen/Quoten zwischen den Tenanten (Gini/Variation).

12) Checklisten

Vor der Änderung der Verteilung

• SLO-Ziele und Serviceklasse sind definiert.
• Es gibt Telemetrie nach Belastung (p95/p99, Wachstum, Saisonalität).
• Die Quoten/Limits sind in Git beschrieben und wurden Revue passieren lassen.
• Überprüfte Effekte auf Nachbarn (Isolationstests).
• Der Rollback-Plan und die Guardrails sind fertig.

Wöchentlicher Betrieb

• Heatmap der Poolentsorgung und Hotspot-Report.
• FinOps-Bericht: $/Einheiten, Überschreitungen, Anomalien.
• Provider Limits und SLAs sind erfüllt.
• Warteschlangen: Verzögerung innerhalb der Klassen, kein Fasten.
• CAPA für identifizierte Arbeitsengpässe.

13) Vorlagen (Ideen)

13. 1 Quotenpolitik (YAML)

yaml tenant: vip-eu class: gold compute:
cpu:
request: "8000m"
limit: "12000m"
memory:
request: "16Gi"
limit: "24Gi"
storage:
tier: hot iops_min: 8000 network:
egress_mbps_cap: 500 slo:
latency_p95_ms: 250 preemption:
protected: true burst:
allowed: true max_factor: 1.5

13. 2 Auto-Zoom-Profil (Ausschnitt)

yaml autoscaling:
metric: "queue_depth"   # или biz_sli.payment_latency_p95 target: 200 min_replicas: 6 max_replicas: 60 warm_pool: 4 cooldown_sec: 120

13. 3 Serviceklasse und Warteschlangen

yaml class: gold sla:
wait_p95_ms: 150 queue:
partition: "gold-eu"
retry_policy:
attempts: 2 backoff_ms: 200 backpressure: "shape" # иначе drop/slow

13. 4 Ressourcenantrag (Personen)

RFC: RES-OPS-2025-11
Цель: усилить on-call P2 на пике ноябрьских промо (EU)
Период: 2025-11-25..2025-12-05
Обоснование: прогноз трафика +30%, прошлогодний p95 MTTA ↑
Запрос: +1 P2 слот/сутки, +IC в prime-time

14) Verfahren und Automatisierung

Planner-Bot: Berechnung von Quoten aus der Traffic-Historie und SLO-Zielen, PR in das Policy-Repository.
Guardrails-Bot: Bremslicht für Deploys mit fehlender Quote/Übersubscription.
Der komms-Kahn: die Mitteilungen der Mannschaften die Mehrausgabe/Verdrängung/Wechsel der Klasse.
Anmerkungen: Releases/Service-Fenster ändern die Gewichte/Quoten für die Dauer der Arbeit (Suppression nach dem Entfernen).

15) Anti-Muster

Hervorheben „nach Gefühl“, ohne SLO und Telemetrie.
Ein großer Pool für alle ohne Isolierung der „lauten Nachbarn“.
Unkontrollierte Burst ohne Obergrenze → „ersticken“ Nachbarn.
Keine Backpress/Warteschlangen → Schneeball-Timeouts.
Ignorieren Sie die Kosten von Protokollen/egress - ein „stiller“ Budgetverlust.
Feste Kontingente ohne Saisonalität/Peaks → Unzugänglichkeit oder Überschreitung.

16) Umsetzungsfahrplan (4-8 Wochen)

1. Ned. 1-2: Bestandsaufnahme von Ressourcen und Dienstleistungen; Zuweisung von Klassen (Gold/Silber/Bronze); Primärquoten; Basis-SLOs.
2. Ned. 3-4: Auto-Skalierung über SLI-Proxy aktivieren; Warteschlangen und Backpress einrichten; Isolieren Sie Tier-0 Pools.
3. Ned. 5-6: FinOps Berichterstattung ($/Einheit, Quoten, Budget Alerts); Warm-Pools und bemalte Scales für Spitzentage.
4. Ned. 7-8: Planner/Guardrails Automation, Tenant Cabinet (Quoten-/Value-Sichtbarkeit), vierteljährliche Fairness & Hotspots Überprüfung.

17) Das Ergebnis

Die Ressourcenzuweisung ist kein einmaliges Setup, sondern ein in SLO, Telemetrie und FinOps eingebetteter Live-Prozess. Wenn Prioritäten formalisiert sind, Quoten und Grenzen - wie Code, Isolation und Elastizität - standardmäßig festgelegt sind und Entscheidungen durch Metriken und Kosten bestätigt werden, übersteht das System kontinuierlich Spitzen, schützt kritische Flows und „brennt“ das Budget nicht durch.