Procesul de aprobare a eliberării

1) Scopul și domeniul de responsabilitate

Procesul de aprobare a lansării asigură modificări predictibile și sigure ale platformei fără a încălca SLO, veniturile și conformitatea. Acesta acoperă întreaga cale: de la cererea de tragere la promovarea completă la prod și post-monitorizare.

2) Principii

1. SLO-first: eliberarea este permisă numai cu SLI verde/fără burn-rate.
2. Loturi mici și reversibilitate: canar/livrare progresivă, rollback rapid.
3. Policy-as-Code: porțile, SoD, ferestrele înghețate și clasele de risc sunt verificate automat.
4. O singură sursă de adevăr: artefacte/configurații/steaguri - în Git, mediul este dat de reconcilierul GitOps.
5. Audit și probabilitate: jurnalele WORM, traseul decizional, proprietarii clari.
6. Securitate în mod implicit: secrete separat, privilegii minime, geo-porți.
7. Comunicații fără surprize: șabloane pregătite pentru actualizări interne/externe.

3) Roluri și RACI

Release Manager (RM) - proprietar de conducte, calendar, porti. A/R

Proprietarul serviciului (SO) - proprietar de domeniu, acceptă riscul, pregătește artefacte. A/R

SRE/Platform - porți SLO, rollout-uri, rollback-uri auto. R

QA Lead - strategia de inspecție, rezultatele testelor. R

Securitate/Conformitate - scanări, SoD, reglementare. C/A

CAB (Change Advisory Board) - Soluție normală de clasă. A

IC/CL de gardă - pregătirea pentru incidente și comunicații. R/C

Părțile interesate (Biz/Support/Partners) - informare. I

4) Schimbați clasele și căile de aprobare

Clasă	Exemple	Calea de omologare	Termeni și condiții
Standard	Sigur, șablon (docuri, configurații non-invazive)	Auto-porți + post-notificare	Ore
Normal	Caracteristici noi, diagrame de baze de date cu migrare, modificări de rutare PSP	Porti + CAB + Livrare progresiva	1-3 zile
Urgență	Hot P1 Fixat, Caracteristică periculoasă/PII Export Off	Decizia IC/RM + CAB post-factum	Minute-ore

Upgrade - la depășirea limitelor de risc (plăți, RG, PII, limite).

5) conducte de eliberare și porți (flux end-to-end)

Etapa 0. Programare și calendar

Freeze-ferestre (sărbători/meciuri), slot on-call și CL, disponibilitatea șabloanelor de stare.

Etapa 1. PR → Build

Lintere/licențe, SBOM, teste de unitate/contract, scanare secretă.

Etapa 2. Integrare/Securitate

E2E (furnizori virtualizați de PSP/KYC), SAST/DAST, revizuirea dependenței.

Etapa 3. Montaj/Repetiţie

Paritatea cu vânzările, migrarea cu reversibilitate, phicheflags cu 5-25%, lista de verificare „burghiu de eliberare”.

Poarta A - Calitate și siguranță (necesară)

+ toate testele/scanează verde

+ scheme/configurații sunt valabile, nu „roșu” SLI de stadializare

+ SoD/4-eyes pentru modificări cu risc ridicat

Etapa 4. Pre-producție (livrare canar)

1-5% trafic pe segment (chiriaș/geo/bancă), validatoare de rulare, guardrails.

Poarta B - SLO/Business Gate

+ fără degradare SLO/KRI (latență/eroare/plată)

+ nu SRM/anomalii în metrica experimentală

+ Comms gata: proiect de stare/parteneri

Etapa 5. Rampă-up → 25% → 100% (regiune/chiriaș)

Promovare pe ture cu cronometre post-monitorizare.

Etapa 6. Post-monitorizare (30-60 min)

Eliberați tabloul de bord, rata de ardere, plângeri/bilete, auto-închidere/rollback în caz de încălcare.

6) Soluții automate (policy-engine)

Pseudo-reguli:

SLO- гейт: "nega promova dacă slo_red în {auth_success, bet_settle_p99}'
PII-export: "necesită dual_control dacă config. afectează = = "PII_EXPORT"'
Freeze: "neagă implementarea în cazul în care calendarul. freeze & not emergency '
Rollback: 'auto dacă auth_success_drop> 10% pentru 10m în geo = TR'

7) Artefacte de eliberare

Manifestul de lansare (necesar): target, clasa de risc, regiuni (chiriaș/regiune), steaguri, migrații, plan de rulare, plan rollback, proprietar, contacte de gardă.
Dovezi Pack: rezultate de testare/scanări, capturi de ecran ale tablourilor de bord, migrații uscate.
Comms Kit: șabloane de stare (interne/externe/parteneri), ETA/ETR.
Planul de backout - pașii exacți ai rollback-ului și criteriile în care este declanșat.

Exemplu (stoarcere YAML):

yaml release:
id: "2025. 11. 01-payments-v42"
owner: "Payments SO"
risk_class: "normal"
scope: { tenants: ["brandA","brandB"], regions: ["EU"] }
rollout:
steps:
- { coverage: "5%", duration: "20m" }
- { coverage: "25%", duration: "40m" }
- { coverage: "100%" }
migrations:
- id: "ledger_ddl_0042"
reversible: true flags:
- id: "deposit. flow. v3"
guardrails: ["api_error_rate<1. 5%","latency_p99<2s"]
rollback:
autoIf:
- metric: "auth_success_rate"
where: "geo=TR"
condition: "drop>10% for 10m"

8) Canare/Albastru-Verde/Feature-Flag de rulare

Canare - implicit în condiții de siguranță: acoperire mică, segmentare prin GEO/chiriaș/BIN.
Blue-Green - pentru schimbări grele: comutare traseu, rollback rapid.
Steaguri - pentru caracteristici comportamentale: TTL, kill-switch, parapete, SoD.

9) Gestionarea configurațiilor și secretelor

Configurații ca date, circuite și validatoare; Promovare GitOps cu detector de derivă.
Secretele - în KMS/Secret Manager, acces JIT, audit și mascare.

10) Comunicații și pagini de stare

Intern: var-room/chat, notificare de gardă, șabloane de actualizare.
Extern: publicații numai prin CL, proiecte pre-pregătite.
Parteneri (PSP/KYC/studios): notificări specifice atunci când sunt afectate integrările.
Stare: Eliberarea nu este un incident, ci are o fereastră de monitorizare cu valori.

11) Comunicate de urgență (de urgență)

Declanșatoare: degradare P1, vulnerabilitate, riscuri PII/RG.
Cale: soluţie IC + RM → set minim de porţi (linter/asamblare) → canar 1-2% → monitorizare → promovare.
Obligatoriu: CAB post-factum, post-mortem ≤ D + 5, documentarea compromisurilor.

12) Audit, SoD și conformitate

SoD/4-eyes: modificări ale rutării PSP, limite bonus, exporturi de date.
Jurnalul WORM: cine/ce/când/de ce; versiuni de politică; diff release/flags/configurs.
Geo/Confidențialitate: date și jurnale în jurisdicția dorită; absența PII în artefacte.

13) Observabilitate și post-control

Tabloul de bord al lansării: SLI (auth-succes, bet→settle p99), error-rate, reclamații, conversie, lag-uri de coadă.
Alerte: burn-rate, SRM, creștere 5xx, degradarea PSP de către bănci/OUG.
Rapoarte: CFR, incidente de eliberare MTTR, timpul mediu post-monitorizare, rata auto-rollback.

14) Procesul KPI/KRI

Timp de plumb pentru schimbare (PR→prod), modificarea ratei de eșec, incidente de eliberare MTTR.
Rata de trecere SLO-gates, rata de auto-rollback, congela conformitatea.
Acoperirea burghiului de lansare (repetiții de montare), încălcări SoD (obiectiv - 0).
Comms SLA (disponibilitatea proiectelor, respectarea temporizărilor).

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

Ned. 1-2: definirea claselor de schimbare, a porților și a artefactelor; activați lintere, SBOM, scanare secretă; eliberați calendarul și înghețați.
Ned. 3-4: GitOps pentru configurații, canar/albastru-verde, porți SLO, șabloane Comms și cameră var.
Ned. 5-6: motor de politică (SoD/4-eyes, reguli de risc), auto-rollback pe metrici; comunicate de bord.
Ned. 7-8: repetiții (exerciții de montare), integrare cu phicheflags/incident-bot, rapoarte KPI/KRI.
Ned. 9-10: audit WORM, DR. burghiu de lansare, optimizare CFR, formare rol (RM/SO/CL/IC).

16) Antipattern

Eliberează fără reversibilitate și incidente canare → în masă.
Ignoră porţile SLO „de dragul termenului limită”.
Configs/steaguri fără circuite și TTL → state „înghețate”.
Clicuri manuale în vânzări fără Git/audit.
Actualizări publice fără rol și șabloane CL.
Secretele din depozit; acces fără JIT și logare.
CAB ca o frână fără date: deciziile trebuie să fie susținute de măsurători de eliberare.

Total

Procesul de aprobare a lansării este un cadru de inginerie și management care conectează calitatea, siguranța și viteza: politici precum codul, porțile SLO, livrarea progresivă, comunicațiile transparente și auditul dovedibil. Această abordare reduce CFR și MTTR, protejează veniturile și conformitatea și permite echipelor să elibereze valoarea în mod frecvent și în siguranță.