Se poate? Desigur, migrarea sistemelor SAP este un proces complex și laborios, pentru succesul căruia este esențială colaborarea eficientă a tuturor participanților. Iar dacă migrarea se desfășoară într-un interval scurt de timp, sarcina devine cu mult mai complicată. Nu toți sunt pregătiți pentru asta. Pot exista mai multe motive. De exemplu, procesul este în sine lung și organizatoric complicat. În plus, există riscul unor opriri neplanificate ale sistemelor. Sau clienții nu sunt siguri că, după o astfel de operațiune, vor obține beneficii pe măsura eforturilor depuse. Cu toate acestea, există și excepții.
Sub acest articol, vă vom povesti despre dificultățile cu care se confruntă clienții în timpul migrației și întreținerii sistemelor SAP, vom discuta de ce stereotipurile nu corespund întotdeauna realității și vom împărtăși un caz în care am reușit să migrăm sistemele clientului într-o nouă infrastructură în doar puțin peste trei luni.
Hosting pentru sistemele SAP
Acum cinci ani, era greu de imaginat că clienții vor începe să utilizeze masiv resursele de hosting pentru aplicații SAP. În majoritatea cazurilor, acestea erau implementate pe premise proprii. Totuși, odată cu dezvoltarea modelului de outsourcing și a pieței serviciilor cloud, percepția clienților a început să se schimbe. Care sunt argumentele care influențează alegerea cloud-ului pentru SAP?
- Pentru începători, care doar planifică implementarea SAP, infrastructura cloud este practic o alegere standard - scalabilitatea resurselor în funcție de nevoile curente ale sistemului și nevoia de a nu devia resursele pentru dezvoltarea competențelor non-core.
- În companiile cu un peisaj sistemic complex, prin intermediul hosting-ului sistemelor SAP, CIO-urile ajung la un nivel calitativ diferit de gestionare a riscurilor, deoarece partenerul este responsabil pentru SLA.
- Al treilea dintre cele mai frecvente argumente este costul ridicat al construirii infrastructurii pentru implementarea scenariilor de disponibilitate ridicată și DR.
- Factorul 2027 - încetarea suportului pentru sistemele învechite anunțată de furnizor în 2027. Aceasta înseamnă migrarea bazei de date pe HANA, ceea ce implică cheltuieli pentru modernizare și achiziționarea de noi capabilități computaționale.
Piața de hosting SAP din Rusia poate fi considerată acum destul de matură. Acest lucru oferă oportunități largi pentru clienții care doresc să își schimbe platformele de hosting. Totuși, astfel de proiecte pot justifica temerile afacerilor din cauza complexității procesului de migrație. Acest aspect impune clienților să aibă cerințe ridicate față de furnizorii de servicii, care trebuie nu doar să aibă competențe excepționale în hosting și suport pentru sistemele SAP, ci și o experiență de succes în domeniul migrației.
Care sunt dificultățile schimbării hostingului SAP?
Există diferite tipuri de hosting. Neconformitatea cu nivelul de servicii declarat, numeroase «daruri» și asteriscuri cu condiții fine, limitările resurselor și capacităților, furnizor de găzduire, lipsa flexibilității în comunicarea cu clientul, birocrația, limitările tehnice, competența scăzută a specialiștilor din suportul tehnic, precum și multe alte nuanțe — sunt doar o mică parte din capcanele cu care se pot confrunta clienții în procesul exploatării sistemelor lor de afaceri în infrastructuri externalizate. Adesea, pentru client, toate acestea rămân în umbră, în hățișul unui contract complex, și ies la iveală abia în procesul utilizării serviciilor.
La un moment dat, devine evident pentru client că nivelul de servicii pe care îl primește este departe de așteptările sale. Acest lucru devine un catalizator pentru căutarea soluțiilor pentru a remedia situația și, în cazul eșecului, când problemele se acumulează până la un punct critic și devin dureroase, se trece la acțiuni active în vederea explorării unor opțiuni alternative în direcția schimbării furnizorului de servicii.
De ce amână până în ultimul moment? Motivul este simplu — procesul de transfer al sistemelor pentru clienți nu este întotdeauna transparent și clar. Clientului îi este greu să evalueze riscurile reale asociate cu procesul de migrație. Se poate spune că migrarea pentru clienți este un fel de cutie neagră: nu se știe prețul, timpul de inactivitate a sistemelor, riscurile și cum să le managezi, și, în general, este întunecos și înfricoșător. Aici este o problemă: dacă nu reușește, capetele vor cădea atât la lideri, cât și la executanți.
SAP — este un sistem de nivel enterprise, complex și, ca să fiu sincer, nu tocmai ieftin. Implementarea, adaptarea și întreținerea acestuia implică bugete considerabile, iar disponibilitatea și funcționarea corectă depind de viața operațională a întreprinderii. Acum imaginați-vă consecințele opririi unei mari producții. Acestea sunt pierderi financiare ce pot fi exprimate în cifre cu multe zerouri, precum și riscuri reputaționale și altele, cel puțin la fel de semnificative.
Să analizăm dificultățile care pot apărea în fiecare etapă prin cazul de migrare a sistemelor SAP pentru unul dintre clienții noștri.
Pregătire și proiectare
Migrarea este o formulă cu multe componente diverse. Și unul dintre cele mai importante este etapa de proiectare și pregătire a infrastructurii țintă (noi).
A trebuit să ne aprofundăm în implementarea existentă a sistemelor, în arhitectura acestora. În infrastructura țintă, am repetat unele soluții existente, în alte momente le-am completat și îmbunătățit, iar în unele cazuri am reproiectat, gândit și ales soluții pentru asigurarea redundanței și disponibilității, precum și am consolidat toate resursele cât mai mult posibil.
În procesul de proiectare, au fost efectuate multe exerciții diverse, care, în cele din urmă, ne-au permis să ne pregătim cât mai bine pentru migrare și să luăm în considerare toate nuanțele și capcanele posibile (despre care vom discuta mai târziu).
Ce am obținut în rezultat — o infrastructură de cloud privat proiectată individual pe baza centrului nostru de date:
- servere fizice dedicate pentru SAP HANA;
- platformă de virtualizare VMware pentru serverele de aplicații și serviciile de infrastructură;
- canale de comunicație duplicate între centrele de date pentru L2 VPN;
- două stocări de date principale pentru separarea produsului și «altor»;
- SRK bazat pe Veritas Netbackup cu un server dedicat, raft de discuri și bibliotecă de benzi.
Iată cum am implementat toate acestea din punct de vedere tehnic.
SAP
- Pentru a utiliza eficient rădăcinile pentru HANA productive, am folosit discuri comune fără replicarea sistemului de baze de date prin intermediul SAP. Totul a fost încapsulat într-un cluster Active-Standby SUSE HAE bazat pe Pacemaker. Da, timpul de recuperare este puțin mai lung decât cu replicarea, dar obținem o economisire a spațiului de stocare în două ori și, ca urmare, o economisire a bugetului clientului.
- În medii de preproductie, clusterele HANA au fost abandonate, dar configurația de producție a fost replicată tehnic.
- Mediile de testare și cele de dezvoltare au fost distribuite pe mai multe servere fără clustere în configurația MCOS.
- Toate serverele de aplicații au fost virtualizate și plasate în VMware.
Rețele
- Contururile rețelelor de gestionare și cele productive au fost fizic separate folosind stive de comutatoare, îndreptând rețelele productive spre centrul de date al clientului.
- S-a prevăzut un număr suficient de interfețe de rețea pentru a nu amesteca volume mari de trafic.
- Pentru transmiterea datelor de la sistemele de stocare, au fost realizate fabrici FC SAN clasice.
Sisteme de stocare
- Sarcina productivă și preproductivă a SAP a fost păstrată pe un array all-flash.
- Mediile de testare pentru dezvoltatori și serviciile infrastructurii au fost plasate pe un array hibrid separat.
SRK
- A fost realizat pe baza Veritas Netbackup.
- Am adăugat câteva scripturi încorporate pentru a face backup configurațiilor MCOS.
- Copiile operative au fost plasate pe un raft de discuri pentru o recuperare rapidă, iar pentru stocarea pe termen lung folosim benzi.
Monitorizare
- Toate hardware-urile, sistemele de operare și SAP au fost integrate în Zabbix.
- Am creat numeroase tablouri de bord utile în Grafana.
- În cazul unui alert, Zabbix poate genera o cerere în sistemul de gestionare a incidentelor, care la noi este implementat în Jira. De asemenea, informația este dublată într-un canal Telegram.
Telegram
Starea generală a HANA
Starea serverului de aplicații SAP:
Serviciile de infrastructură
- Pentru a gestiona spațiile interne de nume, am ridicat un cluster de servere DNS, care se sincronizează cu serverele clientului.
- Am realizat un server de fișiere separat pentru schimbul de date.
- Pentru a stoca diverse configurații, am adăugat Gitlab.
- Pentru informații sensibile, am ales HashiCorp Vault.
Procesul de migrare
În general, procesul de migrare constă în următoarele etape:
- pregătirea toată documentația de proiect necesară;
- negocieri cu furnizorul actual — rezolvarea problemelor organizaționale;
- achiziția, livrarea și instalarea echipamentului nou pentru proiect;
- migrarea de testare și ajustarea procesului;
- transferul sistemelor, migrarea reală.
La sfârșitul lunii octombrie 2019, am semnat un contract, după care am proiectat arhitectura, iar după aprobarea acesteia de către client am comandat echipamentele necesare.
Ceea ce trebuie să fie prioritizat este termenul de livrare al echipamentului. În medie, livrarea hardware-ului certificat pentru SAP NAHA, care corespunde cerințelor furnizorului de software pentru platformele hardware, durează între 10 și 12 săptămâni. Iar având în vedere sezonalitatea (implementarea proiectului coincide exact cu anul nou), acest termen ar putea să se extindă cu încă o lună. Prin urmare, a fost necesar să accelerăm procesul: am colaborat cu distribuitorul-furnizor și am negociat livrări accelerate cu avioanele (în loc de rute terestre și maritime).
Lunile noiembrie și decembrie au fost dedicate pregătirii pentru migrarea și obținerii unei părți din echipament. Pregătirea a fost realizată pe un stand de testare în cloud-ul nostru public, unde am exersat toți pașii esențiali și am identificat posibilele dificultăți și probleme:
- am pregătit un plan detaliat de interacțiune a participanților din echipele proiectului, cu timpi specificați minut cu minut;
- am construit un stand de testare pentru baza de date și serverele aplicațiilor aproximativ la fel ca în infrastructura țintă;
- am configurat canalele de comunicare necesare și serviciile infrastructurale pentru a verifica funcționarea integrărilor;
- am exersat scenarii de cutover;
- cloud-ul ne-a ajutat, de asemenea, să formăm șabloane virtuale pre-configurate, pe care ulterior le-am importat și desfășurat în peisajul țintă.
Cu puțin timp înainte de sărbătorile de Anul Nou, a sosit prima parte a echipamentului. Acest lucru ne-a permis să desfășurăm o parte din sisteme pe hardware-ul real. Deoarece nu a sosit tot echipamentul, am conectat echipamente temporare, pentru care am reușit să negociăm cu vânzătorul și distribuitorii. Restul infrastructurii țintă l-am primit deja în etapa finală.
Pentru a termina la timp, inginerii noștri au trebuit să sacrifice vacanțele de Anul Nou și să înceapă lucrul la pregătirea infrastructurii țintă pe 2 ianuarie, în plin vârtej al sărbătorilor. Da, astfel de situații se mai întâmplă, când este vorba de un termen limită și nu sunt alte opțiuni. Era în joc funcționalitatea sistemelor de care depind activitățile întreprinderii.
Ordinea generală a migrației a fost următoarea: mai întâi – sistemele cele mai puțin critice (peisajul de dezvoltare, peisajul de testare), apoi – sistemele productive. Etapa finală a migrației a avut loc la sfârșitul lunii ianuarie și începutul lunii februarie.
Procesul de migrare a fost detaliat cu precizie. Acesta este un plan cutover cu o listă a tuturor sarcinilor, timpul de execuție și persoanele responsabile. Toți pașii au fost deja exersați în migrarea de test, astfel că în migrarea reală a fost necesar doar să se urmeze planul și să se coordoneze procesul.
Migrarea a fost realizată sistematic în mai multe etape. Fiecare etapă a avut câte două sisteme.
Rezultatul sprintului de trei luni a fost un sistem complet funcțional în Data Center KROK. În general, rezultatul pozitiv a fost obținut datorită muncii colaborative, contribuția și dăruirea tuturor participanților la proces fiind maxime.
Rolul clientului în proiect
A comunica cu furnizorul pe care clientul nostru îl părăsea a fost o provocare. Este de înțeles, deoarece ei erau ultimii pe lista celor interesați de finalizarea cu succes a proiectului. Clientul a preluat sarcinile de escaladare și gestionare a tuturor problemelor de comunicare, reușind să facă acest lucru în proporție de 100500%. Pentru aceasta îi mulțumim separat. Fără o astfel de participare activă în proces, rezultatul proiectului ar fi putut fi foarte diferit.
Din cauza formalizării proceselor de către fostul furnizor, gestionarea infrastructurii era realizată de specialiști care erau, în sens literal, departe de problemele clientului lor la acel moment. De exemplu, procesul de export al aceleași baze de date putea dura între o oră și cinci. Atunci părea că este o magie, un secret care nu ni s-a deschis. Probabil, inginerii de suport tehnic se dedicau meditației, uitând că undeva în Rusia deadline-urile se apropie, inginerii fără salate de Crăciun, iar clientul plânge și suferă...
Concluziile proiectului
Coroana migrației a fost transferul sistemelor în întreținere.
Acum oferim un serviciu de tip one-stop pentru solicitările clientului și acoperim întregul volum de sarcini referitoare la întreținerea componentelor infrastructurii și SAP basis împreună cu partenerul nostru — itelligence. Clientul trăiește în cloud privat de șase luni. Iată statistica incidentelor de serviciu în această perioadă:
- 90 de incidente (20% rezolvate fără implicarea clientului)
- Rezolvate în cadrul SLA – 100%
- Opriri neplanificate ale sistemelor – 0
Dacă aveți sarcini similare cu cele ale clientului nostru și doriți să aflați mai multe despre cum să le rezolvați, scrieți: ahaidukov@croc.ru
Sursa: habr.com
