კონფიგურაციის ვერსიების კონტროლი

1) რატომ კონფიგურაცია

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

2) კონფიგურაციის ტაქსონომია

ინფრასტრუქტურა (IaC): მტევანი, ქსელები, LB, BD, რიგები.
მომსახურება: განაცხადის პარამეტრები, რესურსები, ლიმიტები, ტაიმაუტები, რეტრაები.
პროდუქტის/ბიზნესის ლოგიკა: ტარიფები, AB ექსპერიმენტები, შინაარსის წესები.
მონაცემები/DataOps: სქემების კონტრაქტები, SLA სიახლე, ტრანსფორმაცია.
უსაფრთხოება: წვდომის პოლიტიკოსები, როლები, გასაღებები/სერთიფიკატები (თავად საიდუმლოებები - რეპოს გარეთ).
დაკვირვება: SLI/SLO, ალერტები, დაშბორდები.

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

3) ვერსიის მართვის პრინციპები

1. GitOps: ჭეშმარიტების ერთადერთი წყარო არის საცავი; ცვლილებები PR და ავტომატური რაციონის საშუალებით.
2. დეკლარაცია: სამიზნე მდგომარეობის აღწერა და არა ნაბიჯების სკრიპტები.
3. არტეფაქტების იმიტაცია: კონფისკაცია - ცალსახად მატერიალიზებული სნაიპშოტი.
4. სქემები და შესაბამისობა: JSON/YAML-schema, მკაცრი ტიპები, სავალდებულო ველები.
5. გარემო, როგორც კოდი: 'env' - საქაღალდეები/ოვერლეა (dev/stage/with), განსხვავებები მინიმალურია და აშკარაა.
6. Idempotence და გამოტოვება: კონფიგურაციის ნებისმიერი გამოშვება შექცევადია (revert/rollback).
7. აუდიტი და ტრეკირება: ავტორი, მიზეზი, პიკეტი/RFC, ცვლილებების ხელმოწერა.

4) ვერსიის სტრატეგია

SemVer კონფიგურაციის პაკეტებისთვის ('MAJOR. MINOR. PATCH`):

MAJOR - სქემების/პოლიტიკის შეუთავსებელი ცვლილებები.
MINOR - ახალი ველები/წესები, საპირისპირო თავსებადობა.
PATCH - მნიშვნელობების კორექტირება სქემების შეცვლის გარეშე.
Tag გამოშვებები და release notes: რაც შეიცვალა, თუ როგორ უნდა გამოტოვოთ, საკონტროლო წერტილები.
Pinning/lock ფაილები: ჩაწერეთ დამოკიდებულების ვერსიები (მოდულები, ჩარტები).
Matrix ვერსიები: პროგრამის X არტეფაქტი თავსებადია Y კონფიგურაციასთან (მატრიცა მომსახურების კატალოგში).

5) საცავის ორგანიზაცია


config-repo/
policies/     # общие политики (RBAC, SLO, алерты)
services/
checkout/
schema/    # JSON/YAML схемы конфигов base/     # дефолтные значения overlays/
dev/
stage/
prod/
data-contracts/  # схемы данных, SLA свежести releases/     # теги, changelog, артефакты валидации tools/      # линтеры, генераторы, тесты

ფილიალი: trunk-based (main) + მოკლე feature ფილიალები. Merge - მხოლოდ PR- ის საშუალებით სავალდებულო CI.

6) ვალიდაცია და ტესტირება

სქემა: თითოეული ცვლილება გადის სქემის შემოწმებას (required, enum, ranges).
სტატიკური საბრძოლო მასალები: ფორმატი, გასაღებები, დუბლირება, აკრძალული ველები.
თავსებადობის ტესტები: სერვისის/გრაფიკის კონფისკაცია + ვერსია იზრდება ქვიშის ყუთში.
საკონტროლო ჩხირები: dry-run პროგრამები, „what-if“ სამიზნე მდგომარეობა.
პოლიტიკოსები-as-code: დაშვების წესები (Rego/CEL) - ვინ და რა შეიძლება შეიცვალოს.

7) კონფიგურაციის გათიშვა და გამოტოვება

Progressive delivery: კანარი 1% - 5% - 25% SLO გარდერობებით.
Gate deploy: არ არსებობს აქტიური SEV-1, მწვანე ალერტები, ხელმოწერები რეალურია, დაბრუნება მზად არის.
გამოტოვება: 'revert tag vX. Y.Z 'ან წინა snapshot- ზე გადასვლა; უკაბელო ბრძანებები დოკუმენტირებულია runbook- ში.
გამოშვების მენიუ: კონფიგურაციის ვერსია ქვეყნდება მეტრიკებში/ლოგოებში, რათა სწრაფად დაუკავშირდეს ინციდენტებს.

8) დინამიური და დისტანციური კონფიგურაცია

Remote config/feature flags: ჩვენ ვცვლით პარამეტრებს გადატვირთვის გარეშე; ყველა დროშა ასევე არის GitOps- ის ქვეშ.
საზღვრები: რომელი პარამეტრების შეცვლა შესაძლებელია დინამიურად (თეთრი სიების სია).
კეში და თანმიმდევრულობა: TTL, ვერსიები, კომპლექტების ატომური ჩანაცვლება (ორფაზიანი გამოცემა).
უსაფრთხო მოაჯირები: runtime ცვლილებების შეზღუდვები და დიაპაზონი, rollback მანქანები SLO- ს გასვლისას.

9) საიდუმლოებები და მგრძნობიარე მონაცემები

არასოდეს შევინახოთ საიდუმლოებები რეპოში. კონფიგურაციებში - მხოლოდ ბმულები/მოთამაშეები.
კონფიგურაციის ფაილების დაშიფვრა საჭიროების შემთხვევაში: საიდუმლოების/გასაღებების მენეჯერთან ინტეგრაცია.
როტაცია და JIT: ხელმისაწვდომობა გაიცემა ოპერაციების ხანგრძლივობისთვის; მოქმედების კვალი უცვლელია.
საველე შენიღბვა: ვალდებულება კრძალავს PII/საიდუმლოებების კონფისკაციას.

10) გარემოს მართვა

Base + overlays: განსხვავებები dev/stage/black- ს შორის მინიმალურია და გამჭვირვალეა.
Promotion არტეფაქტების მიხედვით: იგივე snapshot, რომელიც გაიარა stage, მოძრაობს country.
დროებითი ფანჯრები: კონფიგურაციის ცვლილებები არ ხდება მოვალეობის შეცვლის დროს; risk-high- ისთვის - RFC და მომსახურების ფანჯარა.

11) დრიფტის აღმოჩენა და აღმოფხვრა

მაკონტროლებელი ადარებს მიზნობრივ მდგომარეობას ფაქტობრივ და მოხსენებას.
Drift-alerty: Page მხოლოდ კრიტიკული განსხვავებებით; დანარჩენი Ticket.
მანქანის რემედიაცია: ნებართვისას - სამიზნე მდგომარეობის დაბრუნება.
სახელმძღვანელო რედაქტირების აუდიტი: ნებისმიერი „kubectl edit/ssh“ - პროცესის ინციდენტი და CAPA.

12) კონფიგურაციისა და საკუთრების კატალოგი

მომსახურების კატალოგი: მფლობელი, SLO, დაკავშირებული პოლიტიკა, სქემები, ვერსიები, თავსებადობა.
RACI: ვინ გვთავაზობს ვინ იძიებს, ვინ იწონებს; CAB მაღალი რანგისთვის.
გამჭვირვალობა: თითოეულ ჩანაწერს აქვს ვერსიების ისტორია და ბმულები PR/ticets/AAR.

13) სიმწიფის მეტრიკა

Coverage: სერვისების %/პოლიტიკოსი GitOps- ის ქვეშ (მიზანი 95%).
Lead time კონფისკაციის ცვლილებები: საშუალო PR- დან PR- მდე.
Change failure rate: ჩამორთმევის გამოშვების წილი დაბრუნება/ინციდენტი.
დრიფტი: განსხვავებების რაოდენობა/კვირა და აღმოფხვრის დრო.
Rollback time: საშუალო აღდგენა წინა ვერსიამდე.
Audit completeness: ცვლილებების წილი სრული ხედვით (მოვალეობები, დერი-რუნი, მიმოხილვები).

14) ჩეკის ფურცლები

კონფიგურაციის შეცვლამდე

არსებობს ტიკეტი/RFC და ცვლილების მფლობელი.
გაიარა სქემებისა და ლინტერების შესაბამისობა.
არსებობს runbook- ის დაბრუნების გეგმა.
კარიბჭე: ტესტები მწვანეა, ხელმოწერები რეალურია, არ არსებობს აქტიური SEV-1.
მაღალი რანგისთვის - დაინიშნა მომსახურების ფანჯარა.

განქორწინების დროს

კანარიკა და SLO გარდერობები აქტიურია.
ქვეყნდება ვერსიის სურათები.
არხზე არის ექო შეტყობინებები; ალერტული ხმაური თრგუნავს MW- ს წესებს.

შემდეგ

Observation window გაიარა, SLO მწვანე.
შედეგები და evidence (გრაფიკა ადრე/შემდეგ, dry-run მოხსენებები) თან ერთვის თიკეტს.
განახლებულია სქემები/დოკუმენტაცია საჭიროების შემთხვევაში.

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

15. 1 კონფიგურაციის სქემა (YAML-schema, ფრაგმენტი)

yaml type: object required: [service, timeouts, retries]
properties:
service: { type: string, pattern: "^[a-z0-9-]+$" }
timeouts:
type: object properties:
connect_ms: { type: integer, minimum: 50, maximum: 5000 }
request_ms: { type: integer, minimum: 100, maximum: 20000 }
retries:
type: object properties:
attempts: { type: integer, minimum: 0, maximum: 10 }
backoff_ms: { type: integer, minimum: 0, maximum: 5000 }

15. 2 ძირითადი კონფისკაცია + verelles

yaml services/checkout/base/config.yaml service: checkout timeouts: { connect_ms: 200, request_ms: 1500 }
retries: { attempts: 2, backoff_ms: 200 }
limits:  { rps: 500 }
features:
degrade_search: false psp_a_weight: 80 psp_b_weight: 20

yaml services/checkout/overlays/prod/config.yaml limits:  { rps: 1200 }
features:
psp_a_weight: 70 psp_b_weight: 30

15. 3 დაშვების პოლიტიკა (იდეა)

yaml allow_change_when:
tests: passed schema_validation: passed active_incidents: none_of [SEV-0, SEV-1]
rollback_plan: present signed_by: ["owner:team-checkout","platform-sre"]

15. 4 ჩამორთმევის ბარათი


Release: checkout-config v2.3.1
Scope: prod EU
Changes: psp_b_weight 20→30, request_ms 1500→1300
Risk: Medium (маршрутизация платежей)
Canary: 1%→5%→25% (30/30/30 мин), guardrails: success_ratio, p95
Rollback: tag v2.3.0

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

გაყიდვების ცვლილებები GitOps- ის გავლით („სწრაფად გადატრიალდა“).
საიდუმლოებები/PII კონფიგურაციის საცავში.
სქემების არარსებობა და სტატიკური შემოწმება.
გარემოსდაცვითი ძლიერი შეუსაბამობა (ბაზი).
„ცოცხალი“ ფიგურების დროშები ვერსიებისა და ისტორიის გარეშე.
სერვერებზე დრიფტისა და ხელით რედაქტირების უგულებელყოფა.
ჭდეები release notes- ის გარეშე და დაბრუნების გეგმა.

17) განხორციელების გზის რუკა (4-6 კვირა)

1. ნვე. 1: ჩამორთმევის ინვენტარი; ცალკეული კატალოგები, სქემები ტოპ 10 მომსახურებისთვის.
2. ნვე. 2: ჩართეთ linters/validation და dry-run CI- ში; მენჯის აკრძალვა მწვანე ჩეკების გარეშე.
3. ნვე. 3: GitOps scate + canarey; ტელემეტრიული ვერსიების რედაქტირება.
4. ნვე. 4: დაშვების პოლიტიკის შემოღება (პოლიცია-as-code) და rollback შაბლონები; ალერტები დრიფტისთვის.
5. ნვე. 5-6: მომსახურების 90% დაფარვა; შეამცირეთ ენების განსხვავებები overlays- ზე; დაამატეთ სიმწიფის მეტრიკა და ყოველკვირეული კონფისკაციის ცვლილებები.

18) შედეგი

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

კონფიგურაციის ვერსიების კონტროლი

კონფიგურაციის შეცვლამდე

განქორწინების დროს

შემდეგ

დაგვიკავშირდით

სწრაფი კავშირი

ვიდეო მალე განახლდება

ჩვენ ახლა ძალიან დაკავებული ვართ პროექტებით