SOP: <ռուսական գործողություն/նպատակ>

Վիրահատական ընթացակարգերի ստանդարտացումը

1) Ինչո՞ ւ է դա անհրաժեշտ

SOP-ը ընկերության «վիրահատական ՕՀ» է։ Ստանդարտիզացիան մաքրում է քաոսը և «անհատական ոճերը», նվազեցնում է MTTR-ը, ալտերտերի աղմուկը և պարամետրերի ռիսկերը, արագացնում է ուռուցքաբանը և դարձնում արդյունքները վերարտադրված։

Նպատակները

Նվազեցնել գործողությունների փոփոխականությունը միջադեպերի և ռուտինների ժամանակ։

Արագացնել ուսուցումը և բարձրացնել հենդովերների որակը։

Աուդիտ, չափումներ, բարելավումներ ըստ տվյալների։

Ապահովել կարգավորող և ներքին պահանջներին համապատասխանությունը։

2) Ստանդարտացման սկզբունքները

1. Միասնական ձևաչափը և տերմինոլոգիան։ Մեկ նոտացիա, որոշ սահմանումներ (SLO, ETA, Owner)։

2. Actionable, ոչ հանրագիտարանը։ Միայն ստուգված քայլերը, հաջողության և արձագանքման չափանիշները։

3. Նվազագույն ճյուղը։ Հստակ որոշումներ «եթե/ապա» ազատ ներկայացման փոխարեն։

4. Տարբերակումը և սեփականությունը։ Յուրաքանչյուր SOP-ն ունի սեփականատեր, տարբերակը և մրցույթի ամսաթիվը։

5. Ինտեգրումը գործիքների հետ։ Dashbords, tikets, ficheflagy, CLI թիմեր։

6. Նա կոլում հասանելիություն ունի։ Արագ փնտրել, կարդալ, կատարել մեկ հղում։

7. Շարունակական բարելավում։ POSTMORTMORTEMORTEM-ը

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 releom-tool (հղում)
• 2) Ստուգել «Change Safety» և «APP99» վահանակները։
• 3) Ստեղծել REG- ի հյուսվածքը , նշել baseline/պատուհանը
• DoD: p99 ≤ 1. 1 baseline 15m, սխալներ
• Rollback: Դրոշի ամբողջական անջատումը, հետմորտը 3872ch

SOP: PSP Provider Feilover

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

• 1) Միացրեք routing PMS-Y (wwww.g/կոճակը)
• 2) Ստուգել ավանդների ծրարը և p95 PMS-Y-Y-ը։
• 3) Ծանոթագրություններ գծապատկերներում, ապդեյթ # incident-channel
• DoD: success_rate ≥ 99. 5%, p95 24300ms 10m
• Rollback: Մասնակի տրամագիծը 2420 տոկոսն է PMS-X-ում

12) Չեկ թերթերը

SOP-ի պատրաստակամության թուղթը

[] Նպատակը և ձգանները հասկանալի և չափելի են։
[] Թիմերի/հղումների հետ շրջադարձային գործողություններ կան։
[] DoD/Rollback-ը ձևակերպված է։
[] Էսկալացիաները և շփումները արդիական են։
[] Մեթադները լցված են (owner, version, lance _ review)։
[] Link-cheker և CI-ի վալիդատոր անցնում են։

SOP-ի օգտագործման չեկ-թերթիկը (պատահականության մեջ)

[] SOP-ը բացվում է Incident Express/հղում վահանակի վրա։
[] Քայլեր են արվել և գրանցվել արդյունքները։
[] DoD հասել/ոչ - ռուսական։
[] Գործողությունները/անհամապատասխանությունները գրված են տիկետում։
[] SOP թարմացումները/բարելավումները ստեղծվել են առաջադրանքներով (եթե անհրաժեշտ են)։

13) Ուսուցում և ոնբորդինգ

Մինի-դասընթացները հիմնական SOP (Payments/Bets/Games/KYC)։
Shadow-հերթապահությունները, որոնք ունեն SOP-ի օգտագործումը ուսուցման վրա։
Շաբաթական «SOP կլինիկա» '30 րոպե վերլուծություններ/բարելավումներ։
Սիմվոլը (game-days) 'RF-ի ուսումնասիրությունը և SOP-ը։

14) SOP փոփոխությունների կառավարումը

RSA-ն PR-ի միջոցով, թեգերը 'minor/major/breaking "։
Breaking-փոփոխությունները 'ռուսական ուսուցման և անոնսի հետ։
Avto-ծանուցումները օրինագծերի սեփականատերերին և նա-քոլեջին։
Առանձին «SOP-Releant Notes» -ը յուրաքանչյուր շաբաթվա վերջում։

15) Anti-patterna

Ազատ ձևը «ինչպե՞ ս կստացվի» և թիմերի տարբեր ձևանմուշներ։
SOP առանց սեփականատիրոջ/տարբերակի/մրցույթի ամսաթվի։
«Հանրագիտարանային» տեքստերը փոխարենը ցնցող գործողությունների փոխարեն։
Ոչ Rollback/DoD-ը հաջողության ստուգելու բան չէ։
Բիթերի հղումները, «ձեռքով չաթից» թիմերը, մասնավոր «գաղտնի» քայլերը։
SOP-ի անտեսանելի փոփոխությունները առանց ձայնագրման և ուսուցման։

16) 30/60/90 - իրականացման պլանը

30 օր

Հաստատել SOP-ը և նվազագույն ստանդարտները։
Ստեղծել «ops-sop/» (docs-as-code), ներառել CI-liners։
10-15 քննադատական SOP (միջադեպեր/ֆորումներ/պրովայդերներ)։
Միացրեք Incident Express-ը և դիտարկման վահանակները SOP հղումներին։

60 օր

Coverage-ի հասնելը 70 տոկոսն է քննադատական սցենարներով։
Սկսել շաբաթական «SOP կլինիկաները» և նա-կոլայի դասընթացները։
Ավելացնել AI-որոնումը (RAG) SOP և TL-ով։ DR քարտեր։
Ներդրել Review SLA (180 օր) և զեկուցել ժամկետանց SOP-ի մասին։

90 օր

Coverage-90 տոկոսը, Usage Rate-ը 2470 տոկոսը։
Ներկառուցել DoD/Rollback բոլոր SOP-ում, փակել բիթային հղումները (0)։
Կապել KPI SOP-ը OKR թիմերի հետ (MTTR, Change Failure Rate)։
Անցկացնել ռետրո և շտկել հաջորդ զանգվածի բարելավումները։

17) FAQ

Q: Ինչպե՞ ս է SOP-ը տարբերվում runbook-ից։
A: SOP-ը ստանդարտացված ընթացակարգ է (կարգավորումը «ճիշտ»)։ Runbook-ը մանրամասն հրահանգներ է կոնկրետ գործի/2019 համար։ Հաճախ SOP-ը տեղադրված է մեկ կամ մի քանի runbook-ում։

Q 'Քանի՞ մասեր պետք է լինեն SOP-ում։
A 'Ճիշտ այնքան, որ օպերատորը կարողանա անել առանց «կրկնապատկման»։ Այն ամենը, ինչ չի ազդում գործողության վրա 'որոշ տեղեկատու նյութերում։

Q 'Ինչպե՞ ս պահպանել արդիականությունը։
A: SLA 71 (38180 օր), ավտոմատ հիշեցումներ, CI-ոսպնյակներ և Usage/DoD մետրիկ։ Շեղումների ցանկացած պատահականություն բացատրում է SOP-ի նորարարման խնդիրը։