Mobil məhsul yaratmaq artıq yalnız istifadəçi ekranlarının dizaynı və tətbiqin mağazaya yerləşdirilməsi demək deyil. Tətbiqin arxasında işləyən serverlər, məlumat bazası, fayl saxlanması, bildirişlər, inteqrasiyalar və təhlükəsizlik mexanizmləri məhsulun gündəlik fəaliyyətinə birbaşa təsir edir. Buna görə mobil tətbiq hazırlanması prosesində bulud infrastrukturu barədə qərarlar ilkin planlamanın ayrılmaz hissəsi olmalıdır.
Bu mövzunun aktuallığı qlobal bulud bazarının miqyasından da görünür. Microsoft yaxın hesabatında Azure-un rüblük gəlirini ilk dəfə ayrıca dollarla açıqlayaraq 33,2 milyard dollar göstərib. Bu rəqəm Azərbaycan şirkətinin eyni ölçüdə infrastruktur qurmalı olduğu anlamına gəlmir. Lakin o, onlayn xidmətlərin arxa planında dayanan hesablama və məlumat infrastrukturunun artıq əsas biznes resurslarından birinə çevrildiyini göstərir.
Yerli biznes üçün düzgün sual “ən mürəkkəb texnologiyanı necə seçək?” deyil. Daha faydalı sual budur: tətbiqin ilk altı-on iki ayda həll edəcəyi işləri təhlükəsiz, izlənilə bilən və idarəolunan xərclə necə yerinə yetirək?
Mobil tətbiqdə buludun faktiki rolu nədir?
İstifadəçi tətbiqdə sifariş verdikdə, profilini yenilədikdə, sənəd yüklədikdə və ya bildiriş aldıqda prosesin mühüm hissəsi mobil cihazdan kənarda baş verir. Bulud infrastrukturu bu əməliyyatların məlumatlarını qəbul edir, emal edir, saxlayır və lazım olduqda başqa sistemlərə ötürür.
Məsələn, pərakəndə satış tətbiqi məhsul qalığını, qiymətləri, sifariş statuslarını və müştəri məlumatlarını arxa sistemdən alır. Logistika tətbiqi əməkdaşın lokasiyasını, tapşırıq statusunu və çatdırılma sübutunu emal edə bilər. Korporativ tətbiq isə məzuniyyət sorğularını, təsdiq mərhələlərini və sənədləri şirkətin mövcud proqramlarına bağlaya bilər. Hər ssenaridə əsas məsələ məlumatın harada yaranması, hansı sistemdən keçməsi və kim tərəfindən idarə olunmasıdır.
- API qatı: mobil tətbiqlə arxa sistemlər arasında məlumat mübadiləsini təşkil edir.
- Məlumat bazası: istifadəçi, sifariş, əməliyyat və digər biznes məlumatlarını saxlayır.
- Fayl saxlanması: şəkil, qəbz, müqavilə və digər sənədləri idarə edir.
- Bildiriş xidməti: sifariş dəyişikliyi, xatırlatma və əməliyyat xəbərdarlıqlarını çatdırır.
- Monitorinq və qeydlər: xətaları, gecikmələri və şübhəli davranışları izləməyə kömək edir.
Bu komponentlərin hamısını ilk gündən maksimum miqyasda qurmaq vacib deyil. Ancaq tətbiq böyüdükdə nəyi dəyişmək lazım olacağını əvvəlcədən bilmək vacibdir.
İnfrastrukturu istifadə ssenarisindən başlayaraq planlayın
Texniki qərarları ekran siyahısından deyil, istifadə ssenarilərindən çıxarmaq daha sağlam yanaşmadır. Bunun üçün məhsul sahibi və texniki komanda əvvəlcə əsas əməliyyatları sadalamalıdır: istifadəçi qeydiyyatı, giriş, məhsul axtarışı, sifariş, ödənişə yönləndirmə, sənəd yükləmə, yer məlumatı, hesabat və s.
Sonra hər əməliyyat üçün aşağıdakı suallara cavab verilməlidir:
- Bu məlumat tətbiqdə yaradılır, yoxsa mövcud korporativ sistemdən alınır?
- Əməliyyat dərhal cavab tələb edir, yoxsa növbəyə alınaraq sonradan emal oluna bilər?
- Məlumatın itməsi və ya gecikməsi biznes prosesinə necə təsir edir?
- Bu funksiyadan eyni anda neçə əməkdaş və ya müştərinin istifadə etməsi gözlənilir?
- İnternet zəif olduqda tətbiq hansı funksiyaları davam etdirə bilməlidir?
Məsələn, sahə əməkdaşları üçün tətbiqdə internetin qeyri-sabit olması nəzərə alınmalıdır. Forma məlumatını cihazda müvəqqəti saxlamaq, bağlantı bərpa ediləndə sinxronlaşdırmaq və təkrar göndərişlərin qarşısını almaq lazım gələ bilər. Əksinə, yalnız ofis daxili istifadə üçün hazırlanan sadə təsdiq tətbiqində bu qədər mürəkkəb sinxronizasiya tələb olunmaya bilər.
Xərcləri yalnız server qiyməti kimi hesablamayın
Bulud xərci çox vaxt “server aylıq neçəyə başa gələcək?” sualına endirilir. Halbuki ümumi xərc istifadə davranışı və texniki seçimlərin cəmindən yaranır. Fayl yükləmələri, məlumatın ötürülməsi, sorğuların sayı, ehtiyat nüsxələr, bildirişlər, inteqrasiyalar, monitorinq və texniki dəstək ayrı-ayrılıqda kiçik görünsə də, birlikdə əhəmiyyətli ola bilər.
Xərcləri proqnozlaşdırmaq üçün ən faydalı üsul istifadə vahidini müəyyənləşdirməkdir. Məsələn, bir aktiv istifadəçi ayda neçə sifariş yaradır, bir sifariş neçə sorğu göndərir, orta hesabla neçə şəkil əlavə olunur və bir sənəd nə qədər saxlanılır? Bu suallar dəqiq maliyyə proqnozu verməsə də, hansı funksiyanın xərc sürücüsü olduğunu üzə çıxarır.
Xərc nəzarəti üçün praktik mexanizmlər
- İnkişaf, sınaq və canlı mühitləri bir-birindən ayırın ki, test fəaliyyəti real xidmətə təsir etməsin.
- Fayllar üçün ölçü, format və yükləmə limiti təyin edin.
- İstifadə olunmayan sınaq resurslarının bağlanması üçün məsul şəxs və yoxlama qaydası müəyyən edin.
- Əsas göstəricilər üzrə xəbərdarlıqlar qurun: xəta sayı, cavab müddəti, qeyri-adi sorğu artımı və saxlama həcmi.
- Yeni funksiyanı bütün istifadəçilərə eyni anda açmaq əvəzinə, mərhələli tətbiq imkanını nəzərdən keçirin.
Bu yanaşma xərci sıfırlamır, lakin gözlənilməz artımı erkən görməyə və qərarları faktlara əsasən verməyə imkan yaradır.
Məlumat təhlükəsizliyi arxitekturanın başlanğıc nöqtəsidir
Müştəri, əməkdaş və əməliyyat məlumatları ilə işləyən tətbiqdə təhlükəsizlik sonradan əlavə olunan funksiya olmamalıdır. Xüsusilə giriş məlumatları, şəxsi məlumatlar, sənədlər və maliyyə əməliyyatlarına aid məlumatlar üçün giriş səlahiyyətləri aydın bölünməlidir.
Praktik minimum aşağıdakı elementləri əhatə edir:
- istifadəçi rolları və hər rolun görə bildiyi məlumatların dəqiq tərifi;
- məlumat ötürülməsi və saxlanması zamanı müvafiq qoruma tədbirləri;
- parolların və giriş açarlarının mənbə kodunda saxlanmaması;
- vacib əməliyyatlar üzrə audit qeydləri;
- ehtiyat nüsxə və bərpa prosedurunun sınaqdan keçirilməsi;
- istifadəçi cihazı itirildikdə sessiyanın idarə olunması.
Təhlükəsizlik həm də biznes prosesidir. Məsələn, işdən ayrılan əməkdaşın girişinin nə vaxt bağlanacağı, hansı şəxsin yeni səlahiyyət təsdiqləyəcəyi və şübhəli əməliyyatın kimə bildirilməsi əvvəlcədən müəyyən edilməlidir.
MiQyaslanma üçün sadə, dəyişdirilə bilən başlanğıc seçin
Bir çox layihədə iki riskdən biri yaranır: ya başlanğıc üçün həddindən artıq mürəkkəb sistem qurulur, ya da sürətli başlamaq naminə gələcəkdə dəyişdirilməsi çətin olan struktur seçilir. Sağlam tarazlıq əsas modulların sərhədlərini aydın saxlamaqdan keçir.
Məsələn, istifadəçi idarəetməsi, sifariş məntiqi, fayl yükləmə və bildirişlər ayrı məsuliyyət sahələri kimi qurulduqda, gələcək dəyişikliklər daha idarəolunan olur. Eyni zamanda, ilk versiyada real ehtiyac olmayan avtomatlaşdırmaları və nadir istifadə ediləcək funksiyaları sonraya saxlamaq həm vaxtı, həm də əməliyyat yükünü azalda bilər.
Mobil tətbiq hazırlanması üçün texniki tapşırıqda yalnız funksiyalar deyil, performans gözləntisi, məlumatın saxlanma müddəti, inteqrasiya nöqtələri, cavabdeh tərəflər və insident zamanı fəaliyyət qaydası da qeyd edilməlidir. Bu sənəd biznes və inkişaf komandası arasında anlaşılmazlıqları xeyli azaldır.
Layihəyə başlamazdan əvvəl veriləcək 6 sual
- Tətbiqin ilk versiyasında istifadəçi üçün ən vacib üç əməliyyat hansıdır?
- Hansı məlumatlar mövcud ERP, CRM və ya digər daxili sistemlərdən gələcək?
- İnternet kəsildikdə hansı işlər dayanacaq, hansılar cihazda davam etməlidir?
- İstifadəçi və əməkdaş səlahiyyətləri necə fərqlənəcək?
- İstifadə artdıqda ilk məhdudiyyətin harada yaranması ehtimal edilir: sorğular, fayllar, inteqrasiya, yoxsa dəstək?
- Canlı istifadədən sonra xətaları, performansı və istifadə davranışını kim izləyəcək?
Bu sualların cavabları aydın olduqda texniki həllin həcmini, mərhələlərini və prioritetlərini daha düzgün müəyyənləşdirmək mümkündür. Tətbiq ideyasını biznes prosesinə, istifadəçi ssenarilərinə və davamlı əməliyyata bağlamaq istəyən şirkətlər JedanSoft-un mobil tətbiq hazırlanması xidməti çərçivəsində bu tələbləri layihənin ilkin mərhələsində strukturlaşdıra bilər.
Yaxşı mobil məhsulun arxitekturası ən çox funksiyanı deyil, biznesin bu gün ehtiyac duyduğu və sabah dəyişdirə biləcəyi sistemi hədəfləyir.
Tez-tez verilən suallar
Mobil tətbiq üçün bulud infrastrukturu nə vaxt planlanmalıdır?
İlkin tələb toplama mərhələsində. Əsas istifadə ssenariləri, məlumat mənbələri, inteqrasiyalar və gözlənilən istifadəçi yükü müəyyən ediləndə infrastruktur ehtiyacları daha aydın görünür.
Kiçik biznes tətbiqinə ayrıca arxa sistem lazımdırmı?
Bu, funksiyalardan asılıdır. İstifadəçi hesabları, sifarişlər, məlumat sinxronizasiyası və ya daxili sistemlərlə əlaqə varsa, adətən idarə olunan arxa sistem tələb olunur.
Bulud xərclərini necə nəzarətdə saxlamaq olar?
İstifadə vahidlərini izləmək, sınaq və canlı mühitləri ayırmaq, fayl limitləri qoymaq, istifadə olunmayan resursları bağlamaq və xərc artımı üçün xəbərdarlıqlar qurmaq faydalıdır.
Növbəti addım
mobil tətbiq hazırlanması ilə bağlı layihənizi Veb saytların hazırlanması komandası ilə planlaşdırın. Tələbinizi dəqiqləşdirmək üçün JedanSoft-a müraciət edin.
