Bakıda website maintenance services yalnız "nəsə xarab olanda düzəltmək" xidməti olmamalıdır. Yaxşı post-launch dəstək modeli məhsulun kim tərəfindən idarə olunduğunu, kritik hadisəyə nə qədər vaxtda reaksiya veriləcəyini, dəyişikliklərin necə təsdiqlənəcəyini və uğursuz relizin necə geri qaytarılacağını əvvəlcədən müəyyən edir. Sayt korporativ təqdimat səhifəsi, müştəri portalı və ya inteqrasiyalı veb tətbiq ola bilər; əsas məqsəd eynidir: dəyişiklikləri idarə olunan, izlənə bilən və bərpa oluna bilən əməliyyat prosesinə çevirmək.

Bakıda website support Baku xidməti seçərkən ilk sual "aylıq neçə saat daxildir?" olmamalıdır. Daha vacib suallar bunlardır: domen, hostinq, kod repozitoriyası və analitika hesablarının sahibi kimdir? P1 hadisəsində kim qərar verir? Backup bərpası sonuncu dəfə nə vaxt sınaqdan keçirilib? Yeni funksiya canlı mühitə çıxmazdan əvvəl hansı yoxlamalardan keçir?

Post-launch dəstəkdə sahiblik: biznes nəyi öz nəzarətində saxlamalıdır?

Texniki tərəfdaş gündəlik əməliyyat işini idarə edə bilər, lakin biznes üçün kritik hesablar mümkün olduqda şirkətin adına və şirkətin nəzarət etdiyi e-poçt ünvanlarında açılmalıdır. Bu, partnyor dəyişikliyi, əməkdaşın ayrılması və ya təcili bərpa zamanı giriş riskini azaldır.

Sahiblik reyestrinə daxil ediləcək aktivlər

  • Domen və DNS: registrar hesabı, yenilənmə tarixi, registrant məlumatı, DNS zonası və dəyişiklik səlahiyyətləri.
  • Hostinq və bulud: ödəniş sahibi, administratorlar, serverlər, storage, CDN, e-poçt göndəriş xidməti və xərclənmə bildirişləri.
  • Kod və çatdırılma: Git təşkilatı, repozitoriyalar, əsas branch qaydaları, CI/CD sirləri, build artefaktları və deployment girişləri.
  • Məlumat və inteqrasiyalar: verilənlər bazası, backup lokasiyası, üçüncü tərəf API açarları, ödəniş, CRM, SMS və analitika hesabları.
  • Əməliyyat sənədləri: arxitektura sxemi, giriş matrisi, runbook, bərpa təlimatı, reliz qeydləri və açıq risklər siyahısı.

Bu reyestr parolların sənədi deyil. O, hər aktiv üçün biznes sahibi, texniki administrator, bərpa yolu və girişin yenidən yoxlanma tarixini göstərən idarəetmə sənədidir. Girişlər şəxsi hesablar üzərindən deyil, mümkün olduqda rol əsaslı qruplar və çoxfaktorlu identifikasiya ilə verilməlidir.

SLA-nı “tez cavab” yox, prioritet və ölçü ilə yazın

SLA dəstək tərəfdaşının hər dəyişikliyi dərhal tətbiq edəcəyi vədi deyil. O, hadisənin təsnifatı, ilkin cavab vaxtı, yeniləmə tezliyi, eskalasiya və bərpa hədəfləri barədə razılaşmadır. Hədəfləri məhsulun iş saatlarına, istifadəçi təsirinə və gəlir riskinə uyğun qurun. Məsələn, 24/7 alış-veriş və ya tranzaksiya sistemi ilə yalnız iş saatlarında sorğu qəbul edən korporativ saytın eyni SLA-ya ehtiyacı yoxdur.

Praktik prioritet matrisi

  • P1 — kritik: sayt və ya əsas istifadəçi axını əlçatmazdır, təhlükəsizlik hadisəsi var, yaxud tranzaksiya ciddi şəkildə dayanıb. Müqavilədə 24/7 əlaqə kanalı, qısa ilkin cavab hədəfi, status yeniləməsi intervalı və rəhbərliyə eskalasiya yazılmalıdır.
  • P2 — yüksək: əsas funksiya pozulub, lakin alternativ yol var və ya təsir istifadəçilərin bir hissəsi ilə məhdudlaşır. İş saatlarında sürətli araşdırma və müntəzəm yeniləmələr tələb olunur.
  • P3 — normal: məhdud təsirli nasazlıq, kontent problemi və ya performans müşahidəsi. Planlı sprint və ya növbəti baxım pəncərəsində həll oluna bilər.
  • P4 — sorğu: yeni ideya, dizayn düzəlişi, hesabat və ya kiçik təkmilləşdirmə. Bu işlər SLA hadisəsi deyil; ayrıca prioritetləndirmə və təsdiqlənmiş scope tələb edir.

Hər prioritet üçün ən azı dörd göstəricini ayırın: qəbulun təsdiqi, ilkin cavab, status yeniləməsi və bərpa və ya workaround. “Həll vaxtı” yalnız səbəb, üçüncü tərəf asılılığı və biznes təsdiqi nəzərə alınaraq ayrıca hədəf kimi yazılmalıdır. SLA saat qurşağını da açıq göstərsin: məsələn, Bakı iş saatları və kritik hallar üçün 24/7 növbətçilik.

Backup və rollback: mövcud nüsxə hələ bərpa oluna bilən nüsxə demək deyil

Backup strategiyası kodu, verilənlər bazasını, istifadəçi yükləmələrini, konfiqurasiyanı və kritik hallarda infrastruktur təsvirini əhatə etməlidir. Amma yalnız backup job-un “uğurlu” görünməsi kifayət deyil. Müntəzəm bərpa sınağı seçilmiş nüsxənin açıldığını, tətbiqin işlədiyini və bərpa müddətinin biznes üçün qəbul edilən olduğunu yoxlamalıdır.

RPO və RTO-nu sadə dildə razılaşdırın. RPO itirilməsi qəbul edilən ən son məlumat intervalıdır; RTO isə xidmətin bərpası üçün qəbul edilən müddətdir. Məsələn, müraciət formaları və sifarişlər üçün bir günlük məlumat itkisi qəbuledilməzdirsə, gecəlik backup kifayət etməyə bilər. Tələbi sistemə görə yazın, standart paketə görə yox.

Rollback ayrıca mexanizmdir. Uğursuz relizdə “serverdən köhnə faylları tapmaq” plan deyil. Komanda əvvəlki işlək build artefaktını, verilənlər bazası miqrasiyasının geri dönüş və ya irəli düzəliş yolunu, feature flag-ları və rollback qərar səlahiyyətini əvvəlcədən bilməlidir. Backup arxivlərini web root-da və ya ictimai əlçatan qovluqlarda saxlamaq təhlükəlidir; OWASP köhnə və unudulmuş backup fayllarının məxfi məlumat və kod sızdıra biləcəyini vurğulayır.

Təhlükəsizlik baxımı: patch, giriş və konfiqurasiya intizamı

Web application support services çərçivəsində təhlükəsizlik yalnız illik pentest deyil. Davamlı əməliyyat işinə framework, plugin, əməliyyat sistemi və dependency yeniləmələrinin izlənməsi; riskin qiymətləndirilməsi; test; reliz və nəticənin qeydiyyatı daxildir. Hər yeniləməni dərhal canlı mühitə çıxarmaq da düzgün yanaşma deyil: kritik zəifliklər sürətlə eskalasiya edilməli, adi yeniləmələr isə planlı baxım pəncərəsində sınaqdan sonra tətbiq olunmalıdır.

  • İstifadə olunmayan istifadəçiləri, API açarlarını və inteqrasiyaları periodik yoxlayın.
  • Administrator girişləri üçün MFA, minimum səlahiyyət və audit izi tətbiq edin.
  • DNS, server, tətbiq və CDN konfiqurasiya dəyişikliklərini change log-a salın.
  • Staging və production sirlərini ayırın; parolları kodda, ticket-də və ya çatda paylaşmayın.
  • İctimai admin panelləri, lazımsız portlar, köhnə fayllar və default girişlər üzrə periodik yoxlama edin.

Təhlükəsiz reliz prosesi necə görünür?

Nəzarətli reliz daha çox sənəd doldurmaq demək deyil. O, kritik sualları relizdən əvvəl cavablandırır: nə dəyişir, kim təsdiqləyib, necə yoxlanılıb, nə izlənəcək və problem yaranarsa geri dönüş nədir? Google SRE-nin canary yanaşması dəyişikliklərin məhdud hissəyə və məhdud vaxtda tətbiq edilərək nəticənin qiymətləndirilməsini tövsiyə edir. Kiçik məhsullarda bunun sadə ekvivalenti əvvəlcə staging-də yoxlama, sonra az riskli vaxtda nəzarətli production relizi və relizdən sonrakı müşahidə ola bilər.

Hər reliz üçün minimum checklist

  1. Dəyişiklik tələbi, biznes məqsədi və təsdiqləyən şəxs qeyd edilir.
  2. Kod review, avtomatik testlər və əsas istifadəçi ssenarilərinin manual yoxlaması tamamlanır.
  3. DB miqrasiyası varsa backup, təsir analizi və rollback/forward-fix planı hazırlanır.
  4. Reliz pəncərəsi, məsul şəxs, əlaqə kanalı və monitorinq göstəriciləri müəyyən edilir.
  5. Deployment versiyası və konfiqurasiya dəyişiklikləri qeyd olunur.
  6. Relizdən sonra giriş, konversiya, error rate, cavab müddəti və kritik inteqrasiyalar yoxlanılır.
  7. İnsident olarsa, rollback və ya feature flag ilə təsirin məhdudlaşdırılması üçün qərar verilir.

Kontent dəyişikliyi, təhlükəsizlik patch-i, kiçik bug fix və yeni funksiya eyni təsdiq səviyyəsini tələb etmir. Dəyişiklik növlərini əvvəlcədən təsnif etmək həm sürəti qoruyur, həm də qeyri-müəyyənliyi azaldır.

Aylıq hesabat: saatlar yox, əməliyyat vəziyyəti görünməlidir

Faydalı hesabat yalnız sərf edilmiş saat cədvəli deyil. O, biznes sahibinə məhsulun vəziyyətini və növbəti qərarları göstərməlidir: açılmış və bağlanmış ticket-lər, prioritetlər, təkrarlanan nasazlıqlar, relizlər, patch-lər, backup/bərpa sınaqları, performans və təhlükəsizlik riskləri, eləcə də növbəti ay üçün tövsiyələr.

Məsələn, eyni formulun davamlı səhv verməsi sadəcə üç P3 ticket deyil; kök səbəb analizi, istifadəçi axınının yoxlanması və ya inteqrasiya müqaviləsinin yenilənməsi tələb edən məhsul riskidir. Bu yanaşma baxımı reaktiv ticket xidmətindən idarə olunan məhsul əməliyyatına çevirir.

Dəstək tərəfdaşını seçməzdən əvvəl soruşulacaq suallar

  • Hesablar və kod şirkətimizin nəzarətində qalacaqmı?
  • P1, P2, P3 və P4 üçün cavab, yeniləmə və eskalasiya qaydaları hansılardır?
  • Backup nələri əhatə edir, harada saxlanır və bərpası nə vaxt sınaqdan keçirilib?
  • Canlı relizdən əvvəl və sonra hansı testlər aparılır?
  • Uğursuz reliz üçün konkret rollback proseduru varmı?
  • Security patch-ləri və kritik zəifliklər necə izlənir?
  • Aylıq hesabatda ticket-lərdən əlavə hansı risk və tövsiyələr təqdim olunur?

Yeni sayt, müştəri portalı və ya mövcud platforma üçün dəstək modelini qurursunuzsa, POLADO-nun texniki dəstək və konsaltinq xidməti handover auditindən, performans və təhlükəsizlik yoxlamalarından başlayaraq reliz və monitorinq prosesini formalaşdırmağa kömək edə bilər. Məhsulun arxitekturası və gələcək inkişaf planı dəstək xərclərinə birbaşa təsir etdiyinə görə, veb platformaların hazırlanması yanaşmasını da erkən mərhələdə nəzərdən keçirmək faydalıdır. Daha mürəkkəb, inteqrasiyalı məhsul nümunəsi üçün FT10 layihəsinə baxın və mövcud sisteminiz üçün sahiblik, SLA və reliz risklərini müzakirə etmək üçün konsultasiya istəyin.