Wdrażanie konfiguracji
1) Dlaczego
Konfiguracja zmienia się częściej niż kod i bezpośrednio wpływa na przychody (routing PSP, limity, współczynniki, cechy przednie) i zgodność (KYC/AML, RG). Potrzebujemy powtarzalnego, weryfikowalnego i odwracalnego procesu dostarczania konfiguracji do żywności, z ścisłą tolerancją i możliwością obserwacji.
2) Zasady
1. Konfiguracja jako Dane: konfiguracje - dane wersjonowane (YAML/JSON), a nie „kliknięcia ręczne”.
2. Schemat pierwszy: każdy wpis jest walidowany na podstawie schematu (JSON Schema/Protobuf).
3. Zasady jako kod: bramy, tolerancje, SoD - w repozytorium polityki.
4. GitOps: jedynym źródłem prawdy jest Git; klastry są dopasowane przez pojednawcę.
5. Stopniowa dostawa: walcowanie kanaryjskie, według segmentu (GEO/najemca/bank/dostawca).
6. Zero-przestoje: przełączniki atomowe, podwójne buforowanie, kompatybilność formatu.
7. Obserwowalność według projektu: audyt, mierniki aplikacji, detektor dryfu.
8. Bezpieczeństwo: minimalne uprawnienia, sekrety oddzielnie, SoD/4-eyes dla ryzykownych zmian.
3) Model konfiguracyjny
Statyczne: rzadko zmieniają się, wymagają zwolnienia (porty, timeouts jądra).
Dynamiczny: używany bez ponownego uruchomienia (routing PSP, funkcje, limity).
Sekrety: klucze/żetony; oddzielną pętlę (KMS/Secret Manager).
Artefakty: pliki reguł/mapowania (BIN → bank, GEO → PSP, limity bonusowe).
Adresowanie kluczy: „najemca”, „region”, „środowisko”, „usługa”, „wersja”, „segment” (psp/bank_group/device).
4) Formaty i systemy
Przykład programu (schemat JSON, routing płatności):json
{
"$schema": "https://json-schema. org/draft/2020-12/schema",
"title": "pspRouting",
"type": "object",
"properties": {
"version": {"type": "string"},
"rules": {
"type": "array",
"items": {
"type": "object",
"required": ["geo","binGroup","primary","fallback"],
"properties": {
"geo": {"type":"string"},
"binGroup":{"type":"string"},
"primary":{"type":"string"},
"fallback":{"type":"array","items":{"type":"string"}},
"limits":{"type":"object","properties":{"perMinute":{"type":"integer"}}}
}
}
}
},
"required": ["version","rules"]
}5) Cykl życia (GitOps)
1. Autoryzacja: PR do repozytorium konfiguracyjnego: data + ticket/change link.
2. Lint/Validate: CI: schematy, referencje, semantyka (zasady konfliktu), dry-run na stoisku.
3. Bramy zasad: SoD/4-eyes, klasa ryzyka, zamrażanie okien, zgodność ze stanem SLO.
4. Zastosowanie etapu: test integracyjny run/syntetyka, SLI sprawdzić.
5. Stopniowa dostawa: kanarki spożywcze (1-5%) → 25% → region/najemca → 100%.
6. Po monitorowaniu: 30-60 min metrów/wpisów; ustalanie wyniku.
7. Promocja/Rollback: znaki wydania, szybki zwrot za pośrednictwem Git revert/” poprzednia wersja„
6) Strategie kroczące
Kanaryjski według segmentu: 'najemca = A, geo = TR, bank = BIN _ XXXX'.
Według regionu: UE → LATAM → APAC, biorąc pod uwagę godzinowe szczyty.
Według funkcjonalności: włączenie flagi (flagi funkcji) z barierkami (TTL, limity zasięgu).
Niebieski/zielony dla źródła konfiguracji: przełączanie czytników na nowy migawkę.
7) Dynamiczne obciążenie i kompatybilność
Hot reboot (obserwatory/konsuli/OTel Kolektor rurociągu przeładowania).
Podwójny format (v1 + v2): oba są czytane przez producentów, piszą do nowego.
Spójność: Wersja w API odpowiedzi/metryki, aby zobaczyć „kto jest na jakiej konfiguracji”.
8) Bezpieczeństwo, tajemnice, SoD
Sekrety oddzielnie: przechowywanie w KMS/Secret Manager, szyfrowanie na poziomie pola, dostęp przez ABAC.
SoD/4-eyes: zmiana trasy płatności/limitów bonusowych/PII-export - tylko poprzez podwójne zatwierdzenie.
Prawa JIT: tymczasowe żetony do operacji, pełny audyt.
Kontrole bezpieczeństwa: linter zabrania PII/kluczy testowych w konfiguracji prod.
9) Walidacje przed użyciem
Schematy (JSON Schema/Protobuf), lintery, kontrole kardynalności.
Semantyka domeny: brak pętli/duplikatów/” czarne dziury”, kompatybilność z bieżącymi zależnościami.
Ruch/symulacje cieni: „drive” nowe routing/zasady na prawdziwym strumieniu jako read-no-write.
Bramka SLO: czerwony SLI → zakaz awansu.
10) Obserwowalność i audyt
Wskaźniki wdrażania: czas aplikacji, sukces, wskaźnik zasięgu, błędy parsowania, rolki.
Wydarzenia: kto/co/kiedy/dlaczego, różnić (w tym ukrywanie tajemnic).
Detektor dryfu: porównanie „co jest w Git” i „co jest w czasie trwania”; ostrzeżenie w przypadku rozbieżności.
Instances-Reference odczytuje 'trace _ id' konfiguracji.
11) Katalog typowych konfiguracji (iGaming)
Routing płatności: PSP według metody GEO/BIN/; limity retrasy; Funkcje 3DS.
KYC/AML: dostawcy, timeouts, TTL, fallback/manual validation rules.
Ryzyko & RG: limity prędkości, czapki dzienne/miesięczne, wyjątki geograficzne.
Gry/Core: współczynniki pamięci podręcznej, rozmiary puli, ficheflagi (historia powtórzeń, nowe tryby).
Operacje/Obserwowalność: progi ostrzegawcze, zasady pobierania próbek, klasy retencji, syntetyka.
Status/Comms: szablony wiadomości, lokalizacje, harmonogram aktualizacji.
12) Pakiet konfiguracji próbki (Manifest)
yaml apiVersion: cfg. platform/v1 kind: ConfigRelease metadata:
id: payments-routing-2025-11-01 change: "RTE-421: reroute TR BIN_4571 → PSP2"
spec:
scope:
tenants: [brandA, brandB]
regions: [EU]
segments:
geo: [TR]
strategy:
steps:
- name: canary coverage: "5%"
duration: "20m"
- name: ramp coverage: "25%"
duration: "30m"
- name: region-full"
coverage: "100%"
gates:
require:
- policy: "slo-green"
- approval: ["Payments Lead","Compliance"]
- freeze: "not-in-effect"
rollback:
to: "payments-routing-2025-10-29"
autoIf:
- metric: "auth_success_rate"
condition: "drop>10% for 10m"13) Rolki i zmiana bezpieczeństwa
Odwróć przez Git: 'wróć '/' promuj previous'
Przełącznik atomowy: czytniki przełączają się na starą migawkę.
Kryteria auto-rollback: degradacja SLI/KRI, wzrost błędów parsowania/walidatora.
Komunikacja: incydent-bot publikuje status podczas auto-rollback.
14) Lokator wielozadaniowy i rezydencja geograficzna
Plik/folder i obszary nazw na poziomie klucza ('lokator/region/").
Polityka czytania: usługi można zobaczyć tylko ich zakres.
Geopisy konfiguracyjne (EU/LATAM/APAC) i opóźnienia replikacji z SLA.
Różne okna dla różnych jurysdykcji (zgodność/wakacje).
15) Wydajność i koszt (FinOps)
Pamięć podręczna migawki: lokalna/rozproszona; TTL/ETag/If-None-Match.
Rozmiar konfiguracji: ograniczenia objętości i głębokości konstrukcji; modularyzacja.
Karta dostępu: najlepsi konsumenci odczytów; optymalizacja częstotliwości ciągnięcia.
Koszt błędów: licznik „drogich” kopnięć/dodatkowych kanarów.
16) Integracje
Alerting/SLO: bramka promocja, auto kickbacks.
Bramki uwolnienia: blokowanie kodu uwalnia, jeśli nie zostanie zakończone uruchomienie konfiguracji.
Bot incydentu: polecenia '/config promote ', '/config rollback', linki do dyfuzów i desek rozdzielczych.
Workflow Engine: ludzkie zadanie dla zmian wysokiego ryzyka; zegary eskalacyjne.
17) Funkcje KPI/KRI
Konfiguracja Lead Time: PR → prod.
Zmiana współczynnika awarii (CFR): procent zmian z odwróceniem.
Incydent konfig MTTR.
Szybkość dryfowania - Git, wskaźnik rozbieżności w czasie trwania.
Szybkość przechodzenia bramek SLO: odsetek zmian, które przeszły bramki bez ręcznych wyjątków.
Koszt na zmianę: CPU/IO, kanarki, incydenty.
18) Plan działania na rzecz realizacji (6-10 tygodni)
Ned. 1-2: katalog konfiguracji, schematów, linterów; Git-repo; wartość początkowa CI (walidacja/różnica).
Ned. 3-4: GitOps-reconciler, dry-run/staging, status-dashboards; ficheflags z TTL.
Ned. 5-6: policy-as-code (SoD/windows/freeze/SLO-gates), canary rolls, auto-rollback.
Ned. 7-8: detektor dryfu, sekrety za pośrednictwem KMS, wielozadaniowe i geopisy, bot incydent integracyjny.
Ned. 9-10: testy walcowania obciążenia/chaosu, raport FinOps, szkolenie zespołu i szablony.
19) Wzory artefaktów
Szablon PR: cel, klasa ryzyka, region (najemca/region), plan kroczący, plan wsteczny, wyniki na sucho.
Pakiet zasad: bramki SLO, SoD/4-eyes, kalendarz zamrożenia, limity wielkości/kardynalności.
Runbook: „jak przeczytać aktualną wersję/diff/stan kanarów”, „jak ręcznie zatrzymać promocję”.
Katalog Config: właściciel, schemat, czytniki, częstotliwość aktualizacji, notatki zgodności.
20) Antypattery
Ręczne edycje „w panelu administracyjnym” bez Git/audytu.
Konfiguracje zmieszane z kodem artefaktu uwalniania, nie-hot swappable.
Brak programów/walidacji upadku → podczas parsowania.
Globalne jednorazowe walcowanie bez kanarów.
Wspólne tajemnice w konfiguracji; tajemnice w Git.
Brak kickbacks/TTL/barierki na ficheflags.
Żadnego detektora dryfującego.
Usunięcie bram SLO „dyżuru” i bez nagrywania.
Razem
Wdrożenie konfiguracji to rurociąg zarządzany: dane z schematami → zasady i bramy → GitOps i progresywna dostawa → ładowanie na gorąco i odwracalność → obserwowalność i audyt → bezpieczeństwo i koszt. Ramy te umożliwiają szybką i bezpieczną zmianę zachowania platformy iGaming, przy jednoczesnym zachowaniu SLO, przychodów i zgodności.