SOP: <მოკლე მოქმედება/მიზანი>

ოპერაციული პროცედურების სტანდარტიზაცია

1) რატომ არის ეს აუცილებელი?

SOP არის კომპანიის „ოპერაციული OS“. სტანდარტიზაცია ასუფთავებს ქაოსს და „ინდივიდუალურ სტილებს“, ამცირებს MTTR- ს, ალერტების ხმაურს და ინციდენტების რისკებს, აჩქარებს ონბორდინგს და შედეგებს რეპროდუცირებს.

• შეამცირეთ ქმედებების ცვალებადობა ინციდენტებსა და რუტინებში.
• დააჩქაროს ტრენინგი და გააუმჯობესოს ჰენდოვერების ხარისხი.
• პროცესების შემოწმება: აუდიტი, მეტრიკა, მონაცემების გაუმჯობესება.
• უზრუნველყოს მარეგულირებელი და შიდა მოთხოვნების შესაბამისობა.

2) სტანდარტიზაციის პრინციპები

1. ერთი ფორმატი და ტერმინოლოგია. ერთი ნოტაცია, ერთი განმარტება (SLO, ETA, Owner).
2. Actionable, არა ენციკლოპედია. მხოლოდ გამოცდილი ნაბიჯები, წარმატების კრიტერიუმები და დაბრუნება.
3. მინიმალური განშტოება. მკაფიო გადაწყვეტილებები „თუ/მაშინ“ უფასო პრეზენტაციის ნაცვლად.
4. ვერსია და საკუთრება. თითოეულ SOP- ს აქვს მფლობელი, ვერსია და აუდიტის თარიღი.
5. ინსტრუმენტებთან ინტეგრაცია. ბმულები დაშბორდის, თიკეტების, ფიჩეფლაგების, CLI გუნდების შესახებ.
6. წვდომა კოლაში. სწრაფად მოძებნეთ, წაიკითხეთ, შეასრულეთ ერთი მითითება.
7. უწყვეტი გაუმჯობესება. Postmortems არის SOP- ის განახლების დავალებები.

3) SOP ჩარჩო (შაბლონი)

4) SOP classification

Incident: P1/P2 (critical), P3 (important).
Operational routines: releases, feature flags, database migrations, provider failover.
DR/BCP: disabling the region, restoring from backup, working offline.
Quality control/audit: revisions, readiness questionnaires, access.
Security/compliance: KYC/AML checks, log storage, privacy.

5) RACI: Ownership and Responsibility

Process    R (performer)    A (responsible)    C (consultant)    I (notify)
------------------------      ---------------      -----------------      ---------------      -------------
Create/Update SOP     Domain Owner       Head of Ops         SRE/Compliance      Teams
SLA Revision     Ops Enablement      Head of Ops        Domain leads     All
Use in an incident     On-call          Incident Manager      Domain Owner       Stakeholders

6) SOP lifecycle

1. Initiation: need from post-mortem/incident/audit.
2. Draft: by template, with specific artifacts and commands.
3. Review: Domain Owner + Head of Ops + specialized consultants.
4. Publishing: to portal/repository; annotations on dashboards.
5. Training: short training/screencast, knowledge test.
6. Application: recorded in ticket/incident.
7. Audit: by SLA revision or after a significant event.
8. Archiving: mark 'deprecated', indicate replacement.

7) Documentation as code (minimum standard)

We store SOP in Git (Markdown + YAML metadata), PR review, CI-lint.
Required fields are 'owner', 'version', 'last _ review', 'sla _ review'.
Link checker and structure validator in CI; auto-release portal after merge.
Significant changes - through changelog and notifications in the # ops channel.

8) SOP integrations

Incident Manager: Open SOP button when creating/escalating an incident.
Grafana/Observability: references from panels to relevant SOPs; release annotations.
Feature Flags/Release: canary step templates, SLO gates, rollback.
AI assistant: RAG search by SOP, TL; DR and proposals for action.
BCP/DR: DR-playbook automatically loaded by trigger.

9) SOP quality check (KPI and review)

KPI:
Coverage ≥ 90% of critical scenarios are closed by SOP.
Review SLA ≤ 180 days (share of overdue - 0).
Usage Rate ≥ 70% of overt SOP incidents.
DoD Pass Rate ≥ 90% of steps are closed with success criteria.
Broken Links = 0 (по CI).

Weekly monitoring:
Top 5 used and top 5 obsolete SOPs.
SOP communication ↔ postmortems: whether Preventive Actions have been performed.
Noisy SOPs (frequent rollback returns) are candidates for recycling.

10) Containment standards

Steps → specifics: commands/queries/parameters + expected effect in metric.
Time requirements: ETA for updates/next steps.
Escalation: clear matrix, contacts, backup channels.
Security: warnings, restrictions, PII/secrets - via vault/links.
Localization: in the on-call language (critical for distributed commands).

11) SOP examples (fragments)

SOP: Canary pause in SLO degradation

Triggers: error_budget_burn > 4x 10m, api_p99 > 1. 3×baseline 10m

• 1) პაუზის კოშკი რელიეფის ოთახში (ბმული)
• 2) შეამოწმეთ პანელები „Change Safety“ და „API p99“
• 3) შექმნათ ticket REG , მიუთითეთ baseline/ფანჯარა
• DoD: p99 ≤ 1. 1 × baseline 15 მ, შეცდომები
• Rollback: დროშის სრული გამორთვა, postmortem 72ch

SOP: PSP Provider Feilover

Triggers: quota_usage>0. 9 OR outbound_error_rate>2×baseline 5m

• 1) ჩართეთ routing PSP-Y (კონფისკაცია/ღილაკი)
• 2) შეამოწმეთ დეპოზიტების კონვერტაცია და p95 PSP-Y
• 3) სურათები გრაფიკებზე, განახლება # incident channel
• DoD: success_rate ≥ 99. 5%, p95-300ms 10m
• Rollback: ნაწილობრივი ტრაფიკის დაბრუნება 20% PSP-X სტაბილიზაციისას

12) ჩეკის ფურცლები

SOP მზადყოფნის სია:
[] მიზნები და გამომწვევები გასაგები და საზომია.
[] არსებობს ეტაპობრივი მოქმედებები ბრძანებებით/ბმულებით.
[] DoD/Rollback ჩამოყალიბებულია.
[] ესკალაცია და კონტაქტები აქტუალურია.
[] მეტამონაცემები სავსეა (owner, version, last _ review).
[] ლინკ-ჩეკერი და CI წამყვანები გადის.

SOP ჩეკის სია (ინციდენტში):
[] SOP ღიაა Incident Manager- დან/პანელზე ბმულები.
[] გადადგა ნაბიჯები და დაფიქსირდა შედეგები.
[] DoD მიღწეულია/არა - აღინიშნება.
[] მოქმედებები/შეუსაბამობები ჩაწერილია თიკეტში.
[] SOP განახლებები/გაუმჯობესება შეიქმნა დავალებებით (საჭიროების შემთხვევაში).

13) ტრენინგი და ონბორდი

მინი კურსები საკვანძო SOP (Payments/Bets/Games/KYC).
Shadow მოვალეობა SOP- ის სავალდებულო გამოყენებით ვარჯიშში.
ყოველკვირეული „SOP კლინიკები“: 30 წუთი ანალიზები/გაუმჯობესება.
სიმულაციები (თამაშის დღეები): DR- და ინციდენტის SOP განვითარება.

14) SOP ცვლილების მენეჯმენტი

RFC მეშვეობით PR, ჭდეები 'minor/major/breaking'.
Breaking ცვლილებები - სავალდებულო სწავლებით და გამოცხადებით.
მანქანების შეტყობინებები დომენების მფლობელებსა და კოლონა.
ცალკეული „SOP-Release Notes“ ყოველი კვირის ბოლოს.

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

უფასო ფორმა „როგორ გამოდგება“ და გუნდების სხვადასხვა შაბლონები.
SOP მფლობელის/ვერსიის/აუდიტის თარიღის გარეშე.
„ენციკლოპედიური“ ტექსტები ეტაპობრივი მოქმედებების ნაცვლად.
არა Rollback/DoD - წარმატების შესამოწმებლად არაფერია.
გატეხილი ბმულები, ბრძანებები „ხელით ჩატიდან“, პირადი „საიდუმლო“ ნაბიჯები.
SOP- ის უხილავი ცვლილებები ჩაწერისა და სწავლების გარეშე.

16) 30/60/90 - განხორციელების გეგმა

30 დღე:
დაამტკიცეთ SOP შაბლონი და მინიმალური სტანდარტები.
შექმენით საცავი 'ops-sop/' (docs-as-code), ჩართეთ CI ლინტერი.
ციფრული 10-15 კრიტიკული SOP (ინციდენტები/გამოშვებები/პროვაიდერები).
ინტეგრაციის მენეჯერის და სადამკვირვებლო პანელების დაკავშირება SOP ბმულებზე.

60 დღე:
Coverage- ის მიღწევა კრიტიკულ სცენარებში 70% -ს შეადგენს.
დაიწყეთ ყოველკვირეული „SOP კლინიკები“ და ტრენინგი.
დაამატეთ AI ძებნა (RAG) SOP და TL- ით; DR ბარათები.
შემოიღეთ მიმოხილვა SLA (180 დღე) და ვადაგადაცილებული SOP მოხსენებები.

90 დღე:
Coverage - 90%, Usage Rate - ინციდენტების 70%.
ჩამონტაჟეთ DoD/Rollback ყველა SOP- ში, დახურეთ გატეხილი ბმულები (0).
დაუკავშირეთ KPI SOP OKR გუნდებს (MTTR, Change Failure Rate).
ჩაატარეთ რეტრო და დააფიქსირეთ შემდეგი კვარტლის გაუმჯობესება.

17) FAQ

Q: როგორ განსხვავდება SOP runbook- დან?
A: SOP - სტანდარტიზებული პროცედურა (რეგულაცია „როგორ არის სწორი“). Runbook - დეტალური ინსტრუქციები კონკრეტული საქმის/მომსახურებისთვის. ხშირად SOP ეხება ერთ ან მეტ runbook- ს.

Q: რამდენი დეტალი უნდა იყოს SOP- ში?
A: ზუსტად იმდენი, რომ ოპერატორმა შეძლო მოქმედების შესრულება ჩატის „ჩამოსხმის“ გარეშე. ყველაფერი, რაც გავლენას არ ახდენს მოქმედებაზე, გარკვეულ საცნობარო მასალებშია.

Q: როგორ შევინარჩუნოთ აქტუალობა?
A: SLA გადასინჯვა (180 დღე), ავტომატური შეხსენებები, CI ლინტერი და Usage/DoD მეტრიკა. გადახრები ნებისმიერი ინციდენტი SOP- ის განახლების ამოცანაა.