Cloud და SaaS
პლატფორმის საიმედოობა და ხარჯების კონტროლი
დაკვირვებადობა, ინციდენტების პროცესი, ავტომატიზაცია და ხარჯების ხედვა — SaaS პროდუქტის ზრდის ტემპში.
პრობლემა
პროდუქტი იზრდება, ოპერაცია კი იმავე დღეს დარჩა
ინციდენტს მომხმარებელი აღმოაჩენს ხოლმე პირველი. alert-ები იმდენია, რომ აღარავინ უყურებს, და ნამდვილი პრობლემა ხმაურში იკარგება. ვინ დგას ჯერზე — არავინ იცის ზუსტად, ხოლო ღრუბლის ანგარიში ყოველთვე იზრდება ისე, რომ მიზეზი ვერავინ ასახელა.
- alert-ების ხმაური აზრს კარგავს
- ინციდენტს მომხმარებელი აღმოაჩენს
- ჯერზე დგომა შეთანხმებული არაა
- ხარჯი იზრდება, მიზეზი უცნობია
რას ვაწვდით
პლატფორმის საიმედოობა და ხარჯების კონტროლი
სერვისების რუკა
რომელი კომპონენტი რაზეა დამოკიდებული და რომელი ვარდნა რას აჩერებს.
SLO და alert-ების ჰიგიენა
თითოეული alert ან მოქმედებას მოითხოვს, ან იშლება — შუალედური ვარიანტი არაა.
ინციდენტის პროცესი
severity, ჯერზე დგომა, ესკალაცია და ინციდენტის შემდგომი მიმოხილვა.
დაკვირვებადობა აპლიკაციაზე
მეტრიკები, ლოგები და მოთხოვნის კვალი — ერთ ადგილას, ერთი დროის ღერძით.
გაშვების ჯაჭვი
CI/CD, გარემოების პარიტეტი და rollback, რომელიც წუთებში სრულდება.
ხარჯების ხედვა
რა მოიხმარს რესურსს, რა დგას უქმად და რა ჯდება ყოველი გარემო.
არქიტექტურა
არქიტექტურა
- 01სერვისების რუკადამოკიდებულებები და ვარდნის გავლენა
- 02SLOშეთანხმებული ზღვარი — რა ითვლება ვარდნად
- Error budget
- Latency
- Saturation
- 03Alertთითოეული alert მოქმედებას მოითხოვს
- Prometheus
- Alertmanager
- Grafana
- 04ინციდენტიseverity, ჯერზე დგომა, ესკალაცია
- Runbook
- Telegram
- PagerDuty
- 05აღდგენაrollback ან აღდგენა ბექაპიდან
- Rollback
- pg_dump
- Migrations
- 06მიმოხილვაინციდენტის შემდგომი დასკვნა და ხარჯი
- RCA
- Cost review
საოპერაციო ეკრანები
საოპერაციო ეკრანები
ეს კონკრეტული სისტემები ჯგუფის რეალურ ინფრასტრუქტურაზე მუშაობს — სქრინშოტები დამუშავებულია გამოქვეყნებამდე.
8 კლასტერი ერთი ინტერფეისიდან
Proxmox Datacenter Manager აერთიანებს ერთმანეთისგან დამოუკიდებელ Proxmox VE კლასტერებს ერთ სივრცეში. ჩვენს ინფრასტრუქტურაში ის 8 კლასტერს მართავს — სხვადასხვა ფიზიკურ ლოკაციაზე, მათგან 3 საქართველოს ფარგლებს გარეთ. ეკრანზე ჩანს მასშტაბიც: 211 კვანძი ონლაინ, 1480 ვირტუალური მანქანა და 127 კონტეინერი — ერთი ხედით, ერთი პროცედურით.
შესაძლებლობები
შესაძლებლობები
თითოეული პუნქტი აღნიშნულია: დადასტურებული პროდაქშენ გამოცდილება თუ საინჟინრო შესაძლებლობა.
SLO და alert-ების ჰიგიენა
CapabilityCI/CD და გარემოები
Proven- Docker
- GitHub Actions
- Dokploy
დაკვირვებადობა აპლიკაციაზე
Capability- Prometheus
- Loki
- Grafana
On-call პროცესი
Provenმონაცემთა ბაზა და ტესტირებული აღდგენა
Provenბექაპის როტაცია და აღდგენის რეპეტიცია scratch ბაზაში — ჩვენივე პლატფორმებზე ასე მუშაობს.
- PostgreSQL
- pg_dump
- Migrations
ხარჯების ოპტიმიზაცია
Capabilityტექნოლოგიური სტეკი
ტექნოლოგიური სტეკი
- Runtime
- DockerKubernetesnginxTraefik
- CI/CD
- GitHub ActionsDokployGit
- დაკვირვებადობა
- PrometheusGrafanaLokiAlertmanager
- მონაცემები
- PostgreSQLRedisBackups
- ინციდენტი
- TelegramPagerDutyRunbooks
თანამშრომლობის მოდელი
თანამშრომლობის მოდელი
რეტეინერი
ყოველთვიური საინჟინრო საათები — სპეციალისტზე წვდომა მოთხოვნისამებრ.
Co-Managed
NetWizard და თქვენი შიდა გუნდი ერთად, გაყოფილი პასუხისმგებლობით.
პროექტი
ერთჯერადი scope: აუდიტი, მიგრაცია ან დანერგვა ფიქსირებული შედეგით.
გამოყენების შემთხვევები
გამოყენების შემთხვევები
ჯერზე დგომა გუნდს წვავს
ღამის alert-ები დეველოპერებს ხვდებათ და უმეტესობა ცრუა. ვასუფთავებთ წესებს, ვწერთ runbook-ებს და პირველ ხაზს ჩვენს NOC-ზე ვიღებთ.
ინვესტორის due diligence
საჭიროა ნაჩვენები პროცესი: მონიტორინგი, ბექაპი, წვდომის კონტროლი და ინციდენტების ისტორია. ვაწესრიგებთ და ვაბარებთ დოკუმენტაციად.
ღრუბლიდან საკუთარ ინფრასტრუქტურაზე
ანგარიში ზრდას აღარ ამართლებს. ვთვლით რეალურ ხარჯს, ვგეგმავთ ჰიბრიდულ ან საკუთარ განთავსებას და ვიტანთ ეტაპებად, დაბრუნების გზის შენარჩუნებით.
ხშირი კითხვები
ხშირი კითხვები
ჩვენს კოდში ერევით?
მხოლოდ იმდენად, რამდენადაც ინფრასტრუქტურას ეხება: build, კონფიგურაცია, მიგრაციები, მეტრიკების გამოტანა. პროდუქტის ლოგიკა თქვენი გუნდის საქმეა.
მცირე გუნდისთვის ღირს?
სწორედ მცირე გუნდისთვის ღირს — რადგან ჯერზე დგომა და ინციდენტები იმ ადამიანებს ხვდებათ, რომლებიც პროდუქტს აშენებენ. რეტეინერი მათ დროს ათავისუფლებს.
SLA-ს რას გვთავაზობთ?
სამიზნეები severity-ს მიხედვით ხელშეკრულებაში ფიქსირდება, თქვენი სერვისის კრიტიკულობასა და ჯერზე დგომის მოდელზე დაყრდნობით. საიტზე ციფრს არ ვწერთ, სანამ ის თქვენს scope-ზე არ არის შეთანხმებული.