გამოშვების დამტკიცების პროცესი

1) მიზანი და პასუხისმგებლობის სფერო

გამოშვების დამტკიცების პროცესი უზრუნველყოფს პროგნოზირებადი და უსაფრთხო პლატფორმის ცვლილებებს SLO დარღვევის, შემოსავლის და შესაბამისობის გარეშე. იგი მოიცავს მთელ გზას: pull Request- დან დაწყებული, სანამ არ დასრულდება პრომო და პოსტ - მონიტორინგი.

2) პრინციპები

1. SLO-first: გამოშვება ნებადართულია მხოლოდ მწვანე SLI/ბურნის გარეშე.
2. მცირე ნაწილები და შექცევადობა: კანარის/პროგრესული მიწოდება, სწრაფი rollback.
3. Policy-as-Code: კარიბჭეები, SoD, freeze ფანჯრები და რისკების კლასები - ავტომატურად გადამოწმდება.
4. ჭეშმარიტების ერთი წყარო: არტეფაქტები/კონფისკაციები/დროშები - Git- ში, გარემო მოცემულია GitOps რეკონსერვატორის მიერ.
5. აუდიტი და დადასტურება: WORM ჟურნალები, გადაწყვეტილების მიღების კვალი, მკაფიო მფლობელები.
6. ნაგულისხმევი უსაფრთხოება: საიდუმლოებები ცალკე, მინიმალური პრივილეგიები, გეო კარიბჭეები.
7. კომუნიკაციები სიურპრიზების გარეშე: მომზადებული შაბლონები შიდა/გარე განახლებებისთვის.

3) როლები და RACI

Release მენეჯერი (RM) - კონვეიერის მფლობელი, კალენდარი, კარიბჭე. A/R

Service Owner (SO) - დომენის მფლობელი, იღებს რისკს, ამზადებს არტეფაქტებს. A/R

SRE/Platform - SLO კარიბჭეები, districts, მანქანების გამოტოვება. R

QA Lead არის შემოწმების სტრატეგია, ტესტის შედეგები. R

უსაფრთხოება/კომპლექსი - სკანები, SoD, მარეგულირებელი. C/A

CAB (Change Advisory Board) - გამოსავალი Normal Class- ზე. A

On-Call IC/CL - მზადყოფნა ინციდენტისა და კომუნიკაციებისთვის. R/C

Stakeholders (Biz/Support/პარტნიორები) - ინფორმაცია. I

4) ცვლილებების კლასები და კოორდინაციის გზები

კლასი	მაგალითები	კოორდინაციის გზა	ვადები
Standard	უსაფრთხო, შაბლონები (დოქტორანტები, არაინვაზიური კონფიგურაციები)	ავტო კარიბჭე + შეტყობინება	საათი
Normal	ახალი ფიჩები, DD სქემები მიგრაციით, PSP როტინგის ცვლილებები	კარიბჭეები + CAB + პროგრესული მიწოდება	1-3 დღე
Emergency	ცხელი ფიქსაცია P1, საშიში ფიჩხის/ექსპორტის გამორთვა PII	IC/RM გამოსავალი + CAB პოსტ-ფაქტორი	წუთიანი საათი

კლასის ზრდა - რისკის საზღვრების გადაკვეთისას (გადახდები, RG, PII, ლიმიტები).

5) გამოშვებისა და კარიბჭის კონვეიერი (ნაკადის გავლა)

ეტაპი 0. დაგეგმვა და კალენდარი

უფასო ფანჯრები (არდადეგები/მატჩები), კოლონა და CL სპილო, სტატუსის შაბლონების მზადყოფნა.

ეტაპი 1. PR → Build

ლინტერები/ლიცენზიები, SBOM, unit/contract tests, საიდუმლო სკანირება.

ეტაპი 2. ინტეგრაცია/უსაფრთხოება

E2E (ვირტუალური PSP/KYC პროვაიდერები), SAST/DAST, dependence მიმოხილვა.

ეტაპი 3. სტაგინგი/რეპეტიცია

პარიტეტული გაყიდვებით, შექცევადი მიგრაციით, ფიჩეფლაგით 5-25% -ით, ჩეკების ჩამონათვალით „release drill“.

კარიბჭე A - ხარისხი და უსაფრთხოება (სავალდებულო)

+ ყველა ტესტი/მწვანე სკანები

+ სქემები/ჩამორთმევა სავალდებულოა, არა „წითელი“ SLI სტაგინგი

+ SoD/4-eyes მაღალი რანგის ცვლილებებისთვის

ეტაპი 4. Prod Prod (კანარის მიწოდება)

სეგმენტების ტრაფიკის 1-5% (tenant/geo/bank), runtime შემსრულებლები, guardrails.

კარიბჭე B - SLO/ბიზნეს კარიბჭე

+ არ არსებობს SLO/KRI დეგრადაცია (ლატენტობა/შეცდომები/გადახდა)

+ არა SRM/ანომალიები ექსპერიმენტების მეტრიკებში

+ Comms მზად არის: სტატუსის/პარტნიორების პროექტი

ეტაპი 5. Ramp-ap-25% 100% (რეგიონი/ტენანტი)

ეტაპობრივი გამოტოვება პოსტ-მონიტორინგის ტაიმერებით.

ეტაპი 6. პოსტ მონიტორინგი (30-60 წუთი)

გამოშვების Dashboard, burn-rate, საჩივრები/თიკეტები, მანქანის დახურვა/rollback დარღვევების დროს.

6) ავტომატიზირებული გადაწყვეტილებები

ფსევდო წესები:

SLO-гейт: `deny promote if slo_red in {auth_success, bet_settle_p99}`
PII-export: `require dual_control if config. affects == "PII_EXPORT"`
Freeze: `deny deploy if calendar. freeze && not emergency`
Rollback: `auto if auth_success_drop > 10% for 10m in geo=TR`

7) გამოშვების არტეფაქტები

Release Manifest

Evidence Pack: ტესტების/სკანირების შედეგები, staging dashboards- ის ეკრანული კადრები, dry-run მიგრაცია.
Comms Kit: სტატუსის შაბლონები (შიდა/გარე/პარტნიორები), ETA/ETR.
Backout Plan: ზუსტი დაბრუნების ნაბიჯები და კრიტერიუმები, რომლითაც იგი მუშაობს.

მაგალითი (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) კანარის/ცისფერი-მწვანე/Feature-Flag დალაგება

კანარი - უსაფრთხო ნაგულისხმევი: დაბალი გაშუქება, სეგმენტი GEO/tenant/BIN.
ცისფერი-მწვანე - მძიმე ცვლილებებისთვის: მარშრუტის გადართვა, სწრაფი დაბრუნება.
დროშები - ქცევითი ფიგურებისთვის: TTL, kill-switch, guardrails, SoD.

9) კონფისკაციისა და საიდუმლოების მართვა

კონფისკაცია, როგორც მონაცემები, სქემები და მოვალეობები; GitOps გამოტოვება დრიფტის დეტექტორით.
საიდუმლოებები - KMS/Secret Manager, JIT წვდომა, აუდიტი და შენიღბვა.

10) კომუნიკაციები და სტატუსის გვერდები

შინაგანი: var-rum/chat, on-colls შეტყობინებები, apdate შაბლონები.
გარე: პუბლიკაციები მხოლოდ CL- ის მეშვეობით, წინასწარ მომზადებული მონახაზები.
პარტნიორები (PSP/KYC/სტუდიები): targeted შეტყობინებები ინტეგრაციის გავლენის დროს.
სტატუსი: გამოშვება არ არის ინციდენტი, მაგრამ აქვს სათვალთვალო ფანჯარა მეტრიკებით.

11) გადაუდებელი გამოშვებები (განვითარება)

გამომწვევები: P1 დეგრადაცია, დაუცველობა, PII/RG რისკები.
გზა: IC + RM გამოსავალი - კარიბჭეების მინიმალური ნაკრები (ლინტერი/შეკრება) - კანარი 1-2%, მონიტორინგი - გამოტოვება.
დარწმუნდით: CAB post-factum, პოსტ-mortem - D + 5, კომპრომისების დოკუმენტაცია.

12) აუდიტი, SoD და შესაბამისობა

SoD/4-eyes: ცვლილებები PSP როუტინგის, ბონუსის ლიმიტის, მონაცემთა ექსპორტის შესახებ.
WORM ჟურნალი: ვინ/რა/როდის/რატომ; პოლიტიკოსის ვერსიები; გამოშვება/დროშები/ჩამორთმევა.
Geo/Privacy: მონაცემები და ლოგოები სწორ იურისდიქციაში; PII- ის არარსებობა არტეფაქტებში.

13) დაკვირვება და პოსტ კონტროლი

Dashboard გამოშვება: SLI (auth-success, bet-settle p99), error-rate, საჩივრები, კონვერტაცია, რიგების ლაქები.
ალერტები: burn-rate, SRM, 5xx სიმაღლე, PSP დეგრადაცია ბანკებში/GEO.
მოხსენებები: CFR, MTTR განთავისუფლების ინციდენტები, პოსტ-მონიტორინგის საშუალო დრო, auto-rollback.

14) KPI/KRI პროცესი

Lead Time for Change (PR), Change Failure Rate, MTTR განთავისუფლების ინციდენტები.
SLO-gates pass rate, Auto-rollback rate, Freeze compliance.
Release Drill- ის ბრძანება, SoD violations (მიზანი - 0).
Comms SLA (მონახაზების არსებობა, ტაიმინგის დაცვა).

15) განხორციელების გზის რუკა (6-10 კვირა)

ნვე. 1-2: განსაზღვროთ ცვლილებების კლასები, კარიბჭეები და არტეფაქტები; ჩართეთ საბრძოლო მასალები, SBOM, საიდუმლო სკანირება; გამოშვების კალენდარი და უფასო.
ნვე. 3-4: GitOps კონფისკაციისთვის, canary/blue-green, SLO კარიბჭეები, Comms შაბლონები და var-rum.
ნვე. 5-6: policy ძრავა (SoD/4-eyes, risk-rules), auto-rollback მეტრი; Dashboard გამოშვებები.
ნვე. 7-8: რეპეტიციები (staging drills), ინტეგრაცია ძაფებთან/ინციდენტ-ბოტთან, KPI/KRI ანგარიშები.
ნვე. 9-10: WORM აუდიტი, გამოშვების DR სავარჯიშოები, CFR ოპტიმიზაცია, როლების სწავლება (RM/SO/CL/IC).

16) ანტიპატერები

გამოშვებები შექცევადი და არაკეთილსინდისიერი - მასობრივი ინციდენტები.
SLO კარიბჭეების უგულებელყოფა „ვადაზე ადრე“.
კონფისკაცია/დროშები სქემების გარეშე და TTL არის „გაყინული“ სახელმწიფოები.
ხელით დაწკაპუნება გაყიდვაში Git/აუდიტის გარეშე.
საზოგადოებრივი აპდეიტები CL და შაბლონების როლის გარეშე.
საიდუმლოებები საცავებში; წვდომა JIT და ჟურნალისტიკის გარეშე.
CAB, როგორც სამუხრუჭე მონაცემების გარეშე: გადაწყვეტილებებს უნდა დაეხმაროს გამოშვების მეტრიკა.

შედეგი

გამოშვების დამტკიცების პროცესი არის საინჟინრო და მენეჯმენტის ჩარჩო, რომელიც აკავშირებს ხარისხს, უსაფრთხოებას და სიჩქარეს: პოლიტიკოსები, როგორც კოდი, SLO კარიბჭეები, პროგრესული მიწოდება, გამჭვირვალე კომუნიკაციები და დადასტურებული აუდიტი. ეს მიდგომა ამცირებს CFR და MTTR, იცავს შემოსავალს და შესაბამისობას და გუნდებს საშუალებას აძლევს ხშირად და უსაფრთხოდ გაათავისუფლონ ღირებულება.