Standard Operating Procedures

1) რა არის SOP და რატომ არის ეს საჭირო

SOP (სტანდარტული ოპერატიული პროექტი) არის ფორმალიზებული, დამტკიცებული ნაბიჯების თანმიმდევრობა გასაგები შეყვანის/გასასვლელებით, როლებითა და ხარისხის კრიტერიუმებით.

• ცვალებადობისა და რისკების შემცირება.
• შემცირება MTTA/MTTR მზა მოქმედებების გამო.
• შესაბამისობა და აუდიტი: რეპროდუქცია, ტრეკირება.
• ონბორდინგი: სწავლის დაჩქარება და „shadow-solo“.

SOP - playbuk: playbuk - ჩანგლის გადაწყვეტილებების ხე, SOP - ხაზოვანი რეგულაცია კონკრეტული სცენარისთვის (ან playbook ფილიალი).

2) „კარგი“ SOP პრინციპები

Outcome-Driven: ფოკუსირება შედეგზე (SLO/ბიზნეს კრიტერიუმები), არა მხოლოდ ნაბიჯებზე.
სისწორე: ბრძანებები, პარამეტრები, მოსალოდნელი ეფექტები და კონტროლის წერტილები.
ნაგულისხმევი უსაფრთხოება: კარიბჭეები, შეზღუდვები, backout/rollback რეგისტრირებულია.
მინიმალური კონტექსტი: მოკლე შენიშვნები + ბმულები დეტალურ runbook/დიაგნოზზე.
აქტუალობა: შურისძიების თარიღი, მფლობელი, ვერსია, მოქმედების ვადა.
შესრულება: JIT/JEA- ს წვდომა, წინაპირობების შემოწმება, არტეფაქტების შაბლონები.

3) სტანდარტული სტრუქტურა SOP (ჩონჩხი)

ID/Version/Review Date
Name and short purpose (what and why)
Scope (Services/Regions/Tenants, SEV/Risk)
Roles and Responsibilities (RACI: R/A/C/I)
Preconditions (accesses, windows, stage, reserve, artifacts)
Materials/tools (dashboards, feature flags, repos, keys)
Quality gates (SLO-gardrails, quorum of probes, alerts)
Step-by-step instruction (step → command → expected result → verification)
Branches (if X - perform Y) [minimum]
Backout/Rollback (start conditions, steps, verification)
Communications (who, when, where; message templates)
Evidence (what to save: screenshots, logs, chexums, links)
Completion (success criteria, watching who closes the ticket)
Change History (What, By Whom, and Why)

4) SOP კატალოგი და საკუთრება

ერთი საცავი (Docs-as-Code) წარწერებით: 'domain/ops', 'service/checkout', 'risk/high', 'provider/psp-a'.
მფლობელის ბარათი: გუნდი, მორიგე კონტაქტები, სარეზერვო მფლობელი.
SLA აქტუალობა (მაგალითად, გადასინჯვა ყოველ 90 დღეში ან ინციდენტის/გამოშვების შემდეგ).
Linter/SOP (CI) დამადასტურებელი: სტრუქტურის, ბმულების, მფლობელების, შურისძიების ვადის შემოწმება.

5) სასიცოცხლო ციკლი SOP

1. დაწყება (ინციდენტის/სავარჯიშოების/ახალი პროცესის შემდეგ).
2. პროექტი (ავტორი = სამსახურის/პროცესის მფლობელი).
3. Revium (SRE/Security/Legal/Comms - დომენში).
4. მფრინავი (tabletop/game day): გაზომეთ დრო, აღმოჩენა და რედაქტირება.
5. პუბლიკაცია (ვერსია, თარიღი, ნომერი, შაბლონები CMDB/მომსახურების კატალოგში).
6. ოპერაციული გამოყენება (ვიდეო თიკეტებში/ჩატებში, შერჩევა).
7. განახლება (RCA/CAPA- ს მიხედვით, შურისძიების დროში, არქიტექტურის ცვლილებებზე).
8. არქივირება/დეპრესია (შეიცვალა ახალი SOP/playbook).

6) მეზობელ არტეფაქტებთან ურთიერთობა

ფლეიბუკი: SOP - „ხაზოვანი ფილიალი“ პლეიბუკის შიგნით; ბმული ნაბიჯებიდან.
Runbook 'და: ტექნიკური დეტალები/სკრიპტები მოცემულია runbook- ში, SOP ეხება.
პოლიტიკოსები: დაშვების კარიბჭეები, რეტენსიები, RBAC - სავალდებულო ბმულები.
SLO/SLI: წარმატების კრიტერიუმები და garde-rails.
ესკალაციის მატრიცა: როლები/ტაიმინგი SOP- ის უკმარისობის დროს.
მომსახურების ფანჯრები: მოთხოვნები slot/კომუნებისთვის high-risk SOP.

7) SOP ეფექტურობის მეტრიკა

Time-to-Execute (საშუალო/p95) - რამდენს იკავებს პროცედურა.
Success Rate არის წარმატებული სპექტაკლების წილი ესკალაციის/დაბრუნების გარეშე.
Evidence Completeness - არტეფაქტების შევსება.
SLO Impact - არის თუ არა დეგრადაცია ნაბიჯის/ნაბიჯის შემდეგ (ბურნი-წუთი).
Excect Density - კომენტარები 10 SOP- ზე შურისძიების/ვარჯიშის დროს.
Freshness არის SOP- ის წილი რეპროდუქციით 90 დღის განმავლობაში.
Adoption - რამდენი ალერტა/ფანჯარა ნამდვილად უკავშირდება SOP- ს.

8) SOP ავტორის ჩეკის სია

განისაზღვრება განაცხადის მიზანი და საზღვრები.
აღწერილია როლები, წვდომა და ფანჯრები.

• ხარისხის კარიბჭეები და SLO - იზომება, არსებობს სიგნალის წყაროები.
• ნაბიჯები შესრულებულია: ბრძანებები/სკრიპტები, მოსალოდნელი შედეგები, გადამოწმება.
• Backout/rollback და გაშვების კრიტერიუმები ნათელია.
• კომის შაბლონები ერთვის.
• ევიდენციის სია სტრუქტურირებულია.
• ვერსია/თარიღი/მფლობელი/შურისძიება მითითებულია.

9) SOP მხატვრის ჩეკის სია

• დადასტურებულია JIT/JEA წინაპირობები და წვდომა.
• გაიხსნა ticet/war-room და ჩართულია ვიდეოები.
• დაკვირვება: საჭირო დაშბორდები/ალერტები ღიაა.

მე ვდგავარ ნაბიჯებს წესრიგში; თითოეულის შემდეგ - გადამოწმება.

• გარდრალის დარღვევით - დაუყოვნებლივი გაფიცვა და ესკალაცია.
• ევიდენცია სავსეა; საბოლოო შემოწმება SLO/ბიზნეს SLI.
• ტიკეტი დახურულია, სტატუსის გვერდი/კომსი განახლებულია.

10) მაგალითები SOP (ფრაგმენტები)

10. 1 SOP: კანარის გამოშვება (REL-ROLLBACK-01)

The goal: to return the stable version when the burn-rate is exceeded or the p99 grows.
Scope: checkout-api service (prod, EU).
Roles: Release (R), IC (A in SEV-1), P1 (R), Comms (I).
Preconditions: feature flags are ready; JEA accesses; release-annotations included.
Gates: slo. payment_success, http_p99; quorum synthetic EU/US + RUM.
Steps:
1) Freeze unrelated depleys.
2) rollback to tag v2. 3. 7 (command...) → waiting 5 minutes.
I expect: p99↓, error_rate↓, burn-rate <threshold.
3) Business SLI check (payment success, conversion) 10 min.
4) Remove the suppression of alerts; update release annotation.
Backout: if rollback does not help - escalate to IC, enable degrade-UX, consider failover.
Comms: "Rolled back; metrics stabilize; next update in 15 minutes."
Evidence: before/after screenshots, link to dashboards, command and output.
Completion: 30 min green SLOs; close the ticket; assign an RCA (if SEV-1).
Version: 1. 6 (2025-10-28)

10. 2 SOP: BD დაგეგმვის განახლება (MW-DB-UPGRADE-02)

Purpose: update PostgreSQL minor without data loss.
Area: payments-db (prod EU), 02: 00-04: 00 Europe/Kyiv.
Roles: DB Lead (R), SRE (C), Service Owner (A), Comms (R clients).
Preconditions: OK backups; replica in sync; Test upgrade passed.
Gates: lag≤30s, error_rate<0. 5%, p99 <400ms, SLO green 30m.
Steps:
1) Transfer traffic to canary replica 1%→5%→25%; SLI monitoring.
2) Consistently upgrade secondary nodes → switch over → upgrade of the former primary.
3) Restore replication, check consistency.
Backout: promote stable replica; return writer; rolling back packets.
Comms: T-7/-2 days and T-60/-15 min alert; updates q = 30m during the window.
Evidence: migration logs, checksums, p95/p99 graphs.
Completion: observation 60m without burn; MW report with evidence.
Version: 2. 1 (2025-09-12)

10. 3 SOP: PSP პროვაიდერის შეცვლა (PROV-PSP-SWITCH-01)

Objective: to maintain payment success_ratio in case of PSP-A degradation.
Trigger: PSP-A red/partial status + success_ratio% ≥2 drop.
Steps:
1) Install weights: PSP-A 30%, PSP-B 70%.
2) Turn on the degrade_payments_ux; enhance retrays (within SLA).
3) Monitor fraud_rate/chargeback-risk 30m.
Backout: Regain weights at green SLI 60m.
Comms: status page (first ≤15m, cadence 30m).

10. 4 SOP: ბეკის აღდგენის შემოწმება (DATA-BACUP-RESTORE-CHECK-03)

Objective: weekly verification of recoverability.
Steps: lift from backup in isolation → hash control → consistency requests → report.
Success criterion: time-to-restore ≤ 45 min; 100% integrity.

11) ავტომატიზაცია SOP- ის გარშემო

SOP შაბლონიზატორი: ჩონჩხის წარმოება RACI/კარიბჭეებით/კომმ ბლოკით.
Bot შემსრულებელი: ნაბიჯები ჩეკის ყუთებით, ტაიმერები, კადრების შეხსენებები, ავტომობილების ჯგუფი.
ინტეგრაცია CMDB/კატალოგთან: მომსახურებას აქვს შესაბამისი SOP სია.
ტელემეტრიული სურათები: „SOP-RUN: <ID> step N“ - სწრაფი ანალიზი.
დაშვების პოლიტიკოსები: გამონაყარი/ფანჯარა დაიწყება მხოლოდ SOP მწვანე კარიბჭეებით.

12) ანტი შაბლონები

SOP მფლობელის გარეშე/შურისძიების თარიღი - „მკვდარი“ დოკუმენტი.
გაჟღენთილი ინსტრუქციები წარმატების კრიტერიუმებისა და ზურგჩანთების გარეშე.
არაკოორდინირებული გუნდები/გასაღებები შეცდომებისა და გაჟონვის რისკია.
სხვადასხვა ვერსიები ვიკში და საცავში არის ჭეშმარიტების წყაროების შეუსაბამობა.
არ არსებობს ხილვა - ხარისხის/შესაბამისობის დადასტურების არაფერი აქვს.
„ერთი SOP ყველა შემთხვევაში“ - შესრულება იკარგება.

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

1. ნვე. 1: დაამტკიცეთ SOP შაბლონი, ლინტერი და კატალოგი; შეარჩიეთ ტოპ 10 სცენარი.
2. ნვე. 2: დაწერეთ SOP გამოშვების/გამოტოვების/პროვაიდერის/ბეკაპებისთვის; tabletop მფრინავები.
3. ნვე. 3: დააკავშიროთ ChatOps bot და ტელემეტრიული სურათები; დაუკავშირეთ ალერტებს SOP- სთან.
4. ნვე. 4: კვარტალური შურისძიების გრაფიკი; შეიყვანეთ მეტრიკები Freshness/Success Rate.
5. ნვე. 5-6: კრიტიკული ოპერაციების 90% დაფარვა; DR/Security-SOP; ავტომატური შერჩევა.

14) შედეგი

SOP ოპერაციებს პროგნოზირებად და გადამოწმებულად ხდის: ერთიანი ხარისხის კარიბჭეები, დეტალური ნაბიჯები, აშკარა როლები და შექცევადობა. პლეიბუკებთან, პოლიტიკოსებთან, SLO- სთან და ავტომატიზაციასთან ერთად, ეს ექსპლუატაციას საიმედო წარმოების ხაზად აქცევს - სწრაფი რეაქციები, მინიმალური რისკი და გასაგები პასუხისმგებლობა.