Rollback automat al versiunilor

1) De ce aveți nevoie de un auto-rollback

• reduce CFR și MTTR;
• protejează SLO (auth-succes, p99 „stavka→settl”, rata de eroare);
• previne incidentele de conformitate (PII/RG/AML).

2) Principii

1. Revert este o caracteristică: Rollback planificat pentru designul de lansare.
2. Policy-as-Code: praguri, ferestre, excepții - validarea în conductă.
3. Canare-primul: se spală de-a lungul treptelor, rollback - trepte oglindă.
4. Siguranța datelor: migrațiile sunt reversibile/sumative; configs - versionable.
5. SLO-gates: SLI roșu/parapete → auto-rollback imediat.
6. Explicabilitate: cronologie, difuze, motive - la jurnalul WORM.
7. Nici un singur buton de doom: restricții, confirmări pentru acțiuni de risc, SoD.

3) Auto-rollback declanșează (semnale)

3. 1 Tehnic SLI/KRI

auth_success_rate scădere prin OUG/PSP/BIN (de exemplu, − 10% în TR ≥10 min).
latență p99/error-rate căi cheie (depozit/ieșire/decontare).
coadă lag/rata DLQ/încercați din nou furtuna.
db replicare lag/cache miss val.

3. 2 Semnale de afaceri

deposit_conversion − X pp pe canar vs. control.
soluționați scăderea debitului față de valoarea inițială.
chargeback/declin spikes (moale/greu).

3. 3 Evenimente critice

Eșecul SRM în A/B activă (denaturarea traficului).
Declanșarea pazei de securitate/PII.
Incompatibilitatea circuitelor/configurațiilor (validator/linter).

4) Modele de reversibilitate arhitecturală

Canary → Rampa → Full: 5%→25%→100% promovare; rollback - în ordine inversă (100→25→5→0).
Blue-Green: comutator de trafic atomic între albastru și verde, rollback - întoarcere instantanee.
Feature Flags: kill-switch pentru schimbare comportamentală (TTL, guardrails, SoD).
Config ca date: GitOps promovare/re-promovare a versiunii anterioare; instantanee de rulare.

• în două faze (expand→contract)
• reversibil (jos scripturi),
• write-shadow (câmpurile noi sunt scrise duplicat),
• read-compat (vechiul cod înțelege noua schemă).

5) Motor de politică

• 'auto _ rollback dacă auth_success_rate. picătură (geo =” TR”)> 10% pentru 10m ȘI acoperire> = 5%'
• 'auto _ rollback dacă bet_settle_p99> SLO1. 25 pentru 15m '
• 'auto _ pause _ flag dacă api_error_rate> 1. 5% pentru 5m'
• 'deny _ promova dacă slo_red în {"auth _ success", "retrage _ tat _ p95"} "
• 'require _ dual _ control dacă se modifică. afectează în {"PSP _ ROUTING", "PII _ EXPORT"} "

Toate regulile sunt versionate, testate și revizuite.

6) Flux end-to-end

1. Detectorul de regresie este declanșat (metric/alert/validator).
2. Verificarea excepțiilor (vârfuri de vacanță, ferestre de testare).

7) Integrări

Incident bot: '/release rollback <id> ', linii temporale automate, link-uri către tablouri de bord și difuzoare.
Metrics API: gata SLO vizualizare și stări de parapantă; exemplare pentru RCA.
Feature Flags: '/flag off <id> ', autopauză prin parapet.
GitOps/Config: '/config rollback <instantaneu> '; detectorul de derivă confirmă rezultatul.
Pagina de stare: actualizări publice opționale (prin CL/politică).

8) Telemetrie de observabilitate și rollback

Release Dashboard: auth-succes, error-rate, p95/p99, settle throughput, PSP по GEO/BIN.
Guardrail Board: reguli active/declanșate, ferestre, histerezis.
Istoria acoperirii:% din canari/steaguri/regiuni în timp.
Audit: cine/ce/când/de ce; difuzii de artefact; versiunea de politică; rezultat.

9) Securitate, SoD și conformitate

4-eyes/JIT pentru activitățile care afectează plățile/PII/RG.
Geo-garduri: Rollback-uri care afectează cerințele de reglementare sunt aplicate la nivel local.
Jurnalele WORM: urme imuabile pentru verificări.
Pachete de comunicații publice: în concordanță cu CL/Legal; detaliile experimentelor nu au fost dezvăluite în exterior.

10) Exemple de artefacte

10. 1 Auto-Rollback Politica (YAML)

yaml apiVersion: policy.platform/v1 kind: AutoRollbackRule metadata:
id: "payments-auth-success-tr"
spec:
scope: { tenants: ["brandA","brandB"], regions: ["EU"], geo: ["TR"] }
signal:
metric: "auth_success_rate"
condition: "drop > 10% for 10m"
compareTo: "canary_control"
action:
strategy: "step_down"  # 100%->25%->5%->0%
cooldown: "15m"
exceptions:
calendar: ["2025-11-29:black_friday"]
manualOverride: false audit:
owner: "Payments SO"
riskClass: "high"

10. 2 Manifestul rollback de configurare

yaml apiVersion: cfg.platform/v1 kind: ConfigRollback metadata:
id: "psp-routing-revert-2025-11-01"
spec:
from: "payments-routing-2025-11-01"
to:  "payments-routing-2025-10-29"
criteria:
- metric: "auth_success_rate"
where: "geo=TR"
condition: "drop>10% for 10m"
notify:
incidentBot: true stakeholders: ["Payments","SRE","Support"]

10. 3 Steag kill-switch

yaml apiVersion: flag.platform/v1 kind: KillSwitch metadata:
id: "deposit.flow.v3"
spec:
guardrails: ["api_error_rate<1.5%","latency_p99<2s","slo_green:auth_success"]
autoPauseOnBreach: true ttl: "30d"

11) Lucrul cu migrațiile de date

• Extindeți: adăugați coloane/indici noi fără a rupe citirea.
• Migrează: intrare/reluare dublă, verificare consistență.
• Contract: ștergeți vechiul numai după eliberarea cu succes + fereastră de observare.
• Jos scripturi: necesar; evaluarea timpului și a încuietorilor.
• Shadow citește: compararea rezultatelor căii vechi/noi (fără efecte secundare).
• Contract privind criteriile de anulare: orice parapet „roșu”.

12) Procese și RACI

Release Manager: proprietar de conducte și politici.
Proprietarul serviciului: aprobă regulile domeniului, acceptă riscul.
SRE: implementează detectoare, mecanică pullback, tablouri de bord.
Securitate/Conformitate: SoD, PII/RG control, audit.
IC/CL de gardă: comunicații, pagina de stare.
CAB: prezentare generală post-factum a rollback-urilor auto, ajustări ale regulilor.

13) Funcții KPI/KRI

Auto-Rollback Rate: proporția de versiuni care au rulat înapoi automat (normă: scăzut, dar nu zero).
Time-to-Rollback: detekt→otkat (mediană/p95).
SLO-Breach Evitat: Cazuri în care auto-backtrackingul a împiedicat încălcarea țintelor.
False pozitive: proporția de rollback-uri „false” (țintă - ↓).
CFR înainte/după punerea în aplicare a auto-rollback.
Costul Rollbacks: timp suplimentar, canari, resurse de calcul.
Audit complet:% evenimente cu cronologie completă și difuze.

14) Foaie de parcurs de implementare (6-10 săptămâni)

Ned. 1-2: catalog de valori critice și praguri de bază; selectarea strategiilor (canar/albastru-verde/steaguri); inventarul reversibilității migrației.
Ned. 3-4: implementarea detectoarelor și a motorului de politică; integrarea cu incident-bot; GitOps-rollback pentru configurații; tablouri de bord guardrails.
Ned. 5-6: pilot pe domeniul Plăți (auth-succes, PSP-rutare), instruire tabletop; Jurnal WORM și rapoarte.
Ned. 7-8: extinderea pe Games/KYC; pauză automată de pavilion; DR exerciții cu albastru-verde.
Ned. 9-10: calibrarea pragului, reducerea fals pozitivă, estimarea costurilor FinOps, RACI și formalizarea învățării.

15) Antipattern

„Întoarceți-vă cumva”: lipsa unui plan și reversibilitatea migrațiilor.
Activare/dezactivare instantanee globală fără pași.
Metrică brută fără context (fără stratificare GEO/PSP/BIN).
Ignorarea SRM și tragerea cu ochiul în experimente.
Eliberați alerte fără histerezis → clapare rollback.
Editarea manuală a configurațiilor în produs fără Git/Audit.
Șterge vechea schemă înainte de a trece fereastra de observare.

Rezultat

Rollback-ul automat de lansare este grila de protecție a platformei: politici ca cod, semnale și praguri selectate corect, soluții arhitecturale reversibile (canar/albastru-verde/steaguri/migrații reversibile), comunicații încorporate și audit complet. Această buclă reduce dramatic riscul de eliberare, protejează SLO și veniturile și crește încrederea autorităților de reglementare și a partenerilor.