Alokacja zasobów
1) Zadania i zasady
Alokacja zasobów jest systematycznym sposobem na dopasowanie popytu (obciążenie, projekty, incydenty) do podaży (CPU/RAM/IO/network, licencje, ludzie, budżety) dla docelowych ograniczeń SLO i FinOps.
Podstawowe zasady:- SLO-first: zasoby mają cel jakościowy; wybór jest narzędziem, aby wytrzymać.
- Sprawiedliwość + Priorytet: sprawiedliwy udział dla wszystkich, ale gwarancje są priorytetem.
- Izolacja: ograniczone obciążenie „żarliwym” promieniem wybuchu.
- Elastyczność: automatyczne rozszerzenie/skurcz dla rzeczywistego zapotrzebowania.
- Świadomość kosztów: Każdy dodatkowy zasób powinien mieć zrozumiały wpływ na SLO/dochody.
- Oparte na dowodach: rozwiązania potwierdzone telemetrią i eksperymentami.
2) Taksonomia zasobów
Przetwarzanie: procesor/pamięć/GPU, puli kontenerów, kontyngenty bezserwerowe.
Przechowywanie: IOPS/przepustowość, ciepłe/ciepłe/zimne warstwy, pamięć podręczna.
Sieć: egress/ingress, CDN, prywatne kanały, baseny IP.
Dane: szczeliny/zasoby okien w DWH/streaming, windows backfill.
Osoby: dyżury, IC/Release, czas SRE/Dev (godziny/sprint).
Dostawcy: ograniczenia dostawcy (PSP/KYC/CDN), limity stawek i połączenia.
3) Model ustalania priorytetów (portfel)
Tier-0: ważny przepływ (login, płatności). Gwarantowane zasoby, indywidualne puli.
Tier 1: biznes krytyczny (produkt podstawowy, raporty D-1). Preferowane kwoty.
Tier-2/3: pomocnicze/badawcze. Pękające ograniczenia budżetowe.
Projekty: Impact × Urgency × Confidence × Cost rating → rank; dopasowanie w SAV/portfelu.
4) Polityka alokacji (gwarancje, kwoty, limity)
Gwarantowane (dedykowane): stały udział/rezerwa; dla Tier-0/1.
Pęknięcie: kwota bazowa + prawo do pożyczki do limitu.
Najlepszy wysiłek: żadnych gwarancji, można zastąpić.
Kontyngent/kod graniczny: wszystkie kwoty i limity są opisane deklaracyjnie (repozytorium polityki).
Preemption/Pod Disruption Budget: Kto może zostać usunięty i z jaką prędkością.
Kwoty sieciowe: egress/najemca, limity połączeń z dostawcami.
5) Wielopoziomowość i izolacja
Obszar nazw/konto na najemcę: indywidualne limity, budżet, audyt.
Hałaśliwi sąsiedzi: grupy/wnioski/limity/IO-throttling; oddzielne węzły do „ciężkich” zadań.
P95-isolation: SLO oblicza się według percentyli, a nie średnich; pęknięcie nie powinno łamać sąsiadów p95.
Najem danych: oddzielne warstwy pamięci masowej i pamięci podręcznej dla VIP/regionów.
6) Automatyczne skalowanie i elastyczność
HPA/VPA/Cluster-autoscaler: skala przez proxy SLI/SLI (latency p95, głębokość kolejki), nie tylko procesor.
Planowane skalowanie: z góry dla okien/zdarzeń szczytowych.
Ciepłe baseny: rozgrzewane węzły/połączenia dla szybkich skalapek.
Sieć/CDN: automatyczna odbudowa przez obciążenie RUM/Anycast/POP.
7) Kolejki, klasy usług i SLA
Klasy: „złoto/srebro/brąz” z docelowymi czasami oczekiwania i budżetami błędów.
Kolejki/autobusy: priorytety, poszczególne partie dla Tier-0, DLQ.
Ciśnienie wsteczne: kropla/kształt/powolne dyscypliny w celu ochrony jądra.
Czasy adaptacyjne/przekaźniki: dla klasy usług i aktualnego stanu.
8) Zasoby ludzkie
Zmiany i zasięg: mecz ruchu (follow-the-sun), P1 + P2 podwaja się w szczycie.
SRE/Dev focus: procent czasu na odczynnik/proaktywny (np. 50/50) z KPI.
Zasoby żądania: szablony RFC na godziny/sprint, przezroczysta kolejka priorytetowa.
9) Model finansowy (FinOps)
Gospodarka jednostkowa: żądania $/1k, $/udana płatność, dzienniki $/GiB.
Budżety i wpisy: kwoty dla rachunków/najemców, ostrzeżenia o nadmiernych wydatkach.
Optymalizacja: przechowywanie na gorąco/ciepło/na zimno, pobieranie próbek dziennika, puli punktowe dla niekrytycznych.
Showback/Chargeback: Raporty kosztów zespołu/najemcy motywują wydajność.
10) Zarządzanie dostawcą
Limity i okna: kontrakt TPS i kolejki w PSP/KYC/CDN; zaplanowane okna w kalendarzu.
Profile awaryjne: wagi i trasy między wieloma dostawcami.
Wskaźniki impulsów: czas reakcji, odporność, koszt/udana operacja.
11) Wskaźniki zapadalności dystrybucji
SLO Adherence według klasy:% zgodności w złocie/srebro/brąz.
Efektywność zasobów: wykorzystanie procesora/pamięci RAM/IO (mediana/p95), udział bezczynności.
Koszt na punkt SLO: zmiana kosztu utrzymania celu SLO.
Współczynnik przepuszczalności/przedwczesności: jak często i kogo przesuwamy.
Hotspot MTTA: Czas reakcji przegrzania basenu/najemcy.
Wskaźnik rzetelności: Opóźnienie/rozkład kwot między najemcami (gini/variation).
12) Listy kontrolne
Przed zmianą dystrybucji
- Zdefiniowano cele SLO i klasę usług.
- Istnieje telemetria według obciążenia (p95/p99, wzrost, sezonowość).
- Kwoty/limity są opisane w Git i poddane przeglądowi.
- Wpływ na badanych sąsiadów (testy izolacyjne).
- Plan wsteczny i szyny ochronne gotowe.
Tygodniowy pokój operacyjny
- Mapa zagospodarowania basenu i raport hotspot.
- Raport FinOps: $/unit, przekroczenia, anomalie.
- Spełnione są limity dostawców i SLA.
- Kolejki: opóźnienie w obrębie klas, brak postu.
- CAPA poprzez zidentyfikowane wąskie gardła w pracy.
13) Szablony (pomysły)
13. 1 Polityka kontyngentowa (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.513. 2 Profil auto-zoom (fragment)
yaml autoscaling:
metric: "queue_depth" # или biz_sli.payment_latency_p95 target: 200 min_replicas: 6 max_replicas: 60 warm_pool: 4 cooldown_sec: 12013. 3 Klasa serwisowa i kolejki
yaml class: gold sla:
wait_p95_ms: 150 queue:
partition: "gold-eu"
retry_policy:
attempts: 2 backoff_ms: 200 backpressure: "shape" # иначе drop/slow13. 4 Roszczenie o zasoby (ludzie)
RFC: RES-OPS-2025-11
Цель: усилить on-call P2 на пике ноябрьских промо (EU)
Период: 2025-11-25..2025-12-05
Обоснование: прогноз трафика +30%, прошлогодний p95 MTTA ↑
Запрос: +1 P2 слот/сутки, +IC в prime-time14) Procedury i automatyzacja
Bot Planner: obliczanie kwot z historii ruchu i celów SLO, PR do repozytorium polityki.
Guardrails-bot: stop signal to deplors when the quota/oversubscription is insufficient.
Bot comms: powiadomienia zespołów o nadmiernych wydatkach/przejęciu/zmianie klasy.
Adnotacje: zwolnienia konserwacyjne/zmiany wagi/kwot okien na czas pracy (usunięcie tłumienia po).
15) Anty-wzory
Podkreślenie „przez sensację”, bez SLO i telemetrii.
Jeden duży basen dla każdego bez izolacji „hałaśliwych sąsiadów”.
Niekontrolowany wybuch bez górnej granicy → „duszenie” sąsiadów.
Brak pleców/kolejek → kula śnieżna czasu.
Ignoruj koszt kłód/wyjścia - „cichy” wyciek budżetu.
Stałe kwoty bez sezonowości/szczytów → niedostępność lub nadmierne wydatki.
16) Plan działania na rzecz realizacji (4-8 tygodni)
1. Ned. 1-2: wykaz zasobów i usług; przydział klasy (złoto/srebro/brąz) kwoty pierwotne; podstawowe SLO.
2. Ned. 3-4: włącz automatyczne skalowanie za pomocą serwera proxy SLI; Konfiguruj kolejki i backpressure Izoluj puli Tier-0.
3. Ned. 5-6: sprawozdawczość FinOps ($/jednostka, kwoty, wpisy budżetowe); ciepłe baseny i malowane łuski przez szczytowe dni.
4. Ned. 7-8: Planner/Guardrails automation, gabinet najemcy (widoczność kwot/wartości), kwartalny przegląd uczciwości i hotspotów.
17) Sedno sprawy
Alokacja zasobów nie jest jednorazową konfiguracją, ale procesem na żywo wbudowanym w SLO, telemetrię i FinOps. Kiedy priorytety są formalizowane, kwoty i limity - takie jak kod, izolacja i elastyczność - domyślnie, a decyzje są potwierdzane przez metryki i koszty, system stale przetrwać szczyty, chroni przepływ krytyczny i nie „spala się przez” budżet.