რა კრიტერიუმებს იყენებთ rollback-სა და hotfix-ს შორის გადასაწყვეტად?

Question

IT Interview Practice · Accepted Answer

ნაგულისხმევად **rollback** — ეს არის ყველაზე სწრაფი, ყველაზე საიმედო გზა ცნობილ-კარგი მდგომარეობის აღსადგენად. მიმართე **hotfix-ს** მხოლოდ მაშინ, როცა rollback შეუძლებელია ან უფრო საშიში, ვიდრე წინ გასწორება. აქტიურ incident-ში პრიორიტეტია **ჯერ სისხლდენის შეჩერება**, დიაგნოზი მერე.

## გადაწყვეტილების კრიტერიუმები

- **rollback უსაფრთხო და შესაძლებელია?** თუ წინა ვერსია ცნობილ-კარგია და შეუქცევადი არაფერი მომხდარა, გააკეთე rollback. ეს ჩვეულებრივი პასუხია.
- **ცუდმა გამოშვებამ შეუქცევადი state შექმნა?** **database migration** ან მონაცემთა დაზიანება rollback-ს ბაგზე უარესს ხდის. თუ უსაფრთხოდ ვერ დაბრუნდები, წინ უნდა გაასწორო.
- **გვესმის fix?** rollback-ს დიაგნოზი არ სჭირდება — ეს მისი ძალაა. hotfix, რომელიც სრულად არ გესმის, incident-ს გააღრმავებს; არასოდეს დააshipo ვარაუდი prod-ში ზეწოლის ქვეშ.
- **დრო უსაფრთხო მდგომარეობამდე.** აირჩიე ის გზა, რომელიც სტაბილურობას ყველაზე სწრაფად და ნაკლები რისკით აღწევს. ერთხაზიანი, კარგად გასაგები hotfix შეიძლება სჯობდეს რთულ rollback-ს; სარისკო წინ-გასწორება არასოდეს სჯობს სუფთა revert-ს.
- **blast radius და სიმძიმე.** სრული outage ყველაზე სწრაფ შესაძლო აღდგენას მოითხოვს (ჩვეულებრივ rollback); მცირე degradation შეიძლება ფრთხილ hotfix-ს უშვებდეს.

## სწრაფი გადაწყვეტილების ცხრილი

| სიტუაცია | აირჩიე |
| --- | --- |
| წინა ვერსია ცნობილ-კარგი, migration არ არის | Rollback |
| შეუქცევადი DB migration გაიshipa | Hotfix / fix-forward |
| მიზეზი უცნობია, მძიმე გავლენა | Rollback (იყიდე დრო) |
| ტრივიალური, კარგად გასაგები ერთხაზიანი | Hotfix |
| rollback თვითონ სარისკო/გაუტესტავია | Hotfix |

## Trade-off-ები და ხაფანგები

- **rollback** უსაფრთხოა, მაგრამ მხოლოდ სიმპტომს მკურნალობს — ჯერ კიდევ გმართებს რეალური fix და postmortem.
- **hotfix** root cause-ს ეხება, მაგრამ ნორმალურ უსაფრთხოების ბადეს გამოტოვებს; hotfix-ებში ბაგები გავრცელებულია სწორედ იმიტომ, რომ ისინი ნაჩქარევია.
- **გაუტესტავი rollback path** ხაფანგია — თუ არასოდეს გაგირჩევია, შეიძლება ჩავარდეს, როცა ყველაზე მეტად გჭირდება. ივარჯიშე rollback-ებზე, სანამ დაგჭირდება.
- ფრთხილად იყავი **production-ში debugging-თან** ზეწოლის ქვეშ; თუ თავდაჯერებული fix-იდან რამდენიმე წუთზე მეტი გაშორებს, გააკეთე rollback და გამოიკვლიე მშვიდად.

## რატომ არის ეს მნიშვნელოვანი

ეს გადაწყვეტილება ყველაზე ცუდ შესაძლო მომენტში ხდება — სისტემა გათიშულია, საათი მირბის, ყველა უყურებს. Tech Lead, რომელსაც აქვს მკაფიო, ნავარჯიშები წესი ამისთვის, MTTR-ს მკვეთრად ჭრის და თავიდან აცილებს კლასიკურ შეცდომას — incident-ის შუაში ჭკვიანობის მცდელობას, როცა მოსაწყენი revert იქვე იყო. ჯერ აღადგინე, ჭკვიანი მერე იყავი.

სიტუაცია	აირჩიე
წინა ვერსია ცნობილ-კარგი, migration არ არის	Rollback
შეუქცევადი DB migration გაიshipa	Hotfix / fix-forward
მიზეზი უცნობია, მძიმე გავლენა	Rollback (იყიდე დრო)
ტრივიალური, კარგად გასაგები ერთხაზიანი	Hotfix
rollback თვითონ სარისკო/გაუტესტავია	Hotfix

გადაწყვეტილების კრიტერიუმები

სწრაფი გადაწყვეტილების ცხრილი

Trade-off-ები და ხაფანგები

რატომ არის ეს მნიშვნელოვანი

დაკავშირებული კითხვები