Yoxsa bu mümkündür? Əlbəttə ki, SAP sistemlərinin köçürülməsi mürəkkəb və əziyyətli bir prosesdir, onun uğuru bütün iştirakçıların yaxşı əlaqələndirilmiş işini tələb edir. Və miqrasiya qısa müddətdə həyata keçirilərsə, iş daha da mürəkkəbləşir. Hər kəs bunu etməyə qərar vermir. Bunun bir neçə səbəbi ola bilər. Məsələn, prosesin özü uzun və təşkilati cəhətdən mürəkkəbdir. Üstəlik, planlaşdırılmamış sistemin dayanması riski var. Yaxud müştərilər belə bir əməliyyat keçirərək, sərf etdikləri zəhmətə uyğun fayda alacaqlarına əmin deyillər. Bununla belə, istisnalar var.
Aşağıda biz müştərilərin SAP sistemlərinin köçürülməsi və saxlanması prosesində qarşılaşdıqları çətinliklərdən danışacağıq, stereotiplərin niyə həmişə reallığa uyğun gəlmədiyini müzakirə edəcəyik və müştərinin sistemlərini bir sistemə necə köçürməyi bacardığımıza dair nümunə araşdırmasını paylaşacağıq. üç aydan çox müddətdə yeni infrastruktur.
SAP sistemlərinin hostinqi
Cəmi beş il əvvəl müştərilərin SAP proqramları üçün hostinq resurslarından kütləvi şəkildə istifadə etməyə başlayacağını təsəvvür etmək çətin idi. Əksər hallarda onlar yerində həyata keçirilirdi. Bununla belə, autsorsing modellərinin və bulud xidmətləri bazarının inkişafı ilə müştərilərin dünyagörüşü dəyişməyə başladı. SAP üçün buludun lehinə seçimə təsir edən arqumentlər hansılardır?
- SAP-ı yenicə tətbiq etməyi planlaşdıran yeni başlayanlar üçün bulud infrastrukturu demək olar ki, standart seçimdir - resursların sistemin cari ehtiyaclarına uyğun genişlənməsi və resursları əsas olmayan səlahiyyətlərin inkişafına yönəltmək istəməməsi.
- Böyük sistem mənzərəsi olan şirkətlərdə, hosting SAP sistemlərinin köməyi ilə CIO-lar risklərin idarə edilməsinin keyfiyyətcə fərqli səviyyəsinə çatırlar, çünki Tərəfdaş SLA üçün cavabdehdir.
- Üçüncü ən ümumi arqument yüksək əlçatanlıq və DR ssenarilərini həyata keçirmək üçün infrastrukturun qurulmasının yüksək qiymətidir.
- Faktor 2027 – satıcı 2027-ci ildə köhnə sistemlərə dəstəyin bitdiyini elan etdi. Bu, verilənlər bazasını HANA-ya köçürmək deməkdir ki, bu da modernləşdirmə və yeni hesablama gücünün alınması xərclərini tələb edir.
Rusiyada SAP hosting bazarı indi kifayət qədər yetkin hesab edilə bilər. Bu isə hosting platformalarını dəyişmək istəyən müştərilər üçün geniş imkan yaradır. Bununla belə, bu cür layihələr miqrasiya prosedurunun mürəkkəbliyinə görə haqlı olaraq biznesdə narahatlıq yarada bilər. Bu, müştəriləri SAP sistemlərinin yerləşdirilməsi və saxlanmasında müstəsna səriştələrə deyil, həm də miqrasiya sahəsində uğurlu təcrübəyə malik olan xidmət təminatçılarına artan tələblər qoymağa məcbur edir.
SAP hostinqini dəyişdirməyin hansı çətinlikləri var?
Hostinqlər fərqlidir. Elan edilmiş xidmət səviyyəsinə uyğunsuzluq, kiçik mətndə qeyd-şərtlərlə çoxlu “amma” və ulduz işarələri, hostinq provayderinin məhdud resursları və imkanları, müştəri ilə ünsiyyət məsələlərində çevikliyin olmaması, bürokratiya, texniki məhdudiyyətlər, texniki dəstəyin aşağı səriştəsi mütəxəssislər, eləcə də bir çox digər nüanslar - bunlar müştərilərin öz biznes sistemlərini autsorsing infrastrukturlarında işləyərkən qarşılaşa biləcəkləri tələlərin yalnız kiçik bir hissəsidir. Çox vaxt müştəri üçün bütün bunlar kölgədə, çox səhifəlik müqavilənin cəngəlliyində qalır və xidmətlərdən istifadə prosesində ortaya çıxır.
Müştəriyə müəyyən məqamlarda bəlli olur ki, onun aldığı xidmət səviyyəsi onun gözləntilərindən uzaqdır. Bu, vəziyyəti düzəltmək üçün həll yollarının tapılması üçün bir növ katalizatordur və uğursuzluq halında problemlər həddə çatdıqda və çox ağrılı olduqda, xidmət təminatçısını dəyişdirmək istiqamətində alternativ variantları inkişaf etdirmək üçün aktiv hərəkətlərə keçirlər. .
Niyə son dəqiqəyə qədər gözləyirlər? Səbəb sadədir - müştərilər üçün sistemlərin köçürülməsi prosesi həmişə şəffaf və başa düşülən deyil. Müştəri üçün miqrasiya prosesi ilə bağlı faktiki riskləri qiymətləndirmək çətindir. Deyə bilərik ki, müştərilər üçün miqrasiya bir növ qara qutudur: qiymət, sistemin dayanma müddəti, risklər və onları necə azaltmaq aydın deyil və ümumiyyətlə qaranlıq və qorxuludur. Necə ki, alınmasa, başlar həm yuxarıda, həm də ifaçılarda yuvarlanacaq.
SAP müəssisə səviyyəli sistemdir, mürəkkəbdir və yumşaq desək, ucuz deyil. Onların həyata keçirilməsinə, dəyişdirilməsinə və saxlanmasına layiqli büdcələr xərclənir və müəssisənin ömrü onların mövcudluğundan və düzgün işləməsindən asılıdır. İndi bəzi böyük istehsalı dayandırmağın nəticələrini təsəvvür edin. Bunlar çox sayda sıfır olan rəqəmlərlə hesablana bilən maliyyə itkiləri, habelə nüfuz və digər eyni dərəcədə əhəmiyyətli risklərdir.
Müştərilərimizdən birindən SAP sistemlərinin köçürülməsi halında hər mərhələdə yarana biləcək çətinlikləri təhlil edəcəyik.
Hazırlıq və dizayn
Miqrasiya çoxlu müxtəlif hissələrdən ibarət düsturdur. Ən vaciblərindən biri isə hədəf (yeni) infrastrukturun layihələndirilməsi və hazırlanması mərhələsidir.
Sistemlərin mövcud tətbiqinə, onların arxitekturasına dalmaq lazım idi. Hədəf infrastrukturunda biz mövcud həlləri haradasa təkrarladıq, bəzi məqamlarda onları tamamladıq və təkmilləşdirdik, hardasa yenidən işlədik, səhvlərə dözümlülük və əlçatanlığı təmin etmək üçün həll yollarını düşündük və seçdik, həmçinin mümkün qədər bütün resursları birləşdirdik.
Dizayn prosesində bir çox müxtəlif məşğələlər yerinə yetirildi ki, bu da son nəticədə miqrasiya üçün mümkün qədər çox hazırlaşmağa və hər cür nüansları və tələləri nəzərə almağa imkan verdi (onlar haqqında daha sonra).
Nəticə əldə etdiyimiz məlumat mərkəzimizə əsaslanan fərdi dizayn edilmiş şəxsi bulud infrastrukturudur:
- SAP HANA üçün ayrılmış fiziki serverlər;
- Tətbiq serverləri və infrastruktur xidmətləri üçün VMware virtualizasiya platforması;
- L2 VPN üçün məlumat mərkəzləri arasında təkrarlanan rabitə kanalları;
- məhsulu və "hər şeyi" ayırmaq üçün iki əsas saxlama sistemi;
- Ayrı server, disk rəfi və lent kitabxanası olan Veritas Netbackup əsasında SRC.
Bütün bunları texniki baxımdan necə həyata keçirdik.
SAP
- Məhsuldar HANA üçün yaddaşdan səmərəli istifadə etmək üçün SAP istifadə edərək sistemli verilənlər bazası replikasiyası olmadan paylaşılan disklərdən istifadə etdik. Bütün bunlar kardiostimulyatora əsaslanan Active-Standby SUSE HAE klasterinə yığılmışdı. Bəli, bərpa müddəti replikasiya ilə müqayisədə bir qədər uzundur, lakin biz saxlama yerini yarıya qədər qənaət edirik və nəticədə müştərinin büdcəsinə qənaət edirik.
- İstehsaldan əvvəlki mühitlərdə HANA klasterlərindən imtina edildi, lakin texniki olaraq istehsal konfiqurasiyası təkrarlandı.
- Test və inkişaf mühitləri MCOS konfiqurasiyasında klasterlər olmadan daha bir neçə server arasında paylandı.
- Bütün proqram serverləri virtuallaşdırılıb və VMware-də yerləşdirilib.
Seti
- Nəzarət və istehsal şəbəkələrinin konturlarını kommutator yığınları ilə fiziki olaraq ayırdıq, məhsuldar olanları müştərinin məlumat mərkəzlərinə çevirdik.
- Böyük trafik axınlarını qarışdırmamaq üçün kifayət qədər sayda şəbəkə interfeysi quraşdırdıq.
- Saxlama sistemlərindən məlumat ötürmək üçün klassik FC SAN fabrikləri etdik.
saxlama
- SAP-nin məhsuldar və məhsuldarlıqdan əvvəlki yükü tam flaş massivində qaldı.
- Tərtibatçı test mühitləri və infrastruktur xidmətləri ayrıca hibrid massivdə yerləşdirildi.
İBS
- Veritas Netbackup istifadə edərək hazırlanmışdır.
- MCOS konfiqurasiyalarının ehtiyat nüsxəsini çıxarmaq üçün daxili skriptlərə bir az əlavə etdik.
- Biz operativ surətləri tez bərpa etmək üçün disk rəfinə qoyuruq və uzunmüddətli saxlama üçün lentlərdən istifadə edirik.
Monitorinq
- Bütün avadanlıq, OS və SAP Zabbix altında quraşdırılmışdır.
- Biz Grafana-da çoxlu faydalı tablolar topladıq.
- Xəbərdarlıq baş verdikdə, Zabbix hadisənin idarə edilməsi sistemində sorğu yarada bilər; biz bunu Jira-da tətbiq etdik. Məlumat Telegram kanalında da təkrarlanır.
Teleqram
HANA-nın ümumi sağlamlığı
SAP Tətbiq Server Vəziyyəti:
İnfrastruktur xidmətləri
- Daxili ad fəzalarına xidmət göstərmək üçün müştərinin serverləri ilə sinxronlaşdırılan DNS serverlərinin klasteri yaradıldı.
- Məlumat mübadiləsi üçün ayrıca fayl serveri yaratdıq.
- Müxtəlif konfiqurasiyaları saxlamaq üçün Gitlab əlavə edildi.
- Müxtəlif həssas məlumatlar üçün HashiCorp Vault-u götürdük.
Miqrasiya prosesi
Ümumiyyətlə, miqrasiya prosesi aşağıdakı mərhələlərdən ibarətdir:
- bütün lazımi layihə sənədlərinin hazırlanması;
- cari provayder ilə danışıqlar - təşkilati məsələlərin həlli;
- layihə üçün yeni avadanlıqların alınması, çatdırılması və quraşdırılması;
- test miqrasiyası və prosesin sazlanması;
- sistemlərin ötürülməsi, miqrasiya ilə mübarizə.
2019-cu ilin oktyabr ayının sonunda müqavilə imzaladıq, sonra arxitekturasını layihələndirdik və sifarişçi ilə razılaşdıqdan sonra lazımi avadanlıqları sifariş etdik.
Əvvəlcə diqqət etməli olduğunuz şey avadanlıqların çatdırılma müddətidir. Proqram istehsalçısının aparat platformaları üçün tələblərinə cavab verən SAP NAHA üçün sertifikatlaşdırılmış avadanlıqların çatdırılması orta hesabla 10-12 həftə çəkir. Və mövsümiliyi nəzərə alsaq (layihənin icrası məhz Yeni ilə düşürdü), bu müddət daha bir ay arta bilərdi. Müvafiq olaraq, prosesi mümkün qədər sürətləndirmək lazım idi: biz distribyutor-təchizatçı ilə işlədik və təyyarə ilə (quru və dəniz yolları əvəzinə) sürətli çatdırılma barədə razılığa gəldik.
Noyabr və dekabr ayları köçə hazırlaşmaq və bəzi avadanlığın qəbulu ilə məşğul olurdu. Hazırlığı ictimai buludumuzda sınaq skamyasında həyata keçirdik, burada bütün əsas addımları işlədik və mümkün çətinlikləri və problemləri tutduq:
- dəqiqə-dəqiqə vaxtları ilə layihə komandasının üzvləri arasında qarşılıqlı əlaqə üçün ətraflı plan hazırladı;
- verilənlər bazası və proqram serverləri üçün hədəf infrastrukturda olduğu kimi təxminən eyni şəkildə sınaq stendini qurdu;
- inteqrasiyaların işini yoxlamaq üçün lazımi rabitə kanallarını və infrastruktur xidmətlərini konfiqurasiya etdi;
- kəsilmə ssenariləri işlənib hazırlanmışdır;
- Bulud həmçinin əvvəlcədən konfiqurasiya edilmiş virtual maşın şablonlarını yaratmağa kömək etdi, biz onları sadəcə idxal etdik və hədəf mənzərəyə yerləşdirdik.
Yeni il bayramlarına az qalmış, avadanlıqların ilk partiyası bizə gəldi. Bu, bəzi sistemləri real hardware üzərində yerləşdirməyə imkan verdi. Hər şey gəlmədiyi üçün biz təchizatçı və distribyutorlarla razılaşa bildiyimiz əvəzedici avadanlıqları birləşdirdik. Biz son mərhələdə hədəf infrastrukturun qalıqlarını aldıq.
Mühəndislərimiz son tarixə çatmaq üçün Yeni il tətillərini qurban verməli və bayramların ortasında yanvarın 2-də hədəf infrastrukturun hazırlanması işinə başlamalı idilər. Bəli, bu, bəzən yanan zaman baş verir və sadəcə başqa seçim yoxdur. Müəssisənin ömrünün asılı olduğu sistemlərin fəaliyyəti təhlükə altında idi.
Miqrasiyanın ümumi qaydası belə görünürdü: birincisi, ən az kritik sistemlər (inkişaf mənzərəsi, sınaq mənzərəsi), sonra məhsuldar sistemlər. Miqrasiyanın son mərhələsi yanvarın sonu fevralın əvvəllərində baş verdi.
Miqrasiya prosesi dəqiqəyə qədər planlaşdırılmışdı. Bu, bütün tapşırıqların, tamamlanma vaxtının və məsul şəxslərin siyahısı ilə kəsilmiş plandır. Test miqrasiyasında bütün addımlar artıq işlənmişdi, ona görə də canlı miqrasiyada sadəcə olaraq plana əməl etmək və prosesi koordinasiya etmək lazım idi.
Miqrasiya bir neçə mərhələdə sistemli şəkildə həyata keçirilirdi. Hər mərhələdə iki sistem var.
Üç aylıq sprintin nəticəsi CROC məlumat mərkəzində tam işləyən sistem oldu. Ümumilikdə komanda işi sayəsində müsbət nəticə əldə edilib, prosesdə bütün iştirakçıların töhfəsi və fədakarlığı maksimum olub.
Layihədə müştərinin rolu
Müştərimizin ayrıldığı provayderlə əlaqə saxlamaq asan deyildi. Bu başa düşüləndir, onlar layihənin uğurla başa çatmasında maraqlı olanların siyahısında sonuncu olublar. Müştəri bütün kommunikasiya məsələlərini yüksəltmək və pedal çevirmək vəzifəsini öz üzərinə götürdü və bu 100500% öhdəsindən gəldi. Bunun üçün ona xüsusi təşəkkür edirəm. Prosesdə belə mümkün iştirak olmasaydı, layihənin nəticəsi tamamilə fərqli ola bilərdi.
Proseslərin “keçmiş” provayderin tərəfində rəsmiləşdirilməsi səbəbindən infrastruktur dəstəyi problemlərdən sözün əsl mənasında uzaq olan, o vaxt hələ də onların müştərisi olan mütəxəssislər tərəfindən həyata keçirilirdi. Məsələn, eyni verilənlər bazasını ixrac etmək prosesi bir saatdan beşə qədər çəkə bilər. Sonra elə gəldi ki, bu bir növ sehrdir, bizə heç vaxt açılmayan bir sirrdir. Yəqin ki, texniki dəstək mühəndisləri bu arada meditasiya ilə məşğul olublar, hardasa uzaq Rusiyada son tarixlərin olduğunu unudublar, yeni il salatları olmayan mühəndislər, müştəri ağlayır və əziyyət çəkir...
Layihənin nəticələri
Miqrasiyanın son mərhələsi sistemlərin texniki xidmət üçün köçürülməsi idi.
İndi biz müştərilərin müraciətləri üçün vahid pəncərə xidməti təqdim edirik və tərəfdaşımız olan itelligence ilə birlikdə infrastruktur komponentlərinin və SAP əsaslarının dəstəklənməsi ilə bağlı bütün tapşırıqları əhatə edirik. Müştəri altı aydır şəxsi buludda yaşayır. Bu müddət ərzində xidmət halları ilə bağlı statistikanı təqdim edirik:
- 90 insident (20% müştəri cəlb etmədən həll edildi)
- SLA çərçivəsində həll olunur – 100%
- Planlaşdırılmamış sistemin dayandırılması – 0
Müştərimizlə oxşar probleminiz varsa və onları necə həll edəcəyinizi öyrənmək istəyirsinizsə, aşağıdakı ünvana yazın: [e-poçt qorunur]
Mənbə: www.habr.com