Kontrola wersji konfiguracyjnej

1) Dlaczego konfiguracje wersji

Konfiguracja jest polityką wykonywalną: definiuje routing, limity, flagi funkcji, dostęp, schematy danych. Kontrola wersji sprawia, że zmiany powtarzalne, obserwowalne i odwracalne: zmniejsza MTTR i wskaźnik awarii zmiany, eliminuje „magię w sprzedaży”, daje audyty bezpieczeństwa i zgodności.

2) Taksonomia konfiguracji

Infrastruktura (IaC): klastry, sieci, LB, DB, kolejki.
Usługa: parametry aplikacji, zasoby, limity czasowe, przekłady.
Logika produktu/biznesu: taryfy, eksperymenty AB, zasady treści.
Dane/Data Ops: programy umów, świeżość SLA, transformacja.
Bezpieczeństwo: zasady dostępu, role, klucze/certyfikaty (same sekrety są poza repo).
Obserwowalność: SLI/SLO, alerty, deski rozdzielcze.

Zasada: wszystko, co wpływa na zachowanie systemu jest konfiguracją i musi żyć w wersji.

3) Zasady weryfikacji

1. GitOps: jedynym źródłem prawdy jest repozytorium; zmiany poprzez rurociągi PR i automatyczne.
2. Deklaracja: opis stanu docelowego, a nie scenariusze krokowe.
3. Niezmienność artefaktów: config → jednoznacznie zmaterializowany migawka.
4. Schematy i walidacja: schemat JSON/YAML, ścisłe odlewanie typu, wymagane pola.
5. Środowiska takie jak kod: „na” - foldery/nakładki (dev/stage/prod), różnice są minimalne i oczywiste.
6. Idempotencja i rolki: cofnij/odwróć dowolną wersję konfiguracyjną.
7. Audyt i identyfikowalność: autor, powód, bilet/RFC, podpisy zmian.

4) Strategie weryfikacyjne

• MAJOR - niekompatybilne zmiany schematu/polityki.
• MINOR - nowe pola/zasady, kompatybilność wsteczna.
• PATCH - naprawia wartości bez zmiany schematów.
• Tag wypuszcza i zwalnia notatki: co się zmieniło, jak cofnąć, punkty kontrolne.
• Pliki pinning/lock: naprawić wersje zależności (moduły, wykresy).
• Wersje macierzy: artefakt aplikacji X jest kompatybilny z konfiguracją Y (matryca w katalogu serwisowym).

5) Organizacja repozytorium

config-repo/
policies/# general policies (RBAC, SLO, alerts)
services/
checkout/
schema/# JSON/YAML configs base/# default values ​ ​ overlays/
dev/
stage/
prod/
data-contracts/# data schemas, SLA freshness releases/# tags, changelog, validation artifacts tools/# linters, generators, tests

Oddział: bagażnik (główny) + krótkie gałęzie funkcji. Połączenie - przez PR tylko z obowiązkowym CI.

6) Walidacja i testowanie

Schemat: Każda zmiana przechodzi walidację schematu (wymagana, enum, zakresy).
Lintery statyczne: format, klawisze, duplikaty, pola zabronione.
Testy kompatybilności: wersja config + usługa/wykres iść w górę w piaskownicy.
Biegi testowe: aplikacje suche, „co-jeśli” diff docelowy stan.
Policy-as-code: zasady przyjmowania (Rego/CEL) - kto może zmienić co.

7) Odwijanie i odwracanie konfiguracji

Progresywna dostawa: kanarka 1% → 5% → 25% ze SLO-gardrails.
Brama rozmieszczenia: brak aktywnych SEV-1, wpisy są zielone, podpisy są ważne, rolka jest gotowa.
Rollback: 'revert tag vX. Y.Z 'lub przełączanie na poprzedni migawkę; polecenia rollback są udokumentowane w książce startowej.
Adnotacje wydania: Wersja konfiguracyjna jest publikowana w metrykach/dziennikach, aby szybko korelować z incydentami.

8) Dynamiczna i zdalna konfiguracja

Zdalne flagi konfiguracyjne/funkcyjne: zmiana parametrów bez ponownego uruchomienia; wszystkie flagi są również pod GitOps.
Granice: które parametry mogą ulec dynamicznej zmianie (lista białych).
Pamięć podręczna i konsystencja: TTL, wersje, wymiana zestawu atomowego (wydawnictwo dwufazowe).
Bezpieczne balustrady: limity i zakresy dla zmian runtime, auto-rollback podczas opuszczania SLO.

9) Tajemnice i dane wrażliwe

Nigdy nie trzymaj tajemnic w repo. W konfiguracjach - tylko linki/znaczniki.
Szyfrowanie plików konfiguracyjnych, w razie potrzeby: integracja z menedżerem secret/key.
Rotacja i JIT: dostęp jest wydawany na czas trwania operacji; ślad działania jest niezmienny.
Maskowanie pola: Walidacja zabrania PII/tajemnic wejścia do konfiguracji.

10) Zarządzanie środowiskiem

Nakładki Base +: różnice między dev/stage/prod są minimalne i przejrzyste.
Promocja artefaktów: ta sama migawka, która przeszła scenę jest promowana w prod.
Okna czasowe: zmiany w konfiguracjach nie występują w momencie zmiany obowiązku; dla wysokiego ryzyka - okno RFC i konserwacji.

11) Wykrywanie i eliminacja dryfów

Kontroler porównuje stan docelowy do stanu rzeczywistego i zgłasza różnicę.
Alerty dryfujące: Strona tylko dla krytycznych rozbieżności; reszta to Bilet.
Automatyczna rekultywacja: w rozdzielczości - powrót do stanu docelowego.
Ręczna edycja audytu: dowolna „kubectl edit/ssh” → incydent procesowy i CAPA.

12) Katalog konfiguracji i własność

Katalog usług: właściciel, SLO, powiązane zasady, schematy, wersje, kompatybilność.
RACI: kto oferuje, kto ocenia, kto zatwierdza; CAB dla wysokiego ryzyka.
Przejrzystość: Każdy wpis ma historię wersji i linki do PR/biletów/AAR.

13) Wskaźniki zapadalności

Zasięg:% usług/polityk dla GitOps (cel ≥ 95%).
Zmiana czasu ołowiu: mediana od PR do prod.
Zmiana szybkości awarii: odsetek zwolnień config z rollback/incydent.
Szybkość dryfowania: liczba rozbieżności/tydzień i czas eliminacji.
Czas wsteczny: mediana odzysku do poprzedniej wersji.
Kompletność audytu: odsetek zmian z pełnymi dowodami (walidatory, suchy bieg, recenzje).

14) Listy kontrolne

Przed zmianą konfiguracji

• Istnieje bilet/RFC i właściciel zmiany.
• Zatwierdzono programy i lintery.
• Istnieje plan rollback i polecenia w runbook.
• Brama: testy zielone, podpisy ważne, brak aktywnego SEV-1.
• W przypadku wysokiego ryzyka przypisuje się okno konserwacji.

Podczas odwijania

• Kanaryjskie i SLO-szyny są aktywne.
• Opublikowano adnotacje dotyczące wydania.
• Są wiadomości echo do kanału; hałas alarmowy tłumiony przez zasady MW.

Po

• Minęło okno obserwacyjne, SLO green.
• Sumy i dowody (przed/po wykresach, raporty na sucho) są dołączone do biletu.
• Aktualizacja schematu/dokumentacji w razie potrzeby.

15) Mini szablony

15. 1 Schemat konfiguracji (schemat YAML, fragment)

yaml type: object required: [service, timeouts, retries]
properties:
service: { type: string, pattern: "^[a-z0-9-]+$" }
timeouts:
type: object properties:
connect_ms: { type: integer, minimum: 50, maximum: 5000 }
request_ms: { type: integer, minimum: 100, maximum: 20000 }
retries:
type: object properties:
attempts: { type: integer, minimum: 0, maximum: 10 }
backoff_ms: { type: integer, minimum: 0, maximum: 5000 }

15. 2 Basic config + nakładka prod

yaml services/checkout/base/config. yaml service: checkout timeouts: { connect_ms: 200, request_ms: 1500 }
retries: { attempts: 2, backoff_ms: 200 }
limits:  { rps: 500 }
features:
degrade_search: false psp_a_weight: 80 psp_b_weight: 20

yaml services/checkout/overlays/prod/config. yaml limits:  { rps: 1200 }
features:
psp_a_weight: 70 psp_b_weight: 30

15. 3 Polityka przyjmowania (pomysł)

yaml allow_change_when:
tests: passed schema_validation: passed active_incidents: none_of [SEV-0, SEV-1]
rollback_plan: present signed_by: ["owner:team-checkout","platform-sre"]

15. 4 Karta zwalniająca Config

Release: checkout-config v2. 3. 1
Scope: prod EU
Changes: psp_b_weight 20→30, request_ms 1500→1300
Risk: Medium (payment routing)
Canary: 1%→5%→25% (30/30/30 мин), guardrails: success_ratio, p95
Rollback: tag v2. 3. 0

16) Anty-wzory

Edytuje w przeszłości prod GitOps („szybko skręcone”).
Sekrety/PII w repozytorium konfig.
Brak diagramów i kontroli statycznych.
Silna dywergencja środowisk (bazowa).
„Live” posiadają flagi bez wersji i historii.
Ignorowanie dryfu i ręcznych edycji na serwerach.
Tagi bez notatek i planu zwrotu.

17) Plan działania na rzecz realizacji (4-6 tygodni)

1. Ned. 1: inwentaryzacja konfiguracji; oddzielne katalogi, schematy dla 10 najlepszych usług.
2. Ned. 2: włączyć lintery/walidację i suchą pracę w CI; zakaz łączenia się bez zielonych kontroli.
3. Ned. 3: GitOps rolka + kanary; adnotacje wersji w telemetrii.
4. Ned. 4 - Wprowadź zasady-as-code i wzory wsteczne. wpisy do dryfowania.
5. Ned. 5-6: obejmuje 90% usług; zmniejszenie różnic w stosunku do nakładek; dodać wskaźniki dojrzałości i cotygodniowy przegląd zmian konfig.

18) Najważniejsze

Kontrola wersji konfiguracyjnej to system, a nie tylko Git. Schematy i walidacja, GitOps i zasady dostępu, kanary i rolki, wykrywanie dryfów i pełny audyt przekształcają konfigurację w zarządzany artefakt. Rezultatem są szybkie i bezpieczne zmiany, przewidywalność SLO i zaufanie zespołu do każdego wydania.