ესკალაციის მატრიცა
1) მატრიქსის დანიშნულება
ესკალაციის მატრიცა არის ერთიანი წესები, ვინ და როდის უკავშირდება ინციდენტებს სწრაფად ქაოსიდან კონტროლირებად პროცესში. იგი სვამს:- SEV დონე და მათი კრიტერიუმები;
- ტაიმინგი (ack-ack-ascalation-apdaty- ის აღმოჩენა);
- როლები/არხები თითოეული ნაბიჯისთვის;
- გამონაკლისი (უსაფრთხოებისა და შესაბამისობისთვის „მშვიდი საათის“ გარეშე);
- პლეიბუკებთან და სტატუსის გვერდთან ერთად.
2) სიმძიმის კლასიფიკაცია (SEV)
მიუთითეთ თქვენი დომენისა და SLO- ს მიზნობრივი ნომრები.
3) ძირითადი მატრიცა „ვინ/როდის/სად“
4) ესკალაციის გადამწყვეტი ხე (არსი)
1. დადასტურებულია გავლენა SLO- ზე?
დიახ: დანიშნეთ IC, გამოაცხადეთ SEV, გახსნათ ომის ოთახი.
• არა: ticket/დაკვირვება, პეიჯის გარეშე.
2. დროულად არის ACK?
დიახ: ჩვენ ვაგრძელებთ playbook- ს.
• არა: P2 - IC - DM (დროულად ხე).
3. უსაფრთხოება/გაჟონვა/PII?
• ყოველთვის უსაფრთხოების IR + Legal, საჯარო შეტყობინებები შეთანხმებულია.
4. გარე პროვაიდერი?
Vendor Owner- ის ესკალაცია, მარშრუტების გადართვა, სტატუსის ფიქსი.
5) როლები და მოვალეობები ესკალაციაში (მოკლედ)
P1 (Primary): სამჯერ, ფლეიბუკის დაწყება, კომუნიკაცია IC- სთან.
P2 (მეორე): ზურგჩანთა, რთული მოქმედებები, კონტექსტის შენარჩუნება.
IC (Incident Commander): აცხადებს SEV, გადაწყვეტს freeze/rollback, ინარჩუნებს ტემპს.
Duty Manager: წაშლის ბლოკირებას, ანაწილებს რესურსებს, იღებს ორგულ გადაწყვეტილებებს.
Comms: სტატუსის გვერდი, Apdates on SLA.
უსაფრთხოება IR: იზოლაცია, წინსვლა, იურიდიული შეტყობინებები.
Vendor Owner: გარე პროვაიდერები, switchover/fallback.
6) დროებითი ჰაიდები (სახელმძღვანელო)
SEV-1/0: ACK ≤ 5 м, Declare ≤ 10 м, First Comms ≤ 15 м, Updates q=15–30 м.
ესკალაციის ხე: P1-P2 (5 მ), IC (10 მ), Duty Manager (15 მ), Exec on-call (30 მ).
უსაფრთხოება: შეფერხებების გარეშე და „მშვიდი საათი“, განახლება q = 15 მ
7) მარშრუტიზაცია და სეგმენტი
მომსახურების/რეგიონის/ტენანტის მიხედვით: მარშრუტიზაციის გასაღები = 'მომსახურება + რეგულირება + ტენანტი'.
ზონდის კვორუმი: ესკალაცია მხოლოდ მაშინ, როდესაც დადასტურებულია 2 დამოუკიდებელი წყარო (სინთეტიკური 2 რეგიონიდან + RUM/ბიზნეს SLI).
დედაპი: ერთი მასტერ-ალერტი ათობით სიმპტომის ნაცვლად (BD „წითელი“ აჩერებს 5xx ხმაურს).
8) გამონაკლისი და განსაკუთრებული რეჟიმები
უსაფრთხოება/ლეგალი: უსაფრთხოების IR და ლეგალის ესკალაცია თავის მხრივ; საჯარო ტექსტები მხოლოდ კოორდინაციის გზით.
პროვაიდერები: ცალკეული OLA/SLA მატრიცა (კონტაქტები, დროის ზონები, პრიორიტეტი).
Change Freeze: SEV-1/0 - ავტომატური უფასო გამოშვებები და კონფიგურაცია.
9) მატრიქსის სიმწიფის მეტრიკა
Ack p95 (SEV-1/0) - 5 წთ.
დრო Declare (საშუალო) 10 წუთზე.
Comms SLA Adherence ≥ 95%.
Escalation Success (გადაწყდა P1/P2 დონეზე) 70% -ით.
No-ACK escalations ↓ QoQ.
Vendor Response Time კრიტიკულ პროვაიდერებს შორის ხელშეკრულების ფარგლებში.
10) ჩეკის ფურცლები
ოპერატიული (on-call- ისთვის)
- განსაზღვრულია გავლენა SLO და პოტენციური SEV.
- დამზადებულია ACK და დაინიშნა IC (SEV-1/0).
- გაიხსნა ომის ოთახი, პლეიბუკი ერთვის.
- სტატუსის განახლება გამოქვეყნებულია/დაგეგმილია SLA.
- freeze (საჭიროების შემთხვევაში) ჩართულია, პროვაიდერი/უსაფრთხოება ესკალირებულია.
პროცესორი (ყოველკვირეული მიმოხილვა)
- ესკალაციის კიბე მუშაობდა SLA- ში?
არ ყოფილა დამატებითი ესკალაციები IC- მდე?
- მომხმარებელთა შეტყობინებები დროული და ზუსტი?
იყო ბლოკერები (წვდომა, პროვაიდერების კონტაქტები, „მუნჯი“ არხი)?
- CAPA პროცესის გაუმართაობისთვის ასევე მუშაობს.
11) შაბლონები
11. 1 ესკალაციის პოლიტიკა (YAML იდეა)
yaml policy:
sev_levels:
- id: SEV-0 declare_tgt_min: 5 first_comms_min: 10 update_cadence_min: 15
- id: SEV-1 declare_tgt_min: 10 first_comms_min: 15 update_cadence_min: 30 ack_sla_min:
default: 5 ladder:
- after_min: 5 escalate_to: "P2:oncall-<service>"
- after_min: 10 escalate_to: "IC:ic-of-the-day"
- after_min: 15 escalate_to: "DutyManager:duty"
- after_min: 30 escalate_to: "Exec:oncall-exec"
channels:
war_room: "#war-room-<service>"
alerts: "#alerts-<service>"
security: "#sec-war-room"
providers: "vendors@list"
quorum:
required_sources: 2 sources: ["synthetic:eu,us", "rum:<service>", "biz_sli:<kpi>"]
exceptions:
security: { quiet_hours: false, legal_approval_required: true }
providers: { auto_switch: true, notify_vendor_owner: true }
11. 2 ბარათი „დროულად ესკალაცია“ (ბოტისთვის)
T + 05m: no ACK → escalated to P2
T + 10m: no ACK/Declare → escalated to IC, war-room open
T + 15m: no Comms → reminder Comms, escalation Duty Manager
T + 30m: no Updates → IC reminder, Exec on-call CC
11. 3 პირველი საზოგადოებრივი აპდეიტის შაბლონი
Impact: [services/regions] affected, [symptoms e.g. delays/errors].
Reason: Investigating; confirmed by monitoring quorum.
Actions: bypass routes/restrictions are enabled, provider switching is in progress.
Next update: [time, time zone].
12) ინტეგრაცია
Alert-as-Code: თითოეული Page წესი ეხება ზუსტად ერთ ფლეიბუკს და იცის მისი ესკალაციის მატრიცა.
ChatOps: ბრძანებები '/declare sev1 ', '/page p2', '/status განახლება ', Apdate Times.
CMDB/კატალოგი: მომსახურებას აქვს მფლობელები, on-call, მატრიცა, პროვაიდერები, არხები.
Status page: შაბლონები SEV-1/0, აპდეიტების ისტორია, ბმულები RCA- ზე.
13) ანტი შაბლონები
„დაუყოვნებლივ ყველას ესკალაცია“ - ხმაური და ბუნდოვანი პასუხისმგებლობა.
არა IC/ომის ოთახი - გადაწყვეტილებები ვრცელდება ჩეტებზე.
პირველი აფდიტის შეფერხება არის საჩივრების ზრდა და PR რისკები.
უსაფრთხოების გამონაკლისების არარსებობა იურიდიული რისკებია.
გარე პროვაიდერები მფლობელის და კონტაქტების გარეშე.
კიბე არ არის ავტომატიზირებული - ეს ყველაფერი „ხელკეტზეა“.
14) განხორციელების გზის რუკა (3-5 კვირა)
1. ნვე. 1: დაფიქსირდეს SEV კრიტერიუმები და ტაიმინგი; შეაგროვეთ კონტაქტები როლები/პროვაიდერები; არხების არჩევა.
2. ნვე. 2: აღწერეთ პოლიტიკა (YAML), მიბმული Alert-as-Code- სთან, ჩართეთ ხე პეიჯერში/ბოტში.
3. ნვე. 3: მფრინავი 2-3 კრიტიკულ სერვისზე; გამართეთ Comms SLA და შაბლონები.
4. ნვე. 4-5: გაფართოება, ყოველკვირეული ესკალაციის მიმოხილვის შემოღება და სიმწიფის მეტრიკა.
15) შედეგი
ესკალაციის მატრიცა არის ინციდენტების ოპერაციული კონსტიტუცია: ვინ, როდის და როგორ არის დაკავშირებული. მკაფიო SEV, ტაიმინგი, არხები, უსაფრთხოების გამონაკლისი და პლეიბუკებთან და სტატუს გვერდთან ინტეგრაცია, გუნდი რეაგირებს სწრაფად, თანმიმდევრულად და გამჭვირვალედ, ხოლო მომხმარებლები ხედავენ პროგნოზირებულ აფთიაქებს და მომსახურების თავდაჯერებულ აღდგენას.