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

Операциялык процедураларды стандартташтыруу

1) Эмне үчүн керек

SOP - бул компаниянын "операциондук ОС". Стандартташтыруу башаламандыкты жана "жеке стилдерди" жок кылат, MTTRди, алерттердин ызы-чуусун жана инциденттердин коркунучун азайтат, байланышты тездетет жана натыйжаларды кайталанма кылат.

• Окуялар жана күнүмдүк иштерде иш-аракеттердин вариативдүүлүгүн азайтуу.
• Окутууну тездетүү жана хендоверлердин сапатын жогорулатуу.
• Процесстерди текшерилүүчү кылуу: аудит, метрика, маалыматтар боюнча жакшыртуу.
• Жөнгө салуучу жана ички талаптарга ылайык келүүсүн камсыз кылуу.

2) Стандартташтыруу принциптери

1. Бирдиктүү формат жана терминология. Бир нотация, бир аныктамалар (SLO, ETA, Owner).
2. Actionable, эмес, энциклопедия. Болгону текшерилүүчү кадамдар, ийгиликтин жана артка кайтаруунун критерийлери.
3. Минималдуу бутактануу. Эркин билдирүүнүн ордуна "эгер/анда" деген так чечимдер.
4. Версиялоо жана ээлик кылуу. Ар бир SOP ээси, версия жана текшерүү датасы бар.
5. Инструменттер менен интеграция. Дашбордддорго, билеттерге, физикалык фонддорго, CLI командаларына шилтемелер.
6. On-колл жеткиликтүүлүгү. Тез издөө, окуу, бир шилтемени аткаруу.
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) Пауза канары менен release-tool (шилтеме)
• 2) "Өзгөртүү коопсуздук" жана "API p99" панелдерин текшерүү
• 3) REG- тикет түзүү, baseline/терезени көрсөтүү
• DoD: p99 ≤ 1. 1 × baseline 15m, ката
• Rollback: желекти толук өчүрүү, постмортем ≤ 72h

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 ≤ 300ms 10m
• Rollback: PSP-X турукташтыруу менен 20% жарым-жартылай жол кайтаруу

12) Чек-баракчалар

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

SOP колдонуу чек тизмеси (окуя):
[] SOP Incident Manager/Panel шилтемелер ачык.
[] кадамдар аткарылган жана натыйжалары жазылган.
[] DoD жетишилди/жок - белгиленген.
[] Иш-аракеттер/дал келбестиктер билетте жазылган.
[] SOP жаңыртуу/жакшыртуу тапшырмалар менен түзүлгөн (зарыл болсо).

13) Окутуу жана онбординг

негизги SOP Mini курстар (Payments/Bets/Games/KYC).
Машыгууда милдеттүү SOP колдонуу менен Shadow-милдети.
Жумалык "SOP-клиникалар": 30 мүнөт талдоо/жакшыртуу.
Симуляциялар (оюн-күндөр): DR- жана окуя SOP иштеп чыгуу.

14) SOP өзгөрүүлөрдү башкаруу

PR аркылуу RFC, теги 'minor/major/breaking'.
Breaking-өзгөртүүлөр - милдеттүү окутуу жана жарыялоо менен.
домен ээлерине жана он-коллга Auto-эскертмелер.
Ар бир жуманын аягында өзүнчө "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% окуялар.
Бардык SOP үчүн DoD/Rollback киргизүү, сынган шилтемелерди жабуу (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 жаңыртуу милдети.