SOP:

Əməliyyat prosedurlarının standartlaşdırılması

1) Niyə lazımdır

SOP şirkətin "əməliyyat sistemi 'dir. Standartlaşdırma xaos və «fərdi stilləri» aradan qaldırır, MTTR, həyəcan səs-küyü və insident risklərini azaldır, bağlama sürətləndirir və nəticələri təkrarlanabilir edir.

• Hadisələr və rutinlərdə hərəkətlərin dəyişkənliyini azaltın.
• Təlimi sürətləndirin və hendoverlərin keyfiyyətini artırın.
• Prosesləri sınaqdan keçirin: audit, metrika, məlumatlara görə təkmilləşdirmə.
• Tənzimləyici və daxili tələblərə uyğunluğu təmin edin.

2) Standartlaşdırma prinsipləri

1. Vahid format və terminologiya. Bir notasiya, bir tərif (SLO, ETA, Owner).
2. Actionable, bir ensiklopediya deyil. Yalnız yoxlanılan addımlar, uğur və geri dönüş meyarları.
3. Minimal budaq. Sərbəst ifadə əvəzinə «əgər/o» aydın həllər.
4. Version və sahiblik. Hər SOP-nin sahibi, versiyası və yoxlama tarixi var.
5. Alətlərlə inteqrasiya. Dashboard linkləri, biletlər, ficheflaglar, CLI komandaları.
6. On-call mövcudluğu. Tez axtarış, oxumaq, bir link yerinə yetirmək.
7. Davamlı təkmilləşdirmə. Postmortems → SOP yeniləmə tapşırıqları.

3) SOP çərçivə (şablon)

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) Pause canary release-tool (link)
• 2) «Change Safety» və «API p99» panellərini yoxlayın
• 3) REG- bilet yaratmaq, baseline/pəncərə göstərmək
• DoD: p99 ≤ 1. 1 × baseline 15m, səhvlər
• Rollback: bayrağın tam bağlanması, postmortem ≤ 72h

SOP: PSP Provider Feilover

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

• 1) PSP-Y marşrutlaşdırılmasını aktivləşdirin ( /düymə)
• 2) Depozitlərin çevirilməsini yoxlayın və p95 PSP-Y
• 3) Qrafiklərdə şərhlər, #incident -channel yenilənməsi
• DoD: success_rate ≥ 99. 5%, p95 ≤ 300ms 10m
• Rollback: PSP-X sabitləşməsində 20% qismən trafik qaytarılması

12) Çek vərəqləri

SOP hazırlıq siyahısı:
[] Hədəf və tetikləyicilər başa düşüləndir və ölçüləndir.
[] Komandalar/linklərlə addım-addım hərəkətlər var.
[] DoD/Rollback tərtib edilmişdir.
[] Eskalasiya və əlaqə aktualdır.
[] Metadata (owner, version, last_review).
[] Link checker və CI validator keçir.

SOP tətbiqinin yoxlama siyahısı (insidentdə):
[] SOP Incident Manager/panel linklərindən açıqdır.
[] Addımlar yerinə yetirilib və nəticələr qeydə alınıb.
[] DoD əldə/yox - qeyd.
[] Hərəkətlər/uyğunsuzluqlar biletdə qeyd olunur.
[] SOP yeniləmələri/təkmilləşdirmələri vəzifələr tərəfindən yaradılır (lazım olduqda).

13) Təlim və bağlama

Açar SOP (Payments/Bets/Games/KYC) üzrə mini kurslar.
Məşqlərdə SOP-nin məcburi tətbiqi ilə Shadow vəzifələri.
Həftəlik «SOP-klinikalar»: 30 dəqiqəlik təhlil/təkmilləşdirmə.
Simulyasiyalar (game-days): DR- və insident SOP-lərin işlənməsi.

14) SOP dəyişikliyinin idarə edilməsi

PR vasitəsilə RFC, etiketlər 'minor/major/breaking'.
Breaking-dəyişikliklər - məcburi təlim və elan ilə.
Domen sahiblərinə və on-kola avtomatik bildirişlər.
Hər həftənin sonunda ayrıca «SOP-Release Notes».

15) Anti-nümunələr

Sərbəst forma «necə olur» və komandalara görə müxtəlif şablonlar.
SOP heç bir sahibi/versiyası/yoxlama tarixi.
Addım-addım hərəkət etmək əvəzinə «ensiklopedik» mətnlər.
Rollback/DoD yoxdur - müvəffəqiyyəti yoxlamaq üçün heç bir şey yoxdur.
Sındırılmış linklər, «əl ilə chat» komandaları, xüsusi «gizli» addımlar.
Qeyd və təlim olmadan görünməz SOP dəyişiklikləri.

16) 30/60/90 - tətbiq planı

30 gün:
SOP şablonunu və minimum standartları təsdiq edin.
'ops-sop/' (docs-as-code) anbarını yaradın, CI linterlərini daxil edin.
10-15 kritik SOP (insidentlər/buraxılışlar/provayderlər) rəqəmsallaşdırın.
Incident Manager və müşahidə panellərini SOP linklərinə qoşun.

60 gün:
Kritik ssenarilərdə Coverage ≥ 70% -ə çatmaq.
Həftəlik «SOP-klinikalar» və on-cola təlimləri başlayın.
SOP və TL ilə AI-axtarış (RAG) əlavə edin; DR kartları.
Review SLA (180 gün) və vaxtı keçmiş SOP hesabatlarını daxil edin.

90 gün:
Coverage ≥ 90%, Usage Rate ≥ 70% insidentlər.
DoD/Rollback-i bütün SOP-lərə inteqrasiya edin, sınmış bağlantıları bağlayın (0).
KPI SOP-i OKR komandalarına (MTTR, Change Failure Rate) bağlayın.
Retro keçirin və növbəti rübün yaxşılaşdırılmasını qeyd edin.

17) FAQ

Q: SOP runbook fərqli nədir?
A: SOP - standartlaşdırılmış prosedur (düzgün qaydalar). Runbook - xüsusi case/xidmət üçün ətraflı təlimat. Tez-tez SOP bir və ya bir neçə runbook istinad edir.

Q: SOP neçə detal olmalıdır?
A: Tam o qədər ki, operator chatda «qazma» olmadan hərəkətləri yerinə yetirə bilər. Hərəkətə təsir etməyən hər şey ayrı-ayrı istinad materiallarındadır.

S: Aktuallığı necə saxlamaq olar?
A: SLA reviziyaları (≤ 180 gün), avtomatik xatırlatmalar, CI linterlər və Usage/DoD metrikası. Hər hansı bir sapma hadisəsi → SOP yeniləmə vəzifəsi.