Buraxılışdan sonra proqram təminatına dəstək: texniki xidmət nəyi əhatə edir

Buraxılışdan sonra proqram təminatına dəstək tətbiqinizin sabit, təhlükəsiz və bərpa oluna bilən qalmasını təmin edir. Buraya asılılıqların yenilənməsi və təhlükəsizlik yamaqları, fasiləsiz işləmənin monitorinqi, xətaların aradan qaldırılması və verilənlər bazasına qulluq daxildir. Yeni funksiyalar bu xidmətə daxil deyil və ayrıca həcmi müəyyən edilmiş layihə kimi icra olunmalıdır; dəstək xidməti isə insident qaydaları, bərpa testləri və hesab mülkiyyəti müqavilədə yazılı şəkildə təsbit edildikdə ən yaxşı nəticəni verir.

Proqram məhsulunun buraxılışı mühüm mərhələdir, lakin canlı istismar fərqli çətinliklər yaradır. Tətbiqlər asılılıqların köhnəldiyi, xarici API-lərin dəyişdiyi və infrastrukturun müntəzəm nəzarət tələb etdiyi dəyişkən mühitdə işləyir. Strukturlaşdırılmış texniki xidmət müqaviləsi olmadıqda texniki borc səssizcə yığılır və qarşısı alına bilən bir qüsur biznes əməliyyatlarını dayandırana qədər davam edir.

Proqram təminatına texniki xidmətin əsas kateqoriyaları hansılardır?

Proqram təminatına texniki xidmət tək bir təkrarlanan tapşırıq deyil. Effektiv dəstək sabitliyi qorumaq üçün texniki öhdəlikləri ayrı-ayrı əməliyyat istiqamətlərinə bölür.

Birinci istiqamət təhlükəsizlik və asılılıqların idarə olunmasıdır. İşlək tətbiq çox vaxt bir sıra üçüncü tərəf kitabxanalarından, paketlərindən və freymvorklarından asılı olur. Sonatype korporativ proqram təminatında asılılıqların yenilənməsi vərdişlərini qiymətləndirib. Paketlərin 99%-dən çoxunun yenilənmiş versiyası mövcud olsa da, tətbiq asılılıqlarının 80%-i bir ildən artıq müddətdə yenilənməmiş qalır (Sonatype, 2024). Asılılıqların müntəzəm yenilənməsi məlum boşluqların hücumçular tərəfindən istismar edilməzdən əvvəl aradan qaldırılmasını təmin edir.

İkinci istiqamət fasiləsiz işləmə və sistem monitorinqidir. Avtomatlaşdırılmış yoxlamalar server resurslarının sərfiyyatını, tətbiqin gecikmə müddətini, xəta jurnallarını və SSL sertifikatlarının bitmə tarixini izləyir. Xəbərdarlıqlar resursların tükənməsi xidmətin tam dayanmasına səbəb olmazdan əvvəl texniki komandanı məlumatlandırır.

Üçüncü istiqamət qüsurların aradan qaldırılmasını və xətaların düzəldilməsini əhatə edir. İstifadəçilər gözlənilməz kənar hallarla və ya sistem nasazlıqları ilə qarşılaşdıqda mühəndislər problemi təcrid edir, onu sınaq mühitində təkrarlayır və yoxlanılmış düzəlişi tətbiq edirlər.

Dördüncü istiqamət verilənlər bazasına planlı texniki xidməti və məhsuldarlığın qorunmasını əhatə edir. Zaman keçdikcə verilənlər bazasında köhnəlmiş qeydlər yığılır, fraqmentasiya artır və sorğuların icra sürəti aşağı düşür. Müntəzəm texniki xidmət indeksləri təmizləyir, sorğuları optimallaşdırır və müvəqqəti yaddaşı boşaldır. Nəzarətsiz qalan geriləmə köhnəlmiş sistemlərin modernləşdirilməsi üzrə bələdçimizdə təsvir olunan sistem aşınmasına gətirib çıxarır.

Texniki xidmətlə ayrıca layihə arasındakı sərhəd haradan keçir?

Proqram təminatı dəstəyində mübahisələrin geniş yayılmış səbəbi cari texniki xidmətlə yeni proqram təminatının tərtibatı arasındakı qarışıqlıqdır. Dəstək mövcud funksionallığın nəzərdə tutulduğu kimi işləməsini təmin edir. O, yeni biznes imkanlarının yaradılmasını maliyyələşdirmir.

Texniki xidmət əsas sistem axınlarını dəyişdirməyən kiçik əməliyyat düzəlişlərini əhatə edir. Bunlara mətnlərin yenilənməsi, maket üslubunun tənzimlənməsi, e-poçt bildiriş mətninin dəyişdirilməsi və ya mövcud daxiletmə sahəsində yoxlama qaydalarının yenilənməsi daxildir. Bu tapşırıqlar az əmək tələb edir və cari dəstək çərçivəsinə təbii şəkildə uyğun gəlir.

Əksinə, yeni funksiyalar ayrıca layihəyə aiddir. Ödəniş şlüzünün əlavə edilməsi, istifadəçi rollarının idarəetmə sisteminin qurulması və ya hesabat panelinin yaradılması tətbiqin arxitekturasını dəyişdirir. Yeni funksiyaların tərtibatını dəstək müqaviləsinə sığışdırmaq cəhdi gecikmiş son tarixlərə və texniki xidmətin diqqətdən kənarda qalmasına səbəb olur.

Hər bir əhəmiyyətli təkmilləşdirmə arxitektura layihələndirməsi və iş həcminin strukturlaşdırılmış müəyyənləşdirilməsini tələb edir. Qurmadan əvvəl layihələndirmə bələdçimizdə qeyd edildiyi kimi, texniki tələblərin yazılı şəkildə müəyyənləşdirilməsi layihə büdcəsini qoruyur. Tətbiqdə arxitekturanın miqyaslanma əlamətləri görünəndə ayrıca tərtibat sprinti təmiz texniki icranı təmin edir.

İnsident protokolları niyə yazılı şəkildə müəyyənləşdirilməlidir?

Dayanma baş verdikdə komandalar məsuliyyət bölgüsü ilə bağlı qarışıqlığa yol verə bilməz. Aydın dəstək müqaviləsi problemlər yaranmazdan əvvəl insident protokollarını yazılı şəkildə müəyyən edir.

Müqavilə ağırlıq dərəcələrinin dəqiq təriflərini müəyyənləşdirməlidir:

• Ağırlıq dərəcəsi 1 (kritik): İşlək sistem dayanıb, əsas biznes əməliyyatları bloklanıb və ya kritik məlumat sızması mövcuddur.
• Ağırlıq dərəcəsi 2 (ciddi): Əsas funksiya pozulub və dərhal dolama həll yoxdur, lakin tətbiq əlçatan olaraq qalır.
• Ağırlıq dərəcəsi 3 (kiçik): Qeyri-kritik qüsur mövcuddur, lakin istifadəçilər əsas iş axınlarını alternativ addımla tamamlaya bilirlər.
• Ağırlıq dərəcəsi 4 (aşağı): Kiçik vizual qüsurlar, sənədləşmə xətaları və ya təcili olmayan texniki suallar.

Aydın insident prosesləri etibarlılığa birbaşa təsir göstərir. Uptime Institute rəqəmsal infrastruktur kəsintilərinə dair araşdırmasında əməliyyat nasazlıqlarını izləyib. 2024-cü ildə IT və şəbəkə problemlərindən qaynaqlanan dayanmalar artaraq ciddi təsirli kəsintilərin 23%-ni təşkil edib (Uptime Institute, 2025).

Yazılı müqavilə həmçinin kommunikasiya kanallarını və qeydiyyat standartlarını müəyyən edir. Fövqəladə problemlər heç vaxt qeydiyyata alınmayan ani mesajlardan asılı olmamalıdır. Müraciətlər dəqiq vaxt qeydləri, təyin edilmiş növbətçi əlaqə şəxsləri və müəyyən olunmuş eskalasiya marşrutları ilə mərkəzləşdirilmiş sorğu sistemində qeydə alınmalıdır. Konkret reaksiya müddətləri və xidmət saatları ümumi vədlər kimi deyil, yazılı müqavilədə müəyyən edilir.

Ehtiyat nüsxələrin bərpa testləri niyə vacibdir?

Bir çox komandanın ehtiyat nüsxə cədvəli var. Lakin ehtiyat nüsxənin həqiqətən bərpa edilə bildiyini yoxlayanlar daha azdır. Bərpa edilə bilməyən ehtiyat nüsxə faylı məlumat itkisinə qarşı sıfır qoruma təmin edir.

Ehtiyat nüsxə faylları bir neçə səbəbdən yararsız ola bilər. Verilənlər bazasının çıxarışları gizli zədələnmə ilə tamamlana bilər, disk şifrələmə açarları dəyişə bilər və ya avtomatlaşdırılmış skriptlər administratora xəbərdarlıq etmədən sıradan çıxa bilər. Əgər komanda bu qüsurları aktiv qəza zamanı aşkar edərsə, bərpa mümkünsüz olur.

Etibarlı proses yazılı şəkildə razılaşdırılmış cədvəl üzrə avtomatlaşdırılmış və ayrı məkanda saxlanılan ehtiyat nüsxələr tələb edir. Daha vacibi isə təcrid olunmuş sınaq mühitlərində aparılan və sənədləşdirilən bərpa testləridir. Mühəndis komandası verilənlər bazasını bərpa edir, məlumatların bütövlüyünü yoxlayır və ümumi bərpa müddətini ölçür.

Bizim dəstək və texniki xidmətimiz sistemi təhvil alarkən ehtiyat nüsxə cədvəlini yoxlayır və bərpa testi keçirir. Bərpa prosedurlarının əvvəlcədən yoxlanılması avadanlıq nasazlığı, fidyə proqramı hücumları və ya məlumatların təsadüfən silinməsi zamanı biznesin fasiləsizliyini təmin edir.

Hansı hesablar müştərinin mülkiyyətində olmalıdır?

Sağlam müştəri-podratçı münasibətləri texniki şəffaflıq və müstəqil giriş imkanı tələb edir. Müştərilər heç vaxt öz rəqəmsal infrastrukturlarından təcrid olunmamalıdırlar.

Tərtibat üzrə tərəfdaşınıza yeniləmələri yerləşdirmək və insidentləri həll etmək üçün inzibati giriş lazımdır. Bununla belə, hüquqi və kommersiya hesabları sizin təşkilatınızın adına qalmalıdır.

Texniki stekiniz üzrə hesab mülkiyyətini yoxlamaq üçün bu siyahıdan istifadə edin:

• Domen və DNS. Tələb olunan sahib: müştəri təşkilatı. Müştərinin nəzarət etməli olduğu sahə: domen qeydiyyatçısına və əsas DNS qeydlərinə birbaşa mülkiyyət.
• Bulud hostinqi. Tələb olunan sahib: müştəri təşkilatı. Müştərinin nəzarət etməli olduğu sahə: AWS, Google Cloud, Azure və ya VPS provayderində əsas ödəniş hesabı.
• Mənbə kodu. Tələb olunan sahib: müştəri təşkilatı. Müştərinin nəzarət etməli olduğu sahə: tam inzibati hüquqlara malik, təşkilata məxsus GitHub, GitLab və ya Bitbucket repozitoriyası.
• Giriş məlumatları saxlancı. Tələb olunan sahib: müştəri təşkilatı. Müştərinin nəzarət etməli olduğu sahə: işlək açarları və mühit sirlərini saxlayan mərkəzləşdirilmiş parol meneceri.
• Üçüncü tərəf xidmətləri. Tələb olunan sahib: müştəri təşkilatı. Müştərinin nəzarət etməli olduğu sahə: ödəniş şlüzləri, tranzaksiya e-poçtu, SMS və analitika alətləri üçün birbaşa hesablar.
• SSL / TLS sertifikatları. Tələb olunan sahib: müştəri təşkilatı. Müştərinin nəzarət etməli olduğu sahə: sertifikatların yaradılması və avtomatlaşdırılmış yenilənmə axınları üzərində inzibati nəzarət.

Bu hesablara sahib olmaq sizə podratçını sərbəst dəyişmək imkanı verir. Əgər nə vaxtsa agentliyi dəyişsəniz və ya daxili tərtibatçılar işə götürsəniz, hesabların ötürülməsi üçün danışıqlar aparmadan giriş tokenlərini yenidən təyin edə bilərsiniz.

Buraxılışdan sonrakı əməliyyatları necə qurmaq lazımdır?

Proqram təminatına texniki xidmət ikinci dərəcəli məsələ deyil, əməliyyat intizamıdır.

Bizim dəstək əməkdaşlığımız texniki auditlə başlayır. Audit asılılıqları siyahıya alır, hostinq konfiqurasiyalarını nəzərdən keçirir, ehtiyat nüsxələrin bütövlüyünü yoxlayır və istismar müddəti bitmiş komponentləri müəyyən edir. Bu ilkin baza texniki xidmət müqaviləsinin köhnəlmiş sənədlərə deyil, proqram təminatınızın real vəziyyətinə əsaslanmasını təmin edir.

Mövcud texniki xidmət əhatənizi bu gün nəzərdən keçirin. Təşkilatınızın repozitoriyalara və hostinq hesablarına sahib olduğunu təsdiqləyin, ehtiyat nüsxələrin fəal şəkildə sınaqdan keçirildiyini yoxlayın və insident protokollarının sənədləşdirildiyinə əmin olun. Əgər sisteminizdə strukturlaşdırılmış texniki xidmət müqaviləsi yoxdursa, əməliyyat təməlinizi qorumaq üçün texniki audit sifariş edin.

Tez-tez Verilən Suallar

Proqram təminatına texniki xidmət nəyi əhatə edir?

Texniki xidmət təhlükəsizlik və asılılıqların idarə olunmasını, sistemin və fasiləsiz işləmənin monitorinqini, qüsurların aradan qaldırılmasını və verilənlər bazasına qulluğu əhatə edir. O, mövcud funksionallığın layihələndirildiyi kimi işləməsini təmin edir. Mətnlərin yenilənməsi və ya yoxlama qaydasının dəyişdirilməsi kimi kiçik əməliyyat dəyişiklikləri də buraya daxildir.

Dəstək müqaviləsinə nələr daxil deyil?

Yeni funksiyalar buraya daxil deyil. Ödəniş şlüzü, istifadəçi rolları sistemi və ya hesabat paneli arxitekturanı dəyişir, buna görə də öz həcmi olan ayrıca layihə çərçivəsində icra edilməlidir. Bu iki istiqaməti qarışdırmaq son tarixlərin gecikməsinə və cari texniki xidmətin axsamasına gətirib çıxarır.

Ehtiyat nüsxənin bərpa oluna bildiyini niyə yoxlamaq lazımdır?

Bərpa edilə bilməyən ehtiyat nüsxə məlumat itkisindən qorumur. Məsələn, zədələnmiş çıxarış faylları və ya dəyişdirilmiş şifrələmə açarları səbəbindən ehtiyat nüsxələr səssizcə sıradan çıxa bilər. Təcrid olunmuş sınaq mühitində aparılan bərpa testi real insident baş verməzdən əvvəl bərpa prosesinin işlək olduğunu təsdiqləyir.

Webiland dəstək əməkdaşlığına necə başlayır?

Dəstək texniki auditlə başlayır. Audit zamanı asılılıqlar inventarizasiya edilir, hostinq konfiqurasiyaları nəzərdən keçirilir, ehtiyat nüsxələrin bütövlüyü yoxlanılır və istismar müddəti bitmiş komponentlər müəyyən edilir. Bundan sonra texniki xidmət müqaviləsi proqram təminatınızın real vəziyyətini əks etdirir.