SOP: <қысқа әрекет/мақсат>

Операциялық рәсімдерді стандарттау

1) Бұл не үшін қажет

SOP - бұл компанияның «операциялық ОС». Стандарттау хаос пен «жеке стильдерді» жояды, MTTR-ді, алерт шуын және тосын оқиғалар қаупін төмендетеді, онбордингті жеделдетеді және нәтижелерді жаңғыртуға болады.

• Оқиғалар мен рутина кезінде әрекеттердің вариативтілігін төмендету.
• Оқытуды жеделдету және хендоверлердің сапасын арттыру.
• Тексерілетін процестерді жасау: аудит, метрика, деректер бойынша жақсарту.
• Реттеушілік және ішкі талаптарға сәйкестікті қамтамасыз ету.

2) Стандарттау қағидаттары

1. Бірыңғай формат және терминология. Бір нотация, бір анықтама (SLO, ETA, Owner).
2. Actionable, энциклопедия емес. Тек тексерілетін қадамдар, табыс пен кері қайтару критерийлері.
3. Ең аз тармақталу. Еркін мазмұнның орнына «егер/онда» деген нақты шешімдер.
4. Нұсқалау және меңгеру. Әрбір SOP иесі, нұсқасы және тексеру күні бар.
5. Құралдармен біріктіру. Дашбордтарға, тикеттерге, фичефлагтарға, CLI командаларына сілтемелер.
6. Он-колла қол жетімділігі. Бір сілтемені жылдам іздеу, оқу, орындау.
7. Үздіксіз жақсарту. Постмортемалар → 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) Pause canary in release-tool (сілтеме)
• 2) «Change Safety» және «API p99» панельдерін тексеру
• 3) REG- дегенді құру, baseline/терезені көрсету
• DoD: p99 ≤ 1. 1 × baseline 15m, қателер
• Rollback: жалауды толық өшіру, постмортем ≤ 72 сағ

SOP: PSP Provider Feilover

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

• 1) PSP-Y роутингін қосу ( /түймешік)
• 2) Депозиттердің және p95 PSP-Y конверсиясын тексеру
• 3) Графиктегі аннотациялар, #incident -channel-дегі апдейт
• DoD: success_rate ≥ 99. 5%, p95 ≤ 300мс 10м
• Rollback: PSP-X тұрақтандыру кезінде 20% ішінара трафикті қайтару

12) Чек парақтары

SOP дайындық парағы:
[] Мақсат пен триггерлер түсінікті және өлшемді.
[] Командалармен/сілтемелермен қадамдық әрекеттер бар.
[] DoD/Rollback тұжырымдалған.
[] Эскалация мен байланыстар өзекті.
[] Метадеректер (owner, version, last_review).
[] Линк-чекер және CI валидаторы өтеді.

SOP қолдану парағы (инцидентте):
[] SOP Insident Manager/тақтадағы сілтемелер арқылы ашық.
[] Қадамдар орындалды және нәтижелер бекітілді.
[] DoD жетті/жоқ - белгіленді.
[] Әрекеттер/сәйкессіздіктер тикетте жазылған.
[] SOP жаңартулары/жақсартулары тапсырмалармен жасалған (егер қажет болса).

13) Оқыту және онбординг

Негізгі SOP бойынша шағын курстар (Payments/Bets/Games/KYC).
Жаттығуларда міндетті түрде SOP қолданумен Shadow-кезекшілік.
Апта сайынғы «SOP-клиникалар»: 30 минут талдау/жақсарту.
Simulation (game-days): DR- және инциденттік SOP пысықтау.

14) SOP өзгерістерін басқару

PR арқылы RFC, '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 (инциденттер/релиздер/провайдерлер) цифрлау.
Incident Manager және бақылау тақталарын SOP сілтемелеріне қосу.

60 күн:
Критикалық сценарийлер бойынша Coverage ≥ 70% -ға жету.
Апта сайынғы «SOP-клиникалар» мен он-колла тренингтерін іске қосу.
SOP және TL бойынша AI-іздеуді (RAG) қосу; DR карточкалары.
Review SLA (180 күн) және мерзімі өткен SOP бойынша есептілікті енгізу.

90 күн:
Coverage ≥ 90%, Usage Rate ≥ 70% оқыс оқиғалар.
DoD/Rollback бағдарламасын барлық SOP жүйесіне ендіру, сынған сілтемелерді жабу (0).
KPI SOP бағдарламасын OKR командасына (MTTR, Change Failure Rate) байланыстыру.
Ретро жүргiзу және келесi тоқсанның жақсартуларын тiркеу.

17) FAQ

Q: SOP runbook айырмашылығы қандай?
А: SOP - стандартталған рәсім («қалай дұрыс» регламенті). Runbook - нақты кейс/сервис үшін егжей-тегжейлі нұсқаулықтар. SOP көбінесе бір немесе бірнеше runbook бағдарламасына сілтеме жасайды.

Q: SOP қанша бөлшек болуы тиіс?
A: Оператор сөйлесуге «түбін қазусыз» әрекеттерді орындай алатындай. Әрекетке әсер етпейтіндердің барлығы - жекелеген анықтамалық материалдарға.

Q: Өзектілікті қалай сақтауға болады?
A: SLA тексеру (180 күнге ≤), автоматты ескертулер, CI-линтерлер және Usage/DoD метрикасы. Кез келген ауытқу оқиғасы → SOP жаңарту тапсырмасы.