SLA/OLA z dostawcami
1) Warunki i granice
SLI - wymierny wskaźnik (dostępność, opóźnienie p99, pomyślnie przetworzone haki internetowe, RPO/RTO).
SLO - docelowa wartość SLI na okno pomiarowe (na przykład 99. 9 %/30 dni).
SLA - prawnie wiążący dokument (procedury SLO + zwrot kosztów).
OLA - wewnętrzne cele i procesy zapewniające zgodność z SLA.
UC (Underpinning Contract) - „substrat” z osobami trzecimi (kanały, centra danych, CDN itp.).
Granice: wyraźnie oddzielić obszar odpowiedzialności dostawcy (chmura/WAF/CDN/brama płatności/dostawca KYC) od obszaru (kod, konfiguracja, ustawienia klienta).
2) Matryca krytyki i wybór modelu
Dostawcy segmentów według wpływu na przedsiębiorstwa:Matryca określa głębokość SLA, zakres kontroli oraz wymagania dotyczące OLA/UC.
3) Mierniki i okna pomiarowe
Dostępność-Procent czasu, że usługa wykonuje zapytania zgodnie z tolerancjami.
Opóźnienie: p95/p99 dla kluczowych operacji; Liczy się „powolny sukces”.
Niezawodność danych: RPO (maksymalna dopuszczalna utrata danych) i RTO (czas odzysku).
Przepustowość/ograniczenia: kwoty gwarantowane (RPS/MBp).
Jakość integracji: udział dostarczonych haków ≤ X minut, udział odpowiedzi 2xx, powtórzeń i deduplikacji.
Okno pomiarowe: miesięczne/toczenie 30 dni, wyjątki (planowane działania) z limitami.
- „Dostępność _ ext = 1 − (Downtime_confirmed_outages/ Total_minutes_in_window)”
- Gdzie awaria jest potwierdzonym niedostępnym stanem przez zewnętrzny monitoring, a nie tylko przez stronę statusu dostawcy.
4) zawartość SLA (szablon sekcji)
1. Przedmiot i zakres (usługi, regiony, wersje API).
2. Definicje (SLI/SLO, „incydent”, „planowana praca”, „siła wyższa”).
3. Cele usług (SLO) według kategorii i regionu.
4. Monitorowanie i baza dowodów: w jaki sposób, czyje czujniki, z jaką częstotliwością.
5. Incydenty i eskalacje: kanały, czas odpowiedzi/aktualizacji, role.
6. Refundacje: kredyty/grzywny/premie, progi, wzory.
7. Bezpieczeństwo i prywatność: DPA, szyfrowanie, dzienniki, powiadomienia o naruszeniu.
8. Zmiany w usłudze: deprecuje, okno powiadomienia, kompatybilność.
9. Ciągłość i DR: RPO/RTO, testy odzysku.
10. Audyt i zgodność: prawo do audytu, sprawozdawczości, certyfikacji.
11. Plan wyjścia: eksport danych, daty, format, pomoc migracyjna.
12. Przepisy prawne: jurysdykcja, siła wyższa, poufność, okres ważności.
5) Przykłady brzmienia (fragmenty)
5. 1 Dostępność i pomiar
"Dostawca zapewnia 99. 95% dostępności w każdym miesiącu kalendarzowym. Dostępność mierzy zewnętrzny monitoring syntetyczny Klienta z ≥ 3 regionów w odstępach ≤ 1 minuty. Odnotowana niedostępność w ≥ 2 regionach jest równocześnie uważana za incydent SEV2 poziomie i liczona w czasie przestoju "
5. 2 Kluczowe opóźnienia API
"p99 czas odpowiedzi" POST/payments/authorize "≤ 450 ms w 95% dni miesiąca. Przedstawiono raport z analizy przyczyny dla odsetka wniosków, które przekraczają próg"
5. 3 Incydenty i eskalacje
"S1: ack ≤ 15 min, aktualizacje co ≤ 30 min, odzyskiwanie docelowe ≤ 2 h; S2: ack ≤ 30 min, aktualizacje ≤ 60 min; S3: Następny Dzień Biznesu. Kanały: telefon 24 × 7, most czatu, e-mail"
5. 4 Refundacje (kredyty)
If Availability_ext <99. 95% → credit 10% monthly fee
< 99. 9% → 25%
< 99. 5% → 50%
Pożyczki nie wykluczają innych metod odszkodowania za szkody spowodowane rażącym zaniedbaniem.
5. 5 Deprekcja i kompatybilność
"Co najmniej 180 dni powiadomienia o zmianach, które łamią zgodność. Jednoczesne wsparcie dla vN i vN + 1 przez co najmniej 90 dni"
5. Wyjście 6
"W ciągu 30 dni od zakończenia, dostawca zapewnia pełny eksport danych w formatach Parkiet/JSON + bezpłatnie; dodatkowe usługi migracyjne - w taryfie X. Zniszczenie kopii potwierdza ustawa"
6) OLA: wsparcie wewnętrzne dla zewnętrznego SLA
Przykład OLA między „Platformą” a „Zespołem Płatniczym”:- Cele: brama p99 ≤ 200 ms, wskaźnik błędu ≤ 0. 3%, DR: RPO 0, RTO 30 min.
- Odpowiedzialność: dyżur SRE, 24 × 7; wspólne deski rozdzielcze i wpisy.
- Procesy: chaos-dym w zwolnieniach, perf-dym na PR, heurystyka cieniowania.
- Bramki: wdrożyć blok, gdy test SLO/xaoc nie powiódł się; obowiązkowa aktualizacja książki startowej.
7) Monitorowanie i dowody
Syntetyka: sondy zewnętrzne (HTTP/TCP), ścieżka użytkownika, „powolny sukces”.
RUM: rzeczywisty monitoring użytkownika w celu potwierdzenia wpływu.
Korelacja: etykiety 'provider', 'region', 'api _ method', 'incident _ id'.
Artefakty: zrzuty ekranu/ścieżki/dzienniki, eksport KPI, linia czasu eskalacji.
rego package policy. sla deny["Release blocked: provider SLO risk"] {
input. release. affects_providers[_] == p input. slo. forecast[p].breach == true
}
8) Incydenty i interakcje
Playbook:1. Klasyfikacja SEV, otwarcie pokoju wojennego, cel IC.
2. Powiadomienie dostawcy za pośrednictwem „gorącego kanału”, transmisja artefaktów.
3. Tryby obejścia/flagi funkcji (stale, cieniowanie, czapka szybkości).
4. Wspólna linia czasu, odzyskiwanie.
5. Akcje postmortem +: aktualizacja limitów konfiguracyjnych, klawiszy, trasy kopii zapasowych.
6. Inicjowanie pożyczek SLA, ustalanie rachunków.
9) Bezpieczeństwo i DPA
DPA/prywatność: role administratora/procesora, kategorie danych, podstawa legalności, terminy/cele przetwarzania, podwykonawcy i ich SLA.
Szyfrowanie: TLS1. 2 +, PFS; dane „w spoczynku”, zarządzanie kluczami (KMS/HSM), rotacja.
Audyt: dzienniki dostępu, powiadomienia o naruszeniu ≤ 72 godziny, raporty pentest na żądanie.
Lokalizacja: region magazynowania, zakaz wywozu bez zgody.
10) Łańcuch dostaw i interoperacyjność
SBOM/luki: polityka progowa CVSS i czas ustalania (krytykowany ≤ 7 dni, wysoki ≤ 14).
Kompatybilność API: testy kontraktowe, piaskownice i stabilne oprawy.
Zmiany dostawcy: notatki wczesnego wydania, podglądy/okna beta, kompatybilność wsteczna.
11) Wielu dostawców i feilover
Aktywny/Aktywny: Trudniejszy i droższy, ale wyższa dostępność (spójność).
Aktywny/pasywny: zimny/ciepły rezerwat, DR. regularne treningi
Abstrakcje/adaptery: pojedynczy kontrakt, zdrowie/koszt/trasa węgla (w stosownych przypadkach).
Warunki licencyjne/handlowe: przenośność, ograniczenie produkcji danych, koszt wyjścia.
12) Plan wyjścia i próby okresowe
Katalog danych/diagramów i woluminy.
Skrypt przenośności SDK/API (minimum - drugie źródło).
Test suchego wyjścia: eksport/import, przywracanie, sprawdzanie niezmienników.
Prawne okresy przechowywania/unieszkodliwiania po zwolnieniu.
13) Badania kontraktowe i zgodność
Próbki API: pozytywne/negatywne, limity, błędy i przekaźniki.
Dostawa wydarzeń/haków internetowych: podpis/czas/dziadek/powtórzenia.
Linie podstawowe PERF: p99, szerokość pasma; testy regresyjne dotyczące informacji o zwolnieniu dostawcy.
Region poprzeczny: degradacja jednego regionu nie powinna naruszać SLO na całym świecie.
14) Anty-wzory
SLA „na stronie stanu” bez pomiarów zewnętrznych.
Te same cele dla wszystkich regionów/punktów końcowych.
Brak praw do audytu i szczegółowe dzienniki incydentów.
Brak OLA/UC → nie ma nikogo do wypełnienia zewnętrznych zobowiązań wewnątrz.
Nieokreślony plan wyjścia → dostawca zakładnik.
„Grzywny tylko przez pożyczki” bez prawa do rozwiązania w przypadku systematycznych naruszeń.
Odbija się bez okna przejściowego.
15) Lista kontrolna architekta
1. Zdefiniowane SLI/SLO dla kluczowych przepływów i regionów?
2. Wybrana zewnętrzna metoda monitorowania i podstawa dowodowa?
3. Czy incydenty, eskalacje, planowane okna pracy i limit wyjątkowy są zapisane w SLA?
4. Czy skala kredytu/kary i prawo do rozwiązania umowy za naruszenia N?
5. DPA/bezpieczeństwo: szyfrowanie, dzienniki, powiadomienia, sub-procesory, lokalizacja?
6. Testy kontraktowe i piaskownice w rurociągu?
7. Wewnętrzne OLAs/UC umożliwiają zewnętrzne układy SLO?
8. DR: RPO/RTO zadeklarowane, szkolenia prowadzone, raporty dostępne?
9. Plan wyjścia: formaty eksportu, czas, praktyka suchego wyjścia?
10. Czy bramy w wydaniach blokujących CI/CD zwiększają ryzyko naruszenia SLA?
16) Mini-przykłady (szkice)
16. 1 Polityka bramkowa w zakresie ryzyka dostawcy
yaml gate: provider-slo-risk checks:
- name: forecasted-slo-breach input: slo_forecast/providers. json deny_if: any(.providers[].breach == true)
action_on_deny: "block-release"
16. 2 Wywóz „dowodów incydentu”
bash curl -s https://probe. example. com/export? from=2025-10-01&to=2025-10-31 \
jq '. {region, endpoint, status, latency_ms, trace_id, ts}' > evidence. jsonl
16. 3 Test Webhook Contract (pseudokoda)
python evt = sign(make_event(id=uuid4(), ts=now()))
res = post(provider_url, evt)
assert res. status in (200, 202)
assert replay(provider_url, evt). status = = 200 # idempotency
Wnioski
SLA/OLA to nie tylko „dokument prawny”, ale architektoniczny mechanizm zarządzania ryzykiem i jakością. Odpowiednie mierniki i okna, zewnętrzny monitoring, przejrzyste procedury incydentu i zwrotu kosztów, wewnętrzne OLA/UC, rurociągowe bramy, wielobranżowe dostawcy i prawdziwy plan wyjścia przekształcić zależność dostawcy w kontrolowaną, wymierną i ekonomicznie przewidywalną część platformy.