ოპერაციული ფენის არქიტექტურა

1) ოპერაციული ფენის პრობლემა

ოპერაციული ფენა არის პლატფორმა და პრაქტიკის ერთობლიობა, რომელიც უზრუნველყოფს პროგნოზირებულ ოპერაციას: სწრაფი გამოშვება, დაბალი MTTR, შესაბამისობა და კონტროლირებადი ღირებულება. იგი ქმნის მოაჯირს პროდუქტებისა და ინფრასტრუქტურისთვის: სტანდარტები, ავტომატიზაცია, დაკვირვება, ცვლილებების მენეჯმენტი და უსაფრთხო დაშვება.

2) ლოგიკური მოდელი (თვითმფრინავები და დომენები)

┌────────────────────────────────────────────────────────┐
│        Interface Plane (UX)          │← ChatOps/Portals/API
└────────────────────────────────────────────────────────┘
┌────────────────────────────────────────────────────────┐
│ Control Plane: Policy, Orchestration, Identity, CMDB │
└────────────────────────────────────────────────────────┘
┌────────────────────────────────────────────────────────┐
│ Data/Execution Plane: CI/CD, Jobs, IaC, Runtime Ops  │
└────────────────────────────────────────────────────────┘
┌────────────────────────────────────────────────────────┐
│ Telemetry Plane: Logs, Metrics, Traces, SLO Dashboards │
└────────────────────────────────────────────────────────┘
┌────────────────────────────────────────────────────────┐
│ Security & Compliance Plane: Secrets, RBAC, Audit, IR │
└────────────────────────────────────────────────────────┘
┌────────────────────────────────────────────────────────┐
│ Finance/Cost Plane: Usage, Quotas, Budgets, FinOps   │
└────────────────────────────────────────────────────────┘

• სერვისის კატალოგი/CMDB: სერვისების, მფლობელების, SLO, დამოკიდებულების ერთიანი რეესტრი.
• ორკესტრი: პლაკატები, დავალებები, გვირგვინები, ზურგჩანთები, DR.
• პოლიტიკოსები (Policy-as-Code): ალერტები, წვდომა, retentions, change-gates.
• დაკვირვება: მეტრიკა/ტრეისი/ლოგები, SLI/SLO, ალერტები და სტატუსის გვერდი.
• წვდომა/საიდუმლოებები: JIT/JEA, ნიშნები, კრიპტო, KMS/Vault.
• ინციდენტები/ცვლილებები: ITSM/თიკეტები, CAB/RFC, პოსტ-mortems, სიმულაციები.
• DataOps: მონაცემთა კონტრაქტები, სიახლე, ხაზები, ხარისხი.
• FinOps: ხარჯების, ლიმიტების, კვოტების, ოპტიმიზაციის აღრიცხვა.

3) რეფერენდუმის ნაკადები

3. 1 გამოშვება (CI/CD, GitOps)

1. PR კოდი/მანიფესტები - ტესტები/სკანერები - არტეფაქტების ხელმოწერა.
2. პროგრესული გამონაყარი (კანარი/ცისფერი-მწვანე) SLO გარდერობებით.
3. ავტო-როლბეკი დეგრადაციის დროს; გამოშვების ვერსიები ტელემეტრიაში.

3. 2 ინციდენტი (Detect - Respond - Recover)

1. Burn-rate/სიმპტომები + კვორუმი Page + ომის ოთახი.
2. დიაგნოზი ტრასებზე/ლოგებზე; playbuks.
3. პასუხი/ფოლკლორი/შეზღუდვები AAR/RCA/CAPA.

3. 3 ცვლილება (RFC/CAB)

1. რისკის ანალიზი + მომსახურების ფანჯარა + backout გეგმა.
2. არაკრიტიკული ალერტების სუპრესია, SLO სიგნალები აქტიურია.
3. ევიდენცია და მოხსენება, პოლიტიკოსის გადასინჯვა.

4) სერვისის კატალოგი და CMDB

ატრიბუტები: მეპატრონე, SLI/SLO, დამოკიდებულება (შიდა/გარე), დაშბორდები, ალერტები, runbook 'და, მონაცემთა კლასები (PII/ფინანსები), ზონები (stage/stage/dev).
მანქანის შევსება: CI/CD- დან, ტელემეტრიიდან და საცავებიდან.
გამოყენება: ალერტების მარშრუტიზაცია, ესკალაცია, blast radius- ის გაანგარიშება, სიმწიფის ანგარიში.

5) პოლიტიკა, როგორც კოდი (პოლიტიკა-ეს-კოდი)

კატეგორიები: წვდომა (RBAC/ABAC), უსაფრთხოება (SAST/SCA/DAST), ალერტები/SLO, რეტენციები, change-gates, რესურსები/კვოტები.
მექანიკა: დეკლარაციული წესები (YAML/Rego/CEL), შესაბამისობა CI- ში, იძულებითი შესრულება Control Plane- ში.
კარიბჭის მაგალითი: „დაიშვება, თუ ყველა SLO მწვანეა, არ არსებობს აქტიური SEV-1, ტესტები გაიარა, ხელმოწერები რეალურია“.

6) ორკესტრი და შესრულება

CI/CD: build → scan → sign → promote.
Jobs/CronJobs/DAG: bacaps/rotation/backfills; ვადები და კონკურენცია (Forbid/Replace).
Idempotence და გამოტოვება: check-then-act, ნაბიჯების მარკერები, circuit-breaker.
გაშვების უფლებები: JIT ანგარიშები შეზღუდული სკოპით; აუდიტი.

7) დაკვირვება და სიგნალების ხარისხი

SLI/SLO დომენების მიხედვით: წვდომა/ლატენტობა/ბიზნეს ოპერაციების წარმატება, მონაცემთა სიახლე.
Alerta: burn-rate ორ ფანჯარაში, quorum, dedup/rate-limit, runbook და მფლობელი.
Logs/metrics/traces უკავშირდება trace _ id; არხები გრაფიკებიდან ლოგებამდე.
სტატუსის გვერდი: შაბლონები, აფდიტების სიხშირე, პუბლიკაციების აუდიტი.

8) წვდომა, საიდუმლოებები, კრიპტო

საიდუმლოების შენახვა (KMS/Vault), როტაცია, საიდუმლო აკრძალვა რეპოში.
JIT/JEA: ოპერაციის/ცვლის დროს უფლებების გაცემა.
mTLS/OIDC მომსახურებებს შორის; სურათების ხელმოწერა/SBOM.
აუდიტი: უცვლელი ჟურნალები, WORM კრიტიკული ქმედებებისთვის.

9) ინციდენტები, ცვლილებები, მომსახურების ფანჯრები

ინციდენტები: SEV მატრიცა, IC/TL/Comms/Scribe, Apdate შაბლონები, AAR-RCA-CAPA.
ცვლილებები: RFC/CAB, რისკის შეფასება, კანაფები, ქილა.
მომსახურების ფანჯრები: დროის არჩევა, კომუნიკაცია, დამხმარე წესები, საღამო.

10) DataOps ოპერაციული ფენაში

მონაცემთა კონტრაქტები (სქემები, SLA ახალი/სისრულე).
DQ ტესტები თითოეულ ფენაზე (Bronze/Silver/Gold).
ხაზები და კატალოგები; კარანტინი ქორწინებისთვის.
SLO მონაცემები და ალერტები ახალი/დრიფტის მიხედვით.

11) FinOps და ღირებულება

Unit ეკონომიკა: $/1k მოთხოვნა ,/$ წარმატებული გარიგება ,/GiB ლოგოები ,/SLO წერტილი.
კვოტები/ლიმიტები: egress, ლოგიკური მოცულობა, დავალებების ხანგრძლივობა.
ოპტიმიზაცია: წვეულებები/ქეში/მატერიალიზაცია/არქივები (ცხელი-warm-cold).
მოხსენებები: იაფი „ძვირადღირებული“ სერვისები/მოთხოვნები, გადატვირთვის ალერტები.

12) ინტერფეისები: ChatOps/Portals/API

პლატფორმის პორტალი: სერვისების კატალოგი, ღილაკები „გამომცხვარი/გამოტოვება“, SLO სტატუსი, ფანჯრების სლოტი, პოლიტიკა.
ChatOps: `/deploy`, `/handover start`, `/mw create`, `/status update` — с аудитом и evidence.
API: ITSM/HR/ბილინგთან/პროვაიდერთან ინტეგრაციისთვის.

13) პასუხისმგებლობის მოდელი (RACI)

Platform/SRE: საკონტროლო თვითმფრინავი, პოლიტიკა, დაკვირვება, როტაცია.
Product/Dev: SLO სერვისები, გამოშვებები, ფლეიბუკები.
უსაფრთხოება: საიდუმლოებები, დაუცველობა, IR.
Data/Analytics: DataOps, SLA სიახლე/ხარისხი.
კომპლექსი/ლეგალი: მარეგულირებელი, დროებითი შენახვა.
მხარდაჭერა/კომსი: სტატუსის გვერდი, კლიენტის შეტყობინებები.

14) ოპერაციული ფენის სიმწიფის მეტრიკა

SLO coverage: სერვისების% გარკვეული SLI/SLO და burn-rate.
Alert hygiene: actionable ≥80%, FP ≤5%, alerts/on-call-hour (p95).
DORA: eplois, lead time, MTTR, change-failure-rate სიხშირე.
Change Governance: RFC- ში ცვლილებების%, „on time“ ფანჯრების%, გამოტოვება.
უსაფრთხოება: საიდუმლოებების/სერთიფიკატების ბრუნვის საშუალო დრო, დაუცველების დახურვა.
FinOps: $/ერთეული და QoQ ეკონომიკის%.
Docs: runbook/SOP საფარი, სიახლე (90 დღე).

15) ჩეკის სია „მინიმალური სიცოცხლისუნარიანი ოპერაციული ფენა (MVP)“

• კატალოგის სერვისი/CMDB მფლობელებთან, SLO- სთან, დამოკიდებულებებთან და დაშბორდებთან.
• CI/CD + GitOps, არტეფაქტების ხელმოწერა, პროგრესული გამოშვებები, ავტო-გამოტოვება.
• ერთობლივი ტელემეტრია (logs/metrics/traces) trace _ id და SLO ალერტებით (ორმაგი ფანჯრები, კვორუმი).
• Policy-as-Code: წვდომა, ალერტები, რეტენციები, change-gates.
• საიდუმლოების საცავი, JIT/JEA, mTLS/SSO, უცვლელი აუდიტი.
• ITSM/ინციდენტები: SEV მატრიცა, ფლეიბუკი, სტატუსის გვერდი, აფდეიტის შაბლონები.
• მომსახურების ფანჯრები: კალენდარი, RFC შაბლონები, backout გეგმები, evidence.
• FinOps: ხარჯების ხილვადობა, კვოტები/ლიმიტები, მოხსენებები.
• დოკუმენტაცია (Docs-as-Code), SOP/Runbook შაბლონები, პროდუქტების მზადყოფნის სია.

16) ანტი შაბლონები

„პლატფორმა = სკრიპტების ნაკრები“ კონტროლის სიბრტყისა და პოლიტიკოსის გარეშე.
მონიტორინგი „ყველაფრისგან“ არის ალერტის ზვავი, ალერტული fatigue.
სახელმძღვანელო წინსვლის ცვლილებები GitOps/აუდიტის გარეშე.
საიდუმლოებები ცვლადი გარემოში შენახვისა და როტაციის გარეშე.
SLO- ს ნაკლებობა: კამათობთ გრძნობებზე და არა ხარისხის მიზნებზე.
მესაკუთრეთა მიმოფანტული კატალოგები/ცხრილები - დაკარგული ესკალაცია.
High-risk- ის ცვლილების გეგმა არ არსებობს.
ლოგოები სტრუქტურის/კორელაციის გარეშე არის გრძელი გამოძიება.

17) მინი შაბლონები

17. 1 მომსახურების ბარათი (კატალოგი)

Service: checkout-api
Owner: @team-checkout
SLO: availability 99. 9% (28d), p95 latency ≤ 250 ms
Dependencies: payments-api, auth, redis, psp-a
Dashboards: SLO, errors, latency, capacity
Runbooks: rb://checkout/5xx, rb://checkout/rollout
Data: PII masked; retention 30d logs, 365d audit
Change gates: canary 1/5/25%, auto-rollback on burn-rate breach

17. 2 ალერტის პოლიტიკა (იდეა)

yaml id: checkout-latency-burn type: burn_rate sli: http_latency_p99 windows:
short: {duration: 1h, threshold: 5%}
long: {duration: 6h, threshold: 2%}
quorum: [ "synthetic:eu,us", "rum:checkout" ]
owner: team-checkout runbook: rb://checkout/latency routing: page:oncall-checkout controls: {dedup_key: "svc=checkout,region={{region}}", rate_limit: "1/15m"}

17. 3 კარიბჭე (ფსევდო)

yaml allow_deploy_when:
tests: passed signatures: valid active_sev: none_of [SEV-0, SEV-1]
slo_guardrails: green_last_30m rollback_plan: present

18) განხორციელების გზის რუკა (8-12 კვირა)

1. ნვე. 1-2: სერვისების ინვენტარიზაცია/დირექტორია/CMDB; ძირითადი SLI/SLO და დაშბორდები.
2. ნვე. 3-4: GitOps + პროგრესული გამოშვებები; Policy-as-Code (ალერტები/რეტენციები).
3. ნვე. 5-6: ერთი ტელემეტრია და სტატუსის გვერდი; ბურნის კედელი კვორუმით; runbook საფარი.
4. ნვე. 7-8: საიდუმლოებები/JIT, უცვლელი აუდიტი; RFC/მომსახურების ფანჯრები.
5. ნვე. 9-10: FinOps ანგარიშები, კვოტები/ლიმიტები; ლოგოების და შენახვის ოპტიმიზაცია.
6. ნვე. 11-12: ინციდენტების სიმულაცია/DR; სიმწიფის მეტრიკა; უწყვეტი გაუმჯობესების გეგმა.

19) შედეგი

ოპერაციული ფენის არქიტექტურა არის საკონტროლო თვითმფრინავი, პლუს სტანდარტიზებული პრაქტიკა, რომელიც ექსპლუატაციას გადააქცევს განმეორებით, გაზომილ და უსაფრთხო პროცესად. სერვისული კატალოგი, GitOps, ტელემეტრია, პოლიტიკოსები, უსაფრთხო წვდომა და კონტროლირებადი ცვლილებები იძლევა სტაბილურ გამოშვებებს, სწრაფ აღდგენას და გამჭვირვალე ღირებულებას - ანუ ოპერაციულ პროგნოზირებას ბიზნესისთვის.