Zero-Downtime განლაგება

(განყოფილება: არქიტექტურა და ოქმები)

1) რა არის Zero-Downtime და რატომ არის ეს საჭირო

• ნულოვანი მარტივი მომხმარებლებისთვის და ინტეგრაციისთვის.
• პროგნოზირებადი გამოშვებები, სწრაფი დაბრუნება და კონტროლირებადი რისკი.
• SLO/SLI (ლატენტობა, შეცდომები, წვდომა) შენარჩუნება შეთანხმებების საზღვრებში.

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

2) Zero-Downtime- ის ძირითადი პრინციპები

1. ვერსიების თავსებადობა: ახალი და ძველი ვერსიები ერთდროულად სწორად უნდა დაამუშავონ ტრაფიკი და მონაცემები.
2. ოპერაციების იდემპოტენტურობა: განმეორებითი დამუშავება არ უნდა დაარღვიოს მდგომარეობა.
3. მოხდენილი დასრულება (graceful shutdown) და ნაერთების დრენაჟი.
4. ჯანმრთელობის ეტაპობრივი შემოწმება: რეგულირება/მკურნალობა, ჯანმრთელობის ენდოპოინები.
5. გამოტოვება, როგორც მოქალაქის პირველი კლასი: rollback უფრო მარტივი და სწრაფია, ვიდრე hotfix.
6. დაკვირვება by design: გამოშვების ეტიკეტები, ერთიანი დაშბორდები, SLO ალერტები.
7. ავტომატიზაცია: გამოშვების და გამოტოვების სკრიპტები - კოდი და არა სახელმძღვანელო ინსტრუქციები.

3) ადგილზე მიტანის ნიმუშები

3. 1 Rolling Update

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

უპირატესობები: ეკონომიურად ინფრასტრუქტურაში, უბრალოდ k8s/ASG- ში.
უარყოფითი: გარკვეული პერიოდის განმავლობაში, მტევანი ერთდროულად მუშაობს ორი ვერსიით (ვერსიის ციკლი).

3. 2 Blue-Green

ორი სრული გასროლა: აქტიური (ცისფერი) და კანდიდატი (მწვანე). ტრაფიკის გადართვა - ატომური ფრენა.

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

3. 3 Canary/პროგრესული Rollout

ჩვენ ვაძლევთ ტრეფიკის მცირე ნაწილს (1-5-10-25-50-100%) ახალი ვერსიით, მეტრიანი კარიბჭეებით.

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

3. 4 Shadow traffic / Dark launch

ჩვენ ვიწყებთ რეალურ მოთხოვნებს ახალ ვერსიაში (მომხმარებლისთვის უპასუხოდ) ან დავიწყებთ მრიცხველების შეგროვებას.

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

4) ტრაფიკის და ნაერთების მართვა

4. 1 Readiness/Liveness

Liveness ეუბნება ორკესტრს „გადატვირთეთ“.
Readiness - „ნუ გამოგიგზავნით ტრაფიკს, მე ჯერ არ ვარ მზად“.
თქვენ არ შეგიძლიათ გაათავისუფლოთ სწორი რეალობის ლოგიკისა და ტაიმაუტის გარეშე.

4. 2 კავშირების დრენაჟი

• შეწყვიტეთ ახალი ნაერთების მიღება
• ველოდებით აქტიურობის დასრულებას
• შეაჩერეთ „ჩამოკიდებული“ ტაიმუთში.

4. 3 Sticky სესიები და L7 დონის მარშრუტიზაცია

Sticky სასარგებლოა stateful სცენარებისთვის, მაგრამ ართულებს დატვირთვის ბალანსს.
L7 წესები (გზაზე, სათაურით, ქუქი-ფაილით, API ვერსიით) მოსახერხებელია ჟანრული/რინგისთვის.

4. 4 ხანგრძლივი კავშირები

WebSocket/gRPC Streaming: განახლებამდე ჩართეთ drain mode + GOAWAY სიგნალი.
დაგეგმეთ windows, რომ გადალახოთ ნაკადები და მომხმარებლების ზურგჩანთები.

5) მონაცემთა თავსებადობა და BD მიგრაცია

5. 1 Expand-Migrate-Contract

1. Expand: დაამატეთ ახალი სვეტები/ინდექსები/ცხრილები ძველი ვერსიის დაშლის გარეშე.
2. Migrate: ჩვენ გადავცემთ მონაცემებს ფონის და იდემპოტენტურად (ბატები, ჩეკპოინები).
3. Contract: ამოიღეთ ძველი მხოლოდ სტაბილიზაციის შემდეგ.

5. 2 პრაქტიკა

თავიდან აიცილეთ ექსკლუზიური DDL ჩანაწერები გამოშვების ფანჯარაში.
გააფორმეთ API/ღონისძიებების კონტრაქტები (schema registry, CDC).
მძიმე მიგრაციისთვის - ონლაინ ინსტრუმენტები, შენიშვნები, ეტაპობრივი გადართვა.
ორმაგი წრიული ჩაწერა (ორმაგი ჩაწერა) მხოლოდ დედუპლიკაციით და იდემპოტენტური მომხმარებლებით.
Outbox/Inbox საიმედო რიგების ინტეგრაციისთვის.

6) კაში, სესიები და ფონის დავალებები

სესიები და ქეში - გარეგანი (Redis/Memcached) ისე, რომ ვერსიები ცვალებადია.
თბება ქეში/ჯიტებში/ტემპის ინდექსებზე აუზში ჩართვამდე.
გაიზიარეთ ფონის რიგები ვერსიით ან გამოიყენეთ ლიდერობა რბოლების თავიდან ასაცილებლად.

7) SLO დაკვირვება და კარიბჭე

Golden signals: ლატენტობა p95/p99, error rate, RPS, saturation, რიგის ლაქი.
ბიზნეს SLA: ავტორიზაცია, კონვერტაცია, წარმატებული გადახდები, ძაბვის ნაბიჯებზე უარის თქმა.
კარიბჭეები: rollout პროგრესირებს მხოლოდ იმ შემთხვევაში, თუ საკანი - ბაზელინი + დეგრადაციის ბარიერები, და error budget არ იწვის.

8) უსაფრთხო დასრულება და დაბრუნება

გამოტოვება არის იგივე pline, მხოლოდ საპირისპირო მიმართულებით: ფიქსირებული ბრძანებები, არა „სახელმძღვანელო კრაფტი“.
Blue-green- ისთვის - flip back; ანარისთვის - წონის დაკლება 0% ან წინა სტაბილური ნაბიჯი.
მონაცემები: კომპენსაციის გარიგებები, ხელახალი დამუშავება, მოვლენების დედუპლიკაცია.

9) Zero-Downtime ჩეკის ფურცლები

გამოსვლამდე

• შეგროვდა ერთი ხელმოწერილი არტეფაქტი, SBOM და დამოკიდებულების შემოწმება.
• Readiness/liveness განხორციელდა და შემოწმდა.
• მიგრაციის გეგმა ექსპანსიის რეჟიმში, შექცევადობა დადასტურებულია.
• დაშბორდები და ალერტები მზად არიან ახალი ვერსიისთვის, გამოშვების ეტიკეტები პროკინუტია.
• გამოტოვება შემოწმებულია staging/pre-mare.

გამოშვების დროს

• კავშირების დრენაჟი ჩართულია, ტაიმაუტები ადეკვატურია.
• ტრეფიკი თანდათანობით ითარგმნება (canary/ring) ან flip (blue-green).
• მეტრიკა შედარებულია ბასელინთან, კარიბჭეების ბარიერები დაცულია.

გამოსვლის შემდეგ

• N საათის შემდგომი მონიტორინგი, ინციდენტები არ არის.
• დასრულდა კონტრაქტის მიგრაცია, ამოიღეს დროებითი დროშები/მარშრუტები.
• რეტროსპექტივა, ფლეიბუკების განახლება.

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

Recreate deple დრენაჟის და დასვენების გარეშე - მოთხოვნის ხარვეზები.
მოუმზადებელი DDL პრემიერ დროში ბლოკირება და ტაიმაუტები.
შეუთავსებელი სქემების ნაზავი სამსახურის ვერსიებს შორის.
იდემპოტენტურობის არარსებობა დამლაგებლებსა და ვორკერებში.
„შეგრძნება“ კარიბჭეების გარეშე და ბასელინთან შედარება.
გრძელი DNS-TTL ცისფერი-მწვანე, რის გამოც flip გრძელდება საათობით.
ადგილობრივი სესიები/ქეში ინსტანციის მეხსიერებაში rolling/canary.

11) განხორციელების სცენარები

11. 1 Kubernetes (rolling + canary)

Deployment с `maxUnavailable=0`, `maxSurge=25%`.
Readiness ელოდება დათბობას (ქეშის ინიციალიზაცია, მინორის მიგრაცია).
სერვისი-mesh/Ingress wighted routing (1-5-10-25-50-100%).
ალერტები: p95, 5xx, რიგის ლაგი, ბიზნეს ძაბრი.

11. 2 ცისფერი მწვანე ღრუბელში

დაბალანსების ორი დასტა: 'blue. example. com` и `green. example. com`.
გაათბეთ მწვანე, smoke/regress, შემდეგ listener/route swap (ან DNS გადართვა დაბალი TTL).
პრობლემების დროს - მყისიერი ფრენის უკან.

11. 3 Stateful მომსახურება

მონაცემთა რეპლიკები + ონლაინ მიგრაცია; ორმაგი კითხვა ვალიდაციით.
ფონის ჯობი გადაეცემა ვერსიის „ხელმძღვანელობას“ ან განცალკევებულ რიგებს.
სესიები/ქეში ინსტანციის გარეთ; სტიკი მხოლოდ დროებით შედის.

12) ფიჩეფლაგები და კლიენტის პროგრამები

ახალი ფიჩები ააქტიურებენ დროშებს (სეგმენტები: თანამშრომლები - ბეტა - ეს ყველაფერი).
მობილური/desctop კლიენტებისთვის გაითვალისწინეთ პროტოკოლის თავსებადობის საზღვრები და ძველი ვერსიების გადარჩენა.

13) პროდუქტიულობა და ღირებულება

Rolling იაფია, მაგრამ ფრთხილად თავსებადობას მოითხოვს.
Blue-Green უფრო ძვირია გამოშვების დროს, მაგრამ მყისიერი დაბრუნება.
კანარი დაბალანსებს რისკებსა და ღირებულებას, მაგრამ მოითხოვს ძლიერ დაკვირვებას.
დაზოგეთ ephemeral-prection და მანქანების გაწმენდის სტენდების საშუალებით.

14) მინიმალური რეფერენდუმი ZDT

1. Build: ერთი არტეფაქტი, ხელმოწერა, SBOM.
2. Test: unit/integration/contract + security.
3. Staging: smoke, დატვირთვა, ექსპორტი მიგრაცია, დაბრუნება.
4. Shadow-canary (კარიბჭეები) ან blue-green flip.
5. Post-deploy: დაკვირვება, contract-cleanup, რეტრო.

15) მოკლე რეზიუმე

Zero-Downtime არის დისციპლინა: თავსებადი ვერსიები + სწორი მარშრუტიზაცია + კონტროლირებადი მიგრაცია + დაკვირვება და სწრაფი დაბრუნება. შეარჩიეთ ნიმუში კონტექსტის ქვეშ (rolling, blue-green, canary), ავტომატიზირებული gates SLO, შეინარჩუნეთ მონაცემები idempotent - და გამოშვებები შეწყვეტს მოვლენას, გადაიქცევა საიმედო რუტინულ პროცესად.