Standard Operating Procedures

1) SOP nədir və niyə lazımdır

SOP (Standard Operating Procedure) - başa düşülən giriş/çıxış, rollar və keyfiyyət meyarları ilə təkrar əməliyyatlar üçün rəsmiləşdirilmiş, təsdiq edilmiş addım ardıcıllığıdır.

• İcra və risklərin dəyişkənliyinin azaldılması.
• Hazır tədbirlər vasitəsilə MTTA/MTTR azaldılması.
• Uyğunluq və audit: təkrarlanabilirlik, izlənilebilirlik.
• Onbording: öyrənmə sürətləndirilməsi və «shadow → solo».

SOP ≠ pleybuk: pleybuk - yivli ağac həlləri, SOP - müəyyən bir ssenari (və ya pleybuk budağı) üçün xətti tənzimləmə.

2) «yaxşı» SOP prinsipləri

Outcome-Driven: nəticəyə diqqət yetirin (SLO/biznes meyarları), yalnız addımlarla deyil.
Dəqiqlik: komandalar, parametrlər, gözlənilən effektlər və nəzarət nöqtələri.
Default təhlükəsizlik: geytlər, limitlər, backout/rollback təyin olunur.
Minimum kontekst: qısa qeydlər + ətraflı runbook/diaqnostika linkləri.
Aktuallıq: review tarixi, sahibi, versiyası, etibarlılıq müddəti.
İcra: JIT/JEA girişləri, ön şərt yoxlamaları, artefakt şablonları.

3) SOP standart strukturu (skelet)

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 kataloqu və sahiblik

'domain/ops', 'service/checkout', 'risk/high', 'provider/psp-a' etiketləri ilə vahid anbar (Docs-as-Code).
Kart sahibi: komanda, növbətçi əlaqə, ehtiyat sahibi.
SLA aktuallığı (məsələn, hər ≤ 90 gün və ya hadisə/buraxılışdan sonra yenidən baxılması).
Linter/validator SOP (CI): struktur, linklər, sahibləri, review müddəti.

5) SOP həyat dövrü

1. Başlanğıc (hadisədən/təlimdən/yeni prosesdən sonra).
2. Layihə (müəllif = xidmət/proses sahibi).
3. Review (SRE/Security/Legal/Comms - domen vasitəsilə).
4. Pilot (tabletop/game day): vaxt ölçmək, tapmaq → düzəlişlər.
5. Nəşr (versiya, tarix, nömrə, CMDB/xidmət kataloqunda şablonlar).
6. Əməliyyat tətbiqi (biletlərdə/söhbətlərdə şərhlər, evidence yığımı).
7. Yeniləmə (RCA/CAPA, revyu, memarlıq dəyişiklikləri).
8. Arxivləşdirmə/deprekasiya (yeni SOP/playbook ilə əvəz olunur).

6) Qonşu artefaktlarla əlaqələr

Playbook: SOP - playbook daxilində «xətti budaq»; addımlardan keçid.
Runbook 'i: texniki təfərrüatları/skriptləri runbook daxil edilir, SOP istinad edir.
Siyasətlər (Policy-as-Code): Giriş qeytləri, Retens, RBAC - məcburi linklər.
SLO/SLI: uğur meyarları və garde-rails.
Eskalasiya matrisi: SOP uğursuz olduqda rollar/zamanlamalar.
Xidmət pəncərələri: yüksək risk SOP üçün slot/comma tələbləri.

7) SOP effektivliyinin metrikası

Time-to-Execute (mediana/p95) - prosedur nə qədər çəkir.
Success Rate - eskalasiya/geri dönüş olmadan uğurlu performansların payı.
Evidence Completeness - artefaktların dolğunluğu.
SLO Impact - addım (burn-dəqiqə) zamanı/sonra deqradasiya var.
Defect Density - 10 SOP-də revyu/təlimlər zamanı qeydlər.
Freshness - 90 gün ≤ review ilə SOP payı.
Adoption - SOP-yə həqiqətən nə qədər alert/pəncərə bağlıdır.

8) SOP müəllifinin çek siyahısı

• Məqsəd və tətbiq sərhədləri müəyyən edilmişdir.
• Rollar, girişlər və pəncərələr - təsvir edilmişdir.
• Keyfiyyət geytləri və SLO ölçüləndir, siqnal mənbələri var.
• Addımlar həyata keçirilir: komandalar/skriptlər, gözlənilən nəticələr, yoxlama.
• Backout/rollback və başlanğıc meyarları - aydın.
• Comm şablonları əlavə edilmişdir.
• Evidence siyahısı strukturlaşdırılmışdır.
• Versiyası/tarix/sahibi/review göstərilir.

9) SOP icraçısının yoxlama siyahısı

• JIT/JEA ön şərtləri və çıxışları təsdiqləndi.
• Bilet/war-room açılır və şərhlər daxil edilir.
• Müşahidə: Lazımi daşbordlar/alertlər açıqdır.
• Ardıcıllıqla addımlar atıram; hər birindən sonra - yoxlama.
• Gardrails pozulması - dərhal backout və eskalasiya.
• Evidence dolu; SLO/biznes-SLI-nin yekun yoxlaması.
• Sorğu bağlanıb, status-səhifə/komms yenilənib.

10) SOP nümunələri (fraqmentlər)

10. 1 SOP: Kanarya relizi (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: Planlı yeniləmə 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 Provider keçid (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: Backup Recovery Check (DATA-BACKUP-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 ətrafında avtomatlaşdırma

SOP şablonlaşdırıcısı: RACI/geyt/komm bloklu skelet istehsalı.
Bot ifaçısı: çek qutuları ilə addımlar, zamanlayıcılar, cadence xatırlatmaları, evidence avtomobil kolleksiyası.
CMDB/kataloq ilə inteqrasiya: xidmətdə - müvafiq SOP siyahısı.
Telemetriya şərhləri: «SOP-RUN: <ID> step N» → sürətli təhlil.
Giriş siyasəti: deploy/pəncərə yalnız yaşıl SOP geytləri ilə başlayır.

12) Anti-nümunələr

Sahibi/tarixi olmayan SOP «ölü» sənəddir.
Uğur meyarları və backout olmadan şişirdilmiş təlimatlar.
Razılaşdırılmamış komandalar/açarlar - səhv və sızma riski.
Wiki və anbarda müxtəlif versiyalar - həqiqət mənbələrinin uyğunsuzluğu.
Heç bir evidence - keyfiyyəti/uyğunluğu təsdiqləmək üçün heç bir şey yoxdur.
«Bütün hallar üçün bir SOP» - icra qabiliyyətini itirir.

13) Tətbiqi yol xəritəsi (4-6 həftə)

1. Ned. 1: SOP şablonunu, linter və kataloqu təsdiq edin; Ən yaxşı 10 ssenarini seçin.
2. Ned. 2: Releases/rebound/provayder/backup üçün SOP yazın; pilotlar tabletop.
3. Ned. 3: ChatOps bot və telemetriya şərhlərini bağlayın; SOP ilə alert bağlamaq.
4. Ned. 4: rebound cədvəli; Freshness/Success Rate metrikləri daxil edin.
5. Ned. 5-6: kritik əməliyyatların 90% əhatə; DR/Security-SOP; evidence yığımını avtomatlaşdırmaq.

14) Yekun

SOP əməliyyatları proqnozlaşdırıla bilən və yoxlanıla bilən edir: vahid keyfiyyət geytaları, ətraflı addımlar, açıq rollar və geri dönüş. Playbook, siyasətçilər, SLO və avtomatlaşdırma ilə birlikdə bu, istismarı etibarlı bir istehsal xəttinə çevirir - sürətli reaksiyalar, minimal risk və başa düşülən məsuliyyət.