Controlul versiunii de configurare

1) De ce versioning configurații

Configurarea este o politică executabilă: definește rutarea, limitele, steagurile de caracteristici, accesele, schemele de date. Controlul versiunii face modificările repetabile, observabile și reversibile: reduce rata MTTR și rata de eșec a schimbării, elimină „magia în vânzări”, oferă audituri pentru securitate și conformitate.

2) Taxonomie de configurare

Infrastructură (IaC): clustere, rețele, LB, DB, cozi.
Service: parametrii de aplicare, resurse, limite, termene, retroys.
Logica produsului/afacerii: tarife, experimente AB, reguli de conținut.
Data/DataOps: scheme de contracte, prospețime SLA, transformare.
Securitate: politici de acces, roluri, chei/certificate (secretele în sine sunt în afara repo).
Observabilitate: SLI/SLO, alerte, tablouri de bord.

Regula: tot ceea ce afectează comportamentul sistemului este configurația și trebuie să trăiască sub versioning.

3) Principii de versionare

1. GitOps: singura sursă de adevăr este depozitul; modificări prin PR și conducte automate.
2. Declarativ: descrierea stării țintă, nu scripturi pas.
3. Imutabilitatea artefactelor: configurare → instantaneu materializat fără ambiguitate.
4. Scheme și validare: schema JSON/YAML, turnare strictă de tip, câmpuri obligatorii.
5. Medii precum codul: 'env' - foldere/suprapuneri (dev/stage/prod), diferențele sunt minime și evidente.
6. Idempotence și rollback-uri: reveniți/întoarceți orice versiune de configurare.
7. Audit și trasabilitate: autor, motiv, bilet/RFC, schimbare semnături.

4) Strategii de versioning

• MAJOR - scheme/politici incompatibile.
• MINOR - câmpuri/reguli noi, compatibilitate înapoi.
• PATCH - stabilește valorile fără a schimba schemele.
• Lansări de etichete și note de lansare: ce sa schimbat, cum să se rostogolească înapoi, puncte de control.
• Fișiere de fixare/blocare: fixați versiunile de dependență (module, diagrame).
• Versiuni matrice: artefactul aplicației X este compatibil cu configurația Y (matricea din catalogul de servicii).

5) Organizarea depozitului

config-repo/
policies/     # общие политики (RBAC, SLO, алерты)
services/
checkout/
schema/    # JSON/YAML схемы конфигов base/     # дефолтные значения overlays/
dev/
stage/
prod/
data-contracts/  # схемы данных, SLA свежести releases/     # теги, changelog, артефакты валидации tools/      # линтеры, генераторы, тесты

Ramură: pe bază de trunchi (principal) + ramuri de caracteristici scurte. Merge - prin PR numai cu CI obligatorii.

6) Validarea și testarea

Schema: Fiecare modificare trece schema de validare (necesar, enum, intervale).
Lintere statice: format, chei, duplicate, câmpuri interzise.
Teste de compatibilitate: versiunea de config + serviciu/diagramă merge în sus în cutia de nisip.
Testul rulează: aplicații uscate, „ce-dacă” starea țintă diff.
Politici ca cod: reguli de admitere (Rego/CEL) - cine poate schimba ce.

7) Dezactivați și rola configurații înapoi

Livrare progresivă: canar 1%→5%→25% cu gardrails SLO.
Implementați poarta: nu există SEV-1 active, alertele sunt verzi, semnăturile sunt valide, rollback-ul este gata.
Rollback: 'întoarce eticheta vX. Y.Z "sau trecerea la instantaneul anterior; comenzile rollback sunt documentate în runbook.
Adnotări de lansare: Versiunea de configurare este publicată în valori/jurnale pentru a se corela rapid cu incidentele.

8) configurare dinamică și la distanță

Steaguri de configurare/caracteristică la distanță: schimbați parametrii fără reporniri; toate steagurile sunt, de asemenea, sub GitOps.
Frontiere: ce parametri pot fi modificați dinamic (lista listelor albe).
Cache și consistență: TTL, versiuni, înlocuire set atomic (publicare în două faze).
Balustrade sigure: limite și intervale pentru schimbările de rulare, auto-rollback la părăsirea SLO.

9) Secretele și datele sensibile

Nu păstra secrete într-un repo. În configurații - numai link-uri/substituenți.
Criptarea fișierelor de configurare, dacă este necesar: integrarea cu managerul secret/cheie.
Rotație și JIT: accesele sunt emise pe durata operațiunilor; traseul acțiunii este imuabil.
Mascarea câmpului: Validarea interzice PII/secretele să intre în config.

10) Managementul mediului

Baza + suprapuneri: diferențele dintre dev/etapă/prod sunt minime și transparente.
Promovarea pe artefacte: același instantaneu care a trecut etapa este promovat în prod.
Ferestre de timp: modificările în configurații nu au loc în momentul schimbării taxei; pentru risc ridicat - RFC și fereastră de întreținere.

11) Detectarea și eliminarea driftului

Controlorul compară statul ţintă cu statul real şi raportează diferenţa.
Alerte Drift: Pagină numai pentru discrepanțe critice; ceilalţi sunt Ticket.
Remediere automată: la rezoluție - revenirea la starea țintă.
Editări manuale de audit: orice „kubectl edit/ssh” → incident de proces și CAPA.

12) Catalog de configurare și de proprietate

Catalog de servicii: proprietar, SLO, politici conexe, scheme, versiuni, compatibilitate.
RACI: cine oferă, cine recenzează, cine aprobă; CAB pentru risc ridicat.
Transparență: Fiecare intrare are un istoric de versiune și link-uri către PR/bilete/AAR.

13) Valorile maturității

Acoperire:% din servicii/politici pentru GitOps (obiectiv ≥ 95%).
Modificări ale configurației timpului de plumb: mediană de la PR la prod.
Rata de eșec a schimbării: proporția de eliberări de configurare cu rollback/incident.
Rata de derivă: numărul de discrepanțe/săptămână și ora eliminării.
Timp de întoarcere: recuperare mediană la versiunea anterioară.
Integralitatea auditului: proporția de modificări cu dovezi complete (validatori, uscați, recenzii).

14) Liste de verificare

Înainte de a schimba configurația

• Există un bilet/RFC și un proprietar de schimbare.

Schemele și linterele au fost validate.

• Există un plan de rollback și comenzi în runbook.
• Poarta: testează verde, semnături valabile, nici o SEV-1 activă.
• Pentru risc ridicat, este alocată o fereastră de întreținere.

În timpul relaxării

• Canare și SLO-gardrails sunt active.
• Adnotările de lansare sunt publicate.
• Există mesaje ecou la canal; zgomotul de alertă suprimat de regulile MW.

Mai târziu

• Fereastra de observare a trecut, verde SLO.
• Totaluri și dovezi (înainte/după diagrame, rapoarte uscate) sunt atașate la bilet.
• Scheme actualizate/documentație după cum este necesar.

15) Mini șabloane

15. 1 Diagrama de configurare (YAML-schema, 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 config de bază + prod suprapunere

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 Politica de admitere (idee)

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 Config carte de eliberare

Release: checkout-config v2.3.1
Scope: prod EU
Changes: psp_b_weight 20→30, request_ms 1500→1300
Risk: Medium (маршрутизация платежей)
Canary: 1%→5%→25% (30/30/30 мин), guardrails: success_ratio, p95
Rollback: tag v2.3.0

16) Anti-modele

Editează în prod trecut GitOps („rapid răsucite”).
Secretele/PII în depozitul de configurații.
Lipsa diagramelor şi a controalelor statice.
Divergența puternică a mediilor (base≠prod).
„Live” prezintă steaguri fără versiuni și istorie.
Ignorarea driftului și a editărilor manuale pe servere.
Etichete fără note de lansare și plan rollback.

17) Foaie de parcurs de implementare (4-6 săptămâni)

1. Ned. 1: inventarul configurațiilor; cataloage separate, scheme pentru top 10 servicii.
2. Ned. 2: include lintere/validare și uscate în CI; interzicerea fuziunii fără controale verzi.
3. Ned. 3: GitOps roll + canari; adnotări de versiune în telemetrie.
4. Ned. 4 - Introduceți tiparele de politică ca cod și rollback. alerte în derivă.
5. Ned. 5-6: acoperă 90% din servicii; reduce diferențele env la suprapuneri; adăugați valorile maturității și revizuirea săptămânală a schimbărilor de configurare.

18) Linia de jos

Controlul versiunii de configurare este un sistem, nu doar Git. Schema și validarea, GitOps și politicile de acces, canarii și rollback-uri, detectarea derivei și auditarea completă transformă configurarea într-un artefact gestionat. Rezultatul este schimbările rapide și sigure, predictibilitatea SLO și încrederea echipei în fiecare versiune.