თქვენი production ვებსაიტი ახლახან გათიშა. როგორ უმკლავდებით ამას?

Question

Accepted Answer

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

## ჯერ სტაბილიზაცია

- **გამოაცხადე incident** და გახსენი ერთი არხი (war room / Slack thread), რომ კოორდინაცია არ გაიფანტოს.
- **გაანაწილე როლები**: **Incident Commander** გადაწყვეტილებების მისაღებად, **comms owner** stakeholder-ების განახლებისთვის და **responder-ები** გამოსაკვლევად. როგორც Tech Lead, ხშირად ვიღებ IC-ის როლს, რომ ინჟინრები პრობლემაზე ფოკუსირდნენ.
- **მიმართე ყველაზე სწრაფ შექცევად გასწორებას.** თუ deploy კორელირებს outage-თან, ჯერ **roll back** გააკეთე და კითხვები მერე დასვი — მომხმარებლების აღდგენა სჯობს მართალი იყო.

## დიაგნოზი პარალელურად

- შეამოწმე **აშკარა სიგნალები**: dashboard-ები, error rate-ები, ბოლო deploy-ები, infra ცვლილებები, ტრაფიკის ნახტომები, ვადაგასული სერტიფიკატები.
- ჩამოაყალიბე ჰიპოთეზა, ჯერ ყველაზე იაფი შეამოწმე და **არ შეცვალო ხუთი რამ ერთდროულად** — ვერ მიხვდები, რომელმა იმუშავა.

## განუწყვეტელი კომუნიკაცია

სიჩუმე პანიკას აჩენს. ვაგზავნი განახლებებს მუდმივი რიტმით მაშინაც კი, როცა სიახლე არ არის:

```
[14:05] ვიკვლევთ — checkout გათიშულია, ~40% მომხმარებელი დაზარალდა. შემდეგი განახლება 14:20.
[14:20] დადგინდა: ცუდი deploy. ვაკეთებთ rollback-ს. ETA 10 წთ.
[14:35] სერვისი აღდგა. ვაკვირდებით. postmortem მოჰყვება.
```

## აღდგენის შემდეგ

- დაადასტურე სრული აღდგენა და არა მხოლოდ "უკეთ ჩანს".
- ჩაატარე **blameless postmortem** რამდენიმე დღეში: timeline, root cause, რამ გააჭიანურა აღმოჩენა/გასწორება და **კონკრეტული action item-ები მფლობელებით**.
- შედეგი არის სისტემური გაუმჯობესება (უკეთესი alert-ები, guardrail-ები, rollback-ის ავტომატიზაცია) — და არა დასადანაშაულებელი სახელი.

## ხაფანგები

- **debugging mitigation-ამდე**, სანამ მომხმარებლები იტანჯებიან.
- **ერთიანი გადაწყვეტილების მიმღების არარსებობა**, ასე რომ ხუთი ადამიანი პარალელურად გამოიცნობს.
- **stakeholder-ებთან გაჩუმება.**
- **ინდივიდების დადანაშაულება**, რაც კლავს იმ გულახდილობას, რომელზეც სამომავლო incident-ები არიან დამოკიდებული.

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

outage-ები გარდაუვალია; როგორ მართავთ მათ, განსაზღვრავს გუნდის ნდობასა და მომხმარებლის ნდობას. მშვიდი, როლებზე დაფუძნებული კოორდინაცია plus blameless შემდგომი ნაბიჯები ცუდ დღეს უფრო ძლიერ სისტემად აქცევს — და ინჟინრებს ანიშნებს, რომ უსაფრთხოა სწრაფად მოძრაობა, რადგან წარუმატებლობა პროცესად განიხილება და არა ჯადოქრების ნადირობად.