ქვიშის ყუთები და სატესტო გარემო

1) რატომ გვჭირდება გამოყოფილი კონტურები?

• სწრაფად შეამოწმეთ ჰიპოთეზები და ინტეგრაცია წარმოების რისკის გარეშე;
• დააჩქარეთ ფიტბეკის ციკლი (PR) გადახედეთ ბმულს წუთში);
• შეცდომების და ინციდენტების უსაფრთხო ასლის რეპროდუცირება;
• შეასრულეთ ხელშეკრულების, ინტეგრაციის, დატვირთვისა და ქაოსის ტესტები;
• გუნდების მომზადება და პარტნიორების დაქირავება „სათამაშო“ საიტზე.

ძირითადი პრინციპები: იზოლაცია, კონფიგურაციის პარიტეტი, ტესტების დეტერმინიზმი, მონაცემთა უსაფრთხოება, ნაგულისხმევი დაკვირვება.

2) მედიის იერარქია და მათი დანიშვნა

ადგილობრივი (Dev) ადგილობრივი განვითარებაა: Docker Compose/Testcontainers, მსუბუქი დონის პროვაიდერების სიმულატორები.
Sandbox არის სტენდი გარე ინტეგრაციისთვის (PSP, KYC, თამაშების აგრეგატორები) ყალბი მონაცემებით და რეალური პროტოკოლებით.
QA/Test - ინტეგრაციის და e2e ტესტები, მონაცემთა სტაბილური ფიქსაცია, რეგრესიები.
Stage/Pre-Breaking არის კონტური, რომელიც მაქსიმალურად ახლოსაა წარმოებასთან (კონფიგურაცია/ლიმიტები/ტოპოლოგია).
Ephemeral Preview - გარშემორტყმული „PR- ზე“ (ცხოვრობს საათობით/დღეებში), ავტონომიური რესურსები და URL, მანქანების დანგრევა მერჯე/კლოსის შემდეგ.

Parity წესი: „პარამეტრები, პოლიტიკა და ინფრასტრუქტურული დამოკიდებულებები Test/Stage - ში“, განსხვავებები - მხოლოდ საიდუმლოებებში და ლიმიტებში.

3) ქვიშის ყუთების ტიპები

1. პროვაიდერების ქვიშის ყუთები: გარე PSP/KYC/თამაშები გთავაზობთ test endpoints; ჩვენ ვამატებთ სიმულატორების ფენას იშვიათი და მცდარი შემთხვევების მოდელირებისთვის (timeouts, 5xx, არასტაბილური ხელმოწერები).
2. ფუნქციური ქვიშის ყუთები: აფეთქების ღუმელის სერვისების ავტონომიური ინსტანციები (გადახდები, პრემიები, მოსაკრებლები) + ფიქსაცია.
3. ტრენინგი/დემო ქვიშის ყუთები: API- ს „ვიტრინა“ პარტნიორებისთვის DevPortal- ით, კლავიშებით, კვოტებით და საბაზო ლიმიტით.

4) კონტრაქტები, სიმულატორები და ხიდები

Contract-testing (Pact/Buf): მომხმარებელი/პროვაიდერი კოორდინაციას უწევს სქემებს; შეუთავსებელი ცვლილებები იბლოკება CI- ში.
პროვაიდერების სიმულატორები: რეპროდუცირებენ edge შემთხვევებს (ორმაგი კოლბეკი, საათის დრიფტი, HMAC ხელმოწერა ვადაგადაცილებული timestamp- ით).
მოვლენების ფიქსატორები (Kafka/NATS): შემთხვევების ბიბლიოთეკა 'payment. authorized`, `kyc. verified`, `game. round. settled`.
Fault injection: კონტროლირებადი შეფერხებები, drop-rate, out-of-order შეტყობინებები.

X-Timestamp: 1730812800
X-Signature: sha256=hex(hmac_sha256(secret, body + timestamp))

5) ტესტის მონაცემები, GDPR/PCI და ანონიმიზაცია

არასოდეს ვიყენებთ რეალურ PII/PAN წარმოების მიღმა.
ანონიმიზაცია: სინთეზის წარმოქმნა + მგრძნობიარე ველების ტოქსიკაცია; თეთრი სიები მხოლოდ სადემონსტრაციო ანგარიშებისთვის.
მონაცემთა ფაქტები: მომხმარებელთა/გარიგების/სესიების ქარხნები პროგნოზირებადი ID და სტატუსებით.
Deterministic seeds: იგივე ფიქსაცია ტესტებსა და მედიას შორის.
Retenshny პოლიტიკა: მანქანების გაწმენდა გარემოთი და ტესტის მონაცემთა ბაზებით.

6) საიდუმლოებები და წვდომა

ცალკეული საიდუმლოებები ოთხშაბათს; დროებითი კრედიტები და შეზღუდული როლები.
KMS/HSM და როტაცია; Git- ის საიდუმლოებები გამორიცხულია.
RBAC/ABAC QA/Stage; წვდომის აუდიტი, break-glass მხოლოდ კოორდინაციის გზით.

7) Observability არასწორი ოთხშაბათს

ლოგები - სტრუქტურირებული, PII- ის გარეშე, შენიღბვით;

latency p50/p95/p99, error-rate, throughput, DLQ, retrai;

ტრეისი (OTel): 'trace _ id' - ის მეშვეობით შეყვანის მოთხოვნიდან სიმულატორამდე;

Dashboards as Code - დაშბორდები და ალერტები ვერსირებულია სამსახურის გვერდით.

8) Ephemer- ის წინასწარი გარემო (per-PR)

• PR-CI აგროვებს გამოსახულებას, წარმოქმნის მიგრაციას, ამაღლებს namespace 'pr- ' Kubernetes- ში;
• გაიცემა წინასწარი URL და ტესტის მომხმარებლების ნიშნები;
• ტრეისი/მეტრიკა; როდესაც PR დახურულია, გარემო ამოღებულია.

yaml apiVersion: v1 kind: Namespace metadata:
name: pr-4821 labels:
env: preview owner: team-payments

9) ადგილობრივი განვითარება: Compose/Testcontainers

yaml version: "3. 9"
services:
api:
build:.
environment:
- DB_URL=postgres://postgres:postgres@db:5432/app? sslmode=disable
- KAFKA_BROKER=kafka:9092 ports: ["8080:8080"]
depends_on: [db, kafka]
db:
image: postgres:16 environment: [POSTGRES_PASSWORD=postgres]
ports: ["5432:5432"]
kafka:
image: bitnami/kafka:latest environment:
- KAFKA_ENABLE_KRAFT=yes
- KAFKA_CFG_PROCESS_ROLES=controller,broker
- KAFKA_CFG_LISTENERS=PLAINTEXT://:9092,CONTROLLER://:9093
- KAFKA_CFG_CONTROLLER_QUORUM_VOTERS=1@localhost:9093 ports: ["9092:9092"]

ტესტებში დამოკიდებულების ავტომატური შესავსებად - Testcontainers ფიქსატორებით.

10) დატვირთული და სტაბილური ტესტები

დატვირთვის პროფილები: „ტურნირები“, „გადახდის ტალღები“, „მასობრივი იარაღი“.
KPI: RPS, p95/p99, რესურსების ლიმიტები (CPU/memory), TTFB, Time-to-Wallet.
Chaos ინექციები: პროვაიდერების გათიშვა, ლატენტობის ზრდა, ქსელის „flaky“.
Circuit breaker/backoff პოლიტიკა შემოწმებულია Stage- ზე; წარუმატებლობები მიდის DLQ- ში და იძახიან.

11) გამოტოვებისა და რეპლიკის პოლიტიკა

Replay კარიბჭე მოვლენებისთვის DLQ- დან (სახელმძღვანელო/მანქანები რეჟიმები, ღილაკების ფილტრები).
მიგრაციის ბაზები: მკაფიო up/down და dry-run გადახედვა/Stage; დესტრუქციული ცვლილებებისგან დაცვა.

12) ინტეგრაცია DevPortal- თან

ქვიშის ყუთებისა და პროვაიდერების კატალოგი, მინდვრების მოთხოვნები, მოთხოვნის მაგალითები.
Open Preview ღილაკი თითოეულ PR/ფილიალში; SLO/SLA მეტრული ვიჯეტი.
SDK და Postman/Insomnia კოლექციები ხელშეკრულებებიდან.

13) ქვიშის ყუთის პერიმეტრის უსაფრთხოება

WAF + IP-allowlist გარე ქვიშის ყუთებისთვის;

კვოტები და გასაღები ლიმიტები;

ინდივიდუალური დომენები/ქვე-დომენები; არააქტიური გასაღებების ავტომატური მოცილება;

თითოეულ ბილეთზე გამოსახულებებისა და დამოკიდებულების დაუცველების სკანირება.

14) პროცესები: ვინ იყენებს და როგორ

დეველოპერები - ადგილობრივად და წინასწარ, სწრაფი fidback.
QA არის სტაბილური Test/Stage კონტროლირებადი მონაცემებით და სიმულატორებით.
პარტნიორები არიან გარე Sandbox DevPortal- ით, კვოტებითა და მონიტორინგით.
SRE/პლატფორმა - დატვირთვის პროფილები, ქაოსი, SLO შემოწმება.

15) ქვიშის ყუთის გაშვების ჩეკის სია

• კონტრაქტები Registry- ში, სიმულატორები მოიცავს წარმატებებს/შეცდომებს/ტაიმუთებს/გამეორებებს.
• ტესტის მონაცემები სინთეზურია, დეტერმინირებული, PII/PAN გარეშე.
• საიდუმლოებები KMS- სგან, როლები შეზღუდულია, აუდიტი შედის.
• მეტრიკა/ტრეისი/ლოგები ხელმისაწვდომია; ალერტები error-budget და DLQ.
• Ephemeral იზრდება PR- ზე და დანგრეულია.
• დატვირთვის პროფილები და ქაოსის სცენარები აღწერილია კოდით.
• მიგრაციისა და მოვლენების პოლიტიკის შემოწმება ხდება.
• DevPortal აქვეყნებს ჰიდებსა და მოთხოვნების კოლექციებს.

16) გზის განხორციელების რუკა

M0-M1 (MVP): ადგილობრივი გარემოცვები (კომპოზიცია), ძირითადი PSP/KYC სიმულატორი, CI- ს კონტრაქტის ტესტები, K8s- ში ნეიმსპასის გადახედვა.
M2-M3: ფიქსატორების კატალოგები, Dashboards as Code, DLQ + ხელის ჭავლი, დატვირთვის პროფილები.
M4-M6: სრულფასოვანი გარე Sandbox კლავიშებით/კვოტებით, ქაოსის ინფრასტრუქტურა, SDK ავტოგენი, მიგრაციის პოლიტიკა „ორი ვერსია პარალელურად“.
M6 +: გეო-განაწილებული სცენა failover- ით, SLA- ს გასწვრივ პროვაიდერების ჭკვიანი მარშრუტიზაცია ტესტებში, ავტომატიზირებული სასწავლო სცენარები DevPortal- ში.

17) გარემოს სიმწიფის მოდელი (მოკლედ)

1. ძირითადი - არის Test/Stage, სახელმძღვანელო მონაცემები, სუსტი იზოლაცია.
2. მოწინავე - სიმულატორები, კონტრაქტის ტესტები, დაკვირვება, ნაწილობრივი გადახედვა.
3. ექსპერტი - per-PR გარემო, ქაოსი/დატვირთვა, როგორც კოდი, DevPortal, მკაცრი უსაფრთხოება და სრული ავტომატიზაცია.

მოკლე დასკვნა

სწორად შექმნილი ქვიშის ყუთები და სატესტო გარემო არის „საჰაერო ჩანთა“ და მიწოდების „ამაჩქარებელი“. იზოლაცია, პარიტეტული წარმოება, პროვაიდერების სიმულატორები, დეტერმინისტული ტესტის მონაცემები, ძლიერი დაკვირვება და საშუალებების ავტომატიზაცია იძლევა სწრაფ და საიმედო ციკლს „კოდი - შემოწმება - გამოშვება“, ამცირებს რეგრესიების რისკს და ამარტივებს პლატფორმის მასშტაბებს.