სტაბილურობა არის პროდუქტის პრინციპი და არა შემდგომი მოფიქრება. AiHummer მისდევს
SemVer-ს, იყენებს წინ-უსაფრთხო ბაზის მიგრაციებს ავტომატურად და შეუძლია
თვით-განახლება CDN-იდან — ასე რომ განახლებები რუტინულია და არა სარისკო.
ვერსირება (SemVer)
გამოშვებები მისდევენ სემანტიკურ ვერსირებას. ვერსიას აცხადებს /healthz და
aihummer version, ასე რომ ყოველთვის შეგიძლიათ დაადასტუროთ ზუსტად რა მუშაობს
განახლების წინ და შემდეგ.
მიგრაციები წინ-უსაფრთხო და ავტომატურია
გაშვებისას gateway ავტომატურად იყენებს მოლოდინში მყოფ ბაზის მიგრაციებს. ორი თვისება
ინარჩუნებს ამას უსაფრთხოდ:
წინ-უსაფრთხო. მიგრაციები დაწერილია ისე, რომ უფრო ახალი ბინარი მუშაობს იმ
სქემის წინააღმდეგ, რომელზეც ის ახდენს მიგრაციას, რაც ავტო-გამოყენებასა და მოძრავ
განახლებებს უსაფრთხოს ხდის.
ერთი გამმყენებელი advisory lock-ით. მიგრაციები ეშვება PostgreSQL advisory
lock-ის ქვეშ, ასე რომ როცა რამდენიმე gateway ერთდროულად ეშვება, მხოლოდ ერთი
იყენებს მათ და დანარჩენი ელოდება — არასოდეს ორმაგი მიგრაცია.
[!NOTE]
მიგრაციები ყოველთვის ეშვება მფლობელის ბაზის pool-ზე. შეზღუდული RLS როლი
(AIHUMMER_DB_APP_URL) განკუთვნილია ტრაფიკის მოწოდებისთვის და არა სქემის
ცვლილებებისთვის.
თვით-განახლება CDN-იდან
gateway-ს შეუძლია თავი განაახლოს release CDN-იდან. ქცევა იმართება სამი გარემოს
ცვლადით:
ცვლადი
დანიშნულება
AIHUMMER_AUTO_UPDATE
off | check | apply — გათიშული, მხოლოდ-შეტყობინება, ან ავტო-გამოყენება
AIHUMMER_UPDATE_CHANNEL
სათვალყურო გამოშვების არხი (მაგ. stable / alfa / beta / dev)
AIHUMMER_DOWNLOAD_BASE_URL
ბაზისური URL, საიდანაც განახლება იწევა
განახლებები აღმოჩენილია არხის latest.json-ით CDN-ზე. განახლებების ხელითაც მართვა
შეგიძლიათ CLI-ით:
aihummer update --check # report whether a newer version is availableaihummer update # download and apply the update
# gateway.env — notify-only on the stable channelAIHUMMER_AUTO_UPDATE=checkAIHUMMER_UPDATE_CHANNEL=stable
[!TIP]
დაიწყეთ AIHUMMER_AUTO_UPDATE=check-ით ახალი გამოშვებების შესახებ შესატყობინებლად
და გადადით apply-ზე, როცა არხს ენდობით უმეთვალყურეო rollout-ებისთვის.
უმტყუნებო rollout-ები
AiHummer აგებულია იმისთვის, რომ განახლდეს გათიშვის გარეშე:
გაუშვით 2+ gateway proxy-ის უკან. გადააბრუნეთ ისინი თითო-თითოდ; მზადყოფნის
ზონდი (/readyz) ინახავს რესტარტირებად კვანძს როტაციის გარეთ, სანამ ის
მსვლელობას არ მოაწვდის.
scheduler ერთ-ლიდერიანია. ფონური დაგეგმვა ირჩევს ერთ ლიდერს PostgreSQL
advisory lock-ით, ასე რომ მრავალი gateway-ის გაშვება არ ადუბლირებს დაგეგმილ
სამუშაოს.
მიწოდება იდემპოტენტურია. გარანტირებული მიწოდების outbox პლუს იდემპოტენტობის
გასაღებები ნიშნავს, რომ პასუხი არასოდეს იგზავნება ორჯერ რესტარტის გასწვრივ, რაც
ფლოტის გადაბრუნებას უსაფრთხოს ხდის.
სტაბილურობა არის პროდუქტის პრინციპი და არა შემდგომი მოფიქრება. AiHummer მისდევს
**SemVer**-ს, იყენებს **წინ-უსაფრთხო ბაზის მიგრაციებს ავტომატურად** და შეუძლია
**თვით-განახლება** CDN-იდან — ასე რომ განახლებები რუტინულია და არა სარისკო.
## ვერსირება (SemVer)
გამოშვებები მისდევენ სემანტიკურ ვერსირებას. ვერსიას აცხადებს `/healthz` და
`aihummer version`, ასე რომ ყოველთვის შეგიძლიათ დაადასტუროთ ზუსტად რა მუშაობს
განახლების წინ და შემდეგ.
## მიგრაციები წინ-უსაფრთხო და ავტომატურია
გაშვებისას gateway ავტომატურად იყენებს მოლოდინში მყოფ ბაზის მიგრაციებს. ორი თვისება
ინარჩუნებს ამას უსაფრთხოდ:
- **წინ-უსაფრთხო.** მიგრაციები დაწერილია ისე, რომ უფრო ახალი ბინარი მუშაობს იმ
სქემის წინააღმდეგ, რომელზეც ის ახდენს მიგრაციას, რაც ავტო-გამოყენებასა და მოძრავ
განახლებებს უსაფრთხოს ხდის.
- **ერთი გამმყენებელი advisory lock-ით.** მიგრაციები ეშვება **PostgreSQL advisory
lock**-ის ქვეშ, ასე რომ როცა რამდენიმე gateway ერთდროულად ეშვება, მხოლოდ ერთი
იყენებს მათ და დანარჩენი ელოდება — არასოდეს ორმაგი მიგრაცია.
> [!NOTE]
> მიგრაციები ყოველთვის ეშვება მფლობელის ბაზის pool-ზე. შეზღუდული RLS როლი
> (`AIHUMMER_DB_APP_URL`) განკუთვნილია ტრაფიკის მოწოდებისთვის და არა სქემის
> ცვლილებებისთვის.
## თვით-განახლება CDN-იდან
gateway-ს შეუძლია თავი განაახლოს release CDN-იდან. ქცევა იმართება სამი გარემოს
ცვლადით:
| ცვლადი | დანიშნულება |
|---|---|
| `AIHUMMER_AUTO_UPDATE` | `off` \| `check` \| `apply` — გათიშული, მხოლოდ-შეტყობინება, ან ავტო-გამოყენება |
| `AIHUMMER_UPDATE_CHANNEL` | სათვალყურო გამოშვების არხი (მაგ. stable / alfa / beta / dev) |
| `AIHUMMER_DOWNLOAD_BASE_URL` | ბაზისური URL, საიდანაც განახლება იწევა |
განახლებები აღმოჩენილია არხის `latest.json`-ით CDN-ზე. განახლებების ხელითაც მართვა
შეგიძლიათ CLI-ით:
```bash
aihummer update --check # report whether a newer version is available
aihummer update # download and apply the update
```
```ini
# gateway.env — notify-only on the stable channel
AIHUMMER_AUTO_UPDATE=check
AIHUMMER_UPDATE_CHANNEL=stable
```
> [!TIP]
> დაიწყეთ `AIHUMMER_AUTO_UPDATE=check`-ით ახალი გამოშვებების შესახებ შესატყობინებლად
> და გადადით `apply`-ზე, როცა არხს ენდობით უმეთვალყურეო rollout-ებისთვის.
## უმტყუნებო rollout-ები
AiHummer აგებულია იმისთვის, რომ განახლდეს გათიშვის გარეშე:
- **გაუშვით 2+ gateway proxy-ის უკან.** გადააბრუნეთ ისინი თითო-თითოდ; მზადყოფნის
ზონდი (`/readyz`) ინახავს რესტარტირებად კვანძს როტაციის გარეთ, სანამ ის
მსვლელობას არ მოაწვდის.
- **scheduler ერთ-ლიდერიანია.** ფონური დაგეგმვა ირჩევს ერთ ლიდერს PostgreSQL
advisory lock-ით, ასე რომ მრავალი gateway-ის გაშვება არ ადუბლირებს დაგეგმილ
სამუშაოს.
- **მიწოდება იდემპოტენტურია.** გარანტირებული მიწოდების outbox პლუს იდემპოტენტობის
გასაღებები ნიშნავს, რომ პასუხი არასოდეს იგზავნება ორჯერ რესტარტის გასწვრივ, რაც
ფლოტის გადაბრუნებას უსაფრთხოს ხდის.
## სად შემდეგ
- ზონდები, რომლებიც აკონტროლებენ მოძრავ რესტარტს:
[systemd და ჯანმრთელობის შემოწმებები](/ka/v1.0/operations/systemd-health).
- დაარეზერვეთ მნიშვნელოვანი განახლების წინ:
[სარეზერვო ასლები და კატასტროფიდან აღდგენა](/ka/v1.0/operations/backups-dr).
- ადევნეთ თვალი rollout-ს:
[დაკვირვებადობა](/ka/v1.0/operations/observability).
</content>
</invoke>