İstehsal mühitində problem yarananda komandanın əsas məqsədi dərhal “əsas səbəbi tapmaq” deyil, istifadəçiyə və biznesə dəyən zərəri idarə etməkdir. Yaxşı application incident response plan bunun üçün əvvəlcədən razılaşdırılmış iş axınıdır: insidenti tanımaq, təsirini qiymətləndirmək, bir rəhbər təyin etmək, təhlükəsiz bərpa variantını seçmək, düzgün auditoriyaya məlumat vermək və öyrənilənləri məhsul backlog-una çevirmək.

Monitorinq alətləri simptomu aşkar edir: 5xx xətalarının artması, API gecikməsi, uğursuz ödənişlər, crash-rate və ya queue-nun böyüməsi. İnsident prosesi isə insanları, qərarları və kommunikasiya kanalını koordinasiya edir. Bu fərq xüsusilə veb platforma, SaaS məhsulu və mobil tətbiq eyni backend-dən istifadə etdikdə vacibdir.

İnsident nədir və nə deyil?

Hər xəta insident deyil. Bir istifadəçinin lokal brauzer problemi support sorğusu ola bilər; lakin checkout-un işləməməsi, məlumatın səhv hesabda görünməsi, girişin kütləvi pozulması və ya yeni relizin əhəmiyyətli funksiyanı sıradan çıxarması insidentdir. Praktik meyar budur: hadisə normal iş rejimini pozur və aktiv koordinasiya olunmuş cavab tələb edirmi?

Plan həm əlçatanlıq, həm düzgünlük, həm təhlükəsizlik, həm də məlumat bütövlüyünü əhatə etməlidir. Məsələn, sistem cavab verir, amma qiymətləri köhnə cache-dən göstərirsə, bu “uptime” baxımından yox, biznes düzgünlüyü baxımından ciddi insident ola bilər.

Severity səviyyələrini komponentə yox, təsirə görə qurun

“Database problemi” və ya “payment bug” severity deyil. Severity istifadəçilərin kim olması, neçə nəfərin təsirlənməsi, əsas əməliyyatın dayanması, məlumatın riski və workaround-un olub-olmaması ilə təyin olunur. Aşağıdakı dörd səviyyə əksər məhsullar üçün işlək başlanğıcdır.

SEV-1 — kritik xidmət və ya məlumat riski

  • Əsas istifadəçi axını geniş miqyasda dayanıb: login, sifariş, ödəniş, rezervasiya və ya əsas biznes əməliyyatı.
  • Məlumat itkisi, icazəsiz giriş, yanlış məlumatın yayılması və ya geri dönməz maliyyə nəticəsi riski var.
  • Etibarlı workaround yoxdur və ya yalnız çox məhdud istifadəçiyə kömək edir.

SEV-1 üçün insident komandası dərhal toplanır, dəyişikliklər dondurula bilər və müştəriyə ilkin status məlumatı gecikdirilmədən verilir.

SEV-2 — əhəmiyyətli pozulma

  • İstifadəçilərin nəzərəçarpan hissəsi və ya mühüm müştəri seqmenti təsirlənib.
  • Əsas funksiya zəifləyib, lakin qismən workaround mövcuddur.
  • Məsələn, mobil tətbiqdə yeni versiya müəyyən iOS/Android versiyalarında açılmır, amma web versiya işləyir.

SEV-3 və SEV-4 — məhdud təsir və planlı düzəliş

  • SEV-3: funksiya qismən pozulub, istifadəçi təsiri məhduddur, təhlükəsiz workaround var.
  • SEV-4: müşahidə edilən anomaliya və ya aşağı prioritetli qüsurdur; onu ticket və adi reliz prosesi ilə həll etmək olar.

Severity sonradan yenilənə bilər. İlk qiymətləndirmədə ehtiyatlı davranmaq normaldır; yeni telemetriya təsirin daha kiçik və ya daha böyük olduğunu göstərə bilər. Əsas qayda budur: severity müzakirəsi bərpanı ləngitməməlidir.

İlk 30 dəqiqə üçün production incident runbook

  1. İnsidenti elan edin. Tək status kanalı, insident vaxtı, qısa təsvir, ilkin severity və incident commander qeyd olunur.
  2. Rol təyin edin. Incident commander qərarları və tempi idarə edir; technical lead diaqnostika və mitigasiya işini yönəldir; communications lead daxili və xarici yeniləmələri hazırlayır; scribe isə zaman xəttini, müşahidələri və qərarları yazır. Kiçik komandada bir nəfər bir neçə rol daşıya bilər, amma commander eyni anda hər logu analiz etməməlidir.
  3. Təsiri ölçün. Hansı regionlar, tenant-lar, tətbiq versiyaları, endpoint-lər və əsas user journey-lər təsirlənib? Uğursuz əməliyyatların sayı, xəta faizi, gecikmə və biznes əməliyyatlarının vəziyyəti nədir?
  4. Dəyişiklikləri dayandırın. Təsirlənən xidmətə yeni deploy, konfiqurasiya və schema dəyişikliklərini dondurun. Əks halda zaman xətti qarışar və blast radius böyüyər.
  5. Mitigasiya seçin. Rollback, feature flag-in söndürülməsi, trafikin sağlam versiyaya yönləndirilməsi, zərərli job-un dayandırılması, rate limit və ya qeyri-kritik funksiyanın müvəqqəti söndürülməsi daha sürətli və təhlükəsiz ola bilər.
  6. Faktları qoruyun. Deploy SHA-ları, feature flag vəziyyəti, alertlər, dashboard şəkilləri, sorğu identifikatorları, audit logları və əsas qərarlar saxlanmalıdır. Məlumat səhvi ehtimalında avtomatik cleanup və ya mass update etməzdən əvvəl sübutları qoruyun.

Rollback, hotfix, yoxsa konfiqurasiya dəyişikliyi?

Application rollback strategy “hər bug-da geri qayıt” demək deyil. Seçim sistemin vəziyyətindən və geri dönüşün təhlükəsizliyindən asılıdır. Yeni relizlə insident arasında güclü zaman əlaqəsi varsa, əvvəlki artefakt hazırdırsa və rollback database/contract uyğunsuzluğu yaratmırsa, rollback adətən ən sürətli risk azaldan qərardır.

Amma aşağıdakı hallarda rollback təhlükəli və ya faydasız ola bilər:

  • Yeni versiya geri dönməyən database migration yazıb;
  • Problem xarici provayder, sertifikat, DNS, asılılıq və ya trafik pikidir;
  • İki versiya eyni korlanmış məlumatı emal edir;
  • Rollback başqa kritik düzəlişi aradan qaldıracaq;
  • Mobil tətbiq mağazada artıq yayımlanıb və server tərəfdə uyğunluq qatına ehtiyac var.

Bu halda feature flag, server-side kill switch, backwards-compatible hotfix, trafikin bölünməsi və ya təhlükəsiz “read-only” rejim daha yaxşı mitigasiya ola bilər. Hotfix yalnız səbəb və dəyişiklik həcmi kifayət qədər aydın olduqda seçilməlidir. SEV-1 zamanı böyük refaktor yazmaq yox, riski azaltmaq məqsəddir.

Mobil məhsullarda rollback planı əlavə hazırlıq tələb edir: istifadəçinin cihazındakı binary-ni dərhal geri qaytarmaq mümkün deyil. API contract-ları versiyalaşdırmaq, uzaqdan idarə olunan flag-lar, minimum supported version qaydası və köhnə müştərilər üçün uyğunluq siyasəti vacibdir. Mobil tətbiqlərin hazırlanması zamanı bu əməliyyat detalları arxitekturanın və release prosesinin hissəsi olmalıdır.

Müştəri kommunikasiyası: tez, faktiki və istifadəçi yönümlü

Texniki komandaya “Redis timeout” mənalı ola bilər, lakin müştərinin bilməli olduğu budur: hansı funksiya işləmir, kimlər təsirlənir, workaround varmı və növbəti yeniləmə nə vaxt olacaq. İlkin mesaj səbəbi tam təsdiqləməyi gözləməməlidir. Təsdiqlənməmiş fərziyyəni fakt kimi yazmaq isə olmaz.

Hazırda bəzi istifadəçilər sifariş yaratmaqda çətinlik çəkə bilər. Komandamız problemi araşdırır və təsiri azaltmaq üçün tədbir görür. Mövcud sifarişlərə təsir barədə sübut yoxdur. Növbəti yeniləmə saat 14:30-da paylaşılacaq.

SEV-1/SEV-2 üçün əvvəlcədən status səhifəsi, support makrosu və hesab menecerləri üçün qısa brif hazırlayın. Yeniləmə intervalını verin və problem həll olunmasa belə həmin vaxtda status paylaşın. “Resolved” yalnız texniki metrik normaya qayıdanda deyil, əsas istifadəçi ssenarisi real istifadəçi baxımından yoxlananda yazılmalıdır.

Bərpanı necə yoxlamaq lazımdır?

Alertin yaşıl olması bərpa demək deyil. Bərpa yoxlaması ən azı bunları əhatə etməlidir:

  • xəta faizi və gecikmənin normal diapazona qayıtması;
  • login, ödəniş, sifariş, fayl yükləmə və ya məhsulunuzun əsas journey-si üzrə sintetik və ya manual test;
  • queue, retry və dead-letter proseslərinin yoxlanması;
  • məlumat uyğunsuzluğu ehtimalında reconciliation: hansı əməliyyatlar uğursuz, təkrar və ya qismən tamamlanıb;
  • mobil tətbiq, web və API müştərilərinin ayrıca təsdiqi;
  • qısa müşahidə dövrü və təkrar alertlərin izlənməsi.

Xüsusilə ödəniş, inventar, trading və ya digər tranzaksiya sistemlərində “servis ayaqdadır” ilə “bütün əməliyyatlar düzgündür” eyni şey deyil. Veb platformaların hazırlanması üçün idempotency, audit izi və reconciliation imkanları insidentdən əvvəl dizayn edilməlidir.

Post-incident review: hesabatı backlog işinə çevirin

İnsident bitdikdən sonra günahkar axtarmayan, faktlara əsaslanan review keçirin. Sənəddə təsir, zaman xətti, tetikleyici, səbəb faktorları, aşkar etmə üsulu, görülən mitigasiya, nə yaxşı işlədi və nə çətinlik yaratdı qeyd edilməlidir. Ən vacib hissə action item-lardır: hər işin sahibi, prioriteti və tamamlanma tarixi olmalıdır.

Yaxşı nəticələr “monitorinqi yaxşılaşdırın” kimi ümumi olmur. Məsələn: checkout üçün synthetic test əlavə edin; migration üçün expand/contract qaydası tətbiq edin; rollback drill keçirin; payment provider xətalarına tenant səviyyəli dashboard qurun; status mesajı şablonunu hüquq və support komandası ilə təsdiqləyin.

Komandanızda daimi on-call, release nəzarəti, performans və təhlükəsizlik təkmilləşdirməsi üçün resurs yoxdursa, Texniki dəstək və konsaltinq xidməti insident runbook-larını, observability-ni, təhlükəsiz relizləri və bərpa məşqlərini məhsulunuza uyğun qurmağa kömək edə bilər. Mövcud prosesinizi qiymətləndirmək və praktik cavab planı yaratmaq üçün POLADO ilə əlaqə saxlayın.

İnsident planı üçün qısa yoxlama siyahısı

  • Severity səviyyələri istifadəçi, biznes və məlumat təsiri ilə yazılıb.
  • Commander, technical lead, communications lead və scribe rolları məlumdur.
  • On-call kontaktları, giriş səlahiyyətləri və müstəqil kommunikasiya kanalı mövcuddur.
  • Son stabil artefakt, feature flag və rollback addımları sənədləşdirilib və sınaqdan keçirilib.
  • Əsas user journey-lər üçün bərpa yoxlama addımları var.
  • Status yeniləməsi şablonları və müştəri auditoriyaları müəyyənləşdirilib.
  • Post-incident action item-ları backlog-da izlənir.