Köhnəlmiş sistemin miqrasiyasına başlamazdan əvvəl hər bir CTO-nun cavablandırmalı olduğu 5 sual

Köhnəlmiş sistemin miqrasiyası başlamazdan əvvəl rəhbərlik beş suala sənədləşdirilmiş cavab tapmalıdır: mövcud sistemin ölçülə bilən xərci, məlumatların miqrasiyası strategiyası və ona cavabdeh şəxs, köhnə və yeni sistemləri paralel işlətmək imkanı, yoxlanılmış geriyə dönüş planı və real səlahiyyətə malik icraçı sponsor. Bu cavablar yoxdursa, təşkilat miqrasiyaya hazır deyil. Planlaşdırma mərhələsində dayanmaq icranın ortasında dayanmaqdan qat-qat ucuz başa gəlir.

Köhnəlmiş korporativ sistemin əvəzlənməsi təşkilatın həyata keçirə biləcəyi ən riskli texniki əməliyyatlardan biridir. Sıfırdan yeni tətbiq qurmaqdan fərqli olaraq, miqrasiya uçuşda olan təyyarəni havada ikən sökmək deməkdir.

Köhnəlmiş sistem istismarda qaldığı hər ay pul aparır: yamaq xarakterli düzəlişlər, dayanmalar və dəstəkləyə bilmədiyi funksiyalar. Miqrasiya isə biznesin üzərində işlədiyi sistemi elə biznes onun üzərində işləyərkən əvəz edir.

Bu, paradoks yaradır: köhnəlmiş sistemi saxlamaq maliyyə baxımından davamlı deyil, lakin ondan imtina edib miqrasiya etmək nəhəng risk daşıyır. Bu riski azaltmaq üçün rəhbərlik diqqətini yeni sistemin nə edəcəyindən keçidin reallıqla toqquşmadan necə çıxacağına yönəltməlidir.

1. Mövcud sistemin ölçülə bilən xərci nə qədərdir?

«Köhnədir və ləng işləyir» arqumenti bu miqyasda miqrasiya üçün biznes əsaslandırması deyil. Problemi rəqəmlərlə ifadə etməlisiniz:

• Hər ay sistemə yamaq vurmağa neçə mühəndis saatı sərf olunur?
• Son 12 ayda sistem dayanmalarının maliyyə xərci nə qədərdir?
• Köhnəlmiş arxitektura dəstəkləyə bilmədiyi üçün neçə yeni funksiya sorğusu bloklanıb?

Hərəkətsizliyin bədəlini dəqiq məbləğlə ifadə edə bilməsəniz, çətinliklər yarananda miqrasiya büdcəsini müdafiə etmək üçün lazımi təsir gücünüz olmayacaq.

2. Məlumatların miqrasiyası strategiyanız nədir və ona kim cavabdehdir?

Köhnəlmiş sistemlər onilliklər boyu sənədləşdirilməmiş verilənlər bazası sxemi dəyişiklikləri, sahibsiz cədvəllər və zədələnmiş qeydlərlə xarakterizə olunur. Yeni sistem isə təmiz, normallaşdırılmış məlumatlar tələb edir.

• Birdəfəlik (hər şeyi bir həftəsonu ərzində köçürməklə), yoxsa mərhələli miqrasiya həyata keçirirsiniz?
• Məlumatların təmizlənməsi və struktur uyğunlaşdırılmasına kim cavabdehdir?
• Köçürmə pəncərəsi zamanı baş verən aktiv tranzaksiyaları necə emal edirsiniz?

Əgər məlumat strategiyası sonradan yada düşən və kiçik verilənlər bazası administratoruna həvalə edilən məsələdirsə, miqrasiya dalana dirənəcək.

3. Köhnə və yeni sistemləri paralel işlədə bilərsinizmi?

Ən yüksək riskli yanaşma cümə günü köhnə sistemi söndürüb bazar ertəsi yenisini işə salmaqdır. Proqnozlaşdırıla bilən miqrasiyalarda «Strangler Fig» şablonundan istifadə olunur: köhnəlmiş sistemin qarşısına API şlüzü qoyulur, yeni sistem hissə-hissə qurulur və trafik tədricən yeni sistemə yönləndirilir, qalan hissəyə isə köhnəlmiş tətbiq xidmət göstərməyə davam edir (Microsoft Azure Architecture Center). Arxitekturanız hər iki sistemin eyni vaxtda işləməsini dəstəkləmirsə, üzərinizə lazımsız risk götürürsünüz.

4. Yoxlanılmış geriyə dönüş planınız varmı?

Fərz edin ki, yerləşdirmə uğursuz olacaq. Yeni sistemə keçsəniz və o, növbəti səhər işçi yük altında çökərsə — köhnəlmiş sistemə qayıtmaq üçün dəqiq protokol nədir?

Geriyə dönüş planı nəzəri olmur. O, sənədləşdirilməli və icrası üçün tələb olunan vaxt hesablanmalıdır. Əgər geriyə qayıtmaq 50,000 verilənlər bazası tranzaksiyasını əllə ləğv etməyi tələb edirsə, sizin geriyə dönüş planınız yoxdur — fəlakət ssenariniz var.

5. Daxili sponsorlarınız kimlərdir və onların səlahiyyəti nədir?

Köhnəlmiş sistemlərin miqrasiyasını təkcə texnologiya deyil, daxili siyasət də uğursuzluğa uğradır. İstifadəçilər dəyişikliyə müqavimət göstərirlər. Yeni sistem işə düşəndə, hətta əvvəlkindən qat-qat üstün olsa belə, əməkdaşlar şikayət edəcəklər, çünki bu onların vərdiş etdiyi iş mexanikasını pozur.

Əgər orta həlqə rəhbərliyinə prosesdən kənarda qalmağa və ya yeni sistemin eynilə köhnəsi kimi işləməsi üçün sonsuz fərdiləşdirmələr tələb etməyə icazə verilərsə, layihə iflasa uğrayacaq. Tətbiqi məcburi etmək və funksionallığın nəzarətsiz şişməsinə «yox» demək səlahiyyəti olan C-level səviyyəli rəhbər sponsorunuz olmalıdır.

Hər 5 suala cavab verə bilmirsinizsə, nə etməlisiniz?

Bu suallara sənədləşdirilmiş sübutlarla cavab verə bilmirsinizsə, miqrasiyaya hazır deyilsiniz. Zəif planlaşdırılmış miqrasiyanı planlaşdırma mərhələsində dayandırmaq siyasi kapital itkisinə başa gəlir. Onu icranın yarı yolunda dayandırmaq isə həm pul, həm də biznesin növbəti cəhdə olan inamı baxımından qat-qat baha başa gəlir.

Tez-tez Verilən Suallar

Köhnəlmiş sistemin miqrasiyası niyə bu qədər risklidir?

Köhnə sistem əvəzlənərkən biznes həmin sistem üzərində işləməyə davam edir. Xəta təkcə yeni layihəyə deyil, gündəlik əməliyyatlara da təsir göstərir. Bu, uçuş zamanı təyyarəni təmir etməyə bənzəyir.

Hər şeyi bir anda dəyişmədən miqrasiyanı necə həyata keçirmək olar?

Strangler Fig yanaşmasından istifadə edin. Köhnəlmiş sistemin qarşısında API şlüzü qurulur, yeni sistem hissə-hissə yaradılır və trafik tədricən ora yönləndirilir. Keçid tam başa çatana qədər qalan yükü köhnəlmiş tətbiq daşıyır.

Geriyə dönüş planını real edən nədir?

Real plan sənədləşdirilir və onun icrası üçün tələb olunan vaxt əvvəlcədən hesablanır. Əgər əvvəlki vəziyyətə qayıtmaq çox sayda verilənlər bazası əməliyyatını əllə ləğv etməyi tələb edirsə, bu, plan deyil, fəlakət ssenarisidir. Yerləşdirmənin uğursuz ola biləcəyini nəzərə alın və geriyə dönüş üçün dəqiq addımları müəyyən edin.

Miqrasiyanın sponsoru kim olmalıdır?

Yuxarı rəhbərlik səviyyəli icraçı sponsor. Bu şəxsin yeni sistemin tətbiqini məcburi etmək və funksionallığın nəzarətsiz genişlənməsinə yox demək səlahiyyəti olmalıdır. Bu olmasa, orta həlqə rəhbərləri keçiddən yayına və ya sonsuz fərdi dəyişikliklər tələb edə bilər ki, nəticədə layihə uğursuzluğa düçar olar.